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).
Ribbon Release Notes are protected under the copyright laws of the United States of America. This work contains proprietary information of Ribbon Communications, Plano, TX 75023, 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 ID | Description | Fixed In Release |
---|---|---|
Warning-14-00020748 | Verify system and databases are fully in sync prior to Live Software Upgrade (LSWU). Applies to all SBC platforms (HW, SWe, Cloud) except the SBCs deployed in a Distributed SBC (D-SBC) architecture. | N/A |
Warning-21-00029972 | The SBC upgrade may truncate the SQL configuration database due to too many historical alarms. | N/A |
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 the SBC Core Portfolio Interoperability Matrix for the latest and minimum compatible product versions supporting this release.
There are no new features in this release.
To view features in previous releases, refer to the following release notes:
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 .sha256 files separate from the SBC Core application installation and upgrade files:
The system hosting the SBC SWe Cloud must meet the following requirements.
The following tarball file is required to use the Infrastucture as Code 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 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.23.00-R000 |
Kernel: 3.10.108 Busybox: v1.27.2 Openssh: 7.9p1 Openssl: 1.0.2n Lighttpd: 1.4.48-r0 Qualys security issues Password encryption method is SHA512 Lighttpd is secured and supports only TLS1.2 cipher. | ||
SBC 51x0/52x0 BIOS | V2.7.0 | |
SBC 5400 Firmware | BMC: V03.23.00-R000 BIOS: V1.18.0 | |
SBC 7000 Firmware | BMC: V03.23.00-R000 BIOS: V2.14.0 | |
SBC Application | Operating System (OS) Version | V08.02.04-R003 |
SonusDB | V09.02.05-R006 | |
SBC Application | V09.02.05-R006 |
The firmware package of SBC 5400 and 7000 includes BMC, BIOS, and other binaries. The firmware is upgraded from the BMC.
Use the EMA to verify the currently installed software and firmware versions.
Log on to the EMA, and from the main screen navigate to Monitoring > Dashboard > System and Software Info.
The following software release bundles are available for download from the Customer Portal:
Download the appropriate software packages for your desired configuration from the Customer Portal (https://ribboncommunications.com/services/ribbon-support-portal-login) to your PC.
Beginning with version 9.0, the pre-install script now uses the .sha256 checksum files when validating file integrity. Previous versions (7.x and 8.x) use the .md5 checksums.
firmware-5XX0-V03.23.00-R000.img
firmware-5XX0-V03.23.00-R000.img.md5
bmc5X00_v3.23.0-R0.rom.md5sum
bmc5X00_v3.23.0-R0.rom
Perform 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.
Release 9.2 includes a new set of OS security patches, and also a new version of confD. Release 9.2.1 includes a new set of OS security patches including the fix for CVE-2021-3156: Heap-Based Buffer Overflow in Sudo (Baron Samedit).
The SBC Core application installation and upgrade package includes the files:
sbc-V09.02.05R006-connexip-os_08.02.04-R003_982_amd64.qcow2.sha256
sbc-V09.02.05-R006.x86_64.tar.gz
sbc-V09.02.05-R006.x86_64.md5
For detailed information on installation and upgrade procedures, refer to SBC Core Software Installation and Upgrade Guide.
Snapshot name: /subscriptions/ce8b3f68-2147-49db-acef-8da635e6960a/resourceGroups/SBC-Core-Images-RG/providers/Microsoft.Compute/snapshots/release-sbc-v09-02-05r006-04-12-23-20-24.snap
ROHOS is the hardened and tested Host OS that Ribbon provides for qualified servers. ROHOS is the operating system component of Ribbon "whole-box" offerings containing the server hardware, solution software, and operating system.
The latest version of ROHOS is Version 02.04.01
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.
Using older versions of ESXi can trigger a VM instance shutdown. To prevent this from occurring, you must upgrade the VMware ESXi -- refer to the End of General Support column on https://lifecycle.vmware.com/#/ for supported versions.
A LSWU on an SBC 7000 should only be performed when the total number of active calls on the system is below 18,000. If the criteria is not met, a double failure during the upgrade may occur, thereby losing all active calls. If such a failure occurs, both active and standby SBC services will go down. Contact Ribbon Support immediately.
Customers upgrading from 9.2.2R1 using VMware or KVM need to run the following command as root user on both the active and standby instances:
touch /opt/sonus/conf/swe/capacityEstimates/.indexMarker
This is not required for upgrades from earlier releases.
Once the installation or upgrade completes on the SBC SWe platform, the copy of the installation package (SBC Core Installation and Upgrade Package) is automatically removed from the system.
Release 9.2 and later requires additional user account security practices for SBC SWe deployments in Openstack cloud environments. During upgrade of SBC SWe cloud instances deployed using Heat templates, you must use a template that includes SSH keys or passwords for the admin and linuxadmin accounts. The example Heat templates have been updated to include information on how to specify this type of data in the userdata section of a template.
In order to take advantage of performance improvements due to hyper-threading refer to the following MOP to increase the number of vCPUs prior to SBC SWe (KVM Hypervisor or VMware) upgrades from pre-07.01.00R000 release to 07.01.00R000 or higher.
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 LSWU.
In NFV environments, the method used for upgrades involves rebuilding the instance, which requires additional disk space on the host. The minimum disk space needed for this operation is listed in the table below.
Disk Space Requirements
Flavor | Extra Space Required (GB) |
---|---|
S-SBC | 80 |
M-SBC | 80 |
PSX-M | 360 |
PSX-S | 360 |
PSX-Test | 360 |
EMS_SA | 150 |
SWe SBC software enforces I-SBC instances to run only with a single vNUMA node in order to achieve deterministic performance. SWe SBC VM having >8 vCPUs hosted on dual-socket physical server with VMware ESXi software needs to follow the steps below to correct vNUMA topology before upgrading to latest SWe SBC software:
vsish -e get /net/pNics/<PKT port name - vmnicX>/properties | grep "NUMA"
If any of the above settings requires modification, follow the steps below on SWe SBC HA system:
numa.autosize.once = FALSE
numa.nodeAffinity’ = 0 or 1 (based on PKT port NIC affinity)
On ESXi 6.5 and above releases, vSphere web client can be used to add above rows under Edit settings > VM options > configuration parameters > add parameters;
On ESXi 6.0 and below releases, it can be added under Edit > Advanced > general > configuration parameters > add rows using vSphere client.
For more information, refer to:
Before beginning the upgrade on a SBC running code prior to 8.2R0, the following commands on all the DNS Groups needs to be issued if “ednsSupport” is enabled.
Failure statistics are not being mirrored correctly, and the LSWU state may stay in “syncing” if the “ednsFailures “ count is non-zero.
admin@PLUM> request addressContext default dnsGroup DnsGrp dnsServerReset
reason DNS Server statistics are Reset
[ok][2020-11-06 04:08:13]
admin@PLUM> show status addressContext default dnsGroup DnsGrp
dnsServerStatistics 2
{ ipAddress 10.xx.xx.xx; queries 0; timeouts 0; errors 0; referrals 0; totalTcpConnection 0; tcpConnectionFailed 0; tcpConnectionSuccess 0; tcpConnectiontorndown 0; tcpFallback 0; ednsStatus supported; ednsFailures 0; }
[ok][2020-11-06 04:08:22]
admin@PLUM>
2. Disable the ednsSupport to stop mirroring of the statistics if the error count is constantly incrementing or likely to increase during the upgrade.
set addressContext default dnsGroup DnsGrp ednsSupport disabled
Note: The ednsServer stats will be lost/reset during the upgrade.
If the TRF/MRB Features are configured and enabled – some calls are unable to be cleared post upgrade if using the TRF/MRB attributes.
The upgrade is successful and calls continue but some calls may fail to clean up release post upgrade. Session KeepAlive and RTP Inactivity functions will clean any stale calls.
Enable the sessionKeepalive or rtpInactivity monitoring to ensure that mirrored calls are cleaned up post upgrade.
set addressContext default zone ZONE_AS sipTrunkGroup TG_AS_SIPP signaling timers sessionKeepalive <value>
OR
set system media mediaPeerInactivity <value>
set profiles media packetServiceProfile DEFAULT peerAbsenceAction peerAbsenceTrapAndDisconnect
Upgrade from a pre 8.2 release with globalization support for registration enabled will see a registration drop during an upgrade.
If the following localNumberSupport is enabled, those registrations will be dropped after first switchover during LSWU.
% set addressContext <name> zone <name> sipTrunkGroup <name> signaling localNumberSupport <disabled | enabled>
Prior to performing an upgrade to this release, you must remove usernames that do not conform to the SBC user-naming rules 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.
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.As of release 9.2.0R1, the Platform Manager (PM) runs an LSWU infrastructure, 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.
Operators who are using the SBC to interoperate 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 9.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 7.x and 8.x software is EOSL as of Q3 2022.
The SBC Core supports Live Software Upgrade from releases listed in the table below:
Supported Upgrade Paths
V07.00.00Rx - V07.01.00Rx | V07.02.00Rx - V07.02.01Rx | V07.02.02Rx - V07.02.05Rx | V08.00.x - V08.01.x | V08.02.x | V09.00.x - V09.02.01x | V09.02.02x - V09.02.05x |
---|---|---|---|---|---|---|
V07.00.00R000 | V07.02.00R000 | V07.02.02R000 | V08.00.00R000 | V08.02.00R000 | V09.00.00R000 | V09.02.02R001 |
V07.00.00F001 | V07.02.00R001 | V07.02.02R001 | V08.01.00R000 | V08.02.00F001 | V09.01.00R000 | V09.02.02R002 |
V07.00.00F002 | V07.02.00R002 | V07.02.02R002 | V08.01.00F001 | V08.02.00F002 | V09.01.00R001 | V09.02.02R003 |
V07.00.00F003 | V07.02.00S400 | V07.02.02R003 | V08.01.00R001 | V08.02.00R001 | V09.01.00R002 | V09.02.02R004 |
V07.00.00F004 | V07.02.00S401 | V07.02.02R004 | V08.01.00R002 | V08.02.00R002 | V09.01.00R003 | V09.02.02R005 |
V07.00.00F005 | V07.02.00S809 | V07.02.02R005 | V08.01.00R003 | V08.02.01R000 | V09.02.00R000 | V09.02.02R006 |
V07.00.00F006 | V07.02.00S810 | V07.02.02F001 | V08.01.00R004 | V08.02.01F001 | V09.02.00R001 | V09.02.02R007 |
V07.00.00S400 | V07.02.01R000 | V07.02.03R000 | V08.01.00R005 | V08.02.01F002 | V09.02.00R002 | V09.02.02R008 |
V07.00.00S401 | V07.02.01R001 | V07.02.03R001 | V08.01.00R006 | V08.02.01F003 | V09.02.01R000 | V09.02.02R009 |
V07.00.00S402 | V07.02.01R002 | V07.02.03R002 | V08.01.00R007 | V08.02.02R000 | V09.02.01R001 | V09.02.03R000 |
V07.00.00S404 | V07.02.01R003 | V07.02.03R003 | V08.01.00R008 | V08.02.02R001 | V09.02.01R002 | V09.02.03R001 |
V07.00.00S405 | V07.02.01R004 | V07.02.03R004 | V08.02.02R002 | V09.02.01R003 | V09.02.03R002 | |
V07.00.00S406 | V07.02.01F001 | V07.02.03S400 | V08.02.02R003 | V09.02.01R004 | V09.02.03R003 | |
V07.00.00S407 | V07.02.01F002 | V07.02.03S401 | V08.02.02R004 | V09.02.01R005 | V09.02.03R004 | |
V07.01.00R000 | V07.02.01F004 | V07.02.04R000 | V08.02.02R005 | V09.02.01R006 | V09.02.03R005 | |
V07.01.00R001 | V07.02.01F005 | V07.02.04R001 | V08.02.03R000 | V09.02.01R007 | V09.02.03R006 | |
V07.01.00R002 | V07.02.01S400 | V07.02.04R002 | V08.02.03R001 | V09.02.01R008 | V09.02.03R007 | |
V07.01.00R003 | V07.02.01R005 | V07.02.04R003 | V08.02.03F001 | V09.02.01R009 | V09.02.03R008 | |
V07.01.00R004 | V07.02.01R006 | V07.02.04R004 | V08.02.04R000 | V09.02.01R010 | V09.02.03R009 | |
V07.01.00F001 | V07.02.01R007 | V07.02.05R000 | V08.02.04F001 | V09.02.04R000 | ||
V07.01.00F002 | V07.02.01R008 | V07.02.05R001 | V08.02.04R001 | V09.02.04R001 | ||
V07.01.00F003 | V07.02.01R009 | V07.02.05R002 | V08.02.04R002 | V09.02.04R002 | ||
V07.02.01R010 | V07.02.05R003 | V08.02.04R003 | V09.02.04R003 | |||
V07.02.05R004 | V08.02.04R004 | V09.02.04R004 | ||||
V07.02.05R005 | V08.02.05R000 | V09.02.04R005 | ||||
V07.02.05R006 | V08.02.05R001 | V09.02.04R006 | ||||
V07.02.05R007 | V08.02.05R002 | V09.02.05R000 | ||||
V07.02.05R008 | V08.02.05R003 | V09.02.05R001 | ||||
V07.02.05R009 | V08.02.05R004 | V09.02.05R002 | ||||
V07.02.05R010 | V08.02.05R005 | V09.02.05R003 | ||||
V07.02.05R011 | V08.02.05R006 | V09.02.05R004 | ||||
V07.02.05R012 | V09.02.05R005 |
The following security vulnerabilities were resolved in V09.02.05R000 with an OS patch update as of 8/12/2022:
CVE ID | Severity | Description |
---|---|---|
CVE-2017-12562 | Critical | Heap-based Buffer Overflow in the psf_binheader_writef function in common.c in libsndfile through 1.0.28 allows remote attackers to cause a denial of service (application crash) or possibly have unspecified other impact. |
CVE-2021-39713 | Critical | Product: AndroidVersions: Android kernelAndroid ID: A-173788806References: Upstream kernel |
CVE-2022-29155 | Critical | In OpenLDAP 2.x before 2.5.12 and 2.6.x before 2.6.2, a SQL injection vulnerability exists in the experimental back-sql backend to slapd, via a SQL statement within an LDAP query. This can occur during an LDAP search operation when the search filter is processed, due to a lack of proper escaping. |
CVE-2022-1292 | Critical | The c_rehash script does not properly sanitise shell metacharacters to prevent command injection. This script is distributed by some operating systems in a manner where it is automatically executed. On such operating systems, an attacker could execute arbitrary commands with the privileges of the script. Use of the c_rehash script is considered obsolete and should be replaced by the OpenSSL rehash command line tool. Fixed in OpenSSL 3.0.3 (Affected 3.0.0,3.0.1,3.0.2). Fixed in OpenSSL 1.1.1o (Affected 1.1.1-1.1.1n). Fixed in OpenSSL 1.0.2ze (Affected 1.0.2-1.0.2zd). |
CVE-2022-1664 | Critical | Dpkg::Source::Archive in dpkg, the Debian package management system, before version 1.21.8, 1.20.10, 1.19.8, 1.18.26 is prone to a directory traversal vulnerability. When extracting untrusted source packages in v2 and v3 source package formats that include a debian.tar, the in-place extraction can lead to directory traversal situations on specially crafted orig.tar and debian.tar tarballs. |
CVE-2022-1968 | High | Use After Free in GitHub repository vim/vim prior to 8.2. |
CVE-2022-23038 | High | Linux PV device frontends vulnerable to attacks by backends This CNA information record relates to multiple CVEs; the text explains wh ich aspects/vulnerabilities correspond to which CVE. Several Linux PV device frontends are using the grant table interfaces for removi ng access rights of the backends in ways being subject to race conditions, resulting in potential data leaks, data corruption by malici ous backends, and denial of service triggered by malicious backends: blkfront, netfront, scsifront and the gntalloc driver are testing whether a grant reference is still in use. If this is not the case, they assume that a following removal of the granted access will alw ays succeed, which is not true in case the backend has mapped the granted page between those two operations. As a result the backend ca n keep access to the memory page of the guest no matter how the page will be used after the frontend I/O has finished. The xenbus drive r has a similar problem, as it doesn't check the success of removing the granted access of a shared ring buffer. blkfront: CVE-2022-230 36 netfront: CVE-2022-23037 scsifront: CVE-2022-23038 gntalloc: CVE-2022-23039 xenbus: CVE-2022-23040 blkfront, netfront, scsifront, us bfront, dmabuf, xenbus, 9p, kbdfront, and pvcalls are using a functionality to delay freeing a grant reference until it is no longer in use, but the freeing of the related data page is not synchronized with dropping the granted access. As a result the backend can keep a ccess to the memory page even after it has been freed and then re-used for a different purpose. CVE-2022-23041 netfront will fail a BUG _ON() assertion if it fails to revoke access in the rx path. This will result in a Denial of Service (DoS) situation of the guest which can be triggered by the backend. CVE-2022-23042 |
CVE-2022-0413 | High | Use After Free in GitHub repository vim/vim prior to 8.2. |
CVE-2019-2201 | High | In generate_jsimd_ycc_rgb_convert_neon of jsimd_arm64_neon.S, there is a possible out of bounds write due to a missing bounds check. Th is could lead to remote code execution in an unprivileged process with no additional execution privileges needed. User interaction is n eeded for exploitation.Product: AndroidVersions: Android-8.0 Android-8.1 Android-9 Android-10Android ID: A-120551338 |
CVE-2022-0417 | High | Heap-based Buffer Overflow GitHub repository vim/vim prior to 8.2. |
CVE-2022-1621 | High | Heap buffer overflow in vim_strncpy find_word in GitHub repository vim/vim prior to 8.2.4919. This vulnerability is capable of crashing software, Bypass Protection Mechanism, Modify Memory, and possible remote execution |
CVE-2021-4156 | High | An out-of-bounds read flaw was found in libsndfile's FLAC codec functionality. An attacker who is able to submit a specially crafted fi le (via tricking a user to open or otherwise) to an application linked with libsndfile and using the FLAC codec, could trigger an out-o f-bounds read that would most likely cause a crash but could potentially leak memory information that could be used in further exploita tion of other flaws. |
CVE-2021-23177 | High | An improper link resolution flaw while extracting an archive can lead to changing the access control list (ACL) of the target of the li nk. An attacker may provide a malicious archive to a victim user, who would trigger this flaw when trying to extract the archive. A loc al attacker may use this flaw to change the ACL of a file on the system and gain more privileges. |
CVE-2022-1898 | High | Use After Free in GitHub repository vim/vim prior to 8.2. |
CVE-2022-23039 | High | Linux PV device frontends vulnerable to attacks by backends This CNA information record relates to multiple CVEs; the text explains wh ich aspects/vulnerabilities correspond to which CVE. Several Linux PV device frontends are using the grant table interfaces for removi ng access rights of the backends in ways being subject to race conditions, resulting in potential data leaks, data corruption by malici ous backends, and denial of service triggered by malicious backends: blkfront, netfront, scsifront and the gntalloc driver are testing whether a grant reference is still in use. If this is not the case, they assume that a following removal of the granted access will alw ays succeed, which is not true in case the backend has mapped the granted page between those two operations. As a result the backend ca n keep access to the memory page of the guest no matter how the page will be used after the frontend I/O has finished. The xenbus drive r has a similar problem, as it doesn't check the success of removing the granted access of a shared ring buffer. blkfront: CVE-2022-230 36 netfront: CVE-2022-23037 scsifront: CVE-2022-23038 gntalloc: CVE-2022-23039 xenbus: CVE-2022-23040 blkfront, netfront, scsifront, us bfront, dmabuf, xenbus, 9p, kbdfront, and pvcalls are using a functionality to delay freeing a grant reference until it is no longer in use, but the freeing of the related data page is not synchronized with dropping the granted access. As a result the backend can keep a ccess to the memory page even after it has been freed and then re-used for a different purpose. CVE-2022-23041 netfront will fail a BUG _ON() assertion if it fails to revoke access in the rx path. This will result in a Denial of Service (DoS) situation of the guest which can be triggered by the backend. CVE-2022-23042 |
CVE-2022-0443 | High | Use After Free in GitHub repository vim/vim prior to 8.2. |
CVE-2021-27219 | High | An issue was discovered in GNOME GLib before 2.66.6 and 2.67.x before 2.67.3. The function g_bytes_new has an integer overflow on 64-bi t platforms due to an implicit cast from 64 bits to 32 bits. The overflow could potentially lead to memory corruption. |
CVE-2022-0351 | High | Access of Memory Location Before Start of Buffer in GitHub repository vim/vim prior to 8.2. |
CVE-2020-1712 | High | A heap use-after-free vulnerability was found in systemd before version v245-rc1, where asynchronous Polkit queries are performed while handling dbus messages. A local unprivileged attacker can abuse this flaw to crash systemd services or potentially execute code and el evate their privileges, by sending specially crafted dbus messages. |
CVE-2021-26720 | High | avahi-daemon-check-dns.sh in the Debian avahi package through 0.8-4 is executed as root via /etc/network/if-up.d/avahi-daemon, and allo ws a local attacker to cause a denial of service or create arbitrary empty files via a symlink attack on files under /run/avahi-daemon. NOTE: this only affects the packaging for Debian GNU/Linux (used indirectly by SUSE), not the upstream Avahi product. |
CVE-2022-1720 | High | Buffer Over-read in function grab_file_name in GitHub repository vim/vim prior to 8.2.4956. This vulnerability is capable of crashing t he software, memory modification, and possible remote execution. |
CVE-2021-3903 | High | vim is vulnerable to Heap-based Buffer Overflow |
CVE-2017-16932 | High | parser.c in libxml2 before 2.9.5 does not prevent infinite recursion in parameter entities. |
CVE-2022-23040 | High | Linux PV device frontends vulnerable to attacks by backends This CNA information record relates to multiple CVEs; the text explains wh ich aspects/vulnerabilities correspond to which CVE. Several Linux PV device frontends are using the grant table interfaces for removi ng access rights of the backends in ways being subject to race conditions, resulting in potential data leaks, data corruption by malici ous backends, and denial of service triggered by malicious backends: blkfront, netfront, scsifront and the gntalloc driver are testing whether a grant reference is still in use. If this is not the case, they assume that a following removal of the granted access will alw ays succeed, which is not true in case the backend has mapped the granted page between those two operations. As a result the backend ca n keep access to the memory page of the guest no matter how the page will be used after the frontend I/O has finished. The xenbus drive r has a similar problem, as it doesn't check the success of removing the granted access of a shared ring buffer. blkfront: CVE-2022-230 36 netfront: CVE-2022-23037 scsifront: CVE-2022-23038 gntalloc: CVE-2022-23039 xenbus: CVE-2022-23040 blkfront, netfront, scsifront, us bfront, dmabuf, xenbus, 9p, kbdfront, and pvcalls are using a functionality to delay freeing a grant reference until it is no longer in use, but the freeing of the related data page is not synchronized with dropping the granted access. As a result the backend can keep a ccess to the memory page even after it has been freed and then re-used for a different purpose. CVE-2022-23041 netfront will fail a BUG _ON() assertion if it fails to revoke access in the rx path. This will result in a Denial of Service (DoS) situation of the guest which can be triggered by the backend. CVE-2022-23042 |
CVE-2022-23041 | High | Linux PV device frontends vulnerable to attacks by backends This CNA information record relates to multiple CVEs; the text explains wh ich aspects/vulnerabilities correspond to which CVE. Several Linux PV device frontends are using the grant table interfaces for removi ng access rights of the backends in ways being subject to race conditions, resulting in potential data leaks, data corruption by malici ous backends, and denial of service triggered by malicious backends: blkfront, netfront, scsifront and the gntalloc driver are testing whether a grant reference is still in use. If this is not the case, they assume that a following removal of the granted access will alw ays succeed, which is not true in case the backend has mapped the granted page between those two operations. As a result the backend ca n keep access to the memory page of the guest no matter how the page will be used after the frontend I/O has finished. The xenbus drive r has a similar problem, as it doesn't check the success of removing the granted access of a shared ring buffer. blkfront: CVE-2022-230 36 netfront: CVE-2022-23037 scsifront: CVE-2022-23038 gntalloc: CVE-2022-23039 xenbus: CVE-2022-23040 blkfront, netfront, scsifront, us bfront, dmabuf, xenbus, 9p, kbdfront, and pvcalls are using a functionality to delay freeing a grant reference until it is no longer in use, but the freeing of the related data page is not synchronized with dropping the granted access. As a result the backend can keep a ccess to the memory page even after it has been freed and then re-used for a different purpose. CVE-2022-23041 netfront will fail a BUG _ON() assertion if it fails to revoke access in the rx path. This will result in a Denial of Service (DoS) situation of the guest which can be triggered by the backend. CVE-2022-23042 |
CVE-2022-23042 | High | Linux PV device frontends vulnerable to attacks by backends This CNA information record relates to multiple CVEs; the text explains wh ich aspects/vulnerabilities correspond to which CVE. Several Linux PV device frontends are using the grant table interfaces for removi ng access rights of the backends in ways being subject to race conditions, resulting in potential data leaks, data corruption by malici ous backends, and denial of service triggered by malicious backends: blkfront, netfront, scsifront and the gntalloc driver are testing whether a grant reference is still in use. If this is not the case, they assume that a following removal of the granted access will alw ays succeed, which is not true in case the backend has mapped the granted page between those two operations. As a result the backend ca n keep access to the memory page of the guest no matter how the page will be used after the frontend I/O has finished. The xenbus drive r has a similar problem, as it doesn't check the success of removing the granted access of a shared ring buffer. blkfront: CVE-2022-230 36 netfront: CVE-2022-23037 scsifront: CVE-2022-23038 gntalloc: CVE-2022-23039 xenbus: CVE-2022-23040 blkfront, netfront, scsifront, us bfront, dmabuf, xenbus, 9p, kbdfront, and pvcalls are using a functionality to delay freeing a grant reference until it is no longer in use, but the freeing of the related data page is not synchronized with dropping the granted access. As a result the backend can keep a ccess to the memory page even after it has been freed and then re-used for a different purpose. CVE-2022-23041 netfront will fail a BUG _ON() assertion if it fails to revoke access in the rx path. This will result in a Denial of Service (DoS) situation of the guest which can be triggered by the backend. CVE-2022-23042 |
CVE-2022-1851 | High | Out-of-bounds Read in GitHub repository vim/vim prior to 8.2. |
CVE-2022-0572 | High | Heap-based Buffer Overflow in GitHub repository vim/vim prior to 8.2. |
CVE-2022-23037 | High | Linux PV device frontends vulnerable to attacks by backends This CNA information record relates to multiple CVEs; the text explains wh ich aspects/vulnerabilities correspond to which CVE. Several Linux PV device frontends are using the grant table interfaces for removi ng access rights of the backends in ways being subject to race conditions, resulting in potential data leaks, data corruption by malici ous backends, and denial of service triggered by malicious backends: blkfront, netfront, scsifront and the gntalloc driver are testing whether a grant reference is still in use. If this is not the case, they assume that a following removal of the granted access will alw ays succeed, which is not true in case the backend has mapped the granted page between those two operations. As a result the backend ca n keep access to the memory page of the guest no matter how the page will be used after the frontend I/O has finished. The xenbus drive r has a similar problem, as it doesn't check the success of removing the granted access of a shared ring buffer. blkfront: CVE-2022-230 36 netfront: CVE-2022-23037 scsifront: CVE-2022-23038 gntalloc: CVE-2022-23039 xenbus: CVE-2022-23040 blkfront, netfront, scsifront, us bfront, dmabuf, xenbus, 9p, kbdfront, and pvcalls are using a functionality to delay freeing a grant reference until it is no longer in use, but the freeing of the related data page is not synchronized with dropping the granted access. As a result the backend can keep a ccess to the memory page even after it has been freed and then re-used for a different purpose. CVE-2022-23041 netfront will fail a BUG _ON() assertion if it fails to revoke access in the rx path. This will result in a Denial of Service (DoS) situation of the guest which can be triggered by the backend. CVE-2022-23042 |
CVE-2021-27218 | High | An issue was discovered in GNOME GLib before 2.66.7 and 2.67.x before 2.67.4. If g_byte_array_new_take() was called with a buffer of 4G B or more on a 64-bit platform, the length would be truncated modulo 2**32, causing unintended length truncation. |
CVE-2022-0943 | High | Heap-based Buffer Overflow occurs in vim in GitHub repository vim/vim prior to 8.2.4563. |
CVE-2022-2126 | High | Out-of-bounds Read in GitHub repository vim/vim prior to 8.2. |
CVE-2022-24958 | High | drivers/usb/gadget/legacy/inode.c in the Linux kernel through 5.16.8 mishandles dev->buf release. |
CVE-2022-23036 | High | Linux PV device frontends vulnerable to attacks by backends This CNA information record relates to multiple CVEs; the text explains wh ich aspects/vulnerabilities correspond to which CVE. Several Linux PV device frontends are using the grant table interfaces for removi ng access rights of the backends in ways being subject to race conditions, resulting in potential data leaks, data corruption by malici ous backends, and denial of service triggered by malicious backends: blkfront, netfront, scsifront and the gntalloc driver are testing whether a grant reference is still in use. If this is not the case, they assume that a following removal of the granted access will alw ays succeed, which is not true in case the backend has mapped the granted page between those two operations. As a result the backend ca n keep access to the memory page of the guest no matter how the page will be used after the frontend I/O has finished. The xenbus drive r has a similar problem, as it doesn't check the success of removing the granted access of a shared ring buffer. blkfront: CVE-2022-230 36 netfront: CVE-2022-23037 scsifront: CVE-2022-23038 gntalloc: CVE-2022-23039 xenbus: CVE-2022-23040 blkfront, netfront, scsifront, us bfront, dmabuf, xenbus, 9p, kbdfront, and pvcalls are using a functionality to delay freeing a grant reference until it is no longer in use, but the freeing of the related data page is not synchronized with dropping the granted access. As a result the backend can keep a ccess to the memory page even after it has been freed and then re-used for a different purpose. CVE-2022-23041 netfront will fail a BUG _ON() assertion if it fails to revoke access in the rx path. This will result in a Denial of Service (DoS) situation of the guest which can be triggered by the backend. CVE-2022-23042 |
CVE-2022-2124 | High | Buffer Over-read in GitHub repository vim/vim prior to 8.2. |
CVE-2022-21476 | High | Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Libraries). Supported vers ions that are affected are Oracle Java SE: 7u331, 8u321, 11.0.14, 17.0.2, 18; Oracle GraalVM Enterprise Edition: 20.3.5, 21.3.1 and 22. 0.0.2. Easily exploitable vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized access to critical dat a or complete access to all Oracle Java SE, Oracle GraalVM Enterprise Edition accessible data. 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 can also be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. CVSS 3.1 Base Score 7.5 (Confidenti ality impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N). |
CVE-2017-5130 | High | An integer overflow in xmlmemory.c in libxml2 before 2.9.5, as used in Google Chrome prior to 62.0.3202.62 and other products, allowed a remote attacker to potentially exploit heap corruption via a crafted XML file. |
CVE-2021-31566 | High | An improper link resolution flaw can occur while extracting an archive leading to changing modes, times, access control lists, and flag s of a file outside of the archive. An attacker may provide a malicious archive to a victim user, who would trigger this flaw when tryi ng to extract the archive. A local attacker may use this flaw to gain more privileges in a system. |
CVE-2022-1616 | High | Use after free in append_command in GitHub repository vim/vim prior to 8.2.4895. This vulnerability is capable of crashing software, By pass Protection Mechanism, Modify Memory, and possible remote execution |
CVE-2022-0261 | High | Heap-based Buffer Overflow in GitHub repository vim/vim prior to 8.2. |
CVE-2022-23308 | High | valid.c in libxml2 before 2.9.13 has a use-after-free of ID and IDREF attributes. |
CVE-2022-27223 | High | In drivers/usb/gadget/udc/udc-xilinx.c in the Linux kernel before 5.16.12, the endpoint index is not validated and might be manipulated by the host for out-of-array access. |
CVE-2022-1154 | High | Use after free in utf_ptr2char in GitHub repository vim/vim prior to 8.2.4646. |
CVE-2022-1619 | High | Heap-based Buffer Overflow in function cmdline_erase_chars in GitHub repository vim/vim prior to 8.2.4899. This vulnerabilities are cap able of crashing software, modify memory, and possible remote execution |
CVE-2022-21426 | Medium | Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: JAXP). Supported versions that are affected are Oracle Java SE: 7u331, 8u321, 11.0.14, 17.0.2, 18; Oracle GraalVM Enterprise Edition: 20.3.5, 21.3.1 and 22.0.0.2. Easily exploitable vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Oracle 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 can also be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. CVSS 3.1 Base Score 5.3 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L). |
CVE-2022-29824 | Medium | In libxml2 before 2.9.14, several buffer handling functions in buf.c (xmlBuf*) and tree.c (xmlBuffer*) don't check for integer overflows. This can result in out-of-bounds memory writes. Exploitation requires a victim to open a crafted, multi-gigabyte XML file. Other software using libxml2's buffer functions, for example libxslt through 1.1.35, is affected as well. |
CVE-2022-21496 | Medium | Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: JNDI). Supported versions that are affected are Oracle Java SE: 7u331, 8u321, 11.0.14, 17.0.2, 18; Oracle GraalVM Enterprise Edition: 20.3.5, 21.3.1 and 22.0.0.2. Easily exploitable vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM Enterprise Edition accessible data. 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 can also be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. CVSS 3.1 Base Score 5.3 (Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N). |
CVE-2018-1108 | Medium | kernel drivers before version 4.17-rc1 are vulnerable to a weakness in the Linux kernel's implementation of random seed data. Programs, early in the boot sequence, could use the data allocated for the seed before it was sufficiently generated. |
CVE-2019-19221 | Medium | In Libarchive 3.4.0, archive_wstring_append_from_mbs in archive_string.c has an out-of-bounds read because of an incorrect mbrtowc or mbtowc call. For example, bsdtar crashes via a crafted archive. |
CVE-2021-4149 | Medium | A vulnerability was found in btrfs_alloc_tree_b in fs/btrfs/extent-tree.c in the Linux kernel due to an improper lock operation in btrfs. In this flaw, a user with a local privilege may cause a denial of service (DOS) due to a deadlock problem. |
CVE-2022-26691 | Medium | A logic issue was addressed with improved state management. This issue is fixed in Security Update 2022-003 Catalina, macOS Monterey 12.3, macOS Big Sur 11.6.5. An application may be able to gain elevated privileges. |
CVE-2017-5969 | Medium | ** DISPUTED ** libxml2 2.9.4, when used in recover mode, allows remote attackers to cause a denial of service (NULL pointer dereference) via a crafted XML document. NOTE: The maintainer states "I would disagree of a CVE with the Recover parsing option which should only be used for manual recovery at least for XML parser." |
CVE-2022-21434 | Medium | Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Libraries). Supported versions that are affected are Oracle Java SE: 7u331, 8u321, 11.0.14, 17.0.2, 18; Oracle GraalVM Enterprise Edition: 20.3.5, 21.3.1 and 22.0.0.2. Easily exploitable vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM Enterprise Edition accessible data. 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 can also be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. CVSS 3.1 Base Score 5.3 (Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N). |
CVE-2021-28153 | Medium | An issue was discovered in GNOME GLib before 2.66.8. When g_file_replace() is used with G_FILE_CREATE_REPLACE_DESTINATION to replace a path that is a dangling symlink, it incorrectly also creates the target of the symlink as an empty file, which could conceivably have security relevance if the symlink is attacker-controlled. (If the path is a symlink to a file that already exists, then the contents of that file correctly remain unchanged.) |
CVE-2016-9318 | Medium | libxml2 2.9.4 and earlier, as used in XMLSec 1.2.23 and earlier and other products, does not offer a flag directly indicating that the current document may be read but other files may not be opened, which makes it easier for remote attackers to conduct XML External Entity (XXE) attacks via a crafted document. |
CVE-2021-3468 | Medium | A flaw was found in avahi in versions 0.6 up to 0.8. The event used to signal the termination of the client connection on the avahi Unix socket is not correctly handled in the client_work function, allowing a local attacker to trigger an infinite loop. The highest threat from this vulnerability is to the availability of the avahi service, which becomes unresponsive after this flaw is triggered. |
CVE-2022-26966 | Medium | An issue was discovered in the Linux kernel before 5.16.12. drivers/net/usb/sr9700.c allows attackers to obtain sensitive information from heap memory via crafted frame lengths from a device. |
CVE-2022-21443 | Low | Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Libraries). Supported versions that are affected are Oracle Java SE: 7u331, 8u321, 11.0.14, 17.0.2, 18; Oracle GraalVM Enterprise Edition: 20.3.5, 21.3.1 and 22.0.0.2. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Oracle 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 can also be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. CVSS 3.1 Base Score 3.7 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L). |
To view security vulnerabilities in previous releases, refer to the following release notes:
Severity 1 Resolved Issues
The following Severity 1 issues are resolved in this release:
Issue ID | Sev | Problem Description | Resolution |
---|---|---|---|
SBX-109466 | SBX-123958 | 1 | PortFix SBX-109466: Services are going down after SIP Adapter Profile creation Impact: The CHM process could core when creating a new SMM profile via the EMA. Root Cause: When the EMA creates the sipAdapterProfile and the rule comment is not set, the EMA sends a comment of undefined. When the CHM receives a notification of that change and the comment field was left blank, the CHM cores while displaying that field in the audit log message. Steps to Replicate:
| The code is modified to allow the CHM code to check for NULL values. Workaround: None. |
SBX-119103 | 1 | Abnormally long duration when CDRs are generated for the I-SBC Impact: Abnormally long duration CDRs are generated on switchover for calls that were previously released prior to switchover. A regular STOP record was generated on the active SBC, but on switchover, another STOP record was generated for the same GCID with a disconnect time as the switchover time. Root Cause: While processing the call connect (sending 200 OK on ingress side) and call disconnect (receiving CANCEL) at the same time, CC believed the call was established and made the call data redundant. However, NRM never got to a stable state to make its data redundant. Owing to some CDR processing changes in 9.0 release, the standby CC did not clean up its data until it got a confirmation from NRM that it also cleaned up its standby data. When this did not occur, the CC was left with stale redundant data and resulted in an abnormal CDR getting generated on switchover due to call audit running. Steps to Replicate: Run a continuous call load where the A-party is releasing the call at the same time as the SBC is sending out the 200 OK to answer the call. | The code is modified to check for inconsistencies in call data during redundant call terminations to avoid CC getting left with stale data. Workaround: None. |
SBX-121969 | 1 | Options PING receives Error: No clients are registered to process this request Impact: Options PING receives the following error: "No clients are registered to process this request." Root Cause: If the S-SBC or I-SBC is deployed in an N-1 configuration where N is greater than one, then the action command for the options ping is not registered. Steps to Replicate:
| The code is modified to properly register the action command so that the first SCM process (CE_2N_Comp_ScmProcess_0) will register for the action command. Workaround: Perform the options ping request on the first SBC node with a serviceId of "0." |
SBX-123376 | 1 | Monitoring and the HistoryStatus alarm show a time jump in failover and SM process cores Impact: A double failure occurs because both the active and standby encountered a Healthcheck at the same time while processing a user status command that only the active should process. Root Cause: Both the active and standby encountered a Healthcheck at the same time while processing a user status command that only the active should process. Steps to Replicate: The steps are not reproducible. | The code is modified to prevent the standby from processing the user status command. Workaround: Increase the Healthcheck timers to every two seconds, which is released in release v9.2.3 and higher.. |
SBX-123535 | 1 | One-way audio observed after a second hold/offhold sequence Impact: The SBC is not able to resume a g711 fax call with the silence suppression treatment set to FAX. Root Cause: The off hold is suppressed by the fax treatment logic and results in the SBC responding locally. Steps to Replicate: This is specific to a customer g711 call flow and its interaction with fax settings. | The code is modified to forward the new offer to NRMA for resuming the call, since the data path direction is different from the previous offer-answer. Workaround: Turn off silence suppression using the following CLI command: signaling silenceSuppTreatment treatAsG711SilenceSuppOff |
SBX-123571 | 1 | An SBC switchover occurred due to an SCM process core Impact: A pcrf call with many offer/answer exchanges (>10) between two legs may cause the SCM process to core. Root Cause: The logic of adding the access-network-charging-info parameter to the PCV header continued increasing memory allocated for every SBC offer (re-INVITE), which caused memory corruption. Steps to Replicate: Make a pcrf call and generate multiple ingress re-INVITES that are sent to egress more than ten times. | The code is modified to keep only one access-network-charging-info parameter in the PCV for re-INVITE. Workaround: Use the following CLI command: set media pcrf pcrfCommitment none |
SBX-123831 | 1 | SWE ActiveProfile linux files are gone following openstack rebuilds Impact: On a VM rebuild, 1-to-1 direct Cloud SBC fails to acquire the configuration related to the SWe traffic/config profile. Root Cause: The downloaded configuration (from EMS) was not parsed to fetch and apply the SWe traffic/config profile in 1-to-1 SBC scenario. Steps to Replicate:
| The code is modified to introduce configuration parsing logic for 1-to-1 direct SBC scenarios where the configuration is directly downloaded from EMS. Workaround: Upon rebuild of the active/standby SBC, reactivate the required traffic profile once the application comes up in sync. Both the instances of the 1-to-1 SBC will reboot. |
SBX-123877 | 1 | A customer outage for 3 minutes Impact: The PRS cores as a result of the code accessing an invalid memory location. Root Cause: The code attempts to access a structure that is not allocated yet. This is a very rare race condition that can occur when a specific timer expires shortly after a switchover. Steps to Replicate: This problem is triggered by a race condition and is therefore not reproducible. | The code is modified to add a NULL pointer check to prevent the code from accessing invalid memory. Workaround: None. |
SBX-123880 | 1 | SBC sends INFO even though egress is not supporting Impact: The SBC sends INFO to a peer which is not allowed to receive INFO. Root Cause: The SBC was missing logic to check if the peer is allowed to receive INFO. Steps to Replicate:
| The code is modified to add logic that checks if a peer allows INFO methods. Workaround: Use SMM to respond to 200 OK for INFO. |
SBX-124211 | 1 | Session Version not increased in 200 OK causing peer to drop the call Impact: A call with the Selected Codec in Session Refresh may not increment the session version properly when sending the subsequent SDP. Root Cause: When the SBC suppressed the codec due to the Selected Codec in Session Refresh, the internal flag did not reset properly which prevented the session version increment in response. Steps to Replicate:
| The code is modified to reset the internal flag when the SBC sends SDP. Workaround: Disable the Selected Codec in Session Refresh. |
SBX-124450 | 1 | ImProcess cores frequently Impact: The ImProcess cores when attempting to send a Redundancy message related to the PacketCable 2.0 Lawful Interception while the Mediation Server was unreachable. Root Cause: A bug in the IM mirroring code caused memory corruption which results in a core. The code allocates a message buffer that is not large enough for the Redundancy message that will be written into this buffer. The causes memory corruption when the code writes past the end of the buffer. Steps to Replicate: The bug was found by code inspection. | The code is modified to increase the size of the buffer for the Redundancy message to ensure that it is large enough for the data written into it. Workaround: Make sure the Mediation Server is reachable. |
Severity 2-4 Resolved Issues
The following Severity 2-4 issues are resolved in this release:
Issue ID | Sev | Problem Description | Resolution |
---|---|---|---|
SBX-120845 | SBX-121836 | 3 | PortFix SBX-120845: Daily logrotate job interrupts the SBC configuration export, which then never completes Impact: The logrotate process interrupts the export of the configuration started through the EMA. The Export Configuration process does not successfully complete. Root Cause: The logrotate process closes and reopens the apache logs by sending a HUP to Apache. This results in the Export Configuration process failing. Steps to Replicate: Manually run the logrotate process using the command "/usr/sbin/logrotate /etc/logrotate.conf" while the Export Configuration process (started through the EMA) is running. | The code is modified to run the Export Configuration process with NOHUP when started through the EMA. Workaround: In the "/var/log/sonus/export/history/" path, check the status file in the folder with the time stamp related to the task. The status should report "Success." |
SBX-121891 | SBX-123288 | 2 | PortFix SBX-121891: Switch to FAX (T.38) rejected by SBX 488 Impact: A fax call fails if it involves a mid-call modification before fax re-INVITE. Root Cause: If the route PSP is configured with fax tone treatment as ignoreDetectAllowFaxRelay and the call involves a mid-call modification, then the SBC ignores this fax tone treatment. This results in the SBC rejecting the fax call. Steps to Replicate: Configure an Ingress Route with FTT=faxRelay.
Expected Result: The SBC accepts T.38 re-INVITE and the call transitions to a fax call. | The code is modified to apply the fax tone treatment configuration during mid-call modification as well. Workaround: None. |
SBX-121972 | 2 | A SWE switchover loss of media on hairpin calls Impact: Loss of media on hairpin calls after a switchover to a redundant SBC SWe. Root Cause: There are two issues:
Steps to Replicate: Run a loopback call across multiple LIFs and perform switchover. | The code is modified to replace SmaActiveMns() with SmaIsMgmtActive() to properly determine the node's redundancy role during the notification phase of switchover. As well, SmaIsCloudOrNto1() is replaced with SmaIsNto1() in the BRM task. Workaround: None. |
SBX-123073 | 2 | The SBC Application is not starting due to incorrect NIC type Impact: A 9.2.x SBC SWe VM X710 SRIOV interface fails to come up because of an incorrect NIC type. Root Cause: Under certain error conditions, the ethtool command displays the firmware-version of the SRIOV NICs as "N/A". If this occurs, the corresponding SRIOV NICs are incorrectly considered as virtual interfaces, resulting in the incorrect renaming of interfaces. Steps to Replicate: Launch a 9.2.x SBC SWe on the Openstack VM with X710 SRIOV VFs as the PKT interfaces. The application should come up with the assigned role and with the interfaces in the correct order. | The code is modified to update the interface renaming logic to avoid considering the firmware-version output of the ethtool command for determining the given interface as a virtual interface. Workaround: None. |
SBX-123569 | SBX-124394 | 2 | Portfix SBX-123569: Video/Data stream was not relayed on egress side in both bundled and unbundled scenarios Impact: In a bundled call with audio, video, and data, 'show status global callDetailStatus ' command shows egressDtlsStream3 as DISABLED instead of RELAYED. Also, fingerprint was missing in the INVITE SDP of video and data stream. Root Cause: Issue occurs as dtlsSrtpParams and srtpParams are getting cleared due to a code fix in SBX-121550 in the 9.2.5R5 release. Steps to Replicate:
Observed results: The SBC sends BYE. | The code is modified to revert to the changes in SBX-121550. Workaround: None. |
SBX-123826 | 2 | The StunDtlsPacketsReceived count in the callMediaStatus shows incorrect values Impact: The values for ingress/egressMediaStream1StunDtlsPacketsReceived and ingress/egressMediaStream1StunDtlsPacketsDiscarded are incorrect in "show status global callMediaStatus" and the CDR. Root Cause: The Network Process was copying the wrong area of the media statistics for the ReadMedia API response and caused incorrect values for the two StunDtls statistics. Steps to Replicate:
| The code is modified to align the media statistics area correctly and copy the correct area to the ReadMedia API response. Workaround: None. |
SBX-124033 | SBX-124112 | 2 | PortFix SBX-124033: An SBC MSRP call is failing with a truncated egress INVITE Impact: The SBC truncates the SDP in an outgoing INVITE for the MSRP calls when the DNS query is involved in the call. Root Cause: In non-DNS scenarios, the outgoing INVITE on egress leg is formed only once. The SIP stack in the SBC forms this outgoing INVITE correctly for the first time so there are no issues. In summary, the de-construction and re-construction logic was not working properly with respect to the “a=path” header for MSRP calls. Steps to Replicate: Test an MSRP call with FQDN IP Peer. | The code is modified to correct the error in the de-construction and re-construction logic of the outgoing INVITE. Workaround: Calls will not fail if the IP address is used instead of the FQDN address so that no DNS query is involved with the call. |
SBX-124527 | 2 | The SBC sends re-INVITE (session-refresh) without SDP after a switchover event Impact: The MRF releases a call when the SBC sends an INVITE to refresh the session following a switchover on the SBC, due to the SBC sending INVITE without SDP. Root Cause: The SBC does not make the SDP information redundant for the MRF call leg. Following a switchover, the SBC generates an INVITE without SDP when the session refresh timer expires. Steps to Replicate: Make a call using MRF and then perform a switchover on the SBC. Wait for the session refresh timer to expire and check if the SBC sends out an UPDATE message without SDP instead of an INVITE without SDP. | The code is modified to generate an UPDATE message instead of an INVITE to handle the session refresh when no SDP is available. Workaround: None. |
Severity 1 Resolved Issues
The following Severity 1 issues are resolved in this release:
Issue ID | Sev | Problem Description | Resolution |
---|---|---|---|
SBX-122469 | SBX-122915 | 1 | Portfix SBX-122469: An EG UAT SWe SBC switchover occurs when SRTP and SRTCP calls are made. Impact: SWe_NP process cores and a switchover occurs when the SBC processes certain types of malformed RTCP packets for SDES CNAME replacement with RTCP passthrough. Root Cause: A defect in the RTCP SDES parsing code resulted in memory corruption. Steps to Replicate:
| The code is modified to alter the RTCP SDES CNAME replacement code in order to correct (if possible) or drop various types of malformed RTCP packets. Workaround: Disable CNAME replacement and ssrcRandomizeForSrtp features in PSP (if possible). |
SBX-120982 | 1 | An SCM process core occurred on the Server. Impact: An SCM process cores due to a double free of an internal structure. Root Cause: An SCM cores due to a double free of an internal structure. The structure is in an array of these structures. The array is a fixed size. When attempting to add a new entry to this array, we consolidate the array by removing some of the free entries. In the unlikely event that all of the array entries are in use, we remove the oldest entry and consolidate the array by moving the other entries up. There is a bug in this consolidation code that causes a double free when the entire array is later freed. Steps to Replicate: The steps are not reproducible. | The code is modified to clear out the pointers in an array entry after it moves up to the previous entry during consolidation. This ensures that there are no leftover/stale pointers that might cause a double free. Workaround: None.. |
SBX-122577 | 1 | A core dump occurs on a customer SBC with a processAbnormalTermination. Impact: The CPX cores when deleting a CDR server. Root Cause: The code was missing a check for element type when processing a deletion in the CDR server. Steps to Replicate: The steps are not reproducible. | The code is modified so the element type is processed before deleting. Workaround: None. |
SBX-122225 | SBX-123455 | 1 | PortFix SBX-122225: Call trace status getting enabled after a switchover using the EMA. Impact: Call Trace staying enabled in new active node when switching over, when disabled on the current active. Root Cause: No notifications were getting sent to the standby SBC after issuing a stop command. Steps to Replicate:
Test Result: The call trace state is disabled on the new active. | The code is modified so the correct notification is sent to update the standby node when Call Trace is being disabled. Workaround: Without the fix, the workaround is to disable call trace using new active node's EMA or CLI on, if it is enabled after switchover. |
SBX-122331 | 1 | A customer SBC switchover occurred due to an SCM core. Impact: The SCM cores when processing a call that is using SIP Recording. Root Cause: The code is attempting to access a SIP Recorder call block that is already freed. This occurs because of an edge case call scenario where the call block is freed. Steps to Replicate: This bug was found using the back-trace and through code inspection. The core is happening after the call block gets freed. Attempts to recreate the issue are unsuccessful. | The code is modified to always remove the SIP Recorder call block from the hash table before freeing the call block. Workaround: None. |
SBX-120218 | 1 | The SBC is slow to relay the first register. Impact: PES process is slow to process a D+ request when no call notification group attached to TG. Root Cause: While processing the call notification criteria matching, PES processes all the required strings from called and calling number and then it used to check if there is a call notification group attached to the TG. This is done for each and every route. This process previously took up the processing time when there is no call notification group is attached. Steps to Replicate: Make a basic call and find the difference between the start and end time of PES processing the call. Performance related - may only see difference under a load. | The code is modified to check if the call notification criteria is attached to the TG, and then only process the rest of the required strings. Workaround: None. |
SBX-122304 | SBX-122865 | 1 | PortFix SBX-122304: The standby M-SBC did not take over when the active SBC rebooted in an N:1 cluster. Impact: Switchover did not occur after the SWENP process crashed due to a race condition. Root Cause: Infrequently, a switchover event may not be sent to the standby in specific case of SWENP process crash on an active SBC. Steps to Replicate: The steps are not reproducible. | The code is modified to ensure a switchover event is sent and processed by standby on SWENP crash and other switchover scenarios. Workaround: None. |
SBX-123175 | 1 | In the 925R4, a few calls fail with "NrmaAllocResCmd: paramInsert failed" error Impact: Multi-streams call with large SDP (due to crypto and other attributes) fails if DM and DTLS enabled at the SBC. Root Cause: Interprocess communication buffer requirements for multi-stream call is higher compared to other call flows. However, at present, higher buffer is allocated only if number of streams in call is six. Since the number of streams is not six, higher buffer is not allocated resulting in failure. Steps to Replicate: Enable SRTP/DTLS/DM at the SBC. To re-create the issue: UAC sends INVITE to the SBC with 5 streams (mix of audio/video/application) with crypto and other attributes. Expected Result: The call is accepted by the SBC and succeeds. Actual Result: The call is rejected by the SBC. | The code is modified to allocate a higher buffer if the call involves four or more streams. Workaround: None. |
SBX-122403 | 1 | SWE PAID and FROM translation tables not working post 9.2.4R2 upgrade Impact: The SWE PAID and FROM number translation criteria (cpe type: tgWithCallingNumber) are failing to match after an upgrade or restoration of the backup. Root Cause: When the backup is restored, the info table of tollfree prefix info is not populated properly with the length of the calling number (call processing element type 3). It is getting populated with the length of the trunk group (call processing element type 1). In call processing, when trying to find the record of the trunk group with the calling number, the SBC uses the length of the calling number and not the length of the Trunk group. The same series of events occurs in the upgrade scenario, so the customer encountered this issue post upgrade. Steps to Replicate:
| The code is modified to populate the toll-free prefix info table properly for restore and upgrade cases. Workaround: None. |
SBX-123081 | 1 | The SBC cores after upgrade to v09.02.05R003 Impact: The SBC PRS Process cores with NP indicating multiple cores failing. Memory dump analysis shows problem in the RFC2833 DTMF digit detection area of the code. Root Cause: The problem happens when an ICE/DTLS call is established followed by the endpoint sending RFC2833 DTMF digit packets and with DTMF Trigger Profile is enabled. A pointer to store the digit detected in memory is getting reset to zero after the ICE/DTLS call is established. Steps to Replicate:
| The code is modified to set the pointer to store digits detected properly after the ICE/DTLS call is established. Workaround: Disable DTMF Trigger Profile. |
SBX-123245 | 1 | The SCM Process cores and switched over Impact: Direct Media with multiple audio and ICE call may cause the SBC to core. Root Cause: When receiving multiple audios with ICEs, Ingress is passing only one ICE info of active stream to egress. When the egress leg tries to retrieve the ICE info, it expected to receive two ICE info for two streams. As a result, it reads garbage data which may cause the SBC core. Steps to Replicate:
| The code is modified to correct the logic on the ingress leg that passes all ICE info for each stream to the egress leg. Workaround: Disable ICE. |
SBX-123720 | 1 | No Beep Tone issue Impact: The egress endpoint did not hear a Beep Tone from ingress. Root Cause: When the ingress leg switched to tone player to play beep tone, the resource chain was rebuilt and NAPT learning was restarted on egress leg with RTP flow mode = rcv-only. Hence, no RTP packets are sent to the egress endpoint. Steps to Replicate:
| The code is modified to set RTP flow mode to duplex, if the SBC already learns the remote IP address, when enabling NAPT re-learning process. Workaround: None. |
SBX-123628 | 1 | Transparency profile causes a core dump SBC-GW-GW-SBC Impact: SCM may core during a GW-GW call while transparently forwarding P-Sig-Info header:
Root Cause: The core occurs because the code that is processing the P-Sig-Info header is attempting to access invalid memory. Steps to Replicate: - Call is GW-GW NOTE: This may not be easily reproducible. This code hasn't changed in a long time - but we haven't seen this issue before. This is probably because most of the time this bug may not cause a core. Sometimes it will simply set the pointers in P-Sig_info to addresses that are incorrect but still within the valid memory space (which will NOT cause a core). | The code is modified to ensure that the internal representation of the P-Sig-Info header points to valid memory. Workaround: Remove P-Sig-Info from Transparency Profile. |
SBX-122606 | 1 | There was an SSN issue with ICE/TLS/SRTP/P2P Impact: Possible audio issue involving an incorrect SSN when using ICE/TLS/SRTP/P2P. Root Cause: The SSN value 0 was incorrectly saved in XRES on deactivation for the case when the RID was never enabled in NP while performing NAPT or ICE learning. Steps to Replicate: Use on hold and transfer signaling to interrupt learning during the early stages of the call to potentially get a random SSN and ROC values, which the far end rejects. | The code is modified after the NAPT or ICE learning of a remote address is completed, ignoreRocSsn is set and causes NP to use the random SSN/ROC values from RID memory block. This fix is a similar fix to SBX-119900. Workaround: None. |
SBX-123228 | SBX-123411 | 1 | PortFix SBX-123228: DTMF Intermittently not working post upgrade. Impact: Audio loss after DTMF digits. Root Cause: After ingress received a re-INVITE for a media reconfig, we used a new RID to replace the previous RID. But when the resource chain was re-activated, the new RID was programed SSN = 0 that caused the audio loss. Steps to Replicate: The steps are not reproducible. | The code is modified to:
Workaround: Enable “SSRC Randomize For Srtp”. |
Severity 2-4 Resolved Issues
The following Severity 2-4 issues are resolved in this release:
Issue ID | Sev | Problem Description | Resolution |
---|---|---|---|
SBX-123142 | 2 | Unnecessary re-INVITE was removing a 2833 message Impact: A DTMF telephony-event gets dropped in response to a mid-call re-INVITE. Root Cause: A previous enhancement to support both 8K and 16K DTMF and to transcode 16K, when necessary, contained a defect in the logic that resulted in a call appearing to be a pass-through call. Steps to Replicate:
| The code is modified to correct the logic that was not correctly identifying a call as transcoded between DTMF payload types 100 and 101. Workaround: None. |
SBX-122322 | 2 | SWe_NP - NP crashed with SIGSEGV Impact: The SWe_NP crashes due to a SIGSEGV event. Root Cause: The Segmentation table (a table that points to announcement buffers and has meta data for a call) gets initialized during ANN PLAY command. Since an ANN play command was never issued for a given call, the segmentation table was never initialized. The state machine in NP allowed the execution of a second disable command to proceed (which ideally should not be allowed) and tried to flush and build an announcement packet. Since the Segmentation table was never initialized, the source buffer pointer was NULL and crashed with SIGSEGV. Steps to Replicate: The steps are not reproducible. | The code is modified to the flush and disable the code to handle such conditions. Workaround: None. |
SBX-123225 | 3 | An EMA Prefix Profile display issue occurred after upgrading to 9.2.5R1 Impact: In the Prefix Profile Entry, the values for the following parameters (Matching Pattern, Match Start Location, Total Min Digits, Total Max Digits, Digit Type, DM PM Rule, Apply DM Rule and Determine Area) are not displayed for matching pattern starting with '+'. Root Cause: The URLDecoder was replacing the symbol '+' with blank space ' ' in the method decodeTextFromUI. Steps to Replicate:
Values for the following parameters display (Matching Pattern, Match Start Location, Total Min Digits, Total Max Digits, Digit Type, DM PM Rule, Apply DM Rule and Determine Area). | The code is modified to replace the symbol '+' with '%2B' before decoding in the method decodeTextFromUI. Workaround: None. |
SBX-122516 | 2 | A customer SBC failed-over Impact: For t140<=>baudot interworking, if the t.140 packet with a t.140 block contains a long string with alternating letter and numbers, then it can cause a DSP core dump (Swe_UXPAD). The following string was observed to cause crash "q1q1q2q1q1q221q1q1q1q1q1q2 1q". The SBC allows maximum length of 36 bytes for a t140 block. Root Cause: The buffer allocated to convert t140 block to baudot characters was insufficient for a long character string with frequent transition between figure and letter characters. Baudot character sets have FIGURE and LETTER modes and to switch between the two, a mode switch character has to be inserted. A long character string with frequent transitions resulted in buffer overflow and caused crash. Steps to Replicate:
| The code is modified to increase the buffer size to the maximum possible baudot string size (i.e. 72 baudot characters). Workaround: None. |
SBX-122070 | 2 | SO-SBC (4+1) sends out-of-order 200-OK (SUB) and NOTIFY Impact: The SBC is processing the NOTIFY ahead of the 200 OK for SUBSCRIBE message in certain scenarios where there is no delay between the 200 OK and NOTIFY messages arriving at the SBC. Root Cause: The SBC uses the two digits before the B in the following branch prefix = z9hG4bK18B. In this example, '18' identifies the SCM process which handled the 200 OK response. Due to a bug in the code, the SBC was only looking at one digit, and so the SCM process could not be determined. The SBC had to hold up the 200 OK response until it did a TRM query to determine the SCM process that handled the message. Steps to Replicate: Continually run a call flow where the SBC relays SUBSCRIBE messages and the remote party sends back 200 OK SUBSCRIBE and NOTIFY at the same time. Check that the SBC forwards the messages in the same order; i.e., a 200 OK SUBSCRIBE first, and then a NOTIFY to the A-party. | The code is modified to use the two digits of the branch parameter to route the 200 OK for SUBSCRIBE so there is no delay in processing and the messages are processed in order. Workaround: None. |
SBX-121606 | SBX-123254 | 3 | PortFix SBX-121606: Allow user-config-import on the OAM Impact: The user-config-import command is unavailable on an OAM node. Root Cause: This limitation is being removed as part of an enhancement request. Steps to Replicate:
| The code is modified to allow for the user-config-import command on an OAM node. This should only be used for greenfield deployment of a new cluster using the configuration from an existing golden configuration of another cluster. Workaround: Back up the configuration in CLI format and then edit the CLI to use the correct import order into the new cluster. Update the new cluster specific configuration in the CLI file and then source it in. |
SBX-122159 | SBX-122280 | 2 | PortFix SBX-122159: The ICE process does not immediately respond to a call audit Impact: The call cleanup process always takes the full five seconds to complete, even when all the expected processes respond. Root Cause: The five-second timer for a process starts, but a response never occurs. As a result, the cleanup process is delayed by five minutes. Steps to Replicate:
| The code is modified to reduce the amount of unnecessary calls in the ICE process. Workaround: None. |
SBX-122674 | 3 | Rework on the SBX-115152 logic. Impact: Additional logic change for SBX-118384/SBX-115152 resolved originally in 9.2.5R0. Root Cause: In certain call scenarios, the call control block gets reset on the egress side. This results in the SBC deleting a data pointer to one call leg, thus affecting the SBX-115152/SBX-118384 9.2.5R0 bug fix.. Steps to Replicate:
| The code is modified to add the call control block based on the call direction. Workaround: None. |
SBX-119319 | 2 | The GSX generates a STOP CDR while corresponding with ATTEMPT CDR and not STOP record in the SBC Impact: In a SBX-GSX GW call, the GSX generates a STOP CDR while the SBC generates an ATTEMPT CDR instead of a STOP CDR. Root Cause: This issue is not fully understood and cannot be recreated. Steps to Replicate: Not identified. | The code is modified to add enhanced logging to collect more info. Workaround: None. |
SBX-122734 | 2 | The SBC 5400 is stuck in a LSWU after a switchover or restart Impact: Sync does not complete after a switchover or restart when using Call Notify functionality. Root Cause: Sync does not complete after a switchover or restart when using Call Notify functionality because the standby code detects a duplicate entry in the Call Notify array and returns an error. Steps to Replicate:
For more details on this configuration, see Configuring the SBC to Send Unsolicited Call Notifications to Application Servers. | The code is modified to replace the existing entry in the Call Notify array with the new one when a duplicate is detected. Workaround: None. |
SBX-123550 | SBX-123713 | 2 | PortFix SBX-123550: During a LSWU, audio was lost for incoming calls, but was present for outgoing calls Impact: When ssrcRandomizeForSrtp is enabled, a one-way audio issue occurs after the SBC switches over to the standby node Root Cause: If ssrcRandomizeForSrtp is enabled, the NRMA generates an SSRC for the SRTP leg. The SSRC is sent to the NP when enabling the associated RID. In a hot standby setup, that SSRC is mirrored to standby, but it is not sent to the NP when enabling the same RID on the standby. Instead, the NP adapts the SSRC from the incoming RTP stream or the DSP's SSRC. Once the standby node becomes active, the NP changes the SSRC. If the endpoint sees a new SSRC, it starts decrypting using ROC=0. However, the NP was encrypting on send on the SRTP leg with ROC=2 that prevented the endpoint from decrypting, which resulted in one-way audio. Steps to Replicate:
| The code is modified to send NRMA generated SSRC to NP when enabling the RID on standby node so that NP does not adapt incoming RTP stream's SSRC. Workaround: None. |
SBX-123627 | 2 | Special characters incorrectly display using the "View CLI" option Impact: In the SMM GUI, a couple of special characters incorrectly display in the "View CLI" option. Root Cause: The '<' character is sent as '&' instead of '<' and the \\r\\n => double backslash escaped properly but display as a single backslash in HTML. Steps to Replicate:
The CLI commands display as expected. | The code is modified to replace those occurrences with correct responses to address the issue. Workaround: None. |
SBX-123459 | 2 | Multiple PRS process cores occurred on the server Impact: The PRS process cored due to a XRM task failed health check. Root Cause: The sigPortList in the XRM got corrupted. Numerous freed XRESs were left in it. When trying to activate a new signaling port, the XRM task got stuck in the loop and failed a health check. Steps to Replicate: The steps are not reproducible. | The code is modified to properly free already allocated XRES for other pool(s) during a signaling port allocation routine Workaround: None. |
SBX-121394 | 2 | A call transfer (REFER with Replaces) fails with an OA status 0x54 Impact: An attended call transfer failed due to a race condition when the transferor sends an off-hold INVITE and REFER with Replaces in rapid succession. Root Cause: While the SBC is in the process of bridging a transferee and transfer target, the off-hold INVITE from the transferor triggered a new modify request towards transferee, which caused an offer-answer timeout internally due to previous modify still being processed that leads to a call failure (OA status 0x54). Steps to Replicate:
| The code is modified so that the internal offer-answer timeout is handled to avoid call transfer failure. Workaround: None. |
SBX-123595 | 3 | A unique tag is created for a Notify when the 200 OK was not sent yet in response to a Subscribe Impact: When a Notify received before the initial 200 OK response to Subscribe, the SBC may send an invalid tag in 200 OK Subscribe. Root Cause: After receiving a Notify from Egress, the SBC is using egress service group id as part of tag in 200 OK Subscribe for sending to the ingress. Steps to Replicate: Run the following configuration: Subscribe ->Subscribe | The code is modified to relay a 200k Subscribe to the Ingress service group id. Workaround: None. |
Severity 1 Resolved Issues
The following Severity 1 issues are resolved in this release:
Issue ID | Sev | Problem Description | Resolution |
---|---|---|---|
SBX-120361 | 1 | Receiving a syslog spam about ACL Stats from the SBC1b. Impact: /var/log/syslog fills up with cpsi log entries about unable to read ACL statistics. Root Cause: A problem was found in CPS (Common Platform Service) library retrieving the next resource. CPS keeps a list of allocated resources and the CpsXyzGetNext API is used to grab the next entry in the list. The next resource information was stored in common shared memory and was not thread safe. If multiple threads invoked the same API simultaneously, the result would be unpredictable. Steps to Replicate: The steps are not reproducible. | The code is modified to add a limit to the loop count for the number of allocated resources to ensure the caller of the function passes in a CpsXyzGetNext API storage location to make it thread-safe. Workaround: None. If the kernel syslog gets filled, you must reboot Linux to stop the problem. |
SBX-121444 | 1 | The LWRESD process keeps restarting causing the SBC app to not come up. Impact: The LWRESD Process continues to restart as the interface used by it for ENUM/DNS signaling was down. Root Cause: When a SIP SIG port is selected as the signaling interface for LWRESD, by design the SBC uses the query-source-address parameter in the slwresd.conf file. Upon getting this parameter, the bind stack tries to create a socket on that IP and port. If it is unable to create the socket, the bind stack exits abnormally. Steps to Replicate:
The SBC app does not come up in service as the LWRESD process keep on restarting. | The code is modified to generate the default slwresd conf file if both the SIP signaling port type is 'SIP Signaling IP' and if the signaling port is disabled, since LWRESD cannot perform DNS signaling. The process generates the slwresd.conf based on the configuration when the interface is changed to the in-service state using the CLI.
Note: These steps are only required for an upgrade procedure if the signaling type is 'signalingIP' for the LWRESD Profile. Workaround: None. |
SBX-120330 | SBX-121955 | 1 | PortFix SBX-120330: UX_PAD is dumping core while running evrc to g729 load. Impact: A UXPAD Crash observed while running EVRC calls on GPU. Root Cause: As an oversight, the GPU software does not initialize all GPU EVRC decoder context variables, including the variable used as an index to an array. This led to an illegal memory access occurrence. Steps to Replicate: The steps are not reproducible. | The code is modified so the decoder context variables are initialized to their default values. Workaround: None. |
SBX-115363 | SBX-122011 | 1 | PortFix SBX-115363: AWS: eth1 and eth2 subnets are getting interchanged in an HFE instance. Impact: The AWS HFE Node can sometimes have the wrong IPs assigned to the interface. Root Cause: The AMI image incorrectly sets the interface configuration. Steps to Replicate:
| The code is modified to:
Workaround: None. |
SBX-122149 | 1 | Dead air after call is resumed from hold Impact: SSN/ROC reset after hold that caused one-way audio. Root Cause: In order to prevent reading random values of SSN/ROC in the RID’s memory block, XRM has cleared the remote address saved in XRES's security context. But that change should only apply to the case when the call flow uses a new RID after call modification. In this call flow, the same RID was used after hold. But the SSN/ROC got reset unnecessarily after hold. Steps to Replicate:
| The code is modified to introduce a new flag in XRES's security context. The flag is only set to "true" when XRM detects a new RID. Then when NAPT learning times out, XRM checks this flag to determine whether or not to clear the XRES-saved remote address. Workaround: None. |
SBX-122352 | 1 | GW-GW calls are failing after an upgrade from 9.2.3R3 to 9.2.5R2. The SBC stops processing the call after parsing the MCS EST_CONF message from the egress GSX. Impact: Calls between the SBC and GSX may cause an SCM core dump. Root Cause: A bug was introduced in an internal function. CpcMsgInfoCreateCopy(), which copies the CPC Optional Parameters that are used to pass information about a call between processes and between systems. This bug causes us to calculate the offset to the next parameter incorrectly. When the pointer is incorrect, the code that validates the CPC Optional Parameter will detect an error and cause a core dump. Steps to Replicate: This issue was found by code inspection. The steps are not reproducible. | The code is modified so that it now calculates the offset to the next parameter correctly. Workaround: None. |
SBX-113502 | SBX-122359 | 1 | PortFix SBX-113502: CE_2N_Comp_ScmP SYS_ERR generated Impact: Calls between the SBC and GSX may cause an SYS_ERR and not process the internal parameter content correctly. Root Cause: A bug was introduced in an internal function - CpcMsgInfoCreateCopy(), which copies the CPC Optional Parameters that are used to pass information about a call between processes and between systems. This bug causes us to calculate the offset to the next parameter incorrectly. When the pointer is incorrect, the code that validates the CPC Optional Parameter will detect an error and cause a core dump. Steps to Replicate: This issue was found by code inspection. | The code is modified so that it now calculates the offset to the next parameter correctly. Workaround: None. |
SBX-122509 | 1 | There was a core and failover on the SCM Process coredump and the SBC failed over. Impact: The SCM process cores after an attempt to free a memory block that is already free. Root Cause: A memory block was freed but did not clear the pointer to that freed memory block that is stored in the main Call Block. As a result, the app does not know that this memory block has already been freed. If the app tries to free it a second time, a core is caused. Steps to Replicate: This bug was found by code inspection, and is therefore not reproducible. | The code is modified to clear the pointer to the freed memory block that is stored in the main Call Block. Workaround: None. |
The following Severity 2-4 issues are resolved in this release:
Issue ID | Sev | Problem Description | Resolution |
---|---|---|---|
SBX-120807 | 2 | A memory leak occurred in an Advanced SMM dialog variable. Impact: A memory leak occurred in an Advanced SMM dialog variable. Root Cause: When the egress leg responds with 18x, the SBC fails to update the call control block with new dialog variable ID. As a result of the call teardown before 2xx, the SBC fails to delete the memory of SMM dialog variable. Steps to Replicate:
| The code is modified to always update the call control block with new dialog variable ID when received the responds from peer. Workaround: Disable Advanced SMM. |
SBX-120826 | SBX-121159 | 2 | Portfix SBX-120826: ASAN - run-time error " runtime error: load of value 32524, which is not a valid value for type 'SIP_TRANSPORT_ENUM' in sanitizer logs Impact: ASAN reported "runtime error" error while reading a value related to the transport type while processing a 407 response to a REGISTER message. Root Cause: The code was reading from uninitialised memory while processing the 407 message, which led to reading an unexpected value. Steps to Replicate: Only reproducible while running failed registrations in Ribbon lab using ASAN build. | The code is modified to ensure data is initialised correctly to avoid the problem. Workaround: None. |
SBX-121897 | 2 | The SBC sent SYN to a client port instead of port 5060 Impact: The SBC tried to reopen TCP connection to the client for an incoming call and with the SBC in role of server side using TCP and the connection is already closed. The SBC should not try to reopen connection. Root Cause: The same logic will be applied for the SBC TCP connection as a client Steps to Replicate:
The packet capture shows the SBC trying to reopen the connection in order to send a status message. | The code is modified to prevent the SBC from reopening a connection for an SBC TCP connection as a server. Workaround: None. |
SBX-121620 | SBX-122000 | 2 | PortFix SBX-121620: The SBC is not adding country code +81 in Request URI while sending out INVITE towards egress peer in E2E call flow. Impact: The SBC is not adding country code in Request URI of INVITE. Root Cause: The SBC is not globalizing the number by assuming that calledURI is already globalized. Steps to Replicate:
Expected Result: Check whether the SBC is adding the country code in RURI, the SBC does add country code for RURI. | The code is modified to check whether the calledURI globalized or not. If it is not globalized, the SBC does globalize it and adds a country code. Workaround: None. |
SBX-121633 | SBX-122029 | 2 | PortFix SBX-121633: Missing UI control for Level 4 Trace Messages configuration Impact:
Root Cause: Level 4 Trace Message has been added as an Enhancement in EMA. Steps to Replicate:
| The code is modified to add Level 4 Trace Message configuration:
Workaround: None. |
SBX-122013 | SBX-122086 | 2 | PortFix SBX-122013: RCS SBC - Dropping ingress TCP-segmented MSRP packets (parsing error) Impact: Dropping ingress TCP-segmented MSRP packets (parsing error). Root Cause: The transaction ID was getting mismatched due to low buffer ENUM used for the transaction ID copy, truncating the transaction ID that is later compare to match the End of the Packet. Steps to Replicate: Test the MSRP message having Transaction ID of length 32 characters. | The code is modified to increase the buffer size to 4 bytes to compensate for the full length of the transaction ID that can be at maximum length of 32. Workaround: None. |
SBX-122015 | SBX-122140 | 2 | PortFix SBX-122015: The P-charging vector header has ipx3.xxx.com.1 instead of ipx3.xxx.com.2 Impact: On the egress Leg, the SBC is sending wrong PCV values in the PCV Header. Root Cause: On the egress leg, the SBC was supposed to add PCV header. However, the SBC is applying transparency logic to PCV header and as a result, the SBC send wrong values in PCV header. Steps to Replicate: An INVITE is received with PCV header P-Charging-Vector: icid-value=a9fbd640-30e4-1032-00-00-00-10-6b-03-18-01;icid-generated-at=10.xx.yy.zz;orig-ioi=operatorb.com;transit-ioi="operator_A.1" The sendPCVHeader is enabled on egress leg and PCV transparency is enabled. The SBC sends the generated PCV header and not transparently. | The code is modified so when the SBC adds a PCV header, the transparency is not applied again. Workaround: None. |
SBX-122182 | 3 | SBC manager path check URL character violation Impact: An SBC Configuration Manager path check creates a URL character violation. Root Cause: Since the values are not encoded, the ^ symbol creates an issue. Steps to Replicate:
| The code is modified to encode the values of form elements, which resolves the URL character violation. Workaround: None. |
SBX-122178 | SBX-122219 | 2 | PortFix SBX-122178: The SBC is not rejecting the INVITE received over unsupported transport protocol Impact: The SBC is not rejecting the INVITE received over unsupported transport protocol. Root Cause: The SBC returns a failure in an early stage that causes the SBC to select the default sipSigPort. Due to this, the SBC is further processing the INVITE. Steps to Replicate:
| The code is modified to not select the default sipSigPort. Workaround: None. |
SBX-120767 | SBX-122368 | 2 | PortFix SBX-120767: RESTAPI having 'set' operation limitation when using POST API commands. Impact: RESTAPI having 'set' operation limitation when using POST API commands. Root Cause: The validation point for the /META:metadata table was counting all changes in the current transaction, not just changes to the META:metadata table. This caused the limit of metadata table transactions of 1000 to be exceeded. Steps to Replicate:
| The code is modified to only count changes to the META:metadata table. Workaround: Split the REST request into smaller requests to avoid this issue. |
SBX-122399 | 3 | API packets dropped at the kernel layer Impact: NP continuously reports badRidCb errors. Root Cause: RTCP RID is enabled at the same time as RTP RID is enabled in NP. But when BRM is deactivating the LE2LE_RTCPTERM BRES, it incorrectly sets disableRtcpRid flag to "true" in the RTCP Gen disable command. Even the corresponding RTCP RID was not enabled due to XRM having not resolved the destination MAC address. Steps to Replicate:
| The code is modified to allow the BRM code to set disableRtcpRid flag properly in the RTCP Gen disable command. Workaround: None. |
Severity 1 Resolved Issues
The following Severity 1 issues are resolved in this release:
Issue ID | Sev | Problem Description | Resolution |
---|---|---|---|
SBX-121854 | 1 | A MAJOR event containing "PORT_RANGE: id xxxxx not found" regularly seen in DBG log Impact: A MAJOR event containing "PORT_RANGE: id xxxxx not found" is regularly seen in the DBG log. Root Cause: When a registration expires, there is a 52-second window (based on default retry counts) after the port range control block is deleted and before registration control block is freed. Any SIP subscribe request received within this window is forwarded to egress to use the connection ID of an already-freed port range control block, and results in this error message. Steps to Replicate:
In addition to above tests, please also verify following:
| Corrected the logic which only checked registration status when the usePortRangeFlag feature is enabled. Workaround: None. |
SBX-121889 | 1 | ScmProcess may coredump when logging an INFO level message (or Call Trace message) related to secure media IP change after on-hold/off-hold signal sequence Impact: The ScmProcess may core when logging an INFO level message (or Call Trace message) related to a secure media IP change after a on-hold/off-hold signal sequence. Root Cause: The IPUtilGetStr function was called to retrieve the previous and current IP for logging, which was used as an argument that got passed into the logging function without any additional parameters. In this scenario, the function uses local memory for storing the value. Without specifying a buffer to store the data, the local buffer gets overwritten when called two consecutive times. Consequently, when stringcopy or write is called, the first dataset is gone resulting in a null pointer access that causes a core. Steps to Replicate: Run at INFO level logging and put secure media leg on-hold and take off-hold to reproduce the core. | The code is modified to remove the IPUtilGetStr from the call to log the DBG message. Workaround: None. |
Severity 1 Resolved Issues
The following Severity 1 issues are resolved in this release:
Issue ID | Sev | Problem Description | Resolution |
---|---|---|---|
SBX-121121 | 1 | The SBC application is not coming up Impact: Synchronization of the SIP REC call data may fail due to deficiencies in the synchronization algorithm. Root Cause: The algorithm used to the synchronize of SIP REC call data to the standby system suffered from deficiencies, making the algorithm unreliable. Steps to Replicate:
| The code is modified to correct the algorithm's reliability issues. Workaround: Disable (inhibit) SIP REC calls before bringing up the Standby system or performing LSWU upgrade. |
SBX-121031 | 1 | The SBC 5400 failover occurred on server Impact: The SCM cores due to memory corruption. Root Cause: The memory corruption is caused by a bug where the length field of a structure wrapped around the size of the USHORT that it is stored in is causing an incorrect length value. We use this length to calculate the address where we’re going to copy data into. Therefore, when the length is incorrect the incorrect location data is copied, causing memory corruption. Steps to Replicate: The steps are not reproducible. | The code is modified to prevent the length field from wrapping when it becomes very large. Workaround: None. |
SBX-118290 | 1 | SWE Traffic Profile sync problem in HA Impact: The traffic profile fails to get applied on 1-to-1 SBC 9.2.3R0 Openstack VM registered with V13.02.06R000 EMS when the SBC VM is spawned with the large memory config Profile. Root Cause: 1-to-1 mode SBC registered with EMS fails to apply the large config profile as part of init operations on an active SBC. This results in the creation of a marker file (skipRebootMarker). The presence of this marker file causes the application to reject the traffic profile activation from CLI/EMS on an active SBC. Steps to Replicate:
| The code is modified to update the logic for introducing the marker file. The marker file was introduced incorrectly as part of the large config profile activation. Workaround:
|
SBX-121723 | 1 | Incoming SIP SUBSCRIBE requests from registered endpoints were incorrectly rejected with a SIP 403 Forbidden response Impact: The SBC incorrectly rejects incoming SIP SUBSCRIBE requests from registered endpoints with a SIP 403 Forbidden response. Root Cause: The logic that was added for SBX-119915 to check an endpoint's registration status while processing the incoming SIP SUBSCRIBE request should only apply when the usePortRangeFlag feature is enabled. Steps to Replicate:
| Reverted the SBX-119915 code change. Workaround: None. |
Severity 2-3 Resolved Issues
The following issues are resolved in this release:
Issue ID | Sev | Problem Description | Resolution |
---|---|---|---|
SBX-106015 | SBX-120493 | 2/3 | Ingress T.38 Fax fails when the Egress is SIP or TDM (SBX-12043) / T.4 data size exceeds expected size based on fax speed (SBX-106015) Impact:
Root Cause:
Steps to Replicate: SBX-106015:
SBX-120493:
| To overcome when T.38 peers send TCFs earlier than expected, the stack code is modified to delay TCF generation until the DCS is modulated. Additionally, the T.38 stack code changes are rolled back to produce 72-byte packets for 14.4. TCF. Workaround:
|
SBX-121662 | SBX-112437 | 2 | PortFix SBX-112437: The SCM Process and SAM Process core observed for Enhanced Local Redirection Impact: SCM cores when processing a SIP message that contained 10 Contact Headers and Multiple Identity headers. Root Cause: The length of the data became too large to be stored in a length field that is a USHORT. The contents of the length field wrapped around the size of the USHORT that it is stored in, causing an incorrect length value. This length is used to calculate the address where it is going to copy data into. Therefore, when the length is incorrect it copies into an incorrect location causing memory corruption. Steps to Replicate: Run a test where a SIP message that contained 10 Contact Headers and Multiple Identity headers is sent to the SBC. This message is processed correctly and there was no core. | The code is modified to add defensive code to prevent the length field from wrapping when it becomes very large. Workaround: None. |
SBX-121509 | SBX-114422 | 2 | PortFix SBX-114422: SBC 7000 Trunk Group Stats contain Parent CAC trunk group (a.k.a Shared CAC-Limits Pool) stats with strings "key not found in" instead of Zone name and AC name Impact: SBC 7000 Trunk Group Stats contain Parent CAC trunk group (Shared CAC-Limits Pool) stats with strings "key not found in" instead of Zone name and AC name Root Cause: The Trunk Group Stats considers sharedCacLimitsPool as a TG and since sharedCacLimitsPool is not linked to address context or zone, those fields are populated with 000, and later while trying to fetch value for the TrunkGroupStatusStats file it is updated as "key not found in." Steps to Replicate:
| The code is modified to skip the TrunkGroupStatusStats entry for sharedCacLimitsPool. Workaround: None. |
Severity 1 Resolved Issues
The following Severity 1 issues are resolved in this release:
Issue ID | Sev | Problem Description | Resolution |
---|---|---|---|
SBX-121300 | 1 | Back-to-back cores occurring on the SBC Impact: The SBC experiences back-to-back cores while applying disconnect treatment to calls. Root Cause: The disconnect treatment action is invoked twice for the same call while a new control block is created. This second control block includes updated pointers to for the disconnect treatment resources. The pointers in the first block are now invalid. Consequently, a core results if the first block is used. Steps to Replicate: Configure calls behind NAT with a disconnect treatment applied. (You may need to run a simulated load to reproduce the issue) Expected result: A call fails due to the busy trigger invoking the disconnect treatment. A core may not occur because the failure condition is timing-related. | The code is modified to avoid allocating a second control block and will now log a message. Workaround: Remove the Disconnect Treatment Profile. |
SBX-121298 | 1 | SBC3 SBC 7000 switchover and ScmP process crashes Impact: ScmProcess cores after receiving a re-Invite without SDP. Root Cause: The SIP code is attempting to reference a NULL pointer because the initial Invite does not include SDP details. Since the SBC does not have anything in the sessPtr of the pActiveSgPspStr, updates to these elements results in reading a null pointer. Steps to Replicate: This issue was found by code inspection. | The code is modified to prevent referencing a NULL pointer. Workaround: None. |
SBX-120960 | 1 | SIP to SIP call - no response sent for PRACK Impact: While the call is playing disconnect treatment, the SBC receives an SDP offer in the PRACK, but was not able to respond. Root Cause: The application is already in a disconnecting state and is not able to accept a new SDP offer. Steps to Replicate:
| The code is modified so that SIPS answers the 200 OK for PRACK using the same SDP send out(18x) for disconnect treatment. Workaround: Disaple PRACK on ingress or disconnected treatment. |
SBX-121169 | 1 | Transcoding of DTMF stopped working after upgrade to 9.2.5R0 Impact: Transcoding of DTMF stopped working after upgrade to 9.2.5R0 Root Cause: A code change was made involving the NP to do a payload type substitution because the PT2833 field is set to the received value, and is told to substitute it with a new value. Since the DSP expects the original value, it drops the new value. Steps to Replicate:
| The code is modified to add a check for transcoded calls when setting dtmfPTSubEnable flag. So that dtmfPTSubEnable = FALSE will be sent to XRM when activating XRES.. NP is not supposed to do PT sub for transcoded calls because the DSP will effectively do it. This is the fix for WBA Number = Warning-22-00036730 Workaround: None. |
SBX-118946 | 1 | The Service Instance X2 message does not specify which party put a call on hold in a multi-party call Impact: If an intercepted (legacy LI) call is put on hold, the Service instance message is sent to the mediation server. But the call hold direction is not specified in Service instance message. Root Cause: Currently, the SBC sends a service instance message for CALL_HOLD if any leg is intercepted. Also as per packet cable specification, there is no call direction parameter in the Service instance message. Steps to Replicate: Provision the SBC for LI on the ingress leg where a calling party number is the target. Test-1:
Test-2:
| The code is modified such that currently only the "Service name" parameter is populated by the In Service instance message for call hold/retrieve. After the fix, if the call hold/retrieve is received from egress side, the "called party number" parameter is also added to the Service instance message. If the Call hold/retrieve is received from ingress side, the called party number is not added to the Service instance message. Workaround: None. |
SBX-121065 | SBX-120979 | 1 | Portfix SBX-120979: Standby SLB not coming up after upgrading the SBC due to API changes in Azure cloud. Impact: The SBC application fails to come up after running an upgrade. Root Cause: The generated cloudinit configuration is incorrect for the swapped disk due to cloudinit script API changes. Steps to Replicate: Perform an upgrade on the SBC using the IaC package. | The code is modified to remove the incorrectly generated cloudinit config and link to the correct config. Workaround: None. |
Severity 2-4 Resolved Issues
The following Severity 2-4 issues are resolved in this release:
Issue ID | Sev | Problem Description | Resolution |
---|---|---|---|
SBX-114422 | SBX-121509 | 2 | PortFix SBX-114422: The SBC 7000 Trunk Group Stats contain the Parent CAC trunk group (a.k.a Shared CAC-Limits Pool) stats with strings "key not found in" instead of Zone name and AC name. Impact: The SBC 7000 Trunk Group Stats contain the Parent CAC trunk group (a.k.a Shared CAC-Limits Pool) stats with strings "key not found in" instead of Zone name and AC name. Root Cause: The Trunk Group Stats considers sharedCacLimitsPool as a TG and since sharedCacLimitsPool is not linked to address context or zone, those fields are populated with 000. While trying to fetch value for the TrunkGroupStatusStats file, the TG is updated as "key not found in". Steps to Replicate:
TrunkGroupStatusStats does not contain an Entry for sharedCacLimitsPool. | The code is modified to skip the TrunkGroupStatusStats entry for sharedCacLimitsPool. Workaround: None. |
SBX-119612 | 2 | 200 OK for re-INVITE contains telephone-event although the previous offer/answer does not have it Impact: The SBC sends telephone-event in 200 OK for re-INVITE/UPDATE though previous offer/answer does not have it. Root Cause: This issue is observed mainly when auto answering happens on the opposite call leg. While auto answering, the SBC is not checking whether the modify offer contains DTMF set or not. Due to this, if the Peer contains DTMF already, then SBC is sending response with DTMF set. Steps to Replicate: None. | The code is modified to alter the auto answering logic, such that the SBC explicitly checks whether offer contains any DTMF or not and responds accordingly. Workaround: None. |
SBX-121156 | SBX-120560 | 2 | Portfix SBX-120560: RunTime errors and leaks observed during SBX_4948 suite execution. Impact: RunTime errors and leaks observed during running calls with PAreaInfo header. Root Cause: Missing null checks in the clone function for PAreaInfo header. Steps to Replicate: Run Invite callflow containing PAreaInfo header in ASAN build. | The code is modified to add null checks in the clone function for PAreaInfo header. Workaround: None. |
SBX-118972 | 2 | AWS SBC application went down Impact: The SBC applicaton hit a deadlock due to the SbcSftp executable crashing while it still had access to a lock for updating the ACL table. Root Cause: This appears to be due to the command being called from a cronjob and used in conjunction with expect script to provide password. The SbcSftp command was terminated while it still had access to the SBC lock to update the ACL table and the SBC timed out while waiting for the lock to become available. Steps to Replicate: The problem could not be reproduced. | The code is modified to allow the SbcSftp utility to be extended with a new option to supply the key file with -I option. The new usage will look like below: Workaround: Use "nohup" command in conjunction with SbcSftp so it completes successfully and releases resources. Avoid running the command from a cronjob. |
SBX-120984 | SBX-120895 | 3 | PortFix SBX-120895: Clicking Noise on calls transcoded between PCMU+CN to AMR-WB Impact: Clicking sound observed on AMRWB leg in G711U to AMRWB call. Root Cause: Some packets in the G711U stream contained a G711 payload which was not in multiple of 10ms or 80 bytes. The Playout Buffer at DSP does not handle G711 payload which are not in multiples of 10ms. Steps to Replicate:
| The code is modified so that the G711 payload is made to be a multiple of 10ms by appending silence to the payload while copying it into Playout Buffer if the G711 payload is not in multiples of 10ms. Workaround: None. |
SBX-120771 | 2 | SBC fails to reset ROC to 0 on the DTLS/SRTP call leg upon INVITE w/ Replaces on the RTP leg when the RTP peer started using a new SSRC Impact: The SBC fails to reset ROC to 0 on the DTLS/SRTP call leg upon INVITE w/ Replaces on the RTP leg when the RTP peer started using a new SSRC Root Cause: The call modification caused by the re-INVITE causes the NP media RID resource to be disabled and a new RID enabled for the same call leg. The logic in the NP is such that if LAST_SSRC is 0, it does learning and latches the SSRC of the first packet and does not reset the ROC. If the ssrcRandomizeForSrtp flag were enabled, XRM would apply a new randomly-generated initial LAST_SSRC value to the NP RID and instruct NP to reset SSN and ROC when enabling the new RID. Steps to Replicate:
| The code is modified to add dtlsSrtpAdminState in NRMA while enabling ssrcRandomizeForSrtp for non dtlsSrtpRelay/dtlsSctpRelay cases. As well, in XRM, check is added for SSRC change when encId has changed. Workaround: None. |
SBX-120624 | SBX-119468 | 2 | Portfix SBX-119468:2833 DTMF PT is default instead of negotiated on call leg Impact: During mid-call modification, the SBC uses the configured 2833 PT rather than the previously negotiated DTMF PT if either of the endpoints chooses to remove DTMF PT in subsequent mid-call modifications. Root Cause: If either of the endpoints removes the DTMF during mid-call modifications, the SBC is picking the configured 2833 PT while generating offer towards the other endpoint rather than the previously negotiated PT. Steps to Replicate:
| The code is modified to use the already negotiated DTMF PT during mid-call modifications. Workaround: None. |
SBX-120822 | SBX-118073 | 2 | PortFix SBX-118073: SBC did not use the protected port in some of the headers Impact: When IPSEC connection is created the port allocated for the connection is known as protected port, this is different to the standard 5060/5061 port used for signaling. The SBC was not sending the protected port information correctly in all the via/record-route headers.
Per test result and observation:
Currently, SMM is used to store the port-s in variable, then:
Root Cause: The SBC was using the wrong port information due to an interaction with contact header transparency logic. Steps to Replicate:
| The code is modified to remove the logic related to contact header transparency while selecting the correct protected port information to include the SIP headers. Workaround: Disable "passCompleteContactHeader" flag under IPSP. |
SBX-120980 | SBX-120971 | 3 | Portfix SBX-120971: Standby services not starting after upgrade with FIPS enabled. Impact: Services not starting up after upgrade due to CRITICAL FIPS-140-3 error. Root Cause: Integrity check was failing due to missing /home/oracle/product/oracleDB.sha256sums. Steps to Replicate:
| The code is modified so /home/oracle/product/oracleDB.sha256sums is now present in /home/oracle/oracleDB.sha256sums. Updated file paths in checkFipsSoftwareIntegrity.sh to check in correct locations. Workaround: None. |
Severity 1 Resolved Issues
The following Severity 1 issues are resolved in this release:
Issue | Problem Description | Resolution |
---|---|---|
SBX-120433 | Unexpected switchover on the SBC SWe pair. Impact: The SCM process coredumps after processing a Dialog Event. Root Cause: The cause of the coredump is the code accessing a structure where elements are freed. As a result, the code de-references pointers in this structure that is set to NULL. Steps to Replicate: This issue is not reproducible. | The code is modified to free the Dialog structure only after freeing the elements it points to. This fix prevents dereferencing pointers in this structure that are set to NULL. Multiple stack traces show the same routine in the code as being deficient - this is where additional checking logic is added. Workaround: There is no workaround. |
SBX-119679 | SBC Switchover processAbnormalTermination with core Impact: Subscribe relay with multiple crank back failures may cause the SBC to core. Root Cause: When retransition eventually times out and multiple application crank back failures take place for Subscribe Relay, there may be a core observed due to a stack recursion. This results in a duplicate free of the relay control block. Steps to Replicate: Not able to reproduce due to specific customer configuration. | The code is modified to process the freeing of the relay control block in a separate thread. Workaround: Avoid crank back. |
SBX-118299 | Load Testing - Packet Loss Impact: SWe_NP was not able to handle traffic burst, and observed packet loss. Root Cause: Due to high wakeup latencies in SWe_NP caused by scheduling and CPU idle time management, the packets accumulated in the hardware queue are not drained by SWe_NP in time. Steps to Replicate: The reproduction of this test requires simulating the traffic burst. | The code is modified to change the scheduling policy of SWe_NP to Realtime (SCHED_FIFO) and change the idle behavior of the CPU to poll, instead of halt. Workaround: Reduce the number of calls and number of call generators. |
SBX-117435 | Running a sysdump on a SBC 5400 triggers packet port down/up condition Impact: Port link failure observed while running sysdump on the SBC 5400. This could cause an SBC switchover. Root Cause: Enhancements made to collect more Network Processor (NP) memory area caused interference for the interface driver reading the port link status. This interference caused the driver to falsely report link down. The link status is obtained from the NP processor's (Octeon) register. Steps to Replicate: Run np_mem_dump.pl while the SBC application is running while the mgt/pkt interfaces are in a link up state. | The code is modified to allow the utility function to collect NP memory and NP registers in order to access the Octeon register through the driver instead of directly accessing the register. This avoids concurrent access of the register which caused the false link failure. Workaround: Do not run sysdump or /opt/sonus/bin/np/np_mem_dump.pl while the SBC is running. |
SBX-119464 | The SBC performed switchover with processAbnormalTermination error code Impact: The SCM process cored due to a Healthcheck timeout. Root Cause: An infinite loop is encountered when mirroring Subscription CBs. Steps to Replicate: The steps are not reproducible. | The code is modified to prevent the SBC from spinning in this particular loop. Workaround: None. |
SBX-118608 | After a 491 response due to re-INVITE contention, the SBC continues the call even though the SDP is unmatched. Impact: After 491 response, the SBC sends re-INVITEs with invalid application media format. Root Cause: When the application processes the queued request internally, it loses the other leg application media format that it used for the remote to send out. Steps to Replicate:
| The code is modified to properly store the other leg application media format in SIPS, so that it can send out correctly when it processes the queued message. Workaround: None. |
SBX-117393 | The SCM Process cores and causes a switchover. Impact: The SCM Process cores when attempting to allocate memory. Root Cause: The SCM Process cores when attempting to allocate memory because the memory management code has detected memory corruption. Steps to Replicate: The steps are not reproducible. | The code is modified to prevent writing into this memory block after it is freed. Workaround: None. |
SBX-119111 | The SBC Core has a switchover twice during the day. Impact: SCM cores in SIP code when using SIP Refer Relay. Root Cause: The core is due to an attempt to dereference a NULL pointer while processing a message related to SIP Refer Relay. Steps to Replicate: The root cause was found by code inspection. | The code is modified to make sure the pointer is valid before attempting to dereference it. Workaround: Disable the SIP Refer Relay. |
SBX-120416 | SIPSG code cores due to accessing pktCcb pointer that has been set to NULL Impact: SIPSG code cores due to accessing the pktCcb pointer that has been set to NULL. Root Cause: The fix in the past included a change that sets fsmCcb->pktCcb to NULL after clearing out the contents of the pktCcb. The reason for setting fsmCcb->pktCcb to NULL after clearing out the contents of the pktCcb was to prevent executing the code in SgOaClearPktCcb() more than once. The previous fix was unnecessary because SgOaClearPktCcb() already checks every field for NULL before attempting to free it. Steps to Replicate: The steps are not reproducible | The code is modified to remove the change that sets fsmCcb->pktCcb to NULL. Workaround: None. |
SBX-117476 | Congestion Memory issue. Impact: The SCM process leaks memory when "sendSBCSupportedCodecsForLateMediaReInvite" is enabled in the IP Signaling Profile. Root Cause: The SCM process may not free internally allocated structure when "sendSBCSupportedCodecsForLateMediaReInvite" is enabled in IP Signaling Profile. Steps to Replicate: Run load with “sendSBCSupportedCodecsForLateMediaReInvite” enabled in the IP Signaling Profile and confirm the leak. NOTE: The call flow must result with sending a "NRMA Modify" internally. | The code is modified to ensure that these structures are freed when "sendSBCSupportedCodecsForLateMediaReInvite" is enabled in IP Signaling Profile. Workaround: Disabling "sendSBCSupportedCodecsForLateMediaReInvite" may prevent this issue. However, there may be other code paths or scenarios which may trigger this leak. |
SBX-115937 | A switchover occurs on the SBC due to a deadlock issue. Impact: A switchover occurs on the SBC due to a deadlock issue. Root Cause: When the the authPassword is being fetched multiple times a second, that call was occuring at the exact same time as the CpxTrunkGroupMediaIpSecondaryInterfaceGroupNameValidate was called. Both routines use the same global maapiSocket to do maapi calls to read the confd database. Since the same global socket was being used, the maapi_exists call is hung. Steps to Replicate: In one CLI session, make a lot of calls to get the authPassword: | The code is modified so that the CpxTrunkGroupPassGetElem function performs a 'cdb get' action to get the authPassword, so there is no contention for the global maapiSocket. Workaround: Do not get the authPassword at the same time as setting the mediaIpSecondaryInterfaceGroupName. |
SBX-118999 | After an SBC 9.2.3 SW upgrade, the ACLs are blocking traffic when enabled. Impact: The IPACL rule is incorrectly installed in the NP. Root Cause: You can configure the IPACL rules with or without an ipInterface. If an IPACL rule is configured with an ipInterface, it is not installed in the NP until the associated ipInterface is created and enabled in the NP. The IPACL task tries to re-add those rules that are waiting on the ipInterface for it to receive a 'port up' notification from the NRS. When mixing a set of IPACL rules, some rules that are not defined with the ipInterface are installed in the NP during the startup of the applications, while other rules that are defined with the ipInterface may get delayed while waiting for the associated ipInterfaces to become ready. All of the IPACL rules are ordered by precedence in the CPS context and will be programed in the NP in the same order. When the IPACL task tries to re-add the rules that are waiting on ipInterface, the order of the rules is changed. The new rules are inserted at the proper location in the CPS context, based on their precedence. But there is no corresponding shuffling at the NP layer which causes some newly-added rules to randomly overwrite some existing rules. Steps to Replicate:
This should result in rule 3 showing match counts instead of rule 2. | The code is modified to add all the rules in the NP, including the ones already added on the IPACL retry. Workaround: None. |
SBX-119106 | The SBC application restarts. Impact: A SAM process encounters a core due to a Healthcheck timeout when the SIPCM attempts to open a TLS connection. The security certificate named in the tlsProfile is expired. Root Cause: Two threads are hung while attempting to write a security certificate update () to the DB using the same socket. The purpose of the update is to change the state of the certificate to EXPIRED. Steps to Replicate:
| The code is modified to add a lock preventing two threads from writing to the DB using the same socket. Workaround: Renew PKI Security Certificates before they expire. |
SBX-118402 | SBC Ethernet Port Packet Port Statistics have peak value equal zero. Impact: SBC Ethernet Port Packet Port Statistics have incorrect peak value equal to zero. Root Cause: The SBC has reset the bandwidth peak value after statistics collection. Steps to Replicate: Execute a call load for hours and collect ethernet port packet stat. | The code is modified allowing the SBC to reset the bandwidth counter before it collects the real data. Workaround: None. |
SBX-115213 | Node B unexpectedly restarts when Node A is in SyncInProgress for a long time. Impact: The Call/Registration Data on the SBC shows syncInProgress for an extended period of time. Root Cause: A redundancy message buffer is not large enough to hold the data and causes the sync to be incomplete. This results in the Call/Registration Data to remain in a syncInProgress state. Steps to Replicate: Run multiple Registration/Calls on the SBC. | The code is modified to address the issue. Workaround: None |
SBX-115911 | Application restarted due to processAbnormalTermination Impact: SSREq process coredumped while receiving message with length =0. Root Cause: When the message length is =0, the third party software, Xalan, crashes when allocating memory. Steps to Replicate: Perform SSREq request to ERE when configured for external PSX. | The code is modified to add a check to not process messages with length=0. Workaround: Stop the SSREq process. |
SBX-118473 | The SBC resets SRTP encryption sequence number after a re-INVITE; the anti-replay protection at the far end (on another SBC) discards the incoming SRTP packets until the sequence number approaches the highest recorded sequence number. Impact: Intermittent one-way audio with a duration of more than 10 seconds may occur during call transfers when the remote connection media IP address changed on the secure RTP (SRTP) call leg. The RTP sequence number (SSN) of the outgoing SRTP stream encrypted by the SBC may roll back to a lower value that causes the SRTP packets being discarded by SRTP anti-replay protection at the receiver's end. Once the SSN of the SRTP stream reached the highest recorded value, the audio was back and both parties could hear each other. Root Cause: After the call transfer, the remote connection media IP address on the SRTP call leg was modified without deactivating the media resource chain. This caused the delay in applying the security configuration to the media resource chain, which in turn caused the first one of several SRTP packets being sent with a high SSN number and the roll back of the SSN to a lower value. The remote end discarded the SRTP packets with a lower SSN than the highest recorded SSN. Steps to Replicate:
| The code is modified so in a modify offer or answer for a SRTP call, if the remote connection media IP address is modified on the SRTP call leg, the new IP and security configuration are applied at the same time, without a delay. Workaround: None. |
SBX-119079 | SBC delay in processing Late Media re-INVITE Impact: The SBC is not able to relay/responds to the late media re-INVITE after call is connected. Root Cause: There is a race condition where ingress connects first before egress. The SBC received reInvite and forwards to egress. Egress internally responds 491 because egress is not in the connected state yet. However, internally the CC subsystem is ignoring to relay the 491 and responds due to the wrong state. Steps to Replicate: Configure the passthru latemedia:
| The code is modified to correct the CC logic to relay the 491 responds to ingress. Workaround: Disable passthru latemedia. |
SBX-118991 | Transcoding is failing for T.38 involving SRTP Impact: The SBC is not sending SRTP attributes in an outgoing offer for the G711 fax call. Root Cause: This issue is specific to a call flow where the initial audio call is a pass-through with non-G711 codec and later transitions to fax using G711. In this call flow, the SBC fails to offer SRTP crypto attributes during the fax call. Steps to Replicate: Configuration:
Without fix: The re-Invite at step 3 is sent with out SRTP. | The code is modified to offer crypto attributes even when the initial audio call is using a non-G711 codec. Workaround: None. |
SBX-119574 | SIP to SIP call had no response to PRACK. Impact: The SBC is unable to respond to PRACK with new SDP offer while the call is in terminating state. Root Cause: Call is in terminating state. Steps to Replicate: The Ingress configuration disconnected the treatment.
| The code is modified so the SBC rejects a 500 error response to a PRACK request with an SDP offer. Workaround: Disable PRACK or disable disconnected treatment. |
SBX-119797 | Video call disconnects abruptly due to ACK not getting propagated Impact: The SBC is unable to answer ACK for re-INVITE on ingress leg. Root Cause: The Egress leg is resetting the end-to-end ACK feature after receiving 200 OK offer for latemedia call. As a result, this causes the ACK to not send on Ingress for re-INVITE. Steps to Replicate:
| The code is modified to turn on the e2e ACK feature back after the ACK send out for latemedia call. Workaround: Disable e2e re-INVITE or e2e ACK. |
SBX-117963 | SAM Process coredumps are causing a switchover if FAC enabled and call Id is longer than 24 characters. Impact: While reporting statistics for a Fault Avalanche Control (FAC), the SAM process may core if reporting on a call with a callId larger than 24 characters. Root Cause: While reporting statistics for FAC, an incorrect "maximum size" is used when copying a callId - resulting in the code writing past the end of an allocated buffer and corrupting memory. Steps to Replicate: Run some calls with FAC while collecting FAC statistics. The callids for these calls should be longer than 24 characters. | The code is modified to use the correct "maximum size" when copying the callId. Workaround: Disable FAC. The FAC feature blocks SIP messages of certain key elements that caused multiple coredumps in the past. Disabling FAC will block them from getting processed again |
SBX-119885 | An SCM Process core occurred on both servers. Impact: The SIPCM process cores. Root Cause: The SIPCM process cores because it was accessing a Packet CCB that had already been freed. Steps to Replicate: The steps are not reproducible. | The code is modified to add defensive code to prevent SIPSG from accessing a Packet CCB that is already freed. Workaround: None. |
SBX-120363 | The SBC cores along with disk errors seen (2ndcore) Impact: The SCM cores while attempting to update SIP protocol specific fields in the accounting record. Root Cause: The code is using the wrong function to get a pointer to the URL header structure. Therefore, the SBC is using an invalid pointer and operating on invalid data.. This resulted in an attempt to dereference a NULL pointer, which caused a Segmentation Fault. Steps to Replicate: This issue is not reproducible. The code has been the same since prior to the 7.2 release and this issue hasn't been seen before. Low risk of reoccurrence. | The code is modified to use the correct function to get the pointer to the header. Workaround: Disable CDRs. |
SBX-119908 | sanitizer.CE_2N_Comp_CpxAppProc & CE_2N_Comp_DiamProcess Impact: A small amount of memory leaks while configuring diameter peer IP addresses Root Cause: The configuration validation routines were allocating memory while cross-checking the new CDB configuration and this memory was not freed at the end of the validation. Steps to Replicate: Create diameter peer IPs and check for no memory leaks in an ASAN enabled build. | The code is modified to update the validation routines to make sure the memory is freed so there is no leak. Workaround: None. |
SBX-119912 | LeakSanitizer in CE_2N_Comp_CpxAppProc, CE_2N_Comp_ScmProcess0,1,2,3 Impact: While sending a SIP SUBSCRIBE message, the code was leaking memory if there were PATH headers in the associated subscribed registration data. Root Cause: The code was creating copies of the PATH header information to map into the P-Asserted-ID header and not freeing up all the associated information once the subscription processing completed. Steps to Replicate: Run various SUBSCIRBE for REGISTER event test cases and check there are no memory leaks. | The code is modified to make sure all P-Asserted-ID header memory is correctly freed up. Workaround: None. |
SBX-115152 | SBX-118384 | PortFix SBX-115152: Unknown header is not relayed with re-INVITE call flow in PSX. Impact: Unknown Header Transparency for BYE message do not work in call scenario where SBC receives a re-INVITE from Egress peer and BYE is received from Ingress Peer. Issue is observed only when Re-INVITE is auto-answered by SBC Root Cause: SIP request data for Re-INVITE is not cleared from SIP call control block after Re-INVITE offer-answer completion. This results in duplicate entries for SIP request data in the SIP call control block when the SBC receives the BYE message. During handling of the BYE message at Egress leg, request data pointer is retrieved from call control block to set transparency mask for unknown header, request data pointer of Re-INVITE is picked always instead of BYE message. This results in unknown header transparency issues for BYE. Steps to Replicate:
| The code is modified so that SIP request data is cleared properly for Re-INVITE. Workaround: None. |
SBX-120128 | SBX-120335 | PortFix SBX-120128: The SBC 5400 switchovers occur after an upgrade to v09.02.04R003. Impact: The SCM process may core while attempting to set the original peer SDP address when either NAPT for Media is enabled and the SDP is received, or if ICE is enabled and ICE is in the SDP. Root Cause: In the above two scenarios, the software did not protect against using a NULL packet SG control block address. Steps to Replicate: The steps are not reproducible. | The code is modified to prevent the NULL packet SG control block address from causing the SCM process to core. Workaround: None. |
SBX-115304 | SBX-118371 | PortFix SBX-115304: The SBC replies with a 481 message for INVITE with occasional replaces. Impact: The SBC replies a 481 message for INVITE with occasional replaces. Root Cause: In early dialogue, the state to-tag is not updated in the Hashtable but the from-tag is updated. This issue is why when we tried to look up using only the call ID. As a result, it fails to fetch original call as the original INVITE and the INVITE with replaces had the same call ID. Steps to Replicate:
| The code is modified to look up both the call ID and from-tag for the ingress leg. Workaround: None. |
SBX-118049 | SBX-118081 | PortFix SBX-118049 - The SRTP decryption and encryption fail after an upgrade to 9.2.4R0/10.1.0R2. Impact: The SBC fails to decrypt the incoming SRTP packets, causing a static noise instead of audio on the SRTP calls. Root Cause: Since 9.2.0x, one flag is used in the XRM. XRM_SRTP_SESS_UNENCRYPTED is used for both the unencrypted SRTP and unencrypted SRTCP. When this flag is set, the XRM sends cipherType = NP_CIPHER_TYPE_sRTP_NULL to the NP. The SBC does not to decrypt the incoming SRTP packets. Steps to Replicate:
| A new flag is added, for unencrypted SRTCP: XRM_SRTCP_SESS_UNENCRYPTED The modified NRMA and XRM adopt the new flag for SRTCP. Workaround: Disable the UNENCRYPTED_SRTCP in the cryptoSuiteProfile |
SBX-115231 | SBX-118086 | PortFix SBX-115231: Possible stack overflow vulnerability in the RTCP processing. Impact: Potential stack overflow vulnerability was identified through the internal code review in the RTCP generation subsystem of SWe NP module. Root Cause: The root cause of the problem was identified to the use of variables of an incorrect storage size. Steps to Replicate: The steps cannot be reproduced. | The code is modified to address the vulnerabilities. Workaround: No workaround. |
SBX-114456 | SBX-118382 | PortFix SBX-114456: The AMRWB is transcoded although negotiated end-to-end. Impact: The Transcode option for "different2833PayloadType" feature considers only the 8,000 DTMF payload and the 16,000 DTMF payload is not compared with the opposite leg Peer PSP DTMF, unlike the 8,000 DTMF in earlier releases. This leads to unnecessary transcoding when the same 16,000 DTMF is present in both Ingress Offer and Egress Answer. Root Cause: The SBC does not compare the 16,000 DTMF payload type of Ingress and Egress Leg when "different2833PayloadType:" is enabled, unlike 8,000 DTMF. The SBC should only transcode the call only when the 16,000 DTMF payload is different for both Ingress and Egress; otherwise, the SBC should treat the call for pass-through (PT). Steps to Replicate: TC1:
TC3:
| The code is modified to check both the 8,000 and 16,000 DTMF for a difference in payload type with the corresponding answered DTMF payload types, sent by Egress Peer in Offer Answer function to determine whether the call should be transcode or pas-through. If the DTMF payload types are same, the call is passed through and transcoded if the DTMF payload types are different. These checks are done when "different2833PayloadType" feature flag is enabled. Workaround: None. |
SBX-115616 | SBX-116769 | PortFix SBX-115616: Routing label settings could not be changed in the EMA if created by the CLI. Impact: Unable to change Routing label settings from the EMA UI if they were created using special characters in the CLI. Root Cause: CLI was allowing _ + - . : @ characters in the Routing Label name. The EMA, however, was only allowing _ character in Routing Label name. As a result, attempts to update the Routing Label from the EMA failed. Steps to Replicate:
| The code is modified to allow special characters + - . : @ in the EMA. Workaround: No workaround. |
SBX-117637 | SBX-117969 | PortFix SBX-117637: The SCM Process generates a core and a switchover occurs due to null pointer in a forked call. Impact: The SCM is coring when trying to free memory that has already been freed. Root Cause: The SCM process cores when trying to free memory because of a non-reproducible edge case scenario which causes the memory to be freed before returning from a subroutine. The calling function doesn't handle this correctly. NOTE: This scenario only happens if a downstreamForkingSupport is enabled on the SIP Trunk Group. Steps to Replicate: The steps cannot be reproduced. | The code is modified to prevent the scenario. Workaround: None. |
SBX-115262 | SBX-118383 | PortFix SBX-115262: Unexpected UPDATE from the SBC after UPDATE with media inactive. Impact: Delayed RBT with the monitor profile in early dialog with DylRBT, there is an update from the caller to set the media to inactive. That triggers an UPDATE towards the called with media inactive. Just after that, the SBC sends a new UPDATE with the media direction "sendrcv" to the caller. Root Cause: Since in this case tone is playing and dlrbt is enabled, Update from ingress with DPM inactive is processed by the SBC and sent to egress. Egress responds with 200 OK with Media as inactive which is passed to ingress. The SIPSG sends notification to CC to STOP tone. Tone stops and cut-thru is set in CC. CC sends activate to NRMA and NRMA swaps tone context with cut-through context that has a DPM of sendrecv. NRMA sends update notify ingress with DPM of sendrecv, which is sent to ingress peer as an Update. Steps to Replicate:
| The code is modified to address the issue. Workaround: No workaround. |
SBX-114764 | SBX-118380 | PortFix SBX-114764: The G711 codec is used incorrectly during a G729 UPDATE. Impact: The SBC plays the incorrect media towards Ingress End Point after a call is established. Root Cause: Issue 1: Port is not updated after an UPDATE during tone play. After the SBC receives an UPDATE from Ingress End Point 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. |
SBX-118191 | SBX-119175 | PortFix SBX-118191: An upgrade is successful but revert operation failed - V10.1.0R2 to V11.0. Impact: The SBC application does not come up after revert on cloud 1:1 mode. Root Cause: The SBC application gets stuck due to Openclovis model update cache on old active disk. Steps to Replicate:
| The code is modified to indicate this model update cache and perform a model update on standby after revert to remove any component that is not needed. Workaround:
|
SBX-111832 | SBX-116538 | PortFix SBX-111832: PRS Process and ENM Process coredumps observed in SLB during REGISTER Performance run Impact: The PRS and CHM processes were allowing switchover even when the sync was in progress, causing failures in restoring context in XRM. Root Cause: The sync completion check was incorrect and incomplete, thereby allowing a switchover to occur even when the sync is in progress. Steps to Replicate: Trigger the switchover while the sync is still in progress to check if standby either takes over, or if it restarts to prevent the switchover. | The code is modified to add a thorough sync completion check to the PRS and CHM processes to prevent a switchover when a sync is in progress. Workaround: None. |
SBX-118118 | SBX-118169 | PortFix SBX-118118: Both of the SBC units went down after an unregister from the EMS. Impact: Both of the SBC units went down after an unregister from the EMS Root Cause: The code in the ENM process notifies the deletion of the SnmpAgent snmpTargetMib snmpTargetAddrTable snmpTargetAddrEntry. The ENM process code spawns a thread to delete the corresponding trap from the oam snmp trapTarget table that shares a CDB socket with the SonusSnmpTrapTarget::ProcSubDelete. Steps to Replicate:
| The SonusSnmpTrapTarget::DeleteTrapTargetThread routine is modified to use its own CDB socket to prevent contention from two threads for the same socket. Workaround: None |
SBX-114778 | SBX-116976 | PortFix SBX-114778: The STOP RECORD is missing from CDR VIEWER after a switchover. Impact: STOP RECORD IS MISSING from CDR VIEWER after a switchover. Root Cause: With the current Logstash configuration, the logstash reads the TRC and ACT files only from the time when the logstash was started, which means older data is not read by logstash. When a switchover occurs, by the time logstash is started all the calls would have completed thereby updates to TRC and ACT would have stopped. Logstash does not read the TRC and ACT files until they are updated again. When the updates start, logstash does read from the point where the new data is written and not the old data. This is the reason why stop record of the calls are not shown after the switchover Steps to Replicate:
The STOP record should display. | The code is modified to read the older data and not just the new data. Workaround: None. |
SBX-110857 | SBX-118378 | PortFix SBX-110857: The RTP stream with unknown port (5004) with Delayed RBT after 180. Impact: RTP packets being sent to port 5004 after 180. Root Cause: The RTP packet was the silence packet generated from DSP. Before RTP monitoring was enabled, the call had already been cut through. When RTP monitoring was enabled, NRMA sent a flow change to XRM to change the remote port to 5004. As a result, the DSP-generated silence packet got sent out to remote peer on port 5004. Steps to Replicate:
| The code is modified so the XRM ignores the remote RTP port change. So the RTP packets are sent to resolved remote IP and port. Workaround: None. |
SBX-105749 | SBX-106518 | PortFix SBX-105749: The RTP monitoring failed when the iteration is set to 1 or 2. Impact: The RTP Monitoring is not working as expected when the iteration is set to 1 or 2 Root Cause: When the monitoring period is over, it sends FIRST expiry and FINAL expiry together. As a result, this is not being handled properly leading to non-playing of LRBT. Steps to Replicate: Configure monitoring cycle to 1 and make calls. Ensure that LRBT is heard when monitoring cycle gets over. | The code is modified to play the tone. Workaround: Use n=3 or more. |
SBX-120264 | SBX-120270 | PortFix SBX-120264: The SCM Process continually cores on two SBC 7000s - possibly PCV IOI related. Impact: The SCM Process coredumped due to NULL pointer access for a (GSX) ISUP-GW-GW-SIP call after enabling Generate or Replace PCV feature. Root Cause: The code was trying to read a CPC parameter from the ingress side of the call and the parameter is NULL when the ingress side is ISUP. Steps to Replicate:
Expected result: The SCM Process cores. | The code is modified to ensure the CPC parameter is not NULL before accessing it. Workaround: Disable Signaling > Generate or Replace PCV and apply the fix. |
SBX-118822 | SBX-119267 | PortFix SBX-118822: The HA SBC fails to start on version 09.02.04R001 when the Direct IO Passthrough is used. Impact: The SBC application fails to start on a 44 vCPU instance. Root Cause: The maximum number of vCPUs supported is set to 40 in the SM module. This leads to corruption and a subsequent core-dump on instances with a size greater than 40 vCPUs. Steps to Replicate:
| The code is modified and now set to be in sync with other modules. Workaround: None |
SBX-118367 | SBX-118789 | PortFix SBX-118367: Missing CDR sub fields from Column: Ingress Protocol Variant Specific Data. Impact: Missing CDR sub fields from Column: Ingress Protocol Variant Specific Data. Root Cause: The CDR fields were not updated in SipSgFillProtocolSpecData function from where CDR was getting populated. Steps to Replicate:
| Updated SipSgFillProtocolSpecData function with the CDR field that were missing to address the issue. Workaround: None. |
SBX-119525 | SBX-119957 | PortFix SBX-119525: Observed the SCM Process core while running callflow sanity on the SBC 7000 Impact: Application gets crashed while running call flow sanity on the SBC 7000. Root Cause: During Call Progress when a timeout is hit and CANCEL is triggered towards endpoint then due to invalid/null pointer access core dump is observed. Steps to Replicate: Run a call flow sanity on an SBC 7000. | The code is modified to ensure the pointer is validated for NULL before accessing it. Workaround: None. |
SBX-114415 | SBX-118368 | PortFix SBX-114415: The SBC 7000 standby CE stopped functioning with file corruption and "read only" mode. Impact: When the file system turned to Read Only mode the server did not go for reboot. Root Cause: The SBC became stuck during the read only file system checking but the root cause cannot be determined. Steps to Replicate: The steps cannot be reproduced. | The code is modified to use different commands to check for read only status to try and ensure the SBC automatically reboots to recover. Workaround: An operator needs to manually reboot the SBC in order to recover it. |
SBX-113060 | SBX-119252 | PortFix SBX-113060: The SBC needs to open both protected TCP and UDP port in AKA mode. Impact: The SBC drops messages coming on the TCP when some phone does initial registration over UDP but later sends message over TCP in IMS AKA scenario. Root Cause: When initial REGISTER comes on UDP in IMS AKA scenario, the SBC does not open protected ports on TCP. This will cause problem with some phones, which do initial registration over UDP, but later may send some messages over TCP during call. Steps to Replicate:
| The code is modified so that the SBC opens protected ports on both TCP and UDP when the initial registration is over UDP. Workaround: None. |
SBX-118988 | SBX-119249 | PortFix SBX-118988: The sysDump saved with an owner as root even though sbcDiagnostic 2 is run with linuxadmin as user. Impact: In the Cloud SBC when sysdumps are generated using sbcDiagnostic command as linuxadmin user, linuxadmin is unable to copy the sysdumps due to restricted permissions. Root Cause: sbcDiagnostic was generating sysdumps with root ownership, which did not allow linuxadmin to copy them. Steps to Replicate:
With a fix, linuxadmin should be able to copy sysdumps. | The code is modified to allow copying. Workaround: None. |
SBX-118635 | SBX-118704 | PortFix SBX-118635: Observed the IpSockAddr (0.0.0.0) and Port (0) for Egress leg in GW1 and Ingress leg in GW2 for GW-GW HPC call scenario. Impact: The IpSockAddr and Port fields are 0 in the global callDetailStatus status command in a GW-GW HPC call scenario. Root Cause: In 9.2.4R001, the code is added to not send CPC_OP structures unknown to the GW-GW encoder layer over the GW-GW link to reduce the size of the GW-GW message sent to older SBCs and the GSX. However, it was found that at least one of these unknown CPC_OP Structures, CPC_OP_SIP_ZONE_AC_NAME_STR was used to transfer information used in the global callDetailStatus status command. Steps to Replicate:
| The code is modified to send the CPC_OP structures unknown to the GW-GW encoder layer over the GW-GW link. Workaround: None. |
SBX-116340 | SBX-118932 | PortFix SBX-116340: Customer reported DNS failures on 3 different occasions that appears to be related to "time to live" and negative cache functionality. Impact: DNS records (requests) can become stuck in RESOLVING state within the Agent, which causes the FQDN to become unreachable forever. Root Cause: A DNS request (or it's response), sent between the Agent (e.g., ScmProcess) and the Client (DNS Process), becomes lost. This causes the DNS record to become stuck in RESOLVING state, and the FQDN to become unreachable. Steps to Replicate: The steps cannot be reproduced. | The code is modified to:
Workaround: Manually clear the DNS cache or manually query the "stuck" FQDN. |
SBX-117469 | SBX-119169 | PortFix SBX-117469: Azure: Upgrade is failing from 9.2.3R4 build to 11.0.0 on standalone. Impact: Upgrades are failing in Azure using Ribbon IaC package. Root Cause: Newer versions of the Azure CLI change the way it authenticates, meaning it no longer works with the Ribbon IaC package. Steps to Replicate:
| The code is modified to install Azure CLI version 2.24.0 Workaround:
|
SBX-118683 | SBX-119434 | PortFix SBX-118683: The active T-SBC switches over to the standby T-SBC with a health check failure. Impact: The SWe UXPAD core-dumps due to an arithmetic exception. Root Cause:
Steps to Replicate: The issue is not reproducible. | The code is modified by setting the energy value to the maximum positive value if an overflow occurs. Workaround: None. |
SBX-117762 | SBX-120079 | PortFix SBX-117762: If there is only one m-line in the SDP of UPDATE with port ZERO, the SBC is having different behavior for Audio, Video and Application call flows Impact: Root Cause: The code was written to reject update when media is application and port is zero. Steps to Replicate: Send update with m-line application, video and audio with port as zero. The update should pass to the other side and C-line should be present in all the cases and port should be zero. | The code is modified to allow the call flow to function accordingly after the fix: Workaround: The call flow after the fix: |
SBX-118425 | SBX-118930 | PortFix SBX-118425: The SBC as a TLS server fails a TLS handshake attempt if an ECDHE cipher is used and the TLS client specifies an elliptic curve other than secp256r1 (prime256v1) Impact: The SBC as a TLS server fails a TLS handshake attempt if an ECDHE cipher is used and the TLS client specifies an elliptic curve name other than secp256r1 (prime256v1). Root Cause: The SBC uses the default elliptic curve name secp256r1 (prime256v1) when acting as a TLS server. Steps to Replicate: Use "openssl s_client" to trigger TLS handshake with ECDHE ciphers with curve names secp384r1 and secp521r1. | The code is modified to allow the SBC TLS server to select the Elliptic curve name automatically. Workaround: Do not specify the curve name, or use curve name prime256v1 (openssl 1.0's default on TLS server) when using a tls_ecdhe* cipher suite. |
SBX-116997 | SBX-117538 | PortFix SBX-116997: Late media pass-through calls fail after an upgrade from 8.2.2R0 to 8.2.6R0. Impact: Late media pass-through calls with "RTCP termination for passthrough" flag enabled failed. Root Cause: There are two receiver IDs in the RTCP termination Bus RESource definition. If one of the RIDs was not enabled during the BRES activation because the ingress XRES (ethernet resource) had not learned the destination MAC address yet, then the RTCP Gen was left enabled according to the design. When that BRES gets deactivated, we skip sending RID disable command to NP for that not enabled RID, and also missed issuing RTCP Gen disable command to NP. So when that BRES gets re-activated, the logic detected that RTCP Gen has already been enabled and failed the activation process, which then fails the call. Steps to Replicate: Establish a late media pass-through call with "RTCP termination for pass-through" flag enabled. The SBC sends a SIP BYE once it receives the SDP answer in the SIP ACK SDP. | The code is modified to send the RTCP Gen disable command to NP even when RID is not enabled. Workaround: Turn off the "RTCP termination for pass-through" flag. |
SBX-113233 | SBX-117578 | PortFix SBX-113233: Getting bulk alarms of "sonusSbxNodeResourcesNoPacketsReceivedNotification" Impact: The patch includes additional stats from SWe_NP, which can help in triaging false reporting of RTP inactivity issues better. In addition to this, the patch also includes fixes to prevent false reporting of RTP inactivity when policer mode is set to “Bypass” (from release 9.2.3), and preventing false RTP inactivity reporting in “call hold and unhold scenario” (from release 10.1.2R0). Root Cause: There is no root cause identified. Steps to Replicate: The steps are not reproducible. | The code is modified to add additional NP stats to help in triaging false reporting of RTP inactivity, and also backported some known false detection fixes. Workaround: None. |
SBX-118331 | SBX-119250 | Portfix SBX-118331: EMS re-Synchronization feature not working fine with SBC 7000 Impact: EMS trap resync logic does not work for standard SNMP traps e.g linkUp, linkDown. Root Cause: The EMA was not aware of the mapping from the standard OID traps to trap name and as a result it was unable to resync trap information to EMS. Steps to Replicate:
| The code is modified so that the EMA now understands the OID values for the standard SNMP traps and can resync the info to the EMS. Workaround: None. |
SBX-114533 | SBX-119172 | Portfix SBX-114533: CPX not handling the notification correctly from SDR Impact: SNMP traps destinations set by FQDN are not resolved correctly to IP Root Cause: ConfD CDB API return inconsistent data when reading from CDB_RUNNING. Steps to Replicate:
| The code is modified so that the Management Agent API (MAAPI) is now being used to read the SNMP trap target information instead of the CDB API. Workaround: Restart the SBC. |
SBX-116895 | SBX-118614 | PortFix SBX-116895: A SWe SBC switchover occurred because of an ENM Process core. Impact: The ENM Process crashed when an accounting file rolled over. Root Cause: If the fileCount for the accounting files is reduced substantially (ex. 2048 to 1024), and a rollover occurs, then a shell script is run for each file that needs to be deleted to reduce the file count to the new file count configured. This shell script deletes any hash files in the eventLogValidation directory associated with the deleted accounting file. Steps to Replicate:
| The code is modified so that instead of calling a shell script to delete the hash files, the EvmFileDeleteLogfiles routine has been changed to get a list of all the hash files of accounting files in the eventLogValidation, and deletes the associated hash file when an accounting file is deleted. This reduces the time to delete ~2000 files to less than a second. Workaround: Do not reduce that fileCount for the accounting log files more than 300 files at a time. Rollover the accounting file each time the count is reduced. |
Severity 2-4 Resolved Issues
The following Severity 2-4 issues are resolved in this release:
Issue ID | Sev | Problem Description | Resolution |
---|---|---|---|
SBX-119975 | SBX-118755 | 2 | PortFix SBX-118755: The S-SBC drops calls with 404 (Reason: Q.850;cause=3) with disconnected initiator is internal. Impact: If there is a connection issue with one of the TSBC, the S-SBC fails calls often trying to send allocation requests. Root Cause: This event had 8 T-SBCs:
Steps to Replicate: Configure the S-SBC with 8 T-SBC's. Add an ACL in one of the T-SBC for the port from the S-SBC and then make a few calls and monitor if the calls are not failing. | When attempting to se4nd the request, the RRM:
On receiving GW indication, the possible following scenarios can occur:
Workaround: None. |
SBX-105332 | SBX-105137 | 2 | PortFix SBX-105137: The SBC is not able to parse MSRP media packet 200 Impact: When the SBC received "200" as an MSRP response, it did not forward the same to the 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 received "200" as a response, it did not forward the same to other end. Steps to Replicate: Test 1
Test 2
| The code is modified to update the parsing logic to consider 200 as valid MSRP response. Workaround: UAC/UAS needs to send MSRP response as "MSRP <transaction-id> 200 OK" to avoid this issue. |
SBX-114818 | 2 | 18x/200 Contact header sent by the SBC contains port number different than 5061 Impact: The SBC includes an incorrect port number in the Contact header of the outgoing SIP messages towards registered endpoints when the endpoints use TLS as a transport protocol and a Call Data Channel (CDC; a lawful intercept component) is enabled on the SBC. This behavior results in call failures since the endpoints send SIP requests to unused TCP port numbers. As an example, the SBC includes port numbers 5062, 5063 and others while the configured port number is 5061 (and SBC listens on that port number). Root Cause: A Lawful Intercept related subroutine changes the port numbers in the signaling port table which should always be the configured signaling port. Steps to Replicate: To reproduce the problem, create a basic SIP access scenario where an endpoint registers over TLS (REGISTER – 401 – REGISTER – 200). Then, as calea user, provision the following (the assumption is that you already created an IP interface group named LIG with at least 1 IP interface in it): | The code is modified so that the configured signaling port table is not changed. Workaround: This problem happens only when the CDC is configured and a SIP endpoint uses TLS as a transport protocol. If one of the conditions is not met, the problem will not happen. |
SBX-116271 | SBX-116184 | 2 | PortFix SBX-116184: Call is getting failed with 500 error while running call to Verify the Signalling latency in CNF cluster Impact: SLB was not able to determine the SBC instance name when dialogue transparency was enabled. Root Cause: With the ‘dialogTransparency’ flag enabled on both the ingress and egress zones of ISBC and SLB, the instance-ID tag is not stored correctly in an internal hash for the Dialogue data. Steps to Replicate: The fix has been verified for the following scenarios:
| The code is modified to extract the the instance ID from Call Info from request Message in case of dialog transparency call flow. Workaround: None. |
SBX-118104 | SBX-115994 | 2 | PortFix SBX-115994: Configuring the last trunk as incoming/outgoing direction wise is causing the SBC to remove DTG info on receipt of 3xx Impact: Configuring last trunk as incoming/outgoing direction wise is causing the SBC to remove DTG info on receipt of 3xx Root Cause: During a TRM lookup for DTG information in TrmProcessIpLookupCmd() in case TRM_IP_LOOKUP_EGRESS_TYPE_DTGNAME_ONLY, the SBC iterates through all the Contact headers and saves DTG information (such as TG name, blocking status and Trunk Type ) in CPC_OP_TRM_IP_TRUNKGROUP_LOOKUP_DATA_STR *entry. The same CPC structure is used in SipSgFillDestTgrpToCpcMsgInfo() to copy DTG information of all TGs in CPC_MSG. This DTG information is then used to route the call where TRM lookup is done through DTG name. But in the TrmProcessIpLookupCmd(), TG blocking status "status" and TRM_IPTG_CB_STR *ipTgCbPtr of last Contact header is used to send TRM reply. Since, the DTG of Last Contact is blocked, the TRM reply fails and causes the DTG to lose information. Steps to Replicate:
| Two new local variables TRM_IPTG_CB_STR *ipTgCbPtrTemp and UCHAR statusTemp are created in caseTRM_IP_LOOKUP_EGRESS_TYPE_DTGNAME_ONLY. After each iteration, when the status is != FOUND_BLOCKING, these new local variables are populated and then used in TrmIpSendLookupRpyNfy() for TRM reply. Then while the loop has to iterate for each contact header, the user must populate CPC_OP_TRM_IP_TRUNKGROUP_LOOKUP_DATA_STR. Because we are passing good values of status and ipTgCbPtr in TrmIpSendLookupRpyNfy(), the TRM reply does not fail. Workaround: None. |
SBX-120784 | 2 | The SBC call fail: Extra +1 added to globalized INV R-URI and To header (+1+1) Impact: The SBC sends "+1+1..." in user part of To and Ruri. Root Cause: When the flag related to "Use Called URI as R-URI" is enabled, the SBC duplicates globalization of the user part. Steps to Replicate:
| The code is modified so that there is no need to perform globalization if the flag is enabled. Workaround: Disable "Used Called URI as R-URI". |
SBX-120494 | 2 | The S-SBC is dropping few calls after the S-SBC restart operation. Impact: The SBC was releasing more than one standby call instance when the active call instance was released due to the call cleanup procedure: Root Cause: The standby instance was deleting call instances based on the lowest 24 bits of the GCID while processing the call clean up scenario and check for the same value in all standby contexts. The bottom 24 bits of the GCID are not unique across all standby contexts which resulted in other standby call instances being removed. The code has now been updated to check for the full GCID value while removing instances as part of the call clean up procedure. This was not a problem when the call was released normally on the active instance because it was only removed from the specific context on the standby instance. Steps to Replicate:
| The code is modified so that the standby process code verifies the full GCID value between the standby instance and the call cleanup message so that only the unique call is deleted from the standby. Workaround: None. |
SBX-120758 | 2 | I-SBC is not framing the "P-Charging-Vector" header correctly in UPDATE message Impact: The SBC was incorrectly sending a truncated P-charging-vector header in a SIP UPDATE message, resulting in the UPDATE message causing a parsing error at the next SBC and the call being released. Root Cause: The functionality introduced in 9.2.3 supports a maximum of 63 characters when processing each of the fields in the P-charging-vector header. Functionality was always passing the PCV information over from the ingress side of the call to the egress side of the call and using it even if the feature was not enabled. Steps to Replicate:
| The code is modified to only use the internal data associated with SBX-107845 at the egress side when the configuration is enabled so it is no longer being used for PCV header creation at egress unless it's enabled. This avoids the SBC sending the PCV header in the UPDATE message. Workaround: None. |
SBX-117605 | SBX-117592 | 3 | PortFix SBX-117592: An end-to-end re-INVITE is not working after a 491. Impact: After the SBC responds with an 491 and sends out a re-INVITE, some transparency headers were missing. Root Cause: A logical error that did not check the state of the call correctly. As result, the SBC treats this re-INVITE as an internal re-INVITE (not e2e). Steps to Replicate:
As a result, the transparent headers may missing. | The code is modified to address the issue. Workaround: None. |
SBX-117302 | SBX-120765 | 2 | PortFix SBX-117302: PRS Process and the SMC Process are crashing. Impact: The PRS process was crashing while processing an MRSP message due to the first header line not being present: Root Cause: If the SBC does not receive the MSRP header, line it was coring while processing the transaction id later. Steps to Replicate: Verified with MSRP message without header line. | The code is modified to add a NULL check for transaction ID before processing. Workaround: None. |
SBX-115444 | 2 | CDR jitter value incorrectly calculated if DTMF 2833 packets in the stream Impact: The SBC media jitter stats as reported in the CDRs are calculated incorrectly for received media flow containing DTMF digit events that span multiple DTMF digit packets. Root Cause: For DTMF digit events that span multiple packets, all of the DTMF packets for that event contain the same RTP timestamp (corresponding to the beginning of the event), despite being sent over an interval that could span multiple seconds (for long digit events). The SBC previously included all DTMF digit packets in the media flow's jitter calculations, which in this case would be much larger than the actual jitter. Steps to Replicate: Validate media jitter stats when the DTMF digit events spanning multiple DTMF packets are injected into a media flow received by the SBC. | The code is modified so that the SBC now omits DTMF digit packets (identified by their DTMF payload type) from media jitter stats calculations. Workaround: None. |
SBX-119058 | 2 | Call forking - XRM has at least two XRESs referencing same media resource Impact: The NP reports 0xF0 error for set grace command(0x2C) because the associated media flow has already been enabled. The call works, but this error in turn triggers unsolicited call cleanup. Root Cause: For ATCF or SIP Forking calls, XRM allocates a single IP address/UDP with multiple XRES resources (w/ different GCIDs) all referencing the same Media Resource structure. The XRM process uses a reference count in the XRM_MEDIA_RES_STR. The media flow is enabled when the parent XRES is activated. Then when allocating child XRES, XRM sends a set grace command to NP for the same media flow after it has been enabled in NP. Steps to Replicate: Watch for "Unsolicited Call Cleanup" log messages to be written in DBG upon activation of resource chain involving forked calls. | The code is modified to add a check for media flow reference count, and only sends the 'set grace' command to the NP when the reference count equals "1". Workaround: None. |
SBX-118335 | 2 | *NP 0 error counter macError, mgt0 static route missing and the rx_errors are increasing Impact: Customer upgraded the SBC 5400 from 7.2.x to 9.2.3R4 and the management ports went from 100Mbps to 1Gbps due to feature located in the SBC 8.0.0 release. On some occasions, the management port become inaccessible and CRC errors are reported in the port statistics [ethtool -S mgt0]. Root Cause: The problem is specific to the SBC 5400. When the NRS (Network Resource Service) thread issues an interface stop, followed immediately by an interface start request for all management (mgt) ports, resulting in the following behavior:
However, if the rx/tx are stopped and started in a short time (< 10 milliseconds), the remote link ignores the notification and does not renegotiate the clock/speed/duplex. This leads to the data becoming out of sync with the remote end, which causes CRC errors on the packets received. Steps to Replicate: Run the sbxrestart command multiple times. When the SBC application is running, issue "ethtool -S mgt0" and ensure rx_crc_errors is still 0. | The code is modified to power down the PHY to a low power state when the port stop request is received. Thus, when the port start request is issued, the PHY is powered up to a normal power state. This forces the remote end to detect a link down and then a link up. Workaround: If rx_crc_errors is increasing, disable and enable the mgt port. Use the following Linux commands: ifconfig mgt0 down ifconfig mgt0 up (Replace mgt0 with the mgt port name where rx_crc_errors is increasing.) |
SBX-118051 | 2 | The DTLS client Hello was being ignored. Impact: The SBC may ignore DTLS Client Hello message and cause no audio in STUN/ICE/DTLS calls when the endpoint performs STUN checks for two candidates and the two checks overlap. Root Cause: The SBC is storing remote IP/port in the nominated candidate list, even if BREQ/BREQ_UC messages are already sent. Then when resending the BREQ message, the SBC uses the remote IP/port from the stored nominated candidate array and that is causing confusion. Steps to Replicate: Establish a STUN/ICE/DTLS call and have the endpoint initiate STUN connection checks with two candidates. The STUN checks should overlap in the following manner:
| The code is modified to:
Workaround: None. |
SBX-117900 | 2 | The Azure-SWe SLB reboots as a result of memory corruption. Impact: The Azure-SWe SLB reboots as a result of memory corruption. Root Cause: A memory corruption issue produces a memcpy into a buffer that isn't large enough. This memcpy is in code related to the SLB function. Steps to Replicate: The steps cannot be reproduced. | The code is modified to verify the buffer size before the memcpy. Workaround: None. |
SBX-119900 | 2 | A potential SRTP encryption issue that may lead to one-way audio in media NAT scenarios Impact: While debugging SRTP call logs collected from a customer's network, a potential risk is noticed that random values read from RID's memory block can be used as new SRTP sequence number and roll-over counter (SSN/ROC) when RID is enabled. If it happens, customers may experience one-way audio due to remote peer's anti-replay protection discarding SRTP packets or the remote peer's inability to decrypt SRTP packets. Root Cause: The problem is triggered by NAPT timer expiry and the XRM notification to NRMA with previously learned remote IP address and port number. Steps to Replicate: There are no exact steps to test this.
| The code is modified to clear out previous saved remote IP address in XRES's SRTP/SRTCP encryption/decryption configuration to set correct SSN/ROC values in RID enable command. Workaround: None. |
SBX-117546 | 2 | The SBC is adding phone-context=private for a globalized number in the RURI and To Header. Impact: The SBC adds phone-context=private in the RURI for a globalized number when it is modified using a DM rule. Root Cause: Using a DM rule to add '+' in called number does not result in number being treated as globalized. Steps to Replicate: Configure the DM rule to add a '+' sign. Run SIP-SIP call. The SBC sends a INVITE with globalization in RURI and has phone-context=private. | Do not add phone-context=private in the RURI when the RURI is already in globalized format, including when the userpart of globalization number has a '+' sign. Workaround: Disable DM rule or use SMM to delete the phone-context parameter. |
SBX-117799 | 2 | The SBC fails to recognize the Prack in a multi-dialog (different TO tags) if an 18X and 200(Inv) are received simultaneously. Impact: For a dialog transparency and forked call, the SBC may reject the Prack request due to race condition of back to back 18x and 200 OK messages. Root Cause: After receiving a 200 OK message, the SBC finalizes the active remote tag and queues up the send packet to the ingress due to a pending Prack. When the Prack is received, the SBC rejects it because the compare for the Prack comes from a different remote tag than the one already stored in the 200 OK message. Steps to Replicate:
| The code is modified to validate the remote tag based on the forking list not the final one. Workaround: Disable the Prack. |
SBX-119107 | 2 | The SBC in a TLS Client role does not verify the peer's certificate if authClient is set to "false" Impact: The SBC in a TLS client role does not verify the peer's certificate if the authClient flag in the tisProfile is set to "false". Root Cause: The issue is caused by an invalid configuration. For an SBC in SIP Peering environment, the recommended value of the authClient flag is "true". For an SBC in SIP Access environment, the recommended value of the authClient is "false". In a SIP Peering case, the tlsProfile's authClient may be set to "false" inadvertently and the SBC in a TLS client role does not verify the peer's certificate. Steps to Replicate:
The TLS session is established without verifying peer's certificate chain. | The code is modified to verify the peer TLS server's certificate when the SBC acts as a SIP-TLS client, irrespective of the authClient setting. Workaround: Correct the configuration by setting authClient to "true" in SBC Peering case. |
SBX-117506 | 2 | The SCM Process was leaking a resource related to a NRMA sessPtr. Impact: The SCM process may leak memory in some early call failure scenarios. Root Cause: In early call failure scenarios, a different function is called to free the Call Block (and the memory linked off of it) than the function that frees the Call Block in successful call scenario. The function that is called in some early call failure scenario was not freeing all of the memory that had been allocated for the call. Steps to Replicate: The steps cannot be reproduced. | The code is modified so that all the memory that is allocated for a call is freed in all early call failure scenarios. Workaround: None. |
SBX-119965 | 2 | RtmSbyIcmHandle PRS cores, standby PRS cores when modifying IP Header Impact: Standby PRS process cores in 1 to 1 HA mode. Root Cause: The standby BRM mirrors modified IP hdr structure to standby. Steps to Replicate: There are no steps to recreate the PRS core. | The code is modified to check redundancy mode and set mirroring flag accordingly since XrmFlowChange() can be invoked from active and standby context. The BRM mirroring function was originally invoked from XrmFlowChange(). Workaround: None. |
SBX-111934 | 2 | A 300 response with embedded Identity header size of over 512 bytes in the contact is discarded with Force-Requery Redirection Impact: The SBC drops embedded Contact header in 3xx responds when larger than 2k bytes. Root Cause: Currently buffer support for embedded header is too small (max = 2k bytes). Steps to Replicate:
| The code is modified to increase buffer support up to 6,000 bytes. Workaround: None. |
SBX-119463 | 2 | The remote DTLS/SRTP Peer discards the SRTP packets due to an unexpected increase in ROC encryption. Impact: There is a one-way audio issue on the DTLS/SRTP call leg after an INVITE is sent with Replaces on the RTP call leg. Root Cause: When the SIP registrar switched over, it signaled a call hold combined with an INVITE with Replaces method to modify the media path. The call was put on hold and existing Ethernet Resource (XRESs) and Bus Resources (BRES) were deactivated. A new BRES with new RID was allocated and replaced the previous BRES. Before activating the new BRES, Ethernet Resource Manager (XRM) calculated the new SSN/ROC based on XRES's saved SSN/ROC. But in the calculation, the XRM incorrectly increased ROC value which caused one way audio after the call is re-activated. Steps to Replicate: The steps are not reproducible. | The code is modified to correct the resource allocation logic in XRM. Workaround: None. |
SBX-118145 | 3 | The "EMA - System Administration - File Upload" does not allow a .pfx certificate file to be uploaded. Impact: The EMA does not support the uploading of a certificate file with a .pfx extension through the "EMA - System Administration - File Upload" page. Root Cause: There is no requirement to allow a file to be uploaded with a .pfx extension, hence the support for the same is not available. Steps to Replicate:
The upload of the file will be successful. | The code is modified to allow a file with a .pfx extension to be uploaded. Workaround: The file has to be manually copied to the SBC through the SSH. |
SBX-118180 | 3 | A duplicate MIME-Version header is added on a SIP over Core call. Impact: A duplicate MIME-version header is added by the SBC when an incoming INVITE already has the MIIME-version header. Root Cause: When the SBC encounters MIME content it adds the MIME-version by default. When an unknown header transparency is enabled at the egress IPSP and the incoming message has a MIME version header, it is transparently passed to the egress. This results in A duplicate MIME-version header at the egress side. Steps to Replicate:
| The code is modified to check for the MIME content and the MIME-version header. If there is an unknown header transparency then it is not added it to message. Only the MIME-version will be added by the SBC. Workaround: None |
SBX-118353 | 3 | An incorrect DSP insertion/rejection reason can be seen recorded in the ACT record in the case of an incomplete offer/answer. Impact: An incorrect DSP insertion/rejection reason is the result of an incomplete offer/answer. Root Cause: Example:
In the problem scenario where the T.38 is enabled as transcodable codec during an initial offer/answer, the SBC is not able to find the heaviest transcodable codec. The setting for the dspRejectionReason is "Rejected codec unlicensed". Steps to Replicate:
| The code is modified to update the dspRejectionReason to "Rejected codec unlicensed" for only the cases where the license is unavailable . Workaround: None |
SBX-117901 | 3 | Log is incorrect when using regex to filter value to be stored. Impact: After adding an SMM rule for a value to a variable, there is a logging problem only - the wrong value is being written in the DBG log. Root Cause: Logging the wrong data. Steps to Replicate: Configure the SMM rule to store a value to a variable and look for the debug log message: "SipsMmUtilStoreValue ..." | The code is modified so the data log is stored to a variable correctly. Workaround: Ignore the logging message. |
SBX-119032 | 2 | Parsing the ttc-charging-params in the P-Charging-Vector only succeeds if the parameters have a certain order. Impact: Parsing of ttc-charging-params in P-Charging-Vector succeeds only if the parameters have a certain order. Root Cause: The issue is with the contractor parameter that is also picking up all subsequent parameters. Steps to Replicate:
All the subsequent parameters are ignored. | The code is modified to correct the Contractor parameter to be telephone number only. Workaround: Use the SMM to reorder the parameters. |
SBX-119709 | 2 | ASAN : ERROR: AddressSanitizer: SEGV on unknown address 0x000000000004. Impact: While generating early attempt CDR records, the code was trying to read ingress remote gateway information that was not available and this resulted in trying to deter a NULL pointer. Root Cause: The code did not account for an edge case scenario where ingress remote gateway information was not available and tried to access a NULL pointer, which can result in a coredump. Steps to Replicate: Run some call scenarios where the incoming call is queued and then processed later. | The code is modified to check if the pointer is valid before trying to read from it. Workaround: Disable early attempt CDRs to avoid this issue. |
SBX-116820 | 2 | The LDG goes down and triggers ARS - IP ACL. Impact: The XRM debug command failed to dump static discard ACL stats. Root Cause: The existing logic only dumps maximum 100 entries of each allocated ACL list. If a user has more than 100 allocated ACL list in admit TCAM ACL list, then the entry 101 to 200 is dumped for next category of ACL list, and so on. Steps to Replicate:
| The code is modified to:
The change applies to both ACL config and stats. Workaround: Configure less than 10 signaling ports. |
SBX-118393 | 2 | The SBC is not sending message over IP Sec tunnel to UE when UE idles around one hour. Impact: In IMS AKA connections, the SBC was sending a response to UE in clear when UE switched communication from UDP to TCP Root Cause: The SBC was not opening IMS AKA ports for TCP communication when initial registration happened over UDP Steps to Replicate: Run initial registration over UDP. Send INVITE/PRACK over TCP and UDP. Repeat the test with initial registration over TCP. | The code is modified to allow communication on both UDP and TCP irrespective of whether initial registration was on UDP or TCP. Workaround: None. |
SBX-116163 | 3 | G722 is in 183/200 SDP to ingress peer but 711U audio packets sent Impact: When the SBC is playing tone and in subsequent response the Codec is changed, the SBC is not sending updated codec toward Ingress. Root Cause: When the codec is changed in 183 after 180 w/o SDP, the SBC sends old codec in 183 and tries to send the updated codec in the Update. However, since offer answer is not completed the SBC queues the update. After 200 OK the SBC should release the queued SDP. However, in the earlier release the queued SDP was not released Steps to Replicate:
The SBC should trigger re-INVITE toward ingress with updated codec (g722). | The code is modified to release the queued SDP when 200 OK is received Workaround: None. |
SBX-117639 | 3 | Uploading a .p12 file through the Configuration --> Security Configuration --> Commands --> Upload Certificate logs the user out. Impact: Uploading a .p12 certificate through the "EMA - Configuration - Security Configuration - Commands - Upload Certificate" results into logging out the user and failing to upload the certificate. Root Cause: The CSRF token was not passed in the certificate upload request. Due to this, the upload request was rejected and the user is logged out. Steps to Replicate:
| The code is modified to pass the csrf token in the certificate upload request. Workaround: Upload the file through the Administration --> System Administration --> File Upload --> Add Files to Queue --> Upload All Files. |
SBX-120114 | 2 | LeakSanitizer error found in sanitizer.CE_2N_Comp_ScmProcess_0,1,2,3 Impact: The SBC leaks a small amount of memory while loading the ISUP signaling profile from CDB. Root Cause: The functions which read the ISUP signaling profile from CDB were allocating memory to store the information before storing internally and did not free up the memory at the end of processing. Steps to Replicate: This issue was only observed while testing with an ASAN enabled build as the amount of memory leaked is so small. | The code is modified to make sure that memory is correctly freed at the end of reading the ISUP signaling profile information from CDB. Workaround: None. |
SBX-119603 | 2 | LeakSanitizer: detected memory leaks. Impact: The SBC was leaking memory while processing MTRM configuration data. Root Cause: While processing the MTRM configuration, the SBC was reading data to internal memory for validation and not freeing up the memory at the end of the validation process. Steps to Replicate: Run various MTRM configuration changes and check there are no memory leaks. | The code is modified to make sure the configuration validation memory is correctly freed up at the end of processing. Workaround: None. |
SBX-119964 | 2 | The SCM Process cored during call execution of re-INVITE/UPDATE call scenarios. Impact: The SCM process was coring during re-INVITE/UPDATE call scenarios. Root Cause: The code was trying to update packet ccb information, resulting in the dereferencing of a NULL pointer and a coredump. Steps to Replicate: Re-run a selection of re-INVITE/UPDATE test cases to confirm no coredump occurred. | The code is modified to ensure that the pointer is not NULL before dereferencing the pointer to avoid a coredump. Workaround: None. |
SBX-118373 | SBX-118928 | 3 | PortFix SBX-118373: There was an Active SBC 7000 DNS Process core. Impact: The DNS Process on the active CE on a system switchover may coredump. Root Cause: A NULL DNS TCB (transaction control block) was encountered while the Active CE was shutting down (during restart). Steps to Replicate: The steps cannot be reproduced. | The code is modified to guard against using a NULL DNS TCB. Workaround: None. |
SBX-110756 | SBX-116904 | 3 | PortFix SBX-110756: Wrong behavior with sipAdaptiveTransparencyProfile enabled. Impact: When the SipAdaptiveTransparencyProfile was enabled and the SBC received 200 OK with SDP, it was sending ACK without SDP in late media scenario cases. Root Cause: The SDP was not being added in ACK in late media cases. Steps to Replicate: The following are the test cases used in the call flow:
| The code is modified to add SDP in ACK for late media cases. Workaround: None. |
SBX-117280 | SBX-117758 | 2 | PortFix SBX-117280 to 8.2.5R007: Apache Axis security issues Impact: The following vulnerabilities related to Apache 1.2 were identified with in the Ribbon SBC application: Issue 1: The LI uses unsupported Apache Axis 1.2 (2005) on JBoss 5.1 (2009). Issue 2: The LI exposes the Apache Axis AdminServlet without authentication (default for Axis 1.2). Issue 3: The LI runs as the sonusadmin user, a privileged account. Root Cause: The LI uses unsupported Apache Axis 1.2 (2005), exposes the Apache Axis AdminServlet without authentication and runs as the sonusadmin user, a privileged account. Steps to Replicate:
| The Apache Axis cannot be upgraded to version 1.4 for issue 1 due to the following: The Axis 1.2 has 3 vulnerabilities CVE-2018-8032, CVE-2014-3596 and CVE-2012-5784 and the SBC application is not impacted by any of these. Axis 1.4 has four vulnerabilities (3 from version 1.2 plus 1 new) out of which CVE-2019-0227 (this is the new one in version 1.4) could impact the SBC application. As a result, for issue 1 no fix is required. For issue 2 and 3, the code is modified to remove the AdminService. Workaround: None. |
SBX-117293 | SBX-118034 | 3 | PortFix SBX-117293: Unable to import a large SSL certificate to the standby node Impact: Unable to import a large SSL certificate to the standby node. Root Cause: Certificate was not getting restored on standby as its content was getting corrupted due to bufferoverflow. Steps to Replicate:
| The code is modified to add validation to prevent bufferoverflow. Increased size of subjectAlternativeDnsName entries to 4096 chars. Workaround: None. |
SBX-112042 | SBX-117525 | 3 | PortFix SBX-112042: The SAM hangs and crashes during a correct switchover attempt. Impact: After a switchover, the SAM process was not being terminated correctly. Root Cause: SIPCM Terminate was taking longer time than AMF specified time value of two minutes and as a result, the AMF was forcefully aborting the SAM process. Steps to Replicate:
| Incremented the AMF terminate timer from 2 min to 4 min for SAM process. Workaround: Run the below cmd to increase the AMF timer value without any code changes. |
SBX-111141 | SBX-118238 | 3 | PortFix SBX-111141: The SBC 7000 softwareUpgradeStatus shows invalid characters for upgradeCompleteTime Impact: After performing an upgrade, the upgradeCompleteTime field was not getting populated with the correct value. 'upgradeCompleteTime' showed invalid characters. Root Cause: A variable ‘tmp’ defined within SonusSmSoftwareUpgradeCsv::populateTime has a pointer reference to SonusSmSoftwareUpgradeCsv::setSoftwareUpgradeCompleteTime function. Since ‘tmp’ variable’s scope was limited to SonusSmSoftwareUpgradeCsv::populateTime we were getting corrupted value when we access that in SonusSmSoftwareUpgradeCsv::setSoftwareUpgradeCompleteTime. Steps to Replicate: Perform an upgrade and check upgradeCompleteTime through the CLI command: | The code is modified by making the ‘tmp’ variable a static variable, so that gets allocated for the lifetime of program. Workaround: None. |
SBX-116240 | SBX-117343 | 3 | PortFix SBX-116240: EMA TLS profile certificates handling is not working properly. Impact: The EMA TLS profile certificates handling is not working properly. Root Cause: The EMA TLS profile certificates were not getting restored if incorrectly configured. Steps to Replicate: Try configuring EmaTlsProfile clientCaCert and serverCert incorrectly:
| The code is modified to perform validation to ensure user doesn't configure emaTlsProfile. Workaround: Reconfigure EmaTlsProfile with correct certificate types for clientCaCert (remote) and serverCert (local/local-internal). |
SBX-119224 | SBX-119293 | 2 | Microsoft Azure reserves port 65330. Impact: Some DNS queries fail to get a response in an Azure deployment. Root Cause: Microsoft does not allow VMs to use port 65330. The DNS queries are sent using this local port and are dropped. Steps to Replicate: Run DNS queries for a long period of time and check that port 65330 is not used. | The code is modified to mark port 65330 as reserved. Workaround: The Linux configuration can be manually updated to reserve the port.
|
SBX-117921 | SBX-117923 | 2 | PortFix SBX-117921: A de-reference a NULL return value. Impact: The SCM process allocates a null pointer resulting in a crash. Root Cause: While trying to remove the EVS codecs from a call with a leg associated to the MRF/MRFP, the associated call leg is removed due to a race condition and the code dereferences a NULL pointer. Steps to Replicate: The steps cannot be reproduced. | The code is modified to defend against the race condition and validates that the associated call leg pointer is not NULL before dereferencing it to avoid a coredump. Workaround: None. |
SBX-119262 | SBX-119295 | 2 | PortFix SBX-119262: ednsPayloadSize value is not applicable after S-SBC switchover Impact: The ednsPayloadSize value is not taking effort following a switchover. Root Cause: The SBC was missing code to restore the ednsPayloadSize value in an N:1 configuration. Steps to Replicate: Assign a value to the ednsPayloadSize of the DNS configuration check that it is taking effect and then perform multiple switchovers and check that the configuration is still taking effect: | The code is modified to correctly restore this configuration value. Workaround: Following a switchover, the operator needs to remove and reapply the edns configuration value. |
SBX-118109 | SBX-118139 | 2 | PortFix SBX-118109: EMA: Terminate call is not working from EMA Impact: Terminate call command is failing from EMA Root Cause: When terminate call operation is performed, the terminate call xpath is encoded by the UI and sent to the backend. The backend, however was not decoding the xpath due to which the operation was failing. Steps to Replicate:
The call should get terminated | The code is modified to decode the xpath in the backend. Workaround: No workaround. |
SBX-113593 | SBX-117384 | 2 | PortFix SBX-113593: Observed that callResources are not properly clearing after the call is complete. Impact: In a DSBC setup with multiple nodes in the T-SBC cluster, for the initial INVITE processing, resources (DSP, public xres and private xres) were allocated from TSBC1 (for codecs G729 on offer leg, G711 on answer leg). After receiving an answer with 729, the resources from TSBC1 were cleared up properly and the new resources allocated on a TSBC2 for G729 on leg0 and G729 on leg1, with priv xres(s) cleared up since it is a single DSP call. The call turns to be G729-G729 transcode. Upon receiving a re-INVITE with G711, resources (dsp+priv xres+public xres) were allocated from TSBC1, and upon receiving answer (200 OK) from UAS, new resources were allocated from another TSBC (TSBC2). Before activating these new resources from TSBC2, the TSBC1 resources on the call leg have to be deallocated. However, this was not being done correctly. Root Cause: While freeing up resources for initial offer-answer on TSBC1, an incorrect resource mask (only dsp, and not the public/private xres) was being set in the deallocation command by S-SBC to TSBC1. This resulted in the call structure on TSBC1 being held despite the call being terminated and resources being freed. Steps to Replicate: Set up: Run D-SBC with multiple nodes in TSBC cluster. Scenario:
| The code is modified to reduce the number of DSP re-allocations between TSBCs by not allocating fresh DSPs for every new offer, unless absolutely required. This is achieved by performing the following tasks:
Also, while deallocating resources on the T-SBC from the earlier offer-answer, Workaround: None. |
SBX-117948 | SBX-119167 | 2 | PortFix SBX-117948: Deletion of a SMM Profile with 768 rules is failing. Impact: Deletion of a SMM Profile with 768 rules is failing Root Cause: There was a restriction of 1000 transactions per commit to avoid health check issues leading to failure while deleting SMM profile with large number of rules. Steps to Replicate: Validate that deletion of SMM profile with 768 rule succeeds. | The code is modified as the operation was already being performed by disabling the healthcheck timeout for the duration of operation. Workaround: No workaround. |
SBX-116605 | SBX-116737 | 2 | PortFix SBX-116605: The SBC does not log SIP messages to the TRC file when routing calls using the DNS Lookup. Impact: The SBC does not log SIP messages to the TRC file when routing calls using the DNS Lookup. Root Cause: During a DNS lookup, the LogInfoSpec is not set with the proper logging details in the SIPCall data structure. Steps to Replicate: Make a call from the Ingress side with the DNSLookup enabled. Post the call as successful and check the TRC file. | The code is modified to address the issue. Workaround: None. |
SBX-118922 | SBX-119146 | 3 | PortFix SBX-118922: There was a problem on the EMS SBC Manager's SIP Active Register Name Status List. Impact: There was a problem on the EMS SBC Manager's SIP Active Register Name Status List. Root Cause: The SBC browser reloads the screen when clicking the search button. On a reload functionality check for previous search text, if any available it will trigger search button. As a result, this loops continuously. Steps to Replicate:
The page returns an entry according to the search text. The page does not refresh (loop). | The code is modified to stop the default browser behavior by clicking the Search button. Workaround: No workaround. |
SBX-116335 | SBX-117572 | 2 | PortFix SBX-116335: The SBC EMA presents only the SSL server certificate, instead of the full certificate chain. Impact: The SBC EMA/PM web server isn't sending the full certificate chain while negotiating the TLS with clients. Root Cause: The SSLCACertificateFile option is commented in SBC which makes the EMA/PM server send only its serverCertificate to the clients. Steps to Replicate:
| The code is modified to add the SSLCACertificateFile option. Now the EMA/PM web servers will send the CA certificate along with the server certificate during TLS negotiations. Workaround: None. |
SBX-114056 | SBX-116411 | 2 | PortFix SBX-114056: An RTCP goodbye message is sent after a 183 RESPONSE. Impact: When monitoring a profile is enabled with an early media configuration, the early media from the endpoint is triggered. The Root Cause: The indication to stop monitoring is passed as soon as the early media is received. The deactivation and reactivation of resources cause it to send the RTCP bye packet with the SSRC. The SSRC is received from the endpoint. Steps to Replicate:
| The RTCP bye packet is suppressed for early media when the endpoint is playing the media. Workaround: Disable the monitoring profile. |
SBX-118050 | SBX-120032 | 2 | PortFix SBX-118050: The TERM IOI value has not returned in 18x/200 OK to the caller as expected in the IPX PCV header management. Impact: Part of a feature introduced in the SBC Core 9.2.3 release contained these requirements: Customer network
Partner network
Ingress TG: Both SIPCORE TGs. Egress TG: A Call Flow Partner Peer PARTNER TG on the SBC TG on the SBC peer Root Cause: The following configuration must be enabled: Ingress TG: Both SIPCORE TGs. Egress TG: The issue is noticed for the following call flow: Call Flow Partner Peer PARTNER TG on the SBC TG on the SBC peer Steps to Replicate: The issue can be replicated by configuring the following: Ingress TG: Both SIPCORE TGs. Egress TG: The issue is noticed for the following call flow: A Call Flow Partner Peer PARTNER TG on the SBC TG on the SBC peer | The code is modified so when the generateOrReplacePCV functionality is enabled, carry forward the data like the original ioi, icid, etc. in the call block. This is used while processing 18x/200 OK and appropriately adds Term-IOI if configured and when sendPCVHeader is enabled. Workaround: Enable sendPCVHeader on both trunk groups. |
SBX-117119 | SBX-117955 | 2 | PortFix SBX-117119: The removeSavedConfig does not delete a saved config file unless 'show table system savedConfigList' is called beforehand. Impact: The removeSavedConfig does not delete a saved config file unless 'show table system savedConfigList' is called beforehand. Root Cause: When savedConfig and removeSavedConfig called one after the other, the internal list did not have the path to delete the file. Steps to Replicate:
| The code is modified to update the internal list with path and file name. Workaround: Before calling the removeSavedConfig, call the "show table system savedConfigList" |
SBX-115853 | SBX-117894 | 2 | PortFix SBX-115853: The SBC sent an UPDATE with payload (128 101) that caused calling party to fail the call. Impact: This is a SIP-GW1-GW2-SIP call. The issue is GW1 sends an UPDATE to client for codec G.729 but Payload Type as 128. Root Cause: UPDATE is sent by GW1 to ingress because at ingress, there was Tone and Announcement profile configured and playing the Tone triggered by an UPDATE. An UPDATE was sent to client with G729 as G729 was the first codec offered by Server in it's UPDATE message, as the Honor Remote Precedence flag was enabled in Ingress GW's PSP. The G729 PT is updated with wrong value of 128 instead of 18 in the NRMA code. The selected codec's rx PT was assigned with tx PT that contained invalid PT. Steps to Replicate:
| The code is modified with a valid PT value. Workaround: Set the Honor Remote Precedence flag disabled. |
SBX-101758 | SBX-113551 | 2 | PortFix SBX-101758: There was an issue regarding field Ingress Codec inside the CDR for some calls with CLEARMODE. Impact: The SIPI INVITE call fails when CLEARMODE as CODEC feature is enabled. Root Cause: The call failed as CLEARMODE in the PSP was becoming NULL. Steps to Replicate: Run the CLEARMODE as CODEC enabled and PSP has CLEARMODE as entry. Test steps:
Tests can be done to verify different call flows:
| The code is modified so that when the CLEARMODE as CODEC is enabled and the SIPI with CLEARMODE is received, the call is processed and the CDR gets updated with CLEARMODE (p:71:0). Workaround: Not available. |
SBX-114396 | SBX-117392 | 2 | PortFix SBX-114396: An UPDATE to modify AMR-NB to the AMR-WB failed in cases where a multi active TSBC was involved. Impact: In a multiple T-SBC cluster setup, when receiving a modify offer (ex: with Update/reinvite) to change from a lower codec (AMR-NB) to a heavier codec (AMR-WB), the SBC was reallocating a new DSP to support the heavier codec. This DSP could be from the same T-SBC as the initial offer-answer DSPs (TSBC1), or a different T-SBC (TSBC2). In this case, the new DSP on offer leg was from TSBC2. While processing an answer leg, the SBC incorrectly chose to reuse the existing DSP though it is from the first TSBC1 instead of TSBC2, the node from which the new DSP for the offer leg is allocated. Root Cause: While processing the answer leg, when the SBC chooses to either reuse the previously-active DSP on the call leg, or reallocate a new DSP, the SBC did not check the node IP address of the T-SBC (where the DSP on the offer leg was allocated) against the previously-active DSP on the current answer leg. Steps to Replicate: Set up:
Call flow:
The DSP on offer leg is from TSBC2. | The code is modified so the SBC compares the node IP address of the T-SBC for a newly-allocated DSP on the offer leg with that of the previously-active DSP on the current answer leg. The SBC reuses the latter only if both of the IPs match; otherwise, a new DSP is allocated, and the previous DSP frees up later on. Workaround: Run a single T-SBC in a cluster. |
SBX-117279 | SBX-118218 | 2 | PortFix SBX-117279: The SBC init.d script checkForUpgradeRevert() file parsing is forgiving and can facilitate arbitrary command execution. Impact: One of the scripts on the SBC has a security issue that in a particular scenario can cause potential privilege escalation from sonusadmin to root. Root Cause: Script was running a marker content without input validation and location of marker was not secure. Steps to Replicate: This code block gets executed only when an upgrade from version which has single debian root partition to three partition model. It is not applicable for any 6.0 or later installations. | The code modified to move the marker to a secure location owned by root and input validation is added in script as a added measure. Workaround: No workaround. |
SBX-114194 | SBX-118144 | 2 | PortFix SBX-114194:Observing memory leak in ScmProcess of active S-SBC during precondition update call flow Impact: On the D-SBC, there was a memory leak in the cluster transcoding capability during Update with preconditions call flow. Root Cause: On the D-SBC, the reference to cluster transcoding capability held in the current working PSP context was being lost, hence leading to memory leak. Steps to Replicate: Run an Update with preconditions call flow on a D-SBC setup and monitor the memory on the active S-SBC node. Without the fix, there would be an increase in the memory usage of SCM Process indicating a memory leak. | The code is modified to avoid losing a reference to the current working PSP context cluster transcoding capability memory, by saving it to the pending Ack PSP context and ensuring to free this memory during the offer answer processing. Workaround: None. |
SBX-118108 | SBX-119166 | 2 | PortFix SBX-118108: The SBC is not sending SDP offer in outgoing INVITE with all the codecs that are configured in PSP. Impact: The SBC is not sending out INVITE with all configured codecs (passthru + transcodable) when Audio + Text is received. Root Cause: The issue only occurs when the D-SBC ( S/M/T ) set up receives an INVITE from Ingress peer with Audio and T.140 stream. During offer processing, the SBC was checking the transcode capabilities for both Audio and text stream, causing this issue. Steps to Replicate:
| The code is modified to address the issue. Workaround: None. |
SBX-114693 | SBX-119161 | 2 | Portfix SBX-114693: Need to Update all the Application code to set the V6 loopback address. Impact: The SBC fails to identify an address as loopback address for an IPV6 call Root Cause: New feature that was added in the 10.1 release exposes this issue. Steps to Replicate: Run a NATed call from IPV6 end point. The call must be established successfully and media should flow from EP1 to EP2 through the SBC. | The code is modified so that the SBC identifies the loopback address for an IPV6 call correctly. Workaround: None. |
SBX-117842 | SBX-119173 | 2 | PortFix SBX-117842: Number Translation criteria was not appearing after importing the file that contains number translation criteria. Impact: Number Translation criteria was not appearing after importing the file that contains number translation criteria. Root Cause: This issue is caused by a feature code check-in, in the SBC release 9.2.3. Steps to Replicate:
Expected Results: The number translation criteria should appear after the import. Observed Issue: The number translation criteria is not appearing after the import. | The code is removed from all occurrences policy/SBXPIPE/SbxNumberTranslationCriteriaEntity.cpp Workaround: No workaround. |
SBX-115421 | SBX-119159 | 2 | PortFix SBX-115421: Serf Logs and Upgrade marker files are missing from sysDump. Impact: Serf logs and upgrade marker files were missing from sysDump. Root Cause: Capturing only specific log files without * regex. Steps to Replicate: Run sysDump.pl script. | The code is modified to capture all the files including rolled over files. Workaround: No workaround. |
SBX-117972 | SBX-119164 | 2 | PortFix SBX-117972: While expecting BYE, the SBC is sending an INVITE to egress side. Impact: The SBC sending a re-INVITE with text stream disabled when the egress EP sends 200 OK with Audio stream alone. Root Cause: Since, the egress EP sent 200 OK with only audio stream, SBC internally disables the text stream on both call legs that is resulting in triggering of a Re-INV with text stream disabled towards UAS side. Steps to Replicate:
| The code is modified so that if the peer already disables any media stream and if the SBC tries to trigger a re-INVITE towards the peer for disabling the same media stream, then suppress the triggering of the re-INVITE. Workaround: None. |
SBX-116190 | SBX-117072 | 2 | PortFix SBX-116190: Egress congestion handling should only be enabled for the 503 with a retry. Impact: The SBC was treating 503 with or without Retry-After header as a peer overload scenario. But the SBC should only treat 503 responses with retry-after because those are unambiguously overload related. Root Cause: The SBC was not verifying for the presence of Retry-After header to consider it as a peer overload scenario. Steps to Replicate: Send a 503 with Retry-After header for a SIP INVITE. | The code is modified to address the issue. Workaround: None. |
SBX-117985 | SBX-119171 | 2 | Portfix SBX-117985: DSP Reload: Active SBC went down when dsp coredump was issued Impact: Manual DSP coredump initiated via CLI fails to collect core-dump and initiates switchover in case of the SBC 5400. Root Cause: While initiating manual DSP coredump, the DSP should be notified to copy the concerned memories to core-dump section for core-dump collection to happen successfully. Steps to Replicate: * SBC 5400 with at least one DSP card.
| The code is modified to add support for SBC 5400 to notify DSP in case of manual DSP core-dump initiated through the CLI. Workaround: None. |
SBX-90704 | SBX-119255 | 2 | PortFix SBX-90704: Ingress octets sent/egress octet rcvd for T.38 calls Impact: When stopping CDRs for T.38 calls, the Ingress octets sent and received values are not correct. Root Cause: For T38 packets, NP calculates incorrect packets when there is no RTP header for the T38 and as a result, some packets may be less than 12 bytes. Steps to Replicate: Stop CDRs for T.38 calls. | The code is modified to address the issue. Workaround: None. |
SBX-118302 | SBX-119717 | 2 | PortFix SBX-118302: MS TEAMS to PSTN call failed when SILK codec is enabled. Impact: An MS TEAMS to PSTN call failed when SILK codec is configured and the lockdown preferred codec IPSP flag is enabled. Root Cause: When the lock down preferred codec IPSP flag is enabled, one of the codec attributes related to the payload type is not copied properly during an auto answer on the egress call leg. As a result, the call is terminated. Steps to Replicate:
| The code is modified to copy the codec payload type value during an auto answer. Workaround: If "Lock Down Preferred Codec" IPSP flag is disabled then the call scenario works fine. |
SBX-116256 | SBX-119162 | 2 | PortFix SBX-116256: Observed a heap-buffer-overflow on address 0x6260000bf802 at pc 0x56063d63cca4 bp 0x7fe633ce2b00 sp 0x7fe633ce2af8. Impact: A heap-buffer-overflow is observed when Option header with too many spaces or tab is received. Root Cause: When too many space are inserted after Option header. Pdullen is calculated wrongly and include all the spaces also so while doing pre parsing pdulen reaches beyond PDU and leads to coredump. Steps to Replicate: Send option Message with large no spaces or tab such as: | The code is modified to change the startIndex so that it points to Offset Length that is equivalent to the Header length. Now while calculating the PDU length, it is taken from Offset. With these changes, all spaces are taken into consideration and the length is correct. Workaround: None. |
SBX-116942 | SBX-117481 | 2 | PortFix SBX-116942: D-SBC (M-SBC) - The XRM/NP CPUs are also being used by a system task causing slowness in media tasks. Impact: In the SWe, a few sbxPerf processes (example: top2) run on the media cgroup causing congestion issues. Root Cause: Segregation of media and non-media processes at initialization time may fail, leading to non-media processes landing on a VCPUS that is meant for media processing. Steps to Replicate: Install a fix build in the SWe and check whether the sbxPerf process (example: top2, atop) runs on the core0. | The code is modified to move the sbxPerf processes to the system cgroup. The segregation of processes is fixed as part of a separate issue. Workaround: Reboot the SBC. |
SBX-112980 | SBX-115053 | 2 | PortFix SBX-112980: The SBC interworks the extra precondition UPDATE towards the Egress. Impact: The downstream forking and preconditions interwork using an UPDATE method are enabled. When multiple 18x with a precondition are received by the SBC, the SBC sends an UPDATE request to complete the preconditions. The SBC sends an additional precondition UPDATE towards the egress, even though the preconditions are already completed. Root Cause: There was an issue in the code when an UPDATE request is triggered a second time without checking whether preconditions are met already. Steps to Replicate: Run the call flow per the customer's setup. | The code is modified to suppress the additional precondition UPDATE request, if preconditions are already met. Workaround: None. |
SBX-117803 | SBX-118808 | 2 | PortFix SBX-117803: MOH call failure for non core stream Impact: Media On Hold (MOH) Call is failing for non core stream when NAT is enabled. Root Cause: Call is failing because of frequent deactivation and reactivation of resources for a non core stream at the time of NAT relearning causing resources to go into asynchronous error Steps to Replicate:
| The code is modified for non core stream in a NAT call so that deactivation and reactivation of resources does not take place. Workaround:
|
SBX-114293 | SBX-118237 | 2 | PortFix SBX-114293: The S-SBC is unable to clear a call when there are multiple codec changes with RE-INVITES in call. Impact: On the D-SBC, a two DSP transcode call involving multiple re-INVITEs has a hung private respone and a call termination takes more time than expected. For example: a call hold/off-hold with a codec change from narrowband to wideband and vice versa. Root Cause: On the T-SBC, for every DSP, two XRESs are allocated during a re-Invite: a public and a private XRES. Steps to Replicate:
| The code is modified to address a two DSP transcode call. The private XRES(s) is freed appropriately and the call is terminated smoothly when a BYE message is received from the endpoint. Workaround: None. |
SBX-118283 | SBX-119248 | 2 | Portfix SBX-118283: Azure : Observed Availability set gets created when parameter "create_availability_set_for_sbcs" =false Impact: Availability Set being created when associated flags are set to "false". Root Cause: Incomplete Azure terraform scripts allowing Availability Sets to be created. Steps to Replicate: Re-run terraform in the SBC HFE 2.2 setup to ensure Availability Set being created or not created as per the setting of the appropriate flags. | The code is modified to add new Availability Set modules in terraform to support creating or not creating them correctly based on the Availability Set flags. Workaround: None. |
SBX-117097 | SBX-118565 | 2 | PortFix SBX-117097: A DTLS SRTP call fails after the remote peer modifies the session - the SBC fails to process the incoming DTLS Client Hello. Impact: The DTLS SRTP call fails after remote peer modified session. Root Cause: The DTLS SRTP task maintains two contexts, one for client and one for server. They are being passed in when the SBC initiates/re-initiates the session. In this case, the SBC was initiating server session. But in DTLS SRTP session reinitiate function, we passed in client context instead that caused call failure. Also when reinitiating the session, the remote RTP address was not saved in CCB. Steps to Replicate: The steps cannot be reproduced. | The code is modified to:
Workaround: None. |
SBX-117911 | SBX-119163 | 2 | PortFix SBX-117911: A call between Cisco EP and PSTN failed as the SBC is sending incorrect attribute value for Video port 0. Impact: The SBC sends a=sendrecv instead of a=inactive when video stream is received with port 0. Root Cause: When changes were made to support additional video parameters in 9.2.x release, the datapath mode WSA set to default(a=sendrecv) when video stream was marked as absent. This was causing the SBC to send a=sendrecv. Steps to Replicate:
| The code is modified to inactive when video stream is marked as absent when port 0 is received. Workaround: None. |
SBX-118662 | SBX-119256 | 2 | PortFix SBX-118662: The LSWU failed due to Action Command Timeout Impact: The LSWU failed from V10.01.01R3 to V10.01.02A3 This command will start a live software upgrade. Do you want to proceed [no,yes] yes Root Cause: The issue is with media codec related packet size validations in appPreChecks during the LSWU was taking longer time. Steps to Replicate: Run the following command: % request system serverAdmin GARNET startSoftwareUpgrade package <sbc package name> | The code is modified to address the issue. Workaround: None. |
SBX-117235 | SBX-119165 | 2 | PortFix SBX-117235: An additional UPDATE is being triggered by the SBC when the server side sends 18x with Valid Video Port. Impact: In a delayed tone play scenario, the SBC is sending an additional UPDATE when egress EP sends 18x with valid audio and video ports Root Cause: The SBC completed an initial offer-answer in INV and 18x with valid Audio and Video ports. Later, due to delayed tone play logic, the SBC started playing the tone. As part of this tone play activation, the SBC is trying to switch OFF the video stream by triggering an UPDATE with video port as zero. The 200 OK (for UPDATE) is causing the SBC to abort the tone which is not supposed to happen. Steps to Replicate:
| The code is modified so that the SBC does not stop the tone play upon receiving a 200 OK (for UPDATE) response from the ingress EP. Workaround: None. |
SBX-116974 | SBX-118100 | 2 | PortFix SBX-116974: S-SBC is unable to send the 200 OK for 2nd re-INVITE during the 4:1 redundancy with 2 RGs Impact: S-SBC is not sending 200 O.K for RE-INVITE in 4:1 redundancy setup leading to call time-out from remote peer and subsequent call failure. Root Cause: S-SBC is not able to locate the remoteGCID for the call in the DFE module. Steps to Replicate:
| The code is modified so that the DFE module of the S-SBC retains the RemoteGCID unless the call is not unstable. Prior to the fix, the Remote GCID was internally deleted by DFE in the DFE Sync message Workaround: None. |
SBX-118155 | SBX-118260 | 2 | PortFix SBX-118155: The S-SBC is unable to send the UPDATE towards the UAS endpoint for 183 dialog-3 during EGRESS precondition interworking scenario. Impact: The S-SBC is unable to send the UPDATE towards the UAS endpoint for 183 dialog-3. Root Cause: When ingress was not supporting UPDATE, the SBC was trying to send out and stuck in this state. Steps to Replicate:
| The code is modified to locally answer the UPDATE when ingress peer does not allow UPDATE Workaround: None |
SBX-113553 | SBX-117835 | 2 | Portfix SBX-113553: Interworking between a 100 REL compliant UAS and a non 100 REL UAC. Impact: Interworking between a 100 REL compliant UAS and a non 100 REL UAC Root Cause: The UAC is not 100 REL compliant and the SBC cannot forward the UPDATE to the UAC. It fakes a local answer 200 OK for this UPDATE with all the supported codecs of the UAC. This makes the SBC pick a pass through codec which is different from the codec already communicated to the UAC. An audio issue results until the call gets connected. Steps to Replicate:
| The code is modified so that the SBC fakes the local answer 200 OK (for UPDATE here) with the last negotiated codec which is already communicated to the peer. The codec selection remains the same even after the offer-answer completion during an UPDATE-200 OK handshake and there will not be any audio mismatch. Workaround: None. |
SBX-116062 | SBX-119513 | 2 | PortFix SBX-116062: SIPREC - Recorded streams cannot be decrypted successfully after call hold/unhold when the SIPREC server prefers a different SRTP crypto suite than the SBC Impact: With SRTP is enabled for SIPREC: in the scenario mentioned below, SRTP Keys towards SIPREC Servers is corrupted and SIPREC server fails to decrypt the recorded audio stream.
Root Cause: When the SBC receives the answer from SIPREC server with the crypto suite other than the first preference from the offer, the SBC Recorder control block would be updated with the key as received in the answer. However, the crypto suite continued to reflect the offer's top most crypto, thus resulting in corrupted key in further offers towards SRS. Steps to Replicate:
| The code is modified so that when the SBC receives an answer with crypto suite other than 1st preference form the offer, it updates the negotiated crypto in the control block. Workaround: None. |
SBX-118329 | SBX-119174 | 2 | PortFix SBX-118329: A call between CUCM EP and PSTN failed as the SBC is adding additional codecs that are not configured during 18x LRBT play. Impact: The SBC sending all codecs received in the initial INVITE, in the 18x LRBT play. Root Cause: The root cause for this issue is, when TFT and Audio Transparency is enabled, the SBC uses the codec in NSD, during tone play rather from PSP. As part of multi-audio and other bug fixes, the NSD generation for tone Play changed, which is causing this issue. Steps to Replicate:
| The code is modified so when the TFT and Audio Transparency is enabled, the SBC uses the older way to generate the codecs. Workaround: None. |
SBX-116123 | SBX-119176 | 2 | PortFix SBX-116123: The value set against GPU flag in /opt/sonus/conf/swe/capacityEstimates/.activeCallMixInput.json file is not an integer value" error message in DBG Impact: On Managed N:1 MRFP node, when a custom CPU profile is applied, from OAM, by specifying the value against the useGPUForTranscoding field to false, following critical level message is logged in the .DBG file: Root Cause: On N:1 Managed MRFP node, the CDB gives the value against the filed useGPUForTranscoding as False(string), rather than 0(integer). Steps to Replicate: For reproducing the issue on Managed N:1 MRFP, activate a traffic profile with useGPUForTranscoding value set to false, from the OAM, as shown below: | The code is modified to address the issue. Workaround: None. Note: The log does not indicate an error in the functionality of profile activation. |
SBX-116698 | SBX-117509 | 2 | PortFix SBX-116698: The SBC is sending out an Error-Info header in a 400 Bad Request even when the suppressErrorInfoHdr flag is enabled. Impact: The SBC is sending out an Error-Info header in a 400 Bad Request even when the suppressErrorInfoHdr flag is enabled. Root Cause: After the SBC restarts, the suppressErrorInfoHdr flag value is not updated correctly. Steps to Replicate:
| The suppressErrorInfoHdr Flag value is updated properly after a restart. Workaround: None. |
SBX-119428 | SBX-120390 | 2 | PortFix SBX-119428: Frame Lost indication not set for AMRNB. Impact: The frame lost flag is not being set based on talkState for AMRNB decoder. Root Cause: When there is no frame to be fed to the AMRNB decoder, an indication of either 'frame loss' or 'no data' should be provided to the decoder. This indication should be determined based on the decoder's talk state. Currently, the 'no data' indication is set even if there is a frame loss, which is incorrect. Steps to Replicate:
| The code is modified to allow the frame loss flag to be set based on the decoder's talk state. Workaround: None. |
SBX-120625 | SBX-120667 | 2 | PortFix SBX-120625: SRTP one-way audio - SBC not resetting SRTP encryption ROC to zero when ssrcRandomizeForSrtp is enabled Impact: One-way audio on SRTP calls; the far end is unable to decrypt SRTP packets due to ROC mismatch. Root Cause: Once the SBC received re-INVITE on the egress call leg, BRM issued RID modify command to NP on ingress call leg to update SSRC in RID. In the RID modify command, the clear last SSRC flag was not initialized properly which caused NP NOT to clear the ROC. Steps to Replicate: ssrcRandomizeForSRTP Enabled/ passthru:
ssrcRandomizeForSRTP Enabled/ transcode:
ssrcRandomizeForSRTP disabled/ passthru:
ssrcRandomizeForSRTP disabled/ transcode:
| The code is modified so that the NP RID enable and modify interface functions ignore the clear last SSRC flag - keeping ROC reset in sync with clear last SSRC. Workaround: Disable ssrcRandomizeForSRTP. |
SBX-119426 | SBX-120591 | 2 | PortFix SBX-11942: Frame Lost indicator not set for AMRWB & V 1.4 Library Upgrade Impact:
Root Cause:
Steps to Replicate:
| The code is modified so that the frame loss flag is set based on the decoder's talk state. As well, the divide by zero issue is addressed in the AMRWB library upgrade. Workaround: None. |
The following issue is resolved in this release:
Issue ID | Sev | Problem Description | Resolution |
---|---|---|---|
SBX-120264 | 1 | The SCM Process continually cores on two SBC 7000s - possibly PCV IOI related. Impact: The SCM Process coredumped due to NULL pointer access for a (GSX) ISUP-GW-GW-SIP call after enabling Generate or Replace PCV feature. Root Cause: The code was trying to read a CPC parameter from the ingress side of the call and the parameter is NULL when the ingress side is ISUP. Steps to Replicate:
Expected result: The SCM Process cores. | The code is modified to ensure the CPC parameter is not NULL before accessing it. Workaround: Disable Signaling > Generate or Replace PCV and apply the fix. |
SBX-120128 | 1 | SBC 5400 switchovers occur after an upgrade to v09.02.04R003. Impact: The SCM process may core while attempting to set the original peer SDP address when either NAPT for Media is enabled and the SDP is received, or if ICE is enabled and ICE is in the SDP. Root Cause: In the above two scenarios, the software did not protect against using a NULL packet SG control block address. Steps to Replicate: The steps are not reproducible. | The code is modified to prevent the NULL packet SG control block address from causing the SCM process to coredump. Workaround: None. |
SBX-118999 | SBX-119774 | 1 | PortFix SBX-118999: After an SBC 9.2.3 SW upgrade, the ACLs are blocking traffic when enabled. Impact: The IPACL rule is incorrectly installed in the NP. Root Cause: You can configure the IPACL rules with or without an ipInterface. If an IPACL rule is configured with an ipInterface, it is not installed in the NP until the associated ipInterface is created and enabled in the NP. The IPACL task tries to re-add those rules that are waiting on the ipInterface for it to receive a 'port up' notification from the NRS. When mixing a set of IPACL rules, some rules that are not defined with the ipInterface are installed in the NP during the startup of the applications, while other rules that are defined with the ipInterface may get delayed while waiting for the associated ipInterfaces to become ready. All of the IPACL rules are ordered by precedence in the CPS context and will be programed in the NP in the same order. When the IPACL task tries to re-add the rules that are waiting on ipInterface, the order of the rules is changed. The new rules are inserted at the proper location in the CPS context, based on their precedence. But there is no corresponding shuffling at the NP layer which causes some newly-added rules to randomly overwrite some existing rules. Steps to Replicate:
This should result in rule 3 showing match counts instead of rule 2. | The code is modified to add all the rules in the NP, including the ones already added on the IPACL retry. Workaround: None. |
SBX-118335 | SBX-118880 | 2 | PortFix SBX-118335: SBC 5400 redundancy switchover: "NP 0 error counter macError" messages received, mgt0 static route missing, and rx_errors are increasing Impact: Customer upgraded the SBC 5400 from 7.2.x to 9.2.3R4 and the management ports went from 100Mbps to 1Gbps due to feature located in the SBC 8.0.0 release. On some occasions, the management port become inaccessible and CRC errors are reported in the port statistics [ethtool -S mgt0]. Root Cause: The problem is specific to the SBC 5400. When the NRS (Network Resource Service) thread issues an interface stop, followed immediately by an interface start request for all management (mgt) ports, resulting in the following behavior:
However, if the rx/tx are stopped and started in a short time (< 10 milliseconds), the remote link ignores the notification and does not renegotiate the clock/speed/duplex. This leads to the data becoming out of sync with the remote end, which causes CRC errors on the packets received. Steps to Replicate: Run the sbxrestart multiple times. When the SBC application is running, issue "ethtool -S mgt0" and ensure rx_crc_errors is still 0. | The code is modified to power down the PHY to a low power state when the port stop request is received. Thus, when the port start request is issued, the PHY is powered up to a normal power state. This forces the remote end to detect a link down and then a link up. Workaround: If rx_crc_errors is increasing, disable and enable the mgt port. Use the following Linux commands: ifconfig mgt0 down ifconfig mgt0 up (Replace mgt0 with the mgt port name where rx_crc_errors is increasing.) |
SBX-117475 | SBX-119270 | 1 | PortFix SBX-117475: Event log type SYS is filling up in less than 3 hours with SYS errors. Impact: Event log type SYS is filling up in less than 3 hours with SYS errors Root Cause: The root cause cannot be found. Steps to Replicate: Run the call as it is and check if a MAJOR level log is getting printed instead of SYS errors. | The code is modified so the SYS errors add the Max number of association as a MAJOR level Debug log in ccCallGroupMgr.c and an EventNotify in ccHndl.c to track the call that is causing the issue. Workaround: Add the maximum number of association as a MAJOR level Debug log in ccCallGroupMgr.c and an EventNotify in ccHndl.c . |
Severity 1 Resolved Issues
The following Severity 1 issues are resolved in this release:
Issue ID | Sev | Problem Description | Resolution |
---|---|---|---|
SBX-116340 | 1 | Customer reported DNS failures on 3 different occasions and it appears to be related to "time to live" and negative cache functionality. Impact: DNS records (requests) can become stuck in RESOLVING state within the Agent, which causes the FQDN to become unreachable forever. Root Cause: A DNS request (or it's response), sent between the Agent (e.g., ScmProcess) and the Client (DNS Process), becomes lost. This causes the DNS record to become stuck in RESOLVING state, and the FQDN to become unreachable. Steps to Replicate: The steps cannot be reproduced. | The code is modified so the DNS record defaults to 60 seconds when the DNS request is sent by the Agent to Client. In the error case, delete the DNS record when the timer expires in order to recover. In the working case, Workaround: The workaround is to manually clear the DNS cache or manually query the "stuck" FQDN. |
SBX-117393 | 1 | An SCM Process coredumps and causes a switchover. Impact: SCM Process cores when attempting to allocate memory. Root Cause: An SCM Process cores when attempting to allocate memory because the memory management code detects memory corruption. Steps to Replicate: The root cause is found by code inspection and can note be reproduced. | The code is modified to prevent writing into the memory block after it is freed. Workaround: None |
SBX-119106 | 1 | The SBC application restarts. Impact: A SAM process encounters a core due to a Healthcheck timeout when the SIPCM attempts to open a TLS connection. The security certificate named in the tlsProfile is expired. Root Cause: Two threads are hung while attempting to write a security certificate update () to the DB using the same socket. The purpose of the update is to change the state of the certificate to EXPIRED. Steps to Replicate:
| The code is modified to add a lock preventing two threads from writing to the DB using the same socket. Workaround: Renew PKI Security Certificates before they expire. |
SBX-119111 | 1 | The SBC encountered a coredump and switched over when processing a transferred call. Impact: The SCM cores in the SIP code processing a SIP REFER message. Root Cause: The SCM process cored when attempting to dereference a NULL pointer after processing a message related to the SIP refer/relay. Steps to Replicate: The root cause is found by code inspection and the steps cannot be reproduced. | The code is modified to ensure that the pointer is valid before attempting to dereference it. Workaround: Disable the SIP Refer Relay. |
SBX-118822 | 1 | The HA SBC fails to start on version 09.02.04R001 when the Direct IO Passthrough is used. Impact: The SBC application fails to start on a 44 vCPU instance. Root Cause: The maximum number of vCPUs supported is set to 40 in the SM module. This leads to corruption and a subsequent core-dump on instances with a size greater than 40 vCPUs. Steps to Replicate:
| The code is modified and now set to be in sync with other modules. Workaround: None |
SBX-118473 | 1 | The SBC resets SRTP encryption sequence number after a re-INVITE; the anti-replay protection at the far end (on another SBC) discards the incoming SRTP packets until the sequence number approaches the highest recorded sequence number. Impact: Intermittent one-way audio with a duration of more than 10 seconds may occur during call transfers when the remote connection media IP address changed on the secure RTP (SRTP) call leg. The RTP sequence number (SSN) of the outgoing SRTP stream encrypted by the SBC may roll back to a lower value that causes the SRTP packets being discarded by SRTP anti-replay protection at the receiver's end. Once the SSN of the SRTP stream reached the highest recorded value, the audio was back and both parties could hear each other. Root Cause: After the call transfer, the remote connection media IP address on the SRTP call leg was modified without deactivating the media resource chain. This caused the delay in applying the security configuration to the media resource chain, which in turn caused the first one of several SRTP packets being sent with a high SSN number and the roll back of the SSN to a lower value. The remote end discarded the SRTP packets with a lower SSN than the highest recorded SSN. Steps to Replicate:
| The code is modified so in a modify offer or answer for a SRTP call, if the remote connection media IP address is modified on the SRTP call leg, the new IP and security configuration are applied at the same time, without a delay. Workaround: None. |
Severity 2-4 Resolved Issues
The following Severity 2-4 issues are resolved in this release:
Issue ID | Sev | Problem Description | Resolution |
---|---|---|---|
SBX-117506 | 2 | The SCM Process was leaking a resource related to a NRMA sessPtr. Impact: The SCM process may leak memory in some early call failure scenarios. Root Cause: In early call failure scenarios, a different function is called to free the Call Block (and the memory linked off of it) than the function that frees the Call Block in successful call scenario. The function that is called in some early call failure scenario was not freeing all of the memory that had been allocated for the call. Steps to Replicate: The steps cannot be reproduced. | The code is modified so that all the memory that is allocated for a call is freed in all early call failure scenarios. Workaround: None. |
SBX-117901 | SBX-119275 | 3 | PortFix SBX-117901: Log is incorrect when using regex to filter value to be stored. Impact: After storing an SMM rule for a value to a variable, the wrong value is being logged. Root Cause: Logging the wrong data. Steps to Replicate: Configure the SMM rule to store a value to a variable and look for the debug log message: | The code is modified so the data log is stored to a variable correctly. Workaround: Ignore the logging message. |
SBX-119288 | 2 | PortFix SBX-117546: The SBC is adding phone-context=private for a globalized number in the RURI and To Header. Impact: The SBC adds phone-context=private in the RURI for a globalized number when it is modified using a DM rule. Root Cause: Using a DM rule to add '+' in called number does not result in number being treated as globalized. Steps to Replicate: Configure the DM rule to add a '+' sign. Run SIP-SIP call. The SBC sends a INVITE with globalization in RURI and has phone-context=private. | Do not add phone-context=private in the RURI when the RURI is already in globalized format, including when the userpart of globalization number has a '+' sign. Workaround: Disable DM rule or use SMM to delete the phone-context parameter. |
SBX-119224 | 2 | Microsoft Azure reserves port 65330. Impact: Some DNS queries fail to get a response in an Azure deployment. Root Cause: Microsoft does not allow VMs to use port 65330. The DNS queries are sent using this local port and are dropped. Steps to Replicate: Run DNS queries for a long period of time and check that port 65330 is not used. | The code is modified to mark port 65330 as reserved. Workaround: The Linux configuration can be manually updated to reserve the port.
|
SBX-119054 | SBX-116942 | 2 | PortFix SBX-116942: D-SBX (M-SBX) - The XRM/NP CPUs are also being used by a system task causing slowness in media tasks. Impact: In the SWe, a few sbxPerf processes (example: top2) run on the media cgroup causing congestion issues. Root Cause: Segregation of media and non-media processes at initialization time may fail, leading to non-media processes landing on a VCPUS that is meant for media processing. Steps to Replicate: Install a fix build in the SWe and check whether the sbxPerf process (example: top2, atop) runs on the core0. | The code is modified to move the sbxPerf processes to the system cgroup. The segregation of processes is fixed as part of a separate issue. Workaround: Reboot the SBC. |
SBX-119157 | SBX-118353 | 3 | PortFix SBX-118353: An inccorrect DSP insertion/rejection reason can be seen recorded in the ACT record in the case of an incomplete offer/answer. Impact: An inccorrect DSP insertion/rejection reason is the result of an incomplete offer/answer. Root Cause: Example:
In the problem scenario where the T.38 is enabled as transcodable codec during an initial offer/answer, the SBC is not able to find the heaviest transcodable codec. The setting for the dspRejectionReason is "Rejected codec unlicensed". Steps to Replicate:
| The code is modified to update the dspRejectionReason to "Rejected codec unlicensed" for only the cases where the license is unavailable . Workaround: None |
SBX-119048 | SBX-118180 | 3 | PortFix SBX-118180: A duplicate MIME-Version header is added on a SIP over Core call. Impact: A duplicate MIME-version header is added by the SBC when an incoming INVITE already has the MIIME-version header. Root Cause: When the SBC encounters MIME content it adds the MIME-version by default. When an unknown header transparency is enabled at the egress IPSP and the incoming message has a MIME version header, it is transparently passed to the egress. This results in A duplicate MIME-version header at the egress side. Steps to Replicate:
| The code is modified to check for the MIME content and the MIME-version header. If there is an unknown header transparency then it isn't added it to message. Only the MIME-version will be added by the SBC. Workaround: None |
SBX-119052 | SBX-117799 | 2 | PortFix SBX-117799: The SBC fails to recognize the Prack in a multi-dialog (different TO tags) if an 18X and 200(Inv) are received simultaneously. Impact: For a dialog transparency and forked call, the SBC may reject the Prack request due to race condition of back to back 18x and 200 OK messages. Root Cause: After receiving a 200 OK message, the SBC finalizes the active remote tag and queues up the send packet to the ingress due to a pending Prack. When the Prack is received, the SBC rejects it because the compare for the Prack comes from a different remote tag than the one already stored in the 200 OK message. Steps to Replicate:
| The code is modified to validate the remote tag based on the forking list not the final one. Workaround: Disable the Prack. |
SBX-118989 | SBX-118764 | 2 | PortFix SBX-118764: Cac calls are rejected with a 503 Service Unavailable message, instead of a 403. Impact: Cac calls are rejected with a 503 Service Unavailable message instead of a 403. Root Cause: The Sip Call Status is always overwritten with a 503 message. Steps to Replicate:
| The code is modified so that the Sip Call Status has the correct error code. Workaround: None |
The following severity 1 issues are resolved in this release:
Issue ID | Sev | Problem Description | Resolution |
---|---|---|---|
SBX-118635 | SBX-118705 | 1 | PortFix SBX-118635: Observed the IpSockAddr (0.0.0.0) and Port (0) for Egress leg in GW1 and Ingress leg in GW2 for GW-GW HPC call scenario. Impact: The IpSockAddr and Port fields are 0 in the global callDetailStatus status command in a GW-GW HPC call scenario. Root Cause: In 9.2.4R001, the code is added to not send CPC_OP structures unknown to the GW-GW encoder layer over the GW-GW link to reduce the size of the GW-GW message sent to older SBCs and the GSX. However, it was found that at least one of these unknown CPC_OP Structures, CPC_OP_SIP_ZONE_AC_NAME_STR was used to transfer information used in the global callDetailStatus status command. Steps to Replicate:
| The code is modified to send the CPC_OP structures unknown to the GW-GW encoder layer over the GW-GW link. Workaround: None. |
SBX-118367 | 1 | Missing CDR sub fields from Column: Ingress Protocol Variant Specific Data. Impact: Missing CDR sub fields from Column: Ingress Protocol Variant Specific Data. Root Cause: The CDR fields were not updated in SipSgFillProtocolSpecData function from where CDR was getting populated. Steps to Replicate:
| Updated SipSgFillProtocolSpecData function with the CDR field that were missing to address the issue. Workaround: None. |
SBX-115911 | 1 | Application restarted due to a processAbnormalTermination. Impact: The SSReq process coredumped while receiving a message with length = 0. Root Cause: While inputting message length =0, a third-party software Xalan crashes at allocating memory. Steps to Replicate: Perform a SSReq request to the ERE when configured for the external PSX. | The code is modified to not process messages with length = 0. Workaround: Stop the SSReq process. |
SBX-114415 | SBX-118369 | 1 | PortFix SBX-114415: The SBC 7000 standby CE stopped functioning with file corruption and "read only" mode. Impact: When the file system turned to Read Only mode the server did not go for reboot. Root Cause: The SBC became stuck during the read only file system checking but the root cause cannot be determined. Steps to Replicate: The steps cannot be reproduced. | The code is modified to use different commands to check for read only status to try and ensure the SBC automatically reboots to recover. Workaround: An operator needs to manually reboot the SBC in order to recover it. |
SBX-115304 | SBX-118372 | 1 | PortFix SBX-115304: The SBC replies with a 481 message for INVITE with occasional replaces. Impact: The SBC replies a 481 message for INVITE with occasional replaces. Root Cause: In early dialogue, the state to-tag is not updated in the Hashtable but the from-tag is updated. This issue is why when we tried to look up using only the call ID. As a result, it fails to fetch original call as the original INVITE and the INVITE with replaces had the same call ID. Steps to Replicate:
| The code is modified to look up both the call ID and from-tag for the ingress leg. Workaround: None. |
SBX-118425 | 1 | The SBC as a TLS server fails a TLS handshake attempt if an ECDHE cipher is used and the TLS client specifies an elliptic curve other than secp256r1 (prime256v1). Impact: The SBC as a TLS server fails a TLS handshake attempt if an ECDHE cipher is used and the TLS client specifies an elliptic curve name other than secp256r1 (prime256v1). Root Cause: The SBC uses the default elliptic curve name secp256r1 (prime256v1) when acting as a TLS server. Steps to Replicate: Use an "openssl s_client" to trigger TLS handshake with ECDHE ciphers with curve names secp384r1 and secp521r1.
The packet capture will show Server Hello after SBC TLS server selects the matching cipher suite and curve name. | The code is modified so the SBC TLS server selects the Elliptic curve name automatically. Workaround: Do not specify curve name, or use curve name prime256v1 (openssl 1.0's default on TLS server) when using a tls_ecdhe* cipher suite. |
SBX-118731 | 1 | A PES Process core occurred while configuring the npaNxx. Impact: A PES Process coredump could occur while bulk provisioning npaNxx, LocalCallingArea or Tollfree table using API. Root Cause: Postgres tried to clear memory of a NULL pointer. Steps to Replicate: Bulk provision the system using API. | The code is modified to not attempt to call PGclear() with a NULL pointer. Workaround: None. |
SBX-117637 | 1 | The ScmProcess generates a core and a switchover occurs due to null pointer in a forked call. Impact: The SCM is coring when trying to free memory that has already been freed. Root Cause: The Scm process cores when trying to free memory because of a non-reproducible edge case scenario which causes the memory to be freed before returning from a subroutine. The calling function doesn't handle this correctly. NOTE: This scenario only happens if a downstreamForkingSupport is enabled on the SIP Trunk Group. Steps to Replicate: The steps cannot be reproduced. | The code is modified to prevent the scenario. Workaround: None. |
SBX-119425 | SBX-118777 | 1 | Portfix SBX-118473: SRTP one-way audio. SBC resets Impact: TBD Root Cause: TBD Steps to Replicate: TBD | Workaround: |
The following severity 2-3 issues are resolved in this release:
Issue ID | Sev | Problem Description | Resolution |
---|---|---|---|
SBX-117319 | SBX-118777 | 3 | Portfix SBX-117319: IMS AKA issues. Impact: When the egress request is timed out, the SBC timeout handling failed when IMS AKA security is enabled. Due to this issue, the SBC is unable to release the call immediately. Root Cause: When IMS AKA security is enabled, once the egress request is timed out, some parameters are not set in internally generated timeout message. Due this issue, the SIPSTACK layer ignored the timeout message. Steps to Replicate:
The request is timed out and the call should clear immediately. | The code is modified to set the required IMS AKA security params for timeout message. Workaround: None. |
SBX-117097 | 2 | A DTLS SRTP call fails after the remote peer modifies the session - the SBC fails to process the incoming DTLS Client Hello. Impact: The DTLS SRTP call fails after remote peer modified session. Root Cause: The DTLS SRTP task maintains two contexts, one for client and one for server. They are being passed in when the SBC initiates/re-initiates the session. In this case, the SBC was initiating server session. But in DTLS SRTP session reinitiate function, we passed in client context instead that caused call failure. Also when reinitiating the session, the remote RTP address was not saved in CCB. Steps to Replicate: The steps cannot be reproduced. | The code is modified to:
Workaround: None. |
SBX-117280 | SBX-117653 | 2 | PortFix SBX-117280 to 8.2.5R007: Apache Axis security issues Impact: The following vulnerabilities related to Apache 1.2 were identified with in the Ribbon SBC application: Issue 1: The LI uses unsupported Apache Axis 1.2 (2005) on JBoss 5.1 (2009). Issue 2: The LI exposes the Apache Axis AdminServlet without authentication (default for Axis 1.2). Issue 3: The LI runs as the sonusadmin user, a privileged account. Root Cause: The LI uses unsupported Apache Axis 1.2 (2005), exposes the Apache Axis AdminServlet without authentication and runs as the sonusadmin user, a privileged account. Steps to Replicate:
| The Apache Axis cannot be upgraded to version 1.4 for issue 1 due to the following: The Axis 1.2 has 3 vulnerabilities CVE-2018-8032, CVE-2014-3596 and CVE-2012-5784 and the SBC application is not impacted by any of these. Axis 1.4 has four vulnerabilities (3 from version 1.2 plus 1 new) out of which CVE-2019-0227 (this is the new one in version 1.4) could impact the SBC application. As a result, for issue 1 no fix is required. For issue 2 and 3, the code is modified to remove the AdminService. Workaround: None. |
SBX-115853 | SBX-118829 | 2 | PortFix SBX-115853: The SBC sent an UPDATE with payload (128 101) that caused calling party to fail the call. Impact: This is a SIP-GW1-GW2-SIP call. The issue is GW1 sends an UPDATE to client for codec G.729 but Payload Type as 128. Root Cause: UPDATE is sent by GW1 to ingress because at ingress, there was Tone & Announcement profile configured and playing the Tone triggered by an UPDATE. An UPDATE was sent to client with G729 as G729 was the first codec offered by Server in it's UPDATE message, as the Honor Remote Precedence flag was enabled in Ingress GW's PSP. The G729 PT is updated with wrong value of 128 instead of 18 in the NRMA code. The selected codec's rx PT was assigned with tx PT that contained invalid PT. Steps to Replicate:
| The code is modified with a valid PT value. Workaround: Set the Honor Remote Precedence flag disabled. |
SBX-118373 | 3 | There was an Active SBC 7000 DNS Process core. Impact: The DNS Process on the active CE on a system switchover may coredump. Root Cause: A NULL DNS TCB (transaction control block) was encountered while the Active CE was shutting down (during restart). Steps to Replicate: The steps cannot be reproduced. | The code is modified to guard against using a NULL DNS TCB. Workaround: None. |
SBX-118281 | SBX-118051 | 2 | PortFix SBX-118051: The DTLS client Hello was being ignored. Impact: The SBC may ignore DTLS Client Hello message and cause no audio in STUN/ICE/DTLS calls when the endpoint performs STUN checks for two candidates and the two checks overlap. Root Cause: The SBC is storing remote IP/port in the nominated candidate list, even if BREQ/BREQ_UC messages are already sent. Then when resending the BREQ message, the SBC uses the remote IP/port from the stored nominated candidate array and that is causing confusion. Steps to Replicate: Establish a STUN/ICE/DTLS call and have the endpoint initiate STUN connection checks with two candidates. The STUN checks should overlap in the following manner:
| The code is modified to:
Workaround: None. |
SBX-119050 | SBX-118145 | 3 | PortFix SBX-118145: The "EMA - System Administration - File Upload" does not allow a .pfx certificate file to be uploaded. Impact: The EMA does not support the uploading of a certificate file with a .pfx extension. Root Cause: There is no requirement to allow a file to be uploaded with a .pfx extension, hence the support for the same is not available. Steps to Replicate:
| The code is modified to allow a file with a .pfx extension to be uploaded. Workaround: The file has to be manually copied to the SBC through the SSH. |
The following Severity 1 issues are resolved in this release:
Severity 1 Resolved Issues
Issue ID | Sev | Problem Description | Resolution |
---|---|---|---|
SBX-118118 | 1 | Both of the SBC units went down after an unregister from the EMS. Impact: Both of the SBC units went down after an unregister from the EMS Root Cause: The code in the ENM process notifies the deletion of the SnmpAgent snmpTargetMib snmpTargetAddrTable snmpTargetAddrEntry. The ENM process code spawns a thread to delete the corresponding trap from the oam snmp trapTarget table that shares a CDB socket with the SonusSnmpTrapTarget::ProcSubDelete. Steps to Replicate:
| The SonusSnmpTrapTarget::DeleteTrapTargetThread routine is modified to use its own CDB socket to prevent contention from two threads for the same socket. Workaround: None |
SBX-118076 | SBX-115937 | 1 | PortFix SBX-115937- The SBC switches over due to a deadlock issue. Impact: The CPX process deadlocks when the customer is making several calls to get the authPassword, while calling the CpxTrunkGroupMediaIpSecondaryInterfaceGroupNameValidate to validate the SecondaryInterfaceGroupName. For example: Root Cause:
Steps to Replicate:
| The code is modified to perform a Workaround: Do not call for the authPassword while setting the mediaIpSecondaryInterfaceGroupName. |
SBX-118082 | SBX-118049 | 1 | PortFix SBX-118049 - The SRTP decryption and encryption fail after an upgrade to 9.2.4R0/10.1.0R2. Impact: The SBC fails to decrypt the incoming SRTP packets, causing a static noise instead of audio on the SRTP calls. Root Cause: Since 9.2.0x, one flag is used in the XRM. XRM_SRTP_SESS_UNENCRYPTED is used for both the unencrypted SRTP and unencrypted SRTCP. When this flag is set, the XRM sends cipherType = NP_CIPHER_TYPE_sRTP_NULL to the NP. The SBC does not to decrypt the incoming SRTP packets. Steps to Replicate:
| A new flag is added, for unencrypted SRTCP: XRM_SRTCP_SESS_UNENCRYPTED The modified NRMA and XRM adopt the new flag for SRTCP. Workaround: Disable the UNENCRYPTED_SRTCP in the cryptoSuiteProfile |
SBX-118074 | SBX-115213 | 1 | PortFix SBX-115213 - Node B unexpectedly restarts when Node A is in SyncInProgress for a long time. Impact: The Call/Registration Data on the SBC shows syncInProgress for an extended period of time. Root Cause: A redundancy message buffer is not large enough to hold the data and causes the sync to be incomplete. This results in the Call/Registration Data to remain in a syncInProgress state. Steps to Replicate: Run multiple Registration/Calls on the SBC. | The code is modified to address the issue. Workaround: None |
SBX-118089 | SBX-117435 | 1 | PortFix SBX-117435 - Running a sysdump on the SBC 5400 triggers a packet port down/up condition. Impact: A port link failure occurs while running a sysdump on the SBC 5400. This may cause an SBC switchover. Root Cause:
Steps to Replicate: When the mgt/pkt interfaces are in a link up state in the SBC, run an np_mem_dump.pl. Sample command line to run 100x:
Note: This command creates npMem0_d[1..100].log files and will fill up the disk. | The code is modified to access the Octeon register through the driver instead of directly accessing the register. This avoids a concurrent access of the register. Workaround: Do not run a sysdump or /opt/sonus/bin/np/np_mem_dump.pl while the SBC is running. You can obtain an updated /opt/sonus/bin/np/oct-remote-memory and /opt/sonus/bin/np/oct-remote-csr binary to avoid the link bounce while running a sysdump. |
SBX-113233 | SBX-117578 | 1 | PortFix SBX-113233 - Getting bulk alarms of "sonusSbxNodeResourcesNoPacketsReceivedNotification" Impact: The patch includes additional stats from SWe_NP which can help in triaging false reporting of RTP inactivity issues better. In addition to this, the patch also includes fixes to prevent false reporting of RTP inactivity when policer mode is set to “Bypass” (SBX-110362), and preventing false RTP inactivity reporting in “call hold and unhold scenario” (SBX-112867). Root Cause: Not yet RCAed. Steps to Replicate: Issue was not locally reproducible. | The code is modified to add additional NP stats to help in triaging false reporting of RTP inactivity, and also backported some known false detection fixes (SBX-110362, SBX-112867). Workaround: None. |
SBX-118331 | SBX-119250 | 1 | Portfix SBX-118331 - EMS re-Synchronization feature not working fine with SBC7K Impact: EMS trap resync logic does not work for standard SNMP traps e.g linkUp, linkDown. Root Cause: The EMA was not aware of the mapping from the standard OID traps to trap name and as a result it was unable to resync trap information to EMS. Steps to Replicate:
| The code is modified so that the EMA now understands the OID values for the standard SNMP traps and can resync the info to the EMS. Workaround: None. |
SBX-114533 | SBX-119172 | 1 | Portfix SBX-114533 - CPX not handling the notification correctly from SDR Impact: SNMP traps destinations set by FQDN are not resolved correctly to IP. Root Cause: ConfD CDB API return inconsistent data when reading from CDB_RUNNING. Steps to Replicate:
| The code is modified to ensure that the Management Agent API (MAAPI) is now being used to read the SNMP trap target information instead of the CDB API. Workaround: Restart the SBC. |
SBX-116895 | SBX-118614 | 1 | PortFix SBX-116895 - SBCSWE switchover occurred because of EnmP core Impact: The EnmProcess crashed when an accounting file rolled over. Root Cause: If the fileCount for the accounting files is reduced substantially ( ex. 2048 to 1024), and a rollover occurs, then a shell script is run for each file that needs to be deleted to reduce the file count to the new configured file count. This shell script deletes any hash files in the eventLogValidation directory associated with the deleted accounting file. Steps to Replicate:
| The code is modified to ensure that instead of calling a shell script to delete the hash files, the EvmFileDeleteLogfiles routine gets a list of all the hash files of accounting files in the eventLogValidation, and deletes the associated hash file when an accounting file is deleted. This reduces the time to delete ~2000 files to less than a second. Workaround: Do not reduce that fileCount for the accounting log files more than 300 files at a time. Rollover the accounting file each time the count is reduced. |
The following Severity 2-4 issues are resolved in this release:
Severity 2-4 Resolved Issues
Issue ID | Sev | Problem Description | Resolution |
---|---|---|---|
SBX-118336 | SBX-118119 | 3 | PortFix SBX-118119: Do not send CPC_OP_TYPE_NRMA_SESSION_DESCRIPTION to old GSX/SBC. Impact: A large parameter called CPC_OP_TYPE_NRMA_SESSION_DESCRIPTION is not used on the GSX and not used in any SBC prior to 9.1 and could potentially cause a PDU to be sent over a GW link to be too large. Root Cause: In GW Connection Manager (GWCM), information is obtained for the farend if the oldGsxSupport control flag is enabled and if the CPC_OP_TYPE_BUFFER_SIZE parameter from the peer is present. Steps to Replicate: Send calls over GW-GW link with lots of optional parameters to induce call drops due to buffer overrun. | The code is modified to check if the oldGsxSupport flag is enabled and the ulPeerBuflen is still set to the smaller GSX size, so the CPC_OP_TYPE_NRMA_SESSION_DESCRIPTION parameter is marked as to notsend when desired. Workaround: None. |
SBX-118077 | SBX-116820 | 2 | PortFix SBX-116820: The LDG goes down and triggers ARS - IP ACL. Impact: The XRM debug command failed to dump static discard ACL stats. Root Cause: The existing logic only dumps maximum 100 entries of each allocated ACL list. If a user has more than 100 allocated ACL list in admit TCAM ACL list, then the entry 101 to 200 is dumped for next category of ACL list, and so on. Steps to Replicate:
| The code is modified to:
The change applies to both ACL config and stats. Workaround: configure less than 10 signaling ports. |
SBX-118131 | SBX-117302 | 2 | PortFix SBX-117302: The PRS Process and the SM Process is crashing. Impact: The PRS process was crashing while processing an MRSP message due to the first header line not being present. "MSRP 0100543f85f SEND\r\n" "Caller sent this message.\r\n" Root Cause: The code is always assuming that the header line will be present and is missing some defensive checks, which resulted in the code reading from a null pointer. Steps to Replicate: Send in an MSRP message with the header line missing. | The code is modified to defend against this unexpected scenario and not to coredump. Workaround: None. |
SBX-117900 | 2 | The Azure-SWe SLB Reboot due to SAM process coredump, possibly memory corruption. Impact: This is a SamProcess core caused by memory corruption. Root Cause: This is a memory corruption issue caused by using memcpy to copy data into a buffer that was not large enough. ThE memcpy is in code related to the SIP Load Balancer (SLB) function. Steps to Replicate: The steps cannot be reproduced. | The code is modified to verify the buffer size before doing the memcpy. Workaround: None. |
SBX-118101 | SBX-117736 | 2 | PortFix SBX-117736: A GW message parameter is having sending issues. Impact: Calls that arrive at the SBC with m=text SDP content and are routed to a GSX through a GW-GW can be released with a disconnection reason CPC_DISC_GW_GW_MSG_PDU_TOO_LONG_FOR_PEER(0xD6) due to the GW-GW message being too large for the GSX to handle. Root Cause: The SBC was sending parameters to the GSX that the GSX could not use and this was making the GW-GW PDU message larger than the GSX could process. Steps to Replicate: Make a call with m=audio and m=text in the SDP of the INVITE and try to route over GW-GW to a GSX. Check that the call is successful. The following control should be enabled: | The code is modified to delete certain parameters that are not required on the GSX to reduce the GW-GW PDU size and avoid calls being released when the PDU is too big. Workaround: Use SMM to delete m=text SDP content coming into the SBC that is potentially routed over GW-GW to a GSX. |
SBX-118104 | SBX-115994 | 2 | PortFix SBX-115994: Configuring the last trunk as incoming/outgoing direction wise is causing the SBC to remove DTG info on receipt of 3xx Impact: Configuring last trunk as incoming/outgoing direction wise is causing the SBC to remove DTG info on receipt of 3xx Root Cause: During a TRM lookup for DTG information in TrmProcessIpLookupCmd() in case TRM_IP_LOOKUP_EGRESS_TYPE_DTGNAME_ONLY, the SBC iterates through all the Contact headers and saves DTG information (such as TG name, blocking status and Trunk Type ) in CPC_OP_TRM_IP_TRUNKGROUP_LOOKUP_DATA_STR *entry. The same CPC structure is used in SipSgFillDestTgrpToCpcMsgInfo() to copy DTG information of all TGs in CPC_MSG. This DTG information is then used to route the call where TRM lookup is done through DTG name. But in the TrmProcessIpLookupCmd(), TG blocking status "status" and TRM_IPTG_CB_STR *ipTgCbPtr of last Contact header is used to send TRM reply. Since, the DTG of Last Contact is blocked, the TRM reply fails and causes the DTG to lose information. Steps to Replicate:
| Two new local variables TRM_IPTG_CB_STR *ipTgCbPtrTemp and UCHAR statusTemp are created in caseTRM_IP_LOOKUP_EGRESS_TYPE_DTGNAME_ONLY. After each iteration, when the status is != FOUND_BLOCKING, these new local variables are populated and then used in TrmIpSendLookupRpyNfy() for TRM reply. Then while the loop has to iterate for each contact header, the user must populate CPC_OP_TRM_IP_TRUNKGROUP_LOOKUP_DATA_STR. Because we are passing good values of status and ipTgCbPtr in TrmIpSendLookupRpyNfy(), the TRM reply does not fail. Workaround: None. |
SBX-118075 | SBX-114818 | 2 | PortFix SBX-114818: A 18x/200 Contact header sent by the SBC contains port number different than 5061. Impact: The SBC includes an incorrect port number in the Contact header of the outgoing SIP messages towards registered endpoints when the endpoints use TLS as a transport protocol and a Call Data Channel (CDC; a lawful intercept component) is enabled on the SBC. This behavior results in call failures since the endpoints send SIP requests to unused TCP port numbers. As an example, the SBC includes port numbers 5062, 5063 and other while the configured port number is 5061 (and the SBC listens on that port number). Root Cause: The Lawful Intercept related piece of SW changes the port numbers in the SIG port table that should be configured to the SIG port. Steps to Replicate: To reproduce the problem, create a basic SIP access scenario where an endpoint registers over TLS (REGISTER – 401 – REGISTER – 200). Then, as calea user, provision the following (the assumption is that you already created an IP interface group named LIG with at least 1 IP interface in it): set addressContext default intercept nodeNumber 10001 Once the CDC is configured, register the endpoint. The symptoms of the issue is that SBC includes an incorrect port number (5062, 5063 and similar) in the Contact header of all messages sent to the endpoint. The user does not need to make calls though; the presence of port number 5061 in the event, which is printed after the SBC received the REGISTER with an Auth header is a sufficient proof that the issue is present: 195 03022022 092259.154049:1.01.07.12989.Info .SIPSG: sipsgCallProcCommonUtils.c (-6170) 3777. SipSgSelectTransportAndSigPort: Selected address 10.xxx.yy.zz:5060 for Sig port:1107 AddrType 1 | The code is modified so that the configured SIG port table is not changed. Workaround: This problem happens only when the CDC is configured and a SIP endpoint uses TLS as a transport protocol. If one of the conditions is not met, the problem will not happen. |
SBX-118050 | 2 | The TERM IOI value has not returned in 18x/200 OK to the caller as expected in the IPX PCV header management. Impact: Part of a feature introduced in the SBC Core 9.2.3 release contained these requirements: Customer network
Partner network
Ingress TG: Both SIPCORE TGs. Egress TG: A Call Flow Partner Peer PARTNER TG on the SBC TG on the SBC peer Root Cause: The following configuration must be enabled: Ingress TG: Both SIPCORE TGs. Egress TG: The issue is noticed for the following call flow: Call Flow Partner Peer PARTNER TG on the SBC TG on the SBC peer Steps to Replicate: The issue can be replicated by configuring the following: Ingress TG: Both SIPCORE TGs. Egress TG: The issue is noticed for the following call flow: A Call Flow Partner Peer PARTNER TG on the SBC TG on the SBC peer | The code is modified so when the generateOrReplacePCV functionality is enabled, carry forward the data like the original ioi, icid, etc. in the call block. This is used while processing 18x/200 OK and appropriately adds Term-IOI if configured and when sendPCVHeader is enabled. Workaround: Enable sendPCVHeader on both trunk groups. |
The following Severity 1 issues are resolved in this release:
Severity 1 Resolved Issues
Issue ID | Sev | Problem Description | Resolution | |
---|---|---|---|---|
1 | SBX-116568 | 1 | The SBC is sending 183 with precondition mandating without SDP. Impact: Observed call failures when the SBC sends a precondition option tag in 183 Session Progress message when there is no SDP. Root Cause: During precondition interworking, the SBC attempts to add precondition option tag in Require/Supported header even if there is no SDP in the outgoing 18x response. Steps to Replicate:
| The code is modified to clear the precondition option tag (if any) in Required/Supported header when there is no SDP in 18x. Workaround: Remove the precondition option tag using SMM in the outgoing 18x message if there is no SDP. |
2 | SBX-114048 | SBX-114279 | 1 | PORTFIX SBX-114048: The SBC Reports a service discovery error message. Impact: The SBC reports a service discovery error when the service discovery is not being used. Root Cause: The LCA sends an empty ConfigureBackends request to the SDR, causing an error. Steps to Replicate:
| Skip the configuration process if there is nothing to configure. Workaround: None |
3 | SBX-114771 | SBX-115767 | 1 | Portfix SBX-114771: An SCM process core dump occurs on the server. Impact: An SCM process core dump occurs as a result of a Segmentation Fault. Root Cause: The SIPSG code creates a segmentation fault when sending a 200 OK in response to a REGISTER. The code is attempting to dereference an invalid pointer. Steps to Replicate: Regression testing is all that is necessary. | The code that causes the Segmentation Fault is removed. Workaround: None |
4 | SBX-112149 | SBX-115035 | 1 | Portfix SBX-112149: The Comp_Emap Processes cored on the SBC. Impact: In sensitive mode, an SCM Process core dumps when an Un-Hold UPDATE is received from the UAC during Tone Play. Root Cause: When an Un-HOLD UPDATE code is received from the UAC, the SBC tries to activate end to end resources. There is no answer received from the UAS, causing a core dump. Steps to Replicate:
| The code is modified to check whether an answer is received from the UAS before activating the end to end resources. Workaround: This issue occurs when the SBC is running in sensitive mode. Configure the SBC in normal mode. |
5 | SBX-112091 | SBX-115168 | 1 | Portfix SBX-112091: The SBC is not passing an UPDATE to the Egress. Impact: If the SBC receives two 180 responses with the same SDP (one unreliable and one reliable), then the SBC doesn't send an UPDATE to the Egress. Root Cause: The SBC has received two 180 responses with the same SDP. The first is unreliable and the second is reliable. If the SBC sends out an SDP using the unreliable 180, then the offer/answer state will not get updated upon receipt of the second 180. Steps to Replicate:
| The code is modified to address the issue. Workaround: None |
6 | SBX-114012 | SBX-114298 | 1 | Portfix SBX-114012: The SMM is not working when the From section contains an escape character. Impact: The SMM may fail to parse a display name in a double quote string where the inside may have more than one escape character next to each other in a header. Root Cause: A logical error in parsing that causes a parsing fail. Steps to Replicate:
| The code is modified to address the issue. Workaround: There is no workaround. |
7 | SBX-109056 | SBX-114339 | 1 | Portfix SBX-109056: The SBC 5400 TEAMS CQ is having transfer issues. Impact: When a call with DLRBT enabled undergoes more than one transfer with REFER signaling and the final transferee doesn't accept the call, the SBC does not correctly reconnect the call back to the transferor. Root Cause:
Steps to Replicate:
| The code is modified to address the issue. Workaround: Not available |
8 | SBX-114842 | SBX-115012 | 1 | Portfix SBX-114842: There is a Microsoft Teams Shared Line/Hold issue. Impact: The SBC fails to send an ACK after mix of replace and refer Invites (Microsoft Teams Shared line/hold feature). Root Cause: The SBC fails to release a tone announcement after receiving a 200 OK from the refer Invite. Steps to Replicate: The steps can not be reproduced. | Properly release the tone resource. Workaround: Disable the tone as an announcement. |
9 | SBX-114426 | SBX-115189 | 1 | Portfix SBX-114426: There is a standby SBC coredump CE_2N_Comp_SamP Impact: Memory Corruption may occur in the SAM process if an IP Peer is deleted and then added back into a different zone. Root Cause: The code responsible for adding a new configured IP Peer may write into freed memory. Steps to Replicate: The root cause of this bug was found by code inspection. The problem could not be reproduced. | The code is modified to address the issue. Workaround: None. |
10 | SBX-113876 | SBX-115061 | 1 | Portfix SBX-115061: Fraud Mitigation on the SBC requires a specific cause code response. Impact: The functionality works and a call is released with 480 Temporarily Unavailable. There is a regulatory requirement that a specific Cause Code should be released when a Fraud Call is blocked. Root Cause: The ERE needs to have a new SEEDED script for call termination with results in the 607/608 status code being sent to the network. Steps to Replicate:
| Two new scripts are seeded:
Workaround: None |
11 | SBX-111620 | SBX-115025 | 1 | Portfix SBX-111620: During a T140 call there is one-way stream with a zero media port (NAPT media). Impact: A one-way stream is observed with a zero media port when the RTCP NAPT learning is complete before the RTP NAPT learning. Root Cause: Steps to Replicate:
| In a multiple stream scenario, when the RTP Port is 0, set it to loop back port 5004. Workaround:
|
12 | SBX-115316 | SBX-115429 | 1 | PortFix SBX-115316: The upgrade is related to marker files that are not being removed even after a successful upgrade on the public cloud. Impact: On a public cloud like Azure and AWS, a couple of marker files are created to indicate that a model update is needed after an upgrade. These marker files should be removed once the upgrade is completed, but are not. Root Cause: . If a system is being upgraded to 9.x or later releases while on public cloud platforms, these marker files will still exist and can cause the system to go through a model update on every SBC application restart. Steps to Replicate:
| The marker files are deleted correctly after an upgrade. Workaround: Contact TAC through a SFDC ticket to ask for the procedure. It is not a normal activity and will require Linux shell access. |
13 | SBX-97435 | SBX-115056 | 1 | Portfix SBX-97435: During an LRBT scenario, the SBC is not processing a sendrecv in a SIP re-Invite message causing a one-way audio. Impact: A Gateway to Gateway call scenario with a local ring back, causes a one way audio issue. Root Cause: As part of enabling the media end to end, the SBC initiates a Re-INV with an SDP attribute as sendonly for which the UAC responds with receonly. This causes the SBC to start a new modify offer-answer cycle towards the Egress GW. Steps to Replicate:
| The code is modified to address the issue. Workaround: None |
14 | SBX-115939 | SBX-116048 | 1 | Portfix SBX-115939: The SBC uses an incorrect branch parameter from the last transaction. Impact: The SBC retransmits an ACK for 200 OK with a different branch parameter from the previous ACK. Root Cause: Transactions occur before the retransmit ACK and overwrite the previous branch parameter transaction. Steps to Replicate:
| Save the ACK branch parameter in a separate transaction to avoid being overwritten Workaround: If a reInvite is due to a media lock down, then disable the media lock down, or use a reliable transport. |
15 | SBX-114393 | SBX-114801 | SBX-114802 | 1 | Portfix SBX-114393: The TLS Session ID has all zeros on the new 9.2.2R3 code. Impact: The TLS Session IDs are not printed in the TLS Session Status command output. Root Cause: The code is removed in the latest releases. Steps to Replicate:
| The code is added to print Session IDs in TLS Session Status command output. Workaround: None |
16 | SBX-113065 | SBX-115040 | 1 | Portfix SBX-113065: A Critical alarm is showing as Urgent under the "EMA > Monitoring > Alarm > Current Alarm." Impact: A Critical alarm is showing as Urgent under the "EMA > Monitoring > Alarm > Current Alarm." Root Cause: The screen text of a critical alarm appears as Urgent instead of Critical. Steps to Replicate:
| The code is modified to address the issue. Workaround: None |
17 | SBX-116166 | SBX-116580 | 1 | Portfix SBX-116166: The SBC intermittently fails to handle a "Packet Too Big" event and sends an unfragmented packet to the gateway. Impact: The IPv6 Path MTU Discovery does not work.
Root Cause: When performing an IPv6 route/fib lookup while updating the Path MTU from the "ICMPv6 Packet Too Big" message, it doesn't consider the ipInterfaceGroup and the addressContext. This results in not updating the Path MTU with the proper route entry to the peer. Steps to Replicate:
| The code is modified for handling "ICMPv6 Packet Too Big" messages by adding:
Workaround: Add subnet routes on packet interfaces to the peer. |
18 | SBX-114981 | SBX-115572 | 1 | Portfix SBX-114981: The Block Direction does not work when selecting a secondary trunk group with a SIP Parameter Based Action Profile. Impact: The TG Block Direction feature is not applied on a newly selected Ingress TG. The new Ingress TG is selected by the SMM's storeIpTg or by using a sipParamBasedAction Profile. Root Cause: The TG Block Direction feature is not applied on a newly selected Ingress TG due to a design issue. Steps to Replicate:
| The code is modified to address the issue. Workaround: None. |
19 | SBX-115317 | SBX-115683 | 1 | PortFix SBX-115317: Error 0x6 Line 2932 File /sonus/p4/ws/release/sbx5000_V08.02.05R004/marlin/SIPSG/sipsgLibUtils.c Impact: The following command does not work correctly after a switchover: Root Cause: The accounting functionality for Out of Dialog messages uses a specific hash table that does not exist on the new active after a switchover. This hash table is not created on a Standby because it is not needed. But, it should be created when the standby becomes active. Steps to Replicate:
| The code is modified to create the necessary hash table after a switchover. Workaround: Disable accounting for PUBLISH, MESSAGE, OPTIONS or NOTIFY using the command syntax below: |
20 | SBX-113280 | SBX-114630 | 1 | Portfix SBX-113280: An alarm is issued on the M-SBC. The M-SBC resets the VF after the user stops the Tshark. Impact: The Tshark start/stop operations sporadically cause link failure events in theSWe. Root Cause: A Link status of "link down" for DPDK API occurs if it finds the VF<>PF mailbox busy due to another activity In this case it is due to a multicast mac address programming that is triggered by the Tshark. Steps to Replicate:
| The code is modified to address the issue. Workaround: None. |
21 | SBX-111908 | SBX-115254 | 1 | PortFix SBX-111908: The Standby SBC has the same pkt0/pkt1 IPs as an Active SBC and is sending a response to the HFE. Impact: In the Azure HFE, if a connection is created before implementing the routes for CUSTOM_ROUTE natvar, the HFE does not input the source IP correctly. Root Cause: The connection tracking table in Linux caches the connection to go via the eth0 instead of what is set in the CUSTOM_ROUTE, which breaks the source NAT matching rules. Steps to Replicate:
| The code is modified to address the issue. Workaround: After starting up the HFE, run 'sudo conntrack -F conntrack', to refresh the connection tracking rules. This will need to be done after every reboot. |
22 | SBX-110574 | 1 | The RURI is populated with an INTL CC of a calling number to the egress carrier. Impact: The country code in the RURI username is populated incorrectly. The first route fails and a second route is selected after a number translation. The second route has the Undo LNP flag checked in its IP signaling profile. Root Cause: When a second or subsequent route is used, some of the number translation information from the first route is applied. Steps to Replicate:
| The code is modified to address the issue. Workaround: None. |
23 | SBX-113238 | 1 | The location of PAI CPC is not positioned consistently. Impact: When a presentation is allowed, the SBC sends an egress INVITE with a PAI header. The PAI CPC is put between the username and hostname of a SIP URI. When a presentation is restricted, it is present after the hostname in the SIP URI. Root Cause: When a presentation is restricted, the code is checking that the "Disable 2806 compliance" configuration is enabled. It populates a CPC parameter in the PAI after the SIP hostname. Steps to Replicate:
| The code is modified to address the issue. Workaround:
|
24 | SBX-114410 | 1 | The SBC-SOSBC-RTU license is displayed as 0 on the EMA. Impact: The SBC-SOSBC-RTU license is applied to the SBC, but it's not displayed in the EMA/EMS License Manager. Root Cause: A license with the feature name SBC-SOSBC-RTU is not considered. Steps to Replicate: Not applicable | The code is modified to recognize the SBC-SOSBC-RTU license. Workaround: None |
25 | SBX-114393 | 1 | A TLS Session ID has all zeros on the new 9.2.2R3 code. Impact: The TLS Session IDs are not printed in the TLS Session Status command output. Root Cause: The code is removed in the latest releases. Steps to Replicate:
| The code is modified to address the issue. Workaround: None |
26 | SBX-113702 | 1 | Accounting Logs are not escaping the special characters in the calling name fields. Impact: Accounting Logs are not escaping the special characters in the calling name fields. Root Cause: If a non-alpha numeric character is included in the calling name, the SBC is not escaping the character in the Accounting Record. This leads to an incorrect "called asserted identity" field. Steps to Replicate:
| The code is modified to address the issue. Workaround: None |
27 | SBX-113170 | 1 | A Call fails with the NRM error "could not find a card for IP call." Impact: Some calls start failing after a switchover and continue to fail until a manual switchover is performed. Root Cause: No root cause found. The following log message is an indicator of this issue: Steps to Replicate: The steps cannot be reproduced. | The code is modified to gather more information to find a root cause and address the issue. Workaround: This issue can be resolved by a manual switchover. |
28 | SBX-113448 | 1 | A Back to back SAM Process coredump occurs on the system. Impact: A SAM Process coredumps while doing the OCSP queries when the SBC is under Denial-of-Service (DoS) attacks. Root Cause: A Linux file descriptor value in an OCSP query is out of range for select() call, used by OpenSSL API, causing memory corruption. Steps to Replicate:
| Do not perform the OCSP query when the file descriptor value used in the OCSP is out of range for a select() call to prevent memory corruption. Workaround: Disable the OCSP. |
29 | SBX-113986 | 1 | A User-to-User parameter is duplicated in a Refer-To header. Impact: When a REFER message is relayed while transparency for all headers is active, the URI parameters appear twice in the Refer-To header. Root Cause: An interaction between the transparency of all the headers and a relay of the Refer-To header. Steps to Replicate:
| The code is modified so that the URI parameters appear only once. Workaround: An SMM rule workaround is possible, if the Refer-To is relayed transparently. |
30 | SBX-112031 | 1 | A SAM Process coredump occurs on the server. Impact: A SAM Process coredump occurs when an AOR entry is deleted. Root Cause: When an AOR entry is deleted, the SBC starts a registration cache timer after saving an AOR in the cache. If the registration timer fails to start, an AOR cache entry is freed but the hash entry is not removed from the hash table. This results in a corrupted list in the hash table.
Steps to Replicate:
| The code is modified to remove the cache entry from the hash table before freeing up the complete cache RCB block. Workaround: None |
31 | SBX-113883 | 1 | On the SBC SWe, there is a CPU Usage display error in the web page. Impact: On the SBC SWe, the CPU Usage page on the EMA throws out an error indicating an invalid value for the row containing unused vCPUs. Root Cause: When the number of vCPUs allocated to the SBC SWe VM are over-provisioned, some of the cores remain unused.
Steps to Replicate:
| In an SBC SWe with over-provisioned vCPUs, the unused vCPUs are explicitly defined as "unused" even on the EMA page's CPU usage tables. Workaround: None. |
32 | SBX-115484 | 1 | An SCM Process coredumps when accessing a null pointer. Impact: An SCM coredump occurs when there is an attempt to dereference a NULL pointer. Root Cause: This coredump occurs when there is an attempt to dereference a NULL pointer in code that is added. The race condition and coredump results from changes to the MOH for MS Teams after a call legPtr is accessed and the call leg is released. Steps to Replicate: The steps cannot be reproduced. The bug is found by code inspection. | The code is modified to address the issue. Workaround: None |
33 | SBX-114315 | 1 | A failover occurs on the SBC because of a SCM Process coredump. Impact: An SCM coredump occurs if the hostName in the From header is longer than 64 bytes. Root Cause: The code is copying the host name into an array that is not long enough to hold it, resulting in memory corruption. Steps to Replicate:
| The code is modified to address the issue. Workaround: None |
34 | SBX-115082 | 1 | A bug is found in the CDR Viewer Sip Ladder Diagram message contents. Impact: A Ladder diagram is not showing the full message. Different parts of a SIP message that should be shown as a single message instead multiple messages, are displayed in the ladder diagram Root Cause: The implementation assumes that the different parts of a single message are logged in the TRC file in sequence one after the other. In some cases different parts of the SIP message are logged randomly, causing the implementation to break. Steps to Replicate:
| The code is modified to address the issue. Workaround: None |
35 | SBX-113436 | 1 | The Alarm History is not cleared in the EMA after clearing in the CLI. Impact: The Alarm History is not cleared in the EMA after clearing in the CLI. Root Cause: A cleared alarm list is deleted in the CDB and the postgres entries are not ignored, causing the UI to display the entries. Steps to Replicate:
| The code is modified to address the issue. Workaround: None |
36 | SBX-112945 | 1 | The SRTP and the ENCRYPT "IN USE" counters leak for call flows with two transfers that use the INVITE with Replaces. Impact:
Root Cause: The logic for auditing the consultative refer calls does not work properly for a call pick-up. This logic creates one extra virtual leg for a second pick-up call, making a three virtual leg creation for two pick-up calls. This also results in a license adjustment. The licenseCall becomes 0 and the SBC-RTU "IN USE" decrements. Steps to Replicate:
| A new internal flag is introduced to identify a pick-up call. This flag is set for every pick-up call after a virtual call leg creation and license adjustment. A check for the same flag is added in the audit logic to avoid the audit logic for pick-up calls. Workaround: None. |
37 | SBX-112374 | 1 | The SBC is intermittently stripping the last 'm=' line from the Egress Invite. Impact: The SBC strips off the lines after the m =application line when present in the SDP of the incoming Invite, and at Egress the SBC does a DNS lookup. Root Cause: There is a NULL termination after the m=application line, causing the SDP to truncate SDP after the m=application line. Steps to Replicate:
| The code is modified to address the issue. Workaround: Use the actual IP address in the IP peer, instead of the FQDN. |
38 | SBX-116476 | 1 | After an SBC switchover, the standby SBC is not recognized. Impact: There is a PRS core dump in the XrmIPsecSACmdAdd() process. Root Cause: There is a PRS core dump in the XrmIPsecSACmdAdd() process because the process is attempting to de-reference a NULL pointer. This is because the code is not handling an error condition correctly. Steps to Replicate: The steps cannot be replicated. This is found by code inspection. | This code is modified to address the issue. Workaround: None |
39 | SBX-113853 | 1 | There is an SBC Intermittent crash. Impact: When multiple duplicate Diversion headers are received and the stiProfile is enabled and configured on the ingress trunk group, the SBC coredumps core. Root Cause: Removing duplicate Diversion headers from information sent to the PSX causes a crash. Steps to Replicate:
| The code is modified to address the issue. Workaround: None. |
40 | SBX-115115 | 1 | The SBC disconnects the call when offering a LRBT using the first codec in 180 and the received Egress 200 contains a different codec set. Impact: The SBC internally tears down the call if the Egress peer answers with a different first codec than in the 180. Root Cause: The SBC auto answers using the first codec back to Ingress. The SBC cannot reInvite when changed by the Egress because the SBC is not ready to receive the reInvite/Update. Steps to Replicate:
| The code is modified to address the issue. Workaround: None |
41 | SBX-115749 | 1 | Video calls are being disconnected. A call transfer is failing when using both audio and video. Impact: Audio and Video calls are disconnected after a REFER. Root Cause: This issue happens when:
Steps to Replicate:
| The code is modified so that the SBC can now map to the correct video leg post REFER. Workaround: None |
42 | SBX-110716 | 1 | The SBC sends the wrong payload type. Impact: The Egress GW sends the wrong payload in a 200 OK response for an incoming Re-INVITE from the Egress peer in a GW-GW scenario. Root Cause: The issue is observed when the "Lockdown Preferred Codec" is enabled at the Ingress IPSP (at ingress GW). When this flag is enabled, the PSP is updated with selected codec containing an incorrect payload type (rx/tx as 0x00/00). This results in the Ingress SG sending a modified answer to the NRMA with an incorrect payload type Steps to Replicate:
| The code is modified to address the issue. Workaround: None |
43 | SBX-115329 | 1 | The SWe has unexpected switchovers. Impact: A SCM core dump occurs while the SIPSG is processing a "401 Unauthorized". Root Cause: The code is attempting to dereference a NULL pointer and send an UNSUBSCRIBE while processing the "401 Unauthorized" message. Steps to Replicate: The steps cannot be reproduced. | The code is modified to prevent an attempt to dereference a NULL pointer. Workaround: None |
44 | SBX-115074 | 1 | A SCM core dump may occur when using the SIPREC. Impact: A SCM core dump may occur when using the SIPREC. Root Cause: Memory corruption is caused by a double MemFree() in the SIPREC code. Steps to Replicate: The steps cannot be reproduced. This bug is found by code inspection. | The code is modified to address the issue. Workaround: None. |
45 | SBX-114398 | 1 | A core dump occurs on the SBC. Impact: During a P2P call scenario, a codec change from the PCMA to the PCMU is requested via a reInvite for Leg B. The application sends an audio modify request for both Leg A and Leg B. The DSP crashes for codecs like SILK and OPUS. Root Cause: The merging of an audio modify request for Leg A and Leg B on the application end and the lack of a check in the DSP code for a modify request on Leg A to the same codec causes a core dump. Steps to Replicate:
| The code is modified to address the issue. Workaround: None |
46 | SBX-114323 | 1 | No routes are displayed for the EMA configuration > System Provisioning > Routing > Routes screen function. Impact: The function does not work in the EMA configuration > System Provisioning > Routing > Routes. Root Cause: An old browser version does not apply the replaceAll function. and the "replaceAll is not a function" exception is activated. Steps to Replicate: The steps cannot be replicated. | The code is modified to ensure that the replaceAll functionality is working. Workaround: None |
47 | SBX-115952 | 1 | The SBC memory utilization goes up under the load with all the IP Redirect calls and the SMM variableScope rule. Impact: An IP Redirect call and a SMM variableScope may result in a memory leak. Root Cause: When the SBC redirects a call to Leg C, the SBC does not release an SMM variableScope resource that is created/stored for Leg B. Steps to Replicate:
| The code is modified to address the issue. Workaround: Remove the SMM rule |
48 | SBX-113305 | 1 | The DNS recovery packet count of a DSCP with a value of "0." Impact: The DNS probe packet's are sent from the SBC with a DSCP value of 0. Root Cause: The configured DSCP value's are not set for the DNS probe keepalive packets . Steps to Replicate:
| The code is modified to set a configured DSCP value for the packets, including the DNS probe packets. Workaround: None |
49 | SBX-117122 | 1 | Syncing CallData for gcid 0x1E0E4D36 failed: Available buffer (size 27204) exhausted. Impact: A LSWU fails when Direct Media is enabled and the SBC is processing calls that have more than four media streams. Root Cause: A LSWU fails because an error occurred when syncing an SIP call block. SYNC of SIPSG Call Blocks is failing because an individual Call Block does not fit in the 64K buffer that is allocated for mirroring a Call Block. When the mirrored data for a single call does not fit into the buffer, the code currently stops syncing the call blocks. Steps to Replicate: Enable Direct Media and send a call with more than four Media Streams. | The code is modified so that the entire SYNC does not fail if we cannot mirror a single Call Block. Instead, the original Call Block moves onto the next available Call Block and continues the SYNC. Workaround: Disable Direct Media. |
50 | SBX-114458 | 1 | Node A failed to take over after node B had issues with hard disk. Impact: The trap was not generated for HardDisk fault on the SBC. Root Cause: Although the trap was getting generated for some harddisk/FS errors, a new error with 'failed command: FLUSH CACHE EXT' was being considered when generating a trap. Steps to Replicate: The steps cannot be reproduced. | The code is modified to address the issue. Workaround: None. |
51 | SBX-116156 | 1 | A LSWU through the EMA GUI is stuck at post upgrade check and did not continue upgrading to the active EMA. Impact: If the upgrade is in progress when the daily cronjobs run, it may cause the upgrade to stop. Root Cause: As part of the log rotation, Apache/Platform Manager logs gets rotated and apache gets signal HUP and restarts. This causes the upgrade script to terminate because the parent(apache) is restarted. Steps to Replicate: Install and upgrade from a pre 9.2.4 to 9.2.4 | The code is modified to skip apache log rotation if the upgrade is in progress and to use nohup with an upgrade and revert scripts. Workaround: Restart the upgrade or revert and retry upgrade. |
52 | SBX-117099 | 1 | A SCM Process core dump occurred on the SBC server. Impact: The SCM Process cored. Root Cause: The SCM Process has cored because of an attempt to de-reference a NULL pointer. Steps to Replicate: The steps cannot be reproduced. | The code is modified to check the value of the pointer before accessing it. Workaround: There is no known workaround. |
53 | SBX-117187 | 1 | The config Export is failing because of the DM/PM Rule. Impact: The config export is failing due to a confd error occurring while reading a DM/PM Rule. Root Cause: The subRule being exported had a subRule type of uri. However, the export reads all of data for all subRule types, and the data in the digitStringManipulation->replacement->type was 2, which is an invalid value. This value is retrieved from the postgres database table pm_rule, which stores the replace->type value from the uri subrule as the invalid value 2. Steps to Replicate:
| The code is modified when the digitStringManipulation container is being read, if the replacement->type value is 2, it is set to 0. Workaround: Before exporting, change all dmPmRules with a subRule type of uri to set the uriParameterManipulation->userInfoManipulation->replacement->type field to constant and then do the export. Change the value back after the export. |
54 | SBX-116468 | 1 | An SIP.Instance parameter is missing from Contact Header for De-Registration Message generated by the SBC locally. Impact: When the SBC generate the unregister message to registrar, the +sip.instance and reg-id parameters are missing in Contact header. Root Cause: The root cause was missing functionality. Steps to Replicate:
| The code is modified to address the issue. Workaround: None. |
55 | SBX-116299 | 1 | A restart with a Comp_SAM Process Coredump. Impact: Memory corruption causes a SAM Process coredump when processing a GW-GW message. Root Cause: Memory corruption causes a SAM Process coredump when processing a GW-GW message. Code doesn't allocate enough memory for an outgoing message. When the data is copied into the message, the code writes past the end of the allocated buffer because there isn't enough space in the buffer. Steps to Replicate: The steps cannot be replicated. The root cause is found by code inspection. | The code is modified to allocate enough space for the outgoing message. Workaround: None |
56 | SBX-114045 | 1 | The SBC is failing to come up with a "cps is not initialized:failed" message after a shut down. Impact: The Virtual SBC fails to startup due to a missing file link for an OS binary. Root Cause: There is a missing OS level soft link that is required for the SBC startup code. The OS level soft link may have been lost as a result of multiple reboots while the SBC is trying to startup in a virtual deployment. Steps to Replicate: The steps cannot be replicated. | The code is modified to address the issue. Workaround:
|
57 | SBX-114367 | 1 | An Announcement Package Element cannot be deleted. Impact: An element within an announcement package cannot be deleted. Root Cause: The code for handling the announcement package element Delete command is incorrect. Steps to Replicate: Perform following configuration changes through the CLI:
| The code is modified to address the issue. Workaround: The announcement package can be deleted and then re-created without the required element. |
58 | SBX-114301 | 1 | In the EMA GUI, a Destination National is not showing "+" when it is configured in a Route through the EMA. Impact: In the EMA GUI, a Destination National is not showing the plus symbol when it is configured in a Route through the EMA. Root Cause: In the frontend, symbols like the "+"are replaced with a space before sending to the backend. Steps to Replicate: None | The code is modified to address the issue. Workaround: Replace the "+" with "%2B" using the replace function. The plus symbol will appear in the EMA GUI. |
59 | SBX-114980 | 1 | An SBC 7000 memory leak in CE_2N_Comp_ScmProcess_x processes occured. Impact: An SCM memory leak can occur when processing the Contact Headers if the honorEmbeddedHeadersin3xx flag is enabled in the ipSignaling Profile. "set profiles signaling ipSignalingProfile <SIP profile name> egressIpAttributes redirect flags honorEmbeddedHeadersin3xx" This leak will not always happen when this flag is enabled. There are several other conditions that must be met in order to expose this leak. This leak may also exposed by enabling the flag "includeEmbeddedPAIheaderInRedirectedInvite" in the ipSignalingProfile. Root Cause: The leak is caused by a missing call to the MemFree(). Steps to Replicate: The steps cannot be replicated. The root cause is found by code inspection. | The code is modified to ensure that the internal structure is always freed. Workaround: Disable the following flags in the IPSP:
|
60 | SBX-116060 | 1 | Unable to login to the HFE_PKT1 in Azure. Impact: The HFE_AZ.sh script fails on the HFE PKT1 in Azure when a public IP address is attached on the mgmt (eth1) interface. Root Cause: The repository fails to install the required utilities for Linux and fails to create a temporary default route through the eth1. Steps to Replicate:
| The code is modified to add the default route through eth1. Workaround:
|
The following Severity 2-4 issues are resolved in this release:
Severity 2-4 Resolved Issues
Issue ID | Sev | Problem Description | Resolution | |
---|---|---|---|---|
1 | SBX-116735 | 2 | Editing a route with DN using '@ 'and '&' characters is duplicating the same route. Impact: Using '@' and '&' characters in the DN field is duplicating the same route. Root Cause: A few special characters were not decoded while editing and as a result, a route has been duplicated. Steps to Replicate:
| The code is modified to address the issue. Workaround: No workaround. |
2 | SBX-114429 | 2 | The data_type properties fields should not have a "dot" in the identifier. Impact: The data_type properties fields should not have a "dot" in the identifier. Root Cause: MongoDb uses "dot" notation to locate fields within structures. When the NVFO posts the VNFD through the VNFM API, MongoDb incorrctly uses the identifier as a field name, which causes MongoDb to throw an exception. Steps to Replicate: Run VNFM, NFVO and HPE Orchestration, and check communication with the EMS. | The code is modified so the "dot" in the "SBC:EMSPRIVNODEPARMS.cluster_id" is replaced with "hyphen" . The new parameter is listed as "SBC:EMSPRIVNODEPARMS-cluster_id". Workaround: None. |
3 | SBX-117091 | 2 | Discrepancy between ‘View CLI’ from GUI and the SBC CLI output. Impact: If you are viewing the CLI version of the content, the GUI stops displaying the CLI when it hits the ‘type sdpContent’ operation. Root Cause: The CLIRules.xml file were not updated with latest changes in in the CLI. Steps to Replicate: Check CLI commands in CLI is same as commands in UI after selecting the view CLI. | The code is modified to address the issue. Workaround: None. |
4 | SBX-117051 | 2 | There is no planned cluster switchover. Impact: The SCM process coredumps while comparing codec information. Root Cause: In a race condition while comparing codec information, the SCM process is dereferencing a null pointer that resulted in a coredump. Steps to Replicate: The steps cannot be reproduced. | The code is modified to verify that the pointer is not null before dereferencing it to avoid the coredump. Workaround: None. |
5 | SBX-115897 | SBX-116288 | 3 | PortFix SBX-115897: The SBC sends one of the SIP NOTIFY messages with Event: Dialog body back to the registrar instead of relaying it to the subscriber. Impact: Back-to-Back NOTIFY messagesfrom the registrar with dialog event (DialogInfo data) that requires an internal query across distributed ScmProcesses may cause the SBC to send the NOTIFY relay back to the registrar. Root Cause: While doing an off board query (distributed lookup in the SBC), the SBC received a message from IAD and relays to Registrar. After an off board query, the SBC is using the same direction from IAD to registrar for relaying the next Notify Steps to Replicate: A subscribe to registrar, registrar sends multiple back-to-back Notify (around 50ms delay) with dialog event to A. | The code is modified to save the direction of relay before off board query, and restore after off board query reply and using that direction for relaying subsequent messages. Workaround: There is no workaround. |
6 | SBX-111461 | SBX-117346 | 2 | PortFix SBX-111461: The SBC plays LRBT using PCMU when negotiations occurred with AMRWB in a LM call. Impact: The tone played is with old negotiated codec instead of the codec selected by ingress endpoint in Prack. The issue is seen only when multiple codecs are sent in late media offer in 180 with sendSbcSupportedCodecsForLateMediaReinvite flag enabled. Root Cause: The initial DSP resource allocated only has capability to play tone with G711. After AMRWB is selected as the new codec for tone play in Prack, the old DSP resource is found unusable and new DSP resource is allocated with capability to play tone with the new selected codec. However, though a new compatible DSP is allocated, the old DSP resource/XPAD is incorrectly retained in the resource chain and as a result, the tone is with the old codec. Steps to Replicate:
| The code is modified so that when Prack is received with SDP in LM scenarios, SWEA events are issued from PC-FSM to play tone. The ASG has a sequence of events like NRMA allocate reply/activate reply/deactivate reply/dealloc reply that drives these SWEA events to DSP. Workaround: No workaround. |
7 | SBX-116164 | SBX-117373 | 3 | PortFix SBX-116164: Autonomous fail over of the SBC 5210. Impact: There was an SCM core while processing Register request during an IMS intercept. Root Cause: The register looks like a retransmission and the SBC has found an existing TCB for the register. While accessing the Apphandle of TCB (which points to RCB data) the SBC cored. This is due to the RCB is not being present and address is reused for something else. Steps to Replicate:
Without this fix, the SCM cores when the SBC tries to access the deleted RCB. As an additional test, alter the fourth step to, instead of De-reg, try sending the old register that received an 200 OK [branch, call-id, cseq should be exactly the same]. | The code is modified so once a response is sent to a register, IMS intercepts the message. After an interception, reset the correlationTag (i.e, AppHandle) to NULL. Workaround: None. |
8 | SBX-114151 | SBX-116946 | 2 | PortFix SBX-114151: Pre-upgrade BMC version check issues Impact: During pre-upgrade checks, an invalid BMC version error message is displayed and reports pre-upgrade checks as failure. Root Cause: The BMC version check is run during pre-upgrade checks, and reports a failure for an invalid BMC version. Steps to Replicate: Run pre-upgrade checks and ensure BMC version check error is displayed as a warning and not a failure. | The code is modified to make it a warning rather than a failure for pre-upgrade checks. Workaround: None. |
9 | SBX-113966 | SBX-116994 | 2 | PortFix SBX-113966: RCBs are not synced to the STANDBY. Impact: Some Registrations were not being mirrored to the STANDBY SBC due to buffer not large enough for amount of info obtained from the messaging. Root Cause: If/Then/Else statement was modified to check if certain info (Child AOR) present, which allocates a LARGE buffer all the time now. Steps to Replicate:
Expected Results: Actual Results: | The code is modified to address the issue. Workaround: None. |
10 | SBX-113840 | SBX-114372 | 2 | PortFix SBX-113840: Reset the fields in the nrmacalleg. Impact: Certain fields in a data structure are not reset to default values during a call tear down. Root Cause: Due to performance reasons, one of the sub-system re-uses this memory block again for new calls. Since, the fields from previous call were not reset during tear down, these fields continue to be set even for the new call and could result in undesired behavior. Steps to Replicate: The steps cannot be reproduced. | The code is modified to correctly reset missing fields during call tear down. Workaround: None. |
11 | SBX-109315 | SBX-116588 | 2 | PortFix SBX-109315: There are SBC sync issues. Impact: There is no event/alarm to indicate a Postgres transition failure during a switchover. Root Cause: The Postgres Transition failed within the timeout period, but the switchover continued. Subsequently, the SSDB became active, but failed within the timeout duration (20 seconds). As a result, the SSDB became unrecognizable due to a missing replication slot. Steps to Replicate: Return a non-zero value from WaitActive function in startPGDB.sh to simulate Postgres transition failure. Attempt a switchover. Check event logs and startPGDB.log. | The code is modified to indicate a Postgres transition failure during switchover. Workaround: None. |
12 | SBX-115243 | SBX-115847 | 3 | PortFix SBX-115243L The Automatic AD Sync is not completing. Impact: The Automatic AD Sync is not completing. Root Cause: During the change from Daylight Savings Time in the Fall, the addMinsToTime routine returns a time that is greater than the passed-in time. 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 passed-in time when switching from Daylight Saving Time. Workaround: None. |
13 | SBX-110756 | SBX-113982 | 3 | PortFix SBX-110756: Wrong behavior with sipAdaptiveTransparencyProfile enabled. Impact: When the SipAdaptiveTransparencyProfile was enabled and the SBC received 200 OK with SDP, it was sending ACK without SDP in late media scenario cases. Root Cause: The SDP was not being added in ACK in late media cases. Steps to Replicate: The following are the test cases used in the call flow:
| The code is modified to add SDP in ACK for late media cases. Workaround: None. |
14 | SBX-108609 | SBX-110025 | 2 | PortFix SBX-108609: The SBC failed to send telephone-event when payload type number overlaps with configured in PSP for any codec. Impact: The SBC fails to send 16,000 2833 payload type in outgoing INVITE when the 16,000 PT value received from ingress conflicts with the configured PT value for one of the codecs in egress route PSP. Root Cause: The SBC failed to detect and resolve the conflict between 16,000 DTMF PT and egress route codec PT which resulted in the SBC dropping the 16,000 PT in outgoing INVITE. Steps to Replicate: Configuration:
To re-create the issue:
m=audio 5096 RTP/AVP 102 97 0 110 101 107 103 98 96 105 Test Result without a fix: The SBC chooses to follow egress PSP configuration, which means it drops the telephone-event/16000 payload type. | The code is modified to prefer the pass-through DTMF PT value over the route configured codec PT by extending the PT conflict resolution to all the dynamic codecs. Workaround: As a workaround, the conflicted PT value can be modified at egress Route PSP. |
15 | SBX-114691 | SBX-115064 | 2 | Portfix SBX-11469: "Challenge-SMM" is not added in the NOTIFY to the Ingress side of the SBC. Impact: Challenge SUBSCRIBE is not processed when it does not contain a to-tag. Root Cause: When a challenge SUBSCRIBE comes without a to-tag, we are unable to find RelayCb, creating new RelayCb and processing as a new request. Steps to Replicate:
In DBG logs, we can see there will be two relayCbs will be creating for the same SUBSCRIBE flow. | The code is modified to address the issue. Workaround: Send a challenge SUBSCRIBE with the received to-tag. |
16 | SBX-114019 | SBX-114071 | 2 | PortFix SBX-114019: The DBG logs are rolling rapidly with UacSendUpdate messages. Impact: The SBC DBG logs were filling up quickly with the following log message: Root Cause: The code was mistakenly printing logs at the MAJOR level. Steps to Replicate: The log is generated during a call where the SBC attempts to send UPDATE out to ingress leg while the PRACK is pending for previous 18x sent. | The code is modified to only print the logs at INFO level. Workaround: None. |
17 | SBX-113524 | SBX-113910 | 2 | PortFix SBX-113524: The SBC is not forwarding the received 200 OK and fails the call. Impact: When using a GW-GW for direct media calls between signaling-only SBCs, the 200 OK is not being passed through and the call fails. Root Cause: The code is unable to process the outgoing 200 OK because it cannot find any local IP information. Steps to Replicate: Make a direct media call between two signaling-only SBCs with the following control enabled. | If the sigOnlyMode flag is set to global, copy the local IP information. Workaround: Disable the following control: set global signaling sigOnlyMode sigOnlyModeValue off |
18 | SBX-111357 | SBX-113041 | 2 | PortFix SBX-111357: Cleared Alarms functionality is not working properly in the EMA. Impact: Cleared alarms are not listed in "Cleared Alarms" screen under Monitoring > Alarms in the EMA. Root Cause: Cleared Alarms screen combines alarms from both the CDB and Postgres. However, there was a fix made for a customer issue related to an alarm in 9.2.2, resulting in ignored alarms in the CDB. Steps to Replicate:
| The code is modified to retrieve the alarms from CDB and return them to UI for display purpose. Workaround: No workaround. |
19 | SBX-114303 | SBX-114385 | 2 | PortFix SBX-114303: Customer PSTN is incorrectly listed as Busy. Impact: The SBC attempts to map non-E164 display Name of a p-asserted-Identity TEL to generic address for called user. Root Cause: When the SBCs received both pai (tel)and pai(sip) headers, it tries to treat the headers as a customer TTC even though the display name in pai(tel) is not in E164 format. Steps to Replicate:
| The code is modified to address the issue. Workaround: Use the SMM to delete incoming display name in pai(tel) header. For an out going INVITE, add it back if pai is config transparency. |
20 | SBX-111984 | SBX-115026 | 2 | Portfix SBX-111984: The SBC box is not coming up with the latest ASAN build. Impact: The SBC box is not starting up in ASAN build. The SBC code that is used to generate traps was accessing memory after it is freed while processing traps that contained an IP address parameter. Root Cause: The IP parameter passed to confd as part of the trap information was stored in a location that was freed before the confd processed the trap API call. Steps to Replicate:
| Store the IP parameter in a location that is not freed before the call was made to send the trap. Workaround: None. |
21 | SBX-111773 | SBX-115044 | 2 | Portfix SBX-111773: Coverity Issues in SIPSG - Cause Map CPC - SIP Impact: In the SipSgDiscReasonMapCpcToSip, the API pointer is checked against a NULL pointer but then is dereferenced again. Root Cause: The Pointer validation was missing for a particular flow, which led to invalid memory access. Steps to Replicate:
| The code is modified to avoid unwanted flow to get executed. Workaround: None. |
22 | SBX-114110 | SBX-115808 | 2 | PortFix SBX-114110: A call from the child AOR fails after a switchover. Impact: A user is registered on the UDP and INVITE comes in (different port) on the TCP fails with a 403 message. Original bug was fixed in the 8.2.6 release, but the same problem is seen after a switchover. This additional fix is related to the RCB (registration control block) mirrored to the standby. Root Cause: Once the maskportforRcb flag is enabled, a parent RCB is found but the child RCB is not. Mask port and mask IP were not considered during child creation. This additional fix mirrors the child info correctly. Steps to Replicate:
| Update the child information correctly based on the masking flags, then mirror to standby. Workaround: Not available. |
23 | SBX-115151 | SBX-116768 | 2 | PortFix SBX-115151: Addressing log4j vulnerability - CVE-2019-17571 in 10.x. Impact: Addressing the Log4j vulnerability reported in CVE-2019-17571, CVE-2021-45105 and CVE-2021-44832. Root Cause: CVE-2019-17571 is reported in log4j 1.2 up to 1.2.17 Steps to Replicate: The steps cannot be replicated. | The code is modified so the Log4j is 2.17.1 to resolve all the listed CVE vulnerabilities. Workaround: None. |
24 | SBX-111077 | SBX-114786 | 2 | PortFix SBX-111077: The Power LED is OFF instead of AMBER when the BMC is ON. Impact: The SBC 51xx/52xx front panel power LED is off, when it should be AMBER. Root Cause: The power LED is set to off when the host is powered off. Steps to Replicate: Power off the host and check the power LED status. | Setting power led to amber after power off host. Workaround: None. |
25 | SBX-115320 | SBX-115570 | 2 | PortFix SBX-115320: Compressed CDR filename should use a readable timestamp. Impact: The filename for compressed CDR filenames does not contain a human readable timestamp. Root Cause: The timestamp contained in the filename is the number of seconds since the unix epoch time. Steps to Replicate: Configure the SBC to write out compressed CDRs: | The code is modified so the file name form is now yyyymmddhhmmss Workaround: The timestamp in the logs can be converted to a human reading form with the linux command |
26 | SBX-112867 | SBX-113456 | 2 | PortFix SBX-112867: The SBC is monitoring for RTP inactivity when a call is on hold. Impact: The SBC is reporting media inactivity immediately after a call un-hold. The configured timeout value is not being reported after an un-hold when media is not present. Root Cause: With a call un-hold, the SBC NP API handling inactivity detection restart timestamp is not being updated, and it used old timestamp, reporting the inactivity notification earlier than expected. Steps to Replicate: With inactivity detections enabled, make a call, put the call on hold for the configured threshold, and observe the results after call un-hold without sending media. | The code is modified to report the inactivity after a configured interval as expected. Workaround: Inactivity detections can be disabled, or action can be changed from disconnecting the calls in this scenarios. |
27 | SBX-115576 | SBX-115680 | 3 | PortFix SBX-115576: Hitting restart limit during software upgrade leaves the model locked. Impact: AMF model remains locked after an update. Root Cause: System startup failure results in soft restart limit being hit, stopping the AMF model update process. Steps to Replicate: Model update marker needs to be in place, and then repeatedly kill the service after startup but prior to five minutes passing. On the 6th attempt to restart, the soft restart limit will be hit and the service will not attempt restart and the model will remain unlocked. | The code is modified to prevent killing the AMF model update process. Workaround: Fix the instability issue causing the system to repeatedly crash and restart. |
28 | SBX-112162 | SBX-115070 | 2 | PortFix SBX-112162: [ASAN]: AddressSanitizer: unknown-crash on address 0x7f0f40a9d280 at pc 0x5640ea4b71de bp 0x7f0f40a78700 sp 0x7f0f40a786f8 in SipsGetSmmProfileForDlgScopehashUpdate. Impact: The ASAN reported "runtime error" error for an enum. Root Cause: The load value was exceeding the defined enum value. Steps to Replicate: Run the ANSI-88 ISUP INVITE-CANCEL SIP-I codenomicon suite. | The code is modified to add checks to ensure that we do not exceed the defined value. Workaround: None. |
29 | SBX-115908 | SBX-116248 | 2 | PortFix SBX-115908: Dialer SBC - media forking/call recording and high memory usage Impact: There are call failures due to a memory leak in NICE Recording scenarios. Root Cause: The memory leak is caused by a bug in the code that handles mirrored Recorder Call Blocks on the Standby. The Recorder Call Block isn't cleaned up on the Standby until the call goes down. If a second recorder session is started while a call is still up, some of the information about the first Recorder session will be overwritten. This prevents the first Recorder Call Block from ever being freed. When the standby transitions to active as the result of a switchover, these leaked Recorder Call Blocks are carried over to the active because the information needed to initiate the cleanup is still missing. Calls are rejected after surpassing the 55,000 call block per SCM process limit. This limits the number of calls that SCM can process to 55,000 minus the number of leaked call blocks. Steps to Replicate:
| The code is modified to handle mirrored Recorder Call Blocks on the Standby. When a second Recorder Call Block is received on the Standby, the first Recorder Call Block is freed. Workaround: Prevent the NICE server from starting multiple recording sessions for the same call. |
30 | SBX-114833 | SBX-116057 | 2 | PortFix SBX-114833: Extreme congestion causes blocked end points. Impact: Extreme congestion causes end points to become blocked due to a mishap in ARS (address reachability service) handling and does not recover automatically. Root Cause: The ARS state machine does not process some unexpected internal events which leads to it not broadcasting the correct block containing the clear status to all the SCM processes. This results in some end points being stuck in a blocked state. Steps to Replicate: This issue is only reproducible under extreme congestion scenarios. | The code is modified to address the issue. Workaround: Manually recover end points blocked by ARS logic using one of the following commands: request addressContext <context name> zone <zone name> sipArsEndpointRecoveryAll |
31 | SBX-114276 | SBX-115055 | 2 | PortFix SBX-114276: The 'show status oam radiusAuthentication radiusServerStatus availableAt' command disploys the wrong value during Daylight Saving Time (DST) Impact: The show status oam radiusAuthentication radiusServerStatus availableAt command shows the wrong value during DST. Root Cause: Converting the unAvailableFrom time read from from confd to local time in seconds, adding the out of service duration, and converting to back to a local time struct tm did not result in a correct time. Steps to Replicate:
| The code is modified to the current seconds in GMT time and converted back to a time structure using a the localtime_r call. This results in the correct time being displayed. Workaround: None |
32 | SBX-113893 | SBX-114406 | 2 | PortFix SBX-113893: The SBC returned an 500 Internal Server Error and many calls failed. Impact: Observed a memory leak when the ACK sending failed towards the SIP recording server due to a DNS resolution failure. Root Cause: Once the 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. Steps to Replicate: Basic call with SIP Rec feature enabled. | The code is modified to clear call control bock when a cleanup timer expires. Workaround: Not applicable. |
33 | SBX-112830 | SBX-115068 | 2 | PortFix SBX-112830: The pattern mismatch search pattern 'Media\ Attribute\ \(a\)\:\ maxptime\:20' was not found 1 -> INVITE Impact: The max Ptime value was being sent in the egress INVITE's Ptime header though the preferPtime flag was enabled. Root Cause: The datatype of the previous field doNotAnswer was incorrect and the Ptime value was overwritten as proper size was not used. Steps to Replicate:
| The code is modified so the doNotAnswer field is the right value. Workaround: None. |
34 | SBX-112597 | SBX-115069 | 2 | PortFix SBX-112597: I-SBC: "runtime error: shift exponent 48 is too large for 32-bit type 'int' " in np.log. Impact: The ASAN builds reported an integer overflow error in calculation of standard deviation for jitter for RTP packets. Root Cause: Integer overflow during standard deviation calculation. Steps to Replicate: The problem can be reproduced by streaming RTP stream with high jitter. | The code is modified to prevent integer overflow during standard deviation calculation. Workaround: No workaround is available. This metric however, is not written into CDRs. It is currently available using Ribbon Protect. |
35 | SBX-110665 | SBX-114798 | 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. |
36 | SBX-114395 | SBX-114826 | 2 | PortFix SBX-114395: OA FSM timeout - call transfer with e2eAck enabled (ACK not sent by the SBC). Impact: After a call transfer from legB to legC, the e2e re-INVITE and ACK are not working. Root Cause: LegC incorrectly disables the e2e ACK, while legA still enables the e2e ACK. Steps to Replicate: This is specific to customer configurations.
The SBC is unable to sends ACK to legA. | The code is modified to address the issue. Workaround: Disable the e2eAck. |
37 | SBX-113242 | SBX-113350 | 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. |
38 | SBX-91194 | SBX-115048 | 2 | PortFix SBX-91194: Difference in Energy/power level is observed across the SWe and HW platform. Impact: The power of the tone generated by SWe is 3dBm0 higher than the configured value. Root Cause: The root cause of the issue is the configuration of tonePower/amplitude at the DSP interface. Steps to Replicate:
| The code is modified to properly configure the tone Power at DSP. Workaround: Not applicable. |
39 | SBX-105751 | SBX-115045 | 2 | PortFix SBX-105751: There are errors in the CE_node logs. Impact: The"ioctl: No such device" errors seen in CE_Node logs when creating VLAN interfaces on Cloud SBC or N-to-1 SBC with VLAN packet interfaces. Root Cause: The error messages are benign, since a check is made for the VLAN existence before creating a VLAN packet interface. Steps to Replicate: A. Show the issue through logs: With VLAN the interfaces configured, look for ioctl message in CE_Node logs: B. Show the fix through logs: | The code is modified to log the benign error messages in DBG logs instead of CE_Node log. Workaround: None. |
40 | SBX-111034 | SBX-115050 | 2 | PortFix SBX-111034: Unable to login as an admin user using keys after cleanDB. Impact: User is unable to login into Confd CLI using 'admin' user private SSH key after running clearDBs.sh script. Root Cause: Cloud-init fails to run as part of clearDBs.sh script and fails to restore SSH public key for 'admin' user. Steps to Replicate: Run a clearDBs.sh script after launching the instance and then try to log into Confd CLI using 'admin' user private key. | The code is modified to skip the redundant port for mac address validation in the case of packet port redundancy. Workaround: Do not run the clearDBs.sh script |
41 | SBX-110046 | SBX-115046 | 2 | PortFix SBX-110046: Passing a key size for unencrypted, authenticated SRTP/SRTCP to the NP. Impact: The RTP packets drop were occurring between the DUT and SBC. Root Cause: In the SRTP, for unencrypted, authenticated combinations, cipher key size was unable to pass to the NP and due to this session, the authentication key was incorrectly calculated. Steps to Replicate: Test all the SRTP call flows with UNENCRYPTED_SRTP flag enabled in the SBC and UNENCRYPTED_SRTP received from UEs as part of crypto attributes. | The code is modified for the NP to calculate session authentication key. Workaround: No workaround. |
42 | SBX-115261 | SBX-115440 | 2 | PortFix SBX-115261: The SBC is modifying the Warning header even when transparency is enabled. Impact: When the SBC sends a SIP Warning header with IPv6 addresses, it does not including the square brackets around the IPv6 addresses. Root Cause: The code for adding square brackets around an IPv6 address in a Warning header was missing. Steps to Replicate:
Procedure
| The code is modified to include square brackets around IPv6 addresses in a Warning header. Workaround: None. |
43 | SBX-110918 | SBX-113939 | 2 | PortFix SBX-110918: The SBC 7000 is showing DSP insertion with the reason DTMF, but the DTMF should not be displayed. Impact: The status of the following fields are not desired and contains the Junk value when running a correct amount of calls (20,000 calls):
Root Cause: The following fields are not Reset when the call is terminated and as a result, the junk values are preserved in these deallocated spaces. Steps to Replicate:
| The code is modified so that the junk value is not populated to the fields. Workaround: None. |
44 | SBX-115712 | SBX-115926 | 2 | PortFix SBX-115712: There are SIP message relay issues in an INVITE with a replaces call flow, where an early dialog is replaced. Impact: EarlyDialog replaces on ingress causes the SBC to fail and to send ACK out on the Egress when the e2eAck is enabled. Root Cause: The e2eAck flag did not turn on on Ingress yet, therefore once the ingress connected, it did not notify the Egress side to send out ACK. Steps to Replicate: Run the following configuration to reproduce the issue
The SBC fails to send Ack to B | Update the e2eAck flag on the ingress when the query requests a reply, so that the ingress and the egress are in sync. Workaround: Disable the e2eAck. |
45 | SBX-113573 | SBX-115057 | 2 | PortFix SBX-113573: The Call Media Status/ACT Log was showing media count as 0 for Ingress/Egress Packet Sent. Impact: For the egress intercepted (IMS LI/ PC2LI) call, when the RTP monitoring and delayed RBT is configured in the PSX. The Call Media Status is showing a media count as 0 for Ingress/Egress Packet Sent. Root Cause: For the egress intercepted (IMS LI/ PC2LI) call, when the RTP monitoring and delayed RBT is configured in the PSX. The main media along with RBT is impacted, so respective statistics are shown as zero. Steps to Replicate:
When a 183 is received, the SBC plays the Delayed Ring Back Tone towards the UAC. | The code is modified to not stop the main media along with intercepted media for the this call. Workaround: Not applicable. |
46 | SBX-114831 | SBX-115801 | 2 | PortFix SBX-114831: No fallback to G711 for a fax call flow upon receipt of a 488 response. Impact: The SBC is not sending fax fallback re-INVITE upon receiving 488 error response (for T38 re-INVITE) from UAS. Root Cause: New code had been introduced in 8.02 of the SBC to address a few customer requirements related to the flag - bIsOlineSame flag. None of those customer scenarios had any use cases involving Gw-Gw scenarios. There is a miss in the test coverage as a result. This new code has a missing initialization of one field that was being used for Gw-Gw scenarios, which is causing this issue. Steps to Replicate:
The SBC2 is failing to send a fax fall back re-INVITE to UAS. | Initialization code is added for the new field. Workaround: None. |
47 | SBX-115742 | SBX-115829 | 2 | PortFix SBX-115742: Follow-up fix for SBX-114771 that was a SCM core related to refreshAfter. Impact: There is a segmentation fault in SBX-114771 due to code added to avoid hack during fast refresh in SBX-111209. As the code is reverted, the SBC is open to registration hacks during fast refresh. Root Cause: The SIPSG code hit a Segmentation fault while sending a 200 OK response to a REGISTER because it is attempting to dereference an invalid pointer. Steps to Replicate: Test steps are same as SBX-111209. | The fast refresh is handled in the SIPCM for any register. So the fix for the fast refresh hack is moved to the SIPCM Module. Workaround: No workaround. |
48 | SBX-114557 | SBX-115063 | 2 | PortFix SBX-114557: While running a suite for a previous issue on the ASAN, the Build Number: 1252 found this issue in the SCM Process. Impact: The "AddressSanitizer:stck-use-after-scope" while accessing the structure SIPSG_CONTACT_HDR_MEMORY_STR. Root Cause: The SBC was trying to access the structure SIPSG_CONTACT_HDR_MEMORY_STR outside the scope that is defined. Steps to Replicate: Run ASAN call flows. | The code is modified such that SIP_ERROR_INFO_STR structure is defined at the starting of function. Workaround: None. |
49 | SBX-114081 | SBX-114353 | 2 | PortFix SBX-114081: 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. |
50 | SBX-113592 | SBX-115071 | 2 | PortFix SBX-113592: The [ASAN]: AddressSanitizer: stack-buffer-overflow on address 0x7fb9742c6270 at pc 0x555db61239fb bp 0x7fb9742c5fa0 sp 0x7fb9742c5f98 in. Impact: There was a Stack Buffer overflow. Root Cause: The boundary check was missing before running a StrNCpyZ. Steps to Replicate: Run the ANSI-00 ISUP INVITE-BYE SIP-I codenomicon suite. | The code is modified to prevent the overflow. Workaround: Not applicable. |
51 | SBX-111460 | SBX-115067 | 2 | PortFix SBX-111460: The SBC does not offer 16K dtmf in a LM call when SDP is present in 2xx. Impact: The SBC is not sending 16k 2833 Payload type in initial offer towards ingress when SDP is present in 2xx during a Late media "convert" call. Root Cause: The answer received from the egress contained both 8000 and 16000 2833 Payload type and that resulted in the SBC wrongly assigning the 8000 PT value to 16000 as well while generating offer towards ingress. As a result, the 16000 PT get dropped by SIP stack. Steps to Replicate:
Test Result without Fix: 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 8000 and 16000 DTMF in this call flow. Workaround: None. |
52 | SBX-112092 | SBX-115036 | 2 | PortFix SBX-112092: The CallMediaStatus does not display the codec information of t38 image stream. Impact: The SBC does not display codec as "T.38" in callMediaStatus, when the Fax/Image stream is received as a non-core stream. Root Cause: The issue is caused because, by default, the SBC does not populate the codec information for Image streams, if an image is received as non-core stream. Steps to Replicate:
For Fax/Image stream, the codec should be updated as "T.38". | The code is modified so the codec as "T.38" for Image stream received as non-core stream for a call. Workaround: No workaround. |
53 | SBX-90156 | SBX-115030 | 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. |
54 | SBX-109692 | SBX-115037 | 2 | PortFix SBX-109692: The EMS fails to send authentication token while pushing licenses to the SBC. Impact: The EMS fails to send authentication token while pushing licenses to the SBC. Root Cause: To validate the license bundles, the CDB API's are used and in race condition, one of the CDB API is returning unexpected value and as a result, this issue is seen. Steps to Replicate:
Expected result: The license should get associated. Observed result: Receiving an error pop up saying "SBCRestManager - Received error code 400". | The code is modified to validate the license bundles instead of CDB API’s. Workaround: Not applicable. |
55 | SBX-114273 | SBX-114330 | 2 | Portfix SBX-114273: The SBC is sending unexpected UPDATE towards UAS in Support Preconditions Interworking on SIP CORE scenario. (tms927936). Impact: An additional UPDATE is seen towards the egress endpoint during egress precondition interworking scenario. Root Cause: An internal bug fix used to mitigate the egress SIP UPDATE is not being delivered to the endpoint during precondition transparency. This created a side effect of sending additional UPDATE towards egress during egress precondition interworking scenario. Steps to Replicate:
| While releasing the UPDATE, additional conditions have been added to correctly identify the scenario which needs UPDATE to be sent to the egress endpoint Workaround: Not applicable. |
56 | SBX-109059 | SBX-115039 | 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. |
57 | SBX-113096 | SBX-115042 | 2 | PortFix SBX-113096: The RTP inactivity timer kicks in during tone play. Impact: With a short RTP inactivity timeout configuration (five seconds in the test), the SBC generated RTP peer loss trap when the ringback tone was being played during the call setup procedure (after the SBC receiving 180 and before the final 200 OK for the INVITE completed the call setup). Root Cause: The RTP peer loss detection was enabled on the media flow in media plane while ringback tone was being played. Steps to Replicate: Procedure: Configure "media peer inactivity timeout" value in the "Packet Service Profile" entry in PSX to five seconds.
Observed at Step 4, when tone was being played RTP inactivity was detected and the call was torn down. | Disable the media flow RTP peer loss detection when the ringback tone is played. Workaround: No workaround. |
58 | SBX-112547 | SBX-112954 | 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. |
59 | SBX-115370 | SBX-115517 | 2 | PortFix SBX-115370: The SBC is unable to generate UPDATE message towards the UAS for the 183 dialog-3, during the call forwarding scenario. Impact: The SBC is unable to generate the Update towards the ingress side during a Prack 200 OK delay scenario. Root Cause: The Update is queued in a 200 OK delay Prack scenario. The queue Update is never released. Steps to Replicate:
| The code is modified to release the queued Update in the 200 OK Prack Delay Scenario. Workaround: None |
60 | SBX-111176 | SBX-115051 | 2 | PortFix SBX-111176: No media was seen during tone play with the LRBT when the DPM for tone is changed from inactive to sendrecv from an ingress peer with an UPDATE. Impact: An initial INVITE is received with the c=0.0.0.0 connection media IP and datapathmode a=inactive in the SDP. With an LRBT enabled, when the client/ingress endpoint sends an Update with non-zero c=<valid IP> and datapathmode a=sendrecv, the remote media IP maintained in the ingress call leg was being overwritten with zero IP though a valid non-zero IP was received in Update. Without a valid remote IP, tone packets will not be generated by the SBC. Root Cause: After the UPDATE is received, the new non-zero remote IP is updated to the circuit information maintained on the ingress call leg as part of a modify request in tone context. However, an additional allocation request was also triggered to start the tone play with the old zero remoteIp 0.0.0.0 that was overwriting the valid remoteIp and tone play was disabled.As a result, the datapathmode has changed to sendrecv and valid remoteIP is received with the latest UPDATE from a remote endpoint. Steps to Replicate:Run the following call flow to replicate the issue: | The code is modified to prevent an existing non-zero valid remoteIp saved in call leg circuit info from being overwritten by zero remote IP during a tone play. Workaround: None. |
61 | SBX-114728 | SBX-115065 | 2 | PortFix SBX-114728: The SBC did not send Terminating IOI value in P-Charging-Vector header for 183, 180, BYE, and 200 OK. Impact: The SBC was not sending the Terminating IOI value in P-Charging-Vector header for 183, 180, 200 OK, and BYE toward the ingress. Root Cause: The SBC should add term-ioi in PCV header when the term-ioi is configured, irrespective of whether the operator Id is configured or not. However, due to recent code changes, this functionality was broken and when the operator Id is not configured the SBC was not copying term-ioi value in PCV properly. Steps to Replicate: Run the SBC configuration:
The customer script should be configured with DefaultDialTone and DefaultRingBackTone profiles. Run the following call:
| The code is modified to send term-ioi when it is configured without having dependency on the operator Id. Workaround: None. |
62 | SBX-111609 | SBX-115028 | 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. |
63 | SBX-112363 | SBX-115033 | 2 | PortFix SBX-112363: [ASAN]: runtime error: member access within null pointer of type 'struct CC_SG_PROGRESS_UIND_MSG_STR' in CcSgProgressHndl. Impact: Run a basic Update CallModification scenario. After the call was completed, the ASAN runtime error is observed in the system logs indicating that the code is taking the address of a field within a NULL pointer. Root Cause: When a Call Progress message is received from the network, the code was taking the address of a field within the NULL pointer. Steps to Replicate: Run an update CallModification scenario. | The code is modified to validate that the pointer is not null taking the address of a field within the pointer. Workaround: No workaround. |
64 | SBX-113839 | SBX-114138 | 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. |
65 | SBX-112163 | SBX-115054 | 2 | PortFix SBX-112163: [ASAN]: AddressSanitizer: stack-use-after-scope on address 0x7f7e3d1a4510 at pc 0x55cec34efba0 bp 0x7f7e3d1948a0 sp 0x7f7e3d194898 in SipsPSFormatErrorInfoHeaderCmd. Impact: ASAN detected "AddressSanitizer:stck-use-after-scope" while accessing the structure SIP_ERROR_INFO_STR. Root Cause: The SBC was trying to access the structure SIP_ERROR_INFO_STR outside the scope that is defined. Steps to Replicate: Run a call with initial INVITE having no contact header. | The code is modified such that SIP_ERROR_INFO_STR structure is defined at the starting of the SipsTSParseMsgCmd function. Workaround: None. |
66 | SBX-114373 | SBX-115062 | 2 | PortFix SBX-114373: The S-SBC is generating an extra UPDATE towards UAC for 3rd 183 dialog during downstream forking scenario Impact: An additional UPDATE was seen towards ingress endpoint during downstream forking with multiple dialog scenario. Root Cause: When simultaneous 183 messages from different dialog is received, the SBC queues the second 183 message. This is released after the completion of precondition or offer-answer negotiation for current dialog. Due to a previous fix, there were changes introduced in this framework that causes the early release of 183 message, thereby inducing issues in the OA FSM. Steps to Replicate:
The call should be established. | The code is modified so the 183 message is released correctly before releasing the second 183 message. Workaround: None. |
67 | SBX-110891 | SBX-115027 | 2 | PortFix SBX-110891: The 'gzip' should run with a nice value of >15 for lesser resource consumption. Impact: The SBC performance monitoring tools like top2 at times take a large percentage of CPU core, there by reducing the total available CPU resources for management activities on the SBC. Root Cause: The gzip, that compress files, currently runs periodically without any Linux value configured. Steps to Replicate: Install the fix build and ensure top2 gzip processes are running with a correct value of 15 using top2 command. | The code is modified to reduce the priority of processes compared to other management processes on the SBC. Workaround: None. |
68 | SBX-110324 | SBX-115049 | 2 | PortFix SBX-110324: The SBC fails to set up a DTLS-SRTP call if dtlsProfile --> CertName is configured with a local-internal certificate. The call works correctly if a "local" certificate is used. Impact: When local-internal type certificate is configured from the EMA, the certificate is updated in the SAM process correctly but not updated in the PRS process. As a result, the DTLS SRTP calls are unable to get certificate and the call fails. Root Cause: When local-internal type certificate is configured from the EMA, the certificate is updated in the SAM process correctly but not updated in the PRS process. As a result, the DTLS SRTP calls are unable to get certificate and the call fails. Steps to Replicate: Configure the local-Internal type certificate from EMA and make DTLS_SRTP call. DTLS_SRTP connection will fail because of certificate not being available. | The code is modified to read the certData from DB and update x509 when pki certificate state is enabled. Workaround: After configuring a certificate from the EMA, perform an SBC restart. This restores the certificate from DB and the DTLS_SRTP call is successful. |
69 | SBX-108416 | SBX-115059 | 2 | PortFix SBX-108416: Importing of local and remote certificates on the Cloud SBC platforms requires .der and .p12 to be placed on both the active and standby nodes. This is not the case for HW and VMware SBC platforms. Impact: On cloud 1:1 HA, importing of TLS certificate failed on the STANDBY. Root Cause: Importing of local and remote certificates on the Cloud SBC platforms requires .der and .p12 to be placed on both active and standby nodes. This is not the case for HW and VMWare SBC platforms. Steps to Replicate:
Expected Result:
| The code is modified to update the HW and VMware SBC platforms similar to H/W for cloud 1:1 HA and N:1. Workaround: Configure the certificate on both instances. |
70 | SBX-114618 | SBX-114960 | 2 | PortFix SBX-114618: The SBC did not send Terminating IOI value in P-Charging-Vector header for BYE message and STOP CDR record (69.30 field). Impact: The SBC did not send Terminating IOI value in P-Charging-Vector header for BYE message Root Cause: Upon receiving a 200 OK, the SBC is not saving term-ioi, there by causing this issue. Steps to Replicate:
| The code is modified to save the term ioi in a 200 OK Response. Workaround: we can try adding missing term-ioi by SMM. |
71 | SBX-110245 | SBX-115060 | 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. |
72 | SBX-109808 | SBX-115073 | 2 | PortFix SBX-109808: [ASAN] SBC: Scm process gave ERROR: AddressSanitizer: heap-use-after-free on address 0x6150000d6488 at pc 0x5585e065bdec bp 0x7f3900ad0e10 sp 0x7f3900ad0e08 on the SBC standby. Impact: The ASAN error is coming on the standby SBC when the standby is going down anyway. Root Cause: Packet collector is checking requests queue when system is shutting down. Steps to Replicate: Run the same scenario again and check that ASAN error is not seen now on standby MRFP | The code is modified to not check the requests queue when system is going down. Workaround: None. |
73 | SBX-114184 | SBX-114519 | 3 | PortFix SBX-114184: The SMM store/regstore/regsub SMM operations add an extra CRLF if the operation is executed against a header that contains a SIP URI. Impact: The SMM inserted double EOL after using regex for header value operations. Root Cause: After modifying the header value, the SMM logics did not strip off EOL. As resulted when it try to format back, additional EOL was inserted. Steps to Replicate: An incoming message has invalid from header syntax | The code is modified to address the issue. Workaround: No workaround. |
74 | SBX-112706 | SBX-113554 | 3 | PortFix SBX-112706: The SBC populates the NOTIFY XML body using pre-SMM INVITE PDU for outgoing messages. Impact: The SBC was using pre-SMM outbound INVITE PDU for populating the XML body of NOTIFY for the Call Notification feature in the XML Metadata body of the SIPREC INVITE. Root Cause: The SBC considers pre-SMM outbound INVITE PDU instead of the post-SMM PDU for SIPREC and call Notification features. Steps to Replicate:
Observation: The SBC should use post-SMM outbound INVITE PDU for populating XML body of NOTIFY for Call Notification feature (and for SIPREC INVITE). | The code is modified to consider the post-SMM outbound INVITE PDU for populating the XML body of NOTIFY for the Call Notification feature and SIPREC. Workaround: Not applicable. |
75 | SBX-108326 | SBX-115047 | 2 | PortFix SBX-108326: The SBC sends ACK with "a=inactive" when PRACK is enabled only on ingress leg and an outgoing INVITE towards the egress leg that does not have offer, and 18x towards ingress that has offer based on the configuration flag "Sdp100relIwkForPrack" scenario. Impact: The SBC is not triggering a re-INVITE after sending ACK with "a=inactive" on the egress side for an asymmetric PRACK interworking scenario. Root Cause: Since the SBC creates the offer SDP internally, 18x is sent with "a=inactive" on the ingress side. The SBC sets the datapathmode as inactive on the egress side. So even after receiving a 200 OK with "a=sendrecv". it sends ACK with "a=inactive". Steps to Replicate:
| The code is modified so the SBC creates offer and sends in 18x on the ingress side. On the egress side, after receiving 200 OK with "a=sendrecv", So a fix is given to send a re-invite on egress side with "a=sendrecv". Workaround: Not applicable. |
76 | SBX-115476 | 2 | The SBC fails to send ACK in the Re-invite call flow when E2E ACK and E2E re-Invite flags are enabled. Impact: E2eAck not working after Invite with a replace. Root Cause: Currently, the E2eAck configuration is applicable only on egress leg. After receiving an Invite with replace (ingress legC), legC does not support e2eAck. Steps to Replicate:
| The code is modified to address the issue. Workaround: Disable the e2eAck. |
77 | SBX-116421 | 2 | flexiblePolicyAdapterProfile breaks transparency in GW-GW scenarios. Impact: A SMM with action flexiblePolicy assigned at the ingress trunk group may break SIP header transparency for SIP-GW-GW-SIP calls. SIP headers are not sent transparently to the egress SIP peer. Root Cause: The SBC is unable to pack and send flexible routing headers to the GW-GW call leg. As a result, all SIP headers where the transparency is enabled, are not relayed. Steps to Replicate: Enable the flexiblePolicyAdapterProfile and enable either "Unknown Header transparency" in the egress IP signaling profile or configure the egress transparencyProfile with transparency for all headers. Make a SIP-GW-GW-SIP call and observe that the headers are not relayed. | The code is modified to ignore when packing the transparency content. Workaround: Disable the SMM flexible routing. |
78 | SBX-116551 | 2 | Memory leak in the PES process. Impact: The PES Process has leaking memory. Root Cause: In Postgres searching result object was not properly cleared for TRUNK. Steps to Replicate: To reproduce the issue, attempt to make call loads that Trunkgroup has ZZPROFILE assigned. To test the fix, do the same. | The code iis modified to clear the search result object. Workaround: Use a Trunkgroup without ZZPROFILE should help. |
79 | SBX-113053 | 2 | There was a race condition when the 183 and 200 OK (INVITE) are received simultaneously. The 200 OK is not relayed to the other side. Impact: After a 200 OK (UPDATE) received followed immediately by receipt of 183 Session progress, the subsequent 200 OK (INVITE) containing P-Early-Media header is queued indefinitely at egress when downstreamForking is enabled and earlyMedia forkingBehaviour is pemPriority. Root Cause: There was a race condition between internal processing of the 200 OK for an UPDATE and a received 183 Session Progress. Steps to Replicate: Set up the Egress SIP trunk group has downstreamForking is enabled and earlyMedia forkingBehaviour is pemPriority. Make a call so that egress signaling is as follows: | The code is modified to eliminate the race condition. Workaround: None. |
80 | SBX-112483 | 2 | After call transfer 7000 fails to send media stream to new term resulting in dead air to term end - ingress in fax mode. Impact: If the call is in fax mode and if a Re-INV is received with new media address then the SBC is not sending RTP to the new media address. Instead, it is sending RTP to the old media address. Root Cause: When the call is in fax mode and if the SBC receives a Re-INV from the peer, then it responds locally with 200 OK SDP to the peer. The current logic was not checking for any change in the media address received in the re-INVITE. Hence, the SBC was sending RTP to the old media address. Steps to Replicate:
| The code is modified so that when the call is in FAX mode and if any re-INVITE is received from the peer, then the SBC compares the media addresses. If there is any change in it, then it starts a modify offer-answer cycle to get this new media address updated. Workaround: None. |
81 | SBX-114948 | 2 | Post 9.2.3 upgrade, the T.38 has faxing issues. Impact: Customer experienced some fax failures after moving to 9.2 from 7.2 release. Root Cause: Inspection of Traces from field supplied by customer shows this file has 3 DCS and TCF packet captures, and the packets are large with a payload of 176 bytes of V.29-9600. The root cause is that T.38 stack gets stuck in generating a very long TCF instead of 1.5 seconds long, resulting in a fax failure. Steps to Replicate: For test steps refer to unit test for this JIRA and test files loaded in the JIRA. | The code is modified to address the issue. Workaround: Increase the Maxdatagram size to 72 instead of 176. This was tried by customer and found to work. However, this setting is on the peer T.38 device and not always available. |
82 | SBX-114352 | 2 | One way audio when a call starts as a=recvonly and RTP NAT learning completes before the call is switched to a=sendrecv. This happens with RTP coming from port number 5004 or 5006 only. Impact: The RTP NAT learning completes while the call is in a=recvonly mode (SBC is in receive-only mode). Once the called party switches the call to a=sendrecv mode, the XRM stays in rcv-only instead of switching to duplex. This is why the SBC does not send any RTP packets towards the endpoint that is behind NAPT and the endpoint doesn't receive any audio. Root Cause: Port 5004 is defined as LOOPBACK_IP_PORT in the SBC and being used for NAPT. When RTP is coming on port 5004, NAPT re-learning will not be completed. If NRMA is waiting for NAPT re-learning to complete before changing rtpMode to duplex, then one way audio occurs. Steps to Replicate: Configure the SBC as:
| The code is modified so that when RTP is coming on port 5004, the NAPT re-learning is completed and the rtpMode updates as expected. Workaround:Change the endpoint configuration and/or the NAT device configuration so that the SBC receives RTP packets from the UDP port numbers other than 5004 and 5006. |
83 | SBX-112119 | 2 | The SBC is timing out when creating a route through the EMA. Impact: The SBC is timing out when creating a route through the EMA Root Cause: While creating route current system is fetching all the created routes. Due to this issue, the timeout issue is caused as a result. Steps to Replicate: Getting an "Error Saving From Details, TimeoutError: timeout has occurred" while creating a route through the EMA. | The code is modified to address the issue. Workaround: No workaround. |
84 | SBX-114722 | 2 | There was a SCM Process core in SipSgIsEgressPrecondUpdateEnabled. Impact: There was a SCM Process core in SipSgIsEgressPrecondUpdateEnabled. The core occurs when the SBC receives a NULL to function SipSgIsEgressPrecondUpdateEnabled(). Root Cause: The core occurs when the SBC receives a NULL to SipSgIsEgressPrecondUpdateEnabled(pvApplHandle=0x0) and inside that function, the SBC dereferences the NULL pointer. Steps to Replicate: The steps cannot be reproduced. | The code is modified to address the issue. Workaround: None. |
85 | SBX-114725 | 2 | The MIME part headers do not pass over a GW-GW with body transparency. Impact: In the GW-GW call when the PIDF MIME body parts are passed over a GW-GW with the SBC body transparency enabled, the MIME part headers other than Content-Type are not passed. Root Cause: The code for packing unknown headers in first gateway and code for unpacking it at second gateway was absent. Steps to Replicate:
| The code is modified to address the issue. Workaround: No workaround. |
86 | SBX-114020 | 2 | A core dump occurred on a Standby SBC 5210 after a healthcheck failure - ENM Deadlock - while attempting register with the EMS. Impact: Running multiple registers and deregisters of a high availability SBC pair, in a rare case can cause the standby SBC to core dump and restart. Root Cause: The code on the standby SBC for processing the delete of an SNMP trap target can potentially cause a core dump. Steps to Replicate: Internal code debugging mechanisms were used to verify that create and delete of SNMP trap target processing code is bypassed on the standby SBC. | The code is modified to bypass the processing on a standby SBC. Workaround: None. |
87 | SBX-116431 | 2 | The events in the NRMA logging are not printed to the TRC. Impact: Some NRMA call trace log entries are missing. Root Cause: The complete set of NRMA call trace log entries are only generated if the oam eventLog typeAdmin debug filterLevel is set to info or the NRMA subsystem has infoLogState enabled. Steps to Replicate:
| The code is modified to decouple the generation of NRMA call trace logs from the filtering of debug logs. Workaround: None. |
88 | SBX-115002 | 2 | There is a SIPSG sync failure after both nodes update to 9.2. Impact: There is a SIPSG sync failure with this message: Root Cause: The SIPSG is failing to sync Registration data. The failure is due to the fact that the buffer that is allocated for mirroring the Registration data is not large enough. This is because the structures have grown over time and no longer fit in the allocated memory. Steps to Replicate: Enable this configuration: | Increase the amount of memory for the message that is used for mirroring the Registration data to address the issue. Workaround: It may be possible to avoid this issue by disabling the following configuration parameter: |
89 | SBX-116728 | 2 | Failed to create LIF when applications are starting up. Impact: Failed to create a LIF when an application starting up. Root Cause: The LIF name, IPIF_pkt1b, was used in 2 different address contexts which is not allowed. Steps to Replicate: 1. Configure two LIFs with the same name in two different address context. | The code is modified to validate LIF's name against assigned address context and log a detailed major DBG message when finding the bad configuration. Workaround: No workaround. |
90 | SBX-116747 | 2 | No audio in STUN/ICE/DTLS calls and the SBC ignoring DTLS Client Hello requests Impact: There is no audio in STUN/ICE/DTLS calls. Root Cause: During the process of BIND response message, ICE FSM did not verify the remote IP address against stored nominated candidate's IP address. So when the SBC received the response message from a different remote entity other than the nominated candidate, ICE FSM overwrites RTP candidate and notified NRMA with the different remote IP and caused the issue. Steps to Replicate:
| The code is modified to check the remote IP address in the response message. If the remote IP address is different from stored nominated candidate's IP address, log a debug message and drop the response. Workaround: N/A |
91 | SBX-113807 | 3 | The CIN-5400-PJ Application is restarting every 30 minutes. Impact: The CIN-5400-PJ Application is restarting every 30 minutes. Root Cause: The CPX process does not respond within 180 seconds to the confd process because the CPX process received a malformed response from the TRM process on a show addressContext zone trunkGroupStatus request. Steps to Replicate: Perform an snmpwalk on addressContext zone trunkGroupStatus | If the TRM response has a cpxIndex of 0, respond to confd immediately with an error to address the issue. Workaround: Do not run an SNMP getnextrequest on addressContext zone trunkGroupStatus |
92 | SBX-112808 | 3 | Serial Number display issue in the EMA, Azure Impact: In a virtual cloud HA setup, the Serial Number displayed in EMA is incorrect. Root Cause: In a virtual cloud HA setup, the EMA was using the serial number of the standby node instead of active node and the same was displayed in the UI. Steps to Replicate: In a virtual cloud HA setup, log in to the EMA. The serial number should be displayed. | The code is modified to retrieve the serial number of the active instead of standby node. Workaround: None. |
93 | SBX-112252 | 3 | The Verstat parameter is coming before the CPC in PAI header that is not in lexicographical order. Impact: In the SIP P-Asserted-Identity header, in the TEL URI, the verstat parameter appears prior to the CPC parameter. Root Cause: Order of parameters in P-Asserted-Identity header was not in lexicographical order. Steps to Replicate: Make a SIP-SIP call. Egress SIP trunk is configured with JJ9030 interworking profile flavor jj9030. IP Signaling profile for egress trunk has "Include CPC Information" checked. IP Signaling profile for egress trunk has "Include Privacy" checked. | The code is modified so the CPC appears first. Workaround: None. |
94 | SBX-113355 | 3 | The SBC does not change the status of the certificate from "SUCCESS" to "FAILED" when the certificate expires. Impact: The SBC CLI and EMA display the status of the certificate as "SUCCESS" for certificates that expired and are no longer valid. Root Cause: The SBC did not update the certificate status to "FAILED" although the SBC detected the certificate expiry. Steps to Replicate:
| The code is modified so that the status of expired certificates is updated from "SUCCESS" to "FAILED" upon a certificate expiry. In addition to the code changes, the "expired" status is added to the pki > certificate > status statistic in the Security table on the page Show Table System. Workaround: No workaround. |
95 | SBX-114944 | 3 | The SBC does not add "term-ioi" to the PCV of the SIP 503 response when the SIP 503 response is caused by the TG being blocked. Impact: The SBC does not add the "term-ioi" parameter to the PCV header of the SIP 503 response when the SIP 503 response is caused by the ingress TG being configured with "blockDirection: incoming". Root Cause: The code that would update the term-ioi parameter in case the TG is blocked was missing. Steps to Replicate:
| The code is modified to update the term-ioi in a call control block from locally configured sipJJ9030InterworkingProfile. Workaround: No workaround. |
96 | SBX-115603 | 3 | There was a SCM process coredump in SipSgRecFormSipRecSDP. Impact: The SCM process core in SIPREC code after a switchover. Root Cause: The SIPREC code is attempting to dereference a NULL pointer. Steps to Replicate: The steps cannot be reproduced. | The code is modified to prevent the attempt to dereference a NULL pointer. Workaround: There is currently no workaround. |
97 | SBX-113733 | 3 | The SBC SWe with larger disks get stuck at boot after reset or powercycle. Impact: When an SBC on SWe is powered off, without soft shutdown, on reboot system goes into emergency mode and waits for user input on console. On the VMWare, it hangs forever. Root Cause: On reboot after unclean shutdown, the systemd-root-fsck service runs to chec root file system. When the root file system is large (>200GB), it takes more than 90 seconds (default service start time) to start file system check and subsequent devices' file system checks mentioned in /etc/fstab fail pushing the system into emergency mode. Steps to Replicate:
| The code is modified to remove the console=ttyS0 from kernel command line. Workaround: On VMware on reboot, enter into the grub menu and remove console==ttyS0 option from the command line. |
98 | SBX-114540 | 3 | The checkDrbdMountStatus.sh was still in the crontab. Impact: On the SBC startup or switchover, crontab is erroneously updated to contain a call to checkDrbdMountStatus.sh. Root Cause: The legacy call to checkDrbdMountStatus.sh is no longer needed in cron. Steps to Replicate: Start the SBC. At the linux prompt, run command crontab -l to check crontab contents. | The code is modified to no longer add checkDrbdMountStatus.sh. Workaround: None. |
99 | SBX-113564 | 3 | Incomplete data is shown in the "DNS Entry Data Status List" in the EMA. Impact: Incomplete data is shown in the "DNS Entry Data Status List" in the EMA. Root Cause: The data type of key 2 needed to retrieve DNS data entry status from hash is incorrect. Steps to Replicate:
| The code is modified to 1 byte. Workaround: No workaround. |
100 | SBX-114376 | 3 | The SBC does not follow the Q.1912.5 spec for privacy of the display name. Impact: When trunk group variantType is q1912, the SBC includes display name in SIP From: header, even though privacy is enforced. The display name should be set to "Anonymous" in this scenario. Root Cause: The display name in the From: header is mapped from the P-Asserted-Identity: header, rather than being set to "Anonymous". Steps to Replicate:
| The code is modified to set the display name in From: to "Anonymous" when privacy is enforced for variantType q1912. When the variantType is uk and privacy is enforced, the display name in From: is not included. Workaround: A SMM rule may be configured to anonymize the From: header. |
101 | SBX-111650 | 3 | The SBC fails to write SMM values into the CDR when STI profile is attached. Impact: When STI is enabled and attached, we are not writing SMM details to the CDR. Root Cause: SMM fields are impacted when STI profile is enabled as part of SipSgFillStiCdrData -> SipSgSendAcctUpdateToCc -> SipSgFillInProtSpecificString -> SipSgFillSmmCdrString, in sipsgIncomingCallNfy. The SBC fails to write SMM values as ccbPtr→commonFsmCb.ccHndl, and after the fetching values of SMM, free up the SMM-CDR memory and thus we fail to update the SMM data when the normal update happens through the NrmaAllocRpy. Steps to Replicate: Run a normal STI call with SMM rules applied. | The code is modified to control SipSgSendAcctUpdateToCc. Workaround: None. |
102 | SBX-115340 | 3 | FAILURES and LINK FAILURES counts increase by two from portMonitorStatus command in V09. Impact: After a switchover, the failure counts reported in by portMonitorStatus command are doubled. Root Cause: The portMonitorStatus was being registered twice with the CPX process. Steps to Replicate:
| The code is modified to detect and reject duplicate registrations. Workaround: None. |
103 | SBX-108952 | 3 | Making IP interface OOS/disabled stops sending traffic over interface in other AC. Impact: For the SBC SWe running on VMware platform with X710 SRIO NICs, create two IP interface groups in two different address contexts with different VLANs but with the same packet port. As a result, this makes two different VLAN interfaces from the same packet port. When we make an IP interface OOS/disabled in one address context, the SBC packet port was unreachable in another address context. Root Cause: When we make an IP interface OOS/disabled in one address context, the SBC packet port was unreachable in another address context because the packet port started getting untagged (stripped VLAN) packets. The problem is unique to VMware host X710 NIC (i40en) driver version 1.8.6 and this problem is not found in driver versions 1.10.9.0 or above. Steps to Replicate: Set up: Upgrade X710 NIC driver 'i40en' version to 1.10.9.0 and firmware 7.20 on VMware host server.
| The code is modified in the SBC NP code for compatibility with the newer host drivers, since the newer host drivers do not allow the dissimilar number of Rx and Tx queues. Workaround: Make IP interfaces OOS/disabled in all address context of the packet port and then enable the required IP interface. |
104 | SBX-114300 | 2 | No trap is generated when the Max System Call Limit is set. Impact: No trap is generated when the Max System Call Limit is set. Root Cause: The "Max System Call Limit Set/Clear" notifications referred to incorrect trap definitions. Steps to Replicate: Verify the traps are generated for the following CLI commands once the max system call limit is reached. | The code is modified to generate traps for Max System Call Limit Set/Clear. Workaround: None. |
105 | SBX-111177 | 2 | The SBC wrongly interprets RTCP packets as RTP when using the 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, the 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 the 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 has also been updated 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. |
106 | SBX-113704 | 2 | There was a PRS core dump. Impact: The standby PRS cored in the XRM. Root Cause: There were some XRESs stuck in LIF's deferred active list that caused standby XRM to access NUL pointer when processing redundant modify request. Steps to Replicate: Run regular regression tests. | The code is modified to validate XRES's state and remove it from LIF's deferred list if LIF is already in-service, then continue to process redundant modify request. Workaround: None. |
107 | SBX-115496 | 2 | An NP error occurs during a 9.2.3R2 test: .IPM: *NP 1 error counter badRidCb incremented: cnt 1624898 last error 0x1a15 Impact: NP badRidCb error counts continue to increase. Root Cause: In this call flow, NAPT learning is enabled on ingress leg. But the RTP flow mode on egress leg was already set to DUPLEX before ingress leg has finished NAPT learning to enable RID. So egress started to send packets to ingress RID while NAPT learning and caused badRidCb error. Steps to Replicate:
| The code is modified to address the issue. Workaround: None. |
108 | SBX-116532 | 2 | The DSP activation/deactivation errors in the SBC 7000. Impact: Under certain conditions of transcode overload testing on SBC 7000 intermittent DSP activation/deactivation failures were observed. Root Cause: The size of netlink socket buffer that is used for communication between DSP H/W subsystem and the DSP resource manager process was found to be insufficient for handling intermittent bursts messages. Steps to Replicate: The steps cannot be reproduced. | The code is modified to handle increased burst of messages from the H/W subsystem during intermittent spikes in incoming calls. Workaround: None. |
109 | SBX-112597 | 2 | I-SBC: "runtime error: shift exponent 48 is too large for 32-bit type 'int' " in the np.log. Impact: The ASAN builds reported integer overflow error in calculation of standard deviation for jitter for RTP packets. Root Cause: Integer overflow during standard deviation calculation. Steps to Replicate: The problem can be reproduced by streaming RTP stream with high jitter. | The code is modified to prevent an integer overflow during standard deviation calculation. Workaround: No workaround is available. This metric, however is not written into CDRs. It is currently only being used by Ribbon Protect. |
110 | SBX-114446 | 2 | The SBC is not performing more routes request for Ip signaling peer group 2 in a 3xx scenario. Impact: When configuring multiple routes for the 3xx dip, the SBC does not process any routes after the first set of routes Root Cause: When configuring multiple routes, the SBC has a counter to determine if all routes are fetched. Steps to Replicate:
The SBC should fetch all routes for the 3xx dip. | The code is modified to reset the counter once all routes are fetched from the PSX to address the issue. Workaround: None. |
111 | SBX-116685 | 2 | No space left on the instance, /var/log 100%. Impact: When VMware/KVM deployed the SBC is provisioned with an additional log partition, this extra partition is not being monitored for space correctly and can fill up leading to ssh failing. In all platforms, a misbehaving process could write to the /var/log files leading to unexpected large content in /var/log partition. Root Cause: As bug in the code meant the size of the log partition was only check for cloud deployments and not for virtualized deployments in VMware/KVM, this was now been corrected. Steps to Replicate: Start a process to continually write to syslog very quickly and leave it running. This will eventually fill up the disk space. The SBC should generate traps for disk filling up and should automatically stop the application. | The code is modified to correctly monitor log partition in VMware/KVM deployments and the SBC application is shutdown if the log or root partition reaches 95% usage. The code is also modified to rotate the /var/log files based on a 50M file size and the size is checked every hour. Workaround: The log rotation configuration could be updated to rotate based on a 50M size rather than the previous daily or weekly time based rotation that was being used. |
112 | SBX-117020 | 2 | CDR mismatch is happening with respect to Ingress codecParams1 and Egress codecParams1 Impact: The CDR record of EVS codec is incorrectly set for AMR-WB io mode-set. Root Cause: The EVS codec AMRWB-IO mode-set initialization was incorrectly done due to recent changes done by SBX-105793. Steps to Replicate: Test Case Specific Configuration: | The AMRWB-IO mode-set initialization is set correctly Workaround: Not applicable |
113 | SBX-115322 | 2 | DFW3-CUSBC-28 - Sip Sig Ports Down Impact: Multiple sip sigports are configured with same IP address but different UDP ports. SIP sigPorts went down after one of them was deleted. Root Cause: In NRS, we use a refCount to manage multiple signaling ports with the same IP address. The logical binding and CpsLAddrCreate() is invoked when refCount equals 0, i.e. the time when first logical signaling address is added. If user deletes the first logical signaling address, NRS removes it from related hash table. But it's ID is still being referenced in binding structure. Then if user adds another signaling address in the group, a zero CPS laddr handle will be assigned to the new logical address which will pass wrong ACL handle when adding or deleting ACL rules and in turn caused logical address failure. Steps to Replicate: | Two fixes added Workaround: no workaround |
The following Severity 1 issues are resolved in this release:
Severity 1 Resolved Issues
Issue ID | Sev | Problem Description | Resolution |
---|---|---|---|
SBX-112374 | SBX-114945 | 1 | Portfix SBX-112374: The SBC is intermittently stripping the last 'm=' line from an egress INVITE. Impact: When "m=application" line is present in the SDP present in an incoming INVITE, and at the egress, the SBC does a DNS lookup. As a result, the SBC strips off the lines after m =application line. Root Cause: As part of the fix introduced by a bug in 8.2.1, the NULL termination was added after the m=application line. This is causing the SDP to be truncated after the m=application line. Steps to Replicate:
| The code is modified to address the issue. Workaround: Use an actual IP address in IP peer instead of a FQDN. |
SBX-113238 | SBX-114963 | 1 | PortFix SBX-113238: An incorrect PAI CPC position. Impact: When the SBC sends an egress INVITE with a PAI header, and presentation is allowed, the PAI CPC is put between the username and hostname of SIP URI. However, when presentation is restricted, it is present after the hostname in the SIP URI. Root Cause: When a presentation is restricted, the code is checking the "Disable 2806 compliance" configuration and if that was enabled, it is populating the CPC parameter in PAI after the SIP hostname. Steps to Replicate:
| The code is modified so that if the cpcInterworkingForNNI is enabled on the trunk group, the CPC parameter is populated between the username and hostname of SIP URI in PAI header, irrespective of the "Disable 2806 compliance" setting. Workaround: If "Disable 2806 compliance" is set to disabled, the issue is not present. However, if "Disable 2806 compliance" is required to be enabled, there is no workaround. |
SBX-113702 | SBX-114947 | 1 | PortFix SBX-113702: Accounting Logs are not escaping special characters in calling name fields. Impact: Accounting Logs not escaping special characters in calling name fields. Root Cause: The SBC did not escape the non-alpha numeric character in the calling name, leading to incorrect "called asserted identity" field. Steps to Replicate: Make a simple SIP-SIP call and validate the CDR subfield 60 - Called Asserted Identity display name comes as "%22NORTH SHORE RD%2CLLC%the 22". Called Asserted Identity [sf:60] "NORTH SHORE RD, LLC" | The code is modified to escape non-alpha numeric characters in the calling name. Workaround: None. |
SBX-113986 | SBX-114956 | 1 | PortFix SBX-113986: The User-to-User parameter is duplicated in the Refer-To header. Impact: When a REFER message is relayed, if transparency for all headers is active, URI parameters appear twice in the Refer-To header. Root Cause: Interaction between transparency of all headers and relay of Refer-To header. Steps to Replicate:
| The code is modified so that URI parameters only appear once. Workaround: An SMM rule workaround is possible, if the Refer-To is relayed transparently. |
SBX-114393 | SBX-114596 | 1 | PortFix SBX-114393: The TLS Session ID is listed as all zeros on the new 9.2.2R3 code. Impact: The TLS Session IDs were not printed in the TLS Session Status command output. Root Cause: The code was commented out in latest releases. Steps to Replicate: Execute the TLS Session Status command with active TLS calls on the SBC. When the command is executed, the session Ids are printed as zero instead of valid session Ids. | The code is modified to print Session IDs in the TLS Session Status command output. Workaround: None. |
SBX-114426 | SBX-115189 | 1 | PortFix SBX-114426: There was a Standby SBC core dump on the CE_2N_Comp_SamP. Impact: Memory corruption may occur in the SAM process if an IP Peer is deleted and then added back into a different zone. Root Cause: The root cause is that the code that handles adding a new configured IP Peer may write into memory that has already been freed. Steps to Replicate: The root cause of this bug was found by code inspection. There is a race condition that must occur for this bug to be exposed. To attempt to reproduce:
| The code is modified to prevent writing into an IP Peer structure which is freed. Workaround: Avoid deleting an IP Peer and adding the exact same IP Peer back in a different zone. |
SBX-114831 | 1 | No fallback to G711 for a fax call flow upon receipt of a 488 response. Impact: The SBC is not sending fax fallback re-INVITE upon receiving 488 error response (for T38 re-INVITE) from UAS. Root Cause: New code had been introduced in 8.02 of the SBC to address a few customer requirements related to the flag - bIsOlineSame. None of those customer scenarios had any use cases involving Gw-Gw scenarios. There is a miss in the test coverage as a result. This new code has a missing initialization of one field that was being used for Gw-Gw scenarios, which is causing this issue. Steps to Replicate:
The SBC2 is failing to send a fax fall back re-INVITE to UAS. | The code is modified to address the issue. Workaround: None. |
SBX-114842 | 1 | Microsoft Teams has a Shared Line/Hold issue. Impact: The SBC fails to send ACK after the mix of INVITE replaces and refer (Microsoft Teams Shared line/hold) feature. Root Cause: After receiving a 200 OK from the refer INVITE, the SBC fails to release tone announcement. Steps to Replicate: The steps cannot be reproduced. | The code is modified to correctly release the tone resource. Workaround: Disable the tone as an announcement. |
SBX-114367 | SBX-114964 | 1 | PortFix SBX-114367: Unable to delete an Announcement Package Element. Impact: Deleting an element within an announcement package does not work. Root Cause: The code for handling the announcement package element delete command was incorrect. Steps to Replicate: Perform following configuration changes through the CLI:
| The code is modified to handle delete command for announcement package element correctly. Workaround: Delete the announcement package, and then re-create it without the required element. |
The following Severity 2-4 issues are resolved in this release:
Severity 2-4 Resolved Issues
Issue ID | Sev | Problem Description | Resolution |
---|---|---|---|
SBX-114303 | SBX-114978 | 2 | PortFix SBX-114303: 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. |
SBX-110918 | SBX-115120 | 2 | PortFix SBX-110918: The SBC 7000 is showing DSP insertion with the reason DTMF, but the DTMF should not be displayed. Impact: The following fields contain incorrect values when running a correct amount of calls (20,000 calls)
Root Cause: These two fields are not Reset when the call is terminated and as a result, the values are preserved in this memory location from previous use. Steps to Replicate:
| The code is modified so that the value is not populated to the fields. Workaround: None. |
SBX-114020 | SBX-115121 | 2 | PortFix SBX-114020: A core dump occurred on a Standby SBC 5210 after a healthcheck failure - ENM Deadlock - while attempting register with the EMS. Impact: Running multiple registers and deregisters of a high availability SBC pair, in a rare case can cause the standby SBC to core dump and restart. Root Cause: The code on the standby SBC for processing the delete of an SNMP trap target can potentially cause a core dump. Steps to Replicate: Internal code debugging mechanisms were used to verify that create and delete of SNMP trap target processing code is bypassed on the standby SBC. | The code is modified to bypass the processing on a standby SBC. Workaround: None. |
SBX-112252 | SBX-114957 | 3 | PortFix SBX-112252: The Verstat parameter is coming before the CPC in PAI header that is not in lexicographical order. Impact: In the SIP P-Asserted-Identity header, in the TEL URI, the verstat parameter appears prior to the CPC parameter. Root Cause: Order of parameters in P-Asserted-Identity header was not in lexicographical order. Steps to Replicate: Make a SIP-SIP call. Egress SIP trunk is configured with JJ9030 interworking profile flavor jj9030. IP Signaling profile for egress trunk has "Include CPC Information" checked. IP Signaling profile for egress trunk has "Include Privacy" checked. | The code is modified so the CPC appears first. Workaround: None. |
The following Severity 1 issues are resolved in this release:
Severity 1 Resolved Issues
Issue ID | Sev | Problem Description | Resolution |
---|---|---|---|
SBX-113305 | SBX-114425 | 1 | PortFix SBX-113305: DNS recovery packet count of DSCP as "0". Impact: The DNS probe packets are sent from the SBC with a DSCP value of "0". Root Cause: The configured DSCP values were not set for DNS probe keepalive packets. Steps to Replicate:
Result: Observe that the configured DNS server is blacklisted and sending DNS probe packet towards a DNS server with configured DSCP value. | The code is modified to set a configured DSCP value for packets, including DNS probe packets. Workaround: None. |
SBX-114012 | SBX-114320 | 1 | PortFix SBX-114012: The SMM is not working when the From contains an escape character. Impact: The SMM may fail to parse a display name in double quote string when the string has more than one escape characters next to each other of a header. Root Cause: Logical error in parsing logic that causes a parsing failure. Steps to Replicate: Configure a rule to access double quote string display name of uri header, or any parameter. Ensure there is an input display name, such as From: "PhoneLite \\\"test1\\\"test2 " <sip:[field0]@dns.com>;tag=testing | The code is modified to address the issue. Workaround: None. |
SBX-109056 | SBX-114568 | 1 | PortFix SBX-109056: The SBC 5400 MS Teams CQ has transfers issues. Impact: When a call with DLRBT enabled undergoes more than one transfer with REFER signaling and the final transferee does not accept the call, the SBC does not correctly reconnect the call back to the transferor. Root Cause: For an A-to-B call, if B, for example, successfully REFERS the call to C, and then C attempts to REFER the call to D (or back to B), the SBC plays a ringtone towards A while the REFER is taking place. However, when D rejects the call with a 480 "Temporarily not available" message, the SBC does not correctly disable the call context that is playing the tone, nor does it correctly re-enable the A-to-C call association. Steps to Replicate:
| The code is modified to disable the tone playing towards A when a 480 is received and then correctly re-enable the call association back to the transferor. Workaround: None. |
SBX-114315 | SBX-114427 | 1 | PortFix SBX-114315: An SBC failover occurred because of an SCM Process core. Impact: An SCM core can occur if the hostName in the From Header is longer than 64 bytes. Root Cause: The code is copying the host name into an array that is not long enough to hold it. This results in memory corruption. Steps to Replicate: Make a call where the hostName in the From Header is longer than 64 bytes. | The code is modified to use the correct size when copying the host name. Workaround: None. |
The following Severity 2 - 4 issues are resolved in this release:
Severity 2-4 Resolved Issues
Issue ID | Sev | Problem Description | Resolution |
---|---|---|---|
SBX-112547 | SBX-114405 | 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. |
SBX-113053 | SBX-114355 | 2 | PortFix SBX-113053: Race Condition when 183 and 200 OK (INVITE) are received simultaneously. 200 OK is not relayed to other side. Impact: Race condition between internal processing of the 200 OK for an UPDATE and a received 183 Session Progress. Root Cause: After a 200 OK (UPDATE) is received, followed immediately by receipt of 183 Session progress, a subsequent 200 OK (INVITE) containing P-Early-Media header is queued indefinitely at egress when downstreamForking is enabled and earlyMedia forkingBehaviour is pemPriority. Steps to Replicate: Egress SIP trunk group has downstreamForking is enabled and earlyMedia forkingBehaviour is pemPriority. Make a call so that egress signaling is as follows: | The code is modified to eliminate the race condition. Workaround: None. |
SBX-113614 | SBX-114546 | 3 | PortFix SBX-113614: The ActiveRegCount is greater on the INGRESS side. Impact: When registration(s) take longer than 90 seconds to complete, the ingress zone’s activeRegs count can increment, but not decrement, when the registration terminates. This may cause 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 the endless REGISTER/403, or REGISTER/503, or REGISTER/603 sequence. | The code is modified to handle registration(s) that take longer then 90 seconds to complete. In this case, the SIPFE restarts the registration bind timer and avoids "prematurely" deallocating the RCB so that the FE and SG RCB(s) stay "in-sync". Workaround: None. |
GSX-54479 | SBX-114528 | 4 | PortFix GSX-54479: The isup-oli parameter is sending a single digit OLI value in isup-oli parameter for values 0-9. Impact: The SBC sends all OLI digits as a single digit. Root Cause: This functionality is not within spec. Steps to Replicate: Make a call that uses OLI parameter. | The code is modified to add a leading 0 for OLI digits 0-9. Workaround: None. |
The following Severity 1 issues are resolved in this release:
Severity 1 Resolved Issues
Issue ID | Sev | Problem Description | Resolution |
---|---|---|---|
SBX-113954 | SBX-104348 | 1 | PortFix SBX-104348: STUN was received on the SBC and the SBC considers these packets are arriving on another IP. And as a result, the STUN wasn't processed. Impact: The SBC passes the STUN packets to wrong IP address when it received them on the alternate IP. Root Cause: The SBC always uses the primary IP address of LIF to send out the packet, even when it receives the STUN packets on the alternate LIF IP. Steps to Replicate: STUN received on alternate IP of LIF and the SBC does not respond correctly, which appears as the SBC not processing it. | The code is modified so the XRM traverses the IP address list to match the address where it received the packet, instead of directly using the primary IP to send the packets. Workaround: None. |
SBX-114073 | SBX-113853 | 1 | PortFix SBX-113853: The SBC experienced an intermittent crash. Impact: When multiple duplicate Diversion headers are received and stiProfile is enabled and configured on the ingress trunk group, the SBC dumps core. The issue only occurs if six or more Diversion headers are received but fewer than five of them are unique. Root Cause: Removing duplicated Diversion headers from information sent to the PSX causes crash. Steps to Replicate:
| The code is modified to remove the duplicate Diversion headers from information sent to the PSX. Workaround: None. |
The following Severity 2 issue is resolved in this release:
Severity 2 Resolved Issue
Issue ID | Sev | Problem Description | Resolution |
---|---|---|---|
SBX-114019 | 2 | The DBG logs was rolling rapidly with UacSendUpdate messages. Impact: The SBC DBG logs were filling up quickly with the following log message. 114 10192021 114119.823662:1.01.03.16703.MAJOR .SIPSG: UacSendUpdate - local answer for UPDATE: LegSide=Ingress Root Cause: The code was mistakenly printing logs at the MAJOR level. Steps to Replicate: The log is generated during a call where the SBC tries to send an UPDATE out to ingress leg while the PRACK is pending for previous 18x sent. The following control also needs to be disabled on the trunk group the messages are being sent on. | The code is modified to only print the logs at an INFO level. Workaround: None. |
The following Severity 1 issues are resolved in this release:
Severity 1 Resolved Issues
Issue ID | Sev | Problem Description | Resolution |
---|---|---|---|
SBX-112996 | SBX-113115 | 1 | PortFix SBX-112996: 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. |
SBX-112366 | SBX-112738 | 1 | PortFix SBX-112366: 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. |
SBX-112349 | SBX-112847 | 1 | PortFix SBX-112349: The SBC releases a 132 Release code (MODULE FAILURE) message when running an audit call. Impact: An Async CMD Error reported by XRM that triggered call being torn down with release code 132 when running a call audit. Root Cause: Ribbon lacks the necessary level of detail to conclusively determine the root cause. Steps to Replicate: Since we do not know the exact condition and what types of resources were involved, we cannot provide detailed test steps for this case. Suggest running regular regression tests to attempt to reproduce the issue. | The code is modified for LE2MCAST, LE2MCAST_RTCP, LE2SPLITTER. The changes provided are based on source code inspection. Workaround: N/A |
SBX-112677 | SBX-112715 | 1 | PortFix SBX-112677: The SCMP cored in Late media passthrough calls over a GW-GW. Impact: There was a coredump for a late media passthrough case. Root Cause: Dereferences a NULL Pointer. Steps to Replicate: For the SBC GW-GW setup. Enable the LM passthrough flag. Run the following procedure:
| The code is modified to stop the coredump. Workaround: None. |
SBX-107747 | SBX-112649 | 1 | PortFix SBX-107747: Cyclic switchover tests - Observed a PRS Process core dump on the M-SBC1. Impact: If an M-SBC instance transitions to active shortly after the instance comes up as standby, when certain performance stats are collected, the PRS process will crash. Root Cause: When the instance comes up as a standby, the active instances send their metavariable information to the new standby instance. This information is sent twice for each active instances. The first metavariable information for each active instance is not received by the PRS process because the PRS process is not ready to receive it. If the instance switches to active before the second set of metavariable information is received, then the new active will not have metavariable information from the former active, which causes the PRS crash. Steps to Replicate:
unhide debug | The code is modified so the CHM process queues the first set of metavariable information until the PRS process is ready to receive it, and then sends the information to the PRS process. Workaround: None. |
SBX-112445 | SBX-112880 | 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 during hold retrieval for the transferred call. This issue is 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 is 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. |
SBX-112561 | SBX-112836 | 1 | PortFix SBX-112561: Regexp string was not exported by “user-config-export” Impact: In the Regex, the SMM is lost while exporting a configuration using the user-config-export CLI command. Root Cause: The XML formatting is trimming empty node values. Steps to Replicate:
| The code is modified to use the external tool "xmllint" to format the XML. Workaround: Manually edit the field in the XML file after an export and before an import to correct the issue. |
SBX-111126 | SBX-112531 | 1 | PortFix SBX-111126: 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 200 OK sent in response to late media reinvite is set to an incorrect value when the direction attribute received in 200 OK 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 200 OK 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. |
SBX-112624 | 1 | 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. |
SBX-112307 | 1 | 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. |
SBX-106316 | 1 | 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". |
SBX-111498 | 1 | The SBC Ladder diagram (.TRC file) shows a response from the wrong IP for a 400 Bad Request. Impact: When an INVITE (with malformed syntax) is sent to a leg1 (pkt1) SIP signaling IP for the SBC, the SBC responds with a 400 Bad request. In the TRC log, for a 400 Bad request PDU, the Local IP/port is printed with a leg 0 (pkt0) SIP Signaling IP Address instead of leg 1 SIP Signaling IP Address. This occurs only when the SBC sends error response message. Root Cause: During formatting of Error message, the code is incorrectly using the pkt0 SIP Signaling IP Address instead of a pkt1 SIP Signaling IP Address resulting in the incorrect value being printed in the TRC log. Steps to Replicate:
| The code is modified to correctly read the SIP Signaling IP Address of the leg where the call lands. Workaround: None. |
SBX-106037 | 1 | The SBC 7000 is sending a re-INVITE before receiving an ACK to the 200 OK - multi-stream call. Impact: The SBC removes transcodable codecs when the application media m-line is present with port as 0. This results in the SBC sending a re-INVITE without SDP. Root Cause: By default, the SBC does not support transcoding on multi-stream calls. The problem here was that the code incorrectly identified that there was an application stream present even when the port was set to 0. This made it appear as a multi-stream call and resulted in the transcodable codecs being removed. Steps to Replicate: Test Case 1: GW-GW Scenario
The user observes logs in TRC file and the SBC will send BYE to peers. The call will fail. | The code is modified so that the stream with a port 0 is effectively ignored when processing transcodable codecs. Workaround: Enabling "AllowAudioTranscodeForMultiStreamCalls" flag on both ingress and egress PSPs will solve the issue. |
SBX-112557 | 1 | The password policy is not recognized by the SBC. Impact: The password policy not recognized by the SBC. By default, the admin rules were taken. Root Cause: Password policy was assigned based on roles of the user. Steps to Replicate: Go to Administration/Application Management. In Configure Password Rules tab, check by enable or disable "Use Separate Password Rules for Administrators" where you are able to change the password policy or not in change password model. | The code is modified to use the state variable in PasswordRule class Workaround: Add new variable named "state" to PasswordRule Class as a workaround. |
SBX-111743 | 1 | The SBC block list IP with the wrong port. Impact: The ARS block lists port 0, when an INVITE contains a Route header without a port number, and 503 response contains a Retry-After header. Root Cause: The code did not support a case where no port number is provided. Steps to Replicate:
The UAS responds with 503 Service Unavailable with Retry-After header use CLI to check egress zone sipArsStatus. | The code is modified so when 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. |
SBX-113471 | 1 | Multiple SBC core dumps were detected. Impact: There was forking hashtable corrupted memory. Root Cause: Possibility of forking control fails to remove from hashtable when the resource is cleaned up. Steps to Replicate: Unable to reproduce. Run high load with a NAPT, upstream forking and registration and taking a SIP signaling port down/up. | The code is modified to ensure the forking call is removed from hashtable when free. Workaround: None. |
SBX-112322 | 1 | The SBC cored when the subscribe crankback failure. Impact: When a relay Subscribe tried to crank back for the second route and if the SBC does not find trunk group, the SBC may core. Root Cause: The SBC cores due to duplicated memory freed. Steps to Replicate: Configure two routes for the relay Subscribe. The second route is invalid. After the first route exhausted, the SBC try to cranked back for the second route. The SBC fails to find trunk group for the second route. | The code is modified to prevent duplicated memory to be freed. Workaround: Correct the second route. |
SBX-113183 | SBX-107753 | 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. |
SBX-113426 | SBX-112447 | 1 | PortFix SBX-112447: The SIPRec recording failed for an EGRESS call with GCID 291515755. 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 set up to reproduce the issue.
| When a SIP Offer-Answer towards SRS is in progress, SBC shall not attempt to send another offer and instead shall queue the latest event until the current offer-answer is complete. Workaround: None. |
SBX-113196 | 1 | A SCM Process coreump occurred on the SIGABRT. Impact: When the INVITE message contains trunk group/trunk context parameter information and the context is an FQDN, then the SBC can use this information to formulate the IP Peer information if there is none supplied from the PSX. This can result in an SCM process coredump, if multiple routes are returned from the PSX. Root Cause: The internal processing code did not account for multiple routes and it was always freeing memory that was possibly assigned to the first route. However, when processing the second or subsequent routes in a crankback scenario, the memory on the first route freed once when routing the call on the second route and then again when the call was actually released. This second freed memory was invalid and results in a coredump. Steps to Replicate:
| The code is modified to correctly manage the memory on the route being used for the call. The code change frees and allocates memory consistently for a route to avoid freeing the memory twice. Workaround: Remove the trunk group/context using the SMM from the received INVITE. Ensure the PSX only returns one route when processing trunk group/context information. |
The following Severity 2-4 issues are resolved in this release:
Severity 2-4 Resolved Issues
Issue ID | Sev | Problem Description | Resolution |
---|---|---|---|
SBX-112857 | SBX-113197 | 3 | PortFix SBX-112857: Increase the VNFM response timeout. Impact: By default, the VNFR logic had a 5 second timeout to get responses from VNFM for the REST requests that it sent, but it has been observed that in certain networks this timeout value is not enough. This leads to the VNFR timing out while the VNFM was still trying to send back a response and the VNFR never reported ready state in the VNFM. Root Cause: A delay of 5 seconds was originally thought to be long enough but across multiple networks, this was insufficient. Steps to Replicate: Try a relocation operation with VNFM across multiple sites and ensure the VNFR status returns to ready. | The code is modified so the timeout is now increased to 20 seconds. Workaround: None. |
SBX-112487 | SBX-113200 | 2 | PortFix SBX-112487: The LI connection to media server was not connected on a switchover. Impact: When using a PCSILI (P-com-session-info flavour 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 is transitioned from standby to active, so that accurate interface information is available for LI processing. Workaround: Bouncing the interface (e.g. ifup/ifdown that is used for LI connection), will help to recover the connection. |
SBX-109006 | SBX-110819 | 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. |
SBX-112971 | SBX-113352 | 2 | PortFix SBX-112971: The diameter process cored continuously when creating the diamNode entry. Impact: The diameter process acts as a client and server. When it acts as server, on accepting TCP connection from the remote diameter client, the diameter process crashes due to an invalid operation. Note: There is no use case where the diam process accept connection from remote diameter client, so this scenario not covered in our earlier testing. This issue observed during misconfiguration. Root Cause: On accepting TCP connection from the remote diameter client, the diameter process tries to perform an invalid operation (null pointer access) and due to this, the diameter process crashes. Steps to Replicate: Configure the diameter node in the SBC and simulate TCP client application that connects the diameter server (on port 3868). | The code is modified so the diameter process does not perform any invalid operation. Workaround: Do not configure same IP address for the peer and for diameter node. |
SBX-113413 | SBX-113535 | 2 | PortFix SBX-113413: The call failure with an extra INVITE is sending. Impact: If A calls B over the SBC, the SBC sends INV with sendrecv to B. B sends 180/200 with recvonly. After call is established, the SBC sends a re-INVITE to B with data path mode as sendonly. Root Cause: As part of a previous issue, a behavior change was introduced so that the SBC sends a hold re-INVITE (received from the network) to the other end. This was only for the cases where call is already on hold but data path mode is changed. Steps to Replicate:
A to B is connected. When call is connected, there should not be an re-INV towards egress leg (with recvonly). | The code is modified so in the case when the SBC receives a re-INVITE from network and data path mode is changed, it triggers a new re-INVITE to the other leg. In other cases, it would be same behavior (prior to SBX-111611). Workaround: None. |
SBX-107396 | SBX-112247 | 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 don't 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. |
SBX-110592 | SBX-112526 | 3 | PortFix SBX-110592: 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. |
SBX-110755 | SBX-112791 | 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. |
SBX-110490 | SBX-113016 | 2 | PortFix SBX-110490: 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. |
SBX-109364 | SBX-111831 | 2 | PortFix SBX-109364: The SBC ERE was unable to handle "sonusdomain.IP" as a keepalive response from DNS. Impact: The SBC ERE was unable to handle "sonusdomain.IP" as a keepalive response from DNS. Root Cause: A format Error (dns_rcode_formerr) return code of a DNS server was unable to whitelist a server that was block listed. The DNS server is not getting whitelisted from a block list since the Format Error (dns_rcode_formerr) return code is not handled in the code. Steps to Replicate:
| The code is modified to fix the issue. Workaround: None. |
SBX-112429 | SBX-112818 | 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. |
SBX-111740 | SBX-112570 | 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. |
SBX-98627 | SBX-113514 | 2 | PortFix SBX-98627: The Min-SE header is getting added to the ingress metaDataProfile even though it is not in the initial INVITE. Impact: For the SIPREC, the Min-SE and Session-Expires headers are added to the metaDataProfile even though it is not received in the initial INVITE. Root Cause: When receiving an INVITE, the SBC was incorrectly inserted Min-SE and Session-Expires headers as part of an incoming INVITE. Steps to Replicate:
| The code is modified so if an incoming INVITE is missing support for a Timer, the SBC resets the value of the Min-SE and Session-Expires only if it is received. Workaround: Use the SMM to delete the Metadata in the SIPREC INVITE. |
SBX-105688 | SBX-110152 | 2 | Portfix SBX-105688: The TAP ID of an ingress target was not getting embedded in the CCID for IMSLI (both leg interception). Impact: When a call has matched the ingress and egress LI criteria/target for a SIP Out of Dialog message and if each of the criteria was configure with different TAP IDs over the X1 interface, only one of the TAP IDs was processed by the SBC. Root Cause: The SBC always stored only one TAP ID, the TAP ID present in the 0th index of the LI criteria table that is returned by the PSX and it did not store the TAP IDs corresponding to ingress and egress criteria separately. As a result, whenever both legs are intercepted for OOD messages, one of leg would have the incorrect TAP ID in the CCID for X2 messages. Steps to Replicate:
| The code is modified to store and process the TAP ID for both the ingress and egress target criteria. Workaround: None. |
SBX-109103 | SBX-111454 | 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. |
SBX-101255 | SBX-112998 | 2 | PortFix SBX-101255: The OAM should not configure the same IP for two different pkt interfaces. Impact: The OAM is allowing the same IP and alternate IP to be configured under the same address context. Root Cause: During an address context, the interface creation OAM was allowing the configure of the same IP address (IpV4/IpV6) and alternate IP address for different interfaces. Steps to Replicate: The meta table is added for ipVarV4/ipVarV6/altIpVars value. When creating the ipInterface table, we should also observe ipInterfaceIpVarVMeta(hidden) The meta table is created for ipVarV4/ipVarV6/altIpVars. For all test cases, the following table can be observed: | The code is modified to have a unique IP address (IpV4/IpV6) and alternate IP address for an address context. New meta data is created for validating uniqueness efficiently. Workaround: Do not configure the ipVarV4/ipVarV6/altIpVars |
SBX-111019 | SBX-113030 | 2 | PortFix SBX-111019: The SBC should not allow to configure the same IP for two different pkt interfaces. Impact: The SBC should not allow to configure same IP for two different pkt interfaces. Root Cause: After a playback file pushed to the SC nodes, the dummy validate is invoked before creation of the addresscontext table, ipInterfaceIpMetaVar table to be moved out of addresscontext yang. Steps to Replicate: The meta table is added for ipVarV4/ipVarV6/altIpVars value. When creating the ipInterface table, we should also observe ipInterfaceIpVarVMeta(hidden) The meta table is created for ipVarV4/ipVarV6/altIpVars. For all test cases, the following table can be observed:
| The code is modified to move ipInterfaceIpMetaVar out of addresscontext yang. Workaround: None. |
SBX-111956 | SBX-113152 | 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. |
SBX-110985 | SBX-111275 | 2 | PortFix SBX-110985: 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. |
SBX-112082 | SBX-112551 | 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. |
SBX-113278 | SBX-113572 | 2 | PortFix SBX-113278: Need a configurable item added to indicate a legacy meshed network on GW link to lower MAX_ICM value Impact: A call sent from an SBC running 9.0 or above to a older GSX may cause the GSX to core. Root Cause: In 9.0, the PDUs sent from the originating GW to the destination GW in a GW-GW call has increased in size. In this case, the GSX does not expect a PDU this large and this will result in the GSX overwriting the allocated buffer causing memory corruption that eventually leads to a core. Steps to Replicate: Send an SBC-GW-GW-GSX call involving text (T140) streams. As a result, the GSX may crash.
The GSX should not crash. | The code is modified so the new configuration parameter is enabled if there are any older GSXs in the network: set global signaling oldGsxSupport When this parameter is enabled, the SBC reduces the max size of the PDUs that can be sent over a GW-GW connection to older GSXs and older SBCs. Workaround: There is no workaround. |
SBX-112708 | SBX-113492 | 3 | PortFix SBX-112708: The NOTIFY XML body for 200 OK for INVITE does not contain new values that were updated between 180 and 200. Impact: The SBC was not sending latest received P-Asserted-Identity in the call NOTIFY XML body. Root Cause: The SBC was not considering the latest received P-Asserted-Identity and was always sending the first received message in call NOTIFY XML body. Steps to Replicate: Steps:
Expected Result: The SBC sends ringing NOTIFY with the XML body contains PAI element that received in 18x and while sending a connected NOTIFY should consider PAI received in 200 OK. | The code is modified to consider the latest received P-Asserted-Identity identity for populating a call NOTIFY XML body. Workaround: None. |
SBX-110997 | SBX-111367 | 2 | PortFix SBX-110997: There are media problems due to same SSRC after hold/MOH/resume and a previous fix's flag was not helping. Impact: The SBC is not changing local SSRC during a HOLD/RESUME of a Transcoded call. Root Cause: During a HOLD/RESUME of a Transcoded call, the NP was not updated with the new SSRC generated by the SBC, and this resulting in the old SSRC being used in media packets. Steps to Replicate:
| The code is modified to update NP with the latest SSRC generated during mid-call modification due to HOLD/RESUME of Transcoded calls. Workaround: If possible, switch to pass-through calls since this issue is specific to transcoded calls only. |
SBX-113048 | SBX-113389 | 2 | PortFix SBX-113048: Edited the External IP Interface group name disappearing in Visual First Call View as a diagramSetup. page Impact: Edited the External IP Interface group name disappearing in Visual First Call View as a diagramSetup page. Root Cause: The existing system did not handle save functionality when an external "IP Interface Group" was not empty. Steps to Replicate:
After navigating back to Visual First Call Setup, the changes were saved i.e. Carrier type and IP Interface Group should be visible. | The code is modified for the External "IP Interface Group" for both empty and non-empty cases. Workaround: None. |
SBX-111721 | SBX-111722 | 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. |
SBX-111896 | SBX-112373 | 2 | PortFix SBX-111896: Automatic daily updates in HFE script for Azure/GCE were causing the network to reset. Impact: Networking on the HFE can be reset by automatic updates. Root Cause: Ubuntu, by default, has an automatic package updater. Some package upgrades can cause the networking to be reset on the HFE node. Steps to Replicate: Check if the following timers are enabled:
| The code is modified to disable the timer that triggers the automatic updates. Package upgrades should only occur out of hours. Workaround: Run the following commands to disable the the updates:
|
SBX-110291 | SBX-112568 | 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 |
SBX-105367 | 2 | 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. |
SBX-112905 | 2 | The SBC was answering on-hold call with the sendrecv then re-inviting. Impact: On an incoming INVITE onhold, the SBC responds to the 18x offhold and later the re-INVITE onhold. Root Cause: There was a logical error that converts from an inactive to sendrecv when the first 18x is sent out. Steps to Replicate: On the ingress, configure the Minimize flag, and uncheck relay data path mode. Incoming Invite onhold, egress response 18x. The SBC send 18x to ingress with sendrecv. | The code is modified to apply for subsequent 18x only. Workaround: Enable the relay data path mode. |
SBX-110780 | 2 | The SBC was sending Empty Packets when playing an Announcement. Impact: Announcement packets are empty for two stage calls if the NAPT enabled on the ingress. Root Cause: The ARM was not getting indication to start the announcement once NAPT learning was complete. Steps to Replicate: Set up a two stage call and enable the NAT on ingress. | The code is modified to send an indication to start the announcement once NAPT learning was complete Workaround: Disable the NAT. |
SBX-111349 | 2 | 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. |
SBX-112953 | 2 | 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. |
SBX-110359 | 2 | No INFO Logging Warning is provided when enabling the info debug/sys. Impact: The SBC CLI/EMA does not provide any warning when enabling INFO logging, indicating impact to system performance and call processing. Root Cause: There was no code to provide the warning to user. Steps to Replicate: Run the following script to reproduce the issue: admin@sbxsus12% set system admin sbxsus12 cliSetWarningOnEnablingInfoLevelLogging | The code is modified to provide a warning to the user when enabling INFO level logging for system or debug logs. To maintain backward compatibility and not break any customer scripts, a user needs to enable this extra prompt. Workaround: None. |
SBX-112060 | 2 | 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. |
SBX-110746 | 2 | 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. |
SBX-109614 | 2 | There were Error logs in DBG file after upgrade on 9.2.1 Impact: The SIPFE was reporting two kinds of major level error messages in the DBG logs:
Root Cause: Port Range Support was added in a previous feature that involves four subsystems, SIPSG, SIPFE, SIPCM and XRM, among 3 processes. There were several message exchanges between the four subsystems before a port range connection is fully established. Under certain circumstances, it is possible to hit some race conditions and find major DBG messages in DBG logs. Steps to Replicate: The steps cannot be replicated. | The code is modified to print extra call related data in the current major level debug messages to help triage more if the problem occurs in the future. When the issue occurs again, the call ID, signaling port Id, etc., is collected to help identify the call. The SipFeRedundMirrorHashSync() log is reduced from MAJOR level as well. Workaround: N/A |
SBX-111541 | 3 | Reloading previous configuration fails when the LDAP delayedSync is enabled. Impact: The delayed sync leaf used to accept only a future time if a configuration export and import is performed and if the system time is greater than the delayed sync time during import than import fails. Root Cause: The delayed sync leaf used to accept only a future time if a configuration export and import is performed and if the system time is greater than the delayed sync time during import then import fails. It fails due to the check on the delayed sync leaf value that should be greater than the current system time. Steps to Replicate: Use the following configuration:
| Remove the restriction on the delayed sync leaf to be greater than the current system time to address the issue. Workaround: Modify the delayed sync time in the export CLI. |
SBX-112267 | 2 | 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. |
SBX-112493 | 2 | 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. |
SBX-113546 | 2 | Policy server transactions were failing while running a load (3xx redirection with light dip) with 75K Number Translation criteria. Impact: The postgres db is utilizing more CPU when a dmpm translation is executed at the service layer and as a result, impacting the performance. Root Cause: Using a dmpm rule, either the calling or the called number can be modified at the prerouter layer. The PES previously analyzed the called and calling number completely even though it was exclusive to the called number or the calling. During an analysis of the call, the PES used to perform direct DB fetch operations and this caused the postgres process to use more CPU. Steps to Replicate: Create a dmpm rule service to modify the calling number. And then perform performance testing. The postgres process will utilize more CPU. | The code is modified so that, the PES analyzes either only the called number or only the calling number based on the rule type. Workaround: none. |
SBX-113610 | 2 | A PES Process coredumps when deleting an adProfile entry. Impact: The PES Process dumps core when the AD profile 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 its dependent profiles. | The code is modified so the AD profile is not deleted. If, for some reason, the synchronization needs to be stopped, the sync opotion can be disabled on the AD profile. Workaround: If the AD profile is no more required, do not delete the AD Profile but disable the sync option on it. It will stop all the future auto sync operations. |
SBX-112603 | 2 | SBX-107111: Configured the DM/PM Rule not getting executed when the system is loaded with 75,000 number Translation criteria. Impact: When there are more than 3,000 number translation criteria (NTC) objects are created, the PES cache goes for rebuild of the entire cache. The cache rebuild was not caching the NTC objects correctly. Root Cause: During a rebuild of the NTC cache, a static variable was not reinitialized to zero. Since the static variable was not initialized to zero during a cache rebuild, it was using the last modified value, and this was causing the cache to not rebuild with the all the NTC objects. Steps to Replicate: Create more than 3,000 NTC objects and make a call to match the NTC key. It will fail to find a match in the cache. | The code is modified to initialize the static variable to zero, when a fresh cache rebuild is triggered. Workaround: None. |
SBX-112670 | 2 | The SBC is sending an unexpected INVITE towards the UAS. Impact: In an SBX-GW-GW-SBX call flow (as described in the test setup), the SBC was sending unexpected re-INVITE to the network. The re-INVITE was internally generated in order to handle the change in SDP parameters triggered by the SMM rules. Root Cause: This was a side effect of for a previous fix in the 9.2.1 release. Steps to Replicate:
After step 7, we should not see a re-INVITE towards the UAS. | The code is modified to take care of the case when holding a re-INVITE is actually received from a network or if it was locally generated. Only in a case where it was from network, we propagate the re-INVITE to the other end. Workaround: None. |
SBX-113385 | 2 | An unexpected 504 response was received, after a crankback to "500". Impact: When the SIP trunk group control UseNonDefaultCauseCodeForARSBlacklist is enabled and the outgoing message cannot be sent due to address unreachable status, the crankback to the next end point was not occurring. Root Cause: The code was incorrectly updated during 9.2.2 to try and map from SIP to CPC using internal 7xx status codes which are generated by the stack for events such as timeouts. This lead to the disconnect reason code being mapped to 0 that did not exist in the crankback profile instead of 168 which was expected. So the crankback did not occur and the call was released with 504. Steps to Replicate:
The message should be attempted to the next end point, but if that end point is blocklisted due to pathcheck configuration the message should be sent to the next again end point. | The code is modified to only consider the standard SIP status codes when trying to map from SIP to the CPC so that the correct disconnect reason code of 168 is used to trigger a crankback. Workaround: None. |
SBX-113766 | 2 | 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. |
SBX-90989 | 2 | EMA CDR Viewer: SIP Ladder diagram tool presenting incomplete packets The SBC CDR Viewer is enhanced to overcome SIP Ladder diagram size limitations to ensure large messages display. Impact: Incomplete packets display in the SIP Ladder diagram tool because the EMA did not know to append the next block to the previous PDU in the tool, and dropped the secondary packet block. Root Cause: Due to size limitations, large packets are getting split into two blocks, causing the second block to get prepended with information about the filter when it is written to the TRC log. Steps to Replicate: Use call trace filter to capture some large messages i.e. more than 2K in size and check that they are displayed correctly in the SIP ladder diagram. | The code is modified to ensure large messages display in the SIP Ladder diagram. Workaround: None. |
The following Severity 1 issues are resolved in this release:
Severity 1 Resolved Issues