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:
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.
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.06R000 release or refer to the following table:
08.02.06R000 SBC Core Compatibility Matrix
Compatible Ribbon Products by Version | EMS | PSX | GSX 9000 | DSI | SBC 1K/2K/SWe Lite |
---|---|---|---|---|---|
Latest | 12.02.07R000 | 12.02.07R000 | 12.02.03R000 | 12.00.00R0P4 | 08.02.06R000 |
Minimum | 11.00.00R000 | 09.03.06R000 | 09.02.07R000 | 09.03.00R000 | 07.00.00 |
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.22.00-R000 |
SBC 51x0/52x0 BIOS | V2.7.0 | |
SBC 5400 Firmware | BMC: V03.22.00-R000 BIOS: V1.18.0 | |
SBC 7000 Firmware | BMC: V03.22.00-R000 BIOS: V2.14.0 | |
SBC Application | Operating System (OS) Version | V07.02.06-R000 |
SonusDB | V08.02.06-R000 | |
SBC Application | V08.02.06-R000 |
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.22.00-R000.img
firmware-5XX0-V03.22.00-R000.img.md5
bmc5X00_v3.22.0-R0.rom.md5sum
bmc5X00_v3.22.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.
DO NOT perform a LSWU on an SBC 7000 before 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.
Category | Upgrade Notes |
---|---|
Security practices |
|
Installation package removal | Once the installation or upgrade completes on the SBC 51x0 and SBC SWe platforms, the copy of the SBC Core Application Package is automatically removed from the system. |
Network licensing | Customers using network licensing mode will be converted to node locked mode (formerly legacy mode) after upgrade to the SBC 8.0.0 Release. |
SBC 5xx0/7000 CPU degradation due to Spectre/Meltdown security patches | The SBC 8.x 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. |
Performance improvements when upgrading SBC SWe on KVM Hypervisor or VMware | 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 (8.2.6R0) |
LSWU from 6.x to 8.x | 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 the PM is not supported. Please contact Ribbon Support. |
SBC 51xx and 52xx RAM requirements | The SBC 51xx and 52xx platforms require 24GB of RAM to run 6.x code or higher. |
SMM rules limitation during upgrade | The number of rules across SMM profiles in a system is limited to 10000, and the number of actions across profiles in a system is limited to 50000. Ensure the above conditions are met before a LSWU. |
SBC SWe upgrade disk requirements | |
SBC SWe upgrade requirements for VMware ESXi | 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:
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.06R000, 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.6R000.
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.06R000 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.
CPU resource allocation requirements for SBC SWe VM are strictly enforced. 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:
Set the CPU reservation for the VM so that it equals the physical processor CPU speed, multiplied by the number of vCPUs divided by two.
For example, a configuration of 4 vCPUs with a processor of 2.99 GHz CPU speed, reserve: 2992 * 4/2 = 5984 MHz
If the 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.
Customers who are using the SBC to interop with MS Teams need to review and compare their configuration against the latest configuration guide especially the SMM as it might result in call failures after upgrade if the older SMM is left in place. For more information, refer to SBC 8.2 - MS Teams Solution Guide.
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.01.00R002 |
V06.00.00F003 | V07.00.00F004 | V08.01.00R003 |
V06.00.00F004 | V07.00.00F005 | V08.01.00R004 |
V06.00.00F005 | V07.00.00F006 | V08.02.00R000 |
V06.00.00F006 | V07.01.00R000 | V08.02.00R001 |
V06.00.00F007 | V07.01.00R001 | V08.02.00R002 |
V06.00.00F008 | V07.01.00R002 | V08.02.00F001 |
V06.00.00F009 | V07.01.00R003 | V08.02.00F002 |
V06.00.00F010 | V07.01.00R004 | V08.02.01R000 |
V06.00.00F011 | V07.01.00F001 | V08.02.01F001 |
V06.00.00F012 | V07.01.00F002 | V08.02.01F002 |
V06.00.00F013 | V07.01.00F003 | V08.02.01F003 |
V06.00.00F014 | V07.02.00R000 | V08.02.01R001 |
V06.01.00F001 | V07.02.00R001 | V08.02.02R000 |
V06.01.00F002 | V07.02.00R002 | V08.02.02R001 |
V06.01.00F003 | V07.02.00S809 | V08.02.02R002 |
V06.01.00R000 | V07.02.00S810 | V08.02.03R000 |
V06.01.00R001 | V07.02.01R000 | V08.02.03R001 |
V06.01.00R002 | V07.02.01R001 | V08.02.03F001 |
V06.01.00R003 | V07.02.01R002 | V08.02.04R000 |
V06.01.00R004 | V07.02.01R003 | V08.02.04R001 |
V06.01.00R005 | V07.02.01R004 | V08.02.04R002 |
V06.01.00R006 | V07.02.01F001 | V08.02.05R000 |
V06.01.00R007 | V07.02.01F002 | |
V06.01.00R008 | V07.02.01F004 | |
V06.01.00R009 | V07.02.01F005 | |
V06.02.00R000 | V07.02.01R005 | |
V06.02.01R000 | V07.02.01R006 | |
V06.02.01R001 | V07.02.01R007 | |
V06.02.01R002 | V07.02.01R008 | |
V06.02.01F001 | V07.02.01R009 | |
V06.02.01F002 | V07.02.01R010 | |
V06.02.01F003 | V07.02.02R000 | |
V06.02.01F004 | V07.02.02R001 | |
V06.02.01F005 | V07.02.02R002 | |
V06.02.01F006 | V07.02.02R003 | |
V06.02.01F007 | V07.02.02R004 | |
V06.02.01F008 | V07.02.02R005 | |
V06.02.01F009 | V07.02.03R000 | |
V06.02.01F010 | V07.02.03R001 | |
V06.02.01F011 | V07.02.03R002 | |
V06.02.01F012 | V07.02.03R003 | |
V06.02.01F014 | V07.02.03R004 | |
V06.02.02R000 | V07.02.04R000 | |
V06.02.02R001 | V07.02.04R001 | |
V06.02.02F001 | V07.02.04R002 | |
V06.02.02F002 | V07.02.04R003 | |
V06.02.02F003 | V07.02.04R004 | |
V06.02.02F004 | V07.02.05R000 | |
V06.02.02F005 | V07.02.05R001 | |
V06.02.02F006 | V07.02.05R002 | |
V06.02.02F007 | ||
V06.02.02F008 | ||
V06.02.02F009 | ||
V06.02.02F010 | ||
V06.02.02F011 | ||
V06.02.02F012 | ||
V06.02.02F013 | ||
V06.02.02F014 | ||
V06.02.02F015 | ||
V06.02.03R000 | ||
V06.02.03F001 | ||
V06.02.03F002 | ||
V06.02.03F003 | ||
V06.02.03F004 | ||
V06.02.03F005 | ||
V06.02.03F006 | ||
V06.02.03F007 | ||
V06.02.04R000 | ||
V06.02.04F001 | ||
V06.02.04F002 | ||
V06.02.05R000 |
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 table displays the security vulnerabilities resolved in this release.
CVE | Risk | Description |
---|---|---|
CVE-2021-31873 | Critical | An issue was discovered in klibc before 2.0.9. Additions in the malloc() function may result in an integer overflow and a subsequent heap buffer overflow. |
CVE-2021-31870 | Critical | An issue was discovered in klibc before 2.0.9. Multiplication in the calloc() function may result in an integer overflow and a subsequent heap buffer overflow. |
CVE-2021-3520 | Critical | There's a flaw in lz4. An attacker who submits a crafted file to an application linked with lz4 may be able to trigger an integer overflow, leading to calling of memmove() on a negative size argument, causing an out-of-bounds write and/or a crash. The greatest impact of this flaw is to availability, with some potential impact to confidentiality and integrity as well. |
CVE-2021-31872 | Critical | An issue was discovered in klibc before 2.0.9. Multiple possible integer overflows in the cpio command on 32-bit systems may result in a buffer overflow or other security impact. |
CVE-2020-28026 | Critical | Exim 4 before 4.94.2 has Improper Neutralization of Line Delimiters, relevant in non-default configurations that enable Delivery Status Notification (DSN). Certain uses of ORCPT= can place a newline into a spool header file, and indirectly allow unauthenticated remote attackers to execute arbitrary commands as root. |
CVE-2021-25216 | Critical | In BIND 9.5.0 -> 9.11.29, 9.12.0 -> 9.16.13, and versions BIND 9.11.3-S1 -> 9.11.29-S1 and 9.16.8-S1 -> 9.16.13-S1 of BIND Supported Preview Edition, as well as release versions 9.17.0 -> 9.17.1 of the BIND 9.17 development branch, BIND servers are vulnerable if they are running an affected version and are configured to use GSS-TSIG features. In a configuration which uses BIND's default settings the vulnerable code path is not exposed, but a server can be rendered vulnerable by explicitly setting values for the tkey-gssapi-keytab or tkey-gssapi-credential configuration options. Although the default configuration is not vulnerable, GSS-TSIG is frequently used in networks where BIND is integrated with Samba, as well as in mixed-server environments that combine BIND servers with Active Directory domain controllers. For servers that meet these conditions, the ISC SPNEGO implementation is vulnerable to various attacks, depending on the CPU architecture for which BIND was built: For named binaries compiled for 64-bit platforms, this flaw can be used to trigger a buffer over-read, leading to a server crash. For named binaries compiled for 32-bit platforms, this flaw can be used to trigger a server crash due to a buffer overflow and possibly also to achieve remote code execution. We have determined that standard SPNEGO implementations are available in the MIT and Heimdal Kerberos libraries, which support a broad range of operating systems, rendering the ISC implementation unnecessary and obsolete. Therefore, to reduce the attack surface for BIND users, we will be removing the ISC SPNEGO implementation in the April releases of BIND 9.11 and 9.16 (it had already been dropped from BIND 9.17). We would not normally remove something from a stable ESV (Extended Support Version) of BIND, but since system libraries can replace the ISC SPNEGO implementation, we have made an exception in this case for reasons of stability and security. |
CVE-2020-28024 | Critical | Exim 4 before 4.94.2 allows Buffer Underwrite that may result in unauthenticated remote attackers executing arbitrary commands, because smtp_ungetc was only intended to push back characters, but can actually push back non-character error codes such as EOF. |
CVE-2021-26691 | Critical | In Apache HTTP Server versions 2.4.0 to 2.4.46 a specially crafted SessionHeader sent by an origin server could cause a heap overflow |
CVE-2021-39275 | Critical | ap_escape_quotes() may write beyond the end of a buffer when given malicious input. No included modules pass untrusted data to these functions, but third-party / external modules may. This issue affects Apache HTTP Server 2.4.48 and earlier. |
CVE-2020-28017 | Critical | Exim 4 before 4.94.2 allows Integer Overflow to Buffer Overflow in receive_add_recipient via an e-mail message with fifty million recipients. NOTE: remote exploitation may be difficult because of resource consumption. |
CVE-2021-31535 | Critical | LookupCol.c in X.Org X through X11R7.7 and libX11 before 1.7.1 might allow remote attackers to execute arbitrary code. The libX11 XLookupColor request (intended for server-side color lookup) contains a flaw allowing a client to send color-name requests with a name longer than the maximum size allowed by the protocol (and also longer than the maximum packet size for normal-sized packets). The user-controlled data exceeding the maximum size is then interpreted by the server as additional X protocol requests and executed, e.g., to disable X server authorization completely. For example, if the victim encounters malicious terminal control sequences for color codes, then the attacker may be able to take full control of the running graphical session. |
CVE-2021-40438 | Critical | A crafted request uri-path can cause mod_proxy to forward the request to an origin server choosen by the remote user. This issue affects Apache HTTP Server 2.4.48 and earlier. |
CVE-2018-20060 | Critical | urllib3 before version 1.23 does not remove the Authorization HTTP header when following a cross-origin redirect (i.e., a redirect that differs in host, port, or scheme). This can allow for credentials in the Authorization header to be exposed to unintended hosts or transmitted in cleartext. |
CVE-2019-18218 | Critical | cdf_read_property_info in cdf.c in file through 5.37 does not restrict the number of CDF_VECTOR elements, which allows a heap-based buffer overflow (4-byte out-of-bounds write). |
CVE-2020-28022 | Critical | Exim 4 before 4.94.2 has Improper Restriction of Write Operations within the Bounds of a Memory Buffer. This occurs when processing name=value pairs within MAIL FROM and RCPT TO commands. |
CVE-2020-28020 | Critical | Exim 4 before 4.92 allows Integer Overflow to Buffer Overflow, in which an unauthenticated remote attacker can execute arbitrary code by leveraging the mishandling of continuation lines during header-length restriction. |
CVE-2021-31618 | High | Apache HTTP Server protocol handler for the HTTP/2 protocol checks received request headers against the size limitations as configured for the server and used for the HTTP/1 protocol as well. On violation of these restrictions and HTTP response is sent to the client with a status code indicating why the request was rejected. This rejection response was not fully initialised in the HTTP/2 protocol handler if the offending header was the very first one received or appeared in a a footer. This led to a NULL pointer dereference on initialised memory, crashing reliably the child process. Since such a triggering HTTP/2 request is easy to craft and submit, this can be exploited to DoS the server. This issue affected mod_http2 1.15.17 and Apache HTTP Server version 2.4.47 only. Apache HTTP Server 2.4.47 was never released. |
CVE-2021-25215 | High | In BIND 9.0.0 -> 9.11.29, 9.12.0 -> 9.16.13, and versions BIND 9.9.3-S1 -> 9.11.29-S1 and 9.16.8-S1 -> 9.16.13-S1 of BIND Supported Preview Edition, as well as release versions 9.17.0 -> 9.17.11 of the BIND 9.17 development branch, when a vulnerable version of named receives a query for a record triggering the flaw described above, the named process will terminate due to a failed assertion check. The vulnerability affects all currently maintained BIND 9 branches (9.11, 9.11-S, 9.16, 9.16-S, 9.17) as well as all other versions of BIND 9. |
CVE-2021-3712 | High | ASN.1 strings are represented internally within OpenSSL as an ASN1_STRING structure which contains a buffer holding the string data and a field holding the buffer length. This contrasts with normal C strings which are repesented as a buffer for the string data which is terminated with a NUL (0) byte. Although not a strict requirement, ASN.1 strings that are parsed using OpenSSL's own "d2i" functions (and other similar parsing functions) as well as any string whose value has been set with the ASN1_STRING_set() function will additionally NUL terminate the byte array in the ASN1_STRING structure. However, it is possible for applications to directly construct valid ASN1_STRING structures which do not NUL terminate the byte array by directly setting the "data" and "length" fields in the ASN1_STRING array. This can also happen by using the ASN1_STRING_set0() function. Numerous OpenSSL functions that print ASN.1 data have been found to assume that the ASN1_STRING byte array will be NUL terminated, even though this is not guaranteed for strings that have been directly constructed. Where an application requests an ASN.1 structure to be printed, and where that ASN.1 structure contains ASN1_STRINGs that have been directly constructed by the application without NUL terminating the "data" field, then a read buffer overrun can occur. The same thing can also occur during name constraints processing of certificates (for example if a certificate has been directly constructed by the application instead of loading it via the OpenSSL parsing functions, and the certificate contains non NUL terminated ASN1_STRING structures). It can also occur in the X509_get1_email(), X509_REQ_get1_email() and X509_get1_ocsp() functions. If a malicious actor can cause an application to directly construct an ASN1_STRING and then process it through one of the affected OpenSSL functions then this issue could be hit. This might result in a crash (causing a Denial of Service attack). It could also result in the disclosure of private memory contents (such as private keys, or sensitive plaintext). Fixed in OpenSSL 1.1.1l (Affected 1.1.1-1.1.1k). Fixed in OpenSSL 1.0.2za (Affected 1.0.2-1.0.2y). |
CVE-2020-28021 | High | Exim 4 before 4.94.2 has Improper Neutralization of Line Delimiters. An authenticated remote SMTP client can insert newline characters into a spool file (which indirectly leads to remote code execution as root) via AUTH= in a MAIL FROM command. |
CVE-2021-3518 | High | There's a flaw in libxml2 in versions before 2.9.11. An attacker who is able to submit a crafted file to be processed by an application linked with libxml2 could trigger a use-after-free. The greatest impact from this flaw is to confidentiality, integrity, and availability. |
CVE-2021-28660 | High | rtw_wx_set_scan in drivers/staging/rtl8188eu/os_dep/ioctl_linux.c in the Linux kernel through 5.11.6 allows writing beyond the end of the ->ssid[] array. NOTE: from the perspective of kernel.org releases, CVE IDs are not normally used for drivers/staging/* (unfinished work); however, system integrators may have situations in which a drivers/staging issue is relevant to their own customer base. |
CVE-2021-33034 | High | In the Linux kernel before 5.12.4, net/bluetooth/hci_event.c has a use-after-free when destroying an hci_chan, aka CID-5c4c8c954409. This leads to writing an arbitrary value. |
CVE-2020-28023 | High | Exim 4 before 4.94.2 allows Out-of-bounds Read. smtp_setup_msg may disclose sensitive information from process memory to an unauthenticated SMTP client. |
CVE-2020-28012 | High | Exim 4 before 4.94.2 allows Exposure of File Descriptor to Unintended Control Sphere because rda_interpret uses a privileged pipe that lacks a close-on-exec flag. |
CVE-2020-25671 | High | A vulnerability was found in Linux Kernel, where a refcount leak in llcp_sock_connect() causing use-after-free which might lead to privilege escalations. |
CVE-2021-0512 | High | In __hidinput_change_resolution_multipliers of hid-input.c, there is a possible out of bounds write due to a heap buffer overflow. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android kernelAndroid ID: A-173843328References: Upstream kernel |
CVE-2021-32027 | High | A flaw was found in postgresql in versions before 13.3, before 12.7, before 11.12, before 10.17 and before 9.6.22. While modifying certain SQL array values, missing bounds checks let authenticated database users write arbitrary bytes to a wide area of server memory. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability. |
CVE-2021-33909 | High | fs/seq_file.c in the Linux kernel 3.16 through 5.13.x before 5.13.4 does not properly restrict seq buffer allocations, leading to an integer overflow, an Out-of-bounds Write, and escalation to root by an unprivileged user, aka CID-8cae8cd89f05. |
CVE-2021-32399 | High | net/bluetooth/hci_request.c in the Linux kernel through 5.12.2 has a race condition for removal of the HCI controller. |
CVE-2020-28019 | High | Exim 4 before 4.94.2 has Improper Initialization that can lead to recursion-based stack consumption or other consequences. This occurs because use of certain getc functions is mishandled when a client uses BDAT instead of DATA. |
CVE-2020-28008 | High | Exim 4 before 4.94.2 allows Execution with Unnecessary Privileges. Because Exim operates as root in the spool directory (owned by a non-root user), an attacker can write to a /var/spool/exim4/input spool header file, in which a crafted recipient address can indirectly lead to command execution. |
CVE-2021-23133 | High | A race condition in Linux kernel SCTP sockets (net/sctp/socket.c) before 5.12-rc8 can lead to kernel privilege escalation from the context of a network service or an unprivileged process. If sctp_destroy_sock is called without sock_net(sk)->sctp.addr_wq_lock then an element is removed from the auto_asconf_splist list without any proper locking. This can be exploited by an attacker with network service privileges to escalate to root or from the context of an unprivileged user directly if a BPF_CGROUP_INET_SOCK_CREATE is attached which denies creation of some SCTP socket. |
CVE-2021-3444 | High | The bpf verifier in the Linux kernel did not properly handle mod32 destination register truncation when the source register was known to be 0. A local attacker with the ability to load bpf programs could use this gain out-of-bounds reads in kernel memory leading to information disclosure (kernel memory), and possibly out-of-bounds writes that could potentially lead to code execution. This issue was addressed in the upstream kernel in commit 9b00f1b78809 ("bpf: Fix truncation handling for mod32 dst reg wrt zero") and in Linux stable kernels 5.11.2, 5.10.19, and 5.4.101. |
CVE-2020-28013 | High | Exim 4 before 4.94.2 allows Heap-based Buffer Overflow because it mishandles "-F '.('" on the command line, and thus may allow privilege escalation from any user to root. This occurs because of the interpretation of negative sizes in strncpy. |
CVE-2021-3713 | High | An out-of-bounds write flaw was found in the UAS (USB Attached SCSI) device emulation of QEMU in versions prior to 6.2.0-rc0. The device uses the guest supplied stream number unchecked, which can lead to out-of-bounds access to the UASDevice->data3 and UASDevice->status3 fields. A malicious guest user could use this flaw to crash QEMU or potentially achieve code execution with the privileges of the QEMU process on the host. |
CVE-2020-35524 | High | A heap-based buffer overflow flaw was found in libtiff in the handling of TIFF images in libtiff's TIFF2PDF tool. A specially crafted TIFF file can lead to arbitrary code execution. The highest threat from this vulnerability is to confidentiality, integrity, as well as system availability. |
CVE-2018-1000168 | High | nghttp2 version >= 1.10.0 and nghttp2 <= v1.31.0 contains an Improper Input Validation CWE-20 vulnerability in ALTSVC frame handling that can result in segmentation fault leading to denial of service. This attack appears to be exploitable via network client. This vulnerability appears to have been fixed in >= 1.31.1. |
CVE-2021-2388 | High | Vulnerability in the Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Hotspot). Supported versions that are affected are Java SE: 8u291, 11.0.11, 16.0.1; Oracle GraalVM Enterprise Edition: 20.3.2 and 21.1.0. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE, Oracle GraalVM Enterprise Edition. Successful attacks require human interaction from a person other than the attacker. Successful attacks of this vulnerability can result in takeover of Java SE, Oracle GraalVM Enterprise Edition. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 7.5 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H). |
CVE-2021-3246 | High | A heap buffer overflow vulnerability in msadpcm_decode_block of libsndfile 1.0.30 allows attackers to execute arbitrary code via a crafted WAV file. |
CVE-2020-11080 | High | In nghttp2 before version 1.41.0, the overly large HTTP/2 SETTINGS frame payload causes denial of service. The proof of concept attack involves a malicious client constructing a SETTINGS frame with a length of 14,400 bytes (2400 individual settings entries) over and over again. The attack causes the CPU to spike at 100%. nghttp2 v1.41.0 fixes this vulnerability. There is a workaround to this vulnerability. Implement nghttp2_on_frame_recv_callback callback, and if received frame is SETTINGS frame and the number of settings entries are large (e.g., > 32), then drop the connection. |
CVE-2021-26690 | High | Apache HTTP Server versions 2.4.0 to 2.4.46 A specially crafted Cookie header handled by mod_session can cause a NULL pointer dereference and crash, leading to a possible Denial Of Service |
CVE-2021-29154 | High | BPF JIT compilers in the Linux kernel through 5.11.12 have incorrect computation of branch displacements, allowing them to execute arbitrary code within the kernel context. This affects arch/x86/net/bpf_jit_comp.c and arch/x86/net/bpf_jit_comp32.c. |
CVE-2020-35452 | High | Apache HTTP Server versions 2.4.0 to 2.4.46 A specially crafted Digest nonce can cause a stack overflow in mod_auth_digest. There is no report of this overflow being exploitable, nor the Apache HTTP Server team could create one, though some particular compiler and/or compilation option might make it possible, with limited consequences anyway due to the size (a single byte) and the value (zero byte) of the overflow |
CVE-2019-11324 | High | The urllib3 library before 1.24.2 for Python mishandles certain cases where the desired set of CA certificates is different from the OS store of CA certificates, which results in SSL connections succeeding in situations where a verification failure is the correct outcome. This is related to use of the ssl_context, ca_certs, or ca_certs_dir argument. |
CVE-2021-3516 | High | There's a flaw in libxml2's xmllint in versions before 2.9.11. An attacker who is able to submit a crafted file to be processed by xmllint could trigger a use-after-free. The greatest impact of this flaw is to confidentiality, integrity, and availability. |
CVE-2021-3483 | High | A flaw was found in the Nosy driver in the Linux kernel. This issue allows a device to be inserted twice into a doubly-linked list, leading to a use-after-free when one of these devices is removed. The highest threat from this vulnerability is to confidentiality, integrity, as well as system availability. Versions before kernel 5.12-rc6 are affected |
CVE-2020-35523 | High | An integer overflow flaw was found in libtiff that exists in the tif_getimage.c file. This flaw allows an attacker to inject and execute arbitrary code when a user opens a crafted TIFF file. The highest threat from this vulnerability is to confidentiality, integrity, as well as system availability. |
CVE-2020-28025 | High | Exim 4 before 4.94.2 allows Out-of-bounds Read because pdkim_finish_bodyhash does not validate the relationship between sig->bodyhash.len and b->bh.len; thus, a crafted DKIM-Signature header might lead to a leak of sensitive information from process memory. |
CVE-2020-19131 | High | Buffer Overflow in LibTiff v4.0.10 allows attackers to cause a denial of service via the "invertImage()" function in the component "tiffcrop". |
CVE-2020-28009 | High | Exim 4 before 4.94.2 allows Integer Overflow to Buffer Overflow because get_stdinput allows unbounded reads that are accompanied by unbounded increases in a certain size variable. NOTE: exploitation may be impractical because of the execution time needed to overflow (multiple days). |
CVE-2021-23134 | High | Use After Free vulnerability in nfc sockets in the Linux Kernel before 5.12.4 allows local attackers to elevate their privileges. In typical configurations, the issue can only be triggered by a privileged local user with the CAP_NET_RAW capability. |
CVE-2021-22555 | High | A heap out-of-bounds write affecting Linux since v2.6.19-rc1 was discovered in net/netfilter/x_tables.c. This allows an attacker to gain privileges or cause a DoS (via heap memory corruption) through user name space |
CVE-2021-3682 | High | A flaw was found in the USB redirector device emulation of QEMU in versions prior to 6.1.0-rc2. It occurs when dropping packets during a bulk transfer from a SPICE client due to the packet queue being full. A malicious SPICE client could use this flaw to make QEMU call free() with faked heap chunk metadata, resulting in a crash of QEMU or potential code execution with the privileges of the QEMU process on the host. |
CVE-2021-42252 | High | An issue was discovered in aspeed_lpc_ctrl_mmap in drivers/soc/aspeed/aspeed-lpc-ctrl.c in the Linux kernel before 5.14.6. Local attackers able to access the Aspeed LPC control interface could overwrite memory in the kernel and potentially execute privileges, aka CID-b49a0e69a7b1. This occurs because a certain comparison uses values that are not memory sizes. |
CVE-2021-22946 | High | A user can tell curl >= 7.20.0 and <= 7.78.0 to require a successful upgrade to TLS when speaking to an IMAP, POP3 or FTP server (`--ssl-reqd` on the command line or`CURLOPT_USE_SSL` set to `CURLUSESSL_CONTROL` or `CURLUSESSL_ALL` withlibcurl). This requirement could be bypassed if the server would return a properly crafted but perfectly legitimate response.This flaw would then make curl silently continue its operations **withoutTLS** contrary to the instructions and expectations, exposing possibly sensitive data in clear text over the network. |
CVE-2021-35039 | High | kernel/module.c in the Linux kernel before 5.12.14 mishandles Signature Verification, aka CID-0c18f29aae7c. Without CONFIG_MODULE_SIG, verification that a kernel module is signed, for loading via init_module, does not occur for a module.sig_enforce=1 command-line argument. |
CVE-2021-3517 | High | There is a flaw in the xml entity encoding functionality of libxml2 in versions before 2.9.11. An attacker who is able to supply a crafted file to be processed by an application linked with the affected functionality of libxml2 could trigger an out-of-bounds read. The most likely impact of this flaw is to application availability, with some potential impact to confidentiality and integrity if an attacker is able to use memory information to further exploit the application. |
CVE-2021-34798 | High | Malformed requests may cause the server to dereference a NULL pointer. This issue affects Apache HTTP Server 2.4.48 and earlier. |
CVE-2020-28007 | High | Exim 4 before 4.94.2 allows Execution with Unnecessary Privileges. Because Exim operates as root in the log directory (owned by a non-root user), a symlink or hard link attack allows overwriting critical root-owned files anywhere on the filesystem. |
CVE-2020-25672 | High | A memory leak vulnerability was found in Linux kernel in llcp_sock_connect |
CVE-2021-25217 | High | In ISC DHCP 4.1-ESV-R1 -> 4.1-ESV-R16, ISC DHCP 4.4.0 -> 4.4.2 (Other branches of ISC DHCP (i.e., releases in the 4.0.x series or lower and releases in the 4.3.x series) are beyond their End-of-Life (EOL) and no longer supported by ISC. From inspection it is clear that the defect is also present in releases from those series, but they have not been officially tested for the vulnerability), The outcome of encountering the defect while reading a lease that will trigger it varies, according to: the component being affected (i.e., dhclient or dhcpd) whether the package was built as a 32-bit or 64-bit binary whether the compiler flag -fstack-protection-strong was used when compiling In dhclient, ISC has not successfully reproduced the error on a 64-bit system. However, on a 32-bit system it is possible to cause dhclient to crash when reading an improper lease, which could cause network connectivity problems for an affected system due to the absence of a running DHCP client process. In dhcpd, when run in DHCPv4 or DHCPv6 mode: if the dhcpd server binary was built for a 32-bit architecture AND the -fstack-protection-strong flag was specified to the compiler, dhcpd may exit while parsing a lease file containing an objectionable lease, resulting in lack of service to clients. Additionally, the offending lease and the lease immediately following it in the lease database may be improperly deleted. if the dhcpd server binary was built for a 64-bit architecture OR if the -fstack-protection-strong compiler flag was NOT specified, the crash will not occur, but it is possible for the offending lease and the lease which immediately followed it to be improperly deleted. |
CVE-2020-25670 | High | A vulnerability was found in Linux Kernel where refcount leak in llcp_sock_bind() causing use-after-free which might lead to privilege escalations. |
CVE-2020-28015 | High | Exim 4 before 4.94.2 has Improper Neutralization of Line Delimiters. Local users can alter the behavior of root processes because a recipient address can have a newline character. |
CVE-2020-28011 | High | Exim 4 before 4.94.2 allows Heap-based Buffer Overflow in queue_run via two sender options: -R and -S. This may cause privilege escalation from exim to root. |
CVE-2021-31871 | High | An issue was discovered in klibc before 2.0.9. An integer overflow in the cpio command may result in a NULL pointer dereference on 64-bit systems. |
CVE-2021-3580 | High | A flaw was found in the way nettle's RSA decryption functions handled specially crafted ciphertext. An attacker could use this flaw to provide a manipulated ciphertext leading to application crash and denial of service. |
CVE-2021-20305 | High | A flaw was found in Nettle in versions before 3.7.2, where several Nettle signature verification functions (GOST DSA, EDDSA & ECDSA) result in the Elliptic Curve Cryptography point (ECC) multiply function being called with out-of-range scalers, possibly resulting in incorrect results. This flaw allows an attacker to force an invalid signature, causing an assertion failure or possible validation. The highest threat to this vulnerability is to confidentiality, integrity, as well as system availability. |
The following 08.02.06R000 Severity 1 issues are resolved in this release:
Resolved Issues
Issue ID | Sev | Problem Description | Resolution | |
---|---|---|---|---|
1 | SBX-114842 | SBX-115013 | 1 | PortFix SBX-114842: Microsoft TEAMS Shared Line/Hold issue. Impact: The SBC fails to send ACK after mix of INVITE replaces and refer (Microsoft Teams Shared line/hold) feature. Root Cause: After received 200OK from a refer INVITE, the SBC fails to release tone announcement. Steps to Replicate: This is a complicated setup that required Microsoft TEAMS Shared line/hold feature. | The code is modified to address the issue. Workaround: Disable tone as announcement. |
2 | SBX-113170 | SBX-114825 | 1 | PortFix SBX-113170: The call fails with the NRM error "could not find a card for IP call". Impact: Some calls start failing after a switchover and continued to fail until a manual switchover was performed. Root Cause: There is no definitive root cause. The current theory is that a race condition on switchover caused an interior table to contain bad data, which resulted in internal messages being sent to the wrong process. As a result, this prevents certain calls from completing. Steps to Replicate: The steps cannot be reproduced. | The code is modified to address the issue. Workaround: This issue can be resolved by a manual switchover. |
3 | SBX-114764 | 1 | The G711 codec is used incorrectly during a G729 UPDATE. Impact: The SBC played the incorrect media towards Ingress EP after a call is established. Root Cause: Issue 1: Port was not updated after an UPDATE during tone play. After the SBC receives an UPDATE from Ingress EP during tone play, the SBC updates the codecs and port information. But after a 200 OK for UPDATE is sent out, the SBC overwrites the new information with old information. After an UPDATE is received during a tone play, the SBC tends to suppress sending UPDATE/re-INVITE towards ingress during cut-thru (after tone play) by re-using the last tone codec on ingress leg. Steps to Replicate:
Expected Results:
| The code is modified for the following issues: Issue 1: The SBC now changes the port towards Ingress EP. Workaround: None. |
4 | SBX-114012 | 1 | The SMM is not working when a From header contains an escape character. Impact: The SMM may fail to parse a display name in a double quote string, where the inside string may have more than one escape characters next to each other of a header. Root Cause: Logical error in parsing logic that cause parsing fail. Steps to Replicate:
| The code is modified to address the issue. Workaround: There is no workaround. |
5 | SBX-112445 | SBX-112879 | 1 | PortFix SBX-112445: Conference calls fail when taking a recorded (SIPREC) path, but they work when SIPREC settings are not enabled. Impact: The SBC cleanup call occured during hold retrieval for the transferred call. This issue observed only when the SIP Rec is enabled. Root Cause: Invalid operation on media resource during call hold/unhold for the transferred call leads call to cleanup. This issue observed only when the SIP Rec is enabled. Steps to Replicate:
| The code is modified to not perform any invalid operation on media resources during call hold/unhold for the transferred call. Workaround: NA. |
6 | SBX-112309 | SBX-112317 | 1 | PortFix SBX-112309: An LSWU on SWe (VMWare/KVM) via Platform Manager fails with the additional reboot of standby. Impact: An LSWU from V09.02.02R001 to any higher release 1:1 HA SWe (KVM/VMWare) through Platform manager fails because the standby instance undergoes an additional reboot during the upgrade procedure. Root Cause: Index Marker file was missing on the standby instance prior to the LSWU procedure. This is because, when the application comes up with the standby role, the Index Marker is created only when there is a mismatch in the calculated and DB populated indices. Steps to Replicate: To reproduce this issue, use the following procedure:
| The code is modified so an Index Marker file is made on the standby instance irrespective of processor index mismatch in the calculated and DB populated indices. Workaround: The workaround for the upgrade from 9.2.2R1 to any higher release: |
7 | SBX-111719 | SBX-111801 | SBX-111864 | 1 | PortFix SBX-111719: The DNS Process core dumps. Impact: The core observed in timer function when DNS lookup timer timed out. Root Cause: The DNS TCB ID as changed when NAPTR query moved from the DNS server 1 to Dns server 2. This is causing the TCB pointer to be NULL, when timer function trying fetch TCB ptr using TCB ID. Steps to Replicate: dnslookupTimeoutTimer = 20, retransmissionCount 15, retransmissionTimer 500, noPort5060 enabled
| The code is modified to pass DNS TCB pointer instead of the TCB ID as setTimer function parameter and adding proper NULL check for tcb pointer in timer function before accessing it. Workaround: No workaround. |
8 | SBX-108126 | SBX-111427 | 1 | PortFix SBX-108126: Observed a SAM Process crash in another active node during SIPFE crash testing. Impact: The SAM Process coredumps due to a buffer overflow. Root Cause: Key:value length of incoming Message is max 255 Bytes. Steps to Replicate: Steps:
Expectation:
| The code is modified to handle 255 bytes string, so the buffer overflow does not happen and display is not truncated. Workaround: NA |
9 | SBX-107976 | SBX-111426 | 1 | PortFix SBX-107976: Disable the FAC feature in M-SBC, SLB. Impact: Non-SIP personalities should not have FAC feature. So when the Non-SIP instance coredumped, then FAC handler Process was invoked to generate a core file. Root Cause: Do not have check of personalities of instances when setting core pattern. Steps to Replicate: Verify the user defined core pattern is not set in /proc/sys/kernel/core_pattern when instances are spawned with the personalities M-SBC, SLB, MRFP irrespective of facState. | The code is modified to not to set the user defined core pattern for personality type MSBC, MRFP, and SLB. Workaround: Disable the FAC Feature. |
10 | SBX-109616 | SBX-111404 | 1 | PortFix SBX-109616: A core dump was observed in the SCM process in 2vcpu system. Impact: Fault Avalanche Control is enabled by default from release 9.2. If it is disabled, it can result in a coredump. Root Cause: When the Fault Avalanche Control is disabled, the mem map file is disconnected, but the application can still try to access the mem map as the mem map pointer was not set to NULL. Steps to Replicate: Disable the Fault Avalanche Control and run calls. | The code is modified so the mem map pointer is set to NULL to when feature is disabled to address the issue. Workaround: Without this fix, avoid disabling the Fault avalanche Control. |
11 | SBX-108219 | SBX-111403 | 1 | PortFix SBX-108219: A SAM Process coredump was observed in SLB for 1000 cps Peering Call load. Impact: In a load run, there was a core being observed in the SLBDEBUG call when it hits the default states as part of the SBC message processing. Root Cause: In the SLB debug call, there was new line (\n) being passed as part of a string. Steps to Replicate: Observed this issue when running an INVITE call load with PRACK enabled | The code is modified so the new line (\n) is not part of the debug string. Workaround: There is no workaround identified for this issue. |
12 | SBX-109597 | SBX-111384 | 1 | PortFix SBX-109597: Observed an SCM process crash on the newly active SSBC during SWO testing. Impact: While the SBC is running in sensitive mode, observed the SCM Process core during a switchover testing under the 1000 cps call load. Root Cause: As part of switchover, all the connected calls are rebuilt on a newly active SBC. But, there may be a chance that the SBC can hold few stale entries related to active calls in the system, which will be cleaned up after some time. If any of these stale entries receive an unexpected events, that leads to a core dump. Steps to Replicate:
| The code is modified to identify these events for the stale entries and ignore them to avoid a coredump when the SBC running in the sensitive mode. Workaround: None. |
13 | SBX-109464 | SBX-111381 | 1 | Portfix SBX-109464: The leadership algorithm workaround for old Openclovis issue can causes a core dump. Impact: The safplus_gms process crashes when coming out of a split brain. Root Cause: Incorrect/inconsistent data results in the code asserting. Steps to Replicate: The problem is not easily reproducible and is caused by HA link instability/flapping. | The code is modified so that the data is consistent. Workaround: Fix the HA link stability issues. |
14 | SBX-115074 | SBX-115137 | 1 | PortFix SBX-115074: There were multiple SCM Process core dumps observed on the Agent SBC-Y . Impact: A SCM core dump may occur when using the SIPREC. Root Cause: The root cause is memory corruption caused by a double MemFree() in the SIPREC code. Steps to Replicate: This bug was found by code inspection. | The code is modified to prevent a double MemFree(). Workaround: None. |
15 | SBX-100881 | SBX-111382 | 1 | Portfix SBX-100881: The SBC sends a release to the H323 side. Impact: The SBC is sending a call release to the H323 side. Root Cause: During the codec selection on H323 side, the SBC ran into some offer-answer collision due to ACK SDP from SIP side. As a result, the SBC is terminating the call. Steps to Replicate:
| The code is modified so that the codec selection on the H323 side occurs independently during a modify offer-answer is in progress. Workaround: None |
16 | SBX-112322 | SBX-112799 | 1 | PortFix SBX-112322: The SBC cores when receiving a subscribe crankback failure. Impact: When a relay subscribe tries to use crankback for the second route and if the SBC does not find trunk group, the SBC may core. Root Cause: The SBC cores due to a duplicated memory freed. Steps to Replicate:
| The code is modified to prevent a duplicated free. Workaround: Correct the second route. |
17 | SBX-109324 | SBX-110740 | 1 | PortFix SBX-109324: Crankback does not work if egress TG is locally OOS. Impact: This issue occurred only for domain based routing. In case a TG is locally set to out of service, the policy request sent to PSX was not proper for the next route. The domain name in called URI section of policy request was not updated. So the SBC was sending the old domain name in Policy request. As a result, the PSX server was sending previous route, not the current route. Root Cause: In case a TG is set to out of service, the domain name in called URI section of policy request was not updated while sending policy request for next route. Steps to Replicate:
| The code is modified so the domain name in called URI section of policy request is updated properly. Workaround: None. |
18 | SBX-112381 | SBX-112412 | 1 | PortFix SBX-112381: The SBC Crash-Application is in a rebooting loop. Impact: A PRS core is occurring when the code is processing an ICE STUN packet and there are more than 20 Teams clients ringing. This could potentially happen in a simultaneous call group pickup scenario e.g. more than 20 users with a single device or 10 users with 2 or more devices - all ringing at the same time. Root Cause: The root cause of the core is a bug in the code that handles the incoming STUN packet. This code is overwriting the end of array by writing too many entries into the array. This results in memory corruption and eventually a core. Steps to Replicate: Run a call group pickup scenario with more than 20 users all having their Teams clients ringing at the same time. | The code is modified to prevent it from writing too many entries into the array. Workaround: Disable media-bypass or reduce the number of users in the call group. |
19 | SBX-111743 | SBX-113467 | 1 | PortFix SBX-111743: The SBC blacklist IP was running with the wrong port. Impact: ARS blacklists port 0, when an INVITE contains a Route header without a port number, and the 503 response contains Retry-After header. Root Cause: The code is not supported when no port number is provided. Steps to Replicate:
| The code is modified so when there is no port number is set, we now retrieve the port number from the transaction control block. Workaround: Define an SMM rule that adds the port number (5060) if the Route header in the initial INVITE does not contain a port number. |
20 | SBX-112349 | SBX-112846 | 1 | PortFix SBX-112349: There was a SBC 132 Release code (MODULE FAILURE). Impact: An Async CMD Error was reported by XRM triggered call being torn down with the release code 132 when running an audit call. Root Cause: With the high level error messages, we can only determine that there is some kind of race conditions for certain call flow(s) when a RID modify command was received for a disabled RID. (RID = receive ID in NP). Without call informatiuon, the root cause could not be determined. Steps to Replicate: The steps cannot be reproduced. | The code is modified to address the issue. Workaround: None. |
21 | SBX-111688 | SBX-112127 | 1 | PortFix SBX-111688: The ReqURI and TO fields in SIP INVITE were rolled. Impact: When the Diversion header is presented in ingress INVITE without an RN in Request-URI, the egress RURI would use RN in username field, after PSX LNP dip. Root Cause: A fix for a previous fix has caused a problem for the RURI username settings and resulted in this issue. Steps to Replicate:
| The code is modified to ensure the RURI always contains the correct username. Workaround: Use the resolution in Warning-21-00029918. |
22 | SBX-105657 | SBX-109923 | 1 | PortFix SBX-105657: A SBC Upgrade failed. Impact: The LSWU upgrade failed from 7.2.2R0 to 8.2.3R0 Root Cause: The /tmp partition was running out of disk space and restoration failed during the upgrade. Steps to Replicate: Run an LSWU upgrade from 7.2.2R0 to 10.0.0. | Ensure the enough space available to address the issue. Workaround: Free some space in /tmp dir and re-ran the upgrade. |
23 | SBX-110303 | SBX-110822 | 1 | PortFix SBX-110303: The Mgmt Port Status was showing the wrong Status. Impact: An unconfigured Management port is shown as UP when there is no cable connected to the port. Root Cause: The SBC did not keep track of management port status if the management port is not configured/used. Steps to Replicate:
| The code is modified to keep track of the management port state changes even if there is no Management IP interfaces on the management ports. Do not generate management port down event if there is no Management IP interfaces on the management port. Workaround: None. Optionally, connect unused management ports to Ethernet switch to reflect the port UP status. |
24 | SBX-108325 | SBX-111429 | 1 | Portfix SBX-108325: The SBC failed to split the SBC2, and the SBC2 did not take over Impact: The safplus_gms process crashes when coming out of a split brain. Root Cause: Incorrect/inconsistent data results in the code asserting. Steps to Replicate: The steps cannot be reproduced. | The code is modified so that the data is consistent. Workaround: Fix HA link stability issues. |
25 | SBX-113471 | SBX-113598 | 1 | PortFix SBX-113471: Multiple SBC core dumps were detected. Impact: The SBC was forking hashtable corrupted memory. Root Cause: Possibility of forking control fails to remove from hashtable when there is a resource cleanup. Steps to Replicate: The steps cannot be reproduced. | The code is modified to ensure the forking call is removed from hashtable when free. Workaround: None. |
26 | SBX-110247 | SBX-110308 | 1 | PortFix SBX-110247: The "sonusSbxNodePolicerMinorAlarmNotification" alarm is generated by the SBC. Impact: Packets arriving on a unallocated port do not get marked as rogue media. Root Cause: The issue occurs only on ports that were used and disabled. Packets arriving on this port get marked as grace-media packets. This is due to a very high value of grace period is being incorrectly programmed for the udp port instead of the default 4 seconds. The high value is because of endianness. Steps to Replicate:
| The code is modified to perform the appropriate endianness translation on the affected fields to arrive at the correct value. Workaround: No workaround. This does not affect normal media processing, or associated statistics. |
27 | SBX-110003 | SBX-110191 | 1 | PortFix SBX-110003: The SBC5400 coredump after MSRP call with direct media Impact: A PRS core was encountered when customer was running MSRP with direct media and MSRP Multiplexing was enabled. Root Cause: The root cause is when the the MRM code is using an invalid index to get a pointer to an array element. Steps to Replicate: This is not reproducible as it is most likely triggered by a race condition. | The code is modified the ensure that MRM uses the correct index when attempting to get a pointer to an array element. Workaround: The only known workaround is to avoid running MSRP with direct media and MSRP Multiplexing. |
28 | SBX-109336 | SBX-110040 | 1 | Portfix SBX-109336: The SBC 5110: BIOS not updated to 2.07 post-upgrade as indicated in Release Notes. Impact: The BIOS is not upgrading part of the SBC application upgrade. Root Cause: The flashroom utility is using /dev and /proc file system to upgrade BIOS. these file systems are un-mounted part of grub2 config upgrade. Steps to Replicate: Upgrade the SBC app from 7.x (BIOS=2.6) to >= 8.1.x.(BIOS = 2.7). The BIOS should upgrade part of an application upgrade. | Mount /dev and /proc file system before calling BIOS upgrade Workaround:
This scripts will take few minutes to update BIOS, after its done reboot host. In next boot it will boot up with new BIOS. |
29 | SBX-108388 | SBX-108450 | 1 | PortFix SBX-108388: The SBC set "user=phone" on Dummy History-Info header. Impact: When interworking between diversion header and history info header if the diversion count is more than 2 then the SBC generates dummy history info headers. These dummy history info headers contain user=phone which some end points reject. Root Cause: The code was mistakenly adding the user=phone attribute even when no phone number was present in the dummy history info header. Steps to Replicate: Configure the SBC to support interworking from diversion header with a count of 5 to history info headers and check that the dummy history info headers do not include user=phone. | The code is modified not to include user=phone in the dummy history info headers. Workaround: Use SMM to remove the user=phone attribute from the dummy history info headers. |
30 | SBX-108225 | SBX-109350 | 1 | PortFix SBX-108225: Observed core files on fresh installed VMware SWe. Impact: The SSREG and SLWRESD processes a coredump on VMware SWe due to the time being set in past. Root Cause: When the SBC is installed using ISO and then app is installed, the ntp sync is occurring while the application is running and in case the time is set in the past, it causes SSREQ and SLWRESD processes to core dump. Steps to Replicate: Launch with the NTP IP other than a default IP, check if a coredump occurs due to time being set in the past. | The code is modified to update the /etc/ntp.conf before the SBC comes up so the runntpdate can access the NTP server IP. Workaround: No workaround. |
31 | SBX-108237 | SBX-108946 | 1 | PortFix SBX-108237: Performance: Observed SAM and SCM process coredump for FAC enabled execution on SBC 5400 Impact: The SCM experiences a core dump when the Invite gets a transaction timeout and the 200 Ok for Invite is received at the same time. Root Cause: In the problem scenario, the SBC is trying to send ACK for the 200 OK, the SCM cores when creating a SIP Transaction for ACK Message. Steps to Replicate:
A race condition might occur and result in coredump. | The code is modified not to send ACK in this scenario as the CseqType and CseNumber are unknown and 0 respectively. Workaround: Not Applicable. |
32 | SBX-96247 | SBX-110668 | 1 | PortFix SBX-96247: An SCM Process core occurs in the standby SBC after switchover while testing SIPREC with ARS. Impact: A newly-active system may core upon the transition to the active SBC in either of these two circumstances: 1) ARS profile is configured on the active, but not the standby SBC. This core will rarely happen - even under these circumstances - because an internal race condition is also necessary for it to occur. Root Cause: The code that handles blacklisted endpoints when a system is transitioning to active frees a chunk of memory and then continues to attempt to access this memory. Steps to Replicate: A non-reproducible race condition is required in order to replicate this condition. | The code is modified so that the SBC no longer accesses the memory after it has been freed. Workaround: N/A |
33 | SBX-108612 | SBX-111402 | 1 | Portfix SBX-108612: An SCM Process core dump occurred when INVITE with message size of 31700 bytes is sent Impact: Receipt of SIP messages with Content-Type: multipart/mixed and more than 10 content entries cause coredump, if a message manipulation rule is active with criterion on message body. Root Cause: Missing handling for unexpected message received. Steps to Replicate:
| The code is modified so that if more than 10 content entries are present, the message is not considered for SMM rule actions with criterion on message body. Workaround: None. |
34 | SBX-109922 | SBX-111383 | 1 | Portfix SBX-109922: The buffer used while printing PSP's was running out. As a result, this is an error. Impact: The buffer used while printing PSP's was running out because of large PSP. As a result, this is an error. Root Cause: The buffer used while printing PSP's was running out. As a result, this is an error. Steps to Replicate:
| The code is modified to accommodate bigger strings. Workaround: None. |
35 | SBX-107133 | SBX-111047 | 1 | Portfix SBX-107133: Max FD limit is reached in SLB beyond 7,04,000 TLS connections (Access Registrations) tried. Impact: Max FD limit is reached in the SLB beyond 7,04,000 TLS connections (Access Registrations) tried. Root Cause: Observing the FD congestion at high load due to FD limits reached. Steps to Replicate:
| The code is modified for the max FD for the KVM and SLB. Workaround: None. |
36 | SBX-108270 | SBX-110279 | 1 | PortFix SBX-108270: The S-SBC sends a DNS SRV before completing all NAPTR query. Impact: The S-SBC sends DNS SRV before completing all NAPTR query. Root Cause: A DNS agent request timeout occurs after 10 seconds. Because the DNS agent sends the DNS lookup (NAPTR) request to DNS Client process, the DNS client process then queries to an external DNS server for NAPTR records. The DNS agent waits until 10 seconds then timeout's for each DNS lookup. As a result, the DNS request is failed with the first DNS server and query is still in process for a second DNS server. Steps to Replicate: Configure 2 DNS server's
Observation:
| The code is modified to:
Workaround: None. |
37 | SBX-111100 | SBX-111800 | 1 | PortFix SBX-111100: Host check validation failing - Required GB RAM 6 but found 0.03125. Impact: The few host machines in the AWS data center use different units for RAM, HostCheck script assumes that available memory is given in MB. The HostCheck script is fixed to calculate available memory based on unit of memory. Root Cause: The HostCheck script does not have code to consider memory unit. Steps to Replicate: Create VM with >=32 GB RAM, application should come up without complaining about memory in VM. | The code is modified to calculate available resources based on units. Workaround: Create instance/VM that has < 32 GB RAM. |
38 | SBX-105370 | SBX-112797 | 1 | PortFix SBX-105370: The Active Register per TG shows more than the total stable registration. Impact: Under some condition(s), the ingress zone’s activeRegs count can be incremented and not decremented when the registration terminates. The causes the ingress zone’s activeRegs count to grow incorrectly, and never reach ZERO (even after all registrations are terminated). Root Cause: The SIPFE and SIPSG RCB allocation/deallocation become out of sync, indirectly causing the ingress zone's activeRegs count to increment and not decrement. Steps to Replicate: Perform REGISTER/401 - REGISTER/403 until the ingress zone activeRegs count issue is detected. | The code is modified to correctly handle the SIPFE's registration bind timer expiration. Workaround: None. |
39 | SBX-110350 | SBX-111624 | 1 | PortFix SBX-110350: The SBC is forming invalid packet where it is adding 00 in around all headers and parameters. Impact: The SBC puts a NULL termination in every parameter and header of the message. In this case, there was a parser error on a parameter when the DNS translation was required. Root Cause: During the parsing of the message after a DNS query, if a parser error occurs, then incorrect termination is put/left in the message when sent on the wire. Steps to Replicate:
| The code is modified to:
Workaround: On the Ingress, apply an SMM to rename alert_info to an unknown (x-alert_info), and rename back on the egress. |
40 | INS-43702 | SBX-111628 | 1 | PortFix SBX-109244: The SBC Configuration Manager shows "no records found" for SIP TG. Impact: The SBC Configuration Manager shows "no records found" for SIP TG. Root Cause: There is no OAM check in the EMA code. Steps to Replicate:
As a result, we can see the total number of records. | The code is modified to address the issue. Workaround: None. |
41 | SBX-112307 | SBX-112955 | 1 | PortFix SBX-112307: A customer's SBC 7000 SIPREC metadata did not contain an ‘AOR’ parameter value. Impact: In the SIPREC, the metadata sender and receiver's AOR fields for the tel URI were not populated properly. Root Cause: Due to defect in the design, these fields were populated incorrectly. Steps to Replicate:
| The code is modified to populate as per requirements/standard. Workaround: Not Applicable. |
42 | SBX-110354 | SBX-110832 | 1 | Portfix SBX-110354: After upgrading from V08.02 or V09.02 to 10.00.00R000 successfully, a REVERT from 10.00.00R000 to V08.02.04R000 is failing. Impact: Reverting from the higher software version to lower software version fails. Root Cause: The OAM does not upload restored revision against lower software version (ie. restore of config tar ball that was created on lower software version before upgrade). After following the MOP for downgrade when OAM comes up, it downloads the last revision uploaded on EMS (in this case config revision for higher software version). As a result, it fails to start the service because of a version mismatch. Steps to Replicate:
Expected O/P: The OAM should come up with revision 10 created from revision 9. | The code is modified to upload a configuration when a revision that is created on a lower software version is restored. And after a downgrade, it picks the revision with software version where the downgrade is done. Workaround: None. |
43 | SBX-107753 | SBX-113186 | 1 | PortFix SBX-107753: After the LSWU, the apache2 not coming up, resulting in an EMA or PM access issue. Impact: After an upgrade, the Apache did not start. Root Cause: Apache did not start due to a timeout while requesting a password. The Apache would need to be restarted manually especially in case of a failed upgrade. Steps to Replicate:
| The code is modified to find any occurrence of the one-time-issue of server key getting corrupted in the future. Workaround: In case of a failed upgrade or apache startup failure restart apache or apply the workaround mentioned in an issue relating to the apache2 failing after an LSWU. |
44 | SBX-106316 | SBX-112966 | 1 | PortFix SBX-106316: The call established prior to a switchover fails when put on hold after a switchover. Impact: The call established prior to a switchover with a dynamic payload type fails when put on hold after switchover. Root Cause: After a switchover, while processing the hold request, it was unable to locate the codec due to an issue in reconstruction of some flags in PSP data. Steps to Replicate:
result: Call hold invite should be successful with 200 ok for that and call un-hold should also be successful. | The code is modified so that necessary flag for dynamic payloads in PSP data are reconstructed properly. Workaround: Disable“Lock Down Preferred Codec” and enable “Relay Data Path Mode Changes". |
45 | SBX-107747 | SBX-112650 | 1 | PortFix SBX-107747: During Cyclic switchover tests, a PRS Process coredump was observed on the MSBC1. Impact: The application on both active and standby switched over and application reset in short order of each other. Core files were created on both sides of the HA pair. Root Cause: The issue occurs during multiparty call processing, when the SBC tries to determine whether a message was destined for an ingress or egress call segment. As a result of running multiparty call processing, the code was accessing the pointer to the multi party call resource after it was freed up and set to NULL. Steps to Replicate: This issue is not reproducible. Potentially due to a race condition in the code. | Check the multi party call pointer is not NULL before reading from it to avoid the coredump. Workaround: There is no known workaround for this issue. |
46 | SBX-112561 | SBX-112835 | 1 | PortFix SBX-112561: The regexp string "\r\n" was not exported by “user-config-export”. Impact: The \r\n in regex is lost while exporting a configuration using the user-config-export CLI command. Root Cause: XML formatting trims empty node values. Steps to Replicate:
| Use the external XML tool called xmllint. Workaround: Manually edit the field in xml file after export. |
47 | SBX-108127 | SBX-111433 | 1 | Portfix SBX-108127: 9.1r3 to 10.0 LSWU failed with the reason "Failed_to_install_or_configure_database" Impact: The LSWU failed with the reason "Failed_to_install_or_configure_database". Root Cause: Ownership for the files in /var/log/postgresql is getting changed at the time of the upgrade. Steps to Replicate: Perform an upgrade from any version to 9.x | The code is modified to restore ownership of the log files in /var/log/postgresql to postgress. Workaround: None. |
48 | SBX-106329 | SBX-106861 | 1 | PortFix SBX-106329: The SBC disconnects a call every few seconds after recovering a DNS server. Impact: The SBC disconnects a call every few seconds after recovering a DNS server. Root Cause: The DNS client sends a failed lookup response to a DNS agent ( SCM ID 03,01 ...) when a probe query fails to get a response for a blacklisted DNS server because a probe query and regular query were used the same FQDN, record type and zone id. Steps to Replicate: DNS settings: Three DNS servers are configured. Each weight is set to 50. DNS#1 10.xxx.x.xxx has RRs with ttl=5 | The code is modified so the DNS probe query does not trigger any response towards a DNS agent from DNS client. So do not send any failure response to the DNS agent in case of probe query failure. Workaround: None. |
49 | SBX-110833 | SBX-111271 | 1 | PortFix SBX-110833: There are call trace logging issues while all Call Trace filters are disabled. Impact: Messages traced at level 4 for sageTracing may erroneously have FILTER=<name> in the trace header. For the sageTracing, the filter name should be blank. With the sageTracing enabled, 70% of the received INVITES are traced at the level 4 and 0.5% of calls have all their messages traced at level 4. The sageTracing is tracing collected for the Strategic Analysis Gap Execution. Root Cause: The filter name messages traced for sageTracing should be blank but instead uses the 64th entry in the filter names table. Steps to Replicate:
| The code is modified to filter the name blank. Workaround: None. |
50 | SBX-106475 | SBX-110900 | 1 | Portfix SBX-106475: The Cloud SBC instances are not coming up after a fresh installation or rebuild and the MGMT I Pis unreachable in BLR-PC3. Impact: The SBC instances are not coming up after a fresh installation or rebuild and the mgmt ip is unreachable when using the X710 sriov vfs for pkt interfaces. Root Cause: The X710 driver reset has been known to experience a delay in completing, thus causing a cloud-init service failure. For example, after the OS boot (as part of renaming the interfaces by sonusdev), the X710 driver is restarted. When the X710 does not immediately reset, the next cloud-init service fails, and the system is not in proper state. Steps to Replicate: The SBC instances should come up properly after fresh installation or rebuild and mgmt ip should be reachable with all supported sriov vfs for pkt interfaces. | The code is modified so after the renaming is done and the network driver is restarted, wait for some seconds to check if all the nic ports are up and running in sonusdev itself, before exiting the service. This blocks all other dependent service from starting. Once the nic port are up, proceed with the system bring up. With these code changes, the nic does not come up then, we log it as critical log and expect the user to check on it. Workaround: None. |
51 | SBX-107374 | SBX-108986 | 1 | PortFix SBX-107374: A discarded UPDATE of media addition when a data connect TCP stream calls. Impact: When an UPDATE is received with new additional stream, the S-SBC sends an alloc request to a different M-SBC instead of sending to the M-SBC that processed the initial INVITE. This is results in resource allocation failure and S-SBC sends 488 response. Root Cause:When an UPDATE is received with new additional stream, the S-SBC sends an alloc request to a different M-SBC instead of sending to the M-SBC that processed the initial INVITE. This is results in resource allocation failure and S-SBC sends 488 response. Steps to Replicate: The steps cannot be reproduced. | The code is modified to ensure that new allocation requests are sent to same M-SBC if there the prior allocation requests are processed by a particular M-SBC. Workaround: No workaround |
52 | SBX-107517 | SBX-108989 | 1 | PortFix SBX-107517: Import configuration results in two different final status depending where you look at it. Impact: The postgres DB restore fails that leads to provisioning issues such as: Root Cause: The PostgressDB restore is failing due to restricted permission. Steps to Replicate: Set up required: 1to1 S-SBC virtual platform and register it within Direct-Single type of cluster on EMS.
| The code is modified to permit an appropriate permission to postgres user while restoring the pg_policy dump. Workaround: Use the following steps: Update the oam-config.sh on active and standby the SBC as following: |
53 | SBX-110066 | SBX-110492 | 1 | Portfix SBX-110066: Observed a SAM Process core dump in SLB while testing Performance with SLB (TLS Peering Calls) - One time Occurrence. Impact: A SAM Process core was observed on a shutdown. Root Cause: A race condition in the process shutdown code occurred allowing access to an invalid pointer, and causing a core dump during the shutdown of the SAM Process. Steps to Replicate: Restart the SBC and look for a SAM Process core. | The code is modified to avoid the race condition that led to the core. Workaround: No workaround, but since this core is during shutdown, there is no impact to normal operations of the SBC. |
54 | SBX-106058 | SBX-108300 | 1 | PortFix SBX-106058: Multiple coredumps were observed during a Load run for generated Subscription call Flow tested during Registration Display Enhancement feature. Impact: Multiple coredumps were observed when Reg-Event Subscription feature flag gets enabled. Root Cause: Core 1: Incorrect type cast of a structure led to invalid memory access and core was observed. Steps to Replicate: Load test for Reg-Event Subscription initiation. | Core 1: The code is modified to point to valid memory. Workaround: N/A |
55 | SBX-110248 | SBX-110734 | 1 | PortFix SBX-110248: The SBC SWe crashes when making a video call with a certain type of phone. Impact: The SBC SWe NP crashes when IPsec fragmented signaling packets scenario calls made by using IPsec crypto as NULL encryption. Root Cause: During the IPsec crypto null processing of fragments (chained mbuf segments) by the SWe NP, an incorrect first segment length corrupted adjacent buffers, which resulted in a crash of the SBC SWe. Steps to Replicate: Establish IPsec session with null encryption and make calls. | The code is modified to address the issue. Workaround: Use IPsec non-null encryption suites such AES/3DES. |
56 | SBX-107430 | SBX-108139 | 1 | PortFix SBX-107430: URI parameter setting order of R-URI does not meet RFC 3966 requirements. Impact: In the request URI, the isub parameter was after the NPDI parameter, which does not meet the RFC 3966 requirement. (ie. npdi;isub=1111) Root Cause: In the code (sipsgCallProcEngine.c), the isub parameter was getting populated after NPDI and other user parameter. Steps to Replicate:
| The code is modified so the isub parameter populating function is moved before all other parameter populating functions. Workaround: NA |
57 | SBX-109327 | SBX-111049 | 1 | Portfix SBX-109327: Some CDR Events in ACT files have timestamps that are not current. Impact: Duration Field (+24 Duration of SIP Registration/Subscription Context) is not displayed for some register transaction. Root Cause: Duration Field (+24 Duration of SIP Registration/Subscription Context) is only updated in case of de-register for Successful transaction. Steps to Replicate:
| The code is modified to display the duration of SIP Registration/Subscription context for every CDR event. Workaround: None. |
58 | SBX-112624 | SBX-113406 | 1 | PortFix SBX-112624: The SBC is unable to recognize a PRACK message, when call hunts to a secondary route. Impact: The PRACK was rejected with a 481 when the end-to-end PRACK is active if a call is cranked-back following a successful end-to-end PRACK on the earlier route. Root Cause: If end-to-end PRACK is performed on the first route and then a late crank-back occurs, subsequent PRACK is rejected because stale information is present from the first route. Steps to Replicate:
The 18x is received on the second route. When the calling party responds with PRACK, the call has a 481 in response. | The code is modified so that end-to-end PRACK information is started fresh for each route. Workaround: None. |
59 | SBX-106760 | SBX-107965 | 1 | PortFix SBX-106760: Performance: While running IMS AKA Registrations on SWe KVM, cannot achieve 1000 subscribers with 30 RPS properly. Impact: The SBC was not able to achieve the IMS AKA registrations even at a lower rate (30 registrations per second). Root Cause: For one of the IPSec features, the XRM code was modified to perform route lookup and next hop destination MAC resolution during IPSec SA setup. This was causing a delay in setting up IPSec SAs during load causing timeouts during the IMS AKA registration. Steps to Replicate: Run the IMS AKA Registration load at 30rps. | The code is modified to not invoke the route loopup and destination MAC resolution code that is causing delay in setting up IPSec SA, which addresses the issue. Workaround: None. |
60 | SBX-110184 | SBX-110502 | 1 | Portfix SBX-110184: Performance: While pumping Emergency call load on top of normal call load, HPC calls are getting rejected with 488 sip Error due to dsp overload even though resources were reserved on Openstack D-SBC HA. Impact: The HPC calls are rejected with 488 even though the SBC has sufficient DSP resources reserved for such calls through the highPriorityCompressionReservation configuration. Root Cause: In a D-SBC setup, when DSP allocation request is received, the T-SBC applies the call admission policy to know whether the call can be admitted or not before proceeding with DSP allocation. In this process, the T-SBC was not considering if the allocation request was for HPC call or normal call. As a result, the HPC calls were treated like normal call leading to rejections if this T-SBC is running under high load. Steps to Replicate:
| The code is modified to give preferential treatment to HPC calls during call admission policy at the T-SBC. Workaround: No workaround. |
61 | SBX-107182 | SBX-110913 | 1 | Portfix SBX-107182: Performance: Observed "154 02172021 101624.655260:1.01.00.07241.MAJOR .NRS: ARP lookup for 172.10.2.3 on interface pkt0.2 with addrContextId 1 failed: SIOGARP error , error 6" MAJOR Logs on SBC while running. Impact: The MAJOR logs related to the ARP lookup was getting logged in the .DBG files, when the IMS AKA registration load is run. Root Cause: The log is generated when there is no ARP entry in the ARP table. The debug log was generated for each UE IP, for which there is no ARP entry. For one of the IPSec features, the XRM code was modified to perform a route lookup and destination MAC resolution during the IPSec SA setup. The ARP lookup is done as part of MAC resolution. Steps to Replicate: Run IMS AKA Registration load. | The code is modified to not invoke the route loopup and destination MAC resolution code that is causing delay in setting up IMS AKA registrations, which addresses the issue. Workaround: None. |
62 | SBX-111223 | 1 | Memory leak since upgrading to 8.2.5R0. Impact: High memory utilization. Root Cause: Two leaks of the same structure exist:
Warning-21-00029922 pertains to this issue. Steps to Replicate:
|
Workaround: None. Once the memory utilization reaches 91%, an automatic switchover occurs. To avoid an automatic switchover, Ribbon recommends performing a manual switchover during a low traffic period. |
63 | SBX-108317 | 1 | The SBC switchover and isolation of node/SVWSBCD. Impact: The PRS core was truncated because a second ABRT was sent to the process. Root Cause: The PRS core was truncated because a second ABRT was sent to the process while it was in the process of writing the core. Steps to Replicate: This issue is not reproducible. | The code is modified to prevent sending two ABRT signals to the same process Workaround: There is no workaround. |
64 | SBX-109200 | 1 | Missing the CDR for Teams call transfer scenario. Impact: For an MS Teams blind transfer scenario with tonesAsAnnouncements enabled, where the MS Teams user A establishes a call to PSTN user B, then MS Teams user A establishes a call to user C and then invokes a blind transfer to establish the call between B and C. When the call is subsequently cleared one of the CDR STOP records for the call is not generated. Root Cause: When the tonesAsAnnouncements are enabled, after a blind transfer is initiated from user A, the subsequent call clearing logic is not correctly deactivating the internal announcement resources causing the call to not fully clear internally which results in STOP record not being generated. Steps to Replicate: With the SBC configured for MS Teams having DLRBT with announcementBasedTones enabled.
The SBC should generate START and STOP CDR records for A-B and A-C call. | The code is modified to correctly deallocate announcement resources for this call scenario so subsequent call clear can complete successfully and generate the correct CDR stop records. Workaround: If tonesAsAnnouncements are disabled the call scenario works as expected. |
65 | SBX-110323 | 1 | A SWe media Issue occurred after an active reboot Impact: Media issue after switchover. Root Cause: Before a switchover, the loopback call was set up with 2:xx:xx:x:x:x (vbsc1's pkt port mac address) for both src and dst MAC address. After switchover, from packet capture, we found that the SRC MAC address= 2:xx:xx:x:x:xx (vsbc2's pkt port mac address). As a result, using the srcMac and dstMac caused a media issue. Steps to Replicate: Use the following configurations to test:
| The code is modified to use loopback flag mirrored to standby BRM, and overwrite both srcMac and dstMac if loopback flag is set to true. This is done only on SWe when enabling or modifying the RID. Workaround: No workaround. |
66 | SBX-111126 | 1 | In the case of delayed offer, the SBC changes the attribute “a=sendonly” into “a=recvonly” before relaying the 200 OK INVITE. Impact: The direction attribute in 200OK sent in response to late media reinvite is set to an incorrect value when the direction attribute received in 200OK from other side is a value other than a=sendrecv. Root Cause: The datapathmode on the side receiving the late media invite is incorrectly copied from the SBC local datapathmode from the answer leg PSP receiving 200OK when sendSbcSupportedCodecsInLateMediaReinvite flag is enabled. Steps to Replicate:
| The code is modified so the datapathmode in the active PSP on late media offer side is recomputed when the sendSbcSupportedCodecsInLateMediaReinvite flag is enabled. Workaround: Disable the sendSbcSupportedCodecsInLateMediaReinvite IPSP flag on TG receiving late media reinvite. |
67 | SBX-110842 | 1 | A switchover on the SBC 5400. Impact: The SAM process core dumped when the SIP code was attempting to lookup a internal SIP Registration Control Block. Root Cause: The core was the result of SIP code attempting to using a invalid index when accessing an array element for the purposes of finding a internal SIP Registration Control Block. Steps to Replicate: The steps cannot be reproduced. | The code is modified to prevent the use of an invalid index when accessing an array element. Workaround: There is no known workaround. |
68 | SBX-110639 | 1 | When the call is dipped the invite sends only the LRN. Impact: When ingress INVITE's DIVERSION header does not present and TO header is different from RURI, i.e., it has redirecting original number, the egress RURI will take translated number, i.e., LRN, as RURI in egress INVITE, after LNP dip. Root Cause: The RURI should take LRN in egress, while DIVERSION header in ingress presents. But the code change for a previous issue has made RURI equal to LRN even DIVERSION header was missing. Steps to Replicate:
This should reproduce the problem. | The code is modified the condition to only set RURI equal to LRN while DIVERSION header presents. Workaround: None. |
69 | SBX-112366 | 1 | A customer's redundancy had an unexpected switchover. Impact: The SBC is coring in the IPsec/IKE code when a call is using an IKE Protection Profile that was configured without any algorithms. Root Cause: The SBC coredumped in the IPsec/IKE code due to an attempt to de-reference a NULL pointer. The pointer is NULL because the IKE Protection Profile being used was configured without any algorithms. Steps to Replicate:
| The code is modified to check for a NULL pointer and take the correct error path when the pointer is NULL. Workaround: When configuring the IKE Protection Profiles, ensure that an algorithm is configured for this profile. |
70 | SBX-112996 | 1 | There was a SCM core dump. Impact: A rare race condition triggers a bug that caused SCM to core. Root Cause: A bug in the code causes an attempt to access freed memory. This Gateway-to-Gateway bug has has existed for a very long time, but was not encountered until now. The bug is triggered by a rare race condition. Steps to Replicate: This bug was found through code inspection. The bug is triggered by a rare race condition that is not reproducible. | The code is modified to avoid accessing freed memory. Workaround: There is no workaround. |
71 | SBX-112091 | 1 | The SBC is not passing an UPDATE to Egress. Impact: If the SBC receives two 180 responses (first unreliable and second reliable) both with same SDP then the SBC is not sending UPDATE to Egress. Root Cause: The SBC receives two 180 responses (the first unreliable and the second reliable) both with same SDP, if the SBC sends out SDP using the non reliable 180, the offer/answer state is not updated when receiving the second 180 based on how the SBC is coded today. Steps to Replicate:
| The code is modified so that when receiving an SDP in unreliable (100rel not supported) 18x message, the Offer/Answer state does not update properly. If the SBC receives a subsequent 18x with 100 rel, the Offer/Answer state changes and this helps in correctly processing the subsequent UPDATE message. Workaround: None. |
72 | SBX-112010 | 1 | A user is Registered on UDP and INVITE (same port/IP) on TCP fails with 403. Impact: A user is Registered on UDP and INVITE (different port) on TCP fails with 403 Root Cause: Once the maskportforRcb flag is enabled, parent RCB is found but child RCB is not. Mask port and mask IP were not considered during child creation. Steps to Replicate:
| The code is modified to address the issue. Workaround: Not available. |
73 | SBX-112447 | 1 | The SIPRec recording failed for an EGRESS call with GCID. Impact: The SIPREC sessions fail with the following "MAJOR" logs when a CS call is going for call a modification with re-INVITE and a corresponding re-INIVTE is triggered for this towards the SRS while a previous SRS SIP transaction is pending. 159 08192021 154751.374314:1.02.00.26912.MAJOR .SIPSG: sipsgRec.c (-5062) 529606794. [SipSgSendSRSMetadataUpdateCmd] SipSgSendSdpCmd Failed with status 491 Root Cause: The SBC always attempted to send another offer towards SRS even when a offer-answer was pending and this resulted in SRS session failure. Steps to Replicate: Use the following setup to reproduce the issue.
| The code is modified so that when a SIP Offer-Answer towards SRS is in progress, the SBC does not attempt to send another offer, and instead queues the latest event until the current offer-answer is complete. Workaround: None. |
74 | SBX-110572 | 1 | Details on "LAST RESTART REASON" under command "show table system serverStatus" are not updated correctly. Impact: LAST RESTART REASON is not updated with proper reason of last restart. Root Cause: Reading LAST TESTART REASON function is called twice, and it is set to default in the second call. Steps to Replicate:
| The code is modified to read the LAST RESTART REASON only once. Workaround: None. |
75 | SBX-109243 | 1 | The SBC sending 481 for CANCEL in dialog transparency. Impact: When the dialog transparency is enabled and call loops back to the SBC, the SBC does not handle a CANCEL sent from ingress endpoint. Root Cause: The SBC expects a CANCEL to have callinfo header. Steps to Replicate:
| The code is modified to ensure the SBC finds the correct SG to handle the CANCEL even when the CANCEL does not have callinfo. Workaround: None. |
76 | SBX-111050 | 1 | There was a coredump during a reboot on a customer SBC. Impact: A misconfiguration of GW Signaling Ports, in which there is a Secondary GW Signaling Port configured but no Primary GW Sig Port configured, and can lead to a core and switchover. Root Cause: When no Primary GW Signaling Port is configured but a Secondary Signaling Port is configured, the SBC attempts to dereference a NULL pointer (pointer to Primary Sig Port) while attempting to get the DSCP value to use for the socket. Steps to Replicate:
| The code is modified to prevent it from attempting to dereference a NULL pointer (pointer to Primary Sig Port) when it is looking up the dscp value to use for the socket. Workaround: The workaround is to avoid configuring a Secondary GW Signaling Port without configuring a Primary GW Signaling Port. |
77 | SBX-110884 | 1 | The logs are getting printed in openclovis. Impact: If condition present, SCM is filling openclovis logs with this error message: Root Cause: The error message is logged because the code is attempting to write a debug log into a local buffer that is not big enough. Steps to Replicate: This is no risk with/without fix. | The code is modified to increase the size of the local buffer. Workaround: There is no workaround. |
The following 08.02.06R000 Severity 2-4 issues were resolved in this release:
Resolved Issues
Issue ID | Sev | Problem Description | Resolution | |
---|---|---|---|---|
1 | SBX-98627 | 2 | The Min-SE header is getting added to ingress metaDataProfile even though it is not in the initial INVITE. Impact: For the SIPREC, Min-Se and Session-Expires headers are added to the metaDataProfile even though it is not received in the initial INVITE. Root Cause: When Incoming without support Timer, the SBC is incorrectly inserting a Min-Se and Session-Expires headers as part of an incoming INVITE. Steps to Replicate:
| The code is modified to reset the value of the Min-Se and Session-Expires when received. Workaround: SMM deletes the Metadata in the SIPREC INVITE. |
2 | SBX-103228 | SBX-115812 | 2 | PortFix SBX-103228: Excessive logging and fast log rolling observed even at MAJOR level Impact: When testing with Registration CAC enabled, this message is written aggressively per call, and contributes to high disk I/O and ENM processing. MAJOR .SIPFE: *SipFeEpCacUpdateHpcValues:1506 peer was not static returning. Root Cause: The message is written at the MAJOR level per call causing frequent log rolling. Steps to Replicate: Enable registration CAC and make a call. This message is logged for every call and is basically useless at the MAJOR level. | The code is modified so the log event is moved to the INFO level. Workaround: None. |
3 | SBX-115476 | SBX-115676 | 2 | PortFix SBX-115476: The SBC fails to send ACK in the re-INVITE callflow when E2E ACK and E2E re-INVITE flags are enabled. Impact: The E2eAck is not working after an INVITE with replace is sent. Root Cause: Currently, E2eAck configuration is applicable only on egress leg. After sending an INVITE with replace (ingress legC), the legC does not support e2eAck. Steps to Replicate:
| The code is modified so after sending a PSX query, if e2e re-INVITE is enabled, then turn on e2eAck flag as well. Workaround: None. |
4 | SBX-115243 | 3 | Automatic AD Sync was not completing properly. Impact: Automatic AD Sync was not completing properly. Root Cause: During the change from Daylight Saving Time in the fall, the addMinsToTime routine does return a time the is greater then the time passed in. Consequentially, the code loops calling addMinsToTime expecting the time returned by addMinsToTime to be greater than the current time. Steps to Replicate:
| The code is modified to return a time greater than the time passed when switching from Daylight Saving Time. Workaround: None. |
5 | SBX-113242 | SBX-113348 | 2 | Portfix SBX-113242: The SLB/SBC is not fetching the correct branch param from merged VIA header. Impact: Due to merge VIA headers, the SLB/SBC was not getting the correct instance id and response messages were not being routed to backend SBCs. Root Cause: If the SLB/SBC receives a VIA header as merge of two VIA headers, it was overwriting the first via branch param from the second VIA branch param, and due to this SLB was not getting the correct instance id. Steps to Replicate:
| The code is modified to set the SLB/SBC read only in the first branch param, that is what we need from top VIA and ignore the rest branch param. Workaround: None. |
6 | SBX-111731 | SBX-112803 | 2 | Portfix SBX-111731: A restart on the configuration for linux service in systemd unit file is wrong. Impact: The services intervalstats, trc-anonymization continues restarting on failure (if failure happens within 360 seconds). Root Cause: The restart configuration for the linux service in systemd unit file is wrong. Steps to Replicate: Stop the process services intervalstats, trc-anonymization five times and do not retried. | The code is modified to address the issue. Workaround: None. |
7 | SBX-102598 | SBX-111880 | 2 | PortFix SBX-102598: There were MFG Intermittent test failures. Impact: Xaui link is not always coming back up after enabling/disabling the internal loopback mode. Root Cause: Xaui link is not always coming back up after enabling/disabling the internal loopback mode. Steps to Replicate: Run the ESS test mode for days. | The code is modified to the enable/disable loopback code. Workaround: None. |
8 | SBX-110245 | SBX-111811 | 2 | PortFix SBX-110245: The AddressSanitizer: heap-use-after-free /sonus/p4/ws/jenkinsbuild/sbxAsan100/marlin/SIPSG/sipsgMsgProc.c:7097 in SipSgProcessNrmaUpdateNfy(SIPSG_CONTEXT_STR*, nrma_update_nfy_msg_str*) Impact: The ASAN detected "AddressSanitizer: heap-use-after-free" while accessing SG_CCB_STR pointer. Root Cause: The SBC was trying to access the SG_CCB_STR pointer that is already been freed. Steps to Replicate: Run a basic call where ICID value of P-Chargingector header in INVITE message is NULL or absent. | The code is modified to check the pointer is null or not before accessing it. Workaround: None. |
9 | SBX-109059 | SBX-111809 | 2 | PortFix SBX-109059: The SIPSG FAX multiple streams initiated fax call fails (muted T.38 and audio) Impact: The multi-stream fax call is failing with muted T38 and audio. Root Cause: There is a mismatch in the media streams of the SBC offer and the peer answer. Due to this, the images media stream received from UAS is mapped incorrectly to the audio stream in the SBC offer. This is happening when advertise audio only flag is enabled. Steps to Replicate:
| The code is modified so the SBC maps the media streams in offer and answer correctly when advertise audio only flag is enabled. Workaround: None. |
10 | SBX-110215 | SBX-111431 | 2 | Portfix SBX-110215: A coverity issue. Impact: Code fix for an SCM coredump (SBC-108237) when the Invite gets a transaction timeout and the 200 Ok for Invite is received at the same time needed some cleanup. Coverity issue: CID:338630 Root Cause: In the problem scenario, the SBC is trying to send ACK for the 200 OK, when the SCM cores while creating a SIP Transaction for ACK Message. Steps to Replicate:
A race condition might occur and result in coredump. | The code is modified not to send ACK in this scenario as the CseqType and CseNumber are unknown and 0 respectively. Workaround: None. |
11 | SBX-102925 | SBX-111421 | 2 | PortFix SBX-102925: There are issues in the Ova\QCow2 installation. Impact: Differing prompts and root passwords are created for the SBC SWe installed through the ISO, and the SBC SWe created through the image launch method, Root Cause: While installing through the image launch method, the SBC SWe was configured with the Cloud SBC method of creating the root password and prompt. Steps to Replicate:
Results from step 1 and 2 should be same. | The code is modified to ensure both image launch method and ISO install method of the SBC SWe has no root password and the same CLI prompt. Workaround: A user can manually remove root password on ISO installed SWEs using the command below: |
12 | SBX-104319 | SBX-111419 | 2 | PortFix SBX-104319: Conflicted design between two features “sdpRelayAttribute” and “Send RTCP Bandwidth Info”. Impact: The SBC sends duplicate b=RR and b=RS values when “sdpRelayAttribute” and “Send RTCP Bandwidth Info” are enabled together. Root Cause: The SBC was not honoring "sendRTCPBandwidthInfo" only when “sdpRelayAttribute” was enabled with TFT. Due to this, the duplicate of b=RR and b=RS was seen, when “sdpRelayAttribute” was enabled without TFT. Steps to Replicate: Configuration:
Procedure:
Also, the SBC should not add duplicate b=RR and b=RS parameters in the SDP honoring the configured bandwidth values in the PSP. | The code is modified so if “sdpRelayAttribute” is enabled separately without TFT, and "sendRTCPBandwidthInfo" is enabled, then the SBC does not honor "sendRTCPBandwidthInfo" and does not send a duplicate value of b=RR and b=RS. Workaround: None |
13 | SBX-70800 | SBX-111411 | 2 | PortFix SBX-70800: AWS: Observing that metaVariable table is getting modified on loading the backup config file of one instance in other instance. Impact: When loading the backup configuration from one SBC instance to another, the metavar table is getting populated with the list of metavars from both instances. This by itself does not cause any issues so long as the metavars are unique, its just confusing to see the metavars for another instance in the table. Root Cause: The code was not removing the existing metavars prior to loading the configuration of another instance. This meant the metavar table had both sets of information. Steps to Replicate:
| The code is modified to flush the metavars for the existing instance prior to loading the configuration from another instance. Workaround: None. |
14 | SBX-105050 | SBX-111407 | 2 | PortFix SBX-111407: The SBC DRBD mount was not visible on the active SBC. Impact: The SBC DRBD mount was not visible on the active SBC. Root Cause: When the sbxrestart is issued from platform manager, the DRBD gets mounted on apache's mountspace. Steps to Replicate:
| The code is modified to address the issue. Workaround: None. |
15 | SBX-106854 | SBX-110907 | 2 | PortFix SBX-106854: The ASAN runtime flatbuffer serialization unit test fails with asan=1. Impact: The ASAN build is failing due to automated test failures related to serialization. Root Cause: Automated unit test is failing because of uninitialized variables. Steps to Replicate: Create an ASAN build and it should be successful. | The code is modified to initialize the variables that were causing the Unit tests to fail. Workaround: None. |
16 | SBX-101758 | 2 | There was an issue regarding field Ingress Codec inside CDR for some calls with CLEARMODE. Impact: A SIPI Invite call fails when CLEARMODE as CODEC feature is enabled. Root Cause: The call failed as clearmode in PSP was becoming NULL. Steps to Replicate: CLEARMODE as CODEC enabled and PSP has CLEARMODE as entry.
| The code is modified so that when a CLEARMODE as CODEC enabled and SIPI with CLEARMODE is received, a call is processed and the CDR gets updated with CLEARMODE. Workaround: Not available. |
17 | SBX-114081 | 2 | The SecGetTlsProfileDataByName() selects a TLS profile other than the configured one. Impact: The SBC uses the wrong TLS profile. Root Cause: The 'lookup by name' function returned with the wrong profile. Steps to Replicate:
| The code is modified for both TLS and DTLS profile lookup by name routines to return the requested profile. Workaround: None. |
18 | SBX-101409 | SBX-106810 | 2 | PortFix SBX-101409: A T140 call - one-way stream - zero media port (NAPT media). Impact: The call ends up in one-way audio after the called party puts the call on hold and off hold twice. Root Cause: As a result of call-modify a couple of times, the RTCP NAPT learning completes before RTP NAPT learning. This results in RTCP Remote Address being updated, which has remote RTCP Port. Due to incorrect code in RTCP modify flow, remote RTCP port, gets assigned to RTP port. This results in one-way media. Steps to Replicate:
| Set the correct RTP Port as part of RTCP modify flow. Workaround: Since the issue is caused to RTCP NAPT learning completed before RTP during multiple hold/unhold scenario, a workaround could be:
|
19 | SBX-104253 | SBX-108315 | 2 | PortFix SBX-104253: The "Deleting the a=maxptime" SMM is not working after an SBC restart. Impact: SMM with sdpContent not getting applied after restart. Root Cause: At time of restart CPX trying to read SMM with sdpContent from the wrong path. Steps to Replicate:
| The code is modified to address the issue. Workaround: Delete the SMM rule and configure again. |
20 | SBX-105637 | SBX-105686 | 2 | PortFix SBX-105637: The AddressSanitizer: detected heap-buffer-overflow on address 0x61b000013128 at pc 0x55e3eea0419e bp 0x7ff7a52768a0 sp 0x7ff7a5276898 in ScmProcess_0. Impact: There was invalid memory access when the SBC receives the 500 Internal Error to REGISTER. Root Cause: The root cause of this issue is accessing invalid memory while accessing callData, trying to read off the data from the end of memory block. It can potentially cause the coredumps if the memory block is at the edge of the accessible memory region. Steps to Replicate: Testcase:
Procedure:
Expected Results:
| The code is modified to access the respective application data (It can be call data, registration data or subscription data) based on type of SIP message. Workaround: None. |
21 | SBX-105763 | SBX-110037 | 2 | PortFix SBX-105763: Move the dmesg monitoring from SM to a platform cron job Impact: Move dmesg monitoring from SM to a platform cronjob Root Cause: Since the dmseg can be large for long-running SBCs (thus, take longer to dump logs), the function can take longer causing an SM healthcheck. Steps to Replicate: Check for "/var/log/sonus/tmp/dmesgErrorMarker.tmp" after manually running the script | The code is modified to run every minute as a cron job to find i/o and filesystem errors in dmesg. If an error is found, the SBC creates a marker file in tmp, which is later used by other scripts to check sanity of the system. Workaround: None |
22 | SBX-107798 | SBX-111634 | 2 | PortFix SBX-107798: The one way audio when forked leg is MS Teams without ICE/NAT. Impact: For an incoming call that is forked to multiple destinations and DLRBT is enabled, there is a possibility of audio flowing only in one direction when the call gets established. Root Cause: When a 180 ringing is first received from one of the forked destinations, this triggering the SBC to play ringback tone, but if the call subsequently receives 18x messages and RTP media (for media cut through) from a different destination, the SBC fails to activate the RTP media flow resources correctly at the ingress leg of the call because these resources are already activated for playing the ringback tone for the other fork. Steps to Replicate: Set up
| The code is modified to re-activate the media resources after the call is answered on one of the forks and the remaining forks have been cleared. Workaround: Not available, but the issue does not occur if the DLRBT is not enabled. |
23 | SBX-107973 | SBX-110060 | 2 | Portfix SBX-107973: The SBC adding RR and RS attributes twice in the egress INVITE when multiple m lines present in SDP. Impact: The SBC was adding RR and RS attributes twice in the egress INVITE when multiple m lines present in a SDP. Root Cause: The SBC is not setting the default value of M lines present in SDP when number of lines is greater than 1 and as a result, the SIPS value is getting added. Steps to Replicate: Configure these: | The code is modified so that if value is set to default and it is not getting modified, the SIP does not send the RR and RS value twice. Workaround: When the sdpAttributesSelectiveRelay is enabled, the SBC does not send RR and Rs twice. |
24 | SBX-108029 | SBX-108313 | 2 | PortFix SBX-108029: The SIPSG_MSG_PARAM_SIPSG_REDUND_ACT_STR is not registered for serialization correctly before 10.0 release Impact: After LSWU, some of the event record fields are not serialized properly for the calls related to Register and OOD messages. Root Cause: Event record accounting details are not registered for Serialization. Steps to Replicate:
| The code is modified to address the issue. Workaround: None. |
25 | SBX-108572 | SBX-110035 | 2 | Portfix SBX-108572: [ASAN]: /localstore/ws/jenkinsbuild/sbxmainasan/marlin/SIPS/sipsParseActions.c:12698:76: runtime error: index 20 out of bounds for type 'sip_nameval_str [20]' Impact: When the PUBLISH message is received with 20 params in the Contact Header, the SBC throws a runtime error: index 20 out of bounds for type 'sip_nameval_str. Root Cause: The param check for boundary condition was missing while parsing the contact header. While it was checking the params, the number of params should be less than 20, but the condition to handle number of params is not specified. Steps to Replicate: Send a PUBLISH message with 20 or more params in the Contact header. | The code is modified so if the number of params is 20, the SBC should throw a parse error. Workaround: None. |
26 | SBX-108410 | SBX-109378 | 2 | PortFix SBX-108410: [ASAN]: sanitizer.CE_2N_Comp_ScmProcess_3.8866:==CE_2N_Comp_ScmProcess_3==8866==ERROR: AddressSanitizer: heap-use-after-free on address 0x6190001c77dd at pc 0x558bcc9ff877 bp 0x7fea305f4e00 sp 0x7fea305f45b0. Impact: The ASAN reported a "AddressSanitizer: heap-use-after-free" error when Subscribe request having a NULL character in quoted string. Root Cause: Invalid access of the freed memory occurred. Accessing memory after it is freed can cause unexpected behavior that may result in coredumps. Steps to Replicate: The codenomicon subscribe-notify suite. | The code is modified to now log a parser error. Workaround: None. |
27 | SBX-108616 | SBX-111574 | 2 | PortFix SBX-108616: Fora Late Media Call, the SBC is not sending a second UPDATE towards ingress when the DLRBT is enabled. Impact: In a late media convert call scenario, when the DLRBT is enabled, the SBC is not sending UPDATE towards the ingress with the list of codecs received from UAS. Root Cause: The minimizing of media changes from other call leg functionality is suppressing the triggering of the UPDATE towards UAC. Steps to Replicate:
| The code is modified to identify this particular call scenario, such that, the SBC sends an UPDATE towards the UAC if the tone codec is different from the end to end negotiated codec. Workaround: None. |
28 | SBX-108619 | SBX-110034 | 2 | Portfix SBX-108619: [ASAN]: /localstore/ws/jenkinsbuild/sbxmainasan/marlin/SIPS/sipsPreParse.c:1742:46: runtime error: signed integer overflow: 2002002002 * 10 cannot be represented in type 'int'. Impact: A runtime error is seen in the SAM process. When an INVITE is sent out and response code received is very large, we will see the following issue: Root Cause: When the SIP Response code is very large, there is a signed integer overflow during the processing of the SIP PDU. Steps to Replicate: An INVITE is sent out to the egress. If the response code received is very large, the issue is seen. | The code is modified so if the SIP response is greater than or equal to max response code, the SBC throws an error. Workaround: None. |
29 | SBX-109187 | SBX-109265 | 2 | PortFix SBX-109187: [ASAN]: sanitizer.CE_2N_Comp_ScmProcess_0.32472:/localstore/ws/jenkinsbuild/sbxmainasan/marlin/SIPS/sipsParseActions.c:16242:70: runtime error: null pointer passed as argument 2, which is declared to never be NULL. Impact: The NULL pointer was accessed during the codenomicon test with an ASAN SBC build. Root Cause: The Codec Attribute has been accessed in the SDP without a proper NULL check. Steps to Replicate:
| The code is modified to add the defensive NULL check. Workaround: Not applicable. |
30 | SBX-109412 | SBX-110911 | 2 | Portfix SBX-109412: The destination buffer was too small during the snprintf function. Impact: During the snprintf function call, the destination buffer was not big enough to copy the source string. Root Cause: The size of the destination buffer was smaller than the source buffer because the destination buffer length check was not present. The buffer file size should be 256 bytes. File: call/sonus/p4/ws/jenkinsbuild/sbxAsan100/marlin/SIPS/sipsParse.c Steps to Replicate:
| The code is modified to address the issue. Workaround: None. |
31 | SBX-114303 | 2 | Call to landline number was incorrectly listed as busy. Impact: The SBCs try to map the non-E164 display name of p-asserted-Identity TEL to generic address for called user. Root Cause: When the SBCs received both pai (tel) and pai (sip) headers, it attempts to treat as a Japan ttc even though the display name in pai(tel) is not E164 format. Steps to Replicate: Run the following command string to replicate the issue: config outgoing INVITE | Validate if the display name is E164 format, then try to map display name as generic address for called user to address the issue. Workaround: Use the SMM to delete incoming display name in pai(tel) header. For an outgoing message, add it back if pai is config transparency. |
32 | SBX-109443 | SBX-109676 | 2 | PortFix SBX-109443: ERROR: The AddressSanitizer: detected heap-use-after-free on address 0x61900412bbce at pc 0x55d0b8c48037 bp 0x7fb50a457b00 sp 0x7fb50a4572b0 READ of size 2 at 0x61900412bbce thread T11. Impact: The ASAN reported "AddressSanitizer: heap-use-after-free" error for subscribe message received with Proxy-Authorization header having auts parameter. Ex: Proxy-Authorization: Digest auts*="0x01P+20" Root Cause: An invalid access of the freed memory occurred in this case. Accessing memory after it is freed can cause unexpected behavior that may result in coredumps. Steps to Replicate: Send a SUBSCRIBE message received with Proxy-Authorization header having auts parameter. | The code is modified to address the issue. Workaround: None. |
33 | SBX-109862 | SBX-110926 | 2 | Portfix SBX-109862: The SBC is not rejecting the SRTP call when disallowSrtpStream is enabled. Impact: The SBC is not rejecting the SRTP call when disallowSrtpStream is enabled in ingress PSP and Invite is received with only SRTP stream. Root Cause: This is specific call flow when disallowSrtpStream is enabled and an INVITE is received with only SRTP stream. This scenario was not handled and the SBC was not rejecting call. Steps to Replicate:
| The code is modified so that when the disallowSrtpStream is enabled and an INVITE is received with only an SRTP stream, the call is rejected with 488. Workaround: None. |
34 | SBX-110291 | SBX-112567 | 2 | Portfix SBX-110291: AddressSanitizer: The ASAN detected a heap-buffer-overflow-SipSgIncomingCallNfy (unsigned int, sip_addr_str*, sip_msgbody_str*, sip_options_str*, unsigned int, unsigned int, bool) /sonus/p4/ws/jenkinsbuild/sbxAsan100/marlin/. Impact: The ASAN detected "AddressSanitizer: heap-buffer-overflow" while copying the contents of the SIP-I base version string internally. Root Cause: The SIP code was always copying a fixed amount of memory when reading the SIP-I base and version strings to internal memory. Steps to Replicate: Run a SIP-I call flow with INVITE and CANCEL messages. | The code is modified to copy exactly string length size of the SIP-I base and version content to avoid reading past the end of memory buffers as this can cause coredumps. Workaround: None |
35 | SBX-110640 | SBX-110917 | 2 | Portfix SBX-110640: The CDC config not replicated to standby during SWO when there are no active calls. Impact: In a PC2.0 setup with HA, when a switch over is performed without LI calls then the interception stops working on the new active. Root Cause: The standby SBC is not processing CDC config for realm2hash. Realm2hash is only created if SBC has active LI calls at the time of transition from Active to standby. In case when SBC don't have Active call realm2hash is not created on transition from Active to standby. Steps to Replicate:
| Standby code is updated to process CDC config and create realm on standby. Workaround: Disable/enable CDC Diameter Realm Route and Peer on the new-active. |
36 | SBX-110665 | SBX-114797 | 2 | PortFix SBX-110665: Internal IP peers blacklisted after switchover despite that OPTIONS ping worked fine. Impact: When the system experiences a Split Brain condition, the ipPeer(s) using a pathCheck may become BLACKLISTED and may not be RECOVERED. This can result in some ipPeer(s) becoming BLACKLISTED permanently. Root Cause: During a Split Brain, both CEs are running in ACTIVE state. In the error case, the PATHCHK sends BLACKLIST event(s) to the ARS on both systems (CEs). This can result in a PATHCHK and ARS being out-of-sync with respect to the ipPeer(s) BLACKLISTED/RECOVERED state. Steps to Replicate: This issue is very difficult to reproduce. We have only been able to reproduce the issue by performing “kill-stop 2” on a KVM based system, that has a number of ipPeer(s) with pathCheck profile state enabled. | The code is modified so that the PATHCHK sends events to the ARS only on the system (CE) that is being executed. The PATHCHK is prevented from sending events to ARS on the other system (CE). Workaround: If this issue occurs, the ipPeer(s) that are stuck on BLACKLISTED may be RECOVERED through the CLI by disabling the ipPeer(s) pathCheck state. |
37 | SBX-110755 | SBX-112792 | 2 | Portfix SBX-110755: The ACL rules configured with ipInterface are disabled on every SBC start/restart in SBC5400/10GB pkt configuration. Impact: The IPACL rules created with ipInterface defined are not getting installed on the SBC 5400 systems when there is no license present, or after a license is added. Root Cause: The NP will not install an IPACL rule with an ipInterface defined if that interface is not UP and active. The SBC will retry to install failed rules when it sees the port come up. In this scenario the timing is off, however, it tries too soon as the physical port is up but the associated ipInterface is not yet up. Steps to Replicate: The test involves a SBC 5400 without a license for its 10G packet port. The IPACL rules with ipInterface defined on that packet port will then fail to install. Once the license is successfully added, the IPACL rules should be installed. | The code is modified to add an additional delay before attempting to reinstall the failed IPACL rules when the port comes up and to look for an additional failure that starts a timer and try again. Workaround: Do not use IPACL rules with ipInterface defined. |
38 | SBX-111004 | SBX-111798 | 2 | PortFix SBX-111004: The SCM Process cores on the customer PSBCs PS40, PS41, and PS42. Impact: A SCM Process coredump was observed because of Segmentation fault when a call was intercepted with PCSILI and media monitoring enabled. Root Cause: The SCM Process dumped core while pushing request for splitter resources and media monitoring was enabled. Steps to Replicate:
| The code is modified to avoid the coredump. Workaround: None. |
39 | SBX-111177 | SBX-111872 | 2 | PortFix SBX-111177: The SBC incorrectly interprets RTCP packets as RTP when using DLRBT. Impact: The RBT (ring back tone) can be terminated early when the DLRBT (dynamic local ring back tone) is enabled and RTCP packets or comfort noise packets arrive with the B-party. Root Cause: When the DLRBT functionality was initiated it was not informed that RTCP could be received. This resulted in RTCP packets being treated as RTP and caused the SBC to think RTP was learned. Unexpected RTP comfort noise packets can also cause the SBC to think RTP was learned. As soon as SDP was received in 183, the SBC triggered cut through and the RBT was stopped even though the call was not answered. This left the A-party with silence until the call was answered. Steps to Replicate: Make a PSTN to MS Teams call with DLRBT enabled. Leave the call in ringing state with MS Teams for a long time and check that the ring tone is continually generated. | The code is modified to correctly identify RTCP packets and not use this as an indication to media being learned so that the ring tone continues to be played until real RTP packets arrive. The learning mechanism is also modified to look for five or more RTP packets within a five second period to establish that RTP is learned. This is to assure that occasional unexpected comfort noise packets are not used for learning. Workaround: If RTCP is not required on the egress leg then disable it. If RTCP is required there is no work around. |
40 | SBX-111277 | SBX-111820 | 2 | PortFix SBX-111277: The reason parameter was in the wrong History Info Index. Impact: Egress History-Info header's index is incorrect in a SIP to SIP Call, when an ingress call with Diversion mapping to egress leg with History Info. In the egress IPSP the flag diversionHistoryInfoInterworking = disable by default, and flag includeReasonHeader = enabled. Other flags as below: Root Cause: When the index of egress History-info header is generated in above condition, it's generated in a wrong way. Steps to Replicate:
| The code is modified to address the issue. Workaround: None, unless set diversionHistoryInfoInterworking = enable. |
41 | SBX-111349 | SBX-112882 | 2 | PortFix SBX-111349: An SBC 7000 dual crash within 1 minute (old Active side - Fm, new Active - Scm). Impact: The application on both active and standby switched over and the application reset in a short order of each other. Core files are created on both sides of the HA pair. Root Cause: The issue occured during multiparty call processing where the SBC tries to determine a whether message was sent for the ingress or egress call segment. The code was accessing the pointer to the multi party call resource after it was freed up and set to NULL. Steps to Replicate: This issue is not reproducible. Potentially due to a race condition in the code. | The code is modified so the multi party call pointer is not NULL before reading from it to avoid the coredump. Workaround: There is no known workaround for this issue. |
42 | SBX-111659 | SBX-112371 | 2 | PortFix SBX-111659: The intercept is not working when P-Com.Session-Info is received in INVITE and tones are enabled. Impact: When the lawful intercept target is specified in the P-com-session-info header of the INVITE message, the intercept does not occur if an announcement resource is applied to the call and then freed up. There is no issue if the P-com-session-info header is received in the backward direction. Root Cause: This occurs when using P-early-media with tone profile and media monitoring profile applied to the call flow and the B-party sends P-early-media with a=inactive to start the media monitoring and does not provide RTP or does not send 200 OK prior to the monitoring timer expiring which results in the SBC playing RBT via an announcement resource. When the media path is later cut through and the announcement resource is released the intercept information was mistakenly freed up and the intercept did not occur. Steps to Replicate:
| The code is modified to ensure the intercept information is not freed up when freeing the announcement resource. Workaround: None. |
43 | SBX-111740 | SBX-112569 | 2 | Portfix SBX-11174: The SBC takes 72 seconds to send BYE to transferor after call termination. Impact: The SBC is taking 72 seconds to send BYE to the transferor when the transferee disconnects before a transfer target accepts the call. Root Cause: One of the disconnect events towards transfer target is getting ignored in the call control state machine. As a result, a release timer of 70 seconds is getting triggered later and the SBC is sending BYE towards transferor. Steps to Replicate:
| The code is modified so that the SBC sends a disconnect immediately towards the transferor. Workaround: None. |
44 | SBX-111956 | SBX-113447 | 2 | PortFix SBX-111956: An early media case in SIPREC re-INVITE is not triggered with latest values for metaDataSource=fromLatest. Impact: Call modification events like codec change/hold/un-hold on the CS that occur before the RS Session is established is not propagated to the RS Call (SIPREC Session). Root Cause: The SBC does not attempts to trigger SIPREC re-INVITE with updated session characteristics when initial SIPREC INVITE transaction itself is pending with SRS and Main Call received a re-INVITE. Steps to Replicate: Run the following procedure to recreate the scenario:
| The code is modified to queue the SIPREC RE-INVITE event when an initial SIRPEC INVITE transaction is pending. When the initial SIPREC INVITE transaction is completed, the queued SIPREC RE-INVITE is sent towards the SRS (This contains the latest session characteristics). Workaround: None. |
45 | SBX-112060 | SBX-113201 | 2 | PortFix SBX-112060: STIR/SHAKEN services were failing in the second dip in 2-stage call (SIP-SIP). Impact: The SBC was not sending STIR/SHAKEN parameters, such as identity headers, to the PSX in the trigger request portion of a two-stage call or processing the STIR/SHAKEN parameters in the response. Root Cause: The SBC was missing code to handle the interaction between two-stage calls and STIR/SHAKEN logic. Steps to Replicate: Make a two-stage call where the INVITE contains identity headers and check they are sent to the PSX in both the policy request and trigger request. | The code is modified to send STIR/SHAKEN parameters such as identity headers to the PSX in the trigger request portion of a two-stage call and process the STIR/SHAKEN parameters in the response. Workaround: None. |
46 | SBX-112117 | SBX-113050 | 2 | PortFix SBX-112117: There is a Wall LRA I-SBC switchover after the applying ACLs. Impact: Configuring certain combination of ACLs may exceed the hugepage requirement than available in the system. This will cause the ACL configuration to fail and SWe_NP to exit. Root Cause: The code did not account for available hugepages during an ACL configuration. Steps to Replicate: Bring up setup in I-SBC profile. Apply the ACL configuration used by customer. | The code is modified to limit the hugepage memory use during an ACL build and ensure it is within the allocated limit. Workaround: Use more than 64G RAM. |
47 | SBX-112267 | SBX-113203 | 2 | PortFix SBX-112267: Correct the 92x serialization code for a registration control block. Impact: When the registration control block is made redundant and the active/standby instances are running different software releases e.g. during upgrade, the redundancy logic might not work correctly if the registration control block contains a P-Charging-Vector (PCV) and/or P-Charging-Function-Addresses (PCFA) information. The redundancy logic will work correctly post upgrade when serialization of the redundancy data is not required. Root Cause: The parameter lengths of the PCV and PCFA redundant parameters was not calculated correctly. This can lead to the redundancy code being unable to process all the redundancy information correctly. Steps to Replicate: Run registration related tests with PCV and PCFA header parameters in an older release and then upgrade to 922R2 or later. | The code is modified to correctly set the length of these parameters to avoid problems with redundancy. Workaround: None. |
48 | SBX-112429 | SBX-112816 | 2 | Portfix SBX-112429: The NrmGetCallCount was returning max global callcount, instead of the current stable calls. Impact: The I-SBC sends the total (cumulative) number of stable calls instead of current stable calls to the SLB in its utilization message. This could result in the SLB dropping messages if it thinks the I-SBC has reached 100% utilization. Root Cause: The I-SBC was providing the wrong number of stable calls to the SLB. Steps to Replicate:
| The code is modified to provide the current number of stable calls in the utilization message to the SLB. Workaround: None. |
49 | SBX-112487 | SBX-112490 | 2 | PortFix SBX-112487: The LI connection to media server was not connected on a switchover. Impact: When using the PCSILI (P-com-session-info flavor of LI) in an N:1 M-SBC setup and running the SBC release 8.2 or later if there is a switchover, the connection to the LI server might not be re-established. Root Cause: The standby instance was trying to maintain information about the operational status of the interface used for LI processing. But this was only happening correctly for the first instance. The status of the other instances was being misinterpreted and lost. So during the transition to active, the LI code thought the interface was not available and did not try to establish the connection to the LI server. Steps to Replicate: In an N:1 setup perform switchovers from each active instance to the standby and check that the connection to the LI server is restored. | The code is modified to collect the status of the interface after the instance transitions from standby to active so that the accurate interface information is available for LI processing. Workaround: Bounce the interface e.g. ifup/ifdown that is used for LI connection would help to recover the connection. |
50 | SBX-112493 | SBX-112684 | 2 | PortFix SBX-112493: The SBC is not decrypting the IPsec packet when a large PDU was sent over IPv6 from Strongswan. Impact: The SBC is not decrypting the IPsec packet when a large PDU was sent from Strongswan IPSec endpoint. Root Cause: The SBC SWe NP has a issue in last fragment data length processing w.r.t. This StrongSwan fragmented first and encrypted the next combination IPSec packets handling, which caused an ESP trailer offset being incorrect and resulted in call failures. Steps to Replicate: Make large SIP PDU calls with the StrongSwan IPSec endpoint. | The code is modified to work for all combinations. Workaround: Racoon/Navtel/SBC IPsec endpoints can be used if possible as a workaround. |
51 | SBX-112953 | SBX-113392 | 2 | PortFix SBX-112953: The SRTP license counter did not incremented when the called side omits an SIP 18x response. Impact: The license count for the SRTP license was not updated on a call from SRTP to RTP, if no 18x response message is received. Root Cause: The SRTP license usage is not updated at the ingress when response to an INVITE is only 200 OK message. Therefore, if the egress is not using a SRTP, the call does not consume a license. Steps to Replicate: Make an SIP-SIP call where the ingress leg uses SRTP and egress leg uses RTP. | The code is modified to correctly update the license count at ingress, even when no 18x is sent. Workaround: None. |
52 | SBX-113610 | SBX-114155 | 2 | PortFix SBX-113610: Deleting of an adProfile entry caused the PES Process to coredump. Impact: The PES Process dumps core when an AD profile entry is deleted. Root Cause: While synchronizing the data from remote domain controller, the PES fetches the AD profile once from the cache and uses the object for various decision making. So, if the ad profile is deleted, the object reference becomes NULL, and it dumps core. Steps to Replicate: To create an AD profile, create the dependent profiles.
After 1-2 minutes of creating the AD profile, delete it. | The code is modified to prevent deleting the AD profile. If you require, for some reason, to stop the synchronization, disable the sync option on the AD profile. Workaround: If the AD profile is not required, do not delete the AD Profile but disable the sync option on it. This will stop all the future auto sync operations. |
53 | SBX-113766 | SBX-113782 | 2 | portFix SBX-113766: The SCM process crash was observed when trying to show the ARS blocklisted entries. Impact: When too many peers are in ARS blocklisted table(more than 90 entries) and the "show status addressContext default zone <ZONE_NAME> sipArsStatus" command was issued, the SCM process crashed. Root Cause: The code was incorrectly indexing to a negative location in an array that led to an invalid memory access and a coredump. Steps to Replicate: Block list multiple peers and then run the status command. This was only seen once in lab testing. | The code is modified to avoid accessing the negative array location to avoid the coredump. Workaround: None. |
54 | SBX-113839 | SBX-114139 | 2 | PortFix SBX-113839: The customer setup is going for continuous reboot after upgrading (Stack Delete and Create) from 8.2.2R7 and 8.2.2R8 to 10.1. Impact: The SWe_NP process exits during DPDK ACL tries to build operation causing the SBC to go for reboots. Root Cause: postgres process is eating up significant number of huge pages from the quota allocated for SWe_NP. As a result, SWe_NP runs short of huge pages for DPDK ACL trie build operations and exits. Steps to Replicate: 1. Bring up a SBC instance with 10.1 release. | The code is modified to restrict the postgres process from consuming huge pages. Workaround: Increasing number of huge pages could be a possible work around. |
55 | SBX- 114395 | 2 | An OA fsm timeout after a call transfer with the e2eAck enabled (ACK not sent by the SBC). Impact: After a call transfer from legB to legC, the e2e re-INVITE and ACK is not working. Root Cause: LegC incorrectly disables the e2e ACK, while legA still enables the e2eACK. Steps to Replicate: This is specific to customer configurations.
| The code is modified to address the issue. Workaround: Disable the e2eAck. |
56 | SBX-101239 | SBX-110724 | 2 | PortFix SBX-101239: The congestion seen in a SBC with no traffic. Impact: The SBC 5400 reporting congestion even when no calls active. Root Cause: On the 5400 server, the EMA has allocated 4 CPUs for java and there are times when these can all run hot even when no calls on the system. The minimum number of hot CPUs to trigger congestion on the 5400 was set to 4 so it could report without any calls. Steps to Replicate: Enable SIP ladder diagram and CDR viewer on check for congestion reports on an idle system. | The code is modified to avoid congestion when no calls. This is similar to the other 5xxx models where the hot CPUs is one more than the number of java CPUs in EMA. Workaround: Disable SIP ladder diagram and CDR viewer services to reduce the java CPU usage. |
57 | SBX-113893 | 2 | The SBC returned a 500 Internal Server Error and many calls failed. Impact: Observed a memory leak when the ACK sending failed towards SIP recording server due to a DNS resolution failure. Root Cause: Once a 200 OK received from SIP Rec server for initial INVITE/re-INVITE, current design assumes that INVITE/re-INVITE transaction is success and it is designed to free call control block only on completing BYE transactions. But if ACK sending failed due to DNS resolution, then the SBC does not trigger BYE during call cleanup and in this case call control block is not getting freed, causing memory leak. Steps to Replicate:
| The code is modified to hold the call control block only when the SBC triggers BYE towards SIP Rec server and to clear call control bock when cleanup timer expires, in case BYE transaction fails to free call control block. Workaround: None. |
58 | SBX-112222 | 4 | The coreProcesses.py needs to collect the pmap. Impact: Starting with the 8.0 release, the Ribbon core dump analyzer also requires a pmap of a process when analyzing a core dump produced using the gdb gcore command. Root Cause: With the 8.0 release, the stretch version of the Debian release was used. With this release, the information needed by the core dump analyzer was no longer provided in the core dump created by gcore. Steps to Replicate:
| The code is modified to collect a pmap of the process as well as the core file Workaround: The core files must be loaded on an SBC running the release corresponding to the core file. |
59 | SBX-105367 | SBX-112546 | 2 | PortFix SBX-105367: During a sRTP and fax call, the sRTP context is removed for G711 fax pass-thru. Impact: The sRTP context is removed on the leg that has a G711 fax when there is a t38 to g711 fax call. Root Cause: The sRTP context is not updated for G711-fax. Steps to Replicate:
| The code is modified so the the SRTP context is updated only if the calleg has G711 fax. Workaround: None. |
60 | SBX-109006 | SBX-110820 | 2 | PortFix SBX-109006: The DSP DHC had a Failure and failed to coredump. Impact: The FPGA based DSP Health Check (DHC) fails and as a result, no DSP coredump is collected. Root Cause: The root cause for DHC failure is not known. However, subsequent coredumps failed due to a lack of reception of the DSP BOOTP packets, which is a hard failure. It is speculated that both issues are related. Steps to Replicate: Instrument the code to replicate the issue. | Reboot the node instead of running an application restart to address the issue. Note: This is not a fix for the original issue, but just a proposed workaround to prevent or reduce further failures. Workaround: None. |
61 | SBX-112905 | SBX-112915 | 2 | PortFix SBX-112905: The SBC was answering an on-hold call with sendrecv then re-inviting. Impact: When there is an invcoming INVITE on-hold, the SBC responds with 18x offhold and later a re-INVITE onhold. Root Cause: There was a logical error that converts from inactive to sendrecv when the first 18x is send out. This issue was introduced from a previous fix. Steps to Replicate:
| The original fixed of SBX-105961 should applied for subsequent 18x only. Workaround: Enable relay data path mode |
62 | SBX-112304 | 2 | The SBC discards incoming STUN packets after a second call hold - call switched from a DM call to a pass-through call when going on-hold. Impact: When running a call with ICE changes from direct media to running a call through a passthru due to 200 OK response, the ICE learning does not get enabled on the call. Root Cause: The code was not re-enabling the ICE learning when 200 OK caused a change from direct media to passthru. Steps to Replicate:
| The code is modified to re-enable the ICE learning when changing from direct media to passthru to allow receipt and processing of stun messages to complete ICE learning. Workaround: None. |
63 | SBX-101409 | SBX-106810 | 3 | PortFix SBX-101409: The T140 call on a one-way stream had zero media port (NAPT media). Impact: The call ends up in one-way audio after the called party puts the call on hold and off hold twice. Root Cause: As a result of running a call-modify multiple times, the RTCP NAPT learning completes before the RTP NAPT learning. This results in RTCP Remote Address being updated, which has remote RTCP Port. Due to incorrect code in RTCP modify flow, the remote RTCP port is assigned to RTP port. This results in one-way media. Steps to Replicate:
| The code is modified to set the correct RTP Port as part of RTCP modify flow. Workaround: Since the issue is caused to RTCP NAPT learning completed before RTP during multiple hold/Unhold scenario. Use the following workaround:
|
64 | SBX-112304 | 2 | The SBC discards incoming STUN packets after a second call hold and the call switched from a DM call to a passthru call when going on-hold. Impact: When a call with ICE changes from direct media to passthru due to 200 OK response, ICE learning does not get enabled on the call. Root Cause: The code was not re enabling the ICE learning when 200 OK caused a change from direct media to passthru. Steps to Replicate:
| The code is modified to re-enable the ICE learning when changing from direct media to passthru to allow receipt and processing of STUN messages to complete ICE learning, Workaround: None. |
65 | SBX-112547 | SBX-113032 | 2 | PortFix SBX-112547: The SBC routes call to 2nd DNS record if 503 is received after 18x. Impact: The SBC routes an INVITE to next DNS record if 503 is received after 18x. Also, even when the dnsCrankback flag is disabled, on getting 503/INVITE timeout case, the SBC reroutes an INVITE to next DNS record. Root Cause: Due to a design defect, the SBC tries the next DNS record even if an error response is received after an 18x. Also, retrying the next DNS record during a 503/timeout when dnsCrankback flag is disabled is legacy behavior. This behaviour is changed to retry the next DNS record only when the dnsCrankback flag is enabled. Steps to Replicate:
| The code is modified to not apply the DNS crankback procedure if an error response is received after a 18x. Additionally, the default behavior of handling timeout/503 when the dnsCrankback is disabled is updated as part of this fix. With this fix, the SBC retries for the next DNS record only when dnsCrankback is enabled to ensure the error responses match the reasons configured in the crankback profile. Workaround: None. |
66 | SBX-104733 | SBX-110293 | 2 | Portfix SBX-104733: SCM Process core dump during healthcheck. Impact: The SCM Process core dumped when too many set operations executed in a single commit. Root Cause: The Call Processing tasks takes longer than 10 seconds when subscribing to the changes made to SIP Trunk Group. Steps to Replicate: Configure 12 trunk groups. Modify 11 trunk groups with a single commit command and the CLI will deliver the following error message: | The code is modified per commit is changed to 10 from earlier value of 50. Workaround: Ribbon recommends performing a commit after every CLI transaction. |
67 | SBX-111751 | SBX-111898 | 2 | PortFix SBX-111751: The SCM Process is coredumping. Impact: The SBC is relaying multiple reason header instances in the amount of the quantity squared. Root Cause: Logical error when multiple instances of a reason header on the same line. The SBC is relaying in the amount of quantity squared. Steps to Replicate:
Note: If the ingress sends a large number of instances on the same line.
| The code is modified to address the issue. Workaround: Disable the transparency of a reason header. |
68 | SBX-104619 | SBX-109910 | 2 | PortFix SBX-104619: The FM process coredumped. Impact: The FM Process crashed and wrote coredump. Root Cause: The FM Process tried to read the /proc/meminfo file, which should always exist, but it got a file not found error. Steps to Replicate: It is not known how to reproduce this as this should never happen, so defensive code added to prevent null read/write. | The code is modified so when we cannot read the /proc/meminfo file, we return the last good value read instead of a NULL to prevent the crash. Workaround: None. |
69 | SBX-109177 | SBX-109283 | 2 | Portfix SBX-109177: The SbcSftp throws an error as "Failed to add ACL". Impact: The sbcsftp application does not remove the ACL created correctly. Root Cause: The permissions to delete the ACL gets lost while lowering permissions to ensure the sbcsftp can only access the current user's files. Steps to Replicate:
| The code is modified so that we can raise the permissions again once SFTP is complete. Workaround: None. |
70 | SBX-109013 | SBX-110865 | 2 | PortFix SBX-109013: Increased the healthcheck interval. Impact: Core dumps are occasionally seen in the field due to the health check timer expiring when the process gets stuck. Root Cause: In SWe environments, disk/CPU timing issues can lead to the process slowing down and hitting these health checks. Steps to Replicate: This issue was only reproduced using debug code. | The code is modified to be more forgiving to cope with short spikes. The health check ping interval is now 2 seconds and needs to have 15 consecutive non responses in order for the process to be declared deadlocked and a coredump initiated to recover. Workaround: None. |
71 | SBX-104866 | SBX-111272 | 2 | PortFix SBX-104866: ENM Process is leaking memory. Impact: The memory usage for the ENM Process increases when CDR file transfer failures are present. Root Cause: Under certain file transfer scenarios, the third party library libssh2 used by the ENM process leaks memory. Steps to Replicate: This problem was reproduced by creating a custom version of libssh2 that randomly dropped packets received from the remote sftp server. | The code is modified to keep track of the memory allocated by libssh2, and to free up any memory still in use after the file transfer session is closed. Workaround: N/A |
72 | SBX-111720 | SBX-111770 | 2 | PortFix SBX-111720: There was an SCM Process core in the SMM area. Impact: The SBC may coredump when using the SMM and regex to modify the fieldvalue of request-line. Root Cause: The SBC was accessing a corrupted pointer, which caused the issue. Steps to Replicate: Run a SMM using regex to modify fieldvalue of request-line. Note: This may not be reproducible due to the nature of the access pointer. | The code is modified to address the issue. Workaround: Change the fieldValue to headerValue. Or change the rule not to use regex. |
73 | SBX-108356 | SBX-110063 | 2 | PortFix SBX-108356: The SBC has various runtime errors found in np.log. Impact: Internal ASAN builds report runtime errors on SWe platform related to left shift of signed integers. Root Cause: Appropriate integer casts were missing in code, which caused ASAN runtime warnings related to bit shift. Steps to Replicate: Bring up ASAN build on SWe platform and observe if np.log contains ASAN runtime warnings related to bit shifts. | The code is modified to fix the runtime warnings in ASAN builds. Workaround: No workaround. |
74 | SBX-106197 | SBX-108302 | 2 | PortFix SBX-106197: The PKT port manualSwitch triggered twice. Impact: Executing port switchover command from CLI triggers port switchover twice. Root Cause: Link detection sub system on standby node subscribes to port switchover action command with CDB (Confd) twice:
Steps to Replicate:
| The code is modified to not subscribe for action command when the node is in standby mode and subscribe only upon switchover when it transitions from standby to active. Workaround: None. |
75 | SBX-106788 | SBX-110868 | 2 | PortFix SBX-106788: TOD Routing was broken for non-ALL timeRangeProfiles. Impact: Time of Day Routing is broken for any configured time range profile other than the default ALL profile. Root Cause: The time of the day values are stored in the DB as hexadecimal octets and A to F digits are stored as lower case. While matching the configured data, the stored values are compared against upper case A to F digits, thus the result of this match always failed. Steps to Replicate: Set timeRangeProfile other than ALL to test. | The code is modified to check for both lower case and upper case hexadecimal digits. Workaround: No workaround. |
76 | SBX-111310 | SBX-111555 | 2 | Portfix SBX-111310: Standby OAM is rebooting after orchestration. Impact: The Standby OAM is restarting after a launch. Root Cause: The Standby OAM is sending the serf event for 'startingStandby' with an older timestamp (which is fetched even before standby OAM is ready to come up) that results in discarding of the serf event by the active OAM node as its prior to member-join event for standby OAM node. Steps to Replicate: Bring up both the active and standby OAM at the same time and then while standby OAM is coming up, disconnect and connect the HA port on active OAM to trigger member-failed and member-join events. | While sending the 'startingStandby' serf event, get the current timestamp so that its not discarded by the active OAM node. Workaround: Restart the standby OAM application so that the startingStandby event is generated again with a current timestamp. |
77 | SBX-110179 | SBX-111425 | 2 | Portfix SBX-110179: The LeakSanitizer: detected memory leaks. Impact: A memory leak occurs when a logical management interface is added or modified. Root Cause: A confd cursor element was not closed when exiting the routine that validates the logical management interface being added or changed and this resulted in a memory leak. Steps to Replicate: Make changes to the logical management interfaces and check for memory increasing in the Cpx process. | The code is modified to ensure the associated memory is freed to avoid the leak. Workaround: None. |
78 | SBX-106543 | SBX-111420 | 2 | Portfix SBX-106543: The SBC experiences a core dump while running UAS Notify Request. Impact: The SBC coredumps while processing the UAS Notify Request within the XML body. Root Cause: In API SipsCheckForAnyBody(), the loop where the string pointer pch is incremented each time was being accessed before validating for an out of bounds condition that caused the crash. Steps to Replicate: Send a NOTIFY with XML body from UAC towards the SBC. | The code is modified to add a out of bounds check before accessing the pointer value. Workaround: None. |
79 | SBX-105900 | SBX-111428 | 2 | Portfix SBX-105900: Resize log volume on every boot. Impact: The log volume is not being resized on every boot. Root Cause: Currently, we build the filesystem on cinder volume only on the first boot. Steps to Replicate:
Check if the cinder volume is resized to 100 GB. | Check if file system is already built. If the file system is not built, resize the volume to address the issue. Workaround: None. |
80 | SBX-105160 | SBX-111406 | 2 | PortFix SBX-105160: There was a CHM process coredump on standby OAM after reboot. Impact: The SBC application continues to come up even when asp.py zap (zapAsp() call in sbxCleanup.sh) is invoked from sbxCleanup.sh script. When we try to access ceNum in one of the places, since it is not properly set due to failure in sbxCleanup.sh, it results in CHM coredump Root Cause: The SBC application continues to come up even when asp zap is called. Steps to Replicate: Fail sbxcleanup in one of the places and ensure the SBC in not being brought up. | The code is modified to avoid the SBC bring up if any errors are reported in sbxCleanup. Workaround: The issue is fixed, no workaround is required. |
81 | SBX-105856 | SBX-111401 | 2 | Portfix SBX-105856: The Wrong Version in URL after a Restore to an older version. Impact: The wrong version in URL after a Restore to an older version. Root Cause: URL is picked from CDB from path "/system/objectStoreParameters/url" that is independent of software version of revision. Steps to Replicate:
| The code is modified to update the URL with software version of revision being restored. Workaround: None. |
82 | SBX-109493 | SBX-111104 | 2 | PortFix SBX-109493: Forwarding info was redirecting info for a customer. Impact: When testing with JJ90.30 call flows and sending in the following parameters, the RDI (redirection information) parameter created from the history header information had the redirecting indicator field set to “call diverted, all redirection information presentation restricted” even though there was no privacy parameter information in the history header. Root Cause: The SBC interworking code was following the 3GPP 29.163 specification table 7.4.6.3.2.3 that allows the standard SIP privacy header information to be used when setting the RDI parameter information. Due to the setting RDI parameter information "id", it resulted in the redirecting indicator parameter value of “call diverted. All redirection information presentation restricted” instead of it being set to "call diverted". Steps to Replicate: Send an INVITE to the SBC, with parameters similar to those in the impact statement and check in the policy request that the RDI redirecting indicator field is set to "call diverted". The SIP trunk group variant needs to be set to TTC and the signaling acceptHistoryInfo control needs to be set to enabled. | The code is modified to not consider the SIP Privacy header value when determining the RDI parameter redirecting indicator field value if the SIP trunk group variant is set to TTC. Workaround: None. |
83 | SBX-109966 | SBX-110951 | 2 | Portfix SBX-109966: The SBC incorrectly accepts an SDP offer in an ACK Impact: The SBC is designed to ignore an SDP offer in an ACK, but is not doing so. Root Cause: In an early media call, the SIP stack was accepting the SDP in ACK as an offer. This should never happen. Steps to Replicate:
| The code is modified to not forward the SDP to the application. Workaround: None. |
84 | SBX-108058 | SBX-110928 | 2 | Portfix SBX-108058: The SBC CpxAppProc memory leak. Impact: During the SBC startup processing there is a small memory leak. Root Cause: During the startup processing, the SBC is allocating memory while reading configuration information and it is not being freed up correctly at the end of the provisioning steps. Steps to Replicate: This issue was only observed while running with ASAN images in the engineering lab as the amount of memory leaked is small and cannot be checked. | The code is modified to correctly free the memory allocated while processing the configuration data. Workaround: None. |
85 | SBX-109681 | SBX-110924 | 2 | Portfix SBX-109681: Low MOS score for UNENCRYPTED_SRTP calls Impact: In SRTP for unencrypted, Authenticated case, SRTP packets were being discard at NP due to authentication key mismatch. Root Cause: In SRTP for unencrypted, authenticated combinations key size is required in NP to derive the session authentication keys. Since the cipher key size was not being pass to NP, session authentication key was wrongly calculated. Steps to Replicate: On the receipt of an SDP offer with crypto attributes, if 'enable SRTP' is Configured in packet service profile, a common crypto suite is found in the crypto attribute received in the offer and in the packet service profile, and session parameters if included are allowed, the offer will be accepted. In the answer, the SBC includes the same tag used in the offer. Test Setup on the SBC:
Procedure: Endpoint1 sends an offer SDP with crypto attribute SRTP/SHA-1-80 and with Session Parameters UNENCRYPTED_SRTP | The code is modified so the SBC application is passing cipher key size also to NP to calculate session authentication keys. Workaround: Workaround is to not send unencrypted SRTP. Use cases with Encrypted SRTP and authentication no issue is seen. |
86 | SBX-108370 | SBX-110817 | 2 | Portfix SBX-108370: The top2 on the SBC core takes lot of CPU cycles. Impact: The SBC performance monitoring tools like top2 at times take 20% of a CPU core there by reducing total available CPU resources for management activities on SBC. Root Cause: Introduced nice values to sbxPerf commands but still top2 taking around 20-30% at times. As a result, need to check ways to optimize it to take less CPU using /root/.top2rc. Steps to Replicate: Install fix build and by using top command make sure CPU utilization of top2 should not be much CPU utilized. | The code is modified to take less CPU utilization of the SBC performance monitoring tools like top2. Workaround: None. |
87 | SBX-105890 | SBX-110767 | 2 | PortFix SBX-105890: On a disk failure, the correct failover is not triggered. Impact: On an SBC that was running 6.2 code, the disks on the SBC got into a bad state and would not process read or write operations. Automatic attempts to reboot the SBC from the application code failed and manual intervention was required to recover. Root Cause: Later software releases already had better handling for this sort of issue but the code was printing multiple logs as part of the automatic reboot process and it was suspected that these could have gotten hung and the system could not get to the reboot command. Steps to Replicate: The issue was not reproducible. | The code is modified to remove the logs to avoid the potential or not getting to actual reboot command in the code. Workaround: The SBC needs to be manually power cycled to recover. |
88 | SBX-111358 | SBX-111632 | 2 | PortFix SBX-111358: Customer ECGI to CA Mapping Enhancement. Impact: The SMM Switch operation is not working after an SBC reboot. Root Cause: The switchIndex is not being set properly during a config restore. Steps to Replicate:
| The code is modified to set correct the SwitchIndex during a config restore. Workaround: After a reboot, we can delete the SMM profile and configure again. |
89 | SBX-108369 | SBX-110866 | 2 | PortFix SBX-108369: The FIPS mode was broken on the AWS SBC. Impact: After enabling the FIPS mode on the AWS SBC or OpenStack, the SBC functions such as 'certificate import' do not work. Root Cause: While enabling FIPS mode, the FIPS flag is set in sbx.conf. But on Openstack/AWS deployments, the sbx.conf gets reset on the reboot causing a reset of the FIPS flag. Steps to Verify Fix:
The fipsMode in sbx.conf is set to 'enabled'. | The code is modified to retain FIPS flag in sbx.conf on reboot. Workaround: After enabling the FIPS mode, set fipsMode=enabled in /opt/sonus/conf/sbx.conf.reconfigHa.orig and reboot the SBC. After a reboot check, /opt/sonus/conf/sbx.conf |
90 | SBX-110948 | SBX-111396 | 2 | PortFix SBX-110948: Load configuration overwrites the local processor index values. Impact: When we perform a load config operation on a 1:1 HA pair (SWe/Cloud), it ends up overwriting the local processor index estimates with the ones that are present in the config dump.
Root Cause: The load config operation results in overriding the local processor index estimates with the ones that are present in the config dump. This results in standby consuming incorrect indices present in the DB thereby causing the discrepancy in estimates of the active and standby instances. Steps to Replicate: On 1:1 HA SWe/Cloud instances, perform the following steps:
| The code is modified to ensure that the DB reflects the estimated processor indices calculated by the active instance in 1:1 HA pair. Workaround: Run the following commands as root user on the active and standby instances. |
91 | SBX-111163 | SBX-111630 | 2 | PortFix SBX-111163: Export/import of the syslog configuration fails. Impact: The user-config-import command fails if the customer has configured the SBC to send the Linux level logs to a remote syslog server through the platformRsyslog configuration. Root Cause: The child configuration objects under the platformRsyslog configuration were not being applied in the correct order during the import, which led to the configuration validation logic thinking there was no syslog server configuration and failing. Steps to Replicate: Apply syslog configuration under the platformRsyslog and check that it can be exported and imported without errors. | The code is modified to correctly define the configuration order for platformRsyslog configuration so there are no errors during the import. Workaround: If you edit the syslogState line in the xml file and change it from enabled to disabled, the import will complete correctly. Then manually apply the CLI command to enable the syslogState once the rest of the configuration is imported. |
92 | SBX-109298 | SBX-109598 | 2 | PortFix SBX-109298: SBC: The DSP fails to modify ptime. Impact: When the SBC receives a re-INVITE with a change in the ptime for EVS, the DSP Modify command fails. Root Cause: Handling of DSP Modify Command for ptime change for EVS was not present. Steps to Replicate: Run a EVS to G711 call, send a re-invite on the EVS leg with change in ptime. The change in ptime should be put into effect through a DSP Modify. | The code is modified to support for ptime change for EVS is added. Allowable ptime changes include 20, 40, 60, 80 and 100ms. Workaround: None. |
93 | SBX-104537 | SBX-105655 | 2 | PortFix SBX-109298: Observed SIPFE MAJOR logs on the n1-standard-4 SBC_HA_HFE_SPLIT instance. Impact: The log was printed as major, when stale calls are present and whenever we start cleaning the stale calls, then the log is seen. Root Cause: This log is expected when clearing any stale calls. Steps to Replicate: Run call load and if any stale calls are seen, then this log issue is seen (only when the Minor logging is enabled). | The code is modified to address the issue. Workaround: None. |
94 | SBX-106589 | SBX-110494 | 2 | Portfix SBX-106589: The SBC SWe does not forward the SIP Info and drops the call. Impact: After receiving 32763 SIP indialog INFO messages, the SBC sends a 500 error for further INFO messages instead of forwarding the message. Root Cause: The SBC maintains the callHandle structure with refcount, which will be incremented for every reference and decremented once reference is released. But in this case, the refcount is not decremented properly, for every indialog msg (INFO) request received, the count kept increased. Steps to Replicate:
| The code is modified to address the issue. Workaround: No workaround. |
95 | SBX-109407 | SBX-110062 | 2 | PortFix SBX-109407: MicroFlows are failing in the REGISTER Performance of 2400 RPS (256000 REGISTRATIONS) with an error code 0xf9. Impact: Unable to support the 256k concurrent subscriber registrations in Default memory profile for the SBC SWe. Root Cause: Existing logic for determination of flow hash causes increased number of hash collisions leading to increased depth of hash buckets, leading buffer starvation. Steps to Replicate:
| The code is modified to minimize hash collisions. Workaround: There is no workaround for this. |
96 | SBX-105175 | SBX-108185 | 2 | PortFix SBX-105175: The SBC sends a re-INVITE while media is played on the ingress side in a GW-GW early media call. Impact: In a GW-GW call scenario, while the media is played on the ingress Gateway, the egress SBC is sending a re-INVITE to the UAS. Root Cause: Before the ingress GW completes its end to end activation, it received a MODIFY OFFER request from the egress GW due to the change in SDP received in 200 OK for lockdown INVITE. This caused the ingress GW to process modify offer first and then end to end activation later that triggered a re-INVITE towards UAS. Steps to Replicate:
| The code is modified so that while modify offer-answer is handled properly during end to end activation. Workaround: None. |
97 | SBX-108066 | SBX-108295 | 2 | PortFix SBX-108066: The /opt/sonus/sbx/bin/opensslSelftest cmd failed in the SBC 7000. Impact: When the FIPS mode is enabled on hwType SBC7000 (7k), services will fail to come up and the SBC becomes inaccessible. Root Cause: After enabling the FIPS mode when FIPS selfTests run, opensslSelfTests fails due to using a deprecated SSL engine on SBC 7000. Steps to Replicate:
| The code is modified to remove the deprecated SSL engine from opensslSelfTest and this allows FIPS mode to function as expected. Workaround: None. |
98 | SBX-105073 | SBX-110731 | 2 | PortFix SBX-105073: The *XrmAsyncCmdErrHdlr: ERROR NpMediaIntf cmd 2c gcid. Impact: The set grace command returned an error code 0xF0 from the NP, which triggered unsolicited call cleanups. Root Cause: The set grace command can only be performed on a disabled media flow in the NP. But, thet NP had received some set grace commands issued on an already enabled media flow. Unfortunately, we are unable to determine from just the core WHY XRM and NP became out of sync. Steps to Replicate: The issue is not reproducible. | The code is modified to set after XRM has sent media flow enable command to NP and is cleared on media flow disable. The XRM checks this flag and only send set grace commands to NP when this flag is clear. If the flag is set, the XRM reads the media control block in NP and log a MAJOR level debug message to help future debugging efforts. Similarly introduced a set of new flags in the BRES structure for RTCP Gen enable/disable commands sent to NP. The BRM checks the new flags and only enables RTCP Gen in NP when the flag is clear. If the flag is set, BRM reads the rtcpGen control block in NP and log a MAJOR level debug message to help future debugging efforts. Workaround: No workaround. |
99 | SBX-110719 | SBX-110867 | 2 | PortFix SBX-110719: HA setup on ASAN is not coming up after call config - pathcheck and SMM Impact: While testing with the following configuration the code could potentially read of the end of an internal memory block while printing a debug log. In the worst case scenario this could result in an SCM coredump. set addressContext default zone <zonename> sipTrunkGroup <trunk group> signaling messageManipulation smmProfileExecution fixedOrder Root Cause: The internal structure was not always getting initialized correctly prior to trying to print the contents and this led to the code reading pass the end of the memory block. Steps to Replicate: Configure SMM with the fixedOrder configuration and make some calls. This issue was highlighted while running with ASAN images in the engineering lab. | The code is modified to correctly initialise the internal structure and avoid reading past the end of a memory block. Workaround: Avoid using the "signaling messageManipulation smmProfileExecution fixedOrder" configuration if possible. |
100 | SBX-109167 | SBX-111422 | 2 | Portfix SBX-109167: The AddressSanitizer: SEGV on unknown address 0x000000000028. Impact: During the pre-parsing the Messagebody, the SEGV on an unknown address is observed in SipsPreParseMsgBody(). This could result in an SCM coredump. Root Cause: When the Content-Type is NULL the code was performing string comparisons to see if its an expected Content-Type and the code did not verify that the header pointer was not NULL before accessing it. Steps to Replicate:
| The code is modified to check the Content-Type string pointer is not NULL before accessing it. Workaround: None. |
101 | SBX-107975 | SBX-111418 | 2 | Portfix SBX-107975: A Serf event processor is unable to restart because restart check marker file is not getting removed. Impact: The Serf event processor is unable to restart because the restart check marker file is not getting removed. Root Cause: The restart check marker was only being removed if serfeventProcessor starts successfully, so if it fails to start, any attempts to restart it would be prevented because the marker is not removed. Steps to Replicate:
| The code is modified so that the user can attempt a restart. Workaround: None. |
102 | SBX-107960 | SBX-111412 | 2 | Portfix SBX-107960: The AWS IPs remain assigned to the standby SBC. Unnecessary dual restarts. Impact: If communication between active and standby is broken (over ha0 interface) both assume active roles (split brain). When this happens, the standby node that becomes active calls AWS APIs to move IP address to self. Once ha0 link is restored, the machine that becomes active does not call AWS API to move IP addresses, and this might cause issue when node that has IP does not come up as active. In this case, IPs are assigned on standby and another node becomes active. Root Cause: Root cause of this issue is not calling AWS switchover API (move IPs) during split brain recovery. Steps to Replicate: Perform a Split brain test and recovery of the SBC HA, and verify that API query is send by an Active SBC after recovery. | The code is modified to call AWS APIs to move IP to current active machine during split brain recovery path. Workaround: Manually move all secondary IPs to current active machine to restore calls. |
103 | SBX-109418 | SBX-111414 | 2 | Portfix SBX-109418: The LeakSanitizer detected memory leaks Direct leak of 883820 byte(s) in 413 object(s). Impact: The SBC was not freeing memory in one of the failure cases. Root Cause: The SBC was not freeing memory in few cases where incoming INVITE handling fails. Steps to Replicate:
| The code is modified to free up memory allocated, in all cases when the INVITE handling fails. Workaround: None. |
104 | SBX-106629 | SBX-111400 | 2 | PortFix SBX-106629: While expecting the 200 OK, the SBC is sending 503 Service Unavailable. Impact: In a late media convert call scenario with LRBT enabled, the SBC is sending 503 service unavailable when connect is received from egress EP. Root Cause: The SBC was trying to initiate an UPDATE without checking whether it has received SDP in the PRACK from the ingress Peer that is resulting in the call failure. Steps to Replicate: The LRBT is enabled on the ingress Trunk.
| The code is modified to check whether the SBC is received any SDP from the peer, so that, the call establishment occurs successfully. Workaround: None. |
105 | SBX-111059 | SBX-111061 | 2 | PortFix SBX-111059: Memory leaks are observing on ASAN build when SMM is configured Impact: While assigning SMM or flexible policy profiles to the zone configuration small amounts of memory leaked. Root Cause: The code was allocating memory in order to read information from CDB as part of processing the assignment and the memory did not get freed up at the end of processing. Steps to Replicate: Make SMM configuration changes at the zone level. | The code has been updated to correctly the free the memory. Workaround: None. |
106 | SBX-110178 | SBX-110920 | 2 | Portfix SBX-110178: The PRS Process gave heap use after free on address on latest 10.0 build. Impact: The PRS Process gave a "heap use after free on address" error while running the HA suite on ASAN build. Root Cause: Interface number was being returned after typecasting the main structure to packet LIF structure, and not management LIF structure. Steps to Replicate: Run SBX_504_HA suite on ASAN build. | The code is modified to correct the typecasting. Workaround: None. |
107 | SBX-109439 | SBX-110915 | 2 | Portfix SBX-109439: SBC: An activeRevision failure when state for even type audit is set to on/off. Impact: The configuration Playback on managed VMs fails on command. set oam eventLog filterAdmin vsbc1 audit audit level major state off Root Cause: The playback engine does not use user context. Steps to Replicate: Run the command on the OAM. set oam eventLog filterAdmin vsbc1 audit audit level major state off Perform a saveAndActivate. | The code is modified to address the issue. Workaround: Reboot on managed VMs to get the configuration at startup. |
108 | SBX-111162 | SBX-111342 | 2 | Portfix SBX-111162: The SBC fails to defragment/assemble fragmented IPSEC ESP packets received from the customer. Impact: The SBC drops an in-coming 1500B IP fragments sent through an IPsec tunnel, where the ESP packet is also fragmented into approximately equal-sized IP fragment packets. This complex IP frag-IPsec-IP frag problem primarily affects large SIP INVITE packets in certain network designs. Root Cause: This problem affects large packets sent through IPsec gateways that (1) do no reassemble received IP fragmented packets before sending them through the IPsec tunnel (IP fragments themselves are sent through the tunnel), and (2) fragment resulting ESP packets into approximately equal-sized packets instead of a 1500B and 72B fragments. Steps to Replicate: Test should send SIP packets → 1500B to SBC over an IPsec tunnel through a device/devices that:
| The code is modified to reassemble IP fragments up to 1580B divided any way into a single internal packet buffer, which the IPsec decryption code and subsequent IP frag reassembly code can handle. Workaround: Two workarounds are possible:
|
109 | SBX-111211 | SBX-111653 | 2 | PortFix SBX-111211: Get "violates foreign key constraint" error when assigning timeRangeProfile to a Route in EMA Impact: Route creation fails when the name of time range profile contains numerals. Root Cause: During the route creation, validation of time range profile was failing as it was containing numerals. Steps to Replicate:
| The code is modified to consider numerals as valid a character. Workaround: Create a Route from the CLI. |
110 | SBX-109453 | SBX-110623 | 2 | Portfix SBX-109453: The SBC is closing the socket for DNS query over TCP frequently. Impact: The SBC is closing the socket for DNS query over TCP frequently. Root Cause: Whenever the TCP connection is closed, the FIN packet is sent towards the SBC from DNS server. But the application was not closing the connection by sending the FIN and Even after a connection is closed by DNS server, the application is still holding socket information. This details were used in future queries has cause TCP connection to reset. Steps to Replicate:
Actual behavior: In step 3, the SBC will query DNS server to resolve NAPTR records over TCP connection. In step 4, the SBC will try to send a NAPTR query and then immediately close TCP connection. Expected result: The NAPTR query should be successful in step. | The code is modified to close TCP connection (Sending FIN to close connection). Also, the connection information in application is freed. Workaround: No workaround. |
111 | SBX-110746 | SBX-111636 | 2 | PortFix SBX-110746: The SIP ACK was missing in TRC, although the SBC sent one. Impact: The 200 OK for the INVITE received on the egress call leg contains a Record-Route header with an FQDN. The SBC resolves the Record-Route FQDN through the DNS and routes the ACK to the resolved target. The SIP ACK PDU that the SBC sent to the egress call leg is missing in the TRC log. Root Cause: The root cause is in SipsDnsLookupRspForTCB() when the DNS response comes back. Steps to Replicate:
| The code is modified so in the function SipsDnsLookupRspForTCB, SIP_CALL_STR* pstCall is fetched and use in SipsTXNDownstreamMsgToFsm. Workaround: None. |
112 | SBX-110362 | SBX-110364 | 2 | PortFix SBX-110362: The SBC generates RTP inactivity alarms when the policer mode is set to bypass. Impact: The SBC generates false RTP inactivity alarms when the policer mode is set to bypass. Root Cause: A bug in the media policing logic of SWe_NP code skips updating the timestamp of last RTP packet of a media flow, resulting in raising RTP inactivity notifications for every 10 seconds. Steps to Replicate:
| The code is modified to update the timestamp after every arrival of RTP packet for the media flow. Workaround: Ensure the policer mode is set values to other than 'bypass". |
113 | SBX-109424 | SBX-111409 | 2 | Portfix SBX-109424: The SBC sends a 420 Bad Extension response when an INVITE with both supported and require 100rel is sent. Impact: The SBC sends 420 Bad extension when Require:100Rel is received in initial Invite and e2e Prack flag is enabled Root Cause: Incorrect code was added to reject an INVITE with Require:100Rel when rel100Support flag is disabled and e2e prack flag is enabled. Steps to Replicate:
| The code is modified for rejection in the require:100rel scenarios. Workaround: Use SMM to remove Require:100Rel Header. |
114 | SBX-90156 | SBX-111808 | 2 | PortFix SBX-90156: Observed the Major logs "MAJOR .CHM: *send_notification: unknown variable name sonusAlarmNodeID". Impact: Major logs "MAJOR .CHM: *send_notification: unknown variable name" are seen on the sbxrestart. Root Cause: These type of logs are seen when the queued traps are flushed out but the corresponding MIBS are not loaded yet, as a result unknown variable names/faulty varbind logs are seen. Steps to Replicate:
| The code is modified from ConfdSnmpStartupDelay from 5 seconds to 15 seconds to introduce a buffer for the loading of the MIBS, after the Northbound interface is enabled. Workaround: Not applicable. |
115 | SBX-110201 | SBX-110302 | 2 | Portfix SBX-110201: A late offer call resulting in the SBC not sending DTMF for AMR-WB in initial offer towards ingress. Impact: The SBC is not sending 16k 2833 Payload type in the initial offer towards ingress during a Late media "convert" call. Root Cause: Answer received from egress contained both 8k and 16k 2833 Payload type and that resulted in the SBC incorrectly assigning the 8k PT value to 16k as well while generating offer towards ingress. As a result, the 16k PT get dropped by SIP stack. Steps to Replicate: Configuration:
The SBC drops the telephone-event/16000 payload type when generating offer towards ingress in 180. | The code is modified to prevent the same PT value getting assigned to both 8k and 16k DTMF in this call flow. Workaround: None. |
116 | SBX-108112 | SBX-109577 | 2 | PortFix SBX-108112: MS TEAMS - The Media Stats are not correct when the DLRBT profile is removed from TGs and ICE is enabled. Impact: On an SBC was configured for MS Teams LMO centralized mode with ICE, if DLRBT is not correctly configured, this can lead to media not flowing correctly for a call even after ice learning gets completed. Root Cause: The early ICE learning logic for non DLRBT mode in the SBC was not fully deactivating ICE media resources on receipt of 200 OK . As a result, the resources were unable to be re-activated for end to end media flow. Steps to Replicate: On an SBC configured as MS Teams LMO centralized mode with ICE on MS Teams TG:
| The code is modified to correctly deactivate early ice learning media resources on receiving an SDP from MS Teams. Workaround: The DLRBT should be enabled. |
117 | SBX-107999 | SBX-108299 | 2 | PortFix SBX-107999: The LeakSanitizer: CpxDnsCreate leaks observed during SBX-85432 E2E C-SBC automation run. Impact: There is a small memory leak in the Cpx process when DNS elements are added or deleted. Root Cause: As part of adding/deleting DNS entries the Cpx process reads in the interface group name from CDB and stores it in a local buffer but does not free it when finished processing. Steps to Replicate: Add DNS server entries. | The code is modified to correctly free up the local buffer at the end of the configuration logic. Workaround: None. |
118 | SBX-106759 | SBX-111416 | 2 | Portfix SBX-106759: In a N:1 mode, the SBC performs a switchover for a different node than the switchover request is honored for. Impact: In N:1 during few scenarios, SBC switchovers to node that was not request honored. When the issue occurred, a switchover will be processed to other node instead of processing to request honored node. Root Cause: During switchover process SBC was not checking the node which was requested honored. It was switching over to a node that comes first/is available while processing in the SBC. Steps to Replicate:
| The code is modified to check the service id of the request honored node before a switchover. Workaround: None. |
119 | SBX-105804 | SBX-110905 | 2 | PortFix SBX-105804: The CDR field is not populated even though the SBC writes the value to CDR field for '200 Ok of BYE' received/sent. Impact: After SMM manipulation, the SBC writes the value to CDR field as seen in the DBG but the CDR field ‘STOP’ record is empty. Root Cause: The logic to write the ACT file for the incoming 200 OK of Bye was absent. Steps to Replicate:
| The code is modified for updating the CDR field in the STOP record during the processing of response of BYE method. Workaround: Attach the SMM to BYE instead of the 200OK of BYE. |
120 | SBX-111609 | SBX-111810 | 2 | PortFix SBX-111609: The GCID value of '100 Trying" sent is logged with value '0xffffffff' in POST-SMM SMM L4 Trace. Impact: The POST-SMM Level 4 trace log for 100 Trying has GCID incorrectly set to 0xffffffff. Root Cause: Level 4 call trace is active with a configuration to match 100 Trying and a SMM rule is applied that modifies 100 Trying. Steps to Replicate:
| The code is modified so that the correct GCID value is printed in both PRE and POST-SMM traces. Workaround: None. |
121 | SBX-106613 | SBX-110298 | 2 | PortFix SBX-106613: The SBC adds duplicate header on new INVITE upon 422 response, when a transparency profile is attached to egress TG. Impact: The SBC adds a Duplicate Header on a new INVITE after the 422 Response is received. Root Cause: The SIP Stack adds a semi-known twice (Header is unknown to SIP Parser but configured in transparency Profile) in this 422 scenario. Steps to Replicate:
| The code is modified to Skip formatting the second instance of same header based on header type. Workaround: SMM can be added to remove the duplicate header. |
122 | SBX-112082 | SBX-112550 | 2 | Portfix SBX-112082: There was an runtime error: member access within null pointer of type 'struct CC_SG_ALERTING_UIND_MSG_STR in CcSgAlertHndl. Impact: Run a basic G711U pass-thru call. After the call got completed, ASAN runtime error is observed in the system logs indicating that the code is taking the address of a field within a null pointer. This could potentially lead to coredumps if using the SIP recording capabilities other than SIPREC. Root Cause: When a call Progress/Alerting message is received from the network, the code was taking the address of a field within the pointer. Steps to Replicate: Run a basic call. | The code is modified to validate that the pointer is not null taking the address of a field within the pointer. Workaround: None. |
123 | SBX-108434 | SBX-109171 | 2 | PortFix SBX-108434: SBC: A Standby OAM fails to come up after the restart of active and standby. Impact: After restarting the active and standby or after a fault that causes the SBCs to go down, the standby OAM waits for active to come up first and never recovers if active is down. Root Cause: On the Standby OAM startup sequence, there is a makeSureActiveIsUp() loop that exits only after active is up. This results in standby to be in a hung state forever if active is down. Steps to Replicate:
| The code is modified to reboot the instance that is starting as standby, if peer does not become active in 10 minutes. Workaround: Reboot the standby OAM SBC to fix the issue. |
124 | SBX-110984 | SBX-111143 | 2 | PortFix SBX-110984: The EVS CMR not honored when in dtx period. Impact: If the SBC receives a CMR request when it is operating in DTX mode, the CMR was not being processed. Root Cause: The rate or bandwidth change received through a CMR was not put into effect after coming out of the no transmission period. Steps to Replicate: Run an EVS<=>EVS call with dtx enabled. On the Ingress leg, send a valid CMR while there is no media being sent on the Egress Leg. Send a CMR on the ingress leg when it is in the "no transmission period" | The code is modified to address the issue. Workaround: None. |
125 | SBX-109304 | SBX-111288 | 2 | PortFix SBX-109304: The 13.2 wb cmr is not accepted when the SBC is operating in channel aware mode. Impact: The channel aware mode once enabled will always be enabled when the EVS encoder operates at 13.2Kbps and bandwidth WB. The only way to disable channel aware mode is to use a bitrate other than 13.2Kbps. Root Cause: The code to disable the channel aware mode if enabled on receiving on 13.2 WB CMR was absent. Steps to Replicate: Run a EVS to G711 call with br=13.2, ch-aw-recv-5; bw=wb. The call starts with 13.2 Kbps with Channel Aware mode being enabled. On receiving the CMR, the channel aware mode will be disabled while the bitrate is still 13.2. | The code is modified to address the issue. Workaround: None. |
126 | SBX-109300 | SBX-111290 | 2 | PortFix SBX-109300: The SBC should not accept cmr byte from discarded packets. Impact: The SBC was accepting the CMR from discarded packets. Root Cause: The CMR was being processed before Packet Validation. Steps to Replicate: Run and EVS<=>EVS call. Let the peer send 32Kbps packets having CMR for 24.4Kbps. In this case, the 32Kbps packets are discarded as we do not support transcoding beyond 24.4Kbps for EVS. Also since the packets are discarded CMR for 24,4Kbps is also not honored. | The code is modified to validate the packet first followed by the CMR processing. Workaround: None. |
127 | SBX-110956 | SBX-111292 | 2 | PortFix SBX-110956: Introduced the Upsampler for EVS in a EVS(wb)<=> NB codec scenario. Impact: The WB will not be used for EVS encoding and as a result, the channel aware mode cannot be enabled in an IDP NB scenario though negotiated through the SDP. Root Cause: There is an absence of an Upsampler in the Upstream path for EVS when WB is negotiated in an IDP NB scenario. Steps to Replicate: Run a EVS<=>G711 call with bw=wb; ch-aw-recv-5;br=5.9-13.2. In this case, the EVS encoder produces WB packets with channel aware mode enabled. | The code is modified for the EVS when the WB is negotiated in an IDP NB scenario. Workaround: None |
128 | SBX-111721 | SBX-111723 | 2 | PortFix SBX-111721: The EVS encoder picks up the initialCodecMode as the bitrate after switch to Compact Format. Impact: The EVS encoder picks up the initialCodecMode as the current bitrate if a change in packet format from Header Full to Compact is triggered. Root Cause: The root cause is the re-initialization of EVS encoder with bitrate as the initialCodecMode on change in packet format. Steps to Replicate:
Results: Prior to the fix, when switching to the Compact mode, the SBC would use 24.4Kbps (initialCodecMode) as the bitrate. | The code is modified to the re-initialize the EVS encoder with bitrate as the localCodecMode rather than the initialCodecMode. Workaround: None. |
129 | SBX-106520 | SBX-106880 | 2 | PortFix SBX-106520: Among the exported setting values, there were setting values that were not set in other environments. Impact: The "comment" parameter is missing from some configuration related to AAA rules/cmdRules. Root Cause: The "comment" parameter is not being restored during a LSWU. Steps to Replicate:
| The code is modified to restore "comment" parameter during a LSWU. Workaround: None. The "comment" parameter is used only for description. It does not have functional impact. |
130 | SBX-109209 | SBX-110495 | 2 | Portfix SBX-109209: SBC: Observed MAJOR logs for SIPFE "/localstore/ws/jenkinsbuild/sbxMain/marlin/SIPFE/sipFeSigPortCsv.c, SipFeGetSipSigPortStatisticsGetNextReqMsg, 1111] Another Query in process" on T140 load. Impact: Observed MAJOR logs for SIPFE "/localstore/ws/jenkinsbuild/sbxMain/marlin/SIPFE/sipFeSigPortCsv.c, SipFeGetSipSigPortStatisticsGetNextReqMsg, 1111] Another Query in process" on T140 load. Root Cause: The addressContext zone sipSigPortStatistics table is not supported on the SBC, so the code used to return the information was sometimes not returning, causing the error messages above. Steps to Replicate:
| The code is modified so SipFeGetSipSigPortStatistics routines return immediately. Workaround: Do not query that table. |
131 | SBX-108620 | SBX-111415 | 2 | PortFix SBX-108620: A runtime error: load of value 24752, which is not a valid value for type 'SIP_MSG_TYPE'. Impact: While processing an in dialog NOTIFY message, the check for message type was not done using proper data type. Root Cause: Message type check for NOTIFY message was not correct. Steps to Replicate:
| The code is modified to address the issue. Workaround: None. |
132 | SBX-108232 | SBX-110930 | 2 | Portfix SBX-108232: SBC: The AddressSanitizer: detected a heap-use-after-free on address 0x61800000a5a8 at pc 0x559e8989c4ac bp 0x7f4411fde290 sp 0x7f4411fde288 READ of size 8 at 0x61800000a5a8 thread T9. Impact: While the SBC node is shutting down it can access memory after its been freed, this could result in unexpected behaviour and in the worst case a coredump. But would have limited impact as it only happens when shutting down. Root Cause: During a sbxstop/sbxrestart or switchover because of race-condition, when the SBC is in deactivation the oamNodeRegisterRetry can access already deallocated resource leading to a core dump. Steps to Replicate:
| The code is modified to handle this race condition. Workaround: None. |
133 | SBX-108411 | SBX-111417 | 2 | PortFix SBX-108411: [ASAN]: sanitizer.CE_2N_Comp_ScmProcess_2.30828:==CE_2N_Comp_ScmProcess_2==30828==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61b00008dc88 at pc 0x5621c53c6946 bp 0x7f9854100bc0 sp 0x7f9854100bb8. Impact: While running a INVITE CANCEL Proxy Call, the UAS observed a Address Sanitizer leak in SCM process and the SBC services stopped. Root Cause: Issue in parsing string when string is blank and very large that lead to a heap buffer overflow. When the token length becomes large 100 say (which is the LWS length) and this token length point outside the PDU, we will see this issue. Steps to Replicate: Send an INVITE with a VIA header as the last header. | The code is modified to use temptokLen instead of the tokLen. As a result, the tokLen does not reach outside the PDU. Workaround: The VIA header should not be last header, and the empty token string should be small. |
134 | SBX-111270 | SBX-111777 | 2 | PortFix SBX-111270: The CDR record for DSP insertion/rejection reason field in 9.2.2R000 test execution has marked the call as “Transcoding” instead of “Transcoding due to DTMF”. Impact: The CDR DSP insertion reason is showing as trancoded instead of the DTMF for transcoded call with difference in DTMF parameters on the ingress and egress leg. Root Cause: The wrong code is present and overwrites the DSP insertion reason as transcoded. Steps to Replicate: Make a successful transcoded call with AMR codec on both sides and the | The code is modified to set the DSP insertion reason based on the answered call leg. Workaround: None. |
135 | SBX-110439 | SBX-111281 | 2 | PortFix SBX-110439: The DSP rejects CMR requesting channel-aware if localCodecMode is set to a value other than 13.2. Impact: The SBC was rejecting a Channel Aware Mode CMR when the current mode of operation of EVS encoder was not 13.2Kbps WB. Root Cause: A conditional check of the current Bandwidth and current Bitrate to honor a Channel Aware Mode CMR. Steps to Replicate: Run a EVS to AMRWB call with the following SDP: | The code is modified to check if 13.2Kbps is a part of the activeCodecSet and whether WB is present in the bandwidth range negotiated to honor a Channel Aware Mode CMR. Workaround: None. |
136 | SBX-109221 | SBX-110041 | 2 | PortFix SBX-109221: The dpf_core.c "runtime error: shift exponent 432 is too large for 64-bit type 'long long unsigned int'" in np.log. Impact: In the ASAN build, a runtime warning is observed in SWe_NP while running AMR-EVS audio call and insert T140 to both the streams through a RE-INVITE. Root Cause: Incorrect use of bitmask operation to extract dscp field from packet. Steps to Replicate: In an ASAN build, make a AMR-EVS audio call and insert T140 to both the streams through a RE-INVITE. AMR+T140-> EVS+T140. Observe ASAN warning in the np.log. | The code is modified to address the issue. Workaround: None. |
137 | SBX-110299 | SBX-111279 | 2 | PortFix SBX-110299: The SBC does not active EVS partial redundancy mode during the call when the remote offers "ch-aw-recv=0" Impact: When the ch-aw-recv=0 is negotiated through the SDP, a CMR request for the Channel Aware mode with offset 2 and the priority HIGH was not being processed. Root Cause: The root cause of this issue was a wrong initialization of the channel aware mode offset and priority in the code. Steps to Replicate:
Prior to the fix the CMR is not processed. With the fix, the CMR is processed and also honored. | The code is modified to address the issue. Workaround: None. |
138 | SBX-107396 | 2 | PortFix SBX-107396: Error "SYS ERR - Error 0x3b Line 666" was being printed frequently. Impact: SYS ERR repeatedly logged in SYS logs. Root Cause: The SYS ERR seems to only occur for audio encoding type 0x3b, which is SPEEX_8. But we do not have enough information to determine the call flow that triggered it. Steps to Replicate: The steps cannot be reproduced. | The code is modified to replace the SYS ERR with a major level debug message with the GCID and audio encoding type to help future debugging. Workaround: None. |
139 | SBX-105587 | 2 | The IPSEC Tunnel down after running an SBC Upgrade to 8.2.2R1. Impact: After the upgrade is completed, during IPSec SA rekey, the IPSec SA was not getting established. Root Cause: After an upgrade, when IPSec SA gets rekeyed the newly created SA is not getting configured into Kernel and hence IPSec SA creation timeout happens. Steps to Replicate:
| The code is modified so that the new IPSec SA created during rekey after upgrade is configured into Kernel and the IPSec SA is established without any issues. Workaround: Perform an SBC switchover to help clear the problem. |
140 | SBX-109811 | 2 | The SBC uses port number RTP+1 for RTCP instead of the learned RTCP port number if the RTCP NAT learning completes before RTP NAT learning. Impact: The SBC sends the RTCP packets to a destination port number RTP+1 for the RTCP instead of the learned RTCP port number if the RTCP NAT learning completes before RTP NAT learning. Root Cause: The SBC overwrites the learned RTCP port number with the RTP+1 port number if the RTCP is learned before RTP. Steps to Replicate: Send RTCP packets first then RTP packets to the SBC. After call is connected, verify the RTCP port number, if RTCP is learned before RTP. | The code is modified to use correct RTCP learned port when RTCP learning occurs before RTP, instead of comparing the RTP and RTCP addresses from callLeg structure. Workaround: No workaround. |
141 | SBX-109103 | 2 | PortFix SBX-109103: There was an incorrect UDP port used in the Record-Route and Contact on the core side. Impact: The SBC populates an invalid port in the Contact/Record-Route header towards the IMS Core side in call progress (180/200) responses. Root Cause: The signaling engine in the SBC, during a call, progress command modifies the ports without validating the direction of message flow and causes the SBC to populate an invalid port in the SIP responses. Steps to Replicate:
| The code is modified to identify the direction before changing ports, change only when the flow is towards the UE. Workaround: Use the SMM to change the ports in Contact and Record-Route headers. |
142 | SBX-110009 | 2 | The values in callsEstimate.txt differ between the Active and Standby SWe. Impact: The session capacity estimate values differ in active and standby VMs upon an LSWU upgrade of 1:1 the SWe HA pair. Root Cause: The following sequence of events resulted in the issue:
As a result, the Active and Standby VMs obtained different session estimates upon upgrade. Steps to Replicate: After subjecting the 1:1 SWe HA to LSWU upgrade, content of the following file in Active and Standby VMs would differ: | The code is modified to retain the processor indices during the LSWU procedure. Workaround: After completing the LSWU upgrade, once the active (VM-A) and standby(VM-B) VMs are in sync, following a set of operations would make sure that session capacity estimates are identical in Active (VM-A) and Standby(VM-B) VMs:
|
143 | SBX-110985 | 2 | If the VM name in the upper right corner of the "Configuration Manager" EMA/EMS SBC Manager is clicked, the browser freezes. Impact: If the VM name in the upper right corner of the "Configuration Manager" EMA/EMS SBC Manager is clicked, the browser freezes. Root Cause: The issue occurred because the peer setup was unreachable and to get the peer system info, the curl command that is executed was taking default timeout to get a connection timeout. Steps to Replicate:
| The code is modified to address the issue. Workaround: Refresh the UI page. |
144 | SBX-109968 | 2 | The 822R0 SCM Process core dumped. Impact: The SCMProcess core dumped on a SWe. Root Cause: Active SCM sent a Redundancy message to Standby SCM with a Registration index that was outside of its MAX range. The error handling code caught this and attempted to clean up the Registration Control Block but had a problem because the Control Block had not yet been initialized. Steps to Replicate: This problem is not reproducible. It is most likely triggered by a race condition which results in the Active and Standby to have different numbers for max number of Registrations (on a SWe the max number of Registrations comes from the file callEstimates.txt and in this case, the files on the active and standby do not match). This appears to be a SWe specific issue (the callEstimates.txt file is only used in SWE setups). | The code is modified to initialize the Registration Control Block immediately after allocating it, before any validation checks, so that the error handling code can clean up the RCB without causing a core. Workaround: There is no known workaround. |
145 | SBX-110490 | 2 | The IMS preconditions are failing due to UPDATE message race condition. Impact: An UPDATE from the calling party is queued by the SBC because the SBC is waiting for 200 OK for the previous update sent to called party, and when the 200 OK is received, the SBC did not forward the queued Update. Root Cause: Precondition parameters received as part of UPDATE from ingress endpoint is not updated in the egress CCB. Steps to Replicate:
Verify that the SBC sends the queued update, once it receives the 200 ok for the 1st update. | The code is modified so the precondition level of support was set to transparent on both legs in configuration. When the SBC receives precondition parameters as part of an UPDATE and preconditions are transparent, then the SBC saves the precondition parameters into the egress CCB. When the queued update message is being processed there is check for preconditions flag and comparison of precondition variables is done to send the update to called party. Workaround: Enable the "Disable media lockdown" flag in IPSP for egress leg so that the SBC does not send the first update. |
146 | SBX-112151 | 3 | There was an SCM memory growth on Standby. Impact: The standby SIPSG is leaking memory that was allocated on the Standby for storing the Transit IOI value that was configured in the SIP Trunk Group. Root Cause: The standby SIPSG is leaking memory that was allocated on the Standby for storing the Transit IOI value that was configured in the SIP Trunk Group. A pointer to this memory is linked off the the call block. This memory should be freed whenever the call block is freed - but this was not happening. Steps to Replicate:
| The code is modified to free this buffer. Workaround: This leak can be avoided by removing configuration of Transit IOI in SIP Trunk Group. |
147 | SBX-110592 | 3 | There was a misleading TRC message when issuing the callTrace action command start command. Impact: The misleading TRC message when issuing a "callTrace action command start command". Root Cause: There was no alarm/log message indicating a global call trace start action command. Steps to Replicate: Issue the callTrace action command and observe the Trace log. | The code is modified to display correct message indicating call trace being reset. Workaround: None. |
The following 08.02.05R000 Severity 1 issues are resolved in this release:
Resolved Issues
Issue ID | Sev | Problem Description | Resolution | |
---|---|---|---|---|
1 | SBX-104526 | SBX-105586 | 1 | PortFix SBX-104526: The emssftp fails in 9.1R1 Impact: In a EMS registered Cloud 1:1 SBC, the emssftp login was failing that blocks the EMS from carrying out various services on the SBC. Root Cause: In 1:1 SBC, the code logic of getting emssftp credentials from EMS had some gaps that caused issues with storing and keeping passwords in sync between active and the standby SBC. Steps to Replicate: After checking a login, after multiple reboots, rebuild with 1:1 and N: 1, along with 1-2 EMS registered. | The code is modified to get and store the emssftp passwords on both nodes of HA. Workaround: None. |
2 | SBX-104334 | SBX-106055 | 1 | PortFix SBX-104334: The call dropped when being placed on hold - IPv6. Impact: The "anonymous.invalid" in IPv6 media is not considered as hold and rejected. Root Cause: There is no handling for "anonymous.invalid" while handling hold. Steps to Replicate:
| Check for the "anonymous.invalid" and if the present consider it as call hold and avoid going for DNS resolution. Workaround: Use SMM to modify "anonymous.invalid" to "::" on the incoming side. |
3 | SBX-101451 | SBX-105555 | 1 | PortFix SBX-101451: The DSP Threshold setting is not generating Trap on the SBC 5400. Impact: The g711PacketThreshold, g729Threshold, and g726Threshold onset and abate traps are not sent. Root Cause: The NRM did not receive CLI updates to g711PacketThreshold, g729Threshold, and g726Threshold, and trap generation code used wrong trap names. Steps to Replicate: Provision threshold levels: | The code is modified to support g711PacketThreshold, g729Threshold, and g726Threshold. Deprecated the support for allThreshold, as it was never implemented in the SBC. Workaround: None. |
4 | SBX-106732 | SBX-108105 | 1 | PortFix SBX-106732: The CE_Node1.log getting filled up quickly Impact: The CE_Node1.log got filled fast. Root Cause: These prints where coming from stack trace dumps on SYS_ERR ( EVLOG ). Steps to Replicate: Run a suite of REFER call scenarios and see that NrmaCpcCallVerifyTimerFunc is not coming in CE_Node log. | Converted SYS_ERR( EVLOG ) for concerned logs to NrmaDlog to address the issue. Workaround: Run the echo > CE_Node.log when it grows too big. |
5 | SBX-108516 | SBX-109096 | 1 | PortFix SBX-108516: The Call Outage was leading to DSP errors. Impact: The call fails due to the RID Enable errors. The DBG log shows multiple BrmAsnycnCmdErrHdlr logs with cmd 0x30 (RID Enable): Root Cause:
Steps to Replicate: Test with calls that use RTCP terminations and will set the rtcp-xr-relay-drop to TRUE. |
Workaround: Disable the RTCP and RTCP termination in PSP. |
6 | SBX-104935 | SBX-105665 | 1 | PortFix SBX-104935: The Neighbor Advertisement at a high rate - >80 per second. Impact: A port switchover process that was initiated due to a port failure that was not complete due to system call (ioctl()) timeout. This leaves the application (LVM) and NP in inconsistent state w.r.t port roles. Root Cause: Based on the perf stats, it was observed that there were some process scheduling issues that resulted in Kernel timing out on MAC address update ioctl() call. Steps to Replicate: As this issue is related to delay in process scheduling, there is no easy way to reproduce the issue. | The code is modified to handle the ioctl() returning timeout error. In case of other errors, the code is modified to restart application as that leaves the application in the inconsistent state with NP. The code is also modified to send GARPs 3 times instead of sending it once during port switchover. Workaround: Reboot the instance. |
7 | SBX-105687 | SBX-106175 | 1 | PortFix SBX-105687: The SBC 5400 post upgrade to 9.1 SMM rule for options stopped working. Impact: The SMM rules were not applied for PATHCHK OPTONS after upgrade to 9.1 Root Cause: The SBC fixed a bug to pick default trunk group for PATHCHECK OPTIONS method and its response. Due to this, the SMM applied on a user defined trunk group will not be used for PATHCHECK OPTIONS. Steps to Replicate:
| The code is modified to apply SMM at global level. So the PATHCHECK OPTIONS can use SMM attached at the global level. Workaround: No workaround. |
8 | SBX-106722 | SBX-107232 | 1 | PortFix SBX-106722: The S-SBC application goes down with a MESSAGE call load of 11 cps or more. Impact: The SCM coredumps while running a load of MESSAGE method and having Dialog scope variable in the SMM at the ingress. Root Cause: The SBC is storing ingress dialog scope variable in the Relay CB that is already freed. Steps to Replicate:
| Delaying Relay CB free until we send 200 OK for MESSAGE method Workaround: Remove dialog scope variable in the SMM Rules at the ingress side |
9 | SBX-108557 | SBX-109024 | 1 | PortFix SBX-108557: The SBC continuously core dumps for SCM process since upgrading to V09.02.01R000. Impact: The SCM has cored due to memory corruption. Root Cause: There is code that is using an invalid buffer pointer when writing to a buffer. This code was added in 9.2.1R0 and was ported to other branches. (This problem is most likely triggered by the receipt of an invalid PDU and/or an SMM rule.) Steps to Replicate: This problem is most likely triggered by the receipt of an invalid PDU and/or an SMM rule to reject the incoming Invite. And it is random, therefore the issue may not reproduce all the time. | The code is modified to address the issue. Workaround: If there is SMM rule (ignore the Invite), then the SMM rule need to disable. |
10 | SBX-107972 | SBX-108395 | 1 | PortFix SBX-107972: SBC: Multiple PRS Process coredumps on the pn both active and standby while running a 2 day EVS + T140 -> AMR-WB and T140 load. Impact: The PRS Process coredumps during 2-3 nights load scenario. Root Cause: The BRM had validity checks missing for npPoolID before accessing the memory. Steps to Replicate: Setup:
| The code is modified to address the issue. Workaround: None. |
11 | SBX-107853 | SBX-108055 | 1 | PortFix SBX-107853: The SCM core was observed on a standby SBC wile running load with an SBC generated subscribe Impact: There was an SCM core on Standby while running the load for Reg-Event subscription. Root Cause: There is a leak on the Standby for SIP dialog data structure, which is causing a SYS_ERROR on standby. Steps to Replicate:
| The code is modified to fix the leak of SIP dialog structure on the standby SBC. Workaround: No workaround. |
12 | SBX-105764 | SBX-107910 | 1 | PortFix SBX-105764: A core dump resulted for a TEAMS call flow. Impact: There was a random crash observed during TEAMs call flow. Root Cause: There was a Null Pointer exception that lead to SCM Process crash. Steps to Replicate: Call scenario:
| The code is modified to prevent a crash. Workaround: None. |
13 | SBX-106920 | SBX-107732 | 1 | PortFix SBX-106920: The SBC: FmMasterProcess coredumps after a switchover with a stable call. Impact: The FmMasterProcess core dumps during a shutdown. Root Cause: The FmMasterProcess may deadlock during shutdown due to receiving an event while trying to shutdown/finalize the event handling. Steps to Replicate: This is time sensitive and requires an event being published from AMF to FM at just the right time in the shutdown sequence. There is no way to reproduce the issue. | The code is modified to avoid the possibility of the deadlock. Workaround: No workaround. |
14 | SBX-106951 | SBX-106954 | 1 | PortFix SBX-106951: Update the Sudo in the SBC OS to fix CVE-2021-3156: Heap-Based Buffer Overflow in Sudo (Baron Samedit). Impact: Update the Sudo in SBC OS to fix CVE-2021-3156: Heap-Based Buffer Overflow in Sudo. Root Cause: The 8.2.x SBC versions prior to 8.2.5R0 have CVE-2021-3156 Heap-Based Buffer Overflow in Sudo. Steps to Replicate: Run the following configuration: # dpkg -l sudo | The code is modified by applying OS Patch drift for SBC Version 8.2.5R0 that contains a fixed sudo version of 1.8.19p1-2.1+deb9u3. Workaround: No workaround. |
15 | SBX-107586 | SBX-107907 | 1 | PortFix SBX-107586: The SAM Process coredumps while executing a DoS on the SWe SIP signaling port with malformed Register Message with 80 multiple unique and spoofed IP's. Impact: The SAM Process coredumps while processing a malformed REGISTER message. Root Cause: The SIPSG is sending an Update to SIPFE for deleting the RCB details with Username, Hostname and PhoneContext as 0 when the Register is received with malformed PDU. Steps to Replicate: Send a REGISTER message only with the Request-URI and no headers. | The code is modified to delete the RCB when the Username, Hostname or PhoneContext is NULL. Workaround: Run in normal mode instead of sensitive mode for coredump. |
16 | SBX-105263 | SBX-105551 | 1 | PortFix SBX-105263: Observed the PRS Process coredump, followed by "DsPr, Ssre, Cpx" on both active and standby boxes of Openstack S-SBC HA pair and "Ccsp" process core on T-SBC active while running calls on 2CPS with ASAN build. Impact: There was a memory leak detected by ASAN in an active S-SBC while running G711 to G729 transcoding load on the D-SBC. Root Cause: ASAN reported a memory leak related to some pointers used to hold remote DSP resource. Steps to Replicate: Re-run the same load in ASAN and ensure no memory leaks are detected. | The code is modified to free these pointers. Workaround: None. |
17 | SBX-106968 | 1 | Abnormal switchover on the cluster SBC occured. Impact: The PRS process cored due to accessing a NULL destination ICM handle provided by the DRM. Root Cause: DRM does not mirror txIcm handle in DRES data structure to standby, and the code was not validating the pointer in one specific code path. The code intentionally crashed to identify the faulty code. Steps to Replicate: The problem is not reproducible, and the solution was found based on a code review. This is an edge case timing issue where an internal message is sent before a switchover, and the response is processed after the switchover. | The code is modified to validate the tcIcm pointer is not NULL before trying to use it and as a result, avoid the intentional system error crash. Workaround: No workaround. |
18 | SBX-106852 | 1 | There was a switchover and coredump for a customer configuration. Impact: The SCM Process may core while setting the DTMF relay on the call leg's active packet profile configuration. Root Cause: There are cases when an active packet profile can be NULL before it sets the DTMF output, which can cause a SCM crash. Steps to Replicate: Run a coredump analysis and code review. | The code is modified to check for activeProfilePtr before outputting the DTMF. Workaround: None. |
19 | SBX-106476 | 1 | The ipAdaptiveTaransparencyProfile is not working for a re-INVITE coming from Egress. Impact: When the sipAdaptiveTransparencyProfile is configured for the Egress TG and a re-INVITE comes from egress peer with a change in P-ASSERTED-ID, the SBC does not relay the invite from egress to ingress. Root Cause: The SBC code does not set a service bit for re-INVITE transparency for re-INVITEs coming from the egress peer. Steps to Replicate: Test case 1:
| The code is modified to ensure the SBC sets the service bit properly when the sipAdaptiveTransparencyProfile is configured for egress TG. Workaround: None. |
20 | SBX-108081 | 1 | Unable to see video from Cisco 8865/9971 on the ConnectMe BYOD client. Impact: The SBC drops RTCP packets for video stream if audio stream is transcoded by the SBC for a multi-stream call. Root Cause: The Non-RTCP binding resource was incorrectly picked by the SBC for video stream if the audio is transcoded in a multi-stream call. The reason for picking this resource is, natively the SBC did not support audio transcode for a multi-stream call. Therefore, the code assumed the audio to be in pass-through mode. Steps to Replicate: Configuration:
Without a Fix: With a Fix: | The code is modified to pick an RTCP binding resource for video stream irrespective of audio being pass-through or transcoded. Workaround: Disable the allowAudioTranscodeForMultiStreamCall flag at Route PSP, which would result in an audio pass-through call. |
21 | SBX-104522 | 1 | The DM/PM rules are ignored by ERE. Impact: When launching the ENUM SIP AOR query, the ERE is losing the ability to run DM rules configured on the egress TG to the called number. Root Cause: It is not a bug. It is a restriction in design. A DM on called and translated numbers were restricted if the ENUM service occurred. Steps to Replicate:
Watch the policy response to see if the called number is expected. | The code is modified so the new flag "ALLOW DBRULE CALLED EGRESS" in ENUM Service Allows customer can bypass that restriction. Workaround: None, if the DM rule on egress TG applied when ENUM service is used. |
22 | SBX-108080 | 1 | The SBC not adding ICE information when the same SDP content in multiple 18x messages is received Impact: When an egress endpoint sends multiple 18x messages with the same SDP followed by a 200 OK, in certain configurations this causes the SBC to send a RE-INVITE to the ingress endpoint after the 200 OK. However, when ICE is configured on the SBC ingress trunk group, this re-INVITE does not include the expected ICE parameters. Root Cause: The code that processes the SDP to send in the re-INVITE for this particular scenario is not correctly adding the ICE parameters. Steps to Replicate: Test 1:
1. Send a valid INVITE to teams TG with ICE parameters. 2. Responds from PSTN side with valid 183 progress message with SDP. 3. Send another 183 progress message from the PSTN side with the same SDP. 4. Send the 200 Ok from PSTN side with same SDP. 5. Verify that the SBC does not send a further re-INVITE to teams side.
| The code is modified to either not send the RE-INVITE when there is no change to the SDP or to add the required ICE parameters if a re-INVITE is necessary. Workaround: Certain scenarios cause this issue, for example if the acceptAlertInfo is enabled on egress ipSignalingProfile or ifthe downstream forking is enabled. If such configurations are not necessary and can be disabled, the issue can be avoided. |
23 | SBX-106858 | 1 | The customer SBC clears a call when receiving a 200OK answer - CFNA call. Impact: The SBC clears a call upon receiving an answer for a MRF transcoded call involving a egress UPDATE followed by tone play. Root Cause: During a tone play, the SBC detaches the MRF resource from the call since the tone is played by the SBC. However, the media endpoint resource facing the MRF stays with the call that results in a failure later while assigning MRF resource back to the call when answering. Steps to Replicate: The following events lead to the failure in this call flow:
| Detach the media endpoint resource facing MRF from the call during tone play to address the issue. Workaround: None. |
24 | SBX-108194 | 1 | There was no audio on media hairpin/loopback calls Impact: The media loopback call is programed with srcMac = dstMac in NP. When packet port switched over, LVM notified XRM for MAC address update. Then, the loopback call's srcMac got updated, but the dstMac is still set to old MAC address that causes an no audio issue after a port switchover. Root Cause: The root problem was that in XRM process MAC address update notify routine. The XRM only updated new MAC address in xres->nif->locMacAddr. Steps to Replicate: Please test on both SWe and SBC7k platforms:
| The code is modified to first update all the routes using the old MAC address with new MAC address received from LVM, and then update NIF's locMacAddr. Workaround: Avoid the use altMediaIpAddress by either deleting those from the LIF if possible, or by configuring the sipTrunkGroup->media->mediaIpAddress with the same media IP address for the trunk groups that could utilize media loopback. |
25 | SBX-108310 | 1 | There are various link monitor issues on the SBC SWEs with port redundancy enabled. Impact: On VMware platform with Intel 82599 SR-IOV packet port VFs, link does not get restored upon toggling the underlying physical link. Root Cause: Because of VMware PF driver quirks, the DPDK ixgbevf PMD code does not get link up indication from link speed status register for SR-IOV VFs from Intel 82599 card. Steps to Replicate:
| The code is modified to detect the physical link loss from the NACK status set on the hardware mailbox register, specifically for VMware platform. Workaround: No workaround. Only reboot clears the link state. |
26 | SBX-106611 | 1 | The SBC send bye message within dialog sometimes. Impact: After call is connected, if the SBC triggers internal re-INVITE due to minimizeRelayingOfMediaChangesFromOtherCallLegAll flag on one leg and at the same time, if SBC receives late media re-INVITE on other leg, the SBC clears the call. Root Cause: Internal offer answer state of call at SBC SIP subsystem becomes invalid. Steps to Replicate: Configuration: | The code is modified to ensure if the SBC is handling internal re-INVITE on egress leg, the late media re-INVITE on ingress leg responds with a 491 Request Pending with RetryAfter header. After the egress re-INVITE transaction is completed, if the ingress peer sends another late media re-INVITE, it is sent to egress leg correctly and offer answer transaction succeeds for this second re-INVITE. Workaround: Suppress the internal re-INVITE on egress leg. |
27 | SBX-98433 | SBX-99181 | 1 | PortFix SBX-98433: Observed a basic swithcover is not working with the customer SBC in ASAN build. Impact: There was a memory issue reported by ASAN. Root Cause: The LIF structure was not reset to NULL after the memory was freed. Steps to Replicate:
Expected: The switchover should be successful. | The code is modified to set LIF to NULL, after the memory is freed. Workaround: None. |
28 | SBX-106063 | SBX-106066 | 1 | PortFix SBX-106063: Cranckback not working for a non-INVITE for SIP in core. Impact: For SIP in core, the Cranckback was not working for a non-Invite. Root Cause: For non-INVITE requests, there was a check for the Last Tried IP where the SBC compares the next route IP with last route's IP. In the SIP in core, the route IP is always of SBC2, and as result, this next route was never tried. Steps to Replicate:
| The code is modified to not compare the route IP's and as a result, the SBC tries the next route after a Cranckback. Workaround: NA |
The following 08.02.05R000 Severity 2-4 issues were resolved in this release:
Resolved Issues
Issue ID | Sev | Problem Description | Resolution | |
---|---|---|---|---|
1 | SBX-98358 | SBX-108223 | 2 | Portfix changes are made for SBX-98358 to 8.2.x. Impact: An alarm was raised for "OS account gets temporarily locked for user cnxipmadmin after too many failed login attempts." Root Cause: The 'cnxipmadmin' is an internal user that does not get locked on multiple login attempts. In our script, which detects failed OS login, we are not considering the same and raising alarms for 'cnxipmadmin' on failed login. Steps to Replicate: Try login multiple times with 'cnxipmadmin' as user and wrong password. | The code is modified to ignore failed login attempt in case of 'cnxipmadmin' user. Workaround: N/A |
2 | SBX-95126 | SBX-95887 | 2 | PortFix SBX-95126: The SCM Process coredumps after PRACK. Impact: The SCM coredumps when performing a double free of Dialog Scope Variable Data. Root Cause: Double freeing of the Dialog scope variable data is occurring when both the SipAdapter profile and Flexible Adapter profile is configured on same TG. Steps to Replicate: WARNING: Replicating this issue will produce a core.
Expected results: A core will occur. | Modified the code to add a check to ensure the Flexible Adapter Profile does not include dialog scope variable data. Workaround: Do not enable Advanced SMM on the Flexible Adapter Profile |
3 | SBX-108469 | SBX-109086 | 2 | PortFix SBX-108469: There was a registration issue with a switchover case. Impact: The security mechanism of registration is set to TLS in the RCB with two different scenarios. The scenarios are of basic registration, which does not have any security profile. Root Cause: The root cause is when the reconstruction of the RCB occurs during switchover by default, security is set to TLS without verifying the Digest structure. Also whenever Digest structure is deleted for any reason, the code is not setting security back to NONE. Steps to Replicate: Test requires a HA setup.
| The code is modified so when the reconstruction of the RCB occurs, it verifies the Digest structure whether it is set security to TLS or NONE based on the DigestWithoutTLS variable. Whenever the Digest structure is deleted for any reason, the code sets the security back to NONE. Workaround: Try performing a switchover twice. |
4 | SBX-91127 | SBX-105549 | 2 | PortFix SBX-91127: The ASAN found a leak in CpxAaaGetNextEntry. Impact: While processing requests to display user information/status, the CPX process was leaking memory. Root Cause: While processing requests to display user information/status, the CPX process had to allocate internal memory blocks to collect information from the CDB and was not freeing up this memory at the end of the request. Steps to Replicate: From the CLI, run commands to request user information e.g. | The code is modified to free up the memory at the end of the processing request. Workaround: None. |
5 | SBX-106200 | SBX-106264 | 2 | The DSP had a coredump, and the system was unstable. Impact: Some Fax T.38 IAD calls (T.38 protocols version 3) resulted in a DSP crash and reloaded and calls are not successful. Root Cause: This condition is caused because this specific V3 IAD is sending CM messages with incrementing UDPTL seq numbers. Typically, the repeated messages carry the same UDPTL seq number to indicate that they are redundant. Packets with unique seq numbers are assumed to be independent and data from these is causing an unchecked buffer overflow in 3rd party T.38 stack code. Steps to Replicate: The main cause of the crash was based on the core inspection seems to be multiple CM messages with incrementing UDPTL seq numbers Rx by stack. | The code is modified to check to see if there is enough space available in tx_bits[] array to avoid overflow and avoid a crash in case of multiple CMs with incremental sequence numbers. Workaround: Use the Version 0 for T.38 calls. |
6 | SBX-91592 | SBX-105564 | 2 | PortFix SBX-91592: The DRBD tuning is not optimal. Impact: On non-cloud 1:1 SBCs, due to non-optimal tuning of the DRBD, the DRBD connection between active was getting disconnected leading to full sync and high i/o on drbd partition. Root Cause: Due to peer not responding within a certain time (ko-count * timeout), ko-count feature of DRBD was disconnecting the peer leading to full sync. Steps to Replicate: Following are the steps to test the changes: | Disabled the DRBD ko-count feature to address the issue. Workaround: None. |
7 | SBX-92066 | SBX-104720 | 2 | PortFix SBX-92066: Observed the PRS Process core dumps "systemerror healthcheck timeout". Impact: A PRS Process coredump was found due to healthcheck timeout upon executing a CLI debug command. Root Cause: The CLI debug command was taking a long time due to too many ACL entries resulting in a health check timeout. Steps to Replicate:
NOTE: The debug commands are not available on customer sites. | Limited the debug command to process only 200 ACL entries to allow CLI to recover sooner. Workaround: As we do not run debug commands on customer sites, this error should NOT occur. |
8 | SBX-107613 | SBX-108467 | 2 | PortFix SBX-1.07613: The AMRWB encoder produces a corrupted output when channel is reused by lower mode Impact: Degraded audio in AMRWB stream when AMRWB (GPU) call load is running, particularly when each call uses different bitrate. Root Cause: Problem occurs when the same codec context is reused and the previous used was for higher bitrate, the root cause was identified due to reinitialization logic for an internal buffer. Steps to Replicate:
| The code is modified to reinitialize the internal buffer. Workaround: Problem does not occur when all channels use the same bitrate. |
9 | SBX-107593 | SBX-107594 | 2 | PortFix SBX-107593: There is DTLS support for version 1.2. Impact: The SBC did not support DTLS clients which only supported DTLS version 1.2 to connect. Root Cause: The SBC was hardcoded to only support DTLS version 1.0 Steps to Replicate: Make a call from the DTLS client that only supports DTLS version 1.2 and check that the SBC is able to establish the call. | The code is modified to allow support for up to DTLS version 1.2. Workaround: None. |
10 | SBX-107978 | SBX-108304 | 2 | PortFix SBX-107978: There are Coverity issue in SIPSG. Impact: There was a coverity issue for NULL check. Accessing null pointer can lead to coredump. Root Cause: The NULL pointer dereferences while handling Session refresh. Steps to Replicate: Run a call where re-INVITE does not contain SDP | The NULL check is added before accessing the pointer Workaround: No workaround. |
11 | SBX-105674 | SBX-105891 | 2 | PortFix SBX-105674: There are Customer coverity issues. Impact: While processing SUBSCRIBE messages the coverity tool has highlighted that the code could dereference a pointer that is potentially null. Although, no bad behaviour is observed during testing there is a small chance that it could result in coredumps if the pointer really was null. Root Cause: Based on other validation in the code coverity highlighted that some legs of code could result in accessing a pointer that might be NULL. Derefencing null pointers can cause unexpected behaviour and in the worst case coredumps. Steps to Replicate: Run various SUBSCRIBE related test cases. | The code is modified to validate that the pointer is not NULL before using it to avoid any potential issues/coredumps. Workaround: None |
12 | SBX-104671 | SBX-105550 | 2 | PortFix SBX-104671: The SBC: CpxAppProc leak for SBC call Impact: During SBC startup the Cpx process has a small memory leak. Root Cause: During the SBC startup processing the Cpx process reads various CDB configuration and performs DB schema upgrade validation logic. As part of this processing it was creating temporary internal memory blocks but not releasing them at the end of initialization. Steps to Replicate: Restart the SBC after it is configured. | The code is modified to correctly release the temporary memory blocks used for initialization processing. Workaround: None. |
13 | SBX-105496 | SBX-105538 | 2 | PortFix SBX-105496: Fixing the NRMA coverity issue CID:11149. Impact: Coverity scanning tool identified a potential code leg where a null pointer could be dereferenced which could potentially result in a coredump although not observed in internal testing. Root Cause: While trying to allocate resources for PCMU to PCMA call where the ingress leg is being tapped and there is a possibility the code could access an invalid pointer resulting in unexpected behaviour and potentially coredumps. Steps to Replicate: This part of the code could be triggered for PCMU to PCMA call where the ingress leg is being tapped. | The code is modified to verify the pointer is not NULL before trying to use it to avoid potential coredumps. Workaround: None. |
14 | SBX-105679 | SBX-105682 | 2 | PortFix SBX-105679: The ASAN leaksanitizer errors in CPX and SCM Impact: SCM and CPX processes have a small memory leak while changing IPSEC and IP interface group configuration Root Cause: While processing configuration related commands, the SBC was reading information from CDB into temporary memory blocks, but failed to release the memory at the end of the configuration action. This resulted in a small memory leak. Steps to Replicate: Make configuration changes to IPSEC and IP interface group. | The code is modified to ensure the memory is correctly freed up to avoid the leak. Workaround: None. |
15 | SBX-105542 | SBX-105546 | 2 | PortFix SBX-105542: Fix the customer coverity issues. Impact: While processing SUBSCRIBE messages the coverity tool has highlighted that the code could dereference a pointer that is potentially NULL. Although no bad behaviour is observed during testing there is a small chance that it could result in coredumps if the pointer really was null. Root Cause: Based on other validation in the code, coverity highlighted that some legs of code could result in accessing a pointer that might be null. Derefencing null pointers can cause unexpected behaviour and in the worst case, coredumps. Steps to Replicate: Run various SUBSCRIBE related test cases. | The code is modified to validate that the pointer is not null before using it to avoid any potential issues/coredumps. Workaround: None. |
16 | SBX-103950 | SBX-106767 | 2 | PortFix SBX-103950: PAI differences between SBC and GSX Impact: The SBC was using the ingress calling URI information to create the egress PAI header contents even when the calling party number digits are all removed using DM/PM rules in the PSX. Root Cause: The SBC supports additional functionality that is not present on the GSX and it can use the contents of the calling URI from the ingress side of the call even when the PSX does not set the username mask flag in the calling URI parameter in the policy response. Steps to Replicate: Configure the PSX to generate the PAI header on the egress INVITE, but remove all the calling party digits, all the calling URI username digits and the generic name parameter. Then make a basic call and check that the SBC does not include PAI in the egress INVITE. | In order to provide equivalent signaling on the SBC to the GSX, the SBC code is updated to check that the PAI header contains username and/or displayname parameters before adding it into the egress INVITE. On the PSX, when the customer wants to delete the calling party number digits, they also need to remove the calling URI username and the generic name information. Workaround: Need to use SMM to remove the PAI header. |
17 | SBX-106687 | SBX-107178 | 2 | PORTFIX SBX-106687: Network Tools - Platform Interface Status incomplete Impact: In Network Tools, the Platform Interface Status section can be used to display the status of Interface selected from the left side section. Root Cause: For interfaces like pkt0, pkt1, mgt0, mgt1 the status message displayed in textarea element, had more than one < and > characters and so the text within them was considered as HTML block by the browser and it was hidden. Steps to Replicate:
| To prevent the browser from interpreting the special characters < and > as HTML block, the element used to display the status message was changed from <textarea> to <pre> Workaround: Not Available. |
18 | SBX-105850 | SBX-105897 | 2 | PortFix SBX-105850: The SBC: SBC failed to come up after sbxstart. Impact: At startup of SBC, there is a possible race condition due to which SBC processes may go for an additional restart before they come up and restore config data. Root Cause: Race condition in the code between threads. Steps to Replicate: Run installation and startup on various platforms. | Race condition in setting some common variables is avoided by using static path of binaries. Workaround: None. |
19 | SBX-107642 | SBX-107909 | 2 | PortFix SBX-107642: The SBC terminates call as 491 does not get relayed. Impact: 491 response to Re-INVITE is not relayed even though relay4xx-6xx and E2E Re-invite are enabled Root Cause: The SBC was not considering the re-INVITE without SDP to be received from the network. This is causing 491 to be locally handled. Steps to Replicate: Enable relay4xx-6xx flag and E2E re-INVITE. Send a Re-invite without SDP to SBC and respond 491 for that re-invite. | The code is fixed to set the ReInvite without SDP as locally generated or received from the network. Workaround: No workaround. |
20 | SBX-103103 | SBX-105656 | 2 | PortFix SBX-103103: The SBC: BFD packet forwarded by the router is not received by the SBC. Impact: Once the BFD session is established on a port (either primary or secondary), an immediate port switch over is followed due to BFD packets dropped at NP for a brief amount of time (~1 second). This eventually triggers a Node switchover. Root Cause: A race condition in ACL lookup is the cause of this issue. Steps to Replicate:
| The code is modified to address the issue. Workaround: An user ACL can be added as a workaround. |
21 | SBX-103183 | SBX-106172 | 2 | PortFix SBX-103183: The SBC incorrectly formatting the rport in the VIA header. Impact: The SBC incorrectly formats the rport value in the VIA header of the response message if rport has a valid port number at the end of VIA header of a request message Root Cause: The code does not check if rport has some valid port number or not. If rport is the last parameter in VIA header, it appends "=<source port>". Steps to Replicate:
| The code is modified so that it checks for any port number in rport parameter (rport is at the end of VIA header of request message), it replaces the port number and appends it's own report. Workaround: Following SMM can be used as a work around |
22 | SBX-107190 | SBX-108282 | 2 | PortFix SBX-107190: Enabling DisableZoneLevelLoopDetection not working on ZONE level. Impact: When DisableZoneLevelLoopDetection and loopDetectionFeature are both enabled, loop detection is occuring at the zone configured for DisableZoneLevelLoopDetection . Root Cause: When the loop detection flag is enabled at both zone and global level, global logic was taking precedence over zone. Steps to Replicate:
| The code is modified to give precedence to DisableZoneLevelLoopDetection over loopDetectionFeature when the loopdetection flag is enabled at both a zone and global level. Workaround: None. |
23 | SBX-104136 | SBX-104729 | 2 | PortFix SBX-104136: Unable to login to a CLI session. Impact: The SWe Active profile configuration may cause a password change commit to hang. Root Cause: An Internal Configuration change related to sweActiveProfile leaves the changes in candidate database. This causes another commit from SmProcess a deadlock, as sweActiveProfile change subscription needs the SM Subscribers acknowledged. Steps to Replicate: This cannot be recreated through User Interfaces. Internal error condition. | The code is modified to revert the changes from candidate database, if the sweActiveProfile commit fails. Workaround: None. |
24 | SBX-107254 | SBX-107838 | 2 | PortFix SBX-107254: The confd connections are not cleaned up properly. Impact: If the standby experiences a power hit and therefore the confd connections are not properly torn down. Root Cause: Active side needs to run keepalive and cleanup stale connections to address standby abnormal shutdown. Steps to Replicate: Test by shuttingdown/pull plug on standby on a HA system. | The code is modified to run the keepalive the connection and cleanup if standby is shutdown abruptly. Workaround: None. |
25 | SBX-109083 | SBX-109237 | 2 | PortFix SBX-109083: There was a SCM Process core dump during a SipSgAORHashRemove. Impact: The SCM Process cores due to corruption of entry in Registration hash table post switchover. This corruption is rare and occurs infrequently. Root Cause: The corrupted AOR entry in hash table was allocated during reconstruction of Active RCB from standby context after switchover. SYS Error logs indicates presence of duplicate AOR entry. This could potential lead to corruption. Steps to Replicate:
| The code is modified to ensure only one AOR entry exists in hash table after switchover on Active SBC's cache. If AOR entry is not found during remove operation, we manually remove the entry to avoid the corruption later. Workaround: None. |
26 | SBX-107420 | SBX-107881 | 2 | PortFix SBX-107420: Failed to download a Call Diagnostics file. Impact: We were unable to download a large size call diagnostics log file. Root Cause: When we tried to download a large size call diagnostics log file. It was failing with JAVA heap error because IOUtils toByteArray API was created internally ByteArrayStream to store file data into byte format. Due to a JAVA memory restriction, we were getting Heap error from ByteArrayStream. Steps to Replicate:
| Use a copy API instead of the write API of IOUtils. This internally copies the data from inputStream into OutputStream. Workaround: None. |
27 | SBX-104118 | SBX-105335 | 2 | PortFix SBX-104118: The LeakSanitizer detected memory leaks in Scm Process Impact: While relaying REGISTER messages the SBC could leak memory blocks allocated to hold the record-route header information. Root Cause: The SBC allocates memory blocks to hold the contents of the record-route headers in the REGISTER message. But if the record-route header information is associated with the SBC IP address then the SBC does not correctly free up the memory blocks causing a leak. Steps to Replicate: Run test cases for stateless REGISTER relay call scenarios where the IP information in the record-route header is the SBC's IP. | The code is modified to correctly free up memory allocated to store the record route header information. Workaround: None |
28 | SBX-106822 | SBX-108465 | 2 | PortFix SBX-106822: There was a crash observed in Four GPU Codec Scenario. Impact: The G729AB GPU codec may crash when there are lost packets in the incoming G729AB stream, which in turn leads to SWe_UXPAD crash and the SBC application restart. Root Cause: An uninitialized stack variable in GPU G729AB decoder code was identified as the root cause. Steps to Replicate:
| The code is modified to initialize the stack variable appropriately. Workaround: No workaround. |
29 | SBX-60855 | SBX-106923 | 2 | PortFix SBX-60855: The OPTIMA FTTH Stat for TG-A and TG-C Stat mismatching. Impact: The active register count on ingress TG is not decremented when refresh REGISTER is bad. Due to this issue, there is difference in count of total stable registrations across zones. Root Cause: When the load of bad Refresh or initial REGISTERs received at the SBC, some of the registers are not getting userNPhoneContextKey. Due to this issue, the code that is responsible for reducing activeRegCount is not being executed. Steps to Replicate:
| The code is modified to address the issue. Workaround: None. |
30 | SBX-104552 | SBX-105553 | 2 | PortFix SBX-104552: After a switchover, the SBC does not send Goodbye packet for Text stream. Impact: When a call is using T140/TTY interworking, after performing a switchover, the RTCP bye is not sent toward T140 stream endpoint. Root Cause: In the T140/TTY interworking, the resource for T140 stream is not mirrored properly to standby causing deactivating does not work after switchover Steps to Replicate:
| The code is modified to mirror resource correctly for T140 stream in T140/TTY interworking Workaround: None. |
31 | SBX-102726 | SBX-106884 | 2 | PortFix SBX-102726: Diameter RX had the wrong data in media-component AVP post T.38-488 Impact: Sending wrong data in media-component AVP (codec-data) when T.38 failback fails. Root Cause: Instead of sending last negotiated codec, the SBC was sending previous offer-answer data in the media-component AVP of AAR message. Steps to Replicate:
| The code is modified to send last negotiated codecs in the media-component AVP of AAR message. Workaround: Not Applicable. |
32 | SBX-104563 | SBX-104752 | 2 | PortFix SBX-104563: The SBC is not updating DNS servers order in DnsServerStatistics on deleting and creating fresh DNS Group. Impact: The SBC was showing the incorrect DNS Servers Index in DnsServerStatistics command "show table addressContext default dnsGroup <dnsGroupName> dnsServerStatistics " when the DNS Servers were deleted and re-created in a different order with the same server IPs. Root Cause: The DNS Server Statistic blocks are not deleted when the DNS Servers are deleted and continues to remain hashed with the IP with which it was created. Steps to Replicate:
| The code is modified to delete the DNS Server Statistics block and remove it from the IP hash when the DNS Server is deleted. Workaround: None. |
33 | SBX-104507 | SBX-106553 | 2 | PortFix SBX-104507: The SBC is not passing URI parameter while History to Diversion interworking Impact: The SBC is not passing URI parameter user=phone while History to Diversion interworking , though the parameter is present in History Info Root Cause: No support for the requested functionality existed up to now. Probable cause was the lack of requirements. Steps to Replicate: On the ingress leg, enable acceptHistoryInfo. On the egress leg, enable diversionHistoryInfoInterworking. | The code is modified to include URI parameter user=phone in diversion header, when history info header has the uri parameter user=phone during interworking. Workaround: None. |
34 | SBX-105544 | SBX-107905 | 2 | PortFix SBX-105544: The Dialog scope variable is not present after SMM reject on re-invite message. Impact: TheSMM is not adding the header in the rejected response which is stored in the Dialog scope variable. Root Cause: The Dialog scope variable was not saved due to the Reject operation in the SMM. Steps to Replicate:
| The code is modified to store the Dialog scope variable when there is Reject operation in the SMM. Workaround: No workaround. |
35 | SBX-108146 | 2 | External volume is not mounted properly causing LCA to terminate. Impact: The Cinder Volume was unable to attach itself within a required time frame, which caused the mount check for the same to fail and resulting in terminated LCA. Root Cause: The mountVolume.sh mounts the Cinder Volume if it finds it, but if Cinder Volume is not found it within 1 minute it skips the mount. This mount is then checked in lca.py and if the check fails LCA is terminated. Steps to Replicate: In case the mount was successful, we will get this log in lca.log | The code is modified to wait for 90 seconds for the cinder to attach. If the cinder does not attach, it tries (since the max reboot count of 5 is not reached) to reboot the instance and in turn, triggers the mount logic to access the cinder again. Workaround: None. |
36 | SBX-108025 | SBX-108051 | 2 | PortFix SBX-108025: Receiving an unexpected CANCEL in SBC-to-SBC GW early media case Impact: An UPDATE is responded with 503 response and CANCEL is sent out Root Cause: An UPDATE is removed from the dialog when receiving another UPDATE during the processing of previous UPDATE. Steps to Replicate:
| The code is modified not to remove the UPDATE request from the dialog when receiving another UPDATE. Workaround: No workaround. |
37 | SBX-105280 | SBX-105548 | 2 | PortFix SBX-105280: There was a Cpx Process Memory leak for single calls on the OAM node. Impact: The Cpx process can leak small amounts of memory when creating/modifying the SNMP configuration. Root Cause: While processing the SNMP configuration commands, the SBC was creating temporary internal memory blocks to read and write information from/to CDB. But it was not freeing up this memory at the end of the configuration action. Steps to Replicate: Modify the SNMP configuration to reproduce the issue. | The code is modified to correctly free temporary memory allocated during the configuration process. Workaround: None. |
38 | SBX-105389 | SBX-105427 | 2 | PortFix SBX-105389: Dereference after a NULL check and dereference the NULL return value. Impact: The coverity scanning tool identified a potential edge case scenario where the lawful intercept code could potentially access a null pointer leading to unexpected behavior and potentially a coredump. Root Cause: While the code was performing X2 peer status updates it retrieved the peer information from a hash table but did not verify that the pointers inside the record it retrieved were valid. It would be an extreme error case for this to result in reading of a null pointer and would likely need to be due to another problem. But coverity highlight it as an edge case issue to fix up. Steps to Replicate: Run test cases for lawful intercept using packet cable V2.0 configuration. | The code is modified to validate the pointer is not null before using it and avoid any error scenarios. Workaround: None. |
39 | SBX-108575 | SBX-108945 | 2 | PortFix SBX-108575: CE_2N_Comp_CpxAppProc_EO.CPX.CPX.00450 : NOTICE) CpxUpgradePersistentMacAddressStatus: will move 0 entries to new table macAddress2Status Impact: While performing an upgrade of LIF group information there was a small memory leak. Root Cause: The code was reading CDB data and storing the value in local memory while perform CDB schema upgrade. This memory was not being freed causing a small memory leak. Steps to Replicate: Run LSWU calls. | The code is modified to ensure the local memory is correctly free up after usage. Workaround: None. |
40 | SBX-93922 | SBX-108308 | 2 | PortFix SBX-93922: The SBC is sending Min-Expires header twice to endpoint for 423 Interval Too brief response Impact: Min-Expires header is sent twice in the REGISTER response Root Cause: Min-Expires header was sent twice as it was getting added by the application and the transparency profile. Steps to Replicate:
| The code is modified before adding the header during the processing of Transparency profile. Workaround: Remove Min-Expires headers from the Transparency profile. |
41 | SBX-107825 | SBX-108287 | 2 | PortFix SBX-107825: The LM (MoH) re-Invite replied 200 OK (video inactive) Impact: Video stream continues to be on HOLD even though Audio stream is offered as sendrecv when the SBC generates offer for late-media re-INVITE in covert mode. Root Cause: While send offer in 200 OK for late media re-Invite, the SBC changed the audio DPM to sendrecv but video DPM was not changed and retained as inactive based on the last negotiated DPM on that leg. Steps to Replicate: To re-create the issue:
| The code is modified to change the DPM for both audio and video streams to sendrecv while generating offer for late media re-INVITE in Convert mode. Workaround: None. |
42 | SBX-108273 | SBX-108540 | 2 | PortFix SBX-108273: SBX-106321 does not work when Require header comes in 18x without 100Rel. Impact: Proxy Behavior for 18x message not working when Require Header is present in the 18x message, but not 100rel value in it Root Cause: The code is not present for 100 Rel Proxy behavior when Require Header is present in the 18x message, but not 100rel value in it Steps to Replicate: Run the scenario below to reproduce the issue.
| The code is modified to consider this case when the Require Header is present but not with the 100rel value in it. Workaround: Not Applicable. |
43 | SBX-74155 | SBX-104719 | 2 | PortFix SBX-74155: The ACL rule is missing on the SBC in LD triggered switchovers and link recovered after Impact: When an IPACL rule is created that references an IP interface, but that IP interface is down since the system started up, the rule is not successfully created. Root Cause: When an IP interface is failed on system startup, the system does not add that interface to the kernel. When an IPACL rule is added that references that IP interface, it fails to be added to the NP. Steps to Replicate: Start an SBC with an IP interface failed, that also has one or more IPACL rules that have been configured that reference that IP interface. Bring up the IP interface and logs will show the IPACL rules have been successfully added. | The code is modified to detect this situation and maintain a retry list. Once the IP interface comes up, it retries the associated IPACL rules that were previously failed. Workaround: This issue can be worked around by having IPACL rules that do not reference the IP interface. |
44 | SBX-105849 | SBX-106229 | 2 | PortFix SBX-105849: An RTP inactivity call is torn down as expected, but TRAP not sent (even configured). Impact: Due to RTP inactivity call gets torn down as expected, but TRAP is not generated for some of the calls. Root Cause: If a call gets torn down due to RTP inactivity and a trap is raised, then SBC sets an internal flag while raising the trap for such a call. However, due to a software bug, this flag was not reset when this call goes down. Steps to Replicate:
Issue: One would notice that after some time, the SBC fails to raise "media inactivity" trap for some of the calls even though such calls gets torn down due to media inactivity. | Reset the flag gracefully during call tear down to address the issue. Workaround: None. |
45 | SBX-103306 | SBX-107766 | 2 | PortFix SBX-103306: Allocated bandwidth for opus call is 1032kb and 1028kb for a single call. Impact: If "transcoderFreeTransparency(TFT)" is enabled at Route PSP, then extra bandwidth is allocated for opus call in case maxaveragebitrate attribute is not received in SDP from the endpoints. Root Cause: If maxaveragebitrate is not received in SDP, then the SBC was using the max value of 510kbps as the default value (which was not as per RFC). Later, this bitrate value gets intersected with Route PSP configured value. However, for TFT calls, this intersection with route PSP does not happen. As a result, the SBC continues to maintain this value as 510kpbs which results in extra bandwidth allocation. Steps to Replicate: Configuration:
Test Result without Fix: Since the maxaveragebitrate defaults to 510kbs, the SBC ends up allocating more bandwidth than expected. | The code is modified to take action if "maxaveragebitrate" is not received in the SDP by deriving its default value according to RFC using "maxPlayBackRate" and mode (mono/stereo). Workaround: None. |
46 | SBX-65509 | SBX-96822 | 2 | PortFix SBX-65509: Preferred payload number was not used for either dtmf or amrwb when "different2833PayloadType" transcode option is enabled. Impact: Preferred payload number was not used for either dtmf or amrwb when "different2833PayloadType" transcode option is enabled. Root Cause: In case of when the Route PSP being configured with the same payload number for both DTMF and Codec, the SBC skipped over this PT value and as a result, this PT value could not be used for either of DTMF or Codec. Steps to Replicate:
| The code is modified to prefer the configured value for DTMF PT in case of a conflict between the configured PT values. Workaround: Do not configure the same PT value for DTMF and Codec entries in Route PSP. |
47 | SBX-108479 | SBX-108955 | 2 | PortFix SBX-108479: A switchover to standby was not successful when the active node dumped core and went for deadlock Impact: Switchover does not get triggered in case of abnormal termination of CPX and PRS process. Root Cause: Logic to send switchover event is present in PRS process and the PRS cleanup script but in case of abnormal termination, we are unable to get the current node's role and service ID that is needed for checking whether to send switchover event or not. Steps to Replicate: Kill CPX process and then after 2 seconds, kill PRS process. | The code is modified to save the service ID on the node going down if it was running as active so that the PRS cleanup script can look for the file and send switchover event while going down. Workaround: No workaround. |
48 | SBX-107543 | SBX-107544 | 3 | PortFix SBX-107543: CDR Field 12 in ATTEMPT record filled incorrectly when Response Profile is configured. Impact: The CDR code was using the reasonCode from the response profile to populate the call disconnect reason field. But the the reasonCode is the SIP status code, and not the internal CPC disconnect reason. Root Cause: The code was incorrectly using the reasonCode in preference to the cpcCauseCode. Steps to Replicate:
| The code is modified to only use the cpcCauseCode from the response profile, and not the reasonCode. Workaround: None. |
49 | SBX-107518 | SBX-108556 | 2 | PortFix SBX-107518: There was a Sync issue after the Standby SBC took over for the Active SBC. Impact: An active SBC gets into 'syncInProgress' state even after recovering from network glitch. Root Cause: Since network glitch is detected only on an active SBC side, the standby SBC side does not initiate sync process after the active system recovers from the network glitch. Steps to Replicate:
| The code is modified to check for the sync state of an active SBC and based on that, it should initiate the sync process with an active SBC. Workaround: No workaround. |
50 | SBX-105534 | SBX-105683 | 2 | PortFix SBX-105534: The SBC is terminating calls upon a second MSBC switchover. Impact: Calls are failing during a MSBC switchover due to corrupted neighbor cache on the switch. Root Cause: During switchover triggered by "reboot" of an active MSBC node, port switchover gets initiated in old active MSBC, which sends out the GARP from disabled NIF, causing the corruption in neighbor cache of the switch. As a result, packets coming from the SSBC lands on the old active MSBC instance causing call termination. Steps to Replicate:
| The code is modified to drop all outgoing packets from DISABLED port. Workaround: No workaround. |
51 | SBX-104814 | SBX-107756 | 2 | PortFix SBX-104814: A SIPS call load caused SCM to mem congestion and crash. Impact: While running the call/OOD load with more number of dialog stateful SMM variables configured, and those variables are applied per call/OOD message, there seems to increase in memory usage leading to memory congestion and causing the crash. Root Cause: Whenever dialog stateful variable is created, default 6144 bytes will be allocated statically per variable. While running the load with more number of dialog stateful variables configured and applied to call, might lead o increase in memory usage Steps to Replicate: Running the call load with more number of dialog stateful SMM variables configured and used per call. | The code is modified to change the static array to pointer variable and allocate only required memory per dialog stateful variable. Workaround: None. |
52 | SBX-105412 | SBX-105424 | 2 | PortFix SBX-105412: The CE_2N_Comp_CpxAppProc leak for port SWO (BFD). Impact: Small memory leak during configuration of packet port with BFD configuration associated. Root Cause: The configuration code was reading information from CDB and storing information in an internal memory block but not freeing it up. Steps to Replicate: With a BFD configuration on the SBC disable and enable the pkt port by setting mode OOS and state disabled and then enable the pkt port again. | The code is modified to correctly release the internal memory block at the end of the configuration action. Workaround: None |
53 | SBX-105310 | SBX-105350 | 2 | PortFix SBX-105310 : The SM Process leak for the SBC call on an active SBC. Impact: The redundancy group manager (RGM) that is used in conjunction with N:1 deployments has a memory leak. Root Cause: The RGM handles switchover and fault messages in N:1 deployments and it was not freeing up the ICM message after processing which results in a memory leak. Steps to Replicate: This issue was observed in an SBC configuration especially when restarted instances. | The code is modified to correctly free ICM messages. Workaround: None |
54 | SBX-105711 | SBX-105923 | 2 | PortFix SBX-105711: There was a CE_2N_Comp_CpxAppProc leak during disable and enable of pkt port Impact: Creating an H248 signaling port results in a small memory leak Root Cause: While processing the H248 signaling port creation command when metavars are defined for the IP value, the SBX allocated memory to hold the metavar value from CDB internally for processing, but never freed up this memory block at the end of the port creation action resulting in a small leak. Steps to Replicate: Create an SBC instance where metavars are used to define the IP value for the H248 signaling port. | The code is modified to correctly free the memory block at the end of processing the signaling port creation. Workaround: none |
55 | SBX-105591 | SBX-105599 | 2 | PortFix SBX-105591: Observed that PRS process heap buffer overflow issue on 9.2 ASAN build 63. Impact: The BRM process was accessing memory after it had been freed. As the memory is being read immediately after being freed, then it is unlikely this would cause a problem. Root Cause: If the BRM process received an unexpected message then it was trying to print a debug message to indicate the message type. However, the message had already been freed up because it was unexpected. This was observed on the standby server and most likely generated at the point of switchover. Steps to Replicate: Run normal call load and perform switchovers. | The code is modified to collect the message type information before the message is freed so that the debug log content can be safely generated without accessing freed memory. Workaround: None. |
56 | SBX-106042 | SBX-107669 | 2 | Portfix for SBX-106042: The RCB(s) can be hijacked effect on registered users/EPs. Impact: Issue 1: When the register is sent to registrar SBC creates a RCB for that particular User. When a fake/hijacked register is rejected with 403 some of the parameters in RCB are being modified and users were not able to make a call due to security mechanism being set to TLS. Issue 2: If there is any timeout on the RCB that leads to it moving to terminated state and a refresh register arrives subsequent calls are rejected. Root Cause: Issue 1: In 82x build when a Register request is rejected with 403 it moves to terminated state. Also whenever we receive a register we modify the RCB details irrespective of the response we might receive from the registrar. Note: A register is considered fake when we receive a 403 response for that. Steps to Replicate: Make the configuration as mentioned in the description and use the config file attached for reference:
| The code was modified to fix the two main issues: Workaround: None. |
57 | SBX-100225 | SBX-105915 | 2 | PortFix SBX-100225: There was an AddressSanitizer: heap-use-after-free in UasProcessMsgCmd on address 0x623000187198 at pc 0x5623cc7b3b42. Impact: The SCM process is accessing memory after it is freed during timer expiry handling when there is no response to an OPTIONS message that was triggered due to debug optionsPing using an FQDN. Accessing memory after it is freed can cause unexpected behavior and in the worst case potentially coredumps. Root Cause: The SIP dialog memory block was being removed in two places while handling the timeout for the debug optionsPing command, which could result in unexpected behaviour and potentially coredumps. Steps to Replicate: run debug optionsPing command | The code is modified to address the issue. Workaround: Do not use this debug command, or use it with an IP instead of an FQDN. |
58 | SBX-107752 | SBX-108375 | 2 | PortFix SBX-107752: The PRS Process core dumped on detaching/attaching interface on the SBC SWe. Impact: The issue is observed only when the interface is is toggled through the root. Interface has only the SIPSIG Port IP and IPv6 associated with the LIG was not up with interface. Root Cause: When the link was down LIG IPv6 removed, but was not configured when LIG was up. Steps to Replicate:
Result: The PRS Process should not core after re-attaching the pkt0 interface. | The code is modified to also configure the untagged LIF IPv6 address again when link is bounced. Workaround: None. |
59 | SBX-107613 | SBX- | 2 | PortFix SBX-107613: A customer encoder produces corrupted output when the channel is reused by lower mode Impact: Degraded audio in AMRWB stream when AMRWB (GPU) call load is running, particularly when each call uses different bitrate. Root Cause: Problem occurs when the same codec context is reused and the previous used was for higher bitrate, the root cause was identified due to reinitialization logic for an internal buffer. Steps to Replicate:
| The code is modified to appropriately reinitialize the internal buffer. Workaround: Problem does not occur when all channels use the same bitrate. |
60 | SBX-106343 | SBX-108464 | 2 | PortFix SBX-106343: The EVRCB Decoder asserts in Erasure frames simulation test. Impact: GPU EVRCB decoder may crash when there are lost packets in the incoming EVRCB stream, which in turn leads to SWe_UXPAD crash and the SBC application restart. Root Cause: Precision errors in the floating point comparison in EVRCB decoder code was identified as the root cause. Steps to Replicate:
NOTE: The issue may not be reproduced always. | The code is modified to handle precision errors. Workaround: No workaround. |
61 | SBX-107179 | SBX-108418 | 2 | PortFix SBX-107179: The Dual Hold music on hold inter lab failed when both user login on secure PCC. Impact: Dual Hold music on hold inter-lab failed when both user login on secure PCC with "error opening media". Root Cause: The SBC was keeping all the crypto instead of only common crypto if request was coming from egress side. Steps to Replicate: Test Cases for the hold/unhold Scenarios: | The code is modified so the SBC only keeps the common crypto when requesting from the egress side. Workaround: To avoid this issue, the UA should send only single common crypto in UPDATE SDP. There is no workaround from the SBC side. |
62 | SBX-106583 | SBX-106756 | 2 | PortFix SBX-106583: With the Q1912 in a 302 Redirect message, the SBC sends RN and NPDI even though Contact Header in 302 does not have RN and NPDI. Impact: When making a call where INVITE contains NPDI/RN parameters and the SIP variant on the ingress trunk group is set to Q1912 when the call goes through 3xx processing the wrong called party number is sent in the subsequent INVITE. Root Cause: When processing the 3xx and making a second policy dip the code was meant to remove the generic number parameter of type TOA_PORTED_NUMBER. But the code assumed there would only ever be one generic number parameter present. However, when the ingress SIP variant is set to Q1912 the SIP code internally creates a generic number parameter of type additional calling party number based on the contents of the FROM header. In this scenario the code was unable to delete the generic number of type TOA_PORTED_NUMBER and this was passed back to the PSX in the second policy dip and resulted in routing confusion and unexpected parameter content in the INVITE following the 3xx. Steps to Replicate: Perform a call where the SIP variant on the ingress trunk group is set to Q1912 and the INVITE contains the npdi/rn parameters e.g. | The code is modified to correctly delete the generic number parameter of type TOA_PORTED_NUMBER associated with the number translation information from the first policy dip to avoid routing confusion on the second policy dip. Workaround: If possible, change the SIP variant on the ingress trunk group to be "sonus" instead of "Q1912" to avoid the creation of the generic number parameter of type additional calling party number based on the FROM header contents. |
63 | SBX-70305 | SBX-103369 | 2 | PortFix SBX-70305: There was 15-16 seconds media outage when UXPAD processes are killed, the switchover is occuring aonly after 15-16 seconds of killing all the UXPAD processes. Impact: 15 seconds of media outage during switchover triggered by crash of DSP processes on the SBC SWes. Root Cause: The current DSP health-check mechanism takes up to 15 seconds to ascertain failure, leading to delayed switchover action. Steps to Replicate: Attempt a switchover by killing one of the SWe_UXPAD processes on a SBC SWe system. Observe media outage during the process. | The code is modified to enhance crash detection of DSP processes on the SBC SWes. Workaround: No workaround. |
64 | SBX-88007 | SBX-106100 | 2 | PortFix SBX-88007: A call flow should work with 5 video and 1 audio streams that is not working but when one video stream is removed callflow is working. Impact: Call fails if peer SDP contains six streams (5 video and 1 audio) and directMedia along with ICE is enabled at SBC. Root Cause: Insufficient memory allocation for this SDP caused the call failure during inter-process communication. Steps to Replicate: Configuration requirements to run test:
Expected Result: The call succeeds. Actual Result: The call fails. | Increased the memory buffer size to accommodate six streams. Workaround: None. |
65 | SBX-103890 | SBX-105321 | 2 | PortFix SBX-103890: ERROR: ASAN reported "AddressSanitizer: heap-use-after-free" error for dialog-id transparency relay scenarios Impact: Accessing memory after it is freed can cause unexpected behavior which may result in coredumps. Root Cause: An invalid access of the freed memory occurred in dialog-id transparency relay scenarios. Steps to Replicate: Relay a call flow with the Dialog-ID transparency feature enabled. | The code is modified to not free the memory until processing completes. Workaround: None |
66 | SBX-103570 | SBX-106666 | 2 | PortFix SBX-103570: Under the Register load, major logs related to DBL were flooding the SBC. Impact: Unnecessary message exchanges occurred between the SBC modules, resulting in a flood of logs. Root Cause: Due to a missing boundary check, the SBC stopped accepting any new entries when too many DBL tracking entries exist (more than 4K). Steps to Replicate:
| The code is modified to prevent sending unnecessary messages. Workaround: None |
67 | SBX-103539 | SBX-105933 | 2 | PortFix SBX-103539: Observed flooded Logs for refresh registration in the Standby SBXrestart stopped for sometime "sipsgRegSecurity.c (-2745) 1752. SipRaDigestTlsProcessRefreshRegister: No Digest TLS negotiation in progress" Impact: The DBG logs were filling up with the following MAJOR level log: Root Cause: This is an information message and should not have been getting generated at MAJOR level. Steps to Replicate: Run registration call flows. | The code is modified to address the issue. Workaround: None. |
68 | SBX-108951 | SBX-109060 | 2 | PortFix SBX-108951: The ASAN ERROR :==CE_2N_Comp_ScmProcess_0==22395==ERROR: AddressSanitizer: heap-use-after-free on address 0x6200000373c8 at pc 0x560aae46bf67 bp 0x7fc9bc717850 sp 0x7fc9bc717848. Impact: Heap After Free usage for the hMsgHandle after removed from the pstServerRequestList Root Cause: Accessing ToTag from the hSipMsgHandle after free, so it is causing ASAN detecting heap-use after free error. Steps to Replicate: Run a call flow scenario involving PRACK Message with SDP. | The code is modified above few lines before freeing the hSipMsgHandle. Workaround: None. |
69 | CHOR-6320 | SBX-105287 | 2 | PortFix CHOR-6320: The SWelite AKS: UxPAD coredump observed on media container while pumping 2X overload of G711U to G711U DSP (media transcoding disabled) call load. Impact: The SWe_UXPAD crash was seen during overload transcode test in 2 vcpu SWe deployment in the public cloud. Root Cause: Potential corruption in packet buffers due to issues related to concurrency specifically in 2 vcpu transcode overload scenarios. Steps to Replicate:
| The code is modified to fix concurrency issues in transcode call scenarios in 2 vcpu SWe deployments. Workaround: No workaround apart from avoiding overload scenarios for transcoded calls. |
70 | SBX-95106 | 2 | SIP over SCTP calls failing for app. 25-30 seconds after enabling a new SIP signaling port Impact: Disabling/Enabling SIP-UDP signaling port triggers SIP-SCTP packets being sent out of management interfaces (mgt0/mgt1). Root Cause: Missing ipInterfaceGroup information in SCTP socket created by kernel, not SBC application. Steps to Replicate: Without the fix in the SBC providing SIP-SCTP connections, disable/enable/add a SIP-UDP signaling port and observe the SIP-SCTP packets leaving from management interfaces. | The code is modified so when the Linux kernel's SCTP stack makes a copy of another SCTP socket created by SamProcess, the ipInterfaceGroup information has to be copied from application-created socket to internally/kernel created socket. Workaround: None. |
71 | SBX-105290 | 2 | The SBC CDR was redirecting digits captured incorrectly Impact: The redirecting number recorded in the CDR was not correct if the first policy dip route was used for the call but there was an updated redirecting number from a later route in the policy dip. Root Cause: The code was incorrectly using the last per route redirecting number from the policy response to overwrite the redirecting number from the received INVITE message and using this to populated the redirection information field in the CDR record. Steps to Replicate: Configure the PSX routing label with two different route with two different ingress trunkgroups, and in each trunk add a DM rule for RDN. Now make a call check what is the RDN from the CDR logs. If the call gets success with route 1 then it should have RDN according to DM rule in route1. | The code is modified to populate the CDR using the per route redirecting number digits or the contain received from the INVITE. Workaround: Not Applicable. |
72 | SBX-99258 | 2 | For the OOD NOTIFY, the SBC sending 481-Call Leg/Transaction does not exist when the same SBC acting as P-CSCF and IBCF. Impact: The SBC fails to send NOTIFY if the User part is not present in the To Header. Root Cause: The SBC is not able to find the entry in the hash-table as to-tag is not parsed properly, because of user part being absent in the To header. Steps to Replicate: 1. Make a basic Subscribe-Notify call, ensure that in From header of subscribe and To header of NOTIFY does not have User part. 2. See that for Notify SBC will respond with 481 call leg does not exist. 3. Try the same with Fixed build, NOTIFY should reach the subscriber.
| The code is modified to fetch the tag properly even if the user part is not present in To header. Workaround: No Workaround |
73 | SBX-106815 | 2 | The PES Process was leaking memory. Impact: In certain circumstance with high enough call rate, the SBC may experience PES memory leak. Root Cause: The newly ported Postgres code mishandled Postgres DATABASE cursor and counter. Steps to Replicate: We have not reproduced the memory leak in house. This problem is funded and reproduced in the customer lab, when they were testing their call load. The private fix is tested in the customer lab too. | The code is modified and the bug fixed in cursor and counter area. Workaround: Lower call rate should lower the risk. |
74 | SBX-107348 | 2 | In a SIP LM call, a re-INVITE was sent in 18x-PRACK stage on ingress. Impact: The SBC sends re-INVITE to late media while the call is still in PRACK pending state. Root Cause: Logical error that fail to detect the state of call not connect yet and the SBC tries to re-INVITE out. Steps to Replicate:
| The code is modified to check to validate the state of the call before re-INVITE out. Workaround: Disable the PRACK or disable LRBT. |
75 | SBX-106930 | 2 | The SRTP video (direct I/O) packets shuffled on the wire (video quality issue). Impact: Out of sequence media packets are observed on out-going streams of pass-through calls on some NICs when incoming media traffic is bursty. Root Cause: An absence of hardware computed rss hash causes an issue in the media packet processing subsystem, where the packet distributor ends up distributing packets to workers without maintaining flow ordering. This problem becomes observable when incoming media arrives in a bursty manner. Steps to Replicate:
| The code is modified to maintain flow ordering even when rss hash is not computed by the NIC. Workaround: Ensure the incoming media stream is not bursty. |
76 | SBX-107944 | 2 | The SBC had High Memory related to SBX-104247. Impact: There is a PRS leak of structures related to IPSEC. Root Cause: An upgrade of the debian kernel (from 3.16 to 4.19) took place with V08.00 and higher and has triggered a leak of XRM_IPSEC_SA_STRs memory blocks. The leak is only observed in the newer kernel. Steps to Replicate: Register the endpoints using IPSEC and make calls, and leak will be observed over time. | The code is modified to free the structure that was leaking. Workaround: This leak will only affect customers who are using IPSEC. |
77 | SBX-105483 | 2 | Malformed P-charging vector. Impact: P-Charging-Vector not passed transparently to egress on SIP-I to SIP call, when Create P-Charging-Vector is selected on egress IP profile and Store P-Charging vector is selected on ingress IP profile. Root Cause: The SIP-I INVITE contains IAM with a bad parameter and no parameter compatibility, causing the SBC to send 183 with CFN message and not transit the P-Charging-Vector. Steps to Replicate:
| The code is modified to ensure P-Charging-Vector is passed to egress in this case Workaround: Disable support of CFN message in ISUP signaling profile. |
78 | SBX-103616 | 2 | The search function in EMA does not work. Impact: When a custom perspective is created, Search function does not work Root Cause: There is a node called URI Parameter Manipulation that has a child node with the same name. When a custom perspective with this node is created and a search is performed, the search enters into an infinite loop and is never completed. Steps to Replicate: Create a Custom Perspective with "URI Parameter Manipulation" and all its children. | The code is modified to prevent making the node itself as both parent and child Workaround: Delete Custom Perspective and restart the SBC. |
79 | SBX-106317 | 3 | The CAC Offender list shows incorrect date/time when new offenders are added. Impact: The CAC Offender List shows the incorrect first and last reject times Root Cause: The first and last reject times were incorrectly obtained and set. Steps to Replicate: 1) Create sipCacProfile with following data. set profiles sipCacProfile CAC-REDESIGN callIngressRatePeriod 10 set profiles sipCacProfile CAC-REDESIGN callLimitEgress 2 set profiles sipCacProfile CAC-REDESIGN message ingressRatePeriod 1 set profiles sipCacProfile CAC-REDESIGN callLimitThreshold 100 2) Provision unregisteredEndpointCacProfile. [TNT] [SBXSUS9] [TNT] 3) Provision registeredEndpointCacProfile [TNT] [SBXSUS9] [TNT] 4) Do registration for few users 5) Initiate calls from AS side. [TNT] [SBXSUS9] [TNT] The CAC Offender list shows incorrect date/time when new offenders are added. | The code is modified to correctly initialize and obtain the first and last reject times. Workaround: None. |
80 | SBX-106269 | 2 | The RTT-TTY support to verify call flow in the SBC. Impact: Sometimes, the ASCII letters received in a T140 packet are sent as numbers and figures characters on g711 Baudot side. Root Cause: The Baudot has two modes: LTRS mode and FIGS mode. After transmitting 72 characters continuously in one mode, the recommendation requires to repeat LTRS or FIGS Baudot tone to reassert the current mode. The LTRS and FIGS mode have some common Baudot codes such as 0 (BKSP),2(LF), 4(SPACE) and 8 (CR). There is no need to change mode when any of these common characters need to be transmitted. The issue is that when in LTRS mode 72nd character is received as one of common characters mentioned above, then the SBC incorrectly sends FIGS mode Baudot tone. As a result, all subsequent LTRS characters are interpreted as FIGS and show incorrectly on screen of receiving phone. Steps to Replicate: Create a t140 pcap with characters in each packet (per line) such as this. Note: There is LF character after each line. AAAAAAAA | The code is modified to check current LTRS/FIGSmode and send the LTRS/FIGS Baudot code. Workaround: There is no workaround. |
81 | SBX-107142 | 2 | The SBX VM was unable to power on post power off procedure. Impact: The VMWare GPU SWe instance does not come up post reboot or GPU is not visible in the instance. Root Cause: When the SBC SWe instance runs in GPU mode, persistence mode of the NVIDIA driver is enabled using nvidia-smi to prevent the GPU state from being unloaded, this is a kernel-level solution and creating problem when the hypervisor is VMware. Steps to Replicate:
| Replaced the kernel-level solution with a more robust user-space solution by using NVIDIA Persistence Daemon to address the issue. Workaround: No workaround. |
82 | SBX-105497 | 2 | There was the wrong format of SIP 400 BAD REQUEST. Impact: When the SBC receives a message and is unable to find all the required headers, the SBC may respond with a bad 400 with syntax errors itself. Root Cause: When peer intentionally or possibly unintentionally is sending garbage message, the SBC is replying with the same. Steps to Replicate: Incoming requests need to contain required headers as part of content body section. | The code is modified to now discard the message. Workaround: Use SMM to drop the message. |
83 | SBX-109153 | 2 | The DTLS: 503 Service Unavailable with GCM Ciphers Impact: The following ciphers could not be used with DTLS:
Root Cause: The TLS profile had been updated with additional ciphers listed below but the DTLS code was not updated to support these. Steps to Replicate: Using DTLS client that support these ciphers make a connection to the SBX. | The code is modified to include support for these ciphers. Workaround: None. |
84 | SBX-109181 | 2 | The SBC sends all passthrough or transcode codecs in 200 OK of UPDATE at egress when sendOnlySingleCodecInAns is enabled only in Egress TG. Impact: The SBC is sending multiple codecs in 200 OK (for UPDATE) when sendOnlySingleCodecInAns flag is enabled on egress trunk alone. Root Cause: For the new modify offer triggered due to UPDATE from the peer, SBC is not applying the full offer-answer processing. Instead it is using the last negotiated codec list for responding back to the peer in the answer. As a result, the 200 OK(for UPDATE) is having multiple codecs towards the egress peer. Steps to Replicate:
| The code is modified so that the SBC applies full offer-answer cycle even if it receives the same SDP in UPDATE as that of last received SDP in 18x from the peer, so that, the SBC can pick a single codec for sending it in the answer to the peer. Workaround: None. |
85 | SBX-107164 | 2 | The SBC should handle MOH version 2 Impact: MS Teams have changed the mechanism for putting an active call on hold and signaling redirection of the call media to music on hold server (MOH). The original mechanism (MOHv1) used to send a REFER to SBC to refer the call to MOH server, the new new mechanism (MOHv2) sends a re-INVITE to SBC which can require the SBC to switch the media from primary to secondary NIFs. The SBC did not support this mid call media switching with a re-INVITE hence the media was not switching correctly to the MOH server. Root Cause: The SBC code did not support mid call media switching between primary and secondary NIFs with a re-INVITE. Steps to Replicate: | The code is modified to allow the media and ICE stun processing to switch between primary and secondary NIFs based on the X-MS headers received in a mid call re-INVITE message. Workaround: No workaround is supported for MOHv2 but call hold mechanism will work fine with MOHv1. |
86 | SBX-106625 | 3 | The SBC does not tear down the call if the INVITE contains Require: 100rel and the rel100Support flag is disabled on the ingress sipTrunkGroup Impact: The SBC does not reject the call if the incoming INVITE contains Require: 100rel and the rel100Support flag is disabled on the ingress sipTrunkGroup. Root Cause: The SBC was missing logic to reject the call. Steps to Replicate:
| The code is modified to reject incoming INVITE messages with SIP 420 Bad extension response if the incoming INVITE contains Require: 100rel and the rel100Support flag is disabled on the ingress sipTrunkGroup. Workaround: Use SIP Message Manipulation (SMM) to reject the INVITE with SIP 420 response or enable the rel100Support flag on the ingress sipTrunkGroup. |
87 | SBX-106167 | SBX-106863 | 2 | PortFix SBX-106167: The call ends up in one-way audio after the called party puts the call on hold and off hold twice. Impact: Call ends up in one-way audio after the called party puts the call on hold and off hold twice Root Cause: As a result of call-modify a couple of times, RTCP NAPT learning completes before RTP NAPT learning. This results in RTCP Remote Address being updated, which has remote RTCP Port. Due to incorrect code in RTCP modify flow, remote RTCP port, gets assigned to RTP port. This results in one-way media. Steps to Replicate: Run basic SIP to SIP call with NAPT & RTCP enabled. | Set the correct RTP Port as part of RTCP modify flow to address the issue. Workaround: Since the issue is caused to RTCP NAPT learning completed before RTP during multiple hold/Unhold scenario. Work around could be, |
88 | SBX-106200 | SBX-106264 | 2 | PORTFIX SBX-106200: The SBC 08.02.05 DSP coring system is unstable. Impact: Some Fax T.38 IAD calls (T.38 protocols version 3) result in a DSP crash and reload and calls are not successful. Root Cause: This condition is caused because this specific V3 IAD is sending CM messages with incrementing UDPTL seq numbers. Typically repeated messages carry same UDPTL seq number to indicate that they are redundant. Packets with unique seq numbers are assumed to be independent and data from these is causing an unchecked buffer overflow in 3rd party T.38 stack code. Steps to Replicate: Main cause of the crash based on core inspection seems to be multiple CM messages with incrementing UDPTL seq numbers Rx by stack. | The code is modified so there is a check to see if there is enough space available in tx_bits[] array to avoid overflow and avoid a crash in case of multiple CMs with incremental sequence numbers. Workaround: Use Version 0 for T.38 calls. |
89 | SBX-105901 | 2 | The heap-buffer-overflow in ASAN build for SIPS module. Impact: Observing heap buffer overflow in SCM process for info level log while decrypting the ROUTE header. Reading memory beyond the end of the allocated buffer can result in memory access faults and coredumps. Root Cause: Heap overflow is because debug statement is trying to print from a string variable which is not null terminated. Steps to Replicate: Execute a test case where INVITE message contains encrypted route-header and verify that there are no failures. | The code is modified create a local variable of type character array which gets dynamically created and is always null terminated. This variable will be used in the info log. Workaround: Not Applicable. |
90 | SBX-105598 | 2 | Native Forking and DLRBT are not working. Impact: With the Native Forking enabled, if the call is answered by Teams endpoint, the call gets released by the SBC. Root Cause: There are two reasons for Forking and DLRBT calls to fail for TEAMS endpoint. Steps to Replicate:
| 1. The code is modified to not return failure for DUMMY resource modification. Workaround: Disable the DLRBT and ICE learning for forked calls. |
91 | SBX-109286 | 2 | The IP Interface Group will cause issues when there are the same names with different upper or lower cases Impact: The IP Interface Group will cause issues when there are the same names with different upper or lower cases Root Cause: The code reads the attribute value (ignoring case) and selecting the options. As a result, both values are marked selected and last selected option will be shown as selected in GUI. Steps to Replicate:
| The code is modified to ignore the case to exact match the value to select based on case sensitive. Workaround: No workaround. |
92 | SBX-104126 | SBX-107163 | 2 | Portfix SBX-104126: A re-INVITE when 200 OK with crypto line other than 1. Impact: When the SBC offers multiple crypto suite in an INVITE (offer) and the egress sends answer with crypto suite that is other than the top priority crypto offered by the SBC, the SBC sends an unnecessary re-INVITE to the egress when minimizeRelayingOfMediaChangesFromOtherCallLegAll flag is enabled. Root Cause: The SBC does not update the media subsystem structures correctly. Steps to Replicate: Configuration: minimizeRelayingOfMediaChangesFromOtherCallLegAll flag is enabled on ingress and egress TG. Without a fix, the SBC sends re-INVITE to egress. | The code is modified to ensure the SBC suppresses re-INVITE when egress answer has crypto which is not the top priority crypto as per Packet Service Profile configuration. Workaround: None. |
93 | SBX-107865 | 2 | The sendSbcSupportedCodecs flag not set when log level MAJOR. Impact: When the DBG log level is MAJOR, the IPSP flag configuration "Send SBC supported codecs in late media Reinvite" does not get applied when the SBC is processing the offer to send out to the first Invite without SDP received on ingress leg. As a result, all supported codecs on the ingress leg are not offered to ingress endpoint in 18x or 200OK for initial Invite without SDP if DBG log level is not INFO (or) TRC is disabled even if "Send SBC supported codecs in late media Reinvite" flag is enabled. Root Cause: The code to pass "Send SBC supported codecs in late media Reinvite" flag indication from IPSP extension for ingress leg to other modules was within a block meant for only Info/TRC level log analysis/display. Steps to Replicate:
| The code is modified so the "Send SBC supported codecs in late media Reinvite" flag indication is now copied independent of debug log level. Workaround: None. |
The following 08.02.04R000 Severity 1 issues are resolved in this release:
Resolved Issues
Issue ID | Sev | Problem Description | Resolution | |
---|---|---|---|---|
1 | SBX-105269 | 1 | The SBC crashed and a coredump occured. Impact: The SCM process coredumps due to NULL pointer access on a pointer that is freed due to BYE and HOLD race in a transfer call scenario. Root Cause: There was an illegal memory access, absence of NULL check, exposed due to race condition. Steps to Replicate: A calls B, B REFERs to C and now A and C talk. After sometime, A sends BYE and C sends re-INVITE with a=inactive at the same time. | The code is modified to address the issue. Workaround: No workaround. |
2 | SBX-101161 | 1 | A memory leak was observed in SAM process. Impact: A memory leak was observed in the SAM process. Root Cause: There is race condition in the code that handles CALL_AUDITs and CALL_CLEANUPs that can cause a memory leak. If the response to a CALL_AUDIT takes to long, the code that handles the "late" response has allocates memory for a structure that may never get freed. Steps to Replicate: This issue is caused by a race condition that cannot be forced and therefore we cannot specify steps to reproduce this issue. | The code is modified to add a timer every time a fault structure is allocated. When the timer expires, if the the structure still exists it is freed. Workaround: N/A |
3 | SBX-95983 | SBX-103364 | 1 | Portfix SBX-95983: The Customer SBC was seeing STEAL_WARNING: Impact: Getting a steal warning at login. Root Cause: The filtering criteria for a high steal value was not well defined. Steps to Replicate: The script runs as a cron job. This can also be manually tested by making changes in mpstat logs. | The code is modified to detect and warn about high %steal value. Workaround: N/A |
4 | SBX-103629 | SBX-103653 | 1 | Portfix SBX-103629: The SIP registrations are failing. The SBC was reporting REGISTER_PARSE_ERROR and replies with SIP 500 when it receives retransmitted initial REGISTER (CSEQ 1), followed by REGISTER with Authorization header (CSEQ 1). Impact: When the SBC recv rexmit of registration (cseq=1) after sending a 401/407, the SBC relays to the AS. At the same time, the IAD sends new registration(cseq=2) for authentication. It triggers a race condition to the SBC and response 500. Root Cause: The SBC should relay rexmit (cseq=1) registration to the application server. Steps to Replicate: The IAD send registration(cseq1) to AS, AS response 401 to IAD, IAD rexmit the same sceq1, and send a new sceq2 with auth header. | The code is modified to response rexmit request (cseq=1). As a result, a subsequent one cseq=2 can properly handle the relay to AS. Workaround: N/A |
5 | SBX-102625 | 1 | SIP calls stop when receiving a 183 (Precondition). Impact: A call stopped working after a 183 received without SDP. Root Cause: As part of egress precondition interworking, to negotiate the SBC should send an UPDATE to egress endpoint. When 183 received without SDP, the SBC should not try to send UPDATE. The SIPSG call state assumed an UPDATE is sent. As a result, when the next 183 is received it tried to queue the 183 assuming UPDATE is in progress. Steps to Replicate:
The above 183 is not processed due to bug in the code. As a result, retransmissions are observed. | The code is modified to avoid this state transition when 183 received without SDP. Workaround: Remove the 183 without SDP message using SMM. |
6 | SBX-102704 | 1 | Unable to add or Edit route with # in Destination National - CLI or EMA. Impact: User is not able to store some special characters for the destination number field in the route entity. Root Cause: The pattern defined for the destination number field did not allow all special characters. Steps to Replicate: Create a route with special character like #123 for the destination number field in the route entity. It should be successful after this fix. | The code is modified to allow all special characters in this field. Workaround: N/A |
7 | SBX-102833 | SBX-103697 | 1 | Portfix SBX-102833: MS Teams calls are dropping when placed on hold. Impact: When MS Teams puts a call on hold and then attempts to retrieve it while the microphone is disabled, this results in the call being cleared. Root Cause: MS Teams actions the call retrieve by sending an INVITE with replaces message to the SBC. When the microphone is disabled, this message includes a=recvonly. The SBC sends a 200 Ok response to the INVITE with replaces with a=sendrecv, while MS Teams is expecting a=sendonly. This causes MS Teams to clear the call. Steps to Replicate: 1. Establish a PSTN to MS Teams call through the SBC. | The code is modified to respond to an INVITE with replaces containing a=recvonly with 200 OK containing a=sendonly. Workaround: N/A |
8 | SBX-90251 | SBX-103362 | 1 | Portfix SBX-90251: An SM process healthcheck timeout occurred during a configuration restore on the Cloud SBC. Impact: The SM process crashes due to a healthcheck failure. Root Cause: As part of a load configuration, the configuration tar file needs to be untared. The untaring is taking longer than the healthcheck time out, when the size is big. Steps to Replicate:
| The code is modified for the running tar command so that the healthcheck does not fail during a load configuration. Workaround: Override the healthcheck for the tar command. |
9 | SBX-103207 | SBX-103579 | 1 | Portfix SBX-103207: The SBC SWe 8.2.0F1 duplicates audio from call B to call A. Impact: If CN is not negotiated for G711 codec and remote peer still sends CN packets that match default CN payload type (13), then user on other end may hear cross talk audio of completely unrelated channel or hear own reflect audio. Root Cause: When a g711 side does not negotiate CN in signaling, DSP does not initialize Comfort Noise Generation object. However, if remote peer still sends CN packet that matches the g711 SID payload type configured in PSP (default 13), DSP accepts the packet. It processes that CN packet incorrectly and as a result uses stale voice buffer which happens to be of another channel. This continues until next voice packet for that channel arrives. Hence, we happen to see cross talk audio from other call during silence period. In some cases, the user may hear own audio also and that is different manifestation of the same problem. This issue is specific to SWe. Steps to Replicate:
| The code is modified to initialize the comfort noise object even though CN is not negotiated and process the CN packets correctly. Workaround: There are multiple workarounds for this issue: 1. Change the default payload type of comfort noise from 13 to something else (say 15) in PSP of peer that is sending CN packets. This will make DSP drop CN packets because payload type will not match. Run the PSP configurationshow configuration profiles media packetServiceProfile G711_NONE_NONE_NONE..silenceInsertionDescriptor {g711SidRtpPayloadType 13;heartbeat enable;} 2. Enable the silence suppression on PSP of peer that is sending CN packets and keep CN payload type that matches with CN payload type. |
10 | SBX-94491 | 1 | It takes 7 seconds for the standby server to detect a switchover triggered by a reboot thus delaying to time to become active (OpenStack 1:1 HA). Impact: A switchover triggered by the reboot takes 7 seconds to be detected by the standby, increasing the switchover time and causing media takeover issues. Root Cause: The transport protocol is responsible for noticing the peer has gone away, and with the UDP protocol used for SWe, this process takes too long. Steps to Replicate:This does not explain the steps to take to replicate the issue. | The code is modified to alert the peer to take over rather than relying on the transport protocol health check to timeout. Workaround: None. |
11 | SBX-101628 | SBX-102709 | 1 | Portfix SBX-101628: The CPX process leaks memory for a call load. Impact: There was a memory leak in MsgClient message queue. Root Cause: The dispatcherAgent's MsgClient was not instantiated properly, causing messages to be queued and never deleted. Steps to Replicate: Perform traffic test with ASAN load to confirm that memory leak is no longer present. | Instantiate DispatcherAgent's MsgClient properly and to not use the message queue. Run a clear message queue in destructor of MsgClient to address the issue. Workaround: None. |
12 | SBX-102737 | SBX-103483 | 1 | Portfix SBX-102737: The SM Process experiences a core dump on both the active and standby after an sbxrestart. Impact: The SM Process cores at startup due to healthcheck. Root Cause: System_i::fillSavedConfigurations is trying to read /mnt/gfsvol1/config-versions.txt, but it is taking too long. Steps to Replicate:
| Pause healthcheck in System_i::fillSavedConfigurations to address the issue. Workaround: Reboot the failing node. |
13 | SBX-91476 | SBX-99700 | 1 | Portfix SBX-91476: The PEM header contains a gated parameter. Impact: The SBC is sending a gated parameter in the PEM sendrecv toward the Ingress Root Cause: By design if the Early Media is gated by a peer or gated locally, the SBC adds the gated parameter towards the Ingress. Steps to Replicate:
| A new flag "suppressGatedParam" is added at the TG level. set addressContext default zone <ZONE_INGRESS> sipTrunkGroup <TG_INGRESS>media earlyMedia suppressGatedParam <enabled/disabled> Workaround: N/A |
14 | SBX-103948 | SBX-103976 | 1 | Portfix SBX-103948: The SBC Application is crashing when a CPaaS to PSTN call is made. Impact: After a reboot/restart, the CPX process could not read the sdpContent values from "action/from" and "action/to" SMM definitions, as a result while applying the action during a call it does not find the sdpContent and causes a core to happen due to processing a null or incorrect value. Root Cause: After a reboot/restart, the CPX process is unable to read/action/from/sdpContent and /action/to/sdpContent due to wrong path/invalid pointer. Steps to Replicate: Configure the SMM rules to delete the SDP line and generate traffic to confirm it works correctly. | The code is modified to read and store the from/sdpContent and to/sdpContent correctly in the SCM Process cache. Workaround: Disable the SMM that deletes the SDP. |
15 | SBX-101765 | SBX-102294 | 1 | Portfix SBX-101765: The SBC is going down when running NNIProfile CLI Impact: When the application code was reading the NNI profile from CDB, there was a memory overwrite problem. Root Cause: The local variables that were used to store the information being read from the CDB were not large enough resulting in memory being overwritten. Steps to Replicate: Replicate in lab environment only. | The code is modified to use large local variables to avoid the memory overwrite. Workaround: None. |
16 | SBX-102837 | 1 | The SipSignalingPorts OutOfService after switchover. Impact: The SIP sigPorts stuck in OOS after a switchover. Root Cause: Customer had the network/pkt port issue, on one of their HA node, which caused pkt port(s) to bounce randomly, i.e. pkt port went DOWN and came back UP within 2 to 3 seconds. So they have been keeping that node as standby node. They also have link detection enabled for pkt port(s) and have around 100 LIFs per pkt port, one per SIP SIGPORT. When pkt port went down, NRS delays the port down event processing for 2 second to allow link failure detection to be ready and also to avoid the race condition between NRS and LVM. When 2 second delay timer is up, NRS starts to take down affected LIFs and notifies local SIPCM and SIPFE so they can take down affected SIP SIGPORTs. In SIPCM, all the sockets on the affected sigPort are put in a delete pending table and starts a 1 tick timer. Then the socket(s) is being deleted after 1 tick timer is up. Steps to Replicate: The nature of the problem was the timing caused race condition. There is no good way to re-create/verify the fixes. | The code is modified in the following manner:
Workaround: None. |
17 | SBX-101922 | SBX-103370 | 1 | Portfix SBX-101922: GUI CDR Configuration screen - Syslog server field can not be configured. Impact: The server section is appearing on the CDR configuration, but the configuration does not participate in configuration. Root Cause: The child object was added. As default behavior of the EMA, the added child object was not needed. Steps to Replicate: Log in to the EMA and configure the CDR and ensure the Syslog configuration is not listed on the CDR configuration page. | Restricted the child object in this particular case to address the issue. Workaround: None. |
18 | SBX-104015 | 1 | The RE-REGISTAR was shorter than 3600 secs due to a child AoR. Impact: When the 200 OK response to REGISTER request contains a P-Associated-URI header, the SBC creates a child AOR and forwards all REGISTER refresh requests to the registrar (effectively disabling the SBC fast refresh response). Root Cause: The creation of child AORs cause all REGISTER refresh requests to be sent to the registrar (effectively disabling the SBC fast refresh response). Steps to Replicate:
| Removed the child AOR check from SipRaRegisterRequestCompletedAorNfy(), permitting the SBC to send fast refresh responses. Workaround: N/A |
19 | SBX-103645 | SBX-104187 | 1 | Portfix SBX-103645: There was a a customer 81.R5 upgrade with a spiltbrain M-SBC boot issue. Impact: One of the M-SBCs in N:1 mode is not coming up after an upgrade. Root Cause: The M-SBC node went for multiple reboots due to a configuration profile change and split brains after an upgrade exceeding the max limit for reboot. Steps to Replicate: Upgrade all M-SBC nodes at one time so that they all come up together. | The code is modified to avoid split brain due to nodeId/serviceId collision by informing the peer nodes about the self node's nodeId/serviceid as soon as it is allocated. Workaround: Restart the M-SBC application manually on the node that has exceeded max reboot limit. |
20 | SBX-98243 | SBX-99702 | 1 | Portfix SBX-98243: The SIPREC Status command is not showing all four SRS servers after upgrade completes Impact: The SIPREC status does not correctly display all SIPREC servers if the SBC does a SYNC on an HA set up when more than one SIPREC recording is active. The SYNC occurs when the standby box is restarted while the active remains up. This is not an issue if a new SIPREC call is started while the HA set up is already running in active/standby mode. This problem only impacts the status screen and not the processing of the SIPREC call. Root Cause: After a SYNC, only one SIPREC entry is maintained in the SIPREC status on the standby server. So if a switchover then occurs, the status screen only shows one active call, although all the other active SIPREC calls are maintained correctly. Steps to Replicate:
| The code is modified to maintain the status information of all the SIPREC calls from the active server. Workaround: Do not restart the standby server while there are SIPREC calls running on the active server. |
21 | SBX-104484 | 1 | The SBC is rejecting the second Update message from the Egress as a 500 result into a call failure. Impact: The SBC rejects the second Update from the egress due to a DLRB feature. Root Cause: The First Update SIPS response locally 200OK but not clear the server request message. As a result, the second Update triggers a SIPS answer 500. Steps to Replicate: Configure the DLRB, the Egress response 183 with the SDP, the first Update, and the second Update. | The code is modified so after a response 200OK, the SIPS clears the server request so it handles the subsequent one. Workaround: Disable the DLRB. |
22 | SBX-101155 | 1 | A DSP core occurred on the SBC. Impact: The DSP faults with a memory fault in area that pulls buffers out of EMAC port. Suspicion is on the buffer size that is reported by EMAC buffer. These errors result in a DSP reload which is essentially ensures call continuation. Any calls which are using this DSP could have a small media outage while the DSP is reloaded. Root Cause: The root cause is a speculation that the EMAC system is occasionally is a incorrect bufSize, similar to a bit flip. Steps to Replicate: This issue cannot be reproduced, it is fixed based on code review and coredump backtrace. | The code is modified to look for consistency in packet size and EMAC buffer size reported. In case an inconsistency is found, the packet is rejected, avoiding illegal memory access. Workaround: None. |
23 | SBX-101394 | SBX-103365 | 1 | Portfix SBX-101394: The SBC restarts after receiving 3xx with the embedded Identity in Contact header. Impact: Global-buffer-overflow error when the SBC received a 3xx with the Identity header embedded in the contact header. Root Cause: The root cause here is that the number of elements in pstKnownTypes array are less than the length on that the loop was running on. Steps to Replicate:
Honor Embedded Headers and Enhanced Local redirection flag are enabled in the egress TG's IPSP. | The code is modified to use the actual length of pstKnowTypes array rather than using the SIP_HEADER_MAX. Calling the SipHdrTranspGetNumKnownTypes() function returns the actual number of elements in pstKnownTypes array. Workaround: None. |
24 | SBX-99134 | SBX-100038 | 1 | Portfix SBX-99134: There was a SCM process coredump after a second switchover while establishing the SIP-GW-H323 call load. Impact: During a switchover and switchback while running a load, there may be some stale entries in the SIPSG and CC control blocks. Such entries are cleared on an audit but while clearing, the SIPSG is sending CC_SG_UPD_ACCT_NFY_MSG_STR to the CC. Since the load is running a corresponding entry for the CC, the index may be allocated to a new call. As a result, the msgPtr-> gcid is not matching with the ccbPtr->gcid and the gcid stored in the SIPSG. When the CC receives this message, the mismatch happens and it logs a SYS_ERR(SE_EVLOG, SE_CC_UNEXPECTED_DATA)) Root Cause: While performing a switchover during a high load run, the SBC should be run in normal mode instead of sensitive mode. Steps to Replicate: In this scenario, the HA pair and a standalone SBC are used.
| The code is modified to not use a sys error if the GCID sent from the SIPSG in a msgPtr is different from the GCID in the ccbPtr during a switchover. Workaround: N/A |
25 | SBX-99600 | SBX-100025 | 1 | Portfix SBX-99600: After a switchover on SBC 5400 platform, the SCM process is coredumping, due to hitting a SYS_ERR while running in sensitive mode. Impact: When performing a switchover and switchback while running a load, there may be some stale entries in SIPSG and CC control blocks. Such entries are cleared during an audit, but while clearing these entries, the CC is sending SG_CC_DISC_RSP_MSG to SIPSG. Since the load is running a corresponding entry of the CC , the index might be allocated to a new call. As a result of this issue, the msgPtr-> gcid is not matching with the ccbPtr->gcid in SIPSG. When the CC receives a message, the mismatch happens and the CC logs the SYS_ERR(SE_EVLOG, SE_CC_UNEXPECTED_DATA)) Root Cause: While performing a switchover during a high load run, the SBC should be run in normal mode instead of a sensitive mode. Steps to Replicate:
Observed SCM process coredump should not be seen. | If the GCID sent from the CCin msgPtr is different from the GCID in ccbPtr during the case of a switchover, do not use a sys error to address the issue. Workaround: N/A |
26 | SBX-102472 | SBX-103374 | 1 | Portfix SBX-102472: ImPr Process core dumped for Default LI with IPSEC. Impact: When a call is intercepted during switchover, the SBC throws SYS error SE_SYS_HASH_EXISTS and causes coredump. Root Cause: If a call is intercepted during switchover, the standby SBC may have the duplicate info of the intercepted call. So it throws SYS error "SE_SYS_HASH_EXISTS" Steps to Replicate:
| The fix is given to handle the duplicate call data of the intercepted call on the Standby SBC. Workaround: Disable the coredump level. |
27 | SBX-97424 | SBX-99678 | 1 | Portfix SBX-97424: The SCM process core observed in the M-SBC after a switchover with the SIPREC. Impact: The SCM Process coredump is observed in the M-SBC after a switchover when the SIPRec occurred with a stable call and BYE for the main call is triggered post switch-over. Root Cause: The recorderType field (field describing the type of recording happening in the SBC) is not mirrored. Post switch-over once the main call is terminated, the SIPREC delete command goes from an S node to M node but this does not carry the recorderType field. When the command reaches M node from S node with recorderType set to zero, the M node accesses a NULL pointer (call data channel). Steps to Replicate:
| Send a recorderType for all type of monitor commands. Add a Call Data Channel NULL check in the M node while processing a MonitorCommands. Workaround: N/A |
28 | SBX-101451 | 1 | The DSP Threshold setting is not generating a trap on SBC 5400. Impact: The g711PacketThreshold, g729Threshold, and g726Threshold onset and abate traps are not sent. Root Cause: The NRM did not receive CLI updates to the g711PacketThreshold, g729Threshold, and g726Threshold, and the trap generation code used wrong trap names. Steps to Replicate:
| The code is modified to support g711PacketThreshold, g729Threshold, and g726Threshold values. Deprecated the support for allThreshold, as it was never implemented in the SBC. Workaround: N/A |
29 | SBX-103254 | SBX-104774 | 1 | Portfix SBX-103254: The SBC SWe experiences a call set up delay when all remote IP PEERS are provisioned with SIP OPTION Ping. Impact: The configuration support disables the Path MTU Discovery by setting kernel parameter net.ipv4.ip_no_pmtu_disc (ipNoPmtuDisc). When the ipNoPmtuDisc is set to 2, the DF bit in IP packet header will be set 0. Root Cause: The secure network does not support Path MTU Discovery per RFC-1191. Steps to Replicate: Testing the Standalone SBC SWe: | The code is modified to disable the Path MTU Discovery by setting kernel parameter net.ipv4.ip_no_pmtu_disc to 2. When set to 2, the DF bit is set to 0 for the transmitted packets on every created socket. The configuration parameter is "system admin <name of system> kernelParams ipNoPmtuDisc". Workaround: The workaround is a hack. It can be used as a one time test only. The hack will not survive Linux reboots. |
30 | SBX-96239 | 1 | The display-name in the Diversion header or History-info header is deleted during interworking. Impact: The SBC does not send display name present in ingress INVITE's diversion header in history info header in egress INVITE. The SBC does not send display name present in ingress INVITE's history info header in egress INVITE's diversion header. Root Cause: The SBC does not consider display name when interworking between the diversion header and history info header. Steps to Replicate:
| The code is modified to ensure the display name is sent when the SBC is interworking history info and diversion header. Workaround: None. |
31 | SBX-103492 | SBX-103585 | 1 | Portfix SBX-103492: Performance: Observed "Scm" Process core on standby box while running the load on Openstack ISBC HA. Impact: The SCM process cores after a switchover on Standby (new active) node when running the TCP-TCP load at 100 CPS with 10 secs call hold time. Root Cause: The issue is due to not setting the "prtSigZoneEntry->nextMnsPortPtr" when the SIP signaling port is removed. Steps to Replicate: Perform switchover when running TCP-TCP load at 100 CPS with 10 secs CHT. | The code is modified so whenever the SIP signaling port is removed, set the prtSigZoneEntry->nextMnsPortPtr to NULL. Workaround: None. |
32 | SBX-104494 | SBX-104724 | 1 | Portfix SBX-104494: The PES process cored while testing the Flex AD support with ERE. Impact: The PES process dumps core while executing an Active Directory (AD) service when no AD profile and/or AD attribute profile configured. Root Cause: While executing the AD service, PES fetches the AD profile from cache. Since there is no AD profile was configured in this case, cache shall return NULL. The code was missing to check for NULL for the AD profile pointer and dereferencing the NULL pointer results in a coredump. Steps to Replicate: Configure a AD number translation criteria with ingress TG as the trigger criteria type, but with no AD profile and/or AD attribute profile configured. Make a call on the ingress TG. | The code is modified to check for NULL for an AD profile and AD attribute profile. If there is no profiles configured, the control returns and the service is marked as failed. Workaround: Configure an AD Profile and AD attribute profile so that the existing code can be executed further. |
33 | SBX-104773 | SBX-104800 | 1 | Portfix SBX-104773: The SBC is not coming up on the VMWare when using two NUMAs. Impact: The SBC fails to come up in the VMWare dual NUMA configuration. (cps service failed to come up) Root Cause: As part of the CPS service, there is one init script that calculates the performance indices. In the VMWare dual NUMA scenario, the index calculator binary gets launched in the last core, which happens to be on the 2nd NUMA. Since the huge pages are reserved on NUMA0, so the index calculator binary fails (saying fails to create mbuf pool). As a result, the CPS fails to come up. Steps to Replicate:
| The code is modified to always launch on the second core, to ensure the NUMA0 is always used. Workaround: None. |
34 | SBX-104761 | 1 | SM Process core on the Server. Impact: The SM Process crashed while executing the "show table system syncStatus" command. Root Cause: The shell script used to get the Oracle sync status - PolicyDBSyncStatus.sh - did not return within 10 seconds, causing a healthcheck timeout that caused the coredump. Steps to Replicate: This problem is not reproducible. | Disable healthchecks while fetching the syncStatus to address the issue. Workaround: None. |
35 | SBX-95982 | 1 | The SBC running version 6.2.2 cannot capture the media with MCT. Impact: The MCT reload configuration (SBC restart or switchover) will not succeed. Root Cause: Logic was missing during the restart in order to properly reload the MCT configuration. Steps to Replicate: The steps are not easily producible. | The code is modified to properly reload the MCT configuration. Workaround: User can delete the MCT config and reconfigure it after any restart/switchover. |
36 | SBX-91162 | 1 | The PRS process cored, backtrace shows the PrsNpCoreStatusProc(), and the XSC core is spinning. Impact: Only one customer reported this peculiar issue where the Network Processor (NP) hangs due to an interrupt generated by the internal hardware module because a zero length packet request was sent. Root Cause: We were never able to find anything in the code that would send a packet with zero length. Steps to Replicate: You really cannot test this change without damaging the Network Processor. | The code is modified to log the event and not submit the zero length packet to the hardware module. The added code also handles the interrupt and continue running. Workaround: None. |
37 | SBX-104443 | 1 | The SM process and CPX cores prevented the server to come back up as standby after switchover. Impact: The SM process and CPX processes cored on slot 1 after LDG triggered switchover to slot 2. Root Cause: The root cause was SM process deadlock. Steps to Replicate: This is time sensitive issue. I do not have steps to re-produce or verify the fix. | The code is modified to release the smNtpLock_ after issued NTP restart command. Workaround: None. |
38 | SBX-104769 | SBX-105081 | 1 | Portfix SBX-104769: The SCM process cored while testing the SBX H323 Conformance and Interworking. Impact: The SCM process will core for the RFC 2833 to Inband DTMF in SIP to H323 interworking call scenario. Root Cause: Accessing of a NULL pointer caused the core dump. Steps to Replicate: Run a SIP-H323 interworking call with SIP side rfc2833 and the H323 side Inband DTMF being enabled. | The code is modified to check the NULL pointer before accessing it. Workaround: None. |
39 | SBX-105156 | 1 | The SBC was sending m=application 0 UDP/BFCP (null). Impact: The SBC generates the syntax error m-line UDP/BFCP in 183. Root Cause: The SBC accesses initializes data when the format m-line for UDP/BFCP. Steps to Replicate: An incoming call with the m-line UDP/BFCP. ERE/PSX using script NO_ROUTE and triggers an announcement. The internal 183 has m-line UDP/BFCP with invalid syntax. | Make m-line initialize properly to address the issue. Workaround: Use the SMM to correct m-line syntax error |
40 | SBX-105019 | 1 | Crosstalk issue on the SBC 5400. Impact: When a transcoded call with Opus codec and the Opus termination does not send any packets to the SBC, then another termination of Opus call may hear the audio from another unrelated Opus-transcoded call or it may hear white noise. This occurs on the SBC5x10/5400/7K but not on the SWe platforms. This problem only occurs if no Opus packet is received. When the decoder receives the first Opus packet, then subsequently the problem does not happen for that call. Root Cause: Initially, when no packet is received, the Opus decoder is not called. As a result the decoder's output buffer is uninitialized and it happened to be a stale buffer of another Opus call or a leftover buffer of a previous Opus call on that DSP. That buffer is used to encode data for other leg of the Opus call and that results in cross talk audio or distorted noise to other termination of Opus call. Steps to Replicate:
| Clear the buffer (with silence) when the Opus decoder is not primed with any packet to address the issue. Workaround:
|
41 | SBX-104802 | 1 | Enabling the Dialog Transparency causes calls to fail. Impact: A call fails for dialog transparency and forking. Root Cause: When the ingress support prack and multiple 18x fork, the SBC fails to send 200OK to ingress. Steps to Replicate:
| The code is modified to address the issue. Workaround: Disable the dialog transparency. |
42 | SBX-103553 | SBX-105158 | 1 | Portfix SBX-103553: The SBC does not allow multiple 183. Impact: A GSX-GW-SBX call erroneously queues a 183 message on the SBC when the X-Service-Type precondition is received and the downstream forking is enabled. Root Cause: The interaction between the downstream forking and GW-GW code. Steps to Replicate:
| The code is modified to not perform queueing in GW-GW scenarios. Workaround: None. |
43 | SBX-105351 | 1 | The SCM process cored. Impact: The SCM process cores after long extensive load of an OOD relay. Root Cause: The SBC accesses an invalid pointer of link list when the cleanup relay control block. Steps to Replicate: The issue is not easily reproducible. | The code is modified to properly initialize the link list. Workaround: None. |
44 | SBX-104934 | SBX-105254 | 1 | Portfix SBX-104934: The SBC generates the same ICID for more than 1 call, porting the fix for SBX-101887 into 8.2.3F1 did not help. Impact: Duplicate the ICID generated for two different calls. Root Cause: The instance specific value is set to 0 every other call causing the ICID generation to always use 0 in all instances. This results in the same ICID generated in more than one SCM instance when the calls land within the same microsecond. Steps to Replicate: Configure the SBC to generate ICID on the egress side. Run a call load and check for duplicate ICIDs. | The code is modified to manipulate the last octet of the MAC address used in ICID generation. Workaround: None. |
45 | SBX-104688 | SBX-105390 | 1 | Portfix SBX-104688: There was a configuration import issue. Impact: The fields that support \r like regex fields, changes it to \n after configuration Import (XML based). Root Cause: The \r is not xml encoded when parsing the intermediate xml file. Steps to Replicate:
| The code is modified to handle the \r as a special case. Workaround: None. |
46 | SBX-105410 | 1 | The SBC does not select DNS servers in the correct ratio when all weights are set to a value of 1 or 100. Impact: When multiple DNS Server in a DNS Group are configured with weight = 1 then one of the DNS Sever does not get any traffic. Root Cause: Off by one error in handling of DNS load distribution logic. Steps to Replicate:
If the weight = 1 for all the server SBC does not do a hard round robin for load balancing. The load balancing depends on the random value generated but it is expected that for a large number of samples the load will be almost evenly distributed between the servers. | The code is modified to handle this scenario. Workaround: Avoid configuring DNS servers with weight = 1 and recommended to use higher weight values as workaround. |
47 | SBX-103881 | 1 | The Qseries CDR field not matching Qseries format. Impact: When the rn parameter is received as part of SIP R-URI, this value is being used to populate field 10 of the QSBC format CDR record, rather than the received Called Number Root Cause: In case of rn parameter received, the source for field 10 of QSBC CDR is incorrect. Steps to Replicate: Send a SIP INVITE with R-URI including rn parameter. | The code is modified so if the rn is received, field 10 of QSBC is populated with the "Called Number Before Translation" (field 24 of Ribbon format CDR). For other scenarios, field 10 is populated as before. Workaround: None. |
48 | SBX-105241 | 1 | The SCM Process core dumped in the SIGABRT. Impact: The SCM has cored due to a memory corruption issue. Root Cause: The SCM core is the result of a memory corruption caused by a function that is overwriting the end of the buffer that it allocated. Steps to Replicate: This issue is not reproducible. | The code is modified to prevent the function from overwriting the end of the buffer it allocated. Workaround: N/A |
49 | SBX-102082 | SBX-105556 | 1 | Portfix SBX-102082: An SCM coredump observed when the REGISTER is received and the useRandomUserInfoInContactHdr is enabled. Impact: There was an invalid memory access issue when both embeddedRegInfoinUserPart and useRandomUserInfoInContactHdr flag were enabled. Root Cause: In the SBC appropriate memory was not allocated for the contactUrl puchUsername in case both embeddedRegInfoinUserPart and useRandomUserInfoInContactHdr flag were enabled, due to this invalid memory access was happening. Steps to Replicate:
| The code is modified to allocate the appropriate memory for puchUsername based on embeddedRegInfoinUserPart or useRandomUserInfoInContactHdr enable case. Workaround: As per the SBC design anyone of the below flags should be enable not both. |
50 | SBX-105888 | 1 | The SBC is sending the wrong TO tag to the AS side. Impact: The response 200OK for multiple Notify's has an invalid ToTag. Root Cause: There was an internal logical error when processing the second 200OK Notify from AS. The application had a misinterpretation of the direction for the relay message as an IAD and through passing down the wrong data down to SIPS for relaying 200OK to AS. Steps to Replicate: Subscribe the IAD to AS. The AS sends multiple Notify immediately one after another. | The code is modified so that the SBC passes the correct data down to SIPS. Workaround: The peer can send 1 Notify at a time. N/A on the SBC. |
51 | SBX-105989 | 1 | After a cleanDb, a user is unable to login to the KVM SBC as an admin user using keys. Impact: The datasourceList was set to 'None' for KVM platform. After running the clearDB, the cloud-init was not having any datasource to read the ssh keys. Root Cause: The change introduced as part of Jira SBX-88682 caused this issue. Steps to Replicate: Instantiate VM on KVM with ssh keys configured for access to linuxadmin and admin. Perform clearDB and try to login with in ssh keys to admin and linuxadmin. | The code is modified to use 'NoCloud' Data source to address the issue. Workaround: Remove '/etc/cloud/cloud.cfg.d/99-datasource.cfg' file before doing clearDB. |
52 | SBX-105917 | 1 | The SBC fails to relay 4xx-6xx responses when IPTG authentication is enabled after 100 trying Impact: When IPTG authentication is enabled, the SBC maps all 4xx-6xx SIP codes to CPC 176. As a result, the SBC is unable to relay cause code from egress to ingress endpoint. Example: 486 Busy Cause code was not relayed to ingress side. Root Cause: When IPTG authentication is enabled, the SBC maps all 4xx-6xx SIP codes to CPC 176. Steps to Replicate:
| The code is modified so the SBC, upon receipt of error code other than 401 and 407 clears the authentication flag and relays the actual cause code from egress to ingress Workaround: Use CPC mapping to map CPC code 176 to required SIP cause code. |
53 | SBX-106178 | 1 | There was a switchover // sonusCpSystemProcessCoredumpGeneratedNotification. Impact: The SCM process has cored. Root Cause: The SCM has cored when attempting to write a log message because the code is attempting to de-reference a NULL pointer to access information for the log message. Steps to Replicate: There are no specific steps for reproducing this issue. This core will only happen in a multi-transfer scenario. | The code is modified to check that the pointer is non-NULL before de-referencing it. Workaround: There is no workaround. This core will only happen in a multi-transfer scenario. |
54 | SBX-106476 | 1 | The ipAdaptiveTaransparencyProfile is not working for a re-INVITE coming from the Egress. Impact: When the sipAdaptiveTransparencyProfile is configured for the Egress TG and a re-INVITE comes from egress peer with change in the P-ASSERTED-ID, the SBC does not relay the INVITE from the egress to ingress. Root Cause: The SBC code does not set the service bit for re-INVITE transparency for re-INVITEs coming from egress peer. Steps to Replicate: Test case 1:
| The code is modified to ensure the SBC sets the service bit properly when a sipAdaptiveTransparencyProfile is configured for egress TG. Workaround: None |
55 | SBX-105276 | 1 | Filtering does not work on the Cleared Alarm List. Impact: Filtering does not work on the Cleared Alarm List. Root Cause: There is an order mismatch before applying the time filter and after applying the filter. Steps to Replicate:
| The code is modified to address the issue. Workaround: None. |
56 | SBX-103974 | SBX-104212 | 1 | Portfix SBX-103974: The STI sends 2 Identity fields in Contact header, but SBC only passes one Impact: In the case where multiple "Identity Headers" are present as embedded headers in a 3xx "Contact Header", the SBC sends out only 1 Identity Header for the re-directed INVITE. Root Cause: The SBC did not support handling of the scenario where SIP headers are repeated in embedded contact headers in 3xx. The SBC would end up the sending only the last of the repeated headers in the re-directed Invite. Steps to Replicate:
| The code is modified to support repeated SIP headers. Workaround: None. |
57 | SBX-106224 | 1 | The customer SBC failover with SCM Process core due to Memory corruption. Impact: When prack enable on ingress and advanced SMM for "variableScopeValue message" enable, the SBC may core when Egress responses 18x/2xx too fast trigger delay on ingress due to prack pending. Root Cause: On ingress when 18x/2xx is queuing, it did not allocate proper resources for "variableScope" data. By the time it start to send out, the SBC access garbage data. Steps to Replicate: This is random issue so may/may not reproducible. | Properly allocated resource for "variableScope" data to address the issue. Workaround: Disable prack. |
58 | SBX-105961 | 1 | The SBC reinvite with sendonly causing one-way audio. Impact: The SBC unexpectedly send out reInvite sendonly when relay DPM is disabled. Root Cause: There was an internal logical error to queue the sdp on ingress when egress send 18x (sendonly) Steps to Replicate:
| The code is modified so when subsequent 183 (sendonly) received on egress, the SBC updates the queue sdp (recvonly). Since the relay DPM is disable, the SBC should not change the direction of datapath on ingress. Workaround: n/a. This is application bug per rfc, and the SDP should not change in subsequent 18x. |
59 | SBX-106478 | 1 | A SAM Process core dump was seen while executing OCSP stapling feature. Impact: The SAM Process cores randomly when running a TLS call with the OCSP Stapling enabled. Root Cause: Periodically, the SIPCM finds socketPtr to be NULL that is causing an invalid access of a NULL pointer. Steps to Replicate: Running a TLS call with OCSP Stapling enabled. | The code is modified to check a NULL for the socketPtr. Workaround: When the OCSP Stapling is disabled, the SAM process does not core. |
60 | SBX-100237 | SBX-103482 | 1 | Portfix SBX-100237: The CpxApp process is dumping the core on the managed node when callMediaStatus CLI is run from OAM node. Impact: There was a CpxAppProc core when accessing the callMediaStatus of managed VMs from OAM through the node branch. Root Cause: There was a data serialization bug that caused the issue. Steps to Replicate: Access the callMediaStatus of managed VM from OAM through node branch. | The code is modified to address the core issue. Workaround: None. |
61 | SBX-101407 | SBX-103481 | 1 | Portfix SBX-101407: The CpxApp process is dumping the core on the managed node when we get the NTP from OAM node. Impact: The CpxProcess cores on an application shutdown. Root Cause: There was an improper ConfdProxy object destruction. Steps to Replicate: Stop the application while the traffic load is running is best to reproduce. | The code is modified to properly delete the ConfdProxy object. Workaround: None. |
62 | SBX-104015 | SBX-104275 | 1 | Portfix SBX-104015: The RE-REGISTAR was shorter than 3600 secs due to the child AoR. There needs to be more detail about this behavior. Impact: When the 200 OK response to REGISTER request contains a P-Associated-URI Root Cause: The creation of child AORs cause all REGISTER refresh requests to be sent to the registrar (effectively disabling SBC fast refresh response). Steps to Replicate:
| Removed the child AOR check from SipRaRegisterRequestCompletedAorNfy(), permitting the SBC to send a fast refresh responses. Workaround: None. |
The following 08.02.04R000 Severity 2-4 issues were resolved in this release:
Resolved Issues
Issue ID | Sev | Problem Description | Resolution |
---|---|---|---|
SBX-92114 | 3 | Calculated the size of a buffer as too small and error logs were being generated post upgrade. Impact: Removes this incorrect log message: SipsRedGetCallControlSizeCmd() Root Cause: This message is logged incorrectly when the code is calculating the size for a Redundancy message. Steps to Replicate: The steps cannot be replicated. | The code is modified to remove this incorrect log message: SipsRedGetCallControlSizeCmd() Workaround: N/A |
SBX-102629 | 2 | PRS process memory leak for object based messages. Impact: There was a slow memory leak in PRS. Root Cause: Object based messages are not properly being deallocated. This leaked both fm fault notifications and fp stats request messages. Steps to Replicate: Overtime watch PRS memory size increase. | The code is modified to properly free the messages. Workaround: No workaround. |
SBX-102115 | 2 | The SBC modifies the Replaces parameter with the wrong Call-ID and tags if the Replaced call was looped back to the SBC through a SIP Proxy that does not modify SIP Call-ID and tags. Impact: Relay a refer with replaces for loopback call, the SBC picks up the wrong call leg. Root Cause: The SBC query for the replaces callId, and found matching both legs (loopback).The SBC pick up the wrong leg. Steps to Replicate: This is specific to customer call flow. | If loopback is detected, only pick the one with to-tag match local-tag. This is per RFC-3891, section 3. Workaround: N/A |
SBX-103281 | 2 | The Route data lost after the offline PM upgrade from 625R0 to 823A13. Impact: The special character data was not getting migrated to postgres version. Root Cause: The special character was causing issues with the Postgres data loading. Steps to Replicate:
| The code is modified to escape the special characters. Workaround: No workaround. |
SBX-100910 | SBX-103367 | 2 | Portfix SBX-100910: A CE_2N_Comp_CcsP coredump is seen in SWE after disabling the interface. Impact: A CCS Process coredump was observed due to a healthcheck failure. This occurred while the software was establishing a connection to the third-party software serf, which it starts up to detect and communicate with other nodes in the cluster. Root Cause: The healthcheck failure occurs when a software object does not respond quickly enough to a health check message. This occurs because the software was waiting for serf to finish starting up and did not respond to the message in time. Steps to Replicate: Stop/start the SBC with the networking down or disable/enable the interfaces on a running system. These steps will trigger the code to start up serf and reconnect to it. | The code is modified to introduce a new timer for when the serf is started up, to allow the software to remain responsive to other messages. As an added precaution, healthchecks are temporarily disabled while connecting to serf, to avoid any chance of a healthcheck failure. Workaround: N/A |
SBX-101803 | SBX-103382 | 2 | Portfix SBX-101803: The SBC is not sending a 400 Bad request for the From tag length more than 272. Impact: The SBC is not sending a 400 Bad request when the From tag has length more than 272, though the logs show 095 07132020 161318.327763:1.01.00.45444.Info .SIPCM: *SipsParseMessage: from tag too long. Root Cause: As part of SBX-89384 fix, the SipCmSendIncomingPduUind is modified to add a dscpValue. But in the case of a SIP parse failure, while calling the SipCmSendIncomingPduUind in SipCmProcessRemotePdu, the DSCP value is wrongly placed in the position of receiveFlags. The receiveFlags is setting the value of the DSCP, which is 46, enables the SIP_AKA_SECURITY_ENABLED and the value of receiveFlags is wrongly given to the cmFeFlags. As a result, the flag is set and it is dropping the pdu before sending 400. Steps to Replicate:
| The code is modified to correct the position of a DSCP value while calling the SipCmSendIncomingPduUind in SipCmProcessRemotePdu. Workaround: N/A |
SBX-103560 | 2 | There was a content type pattern match failure in an INVITE sent to the second SBC in a GW GW call. Impact: The message body is not sent transparently for the Resource/Lists, QSIG Content-Type: multipart/mixed when the HTP is enabled for all. Root Cause: A fix to SBX-100989 jira broke the existing functionality and caused this issue. Steps to Replicate: TEST SET UP ===========UAC ==> SBC5xx0 --SBX 5xx0 ==> UAS Prerequisite:
Test Specific Configuration:
Test Steps:
Expected Results:
| The code is modified for the Allow message body QSIG Content-Type: multipart/mixed, Resource/Lists across GW-GW. Workaround: N/A |
SBX-103098 | 2 | The To tag in To header is corrupted when the SBC forwards the OOD Message. Impact: The To Tag in OOD messages from the registered users are getting corrupted when relayed. Root Cause: This is because of a logic issue in the stack function. Steps to Replicate: 1. Register an End Point. | The code is modified in stack function and also rejected the OOD messages from the Registered users with "To Tag", similar to SBX-76003 that was done as part of recent customer requirement. Workaround: No workaround. |
SBX-102992 | SBX-103001 | 2 | The SBC is blacklisting a peer when the mid dialog request gets timed out even though "midDialogArsScreenLevel" flag is set to "never" in sipArsProfile. Impact: The SBC is blacklisting peer when a mid dialog request gets timed out even though the midDialogArsScreenLevel flag is set to never in sipArsProfile. Root Cause: The original design only covered original INVITE messages and not mid-call INVITE messages. Steps to Replicate: 1. Make a call from UAC. | The code is modified to correctly handle mid-dialogue INVITE's as well as original INVITEs. Workaround: None. |
SBX-85825 | SBX-103389 | 2 | Portfix SBX-85825: The SBC Application fails with LCA errors on an initial EMS Cluster Configuration push. Impact: There was a packet drop between the SBC and EMS while downloading the configuration. Root Cause: Due to small fill rate and bucket size, traffic between the SBC and EMS is flow controlled. Steps to Replicate: Reboot the SBC so that it registers with the EMS and download the configuration from EMS. Capture the packets between the two to ensure that there is no drop. | Increased the fill rate and bucket size to accommodate large configuration size (~40MB). Workaround: N/A |
SBX-102401 | SBX-103426 | 3 | Porfix SBX-102401: The encryptedStore confd_cmd GET operations taking too much time during switchover (Nto1). Impact: The encryptedStore confd_cmd GET operations were taking too much time during a switchover (Nto1) Root Cause: The confd_cmd GET calls were taking too much time to return during a switchover if the confd was under stress. Steps to Replicate:
| Use the confd_cmd -f option with an empty string argument Workaround: N/A |
SBX-66831 | 2 | The warning message needs to be updated/have a proper ending when deleting the ipInterface. Impact: A warning message does not display in the cloud SBC when deleting the IP interface. But there is no problem with functionality. Root Cause: This is working fine in the hardware SBC. The problem is in the cloud SBC when the warning message is displayed, a few values are checked to see if they arr matching and then we show the warning popup. In the case of the cloud SBC, the values index are different and the check is failing because we are unable to show the warning popup when we delete the IP Interface. Steps to Replicate:
| The code is modified to handle the cloud SBC scenario as well. Workaround: N/A |
SBX-99306 | 3 | The SIPCM (SAM) deadlock reported on the SNMP request. Impact: The SAM process cores when getTlsStatus command is executed. Root Cause: The issue is because when fetching tls Status, Design was trying to access sessData that was no longer valid. Steps to Replicate: Execute the getTlsStatus command when running TLS load. The SAM process cores randomly. | The code is modified to fetch the status from socketPtr instead of the sessData. Workaround: N/A |
SBX-98954 | SBX-103395 | 2 | Portfix SBX-98954: Unable to configure HW/SBC SWe's into an SLB deployment. Impact: The SLB cannot be supported with the H/W SBCs. Root Cause: The CPX validation check prevented configuration on the H/W SBCs to configure the SLB. Steps to Replicate:
| The code is modified to allow configuration of SLB on the H/W SBCs. Workaround: N/A |
SBX-101887 | SBX-103727 | 2 | Portfix SBX-101887: The SBC was generating duplicate ICID for different calls. Impact: The same ICID value was generated for two different calls. Root Cause: The clock resolution used was 10ms leading to using the same timestamp when subsequent calls were received within 10ms. Steps to Replicate: Run load with CDR enabled. Check no two calls have the same ICID. | Use high resolution time tick of a 1 micro second and add a counter for achieving granularity of 100ns. Workaround: N/A |
SBX-102444 | SBX-103405 | 2 | Portfix SBX-102444: The link does not get restored for the mgmt interface for an I-SBC in centralized mode. Impact: The link state in the portMonitorStatus command does not show the correct state when the LDGs are disabled and enabled in a specific order. Root Cause: In a HA set up, each instance (for example, Node A and B) maintains its own Port Monitor configuration where as both instances maintains the link monitors configuration of both nodes. When the state of Link Monitor configured on Node B is modified, this CDB notification goes to both nodes A and B. As both of them have the configuration, they update the state and reset a link status maintained in a port monitor to UNKNOWN. Then, ICMP Pings are sent only on node B. When it receives a response, it updates the link state of a portMonitor configured on that node and generates a event notification. When the node A gets this event notification, it recognizes that this notification is from peer and only updates the Link Monitor fault state and port monitor link state remains as UNKNOWN on this node. Steps to Replicate: 1) Instantiate the I-SBC in a centralized mode. | The code is modified to not initialize link state of port monitor on local node when admin state of peer node LM configuration is changed. Workaround: The sequence of the LDG state modification has to be changed. |
SBX-103496 | 2 | The MGT0 cannot reach the GW. Impact: The mgt0 interface appears to be inactive. The user cannot ping the gateway from SBC-5400. Root Cause: This problem is specific to SBX-5400 fix. The SBC-5400 has a backpressure mechanism for management ports so that when the receive buffer exceeds a certain level, Design sends pause packets out to the interface to ask the switch/router to pause transmission momentarily. The receive buffer count is incremented by a hardware module and decremented by software. This causes the receive buffer count to wrap around, resulting in a high value. This triggers the back-pressure mechanism and Design continuously send out pause packets. Steps to Replicate:
| Set the correct interface information in the notification to address the issue. Workaround:
|
SBX-103561 | 2 | The "tgrp" parameter was not passing transparently when theSIP in the core is enabled. Impact: The SipCore calls are passing the wrong tgrp parameter value. Root Cause: There was missing logic to support the SipCore. Steps to Replicate:
| The code is modified to support the SipCore feature. Workaround: N/A |
SBX-100250 | SBX-103391 | 2 | Portfix SBX-100250: The KVM Direct-Single SBC not uploading configuration to the EMS. Impact: 1:1 on KVM is not creating config store directory. Root Cause: hwSubType variable value for KVM is not consider by lca.py script. Steps to Replicate: Deploy the 1:1 on KVM. | Consider hwType variable value instead of hwSubType. This will work for all virtual deployment types to address the issue. Workaround: N/A |
SBX-101235 | SBX-103488 | 2 | Portfix SBX-101235: The OAM does not output the NTPQ command. Impact: The NTP server CLI command not applied to the OAM. Root Cause: The NTP server CLI command logic was skipped for OAM due to blind logic change from SmaIsConfigurator() to SmaIsOAM(). Steps to Replicate: CLI: Configure: Run the OAM prompt: | Remove erroneous check for OAM node type to address the issue. Workaround: None. |
SBX-101853 | SBX-103390 | 2 | Portfix SBX-101853: Observing an issue with the Restore operation in 9.1. Impact: Restored the configuration is not applied to the Standby OAM and managed nodes. Root Cause: Configuration updater scripts do not detect the restored revision and do not reboot to apply it. This occurs when only two revision entries are present in /mnt/gfsvol1/config-versions.txt Steps to Replicate: Ensure only one revision entry is present in /mnt/gfsvol1/config-versions.txt. | The code is modified to check the revisions available. Workaround: None. |
SBX-102123 | SBX-103487 | 2 | Portfix SBX-102123: There was a CpxA process core on the OAM upon configuring the NTP server. Impact: The CpxProcess cores on an application shutdown. Root Cause: There was an improper ConfdProxy object destruction. Steps to Replicate: Stop the application while the traffic load is running is best to reproduce. | The code is modified to properly delete the ConfdProxy object. Workaround: None. |
SBX-101791 | SBX-102711 | 2 | Portfix SBX-101791: Observed the CpxA Process coredump on the SBC with 10% Packet loss introduced on HA interface. Impact: The CpxProcess cores while traffic load is running. Root Cause: Segmentation fault in MsgClient::checkBuffering. Steps to Replicate: Execute the traffic run. | The code is modified to address the issue. Workaround: None. |
SBX-101555 | SBX-103486 | 2 | Portfix SBX-101555: An application timeout error for "show table node" on OAM. Impact: The 'show table node' aborts with a timeout. Root Cause: There is no handling for empty statistics. Steps to Replicate: Execute a 'show table node'. | The code is modified for the empty statistics by returning an empty response. Workaround: None. |
SBX-96018 | SBX-103388 | 2 | Portfix SBX-96018: Configuration and Profile Import/Export fails on the OAM SBC nodes. Impact: The OAM and managed nodes have access to user-config-import CLI command. Configuration issues can be introduced if this command is used as OAM manages the configuration. Root Cause: There is no display condition check for the user-config-import CLI command. Steps to Replicate: Test #1: Test #2: | The code is modified for the user-config-import CLI command. Workaround: Do not use the user-config-import command. |
SBX-100805 | SBX-103407 | 2 | Portfix SBX-100805: The LCA does not exit even if the DRBD configuration fails in a 1to1 mode. Impact: The LCA does not exit even if the DRBD configuration fails in a 1to1 mode. Root Cause: The reConfigureHa.pl (Which configures DRBD) script's execution status was not checking in the LCA. Steps to Replicate: Removed the DRBD disk and try to bring up the SBC. With the changes, the LCA run stopped. | The code is modified to check the status of execution of the reconfigureHa.pl script and when it fails, stop running of LCA. Workaround: None. |
SBX-102146 | SBX-103375 | 2 | Portfix SBX-102146: Observing the "FAC: *FacSendGetRecordRequest: Get Record request already Sent:192.xxx.x.xxx" major log on an overnight load. Impact: Getting the FacSendGetRecordRequest major log during the overnight SBC load run. Root Cause: The FacSendGetRecordRequest Log is made as a major log but ideally it should be info level log. Steps to Replicate: Run the Overnight SBC load and check for FacSendGetRecordRequest major log. | The code is modified to address the issue. Workaround: None. |
SBX-103798 | SBX-103799 | 2 | Portfix SBX-103798: There was dual NUMA support in SWe. Impact: The SWe does not come up in VMs having multiple NUMA nodes except for signaling traffic profile (SLB, SSBC, SO-SBC). Root Cause: The root cause was due to deliberate software restriction to not allow multiple NUMAs. Steps to Replicate:
| The code is modified to allow multiple NUMA irrespective of personality and profile. Workaround: No workaround except using single NUMA set up. |
SBX-73003 | SBX-101630 | 2 | Portfix SBX-73003: A vulnerability in use of JavaScript Library To 8.2.4. Impact: The vulnerability in use of the Javascript library. Root Cause: When the Javascript library was using version 1.8.0., the vulnerability was reported. Steps to Replicate: Verified the appropriate screens to test and it is success. | The code is modified to fix the vulnerability. To upgrade this Javascript library, upgrade the jquery-ui (1.12.1) and dataTables (1.10.20). Workaround: N/A |
SBX-96788 | 2 | A DTMF 2833 PT change (in offer) was incorrect the OA SBX handling (wrong answer PT). Impact: When there is a peer offer with new PT, the SBC is unable to process and response the previous one. Root Cause: There was a logical error that checked the wrong field to detect PT change. Steps to Replicate:
| The code is modified to check the correct field for PT change. Workaround: None. |
SBX-103852 | 2 | The SBC sent unnecessary 481 for PRACK when the CANCEL is received. Impact: The SBC sends unnecessary 481 for PRACK when receiving a CANCEL. Root Cause: When the SBC received PRACK in response to a 18x message, it generated it was added to an outstanding transaction list. But it was not removed from the list when the SBC sent the subsequent 200 OK for the PRACK. When performing a CANCEL then it arrives, the SBC thought the PRACK was still an outstanding transaction and generated a 481 message. Steps to Replicate:
| The code is modified to remove the PRACK from the outstanding transaction list when the SBC sends back the associated 200 OK, so there is no extra 481 generated if CANCEL then arrives. Workaround: Enable the e2e PRACK if the egress also support PRACK. |
SBX-90884 | SBX-102729 | 2 | Portfix SBX-90884: Performance: Observed a SCM memory leak while running the STIR/SHAKEN with RPH Signing/Verification. Impact: The memory leak is caused at the SCM process for a STIR-SHAKEN failure. Root Cause: When a STIR-SHAKEN call is performed and the STIR-SHAKEN functionality resulted in failure, then the STIR-SHAKEN "Reason Code Text" is populated in order to know the reason for the failure. As a result, the STIR-SHAKEN failure "Reason Code Text" is then communicated in backward messages. While populating "Reason Code Text", the intended function will execute twice for a given call. For the second invocation, the existing "Reason Code Text" memory was neither reused or freed. Instead, the call was newly allocated each time for the same call. This resulted in memory leak for every STIR-SHAKEN call failure. Steps to Replicate:
| The code is modified to fix the following:
Workaround: None. |
SBX-101727 | SBX-103352 | 2 | Portfix SBX-101727: The LeakSanitizer detected memory leaks in the SAM Process (DFe process). Impact: When making configuration changes to the D-SBC profile, the SBC leaks a small amount of memory. Root Cause: The SBC application code uses local buffers while reading profile changes from the CDB and this memory was not getting freed up correctly, leading to a leak. Steps to Replicate: This problem is highlighted when using ASAN enabled build in the engineering lab and making DSBC profile changes. | The code is modified to correctly access the local buffers to avoid the memory leak. Workaround: None. |
SBX-102056 | SBX-103355 | 2 | Portfix SBX-102056: The AddressSanitizer detected a heap-buffer-overflow in SipsgRedundMsgParamLoadSubsCbStr. Impact: While printing the debug messages as part of making subscriber data redundant, the SBC was reading off the end of a buffer. Root Cause: Some of the buffers used to hold string information were not large enough to include a NULL terminator so when printing out debug messages, the printing code was reading off the end of the buffer. Steps to Replicate: This problem is highlighted when using ASAN enabled images in the engineering lab. | The code is modified to ensure the strings for the subscriber data are NULL terminated to avoid the code reading of the end of the string buffer. Workaround: None. |
SBX-101597 | SBX-103354 | 2 | Portfix SBX-101597: The LeakSanitizer detected memory leaks in the CpxAppProcess. Impact: When making changes to the D-SBC signaling port configuration, the SBC is leaking a small amount of memory. Root Cause: While reading configuration changes from the CDB, the SBC application code allocates local buffers and they are not getting freed up at the end of processing leading to a small memory leak. Steps to Replicate: The issue is seen when using ASAN enabled images in the engineering lab and making configuration changes to the DSBC signaling port configuration. | The code is modified to correctly free the memory allocated to the local buffers to avoid the memory leak. Workaround: None. |
SBX-103603 | SBX-103636 | 2 | Portfix SBX-103603: The LeakSanitizer: detected memory leaks in the MrfRmProcessTrmAllocRpyMsg. Impact: While testing call scenarios for RTCP for T.140 Pass-through functionality, it was observed that the SCM process could leak memory for calls associated with an MRF (external media transcoder). Root Cause: The SBC was allocated memory while processing the SDP associated with this call but was not always freeing up the memory at the end of the call. Steps to Replicate: Run various call scenarios with MRF where the SBC is using the SIP to allocated media resources on an external media transcoder (MRF) or T-SBC. | The code is modified to correctly free all the memory allocated for the call. Workaround: None. |
SBX-103489 | SBX-103637 | 2 | Portfix SBX-103489: The LeakSanitizer: detected memory leaks at the confd_malloc. Impact: The small memory leak during the configuration of lawful intercept server. Root Cause: The configuration code was reading information from the CDB and storing information in an internal memory block but not freeing it up. Steps to Replicate: Create a lawful intercept server and make configuration changes. | The code is modified to correctly release the internal memory block at the end of the configuration action. Workaround: None. |
SBX-102054 | SBX-102305 | 2 | Portfix SBX-102054: The LeakSanitizer detected an error in CpxAaaGetElem. Impact: When adding new users, a small amount of memory leaked. Root Cause: While processing the addition of new users, the code allocated temporary memory blocks to hold information retrieved from the CDB about existing users this memory was not getting completely released after use. Steps to Replicate: This issue is observed when running with ASAN images in the lab. | The code is modified to ensure the temporary memory allocated is freed up after use. Workaround: None. |
SBX-102060 | SBX-103356 | 2 | Portfix SBX-102060: Leak detected while running the SBX-93279 HA cases, especially on the SCM and IM process. Impact: When making a CAC profile configuration change, the SBC leaks a small amount of memory. Root Cause: When reading configuration changes from CDB, the application code was storing information in local buffers and not freeing it up correctly, leading to a memory leak. Steps to Replicate: This problem is highlighted when using ASAN enabled images in the engineering lab and making CAC profile configuration changes. | The code is modified to correctly free up the memory in local buffers to avoid the leak. Workaround: None. |
SBX-101504 | SBX-103689 | 3 | Portfix SBX-101504: The SPD for IPSec SA was created for the 3GPP IMS AKA should allow both the TCP and UDP transport protocols. Impact: The Apple and Samsung phones run the IMS AKA registration over the TCP, but send an SMS (MESSAGE) over the UDP later, which was dropped on the SBC. Root Cause: The SBC honors messages only on that transport for IPsec (established using the IMS AKA) that was used initially during registration. Steps to Replicate: 1. Set up SIP registration using IMS AKA on TCP. | The code is modified so the SBC now listens on UDP ports also, same ports that are exchanged during initial IMS AKA registration, along with the TCP ports. Workaround: N/A |
SBX-101749 | SBX-102103 | 2 | Portfix SBX-101749: The SBC incorrectly passed a complete contact header transparently without the presence of the isFocus parameter. Impact: The SBC incorrectly passed a complete contact header transparently without the presence of the isFocus parameter. Root Cause: The SBC passed a complete contact header transparently without the presence of the isFocus parameter, with the contactTransparencyForIsFocusMediaTag enabled on both trunk groups. Steps to Replicate:
| The code is modified to not transparently pass the complete contact header when the contactTransparencyForIsFocusMediaTag flag is enabled, and the isFocus parameter is not present in the 200 OK notification. Workaround: N/A |
SBX-88376 | SBX-103386 | 2 | Portfix SBX-88376: The SBC interop with Ribbon AS: Upstream Forking was not working consistently using the TLS. Impact: For a non UDP transports, in an upstream forking scenario where as on ingress side, the SBC receives multiple INVITE with the same Call-Id, From, and To. Root Cause: The SBC used to drop off those forked INVITE's that are received during the processing of initial INVITE. Steps to Replicate: On a non UDP transport, send multiple forked INVITE's towards the SBC with the same Call-Id, From, To, Request URI. | Queuing the subsequent forked INVITE's and processing them in the same order received solves the problem. Workaround: None or use the UDP as transport. |
SBX-103937 | SBX-103775 | 3 | Portfix SBX-103775: Changing the XRM to build ALL media RID’s static IP headers with the “Don’t Fragment” (DF) bit SET TO 0 instead of 1. Impact: The SBC forwards the DTLS packets correctly but the large certificated packet does not reach the calling device. Root Cause: The SBC has set the DF (do not fragment) bit in IPv4 header so routers cannot split the packet and it can result in the packet getting dropped. Steps to Replicate:
| The code is modified to set the DF bit when the SBC builds the IP header for DTLS and STUN packets. Workaround: N/A |
SBX-103939 | SBX-103945 | 3 | Portfix SBX-103939: The NAPT timer was not armed properly in the MoH. Impact: The NAPT timer did not started as the NRMA requested. Root Cause: The RTP flow mode was xmt-only. Then, the NRMA requested flow change to enable the NAPT timer expiry because we have already learned source address. But the XRM did not start NAPT timer because it was a learning next request. Steps to Replicate: Run NAPT regression tests to reproduce the issue. | The code is modified to start the NAPT timer for learning next if NRMA has set XRM_NAPT_MEDIA_NAPT_TIMER_ACT_ENAB. Workaround: None. |
SBX-100426 | 3 | The `imfile' in rsyslog.conf without freshStartTail="on" can cause the SBC switchover when enabled. Impact: When certain logs (consoleLog, sftpLog, syslogLog, platformAuditLog, ntpLog) get enabled initially, high number of old logs can be sent to the remote syslog server. This can cause network issues which can cause the SBC to switchover. Root Cause: If a log is enabled for the first time, the rsyslog will try to send the whole log to the remote syslog server at once. Steps to Replicate: Fill up /var/log/syslog with messages. Enable syslogLog in the SBC application. Verify older messages are not sent to the remote system. | The code is modified so the rsyslog option only reads in latest logs when initially enabled. Workaround: Update the input rules in /etc/rsyslog.conf: e.g. to: #input(type="imfile" File="/var/log/session/session.*" Tag="console" Severity="info" Facility="lpr" escapeLF="on" addMetadata="on" freshStartTail="on") |
SBX-103763 | 3 | The upgradeSBX.properties makes the EMA to show upgrade in progress forever. Impact: An upgrade was completed but the Platform Manager Install/Upgrade screen gets stuck on previous upgrade and can not perform new upgrade operation. Root Cause: We are facing this issue because we had updated the SBC upgrade steps as part of SBX-56893 Jira in 6.1.0. Whenever we upgrade the SBC from 6.0.x to 8.2.x, we will see the issue because there are different steps in 6.0.x and 8.2.x that is causing the issue. When we upgrade the SBC using 6.0.x code that has the old upgrade steps once we execute the pre install check step, the PM API updates the upgradeSBX.properties file with next step (INSTALL_DB), the SBC goes for reboot and platform manager code gets replace with upgraded version which is 8.2.x. Now, the PM API reads upgradeSBX.properties file to read the steps value that is INSTALL_DB and match the check but in 8.2.x PM code. There is no INSTALL_DB check in PM code because of that, we are unable to update the upgradeSBX.properties file with next steps. Once an upgrade gets completed and the PM code updates upgradeSBX.properties file with FINISHED as steps, we move the upgradeSBX.properties file into upgradeSBX.properties.1, which is not happening and Platform Manager UI is unable to mark as complete and getting stuck on install/upgrade screen with previous upgrade. Steps to Replicate:
| The code is modified to handle the INSTALL_DB step check to mark upgrade as complete from Platform Manager UI. Workaround: To perform again upgrade operation, delete the upgradeSBX.properties file from the SBC. |
SBX-103528 | 3 | There are unwanted critical logs in HW SBC for: "CRITICAL.SMA: *SmaIsCustomGPUProfile: Failed to read /opt/sonus/conf/swe/capacityEstimates/.activeCallMixInput.json". Impact: The critical level log gets written into the DBG event log each application startup on Hardware Systems. Root Cause: The system attempts to open a file that does not exist on Hardware Platforms. Steps to Replicate: Startup the SBC application on a Hardware SBC. Verify the DBG log. | Stop the system from attempting to open the file on the Hardware Systems to address the issue. Workaround: None. |
SBX-104060 | 3 | The DBG logs in the 7.2.4R0 SBCs filling up with the T38 logs. Impact: When the call trace is enabled, the T38 messages are logged in a .DBG file. However, even after a call trace is disabled, T38 log messages continue to appear in .DBG file. Root Cause: A gevelobal variable to set t38 log messages was set for call traces but never reset. Steps to Replicate:
| The code is modified so after the call tracing is disabled, T38 log messages will not appear in .DBG file. Workaround: Use 'unhide debug' command to disable T38 log message after call tracing is no longer needed. |
SBX-102234 | SBX-104007 | 3 | Portfix SBX-102234: The SubsystemAdmin filter affects calltrace (TRC) logging showed useless logs. Impact: After creating then deleting an entry in the oam eventLog subsystemAdmin, the original behaviour is not restored. INFO level events for that subsystem are no longer logged, even if the oam eventLog typeAdmin filterLevel is info. Root Cause: Deleting an entry in oam eventLog subsystemAdmin does not restore settings back to default. Steps to Replicate:
| The code is modified to process to deleted the oam eventLog subsystemAdmin entry so that settings are put back to default values. Workaround: None. |
SBX-98024 | SBX-104011 | 2 | Portfix SBX-98024 The contact header is not transparently passed when the Ingress and Egress had different transport types. Impact: Contact header is not passed transparently from Ingress, when egress side has different transport type, even when the IPSP flag 'passCompleteContactHeader' is enabled on both ingress/egress Trunk Groups. Root Cause: In API SipSgCheckAndSetContactHeaderTrasparency(), irrespective of transparency control is enabled/disabled, if the egress Sig Zone is MS Teams, Steps to Replicate:
| The code is modified so regardless of MS Teams zone, if the transparency control flag is enabled then pass the contact header transparently to the egress. Workaround: None. |
SBX-102059 | 2 | Mismatch in the count of ipPeers on Routing page. Impact: There was a mismatch in the Zone, and IpPeer counts on the UI. Root Cause: The backend logic using the contained predicate that fetches all the related data. Steps to Replicate: Go to the Route screen, select trunkGroup and verify the Zone, IpPeer counts. | The code is modified from contained to match, and is now only associated data being fetch based on the parent selected. Workaround: None. |
SBX-86293 | SBX-104169 | 3 | Portfix SBX-86293: PreInstall Check improvements for file permissions. Impact: PreUpgrade checks failure due to permission issues on external directory. Root Cause: Pre-checks script failed to run commands on peer due to permission issues. Steps to Replicate: Perform upgrade to the fix version and verify that upgrade is successful. | The code is modified to ensure permissions/ownership are set properly before running through pre-checks/upgrade. Workaround: Set the right ownership for external directory as: |
SBX-101918 | 2 | The Out of Memory caused an SBC switchover. Impact: Memory leaks when 3xx relay and reject 3xx on egress IPSP Root Cause: Contact Headers in 3xx memory did not free properly. Steps to Replicate:
| Ensure the memory of contact headers in 3xx are properly free when config to reject 3xx. Workaround: Customer may using SMM to change the status 3xx to 503 instead. |
SBX-104022 | 3 | The digitCriteria numberLength operation parameter was not configured after the first commit. Impact: The digitCriteria numberLength operation parameter not configured after the first commit. Root Cause: The value of the digitCriteria numberLength was overridden to 0 by the dpcIndicator during a Db update at first commit, which caused the issue. At the same time, the dpcIndicator was updating the value due to missing validation. Steps to Replicate: Now in the first commit value digitCriteria numberLength should pick the value. | The code is modified to update the dpcIndicator only if the criteria type is URI. As a result, the digitCriteria numberLength is set expected value properly and issue got fixed. Workaround: Committing twice will set the digitCriteria numberLength value. |
SBX-105838 | 2 | There was an SM coredump, that was in communication with openhpi. Impact: The SM took a bit longer to read all four DSP card version's info on the SBC7000. This leads to an SM coredump. Root Cause: The SM took a bit longer to read all four DSP card version's info on the SBC7000. Steps to Replicate: Test on the SBC7000 with all four DSP cards. | The SM time out value is increased from 90 sec to 120 sec to address the issue. Workaround: None. |
SBX-97650 | SBX-99686 | 2 | Portfix SBX-97650: ERROR: The leakSanitizer detected memory leaks. Impact: The leak sanitizer detected a memory leak for NRMA Session Desc as part of the leak sanitizer tool execution. Root Cause: During the SDP to PSP conversion, the routine SipSgConvertSdpToPsp() is allocating memory for the NSD structure and not freeing the memory when the conversion fails. Steps to Replicate: Run the leak sanitized tool to reproduce the issue. | Freed the memory allocated for the NSD structure in cases where the SipSgConvertSdpToPsp() fails. Workaround: N/A |
SBX-104723 | SBX-103704 | 2 | Portfix SBX-103704: The RTP sourceAddressFiltering is not working (call leg dependency). Impact: The source address validation is not done if call flow does not involve NAPT learning. For calls that want source address validation but does not have NAPT enabled, the SBC would not validate the source address and end up forwarding the RTP packet to the other endpoint. Root Cause: There is no way for application to inform Network Processor to validate source if NAPT learning is not enabled. Steps to Replicate: Involves a CISCO MOH server but probably something else can be used. | The code is modified to validate source even when NAPT learning is not enabled to address the issue. Workaround: Enable NAPT learning for the call. |
SBX-100253 | SBX-103357 | 2 | Portfix SBX-100253: The SBC services are not coming up with an ASAN build. Impact: On the SBC5100/5200, there was an ASAN flags error while processing the negative Boot Init Response received from the DSP. Root Cause: While processing the Boot Init response, variables that are not defined for DSPs on SBC5100/5200 is being accessed. Since memory is not allocated to these variables, accessing them is invalid. Steps to Replicate: None. | The code is modified where if it is SBC5100/5200 DSP, the mentioned variables are not accessed. Workaround: None. |
SBX-103255 | SBX-105069 | 2 | Portfix SBX-103255: Enhance the sbxPerf on the SBC for lesser resource consumption. Impact: The SBC performance monitoring tools like top and top2 at times take 20% of a CPU core there by reducing total available CPU resources for management activities on the SBC. Root Cause: The sbxPerf that contains list of tools such as top, mpstat, and iostat currently runs periodically without any linux value configured. This can cause these processes to get prioritized and scheduled ahead of other management processes such as ConfD and SSH. Steps to Replicate: Install fix build and ensure processes such as top, top2, mpstat sbxPerf are running with corrects value of 15 using the top command. | The code is modified so that priority of these processes are less compared to other management processes on the SBC. Workaround: None. |
SBX-103593 | SBX-104718 | 2 | Portfix SBX-103593: The SBC is ignoring Use Max Bitrate Only flag. Impact: The SBC is ignoring Use Max Bitrate Only flag. Root Cause: During Re-Invite answer processing, NrmaAdjustPeerT38MaxBitRate() routine is doing T38MaxBitRate adjustment based on packet size that is changing T38MaxBitRate value from 14400 to 4800. Steps to Replicate: Call Flow:
| The code is modified to relay the T38MaxBitRate in SDP, which is received from peer for Direct Media calls. Workaround: None. |
SBX-105416 | SBX-105703 | 2 | Portfix SBX-105416: The glusterfs is failing on the standby OAM after a reboot. Impact: The Gluster server on a Standby OAM fails to start. Root Cause: The Gluster heal check conditions are wrong. Steps to Replicate:
| The code is modified to obtain the expected result. Workaround: None. |
SBX-91799 | SBX-103718 | 2 | Portfix SBX-91799: The segfault in pamValidator during PM login with incorrect credentials. Impact: The segfault in pamValidator on a failed login for locked user. Root Cause: The pamValidator defines a conversation function that is called by pam modules to exchange values. The pam module was freeing a struct member in the first call and accessing the same freed value in another call to the conversation function that was causing segmentation fault. Steps to Replicate: Perform following steps on any of the SBC deployment and verify that segmentation fault does not happen: ## TEST 1: Ensure success for correct username and password:
| The code is modified so the pam_response struct properly in between calls to the conversation function. Workaround: None. |
SBX-103387 | SBX-104717 | 2 | Portfix SBX-103387: The Video NAT learning is failing on the D-SBC cloud. Impact: The Video NAT learning failed in the D-SBC. Root Cause: On the D-SBC, NAT learning for video stream was not processed successfully and as a result caused the video packets to be dropped by the SBC. Steps to Replicate:
| The code is modified to process the NAT learning for the video stream in the D-SBC. Workaround: None. |
SBX-104560 | SBX-105027 | 2 | Portfix SBX-104560: The redirection NOA set wrong in the CDR. Impact: The "Redirecting Orig Cd Num - NOA" subfield of "Redirection Feature Spec Data" is not set correctly in CDR record if the the Redirecting Original Called Number - NOA value is modified by PSX. Root Cause: The existing code was not updating the value for the CDR record based on route specific information returned from the PSX. Steps to Replicate: Test Set up
Test Procedure
| The code is modified to populate the CDR value from the route specific data returned from PSX. Workaround: None. |
SBX-103634 | SBX-104230 | 2 | The LeakSanitizer: detected memory leaks in DCmRestoreAllMetaVarsToStandbyContext. Impact: A small memory leak was observed in the SAM process while performing a switchover from standby to active box. Root Cause: The standby instance stores information about the metavars associated with signaling ports configured on the active instance. During the conversion from standby to active, the standby data is moved into active structures but the original standby memory blocks are not freed up correctly resulting in a memory leak. Steps to Replicate: Perform a switchover from standby to active while running a basic call, no memory leak will be observed in the SAM process. | The code is modified to correctly free the memory associated with the standby data when it gets transitioned to active to avoid the memory leak. Workaround: None. |
SBX-103224 | SBX-103589 | 2 | Portfix SBX-103224: The ipsecSaStatus with local SPI is failing, as well as ikeSaStatus and ikeSaStatistics with ikeSaIndex is failing. Impact: The show command for ikeSaStatus and ikeSaStatistics was not displaying information for the IPSEC calls of type ikev2 when trying to display with specific key field information. Root Cause: The display logic was missing to output call information for the type ikev2 with specific parameters. Steps to Replicate: Make IPSEC calls of type ikev2 and then run the status and statistics commands using the remoteSpi as a parameter. | The code is modified to correctly display information for the IPSEC calls of type ikev2 with specific parameters. Workaround: The display prints out all information correctly when no parameters are specified. |
SBX-98302 | SBX-99720 | 2 | Portfix SBX-98302: The LeakSanitizer detected memory leaks. Impact: The LeakSanitizer detected a memory leak in the SIPSG while processing the REGISTER messages. Root Cause: While processing a REGISTER message, the SBC performs a PSX query and gets back the primary domain information in the policy response. The SBC allocates memory to hold this information in the registration control block (RCB) but it was not getting freed up when the RCB was later released. Steps to Replicate: Configure the SBC with Primary Registrar Domain info and run a registration scenario with ASAN enabled images. | The code is modified to free the memory associated with primary domain information to avoid the memory leak. Workaround: N/A |
SBX-103732 | SBX-104002 | 2 | Portfix SBX-103732: There was an error AddressSanitizer: heap-buffer-overflow on address 0x61d001429c18 at pc 0x556c876cf74c bp 0x7fb14f64fab0 sp 0x7fb14f64f260 READ of size 3488 at 0x61d001429c18 thread T21 in the SAM Process. Impact: In a DSBC environment while processing the remote media data command message the SAM process could read off the end of the received message. Reading off the end of the allocated message block could in the worst case result in a coredump. Root Cause: The SAM process was assuming that the size of the received message was larger than it actually was and this resulted in reading off the end of the received message buffer. In most cases this does not cause a problem but in could potentially result in a coredump if the associated buffer is at the end of the addressable memory space. Steps to Replicate: Run RFC4117 test case for audio transcoding and video relay. | The code is modified to not read off the end of the received memory block. Workaround: None. |
SBX-97838 | SBX-100051 | 2 | Portfix SBX-97838: Unable to create a sipSigPort on the cloud SSBC when the IP metaVar is previously used for a different sipSigPort. Impact: Unable to create a sipSigPort on the cloud SSBC when the IP metaVar is previously used for a different sipSigPort. Root Cause: The root cause for this issue is there was a check to skip any validations if the instance is cloud based in the addIpAddressToMetaTable and deleteIpAddressFromMetaTable functions. As a part of SBX-59421 feature, in 8.1 the check was removed in the addIpAddressToMetaTable and as a result duplicate entries were not allowed to be configured. However, it was retained in deleteIpAddressFromMetaTable function. Even after sipSigPort is deleted, stale entries would still remain and the sipSigPort creation was failing with same metaVar as a result. Steps to Replicate: The steps cannot be reproduced.
Error seen: addressContext default zone ZONE_IAD sipSigPort 2': IP address / port number must be unique within an address context | The check that was retained in deleteIpAddressFromMetaTable is removed. Workaround: If the customer is not using 9.0 and still in older releases, the following procedure can be used to remove the stale entries:
|
SBX-97832 | SBX-100054 | 2 | Portfix SBX-97832: Unable to delete the leaf node like ipVarV4 or ipVarV6 in the sipSigport configuration in the I-SBC. Impact: Unable to delete leaf node like ipVarV4 or ipVarV6 in sipSigport configuration as shown in the example below: admin@isbcSwe-192.168.2.21% delete addressContext default zone SBX_89017_KL_1 sipSigPort 5 ipVarV6 [edit] Root Cause: In the SBC systems that were not using the metavar configuration, the deletion of ipAddress was allowed. This was due to a bug in the code that wrongly checked for the metavar value before allowing the IP address deletion. Steps to Replicate: Configure and delete the leaf nodes of the sipSigPort. | The code is modified so the deletion is allowed. Workaround: N/A |
SBX-96436 | SBX-100050 | 2 | Portfix SBX-96436: The SBC was adding a reason header even when the verification is successful. Impact: The SBC should only add a reason header and text when the verification service replied with a failure response. Root Cause: The SBC was adding the reason header when it is received from the PSX without checking whether the verification is SUCCESS or not. Steps to Replicate:
| The code is modified so the SBC checks failure status then only adds the reason header if it is available. Workaround: N/A |
SBX-102827 | SBX-104158 | 2 | Portfix SBX-102827: The SBC 5210 experienced an upgrade failure during Starting DB_RESTORE stage. Impact: Failure during upgrade while creating database referential keys. Root Cause: Creation of foreign key fails on table packet_service_profile (Child Table) column CODEC_ENTRY_FK9, as it had "0" in one of its rows and dbimpl.codec_entry table (parent table) does not have this value. Steps to Replicate: Upgrade a dump that has "0" in the following. It should be successful. packet_service_profile.CODEC_ENTRY_FK9 | The code is modified to check the data and nullify any value that is not present in parent table before adding the referential keys, Workaround: None. |
SBX-104216 | SBX-104477 | 2 | Portfix SBX-104216: The SBC relays STUN packets in RTP streams on pass-thru calls (no transcoding); on RTP to SRTP calls, the relayed STUN packet causes the ROC to reset back to 0 and the remote peer discards the encrypted media packets. Impact: Sending Non_RTP packets mixed/relayed in SRTP stream from the SBC resulted in one-way audio at the endpoints in longer duration calls. Root Cause: These non-RTP packets relayed eg. STUN packet causes resetting of encryption ROC back to 0 on the SRTP stream sent out. This issue results in the remote peer discarding the encrypted media packet in long duration calls from the SBC, where ROC is expected to be non-zero. Steps to Replicate: Run a SRTP passthrough call with media for more than 15 mins, with 10 ptime. Then send a non-RTP packet (STUN, UDP TL t.38) in that stream for pass-thru relay, and observe the media in that call. | The code is modified to not mix Non-RTP packets with SRTP encryption/decryption processing. As a result, SRTP media stream ROC does not reset with these mixed packets, and the endpoint will not have media issues in longer duration calls. Workaround: If longer duration calls are expected to relay STUN messages as well, disabling the SRTP will solve media issue. However, if SRTP must be enabled for security reasons, there is no workaround for this. |
SBX-103788 | SBX-104042 | 2 | Portfix SBX-103788: ASAN ERROR: LeakSanitizer: detected memory leaks in the CpxAppProcess. Impact: There was a small memory leak when making the configuration changes to the GW signaling port. Root Cause: The configuration logic was reading the interface group name from CDB into a temporary local variable in order to perform validation logic but never freed up this memory at the end of the validation. Steps to Replicate: This issue is highlighted in the engineering lab when performing GW sig port configuration changes on an ASAN enabled build. | The code is modified to correctly free the temporary memory to avoid the leak. Workaround: None. |
2 | CE_2N_Comp_ScmProcess_2==4455==ERROR: LeakSanitizer: detected memory leaks at confd_malloc. Impact: ASAN detected memory leaks while processing a E164 profile. Root Cause: The memory was released while processing a E164Profile at the end of the configuration action. Steps to Replicate: Create and modify the E164Profile configuration. | The code is modified to release the internal memory block at the end of the configuration action. Workaround: None. | |
SBX-96307 | SBX-99705 | 2 | Portfix SBX-96307: The LeakSanitizer detected memory leaks at SipSgEmergencyProfileAddPrefix. Impact: Observed a memory leak while adding and deleting the prefix/urnPrefix entries in an emergency profile. Root Cause: On the deletion of prefix/urnPrefix entries, the memory not getting freed for the prefix list and this was causing the memory leak. Steps to Replicate:
| The code is modified to free the memory whenever the prefix entries is deleted from the emergency profile. Workaround: To avoid the memory leak, delete and recreate the entire emergency profile rather than just deleting only the prefix entries from the profile. |
SBX-103731 | SBX-104001 | 2 | Portfix SBX-103731: The AddressSanitizer: heap-buffer-overflow on address 0x61a0000cb9d9 observed in the SAM Process while running OCSP feature. Impact: When the OCSP stapling feature is enabled on the SBC and the code was processing, the response it writes to unallocated memory and in the worst case this could result in process coredumps. Root Cause: While processing a OCSP response, the code was allocating a memory buffer large enough to hold the response, but then incorrectly writing one byte off the end of the memory buffer while attempt to try and null terminate the string. Steps to Replicate: Set up - UAC > Dut<>Adapter -> UAS
| The code is modified to correctly terminate the OCSP response string without writing off the end of the memory buffer allocated to hold the response. Workaround: None. |
SBX-97904 | SBX-99961 | 2 | Portfix SBX-97904: The AddressSanitizer detected a stack-buffer-overflow on the address 0x7f994bb18d30 at pc 0x56314564c886 bp 0x7f994bb18c10 sp 0x7f994bb183c0 WRITE of size 16 at 0x7f994bb18d30 thread T7. Impact: A stack-Buffer-Address overflowed for a V6 Address. Root Cause: As part "SBX-66765:Support for IPsec for Media with UDP transport for LI" feature, Steps to Replicate: This problem is highlighted when testing the following scenario in the lab with ASAN enabled images.
| The code is modified to handle V6 Address overflow. Workaround: N/A |
SBX-103801 | SBX-104105 | 2 | Portfix SBX-103801: ASAN: Observed a run time error in the M-SBC "runtime error: load of value 42, which is not a valid value for type 'bool'" Impact: The M-SBC could potentially configure the wrong data path mode for a call. Root Cause: No issues were observed while running this functionality on a regular deployment image. But while testing with ASAN it highlighted that some of the fields used in a call resource allocation message were not always initialized correctly. This can potentially lead to unexpected behavior e.g. SYS_ERRs, wrong datapath mode set up. Steps to Replicate: This issue was highlighted while while running test suite related to RFC-4117 MRF Mid-Call modification Enhancement. | The code is modified to correctly initialize the resource allocation request fields to avoid issues. Workaround: None. |
SBX-93898 | SBX-104515 | 2 | Portfix SBX-93898: The "request sbx xrm debug command sec -stat gcid <gcid>" was not showing the enc and dec details on the SBC SWe. Impact: This debug command in unhide section is not showing all the required fields populated in the SBC SWe. Root Cause: The NP response is not framed in expected order to application layer. Steps to Replicate: Run a SRTP call and the issue this debug command. The debug command does not show all the populated fields. | The code is modified so the NP Response is correctly framed in expected order to application layer. Workaround: This debug command is to see SSN field value with RoC, all other details can be seen from show call mediastatus. |
SBX-96116 | SBX-99724 | 2 | Portfix SBX-96116: The LeakSanitizer detected memory leaks at SipSgCopyRemoteAddressInfo. Impact: Observed a memory leak during an early call termination. Root Cause: Whenever a call terminated early at the ingress leg, some resources were not freed and it was causing the memory leak. Steps to Replicate: Configure the SBC to reject an HPC call based on GETS-Feature Control Match and RPH header processing (For early termination). | The code is modified to free the memory during an early call termination. Workaround: N/A |
SBX-104342 | 3 | The SBC silently drops the second Notify when running the off board query for the eventDialog. Impact: SBCs silently drop the second Notify within a Subscribe if it received simultaneously. Root Cause: Currently, the SBC does not support multiple Notify when it requires an off board query for a dialogEvent of Notify. Steps to Replicate: After a Subscribe, the Peer server sends multiple Notify (almost at the same time) with dialogEvent for an off board query. | The code is modified so the SBCs respond with 503 with retry-after for this case. Workaround: None. |
SBX-103922 | 2 | There was a PRS Process coredump on an active/A node in the middle of an upgrade. Impact: The PRS Process cored during the LSWU while syncing ICE call data. Root Cause: The ICE redundancy code is taking a long time to sync the call data with the standby during LSWU, causing a Healthcheck timeout and a core dump. Steps to Replicate: The issue cannot be reproduced easily. | The code is modified so the ICE syncs the call data to standby and addresses the issue. Workaround: None. |
SBX-104147 | 3 | After the switchover, a large amount of the DBG messages generated. Impact: When TG block direction setting is modified before a switchover, modified block direction setting does not reflect on SIP calls/message relays after switchover. Root Cause: The SBC does not modify block direction correctly on the standby node. Steps to Replicate:
With a fix, at step 8, the SBC will relay SUBSCRIBE message correctly. | The code is modified to ensure the block direction configuration works correctly after a switchover. Workaround: 1. Apply following workaround to toggle block direction set addressContext AC zone zone1 sipTrunkGroup SIPTG1 blockDirection incoming |
SBX-104247 | 2 | Resource memory congestion level 3 is approaching threshold 90 sample 81. Impact: The SAM Process is leaking memory when the AKA is being used. Root Cause: The SAM Process is leaking an AKA related structure when the code is handling an error case scenario. Steps to Replicate: Unable to reproduce this issue. The root cause was found by code inspection. | The code is modified to correctly free the AKA structure in all scenarios. Workaround: None. |
SBX-101668 | SBX-103360 | 2 | Portfix SBX-101668: The LeakSanitizer detects the memory leaks at the hdb_handle_create. Impact: The leak sanitizer was reporting some memory leaks because of memory allocation done in the CcSetLiCdcMediaTypeFromDb() function in a ccCsv.c file. Root Cause: The CcSetLiCdcMediaTypeFromDb() function in memory is dynamically allocated for the mediaIpInterfaceGroupName but not freed, which caused the memory leak. Steps to Replicate: Run a 3xx call with LI configuration on an ASAN build and this leak should not appear. | The code is modified to free the memory allocated to mediaIpInterfaceGroupName after the use of this variable is completed. Workaround: None. |
SBX-102151 | SBX-103153 | 2 | Portfix SBX-102151: D-SBC is not sending the rtp packets to other end after transfer in a transcoded call. Impact: On the D-SBC, one way media was observed with no media towards calling party A post call transfer by B to C for the scenario: First call (A-SBC-AS, AS-SBC-B), Second call (B'-SBC-AS, AS-SBC-C), where AS=Broadsoft application server. From packet capture on A-SBC leg of the single DSP transcode call, the sequence number of packets sent by the SBC was reset to zero after A is put off hold. This issue is not seen on the I-SBC. Root Cause: In the D-SBC, with every modify (ex: hold/resume) a new DSP(s) is allocated for a transcode call. The RTP sequence number and RTP timestamp from previous the DSP deactivation were not being passed to the subsequent DSPs allocated in the context of the same RTP stream (SSRC). Steps to Replicate: Ways to replicate the issue: Test Set up: Preconditions: | The code is modified to ensure the RTP sequence number and the RTP timestamp statistics of both G711 side of DSP and non-G711 side of previous DSP deactivation are passed to the subsequent DSP, so that the sequence number continues incrementing sequentially within the same media stream/SSRC instead of restarting from zero for every modify. Workaround: No workaround. |
SBX-104156 | SBX-104570 | 3 | Portfix SBX-104156: The RTT-TTY support verify call flow in the SBC. Impact: Lower case characters from the t140 packet were not getting converted correctly to Baudot (tty). Also, some other characters were not getting converted as per V.18 A2 table. Root Cause: The translation table from T140 to Baudot (TTY) only accounted for subset of characters that were present in Baudot (TTY) character set. Steps to Replicate:
| The code is modified for:
Workaround: Instead of lower case letters, use upper case letters. |
SBX-98884 | SBX-99690 | 2 | Portfix SBX-98884: The LeakSanitizer detected memory leaks at the IcmAlloc2. Impact: The ASAN shows a memory leak when run with the surrogate registration. Root Cause: A memory leak caused by the ICM request message since it did not free the SURROGATE task. Steps to Replicate:
| The code is modified so now the ICM memory is freed in the SURROGATE task when receiving a request from the SIPFE. Workaround: N/A |
SBX-100713 | SBX-103587 | 2 | Observing the major log "XrmAsyncCmdErrHdlr: ERROR NpMediaIntf cmd 2a gcid" in all nodes of the 2:1 cluster. Impact: Observed the major log "XrmAsyncCmdErrHdlr: ERROR NpMediaIntf cmd 2a gcid" in all nodes of 2:1 cluster. Root Cause: As the error did not have a valid GCID, the error log becomes unidentified, since there is no action taken by application based on this error message. Steps to Replicate: Set up: | The code is modified to move the error message below the GCID validity check. Workaround: None. |
SBX-103154 | SBX-103400 | 2 | Portfix SBX-103154: The SBC:9.1 Comp_EnmProcessMain experienced a core dump. Impact: Observed an EnmProcess core dump in a AWS instance when the license is applied immediately after the SBC comes up. Root Cause: When the SBC comes up, the EMA loads default configurations on to the SBC (in this particular case it was loading the trap target configuration) and at the same time, the automation suite run by Design triggered the license installation. The race condition between the EMA trigger and the license command caused a deadlock because no command was able to proceed to completion and EnmProcess cored. Steps to Replicate: To simulate the simultaneous trigger from EMA (REST API) and CLI, the following script was running to create and delete the trap target. While the script was running, a CLI session was opened and license installation command was run:
| The code is modified to handle license installation to a thread so that it is not blocked by any other command and it does not block any command. Workaround: Delay the license installation for a few seconds after the SBC is up and running. |
SBX-100938 | SBX-101797 | 2 | Portfix SBX-100938: An SCM process core dump was observed on the SBC for Blind Transfer no Answer from the customer when replied with 603 Decline. Impact: On the refer failure tone was not aborted. Due to this, the media resources were in the wrong states. So when the SBC tried to revert to original call, it crashed. Root Cause: Design was not aborting the tone on refer failure. This lead to issue in media handling. Steps to Replicate: 1. Initiate a basic C2C from the customer app through KL user to Cisco EP1. At this point, a crash should not happen and the SBC reverts to the original call. | The code is modified to abort tone on refer failure. Workaround: None. |
SBX-100515 | SBX-103402 | 2 | Portfix SBX-100515: Calls are getting rejected with 403 instead of 480, when configured subscribeBurstMax is more than subscribeRateMax. Impact: The subscriber request are getting rejected with 403 instead of 480, when configured, the subscribeBurstMax is more than subscribeRateMax. Root Cause: The EndPoint Rate policy for the SUBSCRIBER request putting into OOD (OUT OF DIALOG) request bucket and request handling was treated as SUBSCRIBER, as a result it response causes the code mapping was not working for subscriber. Steps to Replicate: 1. Configure the subsIngressEndPointRatePolicing in internalSipCauseMapProfile. [set profiles signaling sipCauseCodeMapping internalSipCauseMapProfile <profile_name> causeMap subsIngEpRatePolicing sipCause 480]. 3. Set TG level subscribe rate as 4 in ingress Cac [set addressContext default zone <Ingress_zone> sipTrunkGroup <Ingress_TG> cac ingress subscribeRateMax 4 subscribeBurstMax 6]. | The code is modified to keep the EndPoint Rate policy for SUBSCRIBER in the SUBSCRIBER rate policy bucket. Workaround: None. |
SBX-104347 | 2 | Resource memory congestion level 3 is approaching threshold 90 sample 82. Impact: The SIPCM is leaking a structure that is associated with the SIPMM functionality. Root Cause: The code to free this memory under certain error/edge scenarios is missing. Steps to Replicate: Since we do not know the exact call flow that caused the customer to hit the error condition, we cannot suggest Test Steps. | The code is modified to free the SIPMM related structure in error scenarios. Workaround: Since we do not know the exact call flow that caused the customer to hit the error condition, we cannot suggest a workaround. |
SBX-103634 | SBX-104230 | 2 | Portfix SBX-103634: The LeakSanitizer: detected memory leaks in DCmRestoreAllMetaVarsToStandbyContext. Impact: A small Memory leak was observed in the SAM process while doing a switchover from standby to active box. Root Cause: The standby instance stores information about the metavars associated with signaling ports configured on the active instance. During the conversion from standby to active. The standby data is moved into active structures but the original standby memory blocks are not freed up correctly resulting in a memory leak. Steps to Replicate: Perform a switchover from standby to active while running a basic call, no memory leak will observed in the SAM process. | The code is modified to correctly free the memory associated with the standby data when it is transitioned to active to avoid the memory leak. Workaround: None. |
SBX-103988 | SBX-104546 | 2 | Portfix SBX-103988: The ICE not working after an upgrade. Impact: When a call with ICE changes from direct media to pass through, ICE learning does not get enabled on the call. Root Cause: The code was not re-enabling the ICE FSM to start ICE learning when changing from direct media to pass through. Steps to Replicate: Test 1
| The code is modified to re-enable the ICE FSM when changing from direct media to pass through to allow the receipt and processing of stun messages to complete ICE learning. Workaround: N/A |
SBX-103028 | 3 | The PRS process cored in NP media interface function. Impact: The PRS process cored in NP media interface function. Root Cause: When examining the source code, we found the command sent to NP was not initialized properly. Steps to Replicate: This cannot be easily reproduced. | The code is modified to initialize the command correctly. Workaround: None. |
SBX-98843 | SBX-104448 | 2 | Portfix SBX-98843: Problem with management of the maxptime and ptime in Direct Media mode. Impact: Problem with management of the maxptime and ptime in Direct Media mode. Root Cause: Generally, the SBC ignores the ptime value if only the maxptime attribute is present in incoming SDP. If "sendPtimeInSdp" IPSP flag is enabled and peer is sending both ptime and maxptime, the SBC is preferring maxptime value while sending ptime. The existing IPSP flag "sendPtimeInSdp" makes the SBC send out a=ptime, irrespective of what we receive from the peer. Steps to Replicate: R-i=20 R-e=20
| The code is modified when this new flag "preferPtimeInSdp" is enabled, the SBC prefers ptime value received in a=ptime over a=maxptime in an incoming SDP. This new flag "preferPtimeInSdp" needs be enabled in conjunction with existing flag "sendPtimeInSdp". If the SBC is configured to send a=ptime (isendPtimeInSdp is enabled on Workaround: None. |
SBX-97818 | SBX-103401 | 2 | Portfix SBX-97818: The audio stream with port=0 appears in callDetailStatus. Impact: The audio stream with a port=0 shows up in the . Root Cause: Currently, for an audio stream, there is no condition for stream absent. As a result, an audio stream is retaining even if a port is 0. Steps to Replicate: Video and Audio (Audio Port = 0) | The code is modified for an audio stream so that in a Video and Audio (audio port = 0) call, the audio stream gets removed from callMediaStatus and callDetailStatus. Workaround: None. |
SBX-92770 | SBX-99738 | 2 | Portfix SBX-92770: The SBC is not relaying the INFO coming with the message body to the other leg. Impact: After a call transfer, an in-dialog SIP INFO messages were not relayed by the SBC. Root Cause: The code was missing to handle the relay of the SIP INFO messages received on a transferred leg. Steps to Replicate:
| The code is modified to handle the relay of INFO messages received after call transfer. Workaround: N/A |
SBX-104670 | SBX-104845 | 2 | Portfix SBX-104670: Add the configStore information to the sysdump. Impact: Missing the configStore data to properly investigate the configuration revision issues. Root Cause: Missing the configStore directory content list in the configStore tarball produced by the sysDump.pl. Steps to Replicate: Execute the sysDump.pl and check that virtualLogs/configStore tarbal contains the configStore directory content list. | Add a configStore directory content list in the configStore tarball produced by sysDump.pl to address the issue. Workaround: Get the configStore directory content list directly from the node(s). |
SBX-100590 | 2 | An incorrect "Egress Zone Name" in ATTEMPT CDR for a GW-GW call. Impact: For a call with multiple routes that include one or more local routes followed by routes on another gateway (for GW-GW) scenario, if the local routes fail and then other gateway route is selected, the resulting ingress gateway CDR for the call has an incorrect egress zone name and ID. Root Cause: When there are multiple routes, when a route fails the call cranks back to use the next route but when selecting the next route the code is not clearing the internal CDR information for the egress zone, so if the next route selected is on another gateway the CDR information retains the egress zone information from the previous attempt rather than being blank. Steps to Replicate:
| The code is modified to clear the internal CDR information for the egress zone when one route fails and the next route is selected. Workaround: None. |
SBX-104741 | SBX-104777 | 2 | Portfix SBX-104741: An error message is not displayed while creating an IP Peer, Ingress Ip Prefix, Radius Server. Impact: The error message is not displaying while creating an IP Peer, Ingress Ip Prefix, Radius Server. Root Cause: The error message was not displayed because we handled that error in the code and are unable to send it to the UI. Steps to Replicate: Steps to reproduce the issue:
| The code is modified to throw an exception/Error to the UI. Workaround: If we perform the same operation from CLI , we can get the same error message. |
SBX-104704 | 2 | Duplicate audio entries in the route PSP. Impact: If the number of codec entries in the packet service profile is more than 4, then the ERE was sending the codec entries 5-12 in the policy response twice. The duplicate entries could potentially cause problems when the SBC is performing codec intersection logic resulting in some codecs not being selected so the best audio match might not happen. Root Cause: The ERE was incorrectly calling a function to populate entries 5-12 in the policy response twice. Steps to Replicate: Populate the PSP with more than 4 codec entries in the ingress PSP and egress PSP and review the pes.logs to see the duplicate entries. | The code is modified to remove the functions that populated the codec entries 5-12 in the policy response so they only get return once. Workaround: None. |
SBX-102370 | SBX-103335 | 2 | Portfix SBX-102370: Subscription State is not updated as per expires parameter received in NOTIFY. Impact: The subscription State is not updated based on the expired parameter received in the NOTIFY. Root Cause: The SBC was not processing the expires in the Subscription-State header of the NOTIFY. Steps to Replicate: 1. Run SUB-200 OK. | The code is modified to consider the expires value in header, during the state "active" or "pending". Workaround: None. |
SBX-103669 | SBX-104860 | 2 | Portfix SBX-103669: Empty the "Egress Local Signaling IP Addr" field in the CDR. Impact: When an incoming call is routed out of the SBC but is then rejected by the SBC with cause 132 Module failure before a backwards response message is received, the resulting CDR attempt has an empty "Egress Local Signaling IP Addr" field. Root Cause: The SBC currently populates the "Egress Local Signaling IP Addr" CDR field when it processes a backwards response message for the call, and as a result, the field remains empty until a backwards response message is received and processed. Steps to Replicate:
| The code is modified to populate the "Egress Local Signaling IP Addr" CDR field when sending out the egress INVITE message. Workaround: None. |
SBX-102996 | SBX-103332 | 2 | Portfix SBX-102996: The wrong CSeq number was sent for BYE as part of a call termination after a SBC switchover. Impact: The wrong CSeq number was sent for BYE as part of a call termination after an SBC Switchover. Root Cause: When a In dialog Event INFO is received containing body/content type as 'media_control'. The SBC generates a new INFO request towards peer. Due to this the Cseq, in a dialog gets increased, this modified Cseq value was not mirrored to the SBY. Steps to Replicate: 1. The call is established between PSTN User-B to Cisco User-A. | The code is modified to the SBY during the INFO flow fixes the problem. Workaround: Avoid the fail overs and use the stand alone set up. |
SBX-73860 | SBX-104692 | 2 | Portfix SBX-73860: The SAM process coredumps after a restart during surrogate registration and deregistration. Impact: The SAM process coredumps after a restart during surrogate registration and deregistration. Root Cause: Accessing the pointer without a NULL check causes the core dump. Steps to Replicate:
| The code is modified to avoid a segmentation fault. Workaround: None. |
SBX-74991 | 2 | Saving changes to a SMM profile after doing an edit/update operation is taking long time[8 to 16 minutes]. Impact: A SIP Adaptor Profile with 250+ rules takes lot of time to create, including taking a lot of time to update. Root Cause: When the SIP Adapter Profile with more than one rule is created, each rule is committed individually. However, after each commit EMA internally retrieves all the SIP Adapter Profiles along with their rules, though this is not required it is causing slowness of both create and update operation. Steps to Replicate:
| The code is modified to prevent the retrieval of SIP adapter profiles after each commit. Workaround: The only workaround is to create the profile from the CLI. |
SBX-100702 | SBX-103586 | 2 | Portfix SBX-100702: Observing the "ERROR : Channel 146 already in de-activated state" in the dsp log. Impact: The dsp.log is overwhelmed with the "ERROR: Channel ## already in de-activated state" prints. Root Cause: In the GPU design, as part of the command optimization, if there are more than one command for a channel in a particular time slot, the most recent command for the channel is sent to GPU for processing. Steps to Replicate: Activate and de-activate a channel immediately within 20ms. | The code is modified to disable the prints to not overwhelm the log and impact performance. Workaround: None. |
SBX-102745 | SBX-103361 | 2 | Portfix SBX-102745: The C_LIST macro for consistent memory was freeing. Impact: When making changes to the local auth user configuration on the SBC, it was leaking small amounts of memory. Root Cause: While processing the list of configured users, the application code was reading the CDB information into local buffers and then not freeing it, leading to a small memory. Steps to Replicate: This issue is highlighted when make local user configuration changes in the engineering lab with ASAN images. | The code is modified with standard macros to delete the list structures in a generic manner to avoid this problem in the future. Workaround: None. |
SBX-104851 | 2 | The SBC is down and the standby registration with active failed, error 160004. Impact: Standby is not allowed to join cluster and fails to start Root Cause: The safplus checkpoint file is corrupt and the section needing to be overwritten is not found. Steps to Replicate: The root cause of the checkpoint corruption is unknown/checkpoint corruption cannot be forced and therefore directly testing this fix is not possible. | The code is modified to re-add the missing section if it is not found. Workaround: A complete outage is required in order to restart the active server. |
SBX-105072 | 2 | The password padding with random characters by the SBC causes the RADIUS server to reject the password. Impact: The radius password sent to the server has no zero characters at the end, following the password and a NULL. Root Cause: The radius passwords are padded to 16 characters. The existing implementation did not set those padded characters to 0. Steps to Replicate:
| The code is modified so the padded characters are now set to 0. Workaround: Use 15 or 16 character passwords. |
SBX-104113 | 2 | The LI mediationServer signaling channel was online even if the interface was down. Impact: Without this fix, the LI mediationServer signaling channel stays online, even after ipInterfacegroup attached to call data channel (CDC) is disabled post a switch-over. Root Cause: The root cause came from code handling the LI mediation server signaling socket functionality did not register for ipInterfaceGroup operational status in standby mode. As a result, post switch-over it does not get any notification when ipInterfaceGroup attached to CDC toggles. The signaling connection towards mediation server is not closed. Steps to Replicate:
| The code is modified to register the ipInterfaceGroup that is attached in the CDC in standby mode as well so that if and once it becomes active due to switch-over, it is put into operational status of the ipInterfaceGroup attached to the CDC. Workaround: None. |
SBX-104132 | 2 | Incorrect indication for whether the SMM was applied or not required. Impact: For machine parsing of trace logs, it is necessary to have a consistent field in the trace which indicates the message sent on the wire, regardless of whether the SMM is applied or not. Root Cause: There was a design issue. Steps to Replicate:
| When the SMM is applied to a message, the behaviour is unchanged. When an SMM is not applied to a message, the L1-3 trace has "EXTRA_INFO: After SIPMM profile" and the L4 trace has "SMM: OUTBOUND POST-SMM". When looking for messages as sent on the wire, the post SMM trace can always be used. Workaround: None. |
SBX-102501 | SBX-105036 | 2 | Portfix SBX-102501: The SBC fails to relay an embedded header in Contact of 3xx with statusCode3xx relay enabled. Impact: The SBC fails to relay an embedded header in Contact of 3xx with statusCode3xx relay enabled. Root Cause: The code required to send the embedded part in contact of 3xx was not present. Steps to Replicate:
| The code is modified to set only in the relay 3xx case to send the entire contact header transparently. Workaround: None. |
SBX-94798 | SBX-104272 | 2 | Portfix SBX-94798: MS Teams with FLRBT enabled hangs the call. Impact: When Force Local Ringback Tone is applied on a call that been through SIP replace followed by SIP refer procedure, and the final trunk group has downstream forking enabled, the final 200 OK response may be queued indefinitely, meaning the call does not complete. Root Cause: Interactions between Force Local Ringback Tone, multi-party and downstream forking. Steps to Replicate:
| The code is modified to prevent the queuing. Workaround: None. |
SBX-104826 | SBX-105091 | 3 | Portfix SBX-104826: The SBC fails to relay to 3xx and picks the next route when EnhancedLocalRedirection and StatusCode3xx flags are enabled. Impact: The SBC fails to relay the received 3xx to the ingress side and picks the next route when EnhancedLocalRedirection and StatusCode3xx flags are enabled with 2 routes. Root Cause: When both the StatusCode3xx and EnhancedLocalRedirection are enabled for the 2 routes scenario, performCrankback is set to true that leads to this issue. Steps to Replicate:
| The code is modified to ensure that performCrankback is not set to true when both the EnhancedLocalRedirection and StatusCode3xx are enabled. Workaround: None. |
SBX-104214 | 2 | A SIPREC Codec negotiation issue occured. Impact: Without this fix, the wrong codecs are negotiated with the SRS when communication sessions is renegotiated. Root Cause: Because of the wrong conditions in code, the codec information that is to be sent towards SRS is fetched from peer packet service profile rather than active service profile from the communication call leg. Steps to Replicate:
With this fix, the SBC now sends a re-INVITE with G711A codec to SIPRec server. | The code is modified to fetch correct codec information from the communication session and the same is sent in recording session. Workaround: None. |
SBX-100864 | SBX-103376 | 2 | Portfix SBX-100864: The ASAN detected heap-use-after-free in DnsClientTcpSocketRecvMsg. Impact: When a connection to a DNS server running on transport protocol TCP closes, memory is accessed after it is freed, potentially leading to unexpected behavior. Root Cause: A connection to a DNS server running on transport protocol TCP closes. Steps to Replicate: Address Sanitizer (ASAN) build is used to find the issue. Configure a DNS server with transportProtocol TCP. Run a call which requires DNS lookup. | The code is modified to correct management of DNS connections running on transport protocol TCP. Workaround: None. |
SBX-103814 | SBX-104726 | 2 | Portfix SBX-103814: The RECORDING CDR does not have correct value for SRTP field during a switchover. Impact: The SIPREC related "RECORDING" CDR did not had correct values for SRTP related statistics fields during a switchover. Root Cause: It was identified that there was a missing code that actually copies the SRTP related statistics fields data onto to the standby machine. As a result, whenever the standby machine comes up as active the SRTP related data in RECORDING CDR was not populated correctly. Steps to Replicate:
| The code is modified to copy the SRTP related fields data onto standby machine. Whenever standby machine comes up as active, the SRTP related data in RECORDING CDR is populated correctly. Workaround: None. |
SBX-104213 | 2 | The SCM process cores when targets set for OPTIONS/MESSAGE. Impact: Without this fix, the SBC will core dump when the Out Of Dialogue messages like OPTIONS/MESSAGE are intercepted. Root Cause: The double freeing of a data structure is causing the code dump. Steps to Replicate:
| The code is modified to avoid double freeing of the corresponding data structure. Also addressed couple of memory leaks concerned with the same data structure in error cases such as ARS blacklisting. Workaround: None. |
SBX-76462 | SBX-99744 | 2 | Portfix SBX-76462: The incorrect MaxAverageBitRate value is populated in the "ingress codecParams1" after a switchover. Impact: The incorrect MaxAverageBitRate value is populated in the "ingress codecParams1" after a switchover. Root Cause: Some of the codecs attribute values were being set to 0 after a switchover, and as a result those values were getting assigned to the default values. Steps to Replicate: Run aSILK_NB to SILK_NB call. | To fix the issue, those statements are removed and change the attribute fields as a result. Workaround: Some of the codes use certain attribute fields as being defined. But after the switchover, these used attributes field values have been changed to 0. For those codecs, these statements have been eliminated. |
SBX-95677 | SBX-104725 | 2 | Portfix SBX-95677: The SBC is not feeding delayed RBT on monitoring failure in a late media pass through scenario in CLOUD ISBC and SWE ISBC. Impact: The SBC is not feeding delayed RBT on monitoring failure in a late media pass through call Root Cause: The fix for SBC not feeding delayed RBT on monitoring failure in a late media pass through scenario was applicable only when bToneAsAnnc flag is enabled. Steps to Replicate:
After an RTP Monitoring failure, the SBC should play the tone. | The code is modified to address the issue. Workaround: None. |
SBX-97598 | SBX-103366 | 2 | Portfix SBX-97598: The LeakSanitizer detected memory leaks at SipSgGetHpcCallProfileFromDb. Impact: There was a memory leak when configuring and updating the HPC Call Profile gets the Strings Feature Code, Access Number and Number Translation. Root Cause: Configuring and Updating the CLI Hpc Call Profile gets the Strings Feature Code, Access Number and Number Translation. Steps to Replicate: None. | The code is modified so while de-allocating the list's while retrieving the data in the Feature Code, Access Number and Number Translation. Workaround: None. |
SBX-102985 | SBX-103393 | 2 | Portfix SBX-102985: The CDR field 'Ticks from Set up Msg to Service Est.' of a START record is getting logged with the wrong value. Impact: The CDR field 'Ticks from Set up Msg to Service Est.' of the START record is getting logged with the wrong value when the "End To End ACK" is enabled and "No CDR Change in End To End ACK" is disabled. Root Cause: Since the E2E ACK is enabled and No CDR Change in E2E Ack is disabled, the call connect time was not getting updated during the 200 OK and the value is still '0'. Due to this issue, the time difference of a call attempt time and the connect time was coming as a huge value. Steps to Replicate: 1. Enable IPSP flag "End to End ACK" on both TGs. | The code is modified to not trigger the CDR start record when NRM call stable notification is received. Instead, the modified code delays the CDR until the ACK is received from the ingress, so that, the call connect time gets recorded before generating the start record and addresses the issue. Workaround: None. |
SBX-103807 | SBX-104722 | 2 | Portfix SBX-103807: The SBC disables the SRTP for audio when the EP disables and re-enables the audio. Impact: The SBC disables SRTP for audio when EP disables and re-enables the audio. Root Cause: During the modify offer processing, the SRTP value is taken from previous Active security PSP without checking if SRTP is valid or not. Steps to Replicate: Set up Audio and Video RTP to SRTP pass through call between UAC-UAS:
| Copy the Active security PSP only if the SRTP admin state is enabled to address the issue. Workaround: None. |
SBX-101264 | SBX-102822 | 2 | Portfix SBX-101264: The ingressBearerType and egressBearerType is "multimedia", even though negotiation is only with a single audio codec. Impact: The ingressBearerType and egressBearerType is "multimedia", even though negotiation is only a with single audio codec. Root Cause: At present, the bearerType is set as audio only if Audio stream is present at the first index. As a result, audio only call with audio stream present at index>1 (say (video port=0) + audio (valid port)) gets marked as multi-media call. Steps to Replicate:
| The code is modified to set the bearerType as audio irrespective of the audio stream index if the only active stream present in SDP is audio. Workaround: None. |
SBX-100868 | SBX-103588 | 2 | Portfix SBX-100868: The OAM does not push the configuration after a switchover to the standby OAM. Impact: The configuration changes on the standby OAM is not rejected. After a switchover, it would not take the same configuration changes as it is already done locally. It will not playback either the save and activate as there is no playback logs created. There is no way to push the changes to the managed nodes until another switchover. Root Cause: Skipping the playback log creation on the standby OAM caused an inconsistent state between the local configuration store and the playback logs. Steps to Replicate: Perform a switchover with the same configuration to reproduce the issue. | The code is modified so attempts to make configuration changes on the standby OAM node are now rejected. Workaround: Switchover back to the original active and restart the standby node so that it resyncs with the active. |
SBX-100483 | SBX-103383 | 2 | Portfix SBX-100483: Observed a coredump Comp_SamP after disabling the sipSigPort. Impact: While disabling the SIP signaling port, the SBC dumped core due to system error. Root Cause: In the SBC, the wrong context ID was used to fetch the metavar related information while configuring (enabling/disabling) the SIP signaling port. As a result, the SBC has generated a system error. Steps to Replicate: Bring up a Public Cloud (AWS) 1:1 HA system. Restart the standby SBC node. Try to disable the SIP signaling port. The SBC generated the coredump due to system error. | The code is modified to pass the correct context ID information while fetching the metavar related information while configuring the SIP signaling port. Workaround: Execute the disabling of the SIP signaling port when the standby is up and running. |
SBX-102927 | SBX-105029 | 2 | Portfix SBX-102927: The problem with migration of table_version_info was causing the EVS codec attributes non-readable after upgrade from 7.2 to 8.2. Impact: The upgrade fails to set the default value for maxChannel flag. Root Cause: The table_version_info table was not getting populated. Steps to Replicate: The table_version_info table should have data on fresh install. | The code is modified to address the issue. Workaround: The value in db for attribute3 in code entry table should be modified to set the default value of maxChannels. |
SBX-93308 | SBX-97314 | 2 | Portfix SBX-93308: No DLRBT Tone Play can be heard on User-A phone in a Blind Transfer scenario using 180 ringing with SDP. Impact: There is no DLRBT tone play heard on the transferee while transferrer does a blind transfer. Root Cause: When 180 with SDP received from transfer target, SBC is trying to activate the tone resources towards transferee side. But, before this tone activation occurs, the CUT_THRU is received from the transferred leg that is causing to abort the tone. Steps to Replicate:
| The code is modified so it ignores this CUT_THRU received from the transferred leg and as a result, the tone is not getting aborted. When a CONNECT or RTP packet is received, then the tone is aborted. Workaround: N/A |
SBX-104149 | 2 | The SBC fails to send ACK for a self generated re-Invite when the E2E ACK and E2E re-Invite flags are enabled. Impact: The SBC fails to send ACK for a self generated re-Invite when the E2E ACK and E2E re-Invite flags are enabled. Root Cause: When both the E2E re-Invite and E2E Ack are enabled, do not send the ACK re-enable, the SBC was not handling ACk properly for the self-generated re-Invite. There are scenarios when E2e is received RCVD from the Network where the ACK does not need to be sent for a re-Invite from the SIPSG in race condition scenarios. So there was no check to identify if the re-Invite is self generated or the RCVD from a network and wrong logic was executed for the self-generated Invite. Steps to Replicate: Test Configuration:
| The code is modified so if the re-Invite is self generated then send ACK. Workaround: None. |
SBX-99409 | SBX-99697 | 2 | Portfix SBX-99409: The EMA is not displaying all recordings for the SIPREC status command. Impact: The proper SIPREC status was not displayed when more than one recording going on for a specific call on EMA or when checking the status with all the set of keys on the CLI. The SipRecStatus command was updated with new keys (GCID, legId, Recorder IP:port) but the application had a issue that it looked up the data only based on the GCID. Root Cause: When the status command is issued through the EMA, the EMA queries with all the keys and as a result, the application would end up fetching the first recording for each of the queries. Same thing happens when querying on CLI with all keys for specific entry we end up getting first entry for that GCID. As an example, when a quad recording is in progress on GCID1, when the SipRecStatus is queried using EMA, the EMA would query based on keys for each of the recording, say Steps to Replicate:
| The code is modified to receive all the keys of the SIPREC status and display the correct information. Workaround: Check the status on the CLI without specifying all set of keys for the SIPREC status, |
SBX-104705 | SBX-105107 | 2 | Portfix SBX-104705: There was a memory leak on the glusterfsd. Impact: During a soak test on OAM, it was observed that the third party software glusterfsd process was leaking memory. If this occurred over a long duration, the OAM could run out of memory and a core would occur to that process. Root Cause: The memory leak is observed for the glusterfsd process, which is the brick process. The use of the "gluster volume heal info" function causes the process memory usage to increase and not go down afterward. Steps to Replicate:
| Use the "gluster volume heal statistics heal-count" command to determine the gluster bricks heal state. Workaround: Reboot OAM node OR Execute: gluster volume stop gvol1; gluster volume start gvol1. |
SBX-737 | SBX-105413 | 2 | Portfix SBX-737: The support for the 3072 bit long RSA keys is missing. Impact: The SBC needs to support the 3072-bit RSA keys in certificates. Root Cause: A feature change was required to support the 3072-bit RSA keys in certificates in addition to the 2048-bit and 4096-bit RSA keys. Steps to Replicate:
| The code is modified for the 3072-bit RSA keys in certificates. Workaround: None. |
SBX-105363 | 2 | Unable to access any log with the Platform Manager and EMA. Impact: Unable to access log with the EMA and PM. Root Cause: The jquery.ui.datepicker was not removed as this is updated in the jquery-ui.min file. Steps to Replicate:
| Remove the jquery.ui.datepicker from the html file to address the issue. Workaround: None. |
SBX-102364 | SBX-105456 | 2 | Portfix SBX-102364: The SBC behavior is inconsistent with the isfocus parameter handling. Impact: Issue 1: The SBC is not transparently passing the complete Contact header in 200 OK of SUBSCRIBE when there is a isfocus parameter. Issue 2: The SBC is not adding the Record-Route in any message when doing a full Contact header transparency Root Cause: Issue 1: The SBC passes contact header transparently only when the isfocus is present in request as well as response and would not send the contact header transparently only when the contact header in response has isfocus parameter. Issue 2: The code to add a record route for notify and its response is not present. Steps to Replicate:
| Issue 1: The code is modified to check if the service bit is not set (for the response) and check if the contact header has the isfocus parameter, if the parameter is present, set SIP_SERVICE_TYPE_CONTACT_TRANSPARENCY_FOR_ISFOCUS_PARAM for a single contact scenario. Issue 2: The code is modified to add the record route for notify and its response if isfocus parameter is present. Workaround: N/A |
PSX-35183 | SBX-104660 | 2 | Portfix PSX-35183: Setting the PSP with transcode conditional and then change it back to the TFT, all the settings from ‘conditionsInAdditionToNoCommonCodec’ are not reset back to the default values and in some cases affect call processing. Impact: When the transcoder free transparency (TFT) is enabled and some of the ‘conditionsInAdditionToNoCommonCodec" flags are enabled too, the call processing may be different than when only TFT is enabled. Root Cause: In the original design, flags of "Conditions In Addition To No Common" are Steps to Replicate:
| The code is modified to set all flags of "Conditions In Addition To No Common" to disable whenever the PacketToPacketControl's transcode is set to "Transcoder Free Transparency". Workaround: Before changing the transcode to "Transcoder Free Transparency".
|
SBX-104990 | SBX-105465 | 2 | Portfix SBX-104990: In a secure call, the SBC does not increment port number in R-URI after processing Refer. Impact: In a secure call with TLS configured, if the call is REFERed with a REFER-TO header containing a FQDN and port number, the SBC sends out new invite to the specified FQDN and port number. If that INVITE fails and the SBC then sends a subsequent INVITE on the next route it does not correctly increment the RURI port number for TLS. Root Cause: The SBC code does not take into account that a re-route after a REFER-TO with FQDN and port number target needs to increment the port number for TLS, if the target after the re-route is different to the original target specified in the REFER-TO. Steps to Replicate:
| The code is modified to increment the RURI port number for TLS if doing a re-route to a target FQDN and port number that is different to the original target specified in the REFER-TO. Workaround: None. |
SBX-105319 | 2 | The SBC is not able to parse MSRP media packet 200. Impact: When the SBC received "200" as MSRP response, it did not forward the same to other end as it considers 200 as a invalid response in absence of "OK" string in 200. Root Cause: The SBC was strictly parsing "200 OK" for MSRP success response due to that if it is received "200" as response, it did not forward the same to other end. Steps to Replicate: Test 1:
Test 2:
| The code is modified to consider 200 as valid MSRP response. Workaround: There is no workaround at the SBC for this issue, UAC/UAS need to send MSRP response as "MSRP <transaction-id> 200 OK" to avoid this issue. |
SBX-100122 | SBX-104972 | 3 | Portfix SBX-100122: There were various display issues related to media port range modifications. Impact: Issue 1,2,3: The CLI display of mediaPortRangeUnassigned to TGs was not regulated by the system media port range setting, causing the mediaPortRangeUnassigned CLI command displaying the wrong ports. Issue 4: If the basePorts for different TGs are the same in a same zone, their maxPorts will be added up in CLI display of mediaPortRangeAssigned. tcpPortRangeAssigned has the same problem. Root Cause: Issue 1,2,3: The root cause was that the SBC had not considered the system media port range setting as restriction when calculating unassigned ports. Issue 4: The root cause was that assigned media port range map had not been indexed by TG, but by basePort had been a mistake. Steps to Replicate: While working on the SBC CLI
| The code is modified for the following issues:
Workaround: It is a display issue, does not impact call. |
SBX-91111 | 2 | There was a No Way Video after A/V calls is resumed after hold. Impact: There was a No way video after a audio video call is resumed using a late media re-INVITE. Root Cause: The SBC does not send "sendrecv" in 200 OK for late media re-INVITE, and instead sends the same datapath mode that was negotiated last, which could be inactive. Steps to Replicate: Set up a audio and video call. Put the call on hold by sending a=inactive in audio and video SDP. Then send a late media re-INVITE to take the audio off-hold. The SBC will send SendRecv for audio and video in 200 OK and let the remote end choose if it wants to remain on hold or come out. | The code is modified to send a sendrecv for other streams when the audio in call is being resumed aftera hold. Workaround: Do not use late media re-INVITE to come out of hold. |
SBX-105262 | SBX-105635 | 2 | Portfix SBX-105262: The SBC is sending unexpected Re-INVITE to egress side in SRTP early media scenario. Impact: The SBC is sending unexpected Re-INVITE to egress side in SRTP early media scenario. Root Cause: This issue is caused because of a side-effect of SBX-103807. Steps to Replicate: Call flow:
| Copy the active security PSP only if audio stream is present to address the issue. Workaround: None. |
SBX-105114 | SBX-105701 | 2 | Portfix SBX-105114: Usage of the kill command output in active and standby CE_node logs. Impact: The kill command usage gets printed in the CE_Node log file of the managed nodes. Root Cause: No glusterfs process is present when the kill command is executed by the glusterSetup.sh script called by sbxConfigUpdater.sh. Steps to Replicate:
| Redirect kill command error output to /dev/null to address the issue. Workaround: None. |
SBX-104360 | SBX-105562 | 2 | Portfix SBX-104360: The SWITCHOVER ACT Records are not generated in the SBC with the HA mode set as Nto1. Impact: On an N to 1 system, the SWITCHOVER record is not written to the accounting file on the new active node after a switchover. Root Cause: The SWITCHOVER record is sent to the ENM process before it has opened the accounting file, so the record is not written. Steps to Replicate:
| The SWITCHOVER record is stored and then written out when the accounting file is opened to address the issue. Workaround: None. |
SBX-86090 | SBX-104236 | 2 | Portfix SBX-104236: Our SIPREC implementation is prone to failure to record a stream and to tear down the SRS call leg when SRS (SIP Recording Server) sends a re-INVITE to SBC. Impact: SIPREC handling had race conditions issues in the scenario where a RE-INVITE was received on the main call and also RE-INVITE was received from SRS server at the same time. This resulted in recording failure and the SBC sent out BYE towards SRS. Root Cause: This race condition of RE-INIVITE from the main call end point and SRS server simultaneously was not handled on the SBC. Steps to Replicate:
| The RE-INVITE triggered/sent towards SRS due to the main call RE-INVITE is queued in the situation where the SIPREC leg is in middle of processing the RE-INVITE that was received from the SRS. The queued RE-INVITE is sent once the RE-INVITE transaction received from the SRS was completed. Workaround: The SRS can avoid sending an immediate hold RE-INVITE if no media is observed on SIPRec leg. |
SBX-104325 | 2 | There was a SCM coredump observed when multiple gateway TGs are created in a GW-GW call on a HA set up. Impact: On a HA set up, the Standby box SCM Process dumps core when the Standby starts to sync from Active, post a switch over, and the switch over occurs after a scenario where the Gateway TG's are created and then a GW TG with a lower index (Created earlier) is deleted. Example:
Root Cause: The coredump is caused due to difference in indexing of gateway TG's in active and standby boxes. The GW TG indexes were out of sync between the Active and Standby. The Active SBC had holes in the indices of the GW TGs after deletion. The standby SBC does not have holes for the GW TGs that are present post deletion and occupy different index when compared to active. Steps to Replicate:
| The code is modified to ensure that the GWTG indexes on the Active and Standby are in sync. Workaround: None. |
SBX-104975 | 2 | The MCF sent back to ingress as the MPS. Impact: Some fax T.38 endpoints send entire DCS V.21 signal in one packet as opposed to 1 octet per packet. This can causes fax failures. Root Cause: A burst of octets in a single packet is essentially a burst, and causes potential problems as these packets get queued for modulation and cause delay and later TCF (high speed) signal some packets get dropped. Steps to Replicate: This issue was reproduced with a T.38 capture from field that contains a DCS followed by a TCF and a page. | The code is modified to accommodate larger bursts. Workaround: This bug is a specific interoperability problem with endpoints that exhibit burst single packet DCS signals. For such endpoints, we do not have a workaround, unless there is some configurations are available on those devices to modify this behavior. |
SBX-105736 | 2 | Sending m=application 0 UDP/BFCP (null) in case of UPDATE. Impact: The SBC sends m=application line in incorrect format in SIP UPDATE message. Root Cause: The SBC does not format the m=application line for UDP/BFCP when sending UPDATE message. Steps to Replicate: Test case 1: Reproduce the issue: The SBC sends an INVITE with SDP(with audio and video lines and m=application) and receives rel 18x with SDP (with audio and video lines only) followed by the final 200OK with SDP (with audio and video lines and m=application) if flag is enabled then SDP of 200OK should be ignored by the SBC. UPDATE message content: m=application 0 UDP/BFCP (null) Test case 2: Verify the issue the same scenario as test case 1. UPDATE message content: m=application 0 UDP/BFCP * | The code is modified to ensure the SBC sends the m=application line in correct format. Workaround: None. |
SBX-105610 | 2 | There were coverity issues in OAMNODE. Impact: When processing a show list command under the node branch from the OAM node, if the target node fails to read the command path in the request, the code will access memory immediately after freeing it. While in most cases this should not cause issues, accessing memory after it is freed is not good behavior and could result in unexpected behavior and potentially in the worst case coredumps. Root Cause: Error handling flow in the code is incorrect. It hits some code for the success flow. Steps to Replicate: Run coverity tests to reproduce the issue. | The code is modified to address the issue. Workaround: None. |
SBX-105361 | SBX-105881 | 3 | Portfix SBX-105361: The SSH access was not re-enabled on SBC 5400 for the linuxadmin after an upgrade. Impact: The SSH is enabled for root user in SBC 5400 after LSWU or PM upgrade. Root Cause: The getVirtualType function in sonusUtils.sh incorrectly set the virtual type on the SBC 5400. Steps to Replicate: Enable the SSH and run the LSWU, the SSH should not enable for root user. | Validate the previous virtual type in getVirtualType function to address the issue. Workaround: None. |
SBX-105270 | SBX-105608 | 2 | Portfix SBX-105270: There was a cpxAppProc leak for a MRFP call. Impact: There was a small memory leak occurs on SBC/MRFP nodes when action/status/stats under the node branch is accessed through the OAM node CLI or EMS. Root Cause: Resource references are cleared mistakenly after serving the request from the OAM node. Steps to Replicate: Execute a node branch command repeatedly and monitor the CPX process size on the target node. | Resource references are cleared only when the system is shutting down to address the issue.. Workaround: Avoid using node branch commands in automated/periodic operations. Manual use should be ok as the leak is small. |
SBX-102700 | SBX-106067 | 2 | Portfix SBX-102700: Number mapping (translated, RDI, To hdr, R-URI) is odd. Impact: The SBC is not adding translated number received from PSX to RequestURI when Diversion header is present in the ingress Invite. Root Cause: If ingress Invite does not contain Diversion header, then SBC is adding translated number to RURI. So same result is expected when diversion header is present. Steps to Replicate:
| The code is modified to populate the RequestURI with the translated number even when the Diversion header is present in the initial Invite. Workaround: None. |
SBX-103222 | 2 | The SBC is not sending an INVITE to the MRF for a modified transcode call. Impact: Run a MRF call flow by configuring the MRF profile. Root Cause: The MRF Profile values are not correctly read by the application. Steps to Replicate: 1. Configure the System for doing the MRF call flows. | The code is modified to read the values from a proper MRF path. Workaround: The sbxrestart should solve the issue. |
SBX-106004 | SBX-106240 | 2 | Portfix SBX-106004: The EMA display error when SMM deleted through the CLI. Impact: The EMA display error when SMM deleted through the CLI. Root Cause: In the EMA, we are checking the ordering of the rules. If the Order is not continous then we are throwing the error. Steps to Replicate:
| The code is modified to address the issue. Workaround: None. |
SBX-104759 | 3 | The IPv4 Path MTU Discovery (RFC1191) not working for the UDP. Impact: The SBC uses the MTU of the outgoing network interface as the Path MTU when sending out SIP-UDP packets. Without the fix, the SBC does not update Path MTU properly even if a router in the path sends "ICMP Destination Unreachable Fragmentation Needed" message with smaller Path MTU value. The large packets requiring fragmentation to fit the Path MTU from the SBC will not reach the SIP peer. Root Cause: While handling "ICMP Destination Unreachable Fragmentation Needed" error message for UDP packet, route/fib lookup did not consider ipInterfaceGroup and addressContext. This resulted in not updating Path MTU of the proper route entry to the peer for sending SIP-UDP packets. Steps to Replicate: The SBC sends SIP-UDP packets of length 1500 bytes toward the SIP peer when a path to the peer has a smaller MTU. A router with the smaller MTU sends "ICMP Destination Unreachable Fragmentation Needed" to the SBC. Without the fix, the SBC keeps on sending SIP-UDP packets, and the router keeps on sending "ICMP Destination Unreachable Fragmentation Needed" to the SBC. The SBC, with the fix, adjusts the Path MTU, performs the fragmentation on SIP-UDP packet and sends fragments to the SIP peer. | The code is modified to add ipInterfaceGroup and addressContext information in handling ICMP Destination Unreachable Fragmentation Needed message in the Linux kernel. Workaround: Disable Path MTU Discovery by setting ipNoPmutDisc value to. admin@SBCSWE03% set system admin sbcswe03 kernelParams ipNoPmtuDisc 2 Note: The support for ipNoPmutDisc was added to 7.2.5R000, 8.2.4R000, and 9.2.0R001. |
SBX-103986 | SBX-104442 | 2 | Portfix SBX-103986: There was an incorrect RTP time stamp in the SBC packet capture. Impact: After an SBC upgrade, RTP/RTCP time stamp in the SBC packet capture shows the year 2036. Root Cause: Present logic was not considering the edge cases while checking the last modification time of the NTP log. Steps to Replicate:
| The code is modified for the edge case of NTP log last modification time. Workaround: None. |
SBX-105281 | 2 | AddressSanitizer error: heap-use-after-free on the address 0x6190000ba218 at pc 0x56473eecd69f bp 0x7f27682167e0 sp 0x7f27682167d8 Impact: The heap use after free error while running the PC2 ingress leg interception on OPTIONS/200OK call SBC_8.2x ASAN Build. Root Cause: For the 4C, is using memory that is free by previous code. For the 6, the leak due to a missing null check. Steps to Replicate:
| The code is modified in the following manner:
Workaround: None. |
SBX-106149 | 2 | The PSP qos value msrpDscp non-zero causes a PES process crash. Impact: The PES process crashes when the apps are starting up and if msrpDscp in the PSP QoS values are configured with non-zero. Root Cause: A debug statement tried to print a integer as a string, causing memory problem. Steps to Replicate:
Before the code change, the PES will crash. After the code change, the PES will not crash. | The code is modified to print integer as integer. Workaround: None. |
SBX-102277 | 2 | The debug command caused the SCM process to core dump. Impact: We are hitting a Healthcheck timeout when displaying the output of the following debug command: Root Cause: The Heathcheck timeout error occurs due to taking too long to display the data for all of the service groups when there are very large number of trunk groups configured. Steps to Replicate:
| The code is modified to only display up to 50 service groups in order to prevent this Healthcheck timeout. Workaround: To prevent this issue, avoid using the following command if there are large number of TGs configured: |
SBX-102478 | SBX-103385 | 2 | Portfix SBX-102478: An Automated Upgrade failure for the SLB/SBC from 9.0 to 9.1. Impact: The newly upgraded OAM VM did not properly boot. On the investigation, it was seen that the Cluster IP was not set correctly, even though an upgrade was received from VNFM, which contained the correct Cluster IP. Root Cause: The updated userData.json received from VNFM was overwritten with the initial boot userData.json (that did not contain the Cluster IP), even though there is code in convertVnfm.py specifically to prevent that from happening. On investigation, it was seen that a bad propagation of fixes from other releases into main introduced an indentation problem. Indentation is significant in python, and the bad indentation made the code that checked for an updated userData.json fail to work properly. Steps to Replicate: Use different types of auto-upgrades should be tested, because they seem to expose the problem with non-updated userData.json more easily than a normal orchestration. | The code is modified so the correct indentation is restored. Workaround: If the orchestration is failing without this fix, a restart of the VM should be manually triggered to have it re-run the code in question. This needs to be done before VNFM fails the upgrade (1 hour). |
SBX-103720 | 3 | There is packet verification improvements for T.38 stack. Impact: In some of the crashes from the field (e.g. SBX-101155), we have observed a frame in jitter buffer that has unreasonably large fld_cnt as compared to the size of the packet itself. This is a malformed packet and such packets may lead to crashes. Root Cause: These malformed packets are the root cause. Steps to Replicate: TBD | The code is modified to look for UDPTL packet size and frame size inconsistencies and to allow packets with inordinate field count to be accepted by the stack. This logic is improved to reject such packets. Workaround: None. |
SBX-103771 | 2 | Special characters in the DN hinders the EMA display. Impact: Special characters in DN are throwing error in the EMA. Root Cause: Special characters were not supported for the DN through the EMA UI. Steps to Replicate:
| The code is modified to address the issue. Workaround: None. |
SBX-106509 | 2 | Restoring the backup SMM configuration is failing. Impact: Restoring the backup configuration was failing. Root Cause: This issue is caused because the loadConfig was failing because of errors in HwModuleServer.cpp file. Steps to Replicate: Run a load configuration from the CLI, and configure the load properly. | The code is modified to address the issue. Workaround: None. |
SBX-105340 | 3 | The reenableOsAccount silently sets the account expiration to 30 days. Impact: Using the reeanbleOsAccount will add account aging to any OS account. Root Cause: The logic does not take into account state of OS account aging or if OS account aging should be applied (e.g. root). Steps to Replicate: With the OS account aging enabled: 1. Test the root: 2. Test the Confd user: 3. Test the OS user with a password: | The code is modified to check in the OS account aging is enabled and is applied. Workaround: None. |
SBX-106256 | 2 | The Control Display of Table Columns is not working for the DiamNode EMA page. Impact: The Control Display of Table Columns is not working for the DiamNode EMA page. The options selected by the user were not retained and maintained properly when the user navigates to some other page Root Cause: Missing Null Checks on a userName parameter while updating the columns in DiamNode Page. Steps to Replicate:
| The code is modified to ensure that exceptions are handled appropriately. Workaround: None. |
SBX-103135 | 2 | The SBC was sending an INVITE with incorrect b= line values. Impact: The SBC sends the wrong RR and RS values in the outgoing INVITE for a transcoded call. Root Cause: On the D-SBC, the NrmaComputeOfferPspForAnswerLeg() gets executed twice when intersecting. Once with ingress route PSP and once with egress Route PSP and even though we pass the right route PSP to the function, the rtpOptions passed to the function is wrong that results in the wrong computation of RR and RS values. Steps to Replicate: The SBC is configured to make a SIP-SIP call procedure: | The code is modified to pass the correct rtpOptions for computing the RR and RS values. Workaround: None. |
SBX-105256 | 2 | The SBC was sending AMR-WB twice and the SBC was accepting codec in answer that is not present in offer Impact: In a Late Media Call with HD Codecs configured in the Route PSP, the SBC was sending 2 HD codecs in its offer towards the Egress even when the "preventSameCodec" configuration flag is enabled in Trunk Group. Root Cause: The SIPSG module was not passing the "preventSameCodecTransCode" flag to NRMA for Late Media calls. Steps to Replicate: The steps cannot be replicated. | The code is modified to now pass the "preventSameCodecTransCode" flag for late media calls. For normal media calls, this is working in 8.2.3 releases Workaround: None. |
SBX-100320 | SBX-105238 | 2 | Portfix SBX-100320: There were SBC 9.1 coverity issues. Impact: In several modules, coverity pointed illegal access of NULL pointer, that may cause a crash in code. Root Cause: Illegal use of pointers, without checking whether they are NULL or not. Steps to Replicate: After running the coverity, the illegal access of pointers were not encountered again. | The code is modified to correctly check the pointer, whether it is NULL or not. If it is NULL, then no further processing of that pointer is done Workaround: None. |
SBX-98015 | 2 | LSWU. Call/Registration Data syncInProgress. Impact: Issue#1: Upgrade failures with EDNS Feature The LSWU Upgrade from the SBC from pre 8.2 release to a 8.2 or higher release fails when EDNS servers are configured. When the ednsServer statistics table has non-zero values for the field “ednsFailures”, the SBC synchronizes the stats structure. Since the corresponding structure does not have serialization support, the sync is aborted and the upgrade fails. The ednsFailures stats are updated when the SBC encounters RCODE 1, 2 and 4 errors for EDNS qeueries. Example pre-8.2 configuration causing this issue: admin@PLUM> show status addressContext default dnsGroup DnsGrp Issue#2 Root Cause: Issue#1: Upgrade failures with the EDNS Feature There are multiple issues in serialization support for DNSC_REDUND_MIRROR_EDNS_SERVER_STAT_INFO_CMD_MSG_STR
Issue#2: The EDNS Status was lost Steps to Replicate: Procedure:
| The code is modified to handle the LSWU Upgrade of SBC from pre 8.2 release to a 8.2 higher release. Workaround: Issue#1: Upgrade failures with the EDNS Feature Before upgrading a box that is older than 8.2R0, the following commands on all the DNS Groups needs to be issued before we upgrade. Note: The ednsServer stats is lost as a consequence during the upgrade.
Issue#2: The EDNS Stats was lost. No workaround. |
SBX-104533 | 2 | The high CPU Utilization was observed on GPU UXPADs with 1152 chans/process. Impact: The transcoded calls using FMTD (Fax and modem tone detection) require most CPU cycles than expected. As a result, in a loaded system higher than expected CPU utilization is observed. Root Cause: Root cause for this is that the FMTD module code was checked in with a debug compiler flag. The debug flag results in code is less optimal and consumes higher number of CPU cycles. Steps to Replicate: This requires a use of high load to observe the problem. Typical with GPU use, the expected numbers are about 18432 G729A-G711U calls with a max UXPAD utilization to be 80-81%. Due to this bug, 90% CPU utilization is observed with about 13k calls. As a result, the test steps are:
With a fix, the utilization should be same as that for 8.1.0R6 as a comparison. | The code is modified to make a file for the FMTD module to remove the debug flag and then rebuild the optimized library. Workaround: None. |
SBX-104827 | 3 | The SBC was terminating the call when a 491 response is received for the self generated Re-INV. Impact: The SBC is terminating the call when a 491 response is received from a Peer for the self generated Re-INV. Root Cause: When a 491 response is received from the peer for the self generated Re-INV, the SBC is treating this as an error response and as a result, generates a internal clear event and the call is getting terminated. Steps to Replicate: IPSP flag configuration: DML flag disabled.
| The code is modified so that the call will not get terminated. Workaround: None. |
SBX-100912 | 3 | The search filter tab for Routing page in EMA is not working properly in 8.2.1R1. Impact: When user try to perform search for # % & _ in filter tab of EMA route page, results were not fetched as expected. Root Cause: The search values are not encoded before making a request to get results. Steps to Replicate:
| Encoding the values before making the request to get exact results addresses the issue. Workaround: None. |
The following 08.02.03R000 Severity 1 issues are resolved in this release:
Resolved Issues
Issue ID | Sev | Problem Description | Resolution | |
---|---|---|---|---|
1 | SBX-101131 / SBX-101057 | 1 | Portfix SBX-101057 (Originated in Release 7.2.5): The iceSupport and SMM iptgStore coredumped. Impact: The iceSupport and SMM iptgStore configuration, and an invalid incoming call may caused the SBC to core. Root Cause: After a response failure to the invalid call, the SBC still tries to initiate set up call. As a result, it accesses the invalid address. Steps to Replicate: Configure the iceSupport and SMM storeIPTG, incoming call with invalid candidate (no UDP). | The code is modified to not try to initiate set up call if the call fails. Workaround: Use the SMM to drop an incoming call. |
2 | SBX-100088 | 1 | There was a switchover after the TLS certificates were renewed. Impact: When certificate is modified, an old certificate is freed and new certificate is updated. But after freeing the old certificate, the pointer is not set to NULL that can cause undefined behavior due to an invalid access. Root Cause: The issue is when the customer modified the certificates through the CLI, it resulted in the SAM process to core. This is due to memory corruption. Steps to Replicate: Changing the TLS certificates when the TLS load is running will result in memory corruption and the core can occur any time if there is active TLS load running and if the existing TLS calls try to access the certificates that were deleted already. | Set the pointer to NULL so that there is not invalid access to the pointer. Workaround: N/A |
3 | SBX-101050 | 1 | The SBC SWe was not generating a switch over trap-sonusCpRedundGroupSwitchOverNotification. Impact: A switchover notification trap may not be generated. Root Cause: The event, used to generate the trap, is incorrectly dropped due to the logic that thinks the event is stale. Steps to Replicate: Perform switchover and ensure the trap is properly generated. | The code is modified to improve the event handling so that the necessary events process and do not mistakenly drop. Workaround: The problem only occurs during slow processing. Avoid anything that can slow processing down like info level logging, or any external influences on the disk. |
4 | SBX-98177 | 1 | There was an issue with the SBC 7000 TCP window size. Impact: Add the CLI support to set kernel parameter net.ipv4.tcp_window_scaling Root Cause: In certain SBC deployment scenarios (a large number of devices running SIP-TLS), tcp_window_scaling caused small TCP window size. In such cases, the customer had to use Linux command to disable tcp_window_scaling on each SBC node. Steps to Replicate: (1). Show initial setting for tcp_window_scaling on both active (SBCSWE01a) and standby (SBCSWE01b) (2). Use CLI to change the kernel param value and display the changed value on both active and standby. [root@SBCSWE01a ~]# cat /proc/sys/net/ipv4/tcp_window_scaling [root@SBCSWE01b ~]# cat /proc/sys/net/ipv4/tcp_window_scaling | The code is modified to fix the issue and the Linux command is no longer needed with the modified code. Workaround: Use the Linux command to set the kernel parameter on both active and standby. [root@SBCSWE01a ~]# sysctl net.ipv4.tcp_window_scaling To be persistent across the SBC restart and system reboot, use the Linux the following shell command on both active and standby. |
5 | SBX-97791 | 1 | There was a switchover with the PRS process coredumping. Impact: The PRS process coredumped due to memory corruption. Root Cause: Customer encountered a PRS process core due to the memory corruption that happened earlier in processing. The core is the after effect of earlier corruption. Steps to Replicate: None. | The code is modified to avoid the core, and to collect more diagnostic data if a core happens again. Workaround: N/A |
6 | SBX-101119 / SBX-100779 | 1 | Portfix SBX-100779 (Originated in Release 7.2.5): The SBC was adding an extra application/ISUP ACM content. Impact: The 200 OK Bye has duplicated the ISUP body. Root Cause: When the e2e Bye is enabled, 200 OK has duplicated the ISUP body. Steps to Replicate:
| The code is modified so the SBC does not create an isup body internally for the e2e Bye and isupMimeBodyRelay. Workaround: Disable the e2e Bye. |
7 | SBX-100164 | 1 | There was a back-to-back coredump on the Server. Impact: The SCM process cored due to memory corruption while parsing an INVITE with a very long and invalid CallId field, while the parseError trace logging was enabled. Root Cause: The SCM process coredump is caused by memory corruption that is the result of the Trace Logging code overwriting a buffer. This can happen when the SIP parser encounters an invalid CallId that is also very long. Steps to Replicate: This can be reproduced by enabling the parseError trace logging and then sending a INVITE that includes a badly formatted CallId, which is the maximum allowed size for a CallId: | The code is modified to not overwrite the end of the buffer when it is attempting to write a very long error message string. Workaround: Disable the parseError tracing. |
8 | SBX-99850 | 1 | A BYE message was sent to the wrong port. Impact: The SBC does not update remote connection address when refresh INVITE is received from different port. Root Cause: When the endpoint is registered over TLS initiating a call and after the call is established, the endpoint sends a refresh register from a modified port. When a refresh INVITE is sent with no SDP change, the SBC does not send BYE to a modified port when the call disconnects. Steps to Replicate:
| The code is modified to ensure the SBC updates the remote address when refresh INVITE is received from modified port. This ensures when the registration is required and for a TLS connection, after the call is released BYE is sent to correct port. Workaround: N/A |
9 | SBX-100223 | 1 | The SMM for changing ISUP message inside SIP-I does not work properly. Impact: When a message is received with mime content having single msgbody, then after the SMM application on the msg body, the SBC re-formats it as a normal msgbody instead on the mime content. The re-formating was not handled properly. Root Cause: When a message is received with mime content having single msgbody, then after the SMM application on the msg body, the SBC re-formats it as normal msgbody instead on mime content. Steps to Replicate:
| The code is modified so that whenever the SBC re-formats the mime body after the SMM application it formats correctly. Workaround: N/A |
10 | SBX-101693 / SBX-101294 | 1 | Portfix SBX-101294 (Originated in Release 7.2.5): Intermittently, the SBC SWe accesses the sipSigPort for sending the SIP messages to the core side. Impact: The relay options with registration may route to the wrong Sip Signaling Port and causing call fails from AS to IAD. Root Cause: When the IAD sends a registration from SSP1 and relay options from an other SSP2. Since the options from the SSP2 do not match with RCB from SSP1, the SBC treats the options from the AS, triggering an invalid routing to the wrong destination. Steps to Replicate: Configure the SSP1 and SSP2, and enable maskRcbPort. The registration from SSP1 succeeds. Options from the SSP2 will trigger a relay back to the IAD (not AS). Subsequent calls from AS may fail or refresh registration. | The code is modified to detect the relay messages from the IAD or AS based on RCB looks up (not just based on SSP). Workaround: Disable the maskRCBPort. Or use the SMM to make the SBC respond to OPTIONs (not relay). |
11 | SBX-100332 / SBX-100479 / SBX-100480 | 1 | Portfix SBX-100479/480: Observed DSP and MAJOR logs coredumps on the 7000 Platform while running the ICM Scaling suite. Impact: The DSP and MAJOR logs coredumps on the 7000 Platform. Root Cause: Certain variables used in the interrupt context were not protected while being modified outside the interrupt. This impacted the inter-core health-check logic at the DSP and incorrectly led to an error being reported, eventually leading to a coredump. Steps to Replicate: From an HA Pair of fully loaded SBC-5100/5200/5110/5210/5400/7000
| The code is modified so variables are now interrupt-protected. Workaround: N/A |
12 | SBX-101676 / SBX-101547 | 1 | Portfix SBX-101547 (Originated in Release 8.2.2): There was a switchover and coredump after call placed on hold. Impact: The code was dereferencing a null pointer and causing the SCM process to crash. Root Cause: The customer had the passThruPrivacyInfo control enabled on both the ingress and egress privacy profiles. But the ingress side of the call did not pass through some expected information related to the INVITE message and it caused the code to dereference a null pointer. Steps to Replicate: Unable to reproduce this issue, the code is fixed based on code review and coredump analysis. | The code is modified to validate the pointer is not null before trying to use it. Workaround: Disable the passThruPrivacyInfo controls. |
13 | SBX-101934 | 1 | The call is failing intermediately due to the Unsolicited Call Cleanup. Impact: The call is failing intermediately due to the Unsolicited Call Cleanup Root Cause: The affected call failed due to the XRM having received an error response from the NP for modify RID command, which was most likely the race condition in the NP. This issue occurred because the RID enable and modify commands were issued within the same seconds but from two different NP users. Steps to Replicate: Due to the nature of race condition, it is not guaranteed to reproduce the problem. The code is fixed based on a code review. | The code is modified to use the same NP interface user handle when sending the RID enable and modify commands to the NP for that special case. Workaround: N/A |
14 | SBX-100021 / SBX-99579 | 1 | Portfix SBX-99579 (Originated in Release 9.0.0): Observed the Ema process core dump on the S-SBC during a sbxrestart. Impact: The EMA process may coredump and the application may not come up after an upgrade if the SWE/Cloud has a cinder volume attached for log storage. Root Cause: While upgrading the SWE/Cloud platform attached with cinder volume, file ownership and permissions in the cinder volume are untouched causing wrong set of ownership on the EMA log file resulting in the EMA failing to start. Steps to Replicate: Perform an upgrade from 7.x to 8.2.3R0 in cloud with cinder volume and check the sbxstatus and check for coredumps. With the problematic build, the EMA coredumps can be observed. | The code is modified so during an upgrade, the EMA log dir ownership is set to the sonusadmin:sonus to ensure the EMA process can access the log file and can start without issues. Workaround: Manually change the ownership of the EMA log dir after an upgrade with below command: |
15 | SBX-102263 / SBX-102006 | 1 | Portfix SBX-102006 (Originated in Release 7.2.5): The SBC failed to send ACK to the right IP. Impact: After a call was connected with egress received RR in 2xx, the SBC sends a reInvite, and received the rexmit of 2xx. Later on, the SBC sends ACK to the wrong destination. Root Cause: A rexmit of 200OK, accidentally deletes the previous RR. Steps to Replicate:
| The code is modified so the SBC ignores updating the data of the dialog. Workaround: N/A |
16 | SBX-100023 / SBX-99020 | 1 | Portfix SBX-99020 (Originated in Release 9.0.0): Observed Major logs with the error prints of 488 on the SBC 5210 platform while running direct media. Impact: The calls stop working as LIF bandwidth is not freed. Root Cause: In the case of a multi stream direct media call with the last media stream as non-RTP stream, the SBC does not release the session bandwidth even when the call is released. This leads to a leakage in interface bandwidth resulting in call failures after some time. Steps to Replicate: Run direct media calls with multiple streams with the last media stream as a non-RTP stream (BFCP, MSRP). | The code is modified to release the session bandwidth even when the last media stream is non RTP stream in a direct media call. Workaround: N/A |
17 | SBX-101978 | 1 | The call forking with the MS Teams and GW-GW fails. Impact: The call forking with a GW-GW to might not work correctly. Root Cause: The call forking logic was not copying all of the internal parameter information when grouping the routes based on each AoR tag. This meant the SRTP enabled information was lost and the call was initiated using plain RTP instead of the SRTP. Steps to Replicate: Make a call forking call over GW-GW where one egress end point requires SRTP and the other does not. Check that the SRTP call is correctly set up. | The code is modified to correctly copy all of the route parameters between the PSX response and the forking queues. Workaround: N/A |
18 | SBX-102450 / SBX-95873 | 1 | Portfix SBX-95873 (Originated in Release 7.2.2): The E-SBC JIAD622 crashed. Impact: The problem occurred when the Version 3 T.38 fax is enabled. In this case, a CED 2100 Hz is sent to the SBC to G711 leg while it receives the T.38 ANSAM packets from T.38 side, the DSP hardware stack can crash. Root Cause: The root cause has the incorrect initialization in 3rd party T.38 stack. Steps to Replicate:
| The code is modified to avoid crash. Workaround: N/A |
19 | SBX-101284 | 1 | The SBC Software Edition SWe was not sending media to the MS Teams client. Impact: When there are more than 10 MS Teams endpoints that are potential media candidates for an outgoing ICE call to MS Teams, in some cases ice learning may not complete resulting in media path not being enabled when the call is answered. Root Cause: For each outgoing call, the SBC has an internal nominated candidates list of up to 10 entries for storing ICE information received in stun requests from potential media candidates (which can be received before response with SDP) . On receiving SDP, stored entries are checked to see if ICE is learned for the media stream in the SDP. However, if the SDP media is from the 11th or higher endpoint to have sent a stun (which would not have been stored) that can result in ICE learning not completing. Steps to Replicate:
| The code is modified to allow for up to 80 endpoints as potential media candidates. Workaround: None if more than 10 teams potential endpoints are necessary for a call, but works fine for up to 10. |
20 | SBX-101455 | SBX-96001 | 1 | The SBC 7000 has wrong value for call duration Impact: The call service duration (CDR field numbers 10 and 14) has the wrong values causing billing issue. Root Cause: This issue is seen when there is mid call message in this case session refresh. Due to this session refresh, there are mid call messages(INV/200OK/ACK) happens end to end. This makes the "callServiceEstTime" in the function CcRelayInfoMsg() overwritten every time causing the CDR fields 10 and 14 to have wrong values. Steps to Replicate: 1. Enable IPSP flag "End to End ACK" on both TGs. | The code is modified in the function CcRelayInfoMsg() so that the "callServiceEstTime" does not get overwritten once it is recorded initially during the initial offer-answer. Workaround: 1. Enable the flag "No CDR Change in End to End Ack". |
21 | SBX-102290 | 1 | The DBG file was filling up with messages "SIPCM: *ThreadPool: messageSequence". Impact: The DBG logs can be overrun with "SIPCM: *ThreadPool: messageSequence" messages. Root Cause: The DBG logs can be overrun with "SIPCM: *ThreadPool: messageSequence" messages, when there is a double CRLF "pings" received by the SBC over UDP transport. Steps to Replicate: Send Double CRLF "pings" over UDP to the SBC. | The code is modified to properly dispose of Double CRLF "pings" received by the SBC over UDP. Workaround: Inhibit the transmission (or reception) for Double CRLF "pings" over UDP. |
22 | SBX-102072 | 1 | There was a malformed OTG after an upgrade to 7.2.4R2 on GW-GW calls. Impact: In a SIP-GW-GW-SIP call, if the ingress SIP INVITE contains "tgrp" in the Contact header, the contents of the "otg" parameter in the egress SIP INVITE will be incorrect. Root Cause: Design was using an incorrect pointer value when creating the OTG parameter. Steps to Replicate: In the "Egress IP Signaling Profile", set the "Include OTG" in Originating TrunkGroup Options field.
The "otg" in egress INVITE should be the originating TG on the originating GW. | The code is modified to use the correct pointer when creating the OTG parameter. Workaround: Do not send the "tgrp" parameter in the ingress INVITE. |
23 | SBX-102029 | SBX-102835 | 1 | Portfix SBX-102029 (Originated in Release 8.1.0) There was an issue with Packet loss calculation on the NP. Impact: The packet loss count for for a call is incorrect when packets are lost at the end (last 32 packets) of the call. Root Cause: The packet loss algorithm did not include checking the last 32 packets of a call. Steps to Replicate: Send an RTP stream that includes skips in the sequence number during the last 32 packets. | The code is modified to check if packets are lost in the last 32 packets. Workaround: N/A |
24 | SBX-101949 | 1 | The P-Early-Media header with sendrecv sent back to the ingress before the SDP established. Impact: When the makeInBandToneAvailable is disabled, on a Tone And Announcement profile, the SBC sends 180 Ringing with PEM header as sendRecv even when egress 180 has no SDP. This causes ring back issues on ingress endpoints. Root Cause: When the makeInBandToneAvailable is disabled, the SBC does not include SDP in 180 message sent to ingress but still sends PEM header as sendRecv. Steps to Replicate: With a fix, the SBC is sending PEM header as inactive when makeInBandToneAvailable is disabled and egress 180 Ringing has no SDP. | The code is modified to ensure the SBC sends a PEM header as inactive when the makeInBandToneAvailable is disabled and egress 180 Ringing has no SDP. Workaround: Enable makeInBandToneAvailable on Tone And Announcement Profile. |
25 | SBX-102236 | 1 | The SBC CLI responds significantly slower while entering the ping command when one or more options are specified. Impact: Attempting to run the SBC CLI commands ping, ping6, traceroute, traceroute6 or aaarule-display-generatecli with multiple parameters causes the CLI session to freeze. Root Cause: Parsing of parameters on these CLI commands not correct. Steps to Replicate: Try to run the following command from CLI: | The code is modified to address the issue. Workaround: Use Linux equivalents to the commands, rather than using the SBC CLI or, if using the SBC CLI, limit the number of parameters. |
26 | SBX-102803 | 1 | The SIP-I calls cause a platform switchover when the Map Calling party to the PAI is set. Impact: The SBC may core when the configuration sipSigSrvcGrpURIPreference SIP on the egress but the incoming has tel and has pai (tel). Root Cause: The SBC accesses the invalid diversion address. Steps to Replicate: This is specific test case from customer, and cannot be reproduced. | The code is modified to validate the diversion address before access to it. Workaround: Disable the feature sipSigSrvcGrpURIPreference. |
27 | SBX-102122 | 1 | There was an SAM process core dump with v06.02.01 F012. Impact: The SAM and PRS process cored in the Standby node. Root Cause: The DRBD split brain lead to DRBD GI reset. This leads to the DRBD full sync, increasing the i/o congestion and ultimately causing a healthcheck timeout. Steps to Replicate: To test, run "drbdadm disconnect mirror". Once getting a "standby split-brain" log in DBG logs, run "drbdadm disconnect mirror" again so that DRBD does not connect automatically and getting into the block that needs to tested. Run "drbd-overview" and check if drbd does not went for full sync. | The code is modified to perform DRBD checks after a DRBD split-brain recovery. Workaround: N/A |
28 | SBX-103278 | 1 | There was a double SBC SCM process coredump. Impact: The SBC may core for an antiTromboneData feature. Root Cause: The SBC may access null pointer in antiTromboneData feature. Steps to Replicate: A call B, B(sdp) loop back to the SBC (Bprime). antiTromboneData is enable for B and Bprime. NOTE The Bprime also has a replaces header to replace a call which does not exist in the SBC, causing SBC reply 481. | The code is modified to validate pointer before access and address the issue. Workaround: N/A |
29 | SBX-103207 | 1 | The SBC SWe 8.2.0F1 duplicates audio from call B to call A. Impact: If CN is not negotiated for G711 codec and remote peer still sends CN packets that match default CN payload type (13), then user on other end may hear cross talk audio of completely unrelated channel or hear own reflect audio. Root Cause: When a g711 side does not negotiate CN in signaling, DSP does not initialize Comfort Noise Generation object. However, if remote peer still sends CN packet that matches the g711 SID payload type configured in PSP (default 13), DSP accepts the packet. It processes that CN packet incorrectly and as a result uses stale voice buffer which happens to be of another channel. This continues until next voice packet for that channel arrives. Hence, we happen to see cross talk audio from other call during silence period. In some cases, the user may hear own audio also and that is different manifestation of the same problem. This issue is specific to SWe. Steps to Replicate:
| The code is modified to initialize the comfort noise object even though CN is not negotiated and process the CN packets correctly. Workaround: There are multiple workarounds for this issue: 1. Change the default payload type of comfort noise from 13 to something else (say 15) in PSP of peer that is sending CN packets. This will make DSP drop CN packets because payload type will not match. Run the PSP configurationshow configuration profiles media packetServiceProfile G711_NONE_NONE_NONE..silenceInsertionDescriptor {g711SidRtpPayloadType 13;heartbeat enable;} 2. Enable the silence suppression on PSP of peer that is sending CN packets and keep CN payload type that matches with CN payload type. |
30 | SBX-103629 | 1 | The SBC was reporting REGISTER_PARSE_ERROR and replies with SIP 500 when it receives retransmitted initial REGISTER (CSEQ 1) followed by a REGISTER with Authorization header (CSEQ 1). Impact: When the SBC recv rexmit of registration (cseq=1) after sending 401/407, the SBC relays to the AS. At the same time, the IAD sends new registration(cseq=2) for authentication. It triggers race condition to the SBC and responds with 500. Root Cause: The SBC should relay the rexmit (cseq=1) registration to the application server. Steps to Replicate: IAD send registration(cseq1) to AS, AS response 401 to IAD, IAD rexmit the same cseq1, and send a new cseq2 with auth header. | The code is modified to respond to the rexmit request (cseq=1) so that a subsequent one cseq=2 can handle properly relay to the AS. Workaround: N/A |
31 | SBX-101652 | 1 | The SIPFE lookup returned the rcb pointing to wrong SCM post-upgrade. Impact: After an upgrade, registrations mirroring on SIPFE is corrupted. As a result, incoming traffic for the AOR may route to the wrong SCM and get rejected by the SBC. Root Cause: The packing redundancy data structure that was sent to the standby were incorrect due to word alignment issue (using sizeof() to pack the data). Steps to Replicate: Multiple of the same AOR registers from a different source. After an upgrade, call for register end point may route to the wrong SCM. | The code is modified to re-implement the packing logic and avoid using sizeof() to calculate the size of data structure. Workaround: N/A |
32 | SBX-96001 | SBX-101459 | 1 | Portfix SBX-96001 (Originated in Release 9.1.0) The SBC 7000 has the wrong value for call duration. Impact: The call service duration (CDR field numbers 10 and 14) has the wrong values, causing a billing issue. Root Cause: This issue is seen when there is a mid call message in this case session refresh. Due to this session refresh, there are mid call messages(INV/200OK/ACK) that happen end to end. This makes the "callServiceEstTime" in the function CcRelayInfoMsg() overwritten every time, causing the CDR fields 10 and 14 wrong values. Steps to Replicate:
| The code is modified so that the "callServiceEstTime" does not get overwritten once it is recorded initially during initial offer-answer. Workaround: Enable the flag "No CDR Change in End to End Ack". |
33 | SBX-103948 | SBX-103975 | 1 | Portfix SBX-103948 (Originated in Release 8.2.1) The SBC Application is crashing when the CPaaS to PSTN call is made. Impact: The SBC cores after a reboot/upgrade. Root Cause: The issue was introduced when the SBC tries to support the 10000 SMM rules in 8.2.0. Steps to Replicate: Configure the customer rules (delete sdp line). Major logs trigger but the rule still runs successfully. After a reboot/upgrade, the SBC cores. | The code is modified to fix the issue. Workaround: Disable the delete sdp rule. |
The following 08.02.03R000 Severity 2-4 issues were resolved in this release:
Resolved Issues
Issue ID | Sev | Problem Description | Resolution | |
---|---|---|---|---|
1 | SBX-100495 | 3 | The EMA GUI is not showing the username of configured AD Domain Controller correctly. Impact: Getting a Defined type NULL if it is "Direct type". Root Cause: The EMA GUI is not showing the username of configured AD Domain Controller correctly. Steps to Replicate:
Platform/Feature: SBC | The code is modified to get the correct Defined Type. Workaround: N/A |
2 | SBX-98844 | 2 | SDP attribute a=X-nat - duplicated (selective sdp relay). Impact: Due to a new change in 8.2 we did not consider the b line length properly, so "a=X-nat" was added twice Root Cause: Due to a new change in 8.2, we did not took the b line length into account while adding b line on egress. So we ended up adding "a=X-nat" line twice, once as part of b line and once as a line Steps to Replicate: Send INVITE with b line and a line in SDP as below v=0 "a=X-nat " line should not be added twice on egress side. | The code is modified to copy exactly b line bytes as part of adding b line on egress. So "a=X-nat" line is added only once as expected Workaround: N/A |
3 | SBX-100843 / SBX-100839 | 3 | Portfix SBX-100839: The GR-HA leader election could choose the starting node that is not in sync. Impact: A race condition exists with the G-HA leader election algorithm whereby when coming out of split-brain so you could choose the node that is starting and not sync'd to be the leader. This causes a full outage. Root Cause: The potential existed to check the wrong node's sync state when verifying the potential leader was in sync. Steps to Replicate: Cluster is configured for enhanced leader election. | The code is modified so that the proper nodes sync state is checked. Workaround: N/A |
4 | SBX-100512 / SBX-100481 | 2 | Portfix SBX-100481: Observed a jitter for more than 5ms in the passthrough call load. Impact: More than a 5ms jitter and relatively high packet loss was observed in passthrough calls. Root Cause: There was a segregation of media and non-media processes at initialization time that may fail occasionally, leading to non-media processes landing on vcpus meant for media processing. This leads to a higher jitter and possibly higher packet loss. Steps to Replicate: Issuing the following command show only yield kernel threads and SWe_NP processes: | The code is modified to function reliably. Workaround: Reboot the instance. |
5 | SBX-100667 / SBX-99414 | 2 | Portfix SBX-99414: The 6ms of jitter is observed on the pktart side from the SBC while the accepted value of the jitter is 3ms for a transcoded call in a call mix load of direct media and a transcoding scenario. Impact: More than 6ms of jitter was introduced in transcoded calls in call mix scenarios. Root Cause: The primary and Secondary ATA Interrupts landing on media processing cores were causing processing jitter due to high volume |