Table of Contents


About SBC Release Notes

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).

Release Notes Use and Distribution

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.

Associated Ribbon Announcements

The following Ribbon announcements (formerly known as WBAs) are referenced in this release note:

Bulletin IDDescriptionFixed 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-00029972The SBC upgrade may truncate the SQL configuration database due to too many historical alarms.N/A
To view/subscribe to announcements (Warnings, Bulletins, Alerts, or PCNs):
  1. Click here
    to go to the "Announcements" page in the Ribbon Support Portal.
  2. Enter the announcement number (last eight numbers) in the search field and click the magnifying glass icon (or press Return). You can alternatively use the filter tools located on the left side of the screen to narrow your search.

Problems or Questions

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)

About SBC Core

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.

H.323-SIP and SIP-H323 Calls

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.

Note

H.323 is not supported on SBC SWe cloud deployments.

Compatibility with Ribbon Products

Tip

When upgrading your network, ensure to upgrade each product to the most current release to take advantage of the latest features, enhancements, and fixes.

Info

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.


New Features

New Features in Release 09.02.05R007

There are no new features in this release. 

New Features in Previous Releases

To view features in previous releases, refer to the following release notes:


Sample Heat Templates Included in This Release

To instantiate the SBC instances, the following templates can be used:

SBC Heat Templates

 Template NameDescription
heatRgNoDhcp.yamlUsed 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.yamlUsed to instantiate an OAM node.
heatRgNoDhcp-TSBC-template.yamlUsed to instantiate a T-SBC node.


Note

Example template files are packaged together in .tar.gz and .sha256 files separate from the SBC Core application installation and upgrade files:

  • cloudTemplates.tar.gz
  • cloudTemplates.tar.gz.sha256

SBC SWe Cloud Hardware and Software Requirements 

The system hosting the SBC SWe Cloud must meet the following requirements.

OpenStack

OpenStack Hardware

ConfigurationRequirement
Processor

Intel Xeon processors (Nehalem micro-architecture or above) with 6 cores and above (processors should support hyper-threading).

Note

Ribbon recommends Westmere (or newer) processors for better SRTP performance. These processors have the AES-NI instruction set for performing cryptographic operations in hardware. 

 RAMMinimum 24 GiB
 Hard DiskMinimum 100 GB
Network Interface Cards (NICs)

Minimum 4 NICs.

Note

Make sure NICs have multi-queue support which enhances network performance by allowing RX and TX queues to scale with the number of CPUs on multi-processor systems.

Note

The Intel I350, x540, x550, and 82599 Ethernet adapters are supported for configuring as SR-IOV and DirectPath I/O pass-through devices.

Note

The PKT ports must be 10 Gbps SR-IOV enabled ports.

Note

6 NICs are required to support PKT port redundancy.

Note

To configure VLAN on SRIOV and PCI Passthrough Ethernet interfaces, disable the Data Center Bridging (DCB) on the switch connected to the interfaces.

OpenStack Software

The SBC SWe supports the following OpenStack environments:

  • Newton with RHOSP 10 and RHEL 7.4
  • Queens with RHOSP 13 and RHEL 7.5
  • Train with RHOSP 16.1 and RHEL 8.2
Note

The SBC SWe was tested on OpenStack Queens with RHOSP 13 and RHEL 7.5.

S-SBC

The system hosting the SBC SWe must meet the following requirements to achieve the performance targets listed: 

S-SBC SWe Requirements
for 1000 CPS/120K Signaling Sessions 
Notes

32 vCPUs

Due to the workload characteristics, allocate 20 physical cores with two hyper-threaded CPUs from each core to the SBC.

128 GiB RAM

Must be Huge Page memory. The minimum page size is 2048 KiB, but 1048576 is recommended.

100 GB Disk

None

4 vNICs/6 vNICs

Attach MGT0 port to the Management VirtIO Tenant network.

HA port has to be on IPv4 VirtIO Tenant network.

Attach PKT0 and PKT1 ports to SR-IOV and Provider network.

Note

All NIC ports must come from the NUMA node 0. The S-SBC SWe instance is hosted on dual-socket physical server with 10 physical cores coming from each NUMA node.


M-SBC

M-SBC SWe Requirements
for 40K Media Sessions
Notes

16 vCPUs

Due to the workload characteristics, allocate 10 physical cores with two hyper-threaded CPUs from each core and from single NUMA node to the SBC.

32 GiB RAM

Must be Huge Page memory. The minimum page size is 2048 KiB, but 1048576 is recommended.

100 GB Disk

None

4 vNICs/ 6 vNICs

Attach MGT0 port to the Management VirtIO Tenant network.

HA port has to be on IPv4 VirtIO Tenant network.

Note

All NIC ports must come from the same NUMA node from which the M-SBC SWe instance is hosted.

OAM Node

OAM Node (minimum)Notes

4 vCPUs

None

16 GiB RAM

None

80 GB Disk

None

4 vNICs

None

I-SBC

I-SBC SWe RequirementsNotes

20 vCPUs


32 GiB RAM

Must be Huge Page memory. The minimum page size is 2048 KiB, but 1048576 is recommended.

100 GB Disk

None

4 vNICs/ 6 vNICs

Attach MGT0 port to the Management VirtIO Tenant network.

HA port has to be on IPv4 VirtIO Tenant network.


KVM/RHV

KVM/RHV Hardware

The following table lists the server hardware requirements.

Configuration Requirement
Processor

Intel Xeon processors (Nehalem micro-architecture or above) with 6 cores and above (processors should support hyper threading).

Note

Ribbon recommends using Westmere (or newer) processors for better SRTP performance. These processors have the AES-NI instruction set for performing cryptographic operations in hardware.

Note

The supported CPU Family number is 6 and CPU Model number must be newer than 26. Refer to the Intel Architecture and Processor Identification document for more information.


 RAMMinimum 24 GB
Hard DiskMinimum 500 GB
Network Interface Cards (NICs)
Minimum 4 NICs
Note

Make sure NICs have multi-queue support which enhances network performance by allowing RX and TX queues to scale with the number of CPUs on multi-processor systems.

Note

The Intel I350, x540, x550, x710, and 82599 Ethernet adapters are supported for configuring as SR-IOV and DirectPath I/O pass-through devices.


Ports

Number of ports allowed:

Warning

The SBC SWe software runs only on platforms using Intel processors. Platforms using AMD processors are not supported.

KVM/RHV Software

The SBC SWe requirements for a KVM hypervisor environment are shown in the following table:

SoftwareVersionTested or Qualified Version
KVM Module 3.10.0 or above3.10.0
QEMU Emulator  1.5.31.5.3
libvirtd (libvirt)1.1.11.1.1
virt-manager0.10.00.10.0

VMware

VMware Hardware

Warning

The SBC SWe software only runs on platforms using Intel processors. Platforms using AMD processors are not supported.

The following table lists the server hardware requirements:

SBC SWe for VMware – Server Hardware Requirements

 ConfigurationRequirement
Processor

Intel Xeon processors (Nehalem micro-architecture or above) with 6 cores and above (processors should support hyper threading).

Note

Ribbon recommends using Westmere (or newer) processors for better SRTP performance. These processors have the AES-NI instruction set for performing cryptographic operations in hardware.

Note

The supported CPU Family number is 6 and CPU Model number must be newer than 26. Refer to the Intel Architecture and Processor Identification document for more information.

Note

ESXi 6.5 and later releases require approximately 2 physical cores to be set aside for hypervisor functionality. The number of VMs which can be hosted on a server must be planned for accordingly.

 RAMMinimum 24 GB
Hard DiskMinimum 500 GB
Network Interface Cards (NICs)
Minimum 4 NICs, if physical NIC redundancy is not required.
Note

Make sure NICs have multi-queue support which enhances network performance by allowing RX and TX queues to scale with the number of CPUs on multi-processor systems.

Note
  • The following NICs are supported for configuring as SR-IOV and DirectPath I/O pass-through devices. SR-IOV is supported only with 10 Gbps interfaces (x540/82599/x710):

Intel I350, x540, x550, x710 and 82599, Mellanox Connect - 4x, Mellanox Connect - 5x, and CISCO VIC. 

  • The VMware Enterprise Plus license is required for SR-IOV.
Ports

Number of ports allowed:

VMware Software

Warning

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.

The following are the SBC SWe requirements for VMware ESXi environments:


SoftwareVersionTested and Qualified VersionFor More Information
vSphere ESXi

The version must be supported.

See the End of General Support column at  https://lifecycle.vmware.com/#/ for supported versions.

  • VMware 6.7.3 tested with virtual hardware version 14
  • VMware 7.0.2 tested with virtual hardware version 19
  • Customized ESXi images for various server platforms are available on VMware and hardware platform vendor sites.
    • These ensure that all the required drivers for network and storage controllers are available to run ESXi server.
    • Most of the customized ESXi images come with customized management software to manage the server running the ESXi software.
  • Customized ESXi images for HP ProLiant and IBM servers are available at:
vCenter Server
vCenter Server
Note

The VMware Enterprise Plus license is required for SR-IOV.


Requirements for Using the IaC Environment with SBC SWe

The following tarball file is required to use the Infrastucture as Code IaC environment to deploy SWe N:1 deployments on VMware:

  • raf-20.12-iac1.0_sustaining-240.tar.gz

The environment in which you place and expand the IaC tarball must include:

  • A Linux server running RedHat Enterprise Linux (RHEL), CentOS 7 or Debian 9
  • Python 2.7 or later
  • An internet connection for downloading and installing additional files that may be required for your deployment
  • Root access on the instance or ability to become root (for example, using sudo su -)
  • Access to the vSphere ESXi host IP from the Linux server where the IaC environment is set up.

For more information on IaC, refer to  Using the Ribbon IaC Environment to Deploy SBC SWe on VMware.

Required Software and Firmware Versions

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 BIOSV2.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-R007

SBC Application

V09.02.05-R007


Note

The firmware package of SBC 5400 and 7000 includes BMC, BIOS, and other binaries. The firmware is upgraded from the BMC.

How to Verify Currently Installed Software/Firmware Versions

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.

Software Bundles

The following software release bundles are available for download from the Customer Portal:

  • SBC5x7x_9.2
  • SBCSWe_9.2

Download the appropriate software packages for your desired configuration from the Customer Portal (https://ribboncommunications.com/services/ribbon-support-portal-login) to your PC.


Note

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.

SBC 5000 Series (51x0/52x0) Firmware

  • 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

SBC 5400 Firmware

  • firmware-5400-V03.23.00-R000.img
  • firmware-5400-V03.23.00-R000.img.md5

SBC 7000 Firmware

  • firmware-7X00-V03.23.00-R000.img
  • firmware-7X00-V03.23.00-R000.img.md5

Note

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.

SBC Core Operating System Installation Package

The ConnexIP Operating System installation package for SBC Core:

  • sbc-V09.02.05R007-connexip-os_08.02.04-R003_987_amd64.iso
  • sbc-V09.02.05R007-connexip-os_08.02.04-R003_987_amd64.iso.sha256
  • sbc-V09.02.05R007-connexip-os_08.02.04-R003_987_amd64.iso.md5


Note

 Once the ConnexIP ISO procedure is completed, the SBC application package is automatically uploaded to SBC platforms.

Release 9.2 OS Patches

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).


SBC Core Application Package

The SBC Core application installation and upgrade package includes the files:

  • sbc-V09.02.05R007-connexip-os_08.02.04-R003_987_amd64.qcow2
  • sbc-V09.02.05R007-connexip-os_08.02.04-R003_987_amd64.qcow2.sha256

  • sbc-V09.02.05R007-connexip-os_08.02.04-R003_987_amd64.qcow2.md5
  • sbc-V09.02.05R007-connexip-os_08.02.04-R003_987_amd64.ova
  • sbc-V09.02.05R007-connexip-os_08.02.04-R003_987_amd64.ova.sha256
  • sbc-V09.02.05R007-connexip-os_08.02.04-R003_987_amd64.ova.md5
  • sbc-V09.02.05-R007.x86_64.tar.gz

  • sbc-V09.02.05-R007.x86_64.sha256
  • sbc-V09.02.05-R007.x86_64.md5

  • sbc-V09.02.05-R007.x86_64.signature

For detailed information on installation and upgrade procedures, refer to SBC Core Software Installation and Upgrade Guide.

Accessing Public Cloud Images

Error rendering macro 'excerpt-include'

User 'null' does not have permission to view the page.

https://rbbncustomerimagestorage.blob.core.windows.net/swe-initial-image-share/release-sbc-v09-02-05r007-05-30-23-10-11.vhd?st=2023-05-30T10%3A37%3A41Z&se=2023-11-28T10%3A37%3A41Z&sp=r&sv=2021-06-08&sr=c&sig=2OIpBvSzZ%2BA5STNFO0rOv5zJITm4JxjjpgrasJzU2zA%3D

Snapshot name: /subscriptions/1c125f94-dd63-4190-97e3-2c353ca68b96/resourceGroups/SBC-Core-Images-RG/providers/Microsoft.Compute/snapshots/release-sbc-v09-02-05r007-05-30-23-10-11.snap

Ribbon OEM Host Operating System (ROHOS)

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

Cloud Service Archive (CSAR) Packages for VNFM Deployment on OpenStack

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: 

  • createVnfmCsar.py
  • vnfmSol001VnfdTemplate.yaml
  • sbc-V09.02.05R007-connexip-os_08.02.04-R003_987_amd64.qcow2

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. 

Upgrade Notes

Warning

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.


Warning

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.

Warning

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.


Note

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.


Note

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.

Note

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.

Note

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.

Note

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-SBC80
M-SBC80
PSX-M360
PSX-S360
PSX-Test360
EMS_SA150

Note

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: 

  • Check ‘numa.nodeAffinity’ settings on VM. It should be either 0 or 1 based on which NUMA node PKT ports are connected. The following command on ESXi host can be used to check PKT port NUMA affinity:

     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:

  • Shutdown the standby instance.
  • If ‘numa.nodeAffinity’ settings are missing, add the following rows:

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.

  • Power-on standby instance.
  • Once standby instance is up and running, do manual switchover through CLI and repeat above steps to modify ‘number of virtual sockets’ , ‘numa.nodeAffinity’ and ‘numa.autosize.once’ settings.

For more information, refer to:

Note

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.

  1. Issue the following CLI command to clear the EDNS statistics for all DNS Groups in the system. 

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.

Note

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

Note

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>


Upgrade Information

Warning

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 begin with A-Z a-z _ only.
  • Usernames cannot start with a period, dash, or digit.
  • Usernames can contain a period(.), dash(-), alphabetic characters, digits, or underscore(_).
  • Usernames cannot consist of digits only.
  • 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. 

SBC SWe Pre-Upgrade Requirements

VM CPU Resource Allocation Requirements

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.

Disable Call Trace Feature Prior to LSWU/upgrade

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.

Manually Check for Hostcheck Validation Failed message

Perform the following procedure on the Standby to check for the Hostcheck Validation Failed message in the upgrade.out log.

  1. Log on to ESXi of the Standby SBC SWe.
  2. Check in/opt/sonus/staging/upgrade.out (this log shows the Hostcheck Validation Failed error).
  3. Power off the VM.
  4. Reduce the number of vCPUs assigned to VM by one and set the CPU reservation to the appropriate value.
  5. Power on the VM. The SBC SWe successfully upgrades to the latest version 6.2.0. 
  6. Run the command show table system serverSoftwareUpgradeStatus to confirm the successful upgrade.
  7. Perform similar procedure for LSWU on Active.

Preparing for Upgrade (All Platforms)

Note

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.

Warning

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.

Supported Live Software Upgrade (LSWU) Paths

Attention

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.

Note

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.xV09.00.x -
V09.02.01x
V09.02.02x -
V09.02.05x
V07.00.00R000V07.02.00R000V07.02.02R000V08.00.00R000 V08.02.00R000V09.00.00R000V09.02.02R001
V07.00.00F001V07.02.00R001V07.02.02R001V08.01.00R000V08.02.00F001V09.01.00R000V09.02.02R002
V07.00.00F002V07.02.00R002V07.02.02R002V08.01.00F001V08.02.00F002V09.01.00R001V09.02.02R003
V07.00.00F003V07.02.00S400V07.02.02R003V08.01.00R001V08.02.00R001V09.01.00R002V09.02.02R004
V07.00.00F004V07.02.00S401V07.02.02R004V08.01.00R002V08.02.00R002V09.01.00R003V09.02.02R005
V07.00.00F005V07.02.00S809V07.02.02R005V08.01.00R003V08.02.01R000V09.02.00R000V09.02.02R006
V07.00.00F006V07.02.00S810V07.02.02F001V08.01.00R004V08.02.01F001V09.02.00R001V09.02.02R007
V07.00.00S400V07.02.01R000V07.02.03R000V08.01.00R005V08.02.01F002V09.02.00R002V09.02.02R008
V07.00.00S401V07.02.01R001V07.02.03R001V08.01.00R006V08.02.01F003V09.02.01R000V09.02.02R009
V07.00.00S402V07.02.01R002V07.02.03R002V08.01.00R007V08.02.02R000V09.02.01R001V09.02.03R000
V07.00.00S404V07.02.01R003V07.02.03R003V08.01.00R008V08.02.02R001V09.02.01R002V09.02.03R001
V07.00.00S405V07.02.01R004V07.02.03R004
V08.02.02R002V09.02.01R003V09.02.03R002
V07.00.00S406V07.02.01F001 V07.02.03S400
V08.02.02R003V09.02.01R004V09.02.03R003
V07.00.00S407V07.02.01F002 V07.02.03S401
V08.02.02R004V09.02.01R005V09.02.03R004
V07.01.00R000V07.02.01F004 V07.02.04R000
V08.02.02R005V09.02.01R006V09.02.03R005
V07.01.00R001V07.02.01F005 V07.02.04R001
V08.02.03R000V09.02.01R007V09.02.03R006
V07.01.00R002V07.02.01S400V07.02.04R002
V08.02.03R001V09.02.01R008V09.02.03R007
V07.01.00R003 V07.02.01R005V07.02.04R003
V08.02.03F001V09.02.01R009V09.02.03R008
V07.01.00R004V07.02.01R006V07.02.04R004
V08.02.04R000V09.02.01R010V09.02.03R009
V07.01.00F001V07.02.01R007V07.02.05R000
V08.02.04F001
V09.02.04R000
V07.01.00F002V07.02.01R008V07.02.05R001
V08.02.04R001
V09.02.04R001
V07.01.00F003V07.02.01R009V07.02.05R002
V08.02.04R002
V09.02.04R002

V07.02.01R010V07.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






V09.02.05R006

Security Vulnerabilities

The following security vulnerabilities were resolved in V09.02.05R000 with an OS patch update as of 8/12/2022:

CVE IDSeverityDescription
CVE-2017-12562CriticalHeap-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-39713CriticalProduct: AndroidVersions: Android kernelAndroid ID: A-173788806References: Upstream kernel
CVE-2022-29155CriticalIn 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-1292CriticalThe 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-1664CriticalDpkg::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 HighUse After Free in GitHub repository vim/vim prior to 8.2.
CVE-2022-23038HighLinux 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 HighUse After Free in GitHub repository vim/vim prior to 8.2.
CVE-2019-2201 HighIn 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 HighHeap-based Buffer Overflow GitHub repository vim/vim prior to 8.2.
CVE-2022-1621 HighHeap 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 HighAn 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-23177HighAn 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 HighUse After Free in GitHub repository vim/vim prior to 8.2.
CVE-2022-23039HighLinux 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 HighUse After Free in GitHub repository vim/vim prior to 8.2.
CVE-2021-27219HighAn 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 HighAccess of Memory Location Before Start of Buffer in GitHub repository vim/vim prior to 8.2.
CVE-2020-1712 HighA 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-26720Highavahi-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 HighBuffer 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 Highvim is vulnerable to Heap-based Buffer Overflow
CVE-2017-16932Highparser.c in libxml2 before 2.9.5 does not prevent infinite recursion in parameter entities.
CVE-2022-23040HighLinux 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-23041HighLinux 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-23042HighLinux 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 HighOut-of-bounds Read in GitHub repository vim/vim prior to 8.2.
CVE-2022-0572 HighHeap-based Buffer Overflow in GitHub repository vim/vim prior to 8.2.
CVE-2022-23037HighLinux 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-27218HighAn 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 HighHeap-based Buffer Overflow occurs in vim in GitHub repository vim/vim prior to 8.2.4563.
CVE-2022-2126 HighOut-of-bounds Read in GitHub repository vim/vim prior to 8.2.
CVE-2022-24958Highdrivers/usb/gadget/legacy/inode.c in the Linux kernel through 5.16.8 mishandles dev-&gt;buf release.
CVE-2022-23036HighLinux 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 HighBuffer Over-read in GitHub repository vim/vim prior to 8.2.
CVE-2022-21476HighVulnerability 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 HighAn 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-31566HighAn 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 HighUse 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 HighHeap-based Buffer Overflow in GitHub repository vim/vim prior to 8.2.
CVE-2022-23308Highvalid.c in libxml2 before 2.9.13 has a use-after-free of ID and IDREF attributes.
CVE-2022-27223HighIn 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 HighUse after free in utf_ptr2char in GitHub repository vim/vim prior to 8.2.4646.
CVE-2022-1619 HighHeap-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-21426MediumVulnerability 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-29824MediumIn 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-21496MediumVulnerability 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 Mediumkernel 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-19221MediumIn 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 MediumA 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-26691MediumA 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-21434MediumVulnerability 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-28153MediumAn 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 Mediumlibxml2 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 MediumA 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-26966MediumAn 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-21443LowVulnerability 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).

Security Vulnerabilities in Previous Releases

To view security vulnerabilities in previous releases, refer to the following release notes:

Resolved Issues

Resolved Issues in 09.02.05R007 Release

Severity 1 Resolved Issues

The following Severity 1 issues are resolved in this release:

Issue

ID

SevProblem DescriptionResolution
SBX-1231311

There is an SAM Process core

Impact: The SAM process has encountered a Healthcheck Timeout while executing code in GWFE which has leaked some call blocks.

Root Cause: GWFE has detected a call in an invalid state (the call is in the GCID Hash Table but is not in the CRV Hash Table).

The code handles this call incorrectly, which can result in leaked call blocks.

Steps to Replicate: This issue is not reproducible. 

The code is modified to remove the call block if it is determined that the call block is in either of the CRV Hash Table and/or GCID Hash Table.

Workaround: None.

SBX-1246401

Some call activity was causing an SCM Process core

Impact: The SCM cores while attempting to access a NULL pointer. This occurred in a scenario in which "useCalledPartyInRequestUri" is set in the Egress IP Signaling Profile.

Root Cause: There is a bug in the SIP code which fills in the Called Party information for an outgoing SIP PDU. This code handles the scenario where the "useCalledPartyInRequestUri" is set in the Egress IP Signaling Profile.

This bug results in the code attempting to access a NULL pointer.

Steps to Replicate: Enabling "useCalledPartyInRequestUri" flag in the Egress IP Signaling Profile may trigger an SCM core if the Called URI from the ingress side is not available.

The code is modified so that it does not attempt to dereference the pointer if it is NULL.

Workaround: Disable "useCalledPartyInRequestUri" flag in the Egress IP Signaling Profile.

SBX-1247281

The SBC was passing calls without a successful Registration with the previous RCB

Impact: When multipleContactsPerAor is disabled, the incoming call from a different source address may pass through while the registration is in the "challenge" state.

Root Cause: Missing logic for detecting registration in challenge state

Steps to Replicate: 

  1. Disable the mulitpleContactsPerAor flag and configure the SBC to require incoming call registration.
  2. Send an A register from source A.
  3. Send an A register from source B with registration in the "challenge" state.
  4. Send an A incoming call from source B (should get rejected).
  5. Send an A incoming call from source A (should succeed).

The code is modified to add a registration state challenge to the call to validate and reject the call for this scenario.

Workaround: Enable multipleContactsPerAor flag. 

SBX-1248171

There was an SCM process core

Impact: The SCM process cores when processing a SIP message with Dialog Transparency enabled.

Root Cause: The SCM process cores due to an attempt to use an invalid pointer.

Steps to Replicate: The root cause was found by code inspection. The steps are not reproducible.

The code is modified to ensure the correct pointer is used.

Workaround: Disable Dialog Transparency.

SBX-1248401

Attacker can modify existing user Registration entry resulting call failures

Impact: Calls from the registrar to an endpoint user may have the wrong sigport in the VIA/contact header.

Root Cause: The sigport did not restore properly in RCB in memory after registration refresh while RCB was in a challenge state.

Steps to Replicate: 

  1. Disable multipleContactsPerAor, and configure multiple sigports on the same zone.
  2. Send A register from source address A through the sigport1 (success).
  3. Send A register from source address B through the sigport2 in "challenge" state.
  4. Send A refresh register through the sigport1 (still in "challenge" state and succeeds).
  5. Send an AS call to registered end point (The INVITE has via/contact of sigport2)

The code is modified to restore the RCB to correct sigport when processing received refresh registration while in a challenge state.

Workaround: Enable the multipleContactsPerAor flag. 

SBX-1250201

The SAM Process core on the 925R5

Impact: The SAM Process cores during a long duration soak test.

Root Cause: Procedure call to DFeTranslateGcIdFromList with eAction, set to DFE_TRANSLATE_TO_LOCAL_GCID processed a NULL pointer.

The pstGwFeCtrlStr field in pstRemoteGcIdStr was NULL.

This can occur if DFeTranslateGcIdFromList () is called after the pstGwFeCtrlStr has been deallocated in DFeDeAllocGwCtrl().
DFeDeAllocGwCtrl()>DFeRemoveFromGwList() will set pstRemoteGcIdStr>pstGwFeCtrlStr to NULL but does not free the GCID at this point because it waits for NRM Call Clean up to perform this cleanup. This results in pstRemoteGcIdStr having a NULL pointer in the pstGwFeCtrlStr field. A core results due to a short period of time to access this field.

Steps to Replicate: The steps are not reproducible.

The code is modified to access the NULL pointed and correct the issue.

Workaround: None.

SBX-1252391

Valid registered user cannot receive calls during malicious registration in the "challenge" state for the same AOR

Impact: A call from the registrar is unable to send towards registered end point during the period in time while registration in the "challenge" state.

Root Cause: The SBC was missing logic to support this issue.

Steps to Replicate: 

  1. Disable MulitpleContactsPerAor flag.
  2. Register User A to registrar.
  3. User A sends refresh, registrar response 401.
  4. Registrar tries to send call to User A.

The code is modified to allow a call to go through in this scenario.

Workaround: None.

SBX-125224 | SBX-1253451

PortFix SBX-125224: Calls are dropped by MRFPs five minutes after calls are established

Impact: On the MRFP system with a 2.6GHz CPU, if the server is running for 320 consecutive days and media inactivity detection is enabled, then the SBC notifies media inactivity even if media packets are received.

If "Peer Absence Action" in Packet Service Profile is set to "Trap and Disconnect", the call is disconnected when the call reaches the "Media Peer Inactivity Timeout" value.

This problem is present on all SBC platforms.

Root Cause: The conversion of the last RTP received timestamp to CPU cycle loses the upper 7-bits. This caused the last RTP received to have a lower value (older in time) incorrectly, which in turn triggers the inactivity notification.

Steps to Replicate: 

  1. On a 2.6GHz CPU server, keep the server running for more than 320 consecutive days.
  2. Set the "Media Peer Inactivity Timeout" to 300 seconds.
  3. Set the Packet Service Profile's Peer Absence Action to "Trap and Disconnect".
  4. Make a call with RTP packets for over 300 seconds. After 300 seconds, Media Peer Inactivity is reported and the call is disconnected.

With the fix, Media Peer Inactivity is not reported and the call stays up.

The code is modified to preserve the entire value of the last RTP received timestamp when converting it back to a CPU cycle.

Workaround: If you do not want the call to get disconnected, set the "Peer Absence Action" in Packet Service Profile to "None" or "Trap".

SBX-125379 | SBX-1254751

PortFix SBX-125379: A SAM process core occurred on the Standby SBC

Impact: The SAM process cores on the standby as it was transitioning to Active.

Root Cause: The SAM Process cored because SIPFE was attempting to mirror data when it was still in Standby mode.

The root cause is that there is a very small window of time after a switchover during which the functions that return the Active/Standby state may return inconsistent information.

Steps to Replicate: The steps are not reproducible.

The code is modified to use a different function to determine the Active/Standby state. This prevents us from attempting to mirror data while still in the Standby mode.

Workaround: There is no workaround, but this is an extremely rare occurrence and should not happen again.

Severity 2-4 Resolved Issues

The following Severity 2-4 issues are resolved in this release:

Issue

ID

SevProblem DescriptionResolution
SBX-122836 | SBX-1244662

The Signaling SBC OAM is not coming up

Impact: The OAM node does not come up after starting up the SBC due to a gluster sync running in a loop.

Root Cause: The gluster sync is not completed due to entries created in the <Brick-path>.glusterfs/indices/xattrop/.

Steps to Replicate: 

  1. Shut down the standby OAM.
  2. Enable the gluster read-only mode:
    gluster volume set <vol-name> read-only enable
  3. Try to configure anything on the active OAM (it should fail).
  4. Disable the gluster read-only mode:
    gluster volume set gvol1 read-only disable
  5. Bring back the standby OAM and check if the gluster sync is occurring continuously.

This is a corner case scenario and is reproduced randomly while running the commands above.

The code is modified so that the gluster sync runs for 12.5 minutes. Then, the SBC performs a full heal, which brings the OAM nodes back up.

Workaround: Run the following commands from the OAM where the gluster sync is in a loop:
gluster volume heal <vol-name> disable
gluster volume heal <vol-name> enable
gluster volume heal <vol-name> full

SBX-105995 | SBX-125682 | SBX-1228972

Modifying h248SigPort does not delete an old entry and update; instead, it attempts to append the modified information

Impact: Modifying a h248SigPort of a previously deleted entry throws error saying "Signaling Ip and Port must be Unique".

Root Cause: The old entry was not completely deleted from the database.

Steps to Replicate: 

  1. Create a VMG with h248SigPort with any port number.
  2. Modify the h248SigPort to any other port number.
  3. Modify the h248SigPort to port number used in step1.

The code is modified to completely delete the removed entry so no constraint error occurs when trying to reuse data.

Workaround: None.

SBX-1243702

Observed a sonusSbxDsbcNodeAllocationFailureV6 alarm

Impact: The "sonusSbxDsbcNodeAllocationFailureV6” alarm triggered with no apparent failure condition/event.

Root Cause: This alarm indicates there was a failure allocating a Media resource (XRES) on the M-SBC. However, the exact reason for this failure is undetermined as the M-SBC logs during the failure interval were unavailable or did not show any event.

Steps to Replicate: The steps are not reproducible.

The code is modified to log all failure cases for the M-SBC.

Workaround: None.

SBX-1249723

The SBC does not send TCP-ACK when getting TCP-FIN/ACK from the RCS MSRP peer

Impact: When the TCP connection for an MSRP chat session terminated, the SBC did not completing the TCP message disconnect sequence. This left the remote end session hanging until the TCP timers expired and cleared down the call.

Root Cause: The SBC was abruptly closing the TCP socket before the closing message sequence completed.

Steps to Replicate: Make an MSRP call and monitor the TCP message sequence to confirm the connection correctly closed from both ends.

The code is modified to use and correctly shut down a different socket API once the closing message sequence completes.

Workaround: None.

SBX-1250602

Registration issues where calls were allowed from non-registered IP/Port

Impact: With multiple registrations in the challenge state coming through the SBC and back-to-back INVITES, the SBC may allow a call from an unregistered endpoint. This occurs during a small window while the registration transits from the initiating to the challenge state.

Root Cause: When receiving multiple registrations in the challenge from different sources, the SBC may receive a call from an unregistered endpoint. This is a result of the SBC not validating an authenticated end point source address correctly.

Steps to Replicate: 

  1. Disable MultipleContactsPerAor and configure multiple SIP signaling ports in the same zone
  2. Receive a register from source A address and send to signaling port A
  3. Send refresh from A and in the challenge state
  4. Attempt to register A from different source address, B to signaling port B (Registration is in initiating state).
  5. Run A from source address B try to make a call

The code is modified to validate the authenticated endpoint source address.

Workaround: Enable the Global Signaling flag "multipleContactsPerAor".

SBX-1250782

The SBC sends an INVITE to non-Registered IP/PORT when the RCB in Updating/Terminated state

Impact: The registrar server may send a call to the wrong IAD. This can occur if multipleContactsPerAor is disabled and the registrar server is unable to respond to the updated registration.

Root Cause: The registrar server was unable to respond to the updated register, which causes it to send the call to the wrong IAD. The SBC registration is in the middle of updating/terminate state.

Steps to Replicate: Disable the multipleContactsPerAor and multiple SIGport on the same zone.

Case 1:

  1. Run an A register success from sigport 1
  2. Run an A register from sigport 2, and receive call from registrar

Case 2:

  1. Receive an A register success from sigport 1
  2. Run an A register from sigport 2, and wait for retransmit timeout
  3. Receive a call from registrar

If the registration is in the updating state, reject the call. If the registration timeout and in terminating state, still allow the call to the correct previous authenticated contact.

Workaround: Enable the Global Signaling flag "multipleContactsPerAor".

SBX-119060 | SBX-1251023

PortFix SBX-119060: An OAM generated a core file during Binary application

Impact: The CPX Process cores when the SBC was going down.

Root Cause: The CPX process tries to log to an internal memory structure while the SBC was going down.

Steps to Replicate: The steps are not reproducible.

The code is modified to prevent logging to the internal memory when the SBC is going down.

Workaround: None. 

Resolved Issues in 09.02.05R006 Release

Severity 1 Resolved Issues

The following Severity 1 issues are resolved in this release:

Issue

ID

SevProblem DescriptionResolution
SBX-109466 | SBX-1239581

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: 

  1. Log into the EMA as an admin user.
  2. Navigate to Profiles > Signaling > SIP Adaptor Profile.
  3. Click the "New SIP Adaptor Profile" button.
  4. Provide the following values:
    Name: testSP
    Profile Type: messageManipulation
    for: all me
    Type: Header
          store SIP Param
    named: testSP1
           store the: field value
    to the: local variable
           named: var1
  5. Click the "Save" button.


Expected Results: The SIP Adaptor Profile is created successfully.

Observed Issue: The SIP Adaptor Profile is created successfully but services go down.

The code is modified to allow the CHM code to check for NULL values.

Workaround: None.

SBX-1191031

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-1219691

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:

  1. Install an N-1 system with two configured active S-SBC or I-SBC nodes.
  2. Input the following CLI command:
    request addressContext default cmds optionsPing peerIpAddress <address> 3 sigPort 3 peerPort <port>
  3. Verify that the a status response is received.

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-1233761

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-1235351

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-1235711

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-1238311

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: 

  1. Launch Openstack with a 1-to-1 SBC configured to download the configuration from EMS.
  2. From the EMS, modify the SWe traffic profile configurations - both SBC instances will reboot upon applying the profile.
  3. After the reboot, once both SBC VM applications come up in sync, click "Apply saved changes and close" from the EMS dashboard. This will save the latest SBC configuration file in the EMS.
  4. Rebuild the standby instance with the same versioned image.

    Without the changes, the standby instance comes up with the default traffic profile.
    With the changes, the standby instance will come up with the latest activated traffic profile.

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-1238771

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-1238801

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:

  1. Stage a call between A and B, with B disallowed from receiving INFO.
  2. A sends relay INFO to B.

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-1242111

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:

  1. A call B with multiple codecs (0, 18, 101) and with  Selected Codec in Session Refresh turned on at Egress. Called connect with codec (0, 101).
  2. B re-INVITE (0 101) to A triggers the SBC to answer with the same previous selected codec (0).
  3. B re-INVITE (0 18 101), and A answers 0 only.
    The SBC only sends 200 OK(0) and is not able to increment the session version.

The code is modified to reset the internal flag when the SBC sends SDP.

Workaround: Disable the Selected Codec in Session Refresh.

SBX-1244501

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

SevProblem DescriptionResolution
SBX-120845 | SBX-1218363

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-1232882

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.
Configure an Egress Route with FTT=ignoreDetectAllowFaxRelay.

To re-create the issue:

  1. Set up an A-B transcoded call via the SBC.
  2. B sends re-INVITE to convert the call to pass-thru at the SBC.
  3. B sends T.38 re-INVITE to the SBC.

Expected Result: The SBC accepts T.38 re-INVITE and the call transitions to a fax call.

Actual Result: The SBC rejects the T.38 re-INVITE.

The code is modified to apply the fax tone treatment configuration during mid-call modification as well.

Workaround: None.

SBX-1219722

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:

  • The NRS task monitors IP stack on both active and standby nodes. However, the NRS only processes the kernel ARP change event on the active node. The NRS uses the legacy routine SmaActiveMns() to determine whether the local node is in active mode. SmaActiveMns() checks the local node's redundancyRole, but the node's redundancyRole is only updated during the AMF switchover event. So if the kernel ARP change event came before AMF_EVENT_SWITCHOVER, then the SmaActiveMns() routine will return FALSE, and the kernel event will drop.
  • The BRM task incorrectly sets the hot standby mode to FALSE because it used SmaIsCloudOrNto1() instead of SmaIsNto1() to determine the hot standby mode. Because of this, the BRESs were not activated properly on the standby node.

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-1230732

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-1243942

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: 

  1. Run a call that sends bundled media: audio, video and data channel.
    1. Answer accepts bundling on all three.
    2. While the call is running, command "show status global callDetailStatus" should show egressDtlsStream3' => 'RELAYED.
  2. Verify the SBX-121550 fix in the steps below:
    1. Make RTP to SRTP configuration.
      The set up should be HA. The RTP leg should not have any security PSP attached.
    2. Configure the session timer as the session expires for SRTP leg first.
    3. Establish an A--B call and then perform switchover.
    4. Wait for a switchover to occur.
    5. Wait for the session timer to expire and see an INVITE towards SRTP to successfully answer with a 200 OK.
    6. Wait for an INVITE towards the RTP side.

Observed results: The SBC sends BYE.
Expected results: The SBC sends INVITE to ingress.

The code is modified to revert to the changes in SBX-121550.

Workaround: None.

SBX-1238262

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: 

  1. Start a call.
  2. Display "show status global callMediaStatus" and verify that StunDtlsPacketsReceived is correct.
  3. Stop the call.
  4. Gather CDR and verify that StunDtlsPacketsReceived is correct.

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-1241122

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 DNS scenarios, since the FQDN is resolved to IP, the DNS request is sent to DNS server for getting the IP. The DNS response from the DNS server is sometimes delayed. On the SIP stack – if the DNS response is immediate then SIP stack will form the outgoing INVITE with the received IP addresses from the DNS server.

If the DNS response is delayed, SIP stack will form the outgoing INVITE without IP addresses and saves it. Once the SIP stack receives the IP addresses, it de-constructs the saved outgoing INVITE message and re-constructs it with the received IP addresses.

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-1245272

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.

Resolved Issues in 09.02.05R005 Release

Severity 1 Resolved Issues

The following Severity 1 issues are resolved in this release:

Issue

ID

SevProblem DescriptionResolution
SBX-122469 | SBX-1229151

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: 

  1. Configure the SBC for passthrough SRTP calls.
  2. Set RTCP mode to passthrough.
  3. Enable the ssrcRandomizeForSrtp flag in PSP.
  4. Make a call and send in various valid and invalid format RTCP packets for the call, including an RTCP packet with a single-chunk SDES with non-zero pad bytes at the end.

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-1209821

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-1234551

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: 

  1. Enable call trace through the EMA/CLI, and then disable it with a stop command.
  2. Perform a switchover and check the status on the new active SBC.
  3. Try the same with the Call filter enabled.

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-1223311

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-1202181

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-1228651

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-1231751

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-1224031

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:

  1. Take a backup with the existing config.
  2. Restore the backup or upgrade to the next release.
  3. Test the calls with tgWithCallingNumber as criteria.

The code is modified to populate the toll-free prefix info table properly for restore and upgrade cases.

Workaround: None.

SBX-1230811

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: 

  1. Enable DTMF Trigger Profile.
  2. Make an ICE/DTLS call.
  3. Send an RFC2833 digit packet to the SBC within the ICE/DTLS call.

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-1232451

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: 

  1. Enable Direct Media, ICE support, multipleAudioSupport.
  2. A call B with multiple audio streams+ICE.
  3. B re-IVITE with multiple audio stream+ICE. The SBC may core.

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-1237201

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:

  1. Make a SRTP call with egress endpoint behind the NAT.
  2. Switch to a different media server to play the tone via re-INVITE, and check the audio at egress endpoint.

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-1236281

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:

  • A call is GW-GW and contains P-Sig-Info
  • Transparency Profile on Egress GW contains 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
- INVITE contains P-Sig-Info
- Transparency Profile on Egress GW contains P-Sig-Info header

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-1226061

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-1234111

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:

  1. Assign a valid SSN/ROC for the new RID.
  2. Ensure the SSN value is greater than, or equal to, the last saved SSN on the deactivation for anti-replay protection.

Workaround: Enable “SSRC Randomize For Srtp”.

Severity 2-4 Resolved Issues

The following Severity 2-4 issues are resolved in this release:

Issue

ID

SevProblem DescriptionResolution
SBX-1231422

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: 

  1. Ingress UAC endpoint offers DTMF 8K PT 100 to SBC1 , SBC2 offers DTMF 8K PT 101 to UAS endpoint (SIPP).
  2. Egress UAS endpoint(Sipp) answers without DTMF/8000 (DTMF) to SBC 2.
  3. SBC 1 answers with DTMF PT 100 to the Ingress UAC endpoint (SIPP).
  4. Call is setup as xcoded between SBC 1-SBC2.
  5. Egress UAS endpoint re-INVITES to add DTMF PT101 to SBC 2.
  6. SBC 1 re-INVITES with PT 100 to Ingress UAC endpoint.

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-1223222

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-1232253

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:

  1. Log into EMA as admin user.
  2. Go to All -> Profiles -> Digit Parameter Handling -> Prefix Profile -> Entry.
  3. Under the Entry list, select any matching pattern starting with '+'.

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-1225162

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:

  1. Setup a AMRWB+t140 =>g711 (baudot) call.
  2. Send a t140 packet with a t140block consisting of following characters. This is the character string that was observed in crash.
    "q1q1q2q1q1q221q1q1q1q1q1q2 1q"

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.

In the meantime, the NOTIFY arrived and it was processed immediately based on the same digits in the tag parameter i.e. tag=gK18e.

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-1232543

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:

  1. Run user-config-export on one OAM node.
  2. Update the configuration to fit with the new OAM node.
  3. Import the configuration into the new OAM node.

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-1222802

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:

  1. Set up a call with RTP inactivity of 40 seconds with a trap and disconnect. This should result in approximately 1,000 calls with a 40-second gap between calls.
  2. Attach a LRBT and duration of call should be around 42-44 seconds.
  3. Search for repeated occurrences of logs "not known by NRM".

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: 

  1. Establish a SIP-SIP call with G711 U law.
    1. Enable "Minimize Relaying Of Media Changes From Other Call Leg" flag in Ingress IPSP.
    2. Enable "Unknown Header" transparency in IPSPs.
  2. After establishing the session, send a re-INVITE from the Egress peer with G711U law for call hold (a=sendonly).
  3. Send BYE from the Ingress peer with Unknown Header.
  4. Verify if the unknown header in BYE message is sent transparently to the other leg.

The code is modified to add the call control block based on the call direction.

Workaround: None.

SBX-1193192

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-1227342

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: 

  1. Configure the SBC to send unsolicited call notifications to Application Servers.
  2. Run a load test with Call Notify functionality enabled and force a switchover.
  3. "set addressContext <ac name> zone <zone name> sipTrunkGroup <tg name> services sipCallNotificationMetadataProfile <meta data profile name>"
    Note: This is a race condition that will only occur if Notifications are being processed during a switchover or sync.

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-1237132

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: 

  1. Run an HA set up.
  2. Enable the ssrcRandomizeForSrtp.
  3. Make a long duration RTP to SRTP transcode call, and then check audio.

  4. Switch over to the standby node after the call has been up for over 25 minutes.

  5. Revert back, and then check audio.

  6. Repeat above step 1 to 5 for a long duration pass-through call.

  7. Repeat above step 1 to 5 for a short duration transcode call.

  8. Repeat above step 1 to 5 for a short duration pass-through call.

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-1236272

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 '&amp' instead of '&lt;' and the \\r\\n => double backslash escaped properly but display as a single backslash in HTML.

Steps to Replicate:

  1. Log into the EMA and navigate to the SMM screen.
  2. Select the profile that includes the characters < \\.121394
  3. Click the View CLI button for the selected profile.

The CLI commands display as expected.

The code is modified to replace those occurrences with correct responses to address the issue.

Workaround: None.

SBX-1234592

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-1213942

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:

  1. A calls B and the call is connected.
  2. B puts A on hold.
  3. B (you can also assume B' as User C) calls D and the call is connected.
  4. B sends an off-hold INVITE to the SBC.
  5. C sends REFER with Replaces of B to the SBC.

The code is modified so that the internal offer-answer timeout is handled to avoid call transfer failure.

Workaround: None.

SBX-1235953

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
                 <-Notify
                 <-200 Subscribe

The code is modified to relay a 200k Subscribe to the Ingress service group id.

Workaround: None.

Resolved Issues in 09.02.05R004 Release

Severity 1 Resolved Issues

The following Severity 1 issues are resolved in this release:

Issue

ID

SevProblem DescriptionResolution
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.

Example sysdump syslog failure indication:

<27> 1 2022-08-30T09:45:05.191451-04:00 vsbcSystem lwresd 29904 - - could not get query source dispatcher (10.0.4.248#988)
<26> 1 2022-08-30T09:45:05.191769-04:00 vsbcSystem lwresd 29904 - - loading configuration: address not available
<26> 1 2022-08-30T09:45:05.191962-04:00 vsbcSystem lwresd 29904 - - exiting (due to fatal error)
<29> 1 2022-08-30T09:45:05.195760-04:00 vsbcSystem lwresd 29904 - - running

Steps to Replicate: 

  1. Set up the LWRESD profile to use the SIP signaling interface.
  2. Bring the SIP signaling interface mode or state to outOfService/disabled state.
  3. Restart the SBC application.

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.

The LWRESD Profile now maintains two different bit masks for the interface mode and state. Consequently, after upgrading to an SBC version that includes this fix, use the following steps if the LWRESD Profile type is set to signaling IP:

  1. Set both the state and mode of the sipSigPort that is configured in the LWRESD profile to disable and outOfService respectively.
  2. Set both the state and mode of the sipSigPort that is configured in the LWRESD profile to enable and inService respectively.

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: 

  1. Delete the default route for eth2.
  2. Re-run the HFE script to ensure it completes correctly.

The code is modified to:

  1. Correct the 'Debug SBC SWe in AWS' page on how to correctly reconfigure the interfaces.
  2. Handle finding the gateway IP, when the default routes are not available for the interface.

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: 

  1. Enable NAPT learning on egress SRTP call leg.
  2. There is no S-SRC change.
  3. Run call hold and resume test.

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

SevProblem DescriptionResolution
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: 

  1. Configure an Advanced SMM with dialog variables and dialog transparency.
  2. Run an A call.
  3. B reply 1xx and wait for the timeout for the SBC to tear down the call.

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: 

  1. User A (TCP) calls to user B.
  2. User A disconnects/closes the TCP connection.

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:

  1. Set the country code as 81 in TG.
  2. Run a basic call.

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:

  1. Login to EMA.
  2. Go to All -> Global -> Call Trace.
  3. Level 4 Trace Messages configuration is missing in Call Trace Status and Settings.

Root Cause: Level 4 Trace Message has been added as an Enhancement in EMA.

Steps to Replicate:

  1. Login to EMA.
  2. Go to All -> Global -> Call Trace.
  3. Go to Call Trace Status and Settings.
  4. Choose All Messages or Received Invite under Level4 Trace Messages.

The code is modified to add Level 4 Trace Message configuration:

  • allMessages - Level 4 call traces contain all matching messages.
  • rcvdinvite - Level 4 call traces contain only matching received INVITE messages.

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: 

  1. Go to SBC Configuration Manager in the EMA.
  2. Navigate to pathCheck screen.
  3. Select addressContext -> Zone -> IP Peer values.
  4. Scroll down to Commands section.
  5. Select value from the dropdown and click Select.
    The SBC manager starts accepting requests from EMS in the URL.

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: 

  1. Set the allowed transport on sipSigPort as TCP.
  2. Send registration over TCP and INVITE over UDP from the same script.

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: 

  1. Create a rest request that creates a sipSigPort and three sipTrunkGroups.
  2. Execute that command.
  3. Verify that all items are correctly added to the confd database.

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: 

  1. Run negative call tests to reproduce and verify the fix.
  2. Make at least 65 of those calls with a remote IP address that is not reachable (i.e., the NRS does resolve the route).
    Note: Considering the NP's badRidCb error reporting threshold is set to 64, ensure to run at least 65 calls in order to see the error in the logs.

The code is modified to allow the BRM code to set disableRtcpRid flag properly in the RTCP Gen disable command.

Workaround: None.

Resolved Issues in 09.02.05R003 Release

Severity 1 Resolved Issues

The following Severity 1 issues are resolved in this release:

Issue

ID

SevProblem DescriptionResolution
SBX-1218541

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:

  1. Enable usePortRangeFlag on egress TG.
  2. Establish a new registration.
  3. Wait for registration to expire (For example, set expiration value to 2100s. You can use the tail command to check the info level DBG log to see the retry message starting).
  4. When the retry timer starts, run scripts to send at least 10 subscribe requests.

In addition to above tests, please also verify following:

    1. Subscribe refresh is working as expected.
    2. Subscribe request when port range is disabled.

Corrected the logic which only checked registration status when the usePortRangeFlag feature is enabled.

Workaround: None.

SBX-1218891

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.

Resolved Issues in 09.02.05R002 Release

Severity 1 Resolved Issues

The following Severity 1 issues are resolved in this release:

Issue

ID

SevProblem DescriptionResolution
SBX-1211211

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:

  1. Provision the SBC to perform a SIP REC.
  2. Run SIP REC calls.
  3. Bring up the SBC's Standby system and/or perform an LSWU upgrade.

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-1210311

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-1182901

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:

  1. Launch 1:1 Openstack SBC with V09.02.03-R0 Build, registered with EMS V13.02.06R000.
  2. Log into Active SBC and change sweConfiguration profile to large (both SBCs go for a reboot).
  3. Run saveAndactivate from the SBC CLI -- EMS gets synced with the SBC's configuration.
  4. Log into Openstack console, and rebuild both Active and Standby SBC instances with same V09.02.03-R0 build image.
  5. Log in to the active SBC and check sweConfiguration profile – the profile will be shown as small, rather than large.
  6. Try activating the standard_passthrough Profile – none of the SBCs go for reboot for activation of traffic profile.
  7. Reboot both active and standby SBC instances manually - only the old active will come up with the activated traffic profile from the previous step.

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:

  1. Log in to SBCs as root user and remove the marker file from both active and standby instances:
    rm -f /opt/sonus/conf/swe/capacityEstimates/.skipRebootMarker
  2. Re-activate the large sweConfigProfile from the active SBCs CLI console by running the following command:
    set system sweConfigProfileSelection name large
SBX-1217231

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:

  1. Establish a new SIP registration, followed by a new SIP subscription for an event of your choice.
  2. Verify that the SBC relays the SIP SUBSCRIBE to the registrar and that the SBC doesn't reject the SIP SUBSCRIBE with a SIP 403 Forbidden response.

Reverted the SBX-119915 code change.

Workaround: None.

Severity 2-3 Resolved Issues

The following issues are resolved in this release:

Issue

ID

SevProblem DescriptionResolution
SBX-106015 | SBX-1204932/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:

  • SBX-106015 (Sev. 2): The UDP packets for the 14.4 rate are 84 bytes instead of 72 bytes corresponding to a 40 ms payload. This is not a bug, but is considered an unnecessary change that was introduced as a part of T.38 3.35 (This is getting rolled back to the original 72-byte packet size).
  • SBX-120493 (Sev. 3): Certain T.38 endpoints send TCF much earlier relative to DCS packets (e.g. fax server, as indicated by 'SIP User-Agent: VFAXSUA/IPFAX-9.0.7806.611'). The current stack handles it by dropping TCF while its still modulating the DCS signal. This results in a shorter modulated TCF, which causes the receiving fax machines to indicate a failure via an FTT message.

Root Cause:

  • SBX-106015: The T.38 stack upgrade to 3.35 induced an unnecessary change. While this is not a bug, the best approach is to avoid unnecessary changes.
  • SBX-120493: Incorrect DCS message lengths and TCF message timings (TCF messages arrive while the stack is still modulating DCS) are sent from some T.38 endpoints.

Steps to Replicate:

SBX-106015:

  1. Establish a. 14.4 rate T.38-G711 fax call so that the SBC stack G.711 leg is Ingress.
    The SBC stack then generates TCF UDPTL packets.
  2. Using wireshark, inspect the media packets payload size.
    1. Without the fix, the payload size for media packets is 82 bytes.
    2. With the fix, the payload size is 72 bytes.

SBX-120493:

  • If a failure occurs with VFAXSUA/IPFAX type device, and the TCF packets arrive before modulating an earlier DCS, than the generated TCF tends to be shorter than the standard 1.5 seconds.
  • With this fix, the TCF duration matches the actual received TCF duration payload.

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-106015: N/A
  • SBX-120493: No workaround


SBX-121662 | SBX-1124372

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-1144222

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:

  1. Set up basic SIP-SIP call.
  2. Configure sharedCacLimitsPool.
  3. Attach the sharedCacLimitsPool to an Ingress Trunk Group.
    TrunkGroupStatusStats does not contain an Entry for sharedCacLimitsPool.

The code is modified to skip the TrunkGroupStatusStats entry for sharedCacLimitsPool.

Workaround: None.

Resolved Issues in 09.02.05R001 Release

Severity 1 Resolved Issues

The following Severity 1 issues are resolved in this release:

Issue

ID

SevProblem DescriptionResolution
SBX-1213001

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-1212981

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-1209601

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:

  1. Configure call disconnected treatment
  2. A (prack support) call B, B answer 486.
  3. The SBC sends 18x with sdp to A for disconnected treatment.
  4. A send new offer in PRACK.

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-1211691

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:

  1. Make a transcoded call with a different DTMF PT on the ingress and egress legs.
  2. Send DTMF digit events in each direction and verify the DTMF PTs are correctly modified.
  3. Make a pass-through call with different DTMF PTs on the ingress and egress legs
  4. Send DTMF digit events in each direction and verify the DTMF PTs are correctly modified.

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-1189461

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:

  1. Make an A-to-B call.
    Since A is the target, signaling Interception starts.
  2. Send a re-invite from B (egress) side for a call hold.
    The SBC sends a service instance message with service name "Call_Hold" and called party number.
  3. Send a re-invite from B (egress) side for call retrieve.
    The SBC sends a service instance message with service name "Call_Retrieve" and called party number.

Test-2:

  1. Make an A-to-B call.
    Since A is the target, signaling Interception starts.
  2. Send a re-invite from A (ingress) side for call hold.
    The SBC sends a service instance message with only service name "Call_Hold".
  3. Send a re-invite from B(ingress) side for call retrieve.
    The SBC sends a service instance message with only service name "Call_Retrieve".

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-1209791

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

SevProblem DescriptionResolution
SBX-114422 | SBX-1215092

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: 

  1. Set up a basic SIP-SIP call.
  2. Configure sharedCacLimitsPool.
  3. Attach the sharedCacLimitsPool to Ingress Trunk Group.

TrunkGroupStatusStats does not contain an Entry for sharedCacLimitsPool.

The code is modified to skip the TrunkGroupStatusStats entry for sharedCacLimitsPool. 

Workaround: None.

SBX-1196122

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-1205602

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-1189722

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:

Usage: SbcSftp <<IP>> <<port>> <<username>> <<upload/download>> <<local SBC path>> <<remote Server path>> [<<-I certificate file with path>>]

The certificate option is in the end just to keep the same order for existing options.

This should avoid the need to expect script to provide password input. It is also recommended to run the SbcSftp command via "nohup" to make it completes even if the linux ssh session terminates e.g.:

nohup SbcSftp

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-1208953

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:

  1. Make a G711 to GPU AMRWB call.
  2. Configure G711 MULAW with Silence Suppression enabled (CN with PT 13) in SDP.
  3. Stream the attached PKT file (MULAW_p20_SBX102895.pkt) on G711 leg. This file corresponds to field capture srcPort45200.pcap which is attached in the JIRA.
  4. Capture the output on AMRWB leg.

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-1207712

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.
But as per initial impementation, ssrcRandomizeForSrtp does not apply to DTLS/SRTP.

Steps to Replicate:

  1. Enable ssrcRandomizeForSrtp in packet service profile.
  2. Make a long duration RTP(AS side) to DTLS/SRTP passthrough call.
  3. After 27 mins, trigger AS switchover to sent an INVITE w/ Replaces to the SBC.
  4. Check for one way audio.

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-1194682

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: 

  1. Enable "Difference in DTMF" flag under p2p control.
  2. Setup a pass-through call with DTMF PT=110.
  3. Send a late media re-invite from UAS.
  4. The SBC sends offer to UAS with 2833 PT.
  5. UAS sends answer SDP in ACK but without 2833 PT.
  6. The SBC generates offer towards UAC with configured DTMF PT (instead of 110). However, after this fix, SBC continues to uses the negotiated PT (110) on ingress leg.

The code is modified to use the already negotiated DTMF PT during mid-call modifications.

Workaround: None.

SBX-120822 | SBX-1180732

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.

  • When the SBC sends INVITE/UPDATE to UE, the port in Via and Record-Route headers are protected port.
  • When the SBC sends NOTIFY to UE, the port in via is protected port, but port in record-route is 5060.
  • When the SBC sends 180/183/200 to UE, the port in via is protected port, but port in record-route is 5060.
  • When the SBC sends BYE to UE, the port in via is 5060, the SBC was not.

Per test result and observation:

  • When the SBC sends INVITE/UPDATE to UE, the port in Via and Record-Route headers are protected port.
  • When the SBC sends NOTIFY to UE, the port in via is protected port, but port in record-route is 5060.
  • When the SBC sends 180/183/200 to UE, the port in via is protected port, but port in record-route is 5060.
  • When the SBC sends BYE to UE, the port in via is 5060.

Currently, SMM is used to store the port-s in variable, then:

  • If via port is 5060 for request sending by SBC to UE, then uses SMM to change the port in via to protected port.
  • If record-route is 5060 in 18x~200 for response sending from SBC to UE, then use SMM to replace it with protected port.

Root Cause: The SBC was using the wrong port information due to an interaction with contact header transparency logic.

Steps to Replicate:

  1. Setup IPSEC config on ingress interface(LIG1).
  2. Enable passCompleteContactHeader transparency flag.
  3. Setup basic SIP-SIP call.

    Check that the IPSEC port is used correctly in via and record-route headers.

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-1209713

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: 

  1. Enable FIPS mode.
  2. Perform upgrade.
  3. Verify if services are up.
  4. Verify if FIPS mode is enabled.

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.


Resolved Issues in 09.02.05R000 Release

Severity 1 Resolved Issues

The following Severity 1 issues are resolved in this release:

Issue
ID

Problem DescriptionResolution
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.
The hardware queue is quickly filled up when there is traffic burst, and due the latencies caused by scheduling, SWe_NP could not read the packets in time, and the previous packets were overwritten in the hardware queue.

Steps to Replicate: The reproduction of this test requires simulating the traffic burst.
One way is to use multiple call generators.

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.

Sample command line to run 100x:
[root@yf04a np]# x=1; while [ $x -le 100 ]; do echo $x; date; ./np_mem_dump.pl/var/log/sonus/np/npMem0_d$x.log >& npdump.log ; date; $(( x++ )); done

Note: This command creates npMem0_d[1..100].log files and could fill up the disk.

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.

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 sysdump.

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:

  1. Enable e2e re-INVITE.
  2. Run multimedia SDP applications.
    After the call connects with both media, both ends try to re-INVITE with one media active that will trigger the SBC to send 491 and re-INVITE.

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.
The memory corruption occurred because the code was written into a memory block after it had been freed. This appears to have occurred when the SRS gets blacklisted during setup and the call needs to route advance to the next SRS.

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 exact call flow that will causes the pointer to be NULL when entering the affected code is unknown.
(With this fix, the code will not core in the future if the pointer is NULL.)

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.
This issue can show up with a number of different stack traces (depending on the call flow).

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.

This change causes new cores because there is code that is accessing pktCcb pointer after it was set to NULL (in the past it was safe to assume that pktCcb pointer would not be NULL).

This bug was introduced in the 9.2.4R3 release.

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.
The CPX process deadlocks while calling CpxTrunkGroupMediaIpSecondaryInterfaceGroupNameValidate to validate the SecondaryInterfaceGroupName while the customer was making lots of calls to get the authPassword, for example:

show table addressContext <context> zone <zone> sipTrunkGroup <trunkgroup> signaling authentication authPassword

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:
show table addressContext <context> zone <zone> sipTrunkGroup <trunkgroup> signaling authentication authPassword

In another CLI session, do a:
set addressContext <context> zone <zone> sipTrunkGroup <trunk group> media mediaIpSecondaryInterfaceGroupName <groupname>

Observe that the CPX does not crash.

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:

  1. Configure the following three IPACL rules:
    rule 1: Define the LIF and the ipInterfaceGroup that contains this LIF, and assign the smallest precedence value among three rules.
    rule 2: Use the same ipInterfaceGroup as rule1, protocol = ICMP, assign precedence value > rule1, do not define as ipInterface.
    rule 3: Same as rule 2, except assign the precedence value > rule2.
  2. Take the LIF OOS and disable.
  3. Restart the application.
  4. Enable and in-service LIF.
  5. Ping the next hop address through pkt port of the LIF.
  6. Check the stats using the following command:
    "show table addressContext ADDR_CONTEXT_1 ipAccessControlList ipAclRulesByPrecedence"

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: 

  1. Run a TLS load that will attempt to use an expired PKI security certificate (tlsProfile includes the name of the security certificate).
  2. Look for the following messages in the DBG logs:

100000B.DBG:076 05262022 000010.545176:1.02.00.18170.MAJOR .SEC: *Certificate expired

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: 

  1. Make a SRTP-to-RTP call between A and B through the SBC under test.
  2. A puts B on hold and calls C through a different SBC/device.
  3. A bridges B and C together and uses a late-media re-INVITE towards B to modify the original connection media IP address with the C's media IP address.
  4. The SBC sends a re-INVITE with a SDP offer to B.
  5. Once the SBC receives a 200 OK with a SDP answer from B, it starts sending the SRTP packets to C's connection media IP address.
  6. The first SRTP packet sent to C has a SSN of around 1000 and the second SRTP packet has a SSN of less than 256. C discards all received SRTP packets until the SSN reaches the highest recorded SSN, which is 1000.

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:

  1. Late media call
  2. Ingress sends latemedia re-INVITE immediately after sending ACK for the first Invite.

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:

Ingress Route PSP -
Fax Tone Treatment: FAX_TONE_TREATMENT_FALLBACK_G711

Egress Route PSP -
Fax Tone Treatment: FAX_TONE_TREATMENT_IGNORE_DETECT_ALLOW_FAX_RELAY

PSP -> Enable flag "Apply Fax Tone Treatment"

  1. Setup G.722 pass-through call with SRTP on ingress leg.
  2. Once audio call is stable, send T.38 re-invite from UAS.
  3. The SBC sends G711 fax re-Invite towards ingress leg.

Without fix: The re-Invite at step 3 is sent with out SRTP.

With fix: The re-Invite at step 3 is sent with 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.

  1. A (PRACK support) call B, B answer failure response (ex: 486)
  2. SBC sends 183 to play disconnected treatment.
  3. Peer sends PRACK with SDP new offer.

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:

  1. Configure the latemedia passthrough, enable e2e ACK, and e2e re-INVITE
  2. Run a late media call
  3. Egress sends a re-INVITE to Ingress
  4. Ingress answer 200 OK
  5. Egress answer ACK

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.

This code path is executed when writing SIP protocol specific fields into accounting record.

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: 

  1. Make SIP-SIP call setup with G711 U law.
  2. Enable "Minimize Relaying Of Media Changes From Other Call Leg" flag in Ingress IPSP.
  3. Enable "Unknown Header" transparency in IPSPs.
  4. After session establishment, send Re-INVITE from Egress peer with G711U law for call hold ( a=sendonly).
  5. Send BYE from Ingress peer with Unknown Header.
  6. Verify if unknown header in BYE message is sent transparently to other leg.

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: 

  1. Prepare a SIP-to-SIP call setup with INVITE with replaces from the client side having the same call ID for original INVITE and INVITE with replaces.
  2. Check if the INVITE with replaces is replacing the original call and if the lookup is successful or not.

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: 

  1. Enable the UNENCRYPTED_SRTCP in the cryptoSuiteProfile.
  2. Enable the INFO level DBG logging and make calls.
  3. Check the DBG log for NpMediaRidEnable and NpMediaFlowEnable messages
  4. Ensure that:
    • RTCP = cipher/size 0x8000000/0x40000
    • RTP = cipher/size 0x6000000/0x40000

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:

  1. Set preferred DTMF to 101 and enable different2833PayloadType flag.
  2. From Ingress Peer send PCMU and AMRWB with 8,000 PT 101 and dtmf PT 16,000 102.
  3. Egress Peer send AMR-WB 102 in answer.
  4. The call should be pass-through with DTMF 102.


TC2:

  1. Set preferred DTMF to 101 and enable different2833PayloadType flag.
  2. From Ingress Peer send PCMU and AMRWB with DTMF 8,000 PT- 104 and DTMF16K PT - 102.
  3. Egress Peer send AMR-WB 102 in answer.
  4. The call should be pass-through with DTMF 102.

TC3:

  1. Set preferred DTMF to 101 and enable different2833PayloadType flag.
  2. From Ingress Peer send PCMU and AMRWB with DTMF 8,000 PT- 104 and DTMF16K PT - 105.
  3. Egress Peer send AMR-WB 102 in answer.
  4. The call should be transcoded for difference in DTMF - 102 in Egress and 105 in Ingress.

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: 

  1. Log in to CLI.
  2. Created Routing Label with following special characters (+:.@-) from CLI.
  3. Log in to the EMA.
  4. Navigate to Routing and select the Routing Label and edit the same.
  5. Edit is successful.

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: 

  1. Run the Customer configuration.
  2. Run the Customer Scenario DelayedRBT enable with Tone continuation and Monitoring profile is enable.
  3. Run an additional update to stop after an UPDATE with media = inactive.

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.

Issue 2: The wrong codec is used after the call is established.

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.

However, it does not preserve/re-use the transcoding resources which results in wrong media being played towards Ingress EP.

Steps to Replicate: 

  1. Configure the SBC with Basic call configuration.
  2. Attach TONE_GENERATION_CRITERIA to Tone and Announcement Profile.
  3. Configure earlyMedia in Egress TG.


Procedure:

  1. The SBC receives INVITE with 0,8,18 from Ingress EP.
  2. The SBC receives 180 Ringing with 0 from Egress EP.
  3. The SBC receives UPDATE from Ingress EP with 18 and with new media port.
  4. The SBC receives 200 OK for INVITE without SDP from egress EP.

Expected Results:

  1. The SBC will forward the INVITE to Egress EP.
  2. Once the SBC receives 180 with SDP, it will forward to Ingress EP.
    The SBC starts monitoring RTP from Egress. Once timeout happens, the SBC will start generating tone towards Ingress EP.
  3. Once an UPDATE is received, the SBC will change the codec to 18 and port to new media port.
  4. The SBC receives 200 OK for an INVITE.
    The SBC will use the same codec combination used during tone play.
    A call gets established successfully as G729-PCMU.

The code is modified for the following issues: 

Issue 1: The SBC now changes the port towards Ingress EP.

Issue 2: The correct media is played at the tone play Ingress EP, based on whether or not the call needs transcoding resources..

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: 

  1. Perform an upgrade on an SBC HA 1:1 on public cloud (such as AWS) from a pre-9.2 to a 9.2 release.
  2. Revert the SBC HA 1:1 to a pre-9.2 release.

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: 

  1. Bring up SBC HA application with a pre-9.2 release on public cloud, such as AWS.
  2. Upgrade both active and standby SBC to this release using the recommended upgrade method.
  3. Revert the SBC application to pre 9.2 release.
  4. After revert operation, check to see if application is coming up fine on both active or standby.
  5. If the application is stuck and not able to get the assigned role, stop SBC application on both active and standby nodes using ‘sbxstop’ command.
  6. Remove the following file/directories from both active and standby SBC if existing:
    1. rm -rf /home/cnxipmadmin/peerDynamicHANewComps
    2. rm -rf /opt/sonus/sbx/openclovis/var
  7. Start the SBC application on both active and standby nodes using ‘sbxstart’ command.
  8. Check to ensure that application is coming up fine on both nodes.
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: 

  1. Register an SBC instance with an EMS.
  2. Unregister the same SBC instance with the EMS.
  3. Observe that the ENM process does not crash.

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: 

  1. Log in to the EMA of an active SBC and Enable CDR Viewer.
  2. Run a call with a duration (about 50 seconds) such that it gets stopped before EMA is started in the standby SBC after the switchover.
  3. Initiate a switchover.
  4. Log in to EMA of a standby SBC (which is the active now).
  5. Navigate to CDR viewer screen.

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: 

  1. Enabled INFO debug logging.
  2. Establish a simple transcode call with RTP monitoring enabled on egress side.
  3. Check the DBG log for the port number in message "NpMediaFlowModify: Src RTP port modified port 5004 enSrcVal 0x1"

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: 

  1. Set up a GW-GW call from GSX using ISUP as ingress
  2. Enable Signaling > Generate or Replace PCV

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: 

  1. Install the SBC application on an instance with a vCPU size greater than 40.
  2. Make sure the application starts and there are no core dumps observed.

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: 

  1. Replicate the issue by running a basic SIP-to-SIP call and removing any mandatory header field.
  2. Check if all of the 86 sub fields are getting populated in CDR of 45th field (Ingress Protocol Variant Spec Data).

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: 

  1. Run an IMS AKA registration over UDP.
  2. Check netstat on the SBC to see if the negotiated protected ports are opened on both UDP and TCP.

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: 

  1. Run sbcDiagnostic 2 command as linuxadmin user in the cloud SBC.
  2. Try copying generated sysdumps from /opt/sonus/external/ location.

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: 

  1. Set up two SBCs that communicate over the GW-GW.
  2. Place a GW-GW HPC call scenario call.
  3. Observe that the IpSockAddr and Port fields are not 0 after running the global callDetailStatus status command.

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:

  • Add a default value of 60 seconds for the DNS record when the DNS request is sent by the Agent to the Client.
  • In the error case, delete the DNS record when the timer expires in order to recover.
  • In the working case, reset the expiration time to the TTL received in the DNS data.

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: 

  1. Log in to the Azure CLI.
  2. Attempt to upgrade the Azure SBC using Ribbon IaC.
  3. The upgrade fails due to lack of credentials.

The code is modified to install Azure CLI version 2.24.0

Workaround: 

  1. Uninstall the current Azure CLI version.
  2. Install the Azure CLI version 2.24.0 using the system package manager.
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: 

  1. The arithmetic exception is the result of a denominator of a divide operation with a zero value.
  2. The denominator is a sum of two energy values, both of which are expected to be positive. The issue occurs when one of the energy values is negative.
  3. The negative energy value is attributed to the incorrect handling of overflow when computing the energy value. The incorrect handling of the overflow makes a large positive number appear to have a negative value.

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:
Ingress is sending UPDATE and setting Media Port to ZERO.

1> For m-line application
The SBC is rejecting this UPDATE with 488.

2> For m-line Audio
The SBC is passing this UPDATE to other side with valid port and c-line is present.

3> For m-line Video
The SBC is passing UPDATE to other side but removing C-line

The SBC must pass an update for m-line application and also c-line should be present in all the cases.

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:

1> For m-line application
The SBC is passing this UPDATE to the other side with valid c-line.

2> For m-line Audio
The SBC is passing this UPDATE to other side and c-line is present.

3> For m-line Video
The SBC is passing this UPDATE to other side without removing C-line.

In all the above scenarios if UPDATE is sent from ingress side with port zero, it is received on the other side with port zero.

Workaround: The call flow after the fix:

1> For m-line application
The SBC is passing this UPDATE to the other side with valid c-line.

2> For m-line Audio
The SBC is passing this UPDATE to other side and c-line is present.

3> For m-line Video
The SBC is passing this UPDATE to other side without removing C-line.

In all the above scenarios if UPDATE is sent from ingress side with port zero, it is received on the other side with port zero.

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 following commands assume the SBC's SIP-TLS address/port number is 10.x.yy.zz:5061:
$ openssl s_client -showcerts -connect 10.x.yy.zz:5061 -cipher 'ECDHE-RSA-AES128-GCM-SHA256' -curves secp384r1 | egrep "i:\s:"
$ openssl s_client -showcerts -connect 10.x.yy.zz:5061 -cipher 'ECDHE-RSA-AES128-GCM-SHA256' -curves secp521r1 | egrep "i:\s:"

A. Failed case shows the the SBC TLS server fails to find matching cipher suite and curve name:
$ openssl s_client -showcerts -connect 10.x.yy.zz:5061 -cipher 'ECDHE-RSA-AES128-GCM-SHA256' -curves secp384r1 | egrep "i:\s:"
140485529323328:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:ssl/record/rec_layer_s3.c:1544:SSL alert number 40
...
Packet capture will not show Server Hello Message.

B. Successful case displays the SBC TLS server's certificate chain after TLS server properly selects cipher suite and curve name.
$ openssl s_client -showcerts -connect 10.x.yy.zz:5061 -cipher 'ECDHE-RSA-AES128-GCM-SHA256' -curves secp521r1 | egrep "i:\s:"
depth=2 C = US, O = Sonus, OU = SonusProductPKI, CN = SonusProductRootCA
...
The packet capture will show Server Hello after the SBC TLS server selects the matching cipher suite and curve name.

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: 

  1. Bring down mgt1 interface on the SBC side, critical alarm raised on the SBC and same has been reached to EMS.
    ip l set mgt1 down
  2. Teardown the connectivity between EMS & SBC by creating the static route at SBC side (no trap will be reached to EMS).
  3. Bring the mgt1 interface up on SBC side. (Clear trap generated on SBC but not reached to EMS because link between EMS & SBC is down so which is expected).
  4. Bring the connectivity between EMS & SBC up (trap re-sync should work and EMS should clear the critical alarm raised on Step 1).

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:

  1. Deploy the SBC.
  2. Add DNS records for SNMP trap target.
  3. Configure DNS nameserver in the SBC.
  4. Configure SNMP trap target fqdn.
  5. Validate that the SBC resolve the fqdn and add the corresponding IP address and port.

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: 

  1. Set the fileCount for accounting files to 2048.
  2. Enable eventLogValidation for account files.
  3. Rollover the log repeated to created 2028 accounting files.
  4. Set the fileCount for accounting files to 32.
  5. Rollover the account log.
  6. Ensure the SBC has not crashed.

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

SevProblem DescriptionResolution
SBX-119975 | SBX-1187552

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:

  • If an allocation failed to one T-SBC because of a connection issue, the S-SBC removes the node from the cache but when cache expires for this LIF, fetch the same node again in bad state and once again try to send more requests

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:

  • checks if the remote IP Address is mandated by NRM and if so tries to send the request out if it is connected. Otherwise, the RRM rejects it.
  • checks if the remote IP Address is provided and preferred, if the remote node is connected then the request is sent out.
  • checks if the remote IP address is provided and preferred but not connected then it tries to fetch a Connected Node with matching LIF group; or if finds a node which is in connecting state with matching LIF and queues the request and starts timer; or if the cache for the LIF group is not existent and is initial request, request Leader Node for the Cache.

On receiving GW indication, the possible following scenarios can occur: 

  • If it is connected, fetch the queued messages and sends the request.
  • If it is disconnected, fetch the queue and rejects the messages so that NRMA can retry.
  • If the GW Connection timer expires, fetch the queue and rejects the messages so that NRMA can retry.

Workaround: None.

SBX-105332 | SBX-1051372

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

  1. Configure SBC for MSRP-B2BUA support.
  2. Complete the INVITE signaling message for MSRP
  3. Send MSRP request message from UAC to SBC, SBC Should forward this to UAS.
  4. From UAS send "MSRP <transaction-id> 200" response message to SBC.
  5. SBC should successfully send it to UAC.

Test 2

  1. Configure SBC for MSRP-B2BUA support.
  2. Complete the INVITE signaling message for MSRP
  3. Send MSRP request message from UAC to SBC, SBC Should forward this to UAS.
  4. From UAS send "MSRP <transaction-id> 200 OK" response message to SBC.
  5. SBC should successfully send it to UAC.

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):

set addressContext default intercept nodeNumber 10001
comm
set addressContext default intercept callDataChannel LigCDC interceptStandard etsi ipInterfaceGroupName LIG
set addressContext default intercept callDataChannel LigCDC mediaIpInterfaceGroupName LIG
comm
set addressContext default intercept callDataChannel LigCDC vendorId utimaco
set addressContext default intercept callDataChannel LigCDC dsrProtocolVersion 1
comm
set addressContext default intercept callDataChannel LigCDC mediationServer dfxa media udp
set addressContext default intercept callDataChannel LigCDC mediationServer dfxa media udp ipAddress 11.22.33.44
set addressContext default intercept callDataChannel LigCDC mediationServer dfxa media udp portNumber 37373
set addressContext default intercept callDataChannel LigCDC mediationServer dfxa media udp dscpValue 16
comm
set addressContext default intercept callDataChannel LigCDC mediationServer dfxa media udp mode inService
set addressContext default intercept callDataChannel LigCDC mediationServer dfxa media udp state ena
comm
set addressContext default intercept callDataChannel LigCDC mediationServer imsa signaling
set addressContext default intercept callDataChannel LigCDC mediationServer imsa signaling ipAddress 11.22.33.44
set addressContext default intercept callDataChannel LigCDC mediationServer imsa signaling portNumber 38154
set addressContext default intercept callDataChannel LigCDC mediationServer imsa signaling dscpValue 16
set addressContext default intercept callDataChannel LigCDC mediationServer imsa signaling protocolType tcp
comm
set addressContext default intercept callDataChannel LigCDC mediationServer imsa signaling mode inService
set addressContext default intercept callDataChannel LigCDC mediationServer imsa signaling state ena
commit

Once the CDC is configured, register the endpoint. The symptoms of the issue is that the SBC includes an incorrect port number (5062, 5063 and similar) in the Contact header of all messages sent to the endpoint. You don’t need to make calls though: the presence of port number 5061 in the event which is printed after the SBC received the REGISTER w/ 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.0.1.9:5060 for Sig port:1107 AddrType 1
195 03022022 092259.284953:1.01.07.14012.Info .SIPSG: sipsgCallProcCommonUtils.c (-6170) 4022. SipSgSelectTransportAndSigPort: Selected address 10.0.1.9:5061 for Sig port:1107 AddrType 1

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-1161842

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:

  1. With the ‘dialogTransparency’ flag enabled on both the ingress and egress zones of ISBC and SLB.
  2. With the ‘dialogTransparency’’ and ‘generateCallIdWithDialogTransparency’ flags enabled on both the ingress and egress zones of ISBC and SLB, both for a basic call flow and call flow with PRACK, UPDATE, Re-INV.

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-1159942

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: 

  1. Make SIP-SIP call configuration using the PSX.
  2. At Egress zone, in addition with Egress TG, create three more TGs.
  3. On the SBC, configure the "ingressIpPrefix" of all three TGs (TG1, TG2, TG3) with different server IPs address (IP1, IP2, IP3).
  4. Send 3xx with three Contact headers.
  5. Configure same ingressIpPrefix address in Contact Headers of 3xx message so that the first Contact header is set to IP1, the second Contact Header is set to IP2 and the third Contact Header is set to IP3.
  6. Set "blockDirection" of TG3 to outgoing.
  7. On PSX, Enable "Force Re-query for Redirection" flag in IPSP of Egress Trunkgroup.
    For example:
    Contact: <sip:14135;tgrp=<trunk_group>;trunk-context=meta1001-1002.<domain_name>@IP1>;q=1
    Contact: <sip:14135;tgrp=<trunk_group>;trunk-context=10.xxx.yyy.zz@IP2>;q=0.9
    Contact: <sip:14135;tgrp=<trunk_group>;trunk-context=meta3001-3002.<domain_name>@IP3>;q=0.8
  8. Make an SIP-SIP call, send 3xx from Egress peer with these 3 Contact headers.
  9. The SBC sends INVITE to first Contact header through TG1.
  10. If the first Contact is not reachable, the SBC tries with the second Contact using TG2 and so on.
  11. Verify that after receipt of 3xx with multiple contact headers, the TRM debugs are logged in DBG with trunk group names of all 3 Contact headers and there is no TRM failure message.

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: 

  1. Enable "Used Called URI as R-URI".
  2. Incoming call with userpart of To header and RURI have "+1...".
  3. Outgoing call will have "+1+1..." in userpart of To and Ruri.

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: 

  1. Make 8 calls on a cloud S-SBC 1:1 setup to to 8 different T-SBCs.
  2. While the calls are stable and redundant apply an ACL to block the traffic to one of the T-SBCs. This will trigger a call cleanup to release the call on both the active and standby SBCs.
  3. Perform a switchover and check the 7 other calls are preserved over the switchover.

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.

Received:
P-Charging-Vector: icid-value="PCSF:1-UHN3kli1asbc0000cfed-0-3-000000005f7d96fc-0000000000000581";orig-ioi=domainname.org

Sent:
P-Charging-Vector: icid-value="PCSF:1-UHN3kli1asbc0000cfed-0-3-000000005f7d96fc-0000000000000;orig-ioi=domainname.org

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:

  1. Send an INVITE to the SBC that contains a PCV header and check that the PCV header is sent out of the egress side without the PCV header being added.
  2. Respond with 183 to complete the offer/answer processing and then send forward an UPDATE message to change the SDP content with SDP and PCV.
  3. Check that the egress UPDATE message should not include the PCV header.

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-1175923

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:

  1. Run an e2e re-INVITE enable, A call B.
  2. Both A and B send re-INVITE at the same time. SBC answer 491 on egress and send a re-INVITE on Egress. At the same time, answer 200 OK to the ingress.

As a result, the transparent headers may missing.

The code is modified to address the issue.

Workaround: None.

SBX-117302 | SBX-1207652

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:

"MSRP 0100543f85f SEND
"
"To-Path: msrp://17000000000.example.com:10000/%s;tcp
"
"From-Path: msrp://11.2.3.44:37001/1789102;tcp
"
"Message-ID: 016f28000567
"
"Byte-Range: 1-25/25
"
"Success-Report: yes
"
"Failure-Report: no
"
"Content-Type: text/plain
"


"Caller sent this message.
"
"-------0100543f85f$
"

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-1154442

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-1190582

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-1183352

*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:

  • When a port stop request is received, the mgt port driver puts the PHY in "super-isolate" mode where the receive and transmit (rx/tx) are stopped. This causes the remote link to go down.
  • When a port start request is received, the mgt port driver takes the PHY out of "super-isolate" mode and the rx/tx are started. This results in the remote link to go up.

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-1180512

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:

  • A Binding Request from candidate 1 (C1) received at the SBC, the SBC replies with a Binding Success Response to C1 and initiates a Binding Request to C1.
  • A Binding Request from candidate 2 (C2) received at the SBC, the SBC overwrites the stored candidate with C2, sends a Binding Success Response to C2 and initiates a Binding Request to C2.
  • The SBC receives a Binding Success Response from C2 and sends a new Binding Request with the USE-CANDIDATE attribute to C2.
  • At this moment, the SBC receives a Binding Success Response from C1.

The code is modified to:

  1. Avoid updating the nominated candidate list if we already sent out BREQ or BREQ_UC.
  2. Not to send BREQ during the window where the SBC has switched from sending BREQ to BREQ_UC.
  3. Wait for timer to be fired before resending BREQ.

Workaround: None.

SBX-1179002

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-1199002

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.
It is suggested to:

  1. Run SRTP regression tests.
  2. Perform SIP registrar switchover while running SRTP calls.

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-1175462

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-1177992

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: 

  1. Configure the dialog transparency, forking, and E2E Prack to enable.
  2. Leg A calls Leg B.
  3. B1, B2 answer 18x
  4. B2 18x, B1 200 OK (no SDP) (back to back)

The code is modified to validate the remote tag based on the forking list not the final one.

Workaround: Disable the Prack.

SBX-1191072

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: 

  1. Configure SIP-TLS in Peering case with authClient=false without configuring the peer's certificate chain's Root CA in the SBC.
  2. Attempt to make a SIP-TLS call to peer.

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-1175062

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-1199652

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-1119342

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: 

  1. Enable embedded header in 3xx.
  2. Egress responds to 3xx with embedded header size large.

The code is modified to increase buffer support up to 6,000 bytes.

Workaround: None.

SBX-1194632

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-1181453

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: 

  1. Log into the EMA.
  2. Navigate to the "System Administration - File Upload" screen.
  3. Select a file with a .pfx extension.
  4. Upload the file.

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-1181803

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: 

  1. Setup a basic SIP-SIP call.
  2. Send an INVITE message having the MIME content and MIME-version header.
  3. Enable a PIDF transparency at the ingress IPSP.
  4. Enable the PIDF and an unknown header transparency at the egress IPSP.
  5. Verify if a duplicate MIME-version header is present inthe  egress INVITE.
    This can be tested without sending the MIME-version in the INVITE as well.

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-1183533

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:

  1. A T.38 is present in the Leg A and Leg B in the PSP.
  2. The egress peer rejects the offer.
  3. A 4xx message attempt record is updated with the DSP reject reason as "Call Rejected Unlicensed."

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: 

  1. Set up a basic SIP-SIP call configuration using the PSX.
  2. Enable the T.38 and G711 u in Leg A and Leg B in the PSP .
  3. Check the CDR and verify the DSP Rejection Reason.

The code is modified to update the dspRejectionReason to "Rejected codec unlicensed" for only the cases where the license is unavailable .

Workaround: None

SBX-1179013

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-1190322

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: 

  1. Run incoming ttc-charging-params in P-Charging-Vector.
  2. Run subsequent parameters after the contractor param.

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-1197092

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-1168202

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: 

  1. Configure a set of SIP sigPorts.
  2. Unhide debug command.
  3. Issue a command "request sbx xrm debug command acl\ -stat", or "request sbx xrm debug command acl\ -cfg\ 50"

The code is modified to:

  1. Return the count of allocated ACL list.
  2. Specify number of entries to display, which is limited to <= 100. If user does not specify the number of entries, then we will default to 100.
  3. Display allocated ACL rules of each category, either from the beginning of the list, or continue from last entry of previous request.
  4. Have the user repeat the request multiple times to reach the end of the list. 

The change applies to both ACL config and stats.

Workaround: Configure less than 10 signaling ports.

SBX-1183932

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-1161633

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:

  1. Invite is received with multiple codec i.e ( 0 18 8 9 102 101), the SBC sends Invite toward egress.
  2. From egress 180 without SDP is received, the SBC starts playing tone in G722 codec.
  3. From egress 183 is received with new codec i.e(0), the SBC sends 183 with SDP with old codec (G722).
  4. 200 OK with SDP(0) is received from egress.

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-1176393

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:

  1. Login to EMA.
  2. Navigate to Configuration --> Security Configuration --> Commands --> Upload Certificate screen.
  3. Select a certificate file to upload.
  4. Click Save.
  5. The upload should be successful.

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-1201142

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-1196032

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-1199642

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-1189283

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-1169043

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:

  1. Send a 200 OK for re-INVITE from EGRESS PEER without SDP.
  2. Send a 200 OK for re-INVITE from EGRESS PEER with SDP but changed CODEC.
  3. Send a 200 OK for re-INVITE from EGRESS PEER with SDP.
  4. Send a 4xx (for re-INVITE) from EGRESS PEER.

The code is modified to add SDP in ACK for late media cases.

Workaround: None.

SBX-117280 | SBX-1177582

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: 

  1. Access the url https://{SBC hostname}/liTargetProvisioning/services/AdminService from the browser.
    1. Result: An Axis error "No service is available at this URL" is displayed.
  2. Access the url https://{SBChostname}/liTargetProvisioning/services/AdminService?wsdl from the browser.
    1. Result: An Axis error "Could not generate WSDL! There is no SOAP service at this location" is displayed.

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-1180343

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: 

  1. Import certificate with large DER content (more than 6400 bytes) and verify that action is aborted and user is presented with error.
  2. Create a local-internal certificate with subjectAlternativeDnsName of size 512 chars to 4096 chars.

The code is modified to add validation to prevent bufferoverflow. Increased size of subjectAlternativeDnsName entries to 4096 chars.

Workaround: None.

SBX-112042 | SBX-1175253

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: 

  1. Launch the SBC HA.
  2. Run the mix load.
  3. Perform a switchover.

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.
removeenv.pl -n TERMINATE_TIMEOUT sam
addenv.pl -n TERMINATE_TIMEOUT -v 240000 sam

SBX-111141 | SBX-1182383

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:
show table system softwareUpgradeStatus

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-1173433

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:

  1. Set remote cert as serverCert.
  2. Set local cert as clientCaCert.
  3. Verify that validation fails and user is prompted.

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-1192932

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. 

  1. The following actions need to be run as root on the SBC.
    echo '5041,5043,65330' > /proc/sys/net/ipv4/ip_local_reserved_ports
  2. Edit the following line in /etc/sysctl.conf
    net.ipv4.ip_local_reserved_ports=5041,5043
    to append “,65330”
    net.ipv4.ip_local_reserved_ports=5041,5043,65330
  3. There is no need to reboot.
SBX-117921 | SBX-1179232

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-1192952

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:

set global servers dns global ednsPayloadSize <512-4096 bytes>

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-1181392

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:

  1. Run a long duration call (approximately for two mins or more).
  2. Log in to EMA and go to All->Address Context ->Call Media Status Detail and note the GCID.
  3. Click on All->Global and from commands, drop down select Terminate Call and give the value of GCID in the popup.
  4. Click on terminateCall.

The call should get terminated

The code is modified to decode the xpath in the backend.

Workaround: No workaround.

SBX-113593 | SBX-1173842

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.
Route the PSP has codecs in order- G711, G729.

Scenario:

  1. Make a UAC-SBC-UAS call where initially call is established as G729-G729 transcode call with PSP setting is transcode only and G711.
  2. Send a re-INVITE through the UAC by changing codec to G711U call with transcode flag is transcode only.
  3. Observe if there are any hung resources/active call count in the callResourceDetailsStatus / callCountStatus after a call has terminated.

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:

  1. Setting the correct resource mask (dres+priv xres+public xres) in the deallocate command from the S-SBC to the T-SBC to free resources on the T-SBC.
  2. Prevent the codec capability mask from being overwritten during reallocation based on answer (The codec mask for answer is frequently a subset or partial mask of that in the initial offer). This retains the codec capability mask set during previous offer-answer and retains the old DSP resource if it is capable in servicing the new offer instead of going for new resource allocation just because of the restricted capability mask set during answer processing.

Also, while deallocating resources on the T-SBC from the earlier offer-answer,
in the current working context, the S-SBC structure holding details of the resource being freed that includes the TSBC node gcid, node IP, and resource info pertaining to the DSP, private xres and public xres, is set to NULL if it is also referenced in any other existing contexts. This is to prevent the private xres also referenced in another context from being incorrectly freed.

Workaround: None.

SBX-117948 | SBX-1191672

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-1167372

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-1191463

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: 

  1. Log in to the EMA.
  2. Navigate to All -> Address Context -> SIP Active Register Name Status.
  3. Enter search text and click the Search button.

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-1175722

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:

  1. Initiate the TLS connection from the browser to the SBC EMA/PM server and capture packets using Wireshark on the client.
  2. The CA certificate does not show up in the packets.

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-1164112

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
RTCP Bye packet is sent with the SSRC of the endpoint. The media continues with the same SSRC, resulting in issues because it is not compliant to the RFC.

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:

  1.  Configure monitoring profile with an early media authorization (EMA) flag enabled and the RTCP gen.
  2. Configure the early media and create scripts with the P- early media supported.
  3. The UAC sends an invite with the p-early media supported,
  4. The UAS sends a 183 with a SDP that has a local PRACK and media with the SSRC1.
  5. The UAS sends a 200 OK and media with the SSRC1.

The RTCP bye packet is suppressed for early media when the endpoint is playing the media.

Workaround: Disable the monitoring profile.

SBX-118050 | SBX-1200322

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

  1. All messages toward the customer MUST be sent with a PCV header and use provisioned ioi values.
  2. ioi in the PCV header will be the customer's assigned value for the PARTNER generating it.
  3. When messages from PARTNER have a PCV with ioi, the ioi needs to be overwritten with the customer assigned PARTNER value.
  4. Messages from the SBC may have a PCV but without ioi params in it.

Partner network

  1. PCV may/may not be received from PARTNER with/without ioi params
  2. PCV is not sent toward PARTNER in most cases but some PARTNER networks may want this in the future
  3. So, this needs to be configurable and where applicable, provisioned ioi values used in the PCV in messages to the PARTNER
  4. However in testing, when the far end is not set to sendPCV, the 18x/200 OK back to the Ingress trunk does not get sent the Term-IOI value, only the Orig-IOI in the 18x/200 OK. However, on the 200 OK from the BYE there is both Term/Orig IOI.

Ingress TG:
generateOrReplacePCV {
state enabled;
origIOI orig.Server.iqntipx;
termIOI term.Server.iqntipx;
sendPCVHeader enabled;

Both SIPCORE TGs.
generateOrReplacePCV {
state disabled;
sendPCVHeader enabled;

Egress TG:
generateOrReplacePCV {
state enabled;
origIOI orig.cust.iqntipx;
termIOI term.cust.iqntipx;
sendPCVHeader disabled;


A Call Flow Partner Peer PARTNER TG on the SBC TG on the SBC peer
4 <------- INVITE w/o PCV -------
-------- 18x w/o PCV ---------> <------------ INV w/o PCV ----------
---- 18x w [PCV w prov term-ioi] -→

Root Cause: The following configuration must be enabled:

Ingress TG:
generateOrReplacePCV {
state enabled;
origIOI orig.Server.abcdefg;
termIOI term.Server.abcdefg;
sendPCVHeader enabled;

Both SIPCORE TGs.
generateOrReplacePCV {
state disabled;
sendPCVHeader enabled;

Egress TG:
generateOrReplacePCV {
state enabled;
origIOI orig.cust.abcdefg;
termIOI term.cust.abcdefg;
sendPCVHeader disabled;

The issue is noticed for the following call flow:

Call Flow Partner Peer PARTNER TG on the SBC TG on the SBC peer
4 <------- INVITE w/o PCV -------
-------- 18x w/o PCV ---------> <------------ INV w/o PCV ----------
---- 18x w [PCV w prov term-ioi] -→

Steps to Replicate: The issue can be replicated by configuring the following:

Ingress TG:
generateOrReplacePCV {
state enabled;
origIOI orig.Server.abcdefg;
termIOI term.Server.abcdefg;
sendPCVHeader enabled;

Both SIPCORE TGs.
generateOrReplacePCV {
state disabled;
sendPCVHeader enabled;

Egress TG:
generateOrReplacePCV {
state enabled;
origIOI orig.cust.abcdefg;
termIOI term.cust.abcdefg;
sendPCVHeader disabled;

The issue is noticed for the following call flow:

A Call Flow Partner Peer PARTNER TG on the SBC TG on the SBC peer
4 <------- INVITE w/o PCV -------
-------- 18x w/o PCV ---------> <------------ INV w/o PCV ----------
---- 18x w [PCV w prov term-ioi] --->

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-1179552

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: 

  1. Run the Saveconfig.
  2. Run the removeSavedConfig.

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-1178942

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: 

  1. Set up a SIP-GW-GW-SIP call.
  2. Set up Tone and Announcement in Ingress GW TG.
  3. Set Honor Remote Precedence flag enabled in Ingress TG PSP.
  4. Sent an UPDATE from server with a codec other than G711 and a codec which is different from previously negotiated codec.
  5. An UPDATE should be sent to client with correct PT.

The code is modified with a valid PT value.

Workaround: Set the Honor Remote Precedence flag disabled.

SBX-101758 | SBX-1135512

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:

  1. Use the SIPI scripts.
  2. Enable ClearModeAsCodec flag in both ingress and egress TG. Add a CLEARMODE codec in ingress and egress PSP.
  3. Use the scripts and make a SIPI-SIPI call.
  4. The call should connect and CDR should be populated as DATA, CLEARMODE (P:71:0).

Tests can be done to verify different call flows:

  1. SIPI-SIPI call with ingress offers CLEARMODE, Egress responds CLEARMODE.
    expected output: CDR and Call media status cli command should show data and CLEARMODE.
  2. SIPI-SIP call with ingress offers CLEARMODE, Egress responds CLEARMODE.
    expected output: CDR and Call media status cli command should show data and CLEARMODE.
  3. SIPI-SIP call with ingress offers CLEARMODE + G711U, Egress responds G711U.
    expected output: CDR and Call media status cli command should show audio and G711U.

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-1173922

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:

  1. Set up a D-SBC having multiple T-SBC nodes.
  2. Transcode the PSP setting only.

Call flow:

  1. Run an initial call after an INVITE, list 183/Prack and UPDATE for preconditions is AMR-NB–AMR transcode. DSPs for this call are from TSBC1.
  2. Send an UPDATE to the change codec on egress leg from AMR to AMR-WB.

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-1182182

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-1181442

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-1191662

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: 

  1. Configure multiple codecs in Ingress and Egress PSPs.
  2. Send multiple codecs in INVITE from Ingress Peer. (Audio + Text )
  3. The SBC should sent all passthru and transcodable codecs configured in the PSP to Egress Peer.

The code is modified to address the issue.

Workaround: None.

SBX-114693 | SBX-1191612

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-1191732

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: 

  1. Log into the PM.
  2. Navigate to Administration --> System Administration --> Profile Import/Export.
  3. Click on Export Profile button.
  4. Provide a File Name and Select the Type "Number Translation Criteria".
  5. Check if all instances of that profile are listed.
  6. Select an instance of the profile.
  7. Click on the Export button.
  8. Delete the profile from Number Translation Criteria.
  9. Import the exported file that contains the Number Translation Criteria.

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

tfpem.serviceDmPmRuleIb.setData((char *)CONFD_GET_BUFPTR(key));
tfpem.serviceDmPmRuleIb.setDataNull(GUISVR_BOOL_FALSE);
tfpem.serviceDmPmRuleIb.setLoaded(GUISVR_BOOL_TRUE);

Workaround: No workaround.

SBX-115421 | SBX-1191592

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-1191642

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: 

  1. UAC sends INVITE Audio + Text to the SBC.
  2. The SBC sends INVITE Audio + Text to UAS.
  3. UAS sends 18x Audio + Text (port=0) to the SBC.
  4. The SBC sends an INVITE to MRF server and MRF server responds back with valid Audio and Text Ports.
  5. The SBC sends 18x Audio + Text to UAC.
  6. UAS sends 200 OK Audio stream alone.

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-1170722

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-1191712

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.
In case of the SBC 5400, sending of notification to DSPs were skipped due to non-support.

Steps to Replicate: * SBC 5400 with at least one DSP card.

  1. Once the application is active, assuming DSP card to be present in slot #1, issue manual DSP core-dump command.
  2. Enable debug commands (unhide debug).
  3. Execute the following command.
  4. Request an SBC drm debug command "dspcoredump dsp 1".

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-1192552

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-1197172

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:

  1. Enable "Lock down Preferred codec" flag on the egress trunk.
  2. Configure the packet service profile with "Transcode only" option.
  3. Configure ingress route with SILK codec and egress route with PCMU codec.
  4. UAC sends an INVITE with the SILK codec.
  5. The SBC sends an INVITE with PCMU codec to UAS.
  6. UAS sends a 200 OK with PCMU to the SBC.
  7. The SBC sends a 200 OK with SILK to UAC.
  8. UAC sends ACK to the SBC.
  9. The SBC sends ACK to UAS.

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-1191622

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: 
OPTIONS \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \tsip:9611912691@10.xx.yy.zzz:7050 SIP/2.0

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-1174812

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-1150532

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-1188082

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: 

  1. Configure the NAT media and signalling.
  2. RUN a hold resume with a two media stream (audio + video).
  3. Check if it throws a BRM sync Error or if the resources are deactivated and reactivated frequently.

The code is modified for non core stream in a NAT call so that deactivation and reactivation of resources does not take place.

Workaround: 

  1. Run the call with only core audio
  2. Run the call without configuring NAT
SBX-114293 | SBX-1182372

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.
In a single DSP call, the private XRES is retained. But if the call requires both DSPs, the private XRES(s) on each call leg is released.
In the two DSP call scenario, after multiple re-Invites(hold/off hold with codec change) , a stale private XRES(s) is held unnecessarily in the previous pending ACK PSP context. The SBC is unable to terminate the call smoothly.

Steps to Replicate: 

  1. Run the call flow with the initial call being a 2 DSP transcode call with AMRWB-AMRWB codecs.
  2. Send multiple re-INVITES from the endpoint to change the codec to AMR and AMRWB and so on.
  3. The output of the callResDetailStatus shows a hung private XRES(s).
  4. After receiving a BYE message from the  end point, a call termination takes an unreasonably long time.

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-1192482

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-1185652

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:

  1. Use the proper context when starting a server or client session.
  2. Save remote RTP address in the CCB.

Workaround: None.

SBX-117911 | SBX-1191632

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: 

  1. Initiating call from Cisco phone to PSTN endpoint and PSTN sends back 180 Ringing.
  2. The SBC added SDP in the 180 Ringing for LRBT and sent back to CUCM Cisco phone.
  3. Ensure SBC added audio m line with valid IP and port, and for Video added port Zero with a=inactive.
  4. Answering the call from PSTN phone.
  5. Now ensure that POLYCOM phone is in CONNECTED state after answering call.
  6. Media Validation for Call between PSTN user and Cisco User on Cisco Phone.

The code is modified to inactive when video stream is marked as absent when port 0 is received.

Workaround: None.

SBX-118662 | SBX-1192562

PortFix SBX-118662: The LSWU failed due to Action Command Timeout

Impact: The LSWU failed from V10.01.01R3 to V10.01.02A3
admin@EMERALD> request system serverAdmin GARNET startSoftwareUpgrade <sbc package>

This command will start a live software upgrade. Do you want to proceed [no,yes] yes
Error: Action Command Timeout.

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-1191652

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: 

  1. UAC sends INVITE with Audio and Video.
  2. UAS sends 183 with Audio and Video
  3. The SBC starts playing tone due to delayed ring back tone configuration.
  4. The SBC triggers an UPDATE with video port as zero towards ingress EP.
  5. A 200 OK (for UPDATE) response makes the SBC abort the tone.

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-1181002

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:

  1. Configure the setup to transparent precondition interworking + transcode scenario.
  2. Send an initial INVITE with precondition attributes from UAC.
  3. Now preconditions met. Now, call is with AMR-WB to AMR transcode scenario.
  4. From UAS, send the 183 without SDP.
  5. From UAS, send the UPDATE message, change the codec from AMR to AMR-WB.
  6. Now, AMR-WB and AMR-WB transcoding call got established.
  7. From UAS, send the 183 without SDP.
  8. From UAS, send the UPDATE message , by changing the codec from AMR-WB to AMR.
  9. Now, AMR-WB and AMR transcoding call established.
  10. From UAS, send the 180 without SDP.
  11. From UAS, send the UPDATE message, by changing the codec from AMR to AMR-WB.
  12. 200 OK of INVITE without SDP sent from UAS. Call got established.
  13. From UAS, change the codec from AMRWB to AMR with Re-INVITE.
  14. Now the call is established with AMR-WB and AMR transcoding call.
  15. From UAS, change the codec from AMR to AMRWB with Re-INVITE.
  16. Now the call is established with AMR-WB and AMR-WB transcoding call.
  17. Send the BYE from UAC.

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-1182602

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: 

  1. Send the initial INVITE message without precondition attributes.
  2. The SBC sends the INVITE to UAS with precondition attributes.
  3. Send a 183 dialog-1 from UAS with precondition attributes.
  4. Before preconditions met for 183 dialog-1 , Send the 183 dialog-2
  5. Once preconditions met for 183 dialog-1, Send the 183 dialog-3 after the 183 dialog-2 (retransmission)
  6. Now, the SBC process the 183 dialog-2 and send it UAC.
  7. Before completing the preconditions for 183 dialog-2, send the 183 dialog-3 again from UAS (retransmission).
  8. After preconditions met for 183 dialog-2, the SBC should dequeue the 183 dialog-3 and process it.
  9. The SBC should generate UPDATE message for 183 dialog-3 and send to UAS.

The code is modified to locally answer the UPDATE when ingress peer does not allow UPDATE

Workaround: None

SBX-113553 | SBX-1178352

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:

  1. The UAC doesn't have a 100 REL support and UAS support 100 REL. Enable SendSingleCodecinAns for both the legs
  2. The UAC sends an INVITE with the G729, AMR, AMRWB and PCMA to the SBC.
  3. The SBC sends INVITE with G729 AMR, AMRWB and PCMA to the UAS.
  4. The UAS sends 18x G729 and PCMA to the SBC.
  5. The SBC sends 18x G729 to the SBC.
  6. The UAS sends an UPDATE PCMA to the SBC.
  7. The SBC sends a 200 OK Update message with the PCMA.
  8. The call is transcoded from G729 to the PCMA.

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-1195132

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.

  1. The SBC offers more than one crypto suite towards SIPREC Server in the initial INVITE.
  2. The SBC receives answer with the crypto suite other than the first preference.
  3. The main call/CS call goes on hold/unhold.
  4. The SBC sends a Re-INVITE towards the SRS with corrupted crypto key values and SIPREC server fails to decrypt the streams.

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.
The crypto suite from the answer was supposed to be updated in the recorder control block along with the answer key and maintain the correct pair of key and suite values.

Steps to Replicate: 

  1. Configure the crypto suite profile with more than one crypto entry, attach it to the srsGroupProfile and enable SRTP.
  2. Put the main call on/off hold and simulate the SIPREC server to send different crypto preference form the offer.
  3. Make sure that the SBC is not sending corrupted key values in the Re-INVITEs towards SIPREC server.

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.
When the CS call is put on hold/unhold, the SBC sends a re-INVITE towards the SRS with negotiated crypto key values.

Workaround: None.

SBX-118329 | SBX-1191742

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: 

  1. Configure the SBC for A-B call with Tone.
    Enable transcoderFressTransparency and seectiveSdpRelay flag.
  2. Send multiple codecs in INVITE from UAC.
  3. The SBC should send an INVITE out and should receive 18x from UAS.
  4. The SBC should play tone with whatever codec that is configured in the PSP.

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-1191762

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: 

" The value set against GPU flag in /opt/sonus/conf/swe/capacityEstimates/.activeCallMixInput.json file is not an integer value. "

This log does not indicate any issue with the the functionality of the profile activation.

Root Cause: On N:1 Managed MRFP node, the CDB gives the value against the filed useGPUForTranscoding as False(string), rather than 0(integer).

Application takes the value for the corresponding field as 0 by default, but a critical error message is logged in .DBG log.

Note: For the useGPUForTranscoding field value set to True, the corresponding logic was already in place, no issues in this scenario.

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:

%set system sweTrafficProfiles VzW_callmix_profile useGPUForTranscoding false
%commit

% request system admin vsbcSystem saveAndActivate rebootSBCs true
%commit

All the N:1 MRFP nodes will go for a reboot and once the application comes up, observe the following logs in latest DBG logs:

" The value set against GPU flag in /opt/sonus/conf/swe/capacityEstimates/.activeCallMixInput.json file is not an integer value. "

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-1175092

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:

  1. Enable the suppressErrorInfoHdr flag:
    --set global signaling sipSigControls suppressErrorInfoHdr enabled
  2. Restart the SBC.
  3. Send a Malformed INVITE from the UAC.
  4. The SBC sends a 400 bad request in response to the malformed INVITE when the Error-Info header is eliminated.

The suppressErrorInfoHdr Flag value is updated properly after a restart.

Workaround: None.

SBX-119428 | SBX-1203902

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: 

  1. Run a AMRNB to G711 call.
  2. Stream a media with packet loss on the AMRNB leg.
  3. Capture the media on the G711 leg.
    The media quality should be good which can be validated using PESQ analysis.

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-1206672

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:

  • Long call scenario (25 min) with SRTP, switchover.
  • Long call scenario (25 min) with SRTP, re-invites.

ssrcRandomizeForSRTP Enabled/ transcode:

  • Long call scenario (25 min) with SRTP, switchover.
  • Long call scenario (25 min) with SRTP, re-invites.

ssrcRandomizeForSRTP disabled/ passthru:

  • Long call scenario (25 min) with SRTP, switchover.
  • Long call scenario (25 min) with SRTP, re-invites.

ssrcRandomizeForSRTP disabled/ transcode:

  • Long call scenario (25 min) with SRTP, switchover.
  • Long call scenario (25 min) with SRTP, re-invites.

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-1205912

PortFix SBX-11942: Frame Lost indicator not set for AMRWB & V 1.4 Library Upgrade

Impact: 

  1. Frame lost flag is not being set based on talkState in AMRWB decoder
  2. Divide by zero issue in AMRWB energy computation which can lead to a crash

Root Cause: 

  1. When there is no frame to be fed to the AMRWB decoder, an indication of either 'frame loss' of 'no data' should be provided to the decoder. This indication should be determined based on decoder's talk state. Currently, 'no data' indication is set even if there is a frame loss, which is incorrect.
  2. The denominator is a sum of two energy values, both of which were expected to be positive. However one of the energy values turned out to be negative. The negative energy value is attributed to incorrect handling of overflow when computing the energy value. The incorrect handling of the overflow makes a large positive number appear to be a negative value.

Steps to Replicate:

  1. Run a AMRWB to G711 call.
  2. Stream a media with packet loss on the AMRWB leg
  3. Capture the media on the G711 leg. The media quality should be good which can be validated using PESQ analysis.

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.

Resolved Issues in 09.02.04R004 Release

The following issue is resolved in this release:

Issue IDSevProblem DescriptionResolution
SBX-1202641

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: 

  1. Set up a GW-GW call from GSX using ISUP as ingress
  2. Enable Signaling > Generate or Replace PCV

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-1201281

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-1197741

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:

  1. Configure the following three IPACL rules:
    rule 1: Define the LIF and the ipInterfaceGroup that contains this LIF, and assign the smallest precedence value among three rules.
    rule 2: Use the same ipInterfaceGroup as rule1, protocol = ICMP, assign precedence value > rule1, do not define as ipInterface.
    rule 3: Same as rule 2, except assign the precedence value > rule2.
  2. Take the LIF OOS and disable.
  3. Restart the application.
  4. Enable and in-service LIF.
  5. Ping the next hop address through pkt port of the LIF.
  6. Check the stats using the following command:
    "show table addressContext ADDR_CONTEXT_1 ipAccessControlList ipAclRulesByPrecedence"

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:

  • When a port stop request is received, the mgt port driver puts the PHY in "super-isolate" mode where the receive and transmit (rx/tx) are stopped. This causes the remote link to go down.
  • When a port start request is received, the mgt port driver takes the PHY out of "super-isolate" mode and the rx/tx are started. This results in the remote link to go up.

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-1192701

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 .

Resolved Issues in 09.02.04R003 Release

Severity 1 Resolved Issues

The following Severity 1 issues are resolved in this release:

Issue IDSevProblem DescriptionResolution
SBX-1163401

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,
reset the expiration time to the TTL received in the DNS data.

Workaround: The workaround is to manually clear the DNS cache or manually query the "stuck" FQDN.

SBX-1173931

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.
The memory corruption occurs because the code writes into a memory block after it is freed. This appears to occur when the SRS gets blacklisted during a setup and the call needs to route advance to the next SRS.

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-1191061

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: 

  1. Run a TLS load that will attempt to use an expired PKI security certificate (tlsProfile includes the name of the security certificate).
  2. Look for the following messages in the DBG logs:

100000B.DBG:076 05262022 000010.545176:1.02.00.18170.MAJOR .SEC: *Certificate expired

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-1191111

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-1188221

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: 

  1. Install the SBC application on an instance with a vCPU size greater than 40.
  2. Make sure the application starts and there are no core dumps observed.

The code is modified and now set to be in sync with other modules.

Workaround: None

SBX-1184731

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: 

  1. Make a SRTP-to-RTP call between A and B through the SBC under test.
  2. A puts B on hold and calls C through a different SBC/device.
  3. A bridges B and C together and uses a late-media re-INVITE towards B to modify the original connection media IP address with the C's media IP address.
  4. The SBC sends a re-INVITE with a SDP offer to B.
  5. Once the SBC receives a 200 OK with a SDP answer from B, it starts sending the SRTP packets to C's connection media IP address.
  6. The first SRTP packet sent to C has a SSN of around 1000 and the second SRTP packet has a SSN of less than 256. C discards all received SRTP packets until the SSN reaches the highest recorded SSN, which is 1000.

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 IDSevProblem DescriptionResolution

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-1192753

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:
"SipsMmUtilStoreValue ..."

The code is modified so the data log is stored to a variable correctly.

Workaround: Ignore the logging message.

SBX-1192882

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-1192242

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. 

  1. The following actions need to be run as root on the SBX.
    echo '5041,5043,65330' > /proc/sys/net/ipv4/ip_local_reserved_ports
  2. Edit the following line in /etc/sysctl.conf
    net.ipv4.ip_local_reserved_ports=5041,5043
    to append “,65330”
    net.ipv4.ip_local_reserved_ports=5041,5043,65330
  3. There is no need to reboot.
SBX-119054 | SBX-1169422

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-1183533

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:

  1. A T38 is present in the Leg A and Leg B in the PSP.
  2. The egress peer rejects the offer.
  3. A 4xx message attempt record is updated with the DSP reject reason as "Call Rejected Unlicensed."

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: 

  1. Setup a basic SIP-SIP call configuration using the PSX.
  2. Enable the T.38 and G711 u in Leg A and Leg B in the PSP .
  3. Check the CDR and verify the DSP Rejection Reason.

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-1181803

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: 

  1. Setup a basic SIP-SIP call.
  2. Send an INVITE message having the MIME content and MIME-version header.
  3. Enable a PIDF transparency at the ingress IPSP.
  4. Enable the PIDF and an unknown header transparency at the egress IPSP.
  5. Verify if a duplicate MIME-version header is present inthe  egress INVITE.
    This can be tested without sending the MIME-version in the INVITE as well.

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-1177992

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: 

  1. Configure the dialog transparency, forking, and E2E Prack to enable.
  2. Leg A calls Leg B.
  3. B1, B2 answer 18x
  4. B2 18x, B1 200 OK(no sdp) (back to back)

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-1187642

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: 

  1. Create a Cac profile.

    set profiles sipCacProfile SIPCAC1 state enabled;
    callLimit 1

  2. Attach the Cac profile to the ingress Sip Trunk group.

    addressContext default zone ZONE1 sipTrunkGroup PA_ZONE cac
    registeredEndpointCacProfile SIPCAC1;
    unRegisteredEndpointCacProfile SIPCAC1;

  3. Attach the egress peer to the Cac profile.

    set addressContext default zone ZONE2 ipPeer EGRESS_PEER sip cacProfile SIPCAC1;

  4. Test a basic Sip-Sip call (two calls) and verify that the second call fails with a 503 message.

    After the code changes for the fix, verify that the second call fails with a 403 message.

The code is modified so that the Sip Call Status has the correct error code.

Workaround: None

Resolved Issues in 09.02.04R002 Release

The following severity 1 issues are resolved in this release:

Issue IDSevProblem DescriptionResolution
SBX-118635 | SBX-1187051

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: 

  1. Set up two SBCs that communicate over the GW-GW.
  2. Place a GW-GW HPC call scenario call.
  3. Observe that the IpSockAddr and Port fields are not 0 after running the global callDetailStatus status command.

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-1183671

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: 

  1. Replicate the issue by running a basic SIP-to-SIP call and removing any mandatory header field.
  2. Check if all of the 86 sub fields are getting populated in CDR of 45th field (Ingress Protocol Variant Spec Data).

Updated SipSgFillProtocolSpecData function with the CDR field that were missing to address the issue.

Workaround: None.

SBX-1159111

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-1183691

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-1183721

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: 

  1. Prepare a SIP-to-SIP call setup with INVITE with replaces from the client side having the same call ID for original INVITE and INVITE with replaces.
  2. Check if the INVITE with replaces is replacing the original call and if the lookup is successful or not.

The code is modified to look up both the call ID and from-tag for the ingress leg.

Workaround: None.

SBX-1184251

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.

  1. The following commands assume the SBC's SIP-TLS address/port number is 10.x.yy.zz:5061.
    $ openssl s_client -showcerts -connect 10.x.yy.zz:5061 -cipher 'ECDHE-RSA-AES128-GCM-SHA256' -curves secp384r1 | egrep "i:\s:"
    $ openssl s_client -showcerts -connect 10.x.yy.zz:5061 -cipher 'ECDHE-RSA-AES128-GCM-SHA256' -curves secp521r1 | egrep "i:\s:"
  2. A failed case shows the the SBC TLS server fails to find matching cipher suite and curve name.
    $ openssl s_client -showcerts -connect 10.x.yy.zz:5061 -cipher 'ECDHE-RSA-AES128-GCM-SHA256' -curves secp384r1 | egrep "i:\s:"
    140485529323328:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:ssl/record/rec_layer_s3.c:1544:SSL alert number 40
    ...
  3. The Packet capture will not show Server Hello Message.
  4. A successful case displays the SBC TLS server's certificate chain after TLS server properly selects cipher suite and curve name.
    $ openssl s_client -showcerts -connect 10.x.yy.zz:5061 -cipher 'ECDHE-RSA-AES128-GCM-SHA256' -curves secp521r1 | egrep "i:\s:"
    depth=2 C = US, O = Sonus, OU = SonusProductPKI, CN = SonusProductRootCA
    ...

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-1187311

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-1176371

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-1187771

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 IDSevProblem DescriptionResolution

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: 

  1. Enable all required configuration along with IMS AKA configuration.
  2. Make end-to-end call. Do not answer from egress endpoint.

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-1170972

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:

  1. Use the proper context when starting a server or client session.
  2. Save remote RTP address in the CCB.

Workaround: None.

SBX-117280 | SBX-1176532

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: 

  1. Access the url https://{SBC hostname}/liTargetProvisioning/services/AdminService from the browser.
    1. Result: An Axis error "No service is available at this URL" is displayed.
  2. Access the url https://{SBChostname}/liTargetProvisioning/services/AdminService?wsdl from the browser.
    1. Result: An Axis error "Could not generate WSDL! There is no SOAP service at this location" is displayed.

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-1188292

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: 

  1. Set up a SIP-GW-GW-SIP call.
  2. Set up Tone and Announcement in Ingress GW TG.
  3. Set Honor Remote Precedence flag enabled in Ingress TG PSP.
  4. Sent an UPDATE from server with a codec other than G711 and a codec which is different from previously negotiated codec.
  5. An UPDATE should be sent to client with correct PT.

The code is modified with a valid PT value.

Workaround: Set the Honor Remote Precedence flag disabled.

SBX-1183733

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:

  • A Binding Request from candidate 1 (C1) received at the SBC, the SBC replies with a Binding Success Response to C1 and initiates a Binding Request to C1.
  • A Binding Request from candidate 2 (C2) received at the SBC, the SBC overwrites the stored candidate with C2, sends a Binding Success Response to C2 and initiates a Binding Request to C2.
  • The SBC receives a Binding Success Response from C2 and sends a new Binding Request with the USE-CANDIDATE attribute to C2.
  • At this moment, the SBC receives a Binding Success Response from C1.

The code is modified to:

  1. Avoid updating the nominated candidate list if we already sent out BREQ or BREQ_UC.
  2. Not to send BREQ during the window where the SBC has switched from sending BREQ to BREQ_UC.
  3. Wait for timer to be fired before resending BREQ.

Workaround: None.

SBX-119050 | SBX-1181453

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: 

  1. Login to the EMA.
  2. Navigate to the File Upload screen.
  3. Select a file with a .pfx extension.
  4. Upload the file.

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.

Resolved Issues in 09.02.04R001 Release

The following Severity 1 issues are resolved in this release:

Severity 1 Resolved Issues

Issue ID

Sev

Problem Description

Resolution

SBX-1181181

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: 

  1. Register an SBC instance with an EMS.
  2. Unregister the same SBC instance with the EMS.
  3. Observe that the ENM process does not crash.

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-1159371

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:
show table addressContext <context> zone <zone> sipTrunkGroup <trunkgroup> signaling authentication authPassword

Root Cause: 

  1. The authPassword fetches calls several times a second.
  2. The call occurs at the same time that the CpxTrunkGroupMediaIpSecondaryInterfaceGroupNameValidate is called.
  3. Both routines use the same global maapiSocket for maapi calls to read the confd database.
  4. Since the same global socket is used, the maapi_exists call is hung.

Steps to Replicate: 

  1. In one CLI session, make several calls to get the authPassword.
  2. show table addressContext <context> zone <zone> sipTrunkGroup <trunkgroup> signaling authentication authPassword
  3. In another CLI session, do a
    set addressContext <context> zone <zone> sipTrunkGroup <trunk group> media mediaIpSecondaryInterfaceGroupName <groupname>
  4. Observe that the CPX does not crash.

The code is modified to perform a cdb get to obtain the authPassword. 

Workaround: Do not call for the authPassword while setting the mediaIpSecondaryInterfaceGroupName.

SBX-118082 | SBX-1180491

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: 

  1. Enable the UNENCRYPTED_SRTCP in the cryptoSuiteProfile.
  2. Enable the INFO level DBG logging and make calls.
  3. Check the DBG log for NpMediaRidEnable and NpMediaFlowEnable messages
  4. Ensure that:
    • RTCP = cipher/size 0x8000000/0x40000
    • RTP = cipher/size 0x6000000/0x40000

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-1152131

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-1174351

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: 

  1. Enhancements made to collect more Network Processor (NP) memory area, introduced in a previous fix in 9.2.3R4, causes interference to the interface driver reading the port link status.
  2. The interference causes the driver to falsely report a link down.
  3. The link status is obtained from the NP processor's (Octeon) register.

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:

[root@xxxxx np]# x=1; while [ $x -le 100 ]; do echo $x; date; ./np_mem_dump.pl /var/log/sonus/np/npMem0_d$x.log >& npdump.log ; date; $(( x++ )); done

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-1175781

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-1192501

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: 

  1. Bring down mgt1 interface on the SBX side, critical alarm raised on SBX and same has been reached to EMS
    ip l set mgt1 down
  2. Teardown the connectivity between EMS and the SBC by creating the static route at the SBX side (no trap will be reached to EMS).
  3. Bring the mgt1 interface up on the SBX side. (Clear trap generated on the SBC but not reached to EMS because link between EMS and the SBC is down so which is expected).
  4. Bring the connectivity between EMS and the SBC up (trap re-sync should work and EMS should clear the critical alarm raised on Step 1).

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-1191721

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:

  1. Deploy the SBC.
  2. Add DNS records for SNMP trap target.
  3. Configure DNS nameserver in the SBC.
  4. Configure SNMP trap target fqdn.
  5. Validate that the SBC resolves the fqdn and add the corresponding IP address and port.

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-1186141

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: 

  1. Set the fileCount for accounting files to 2048.
  2. Enable eventLogValidation for account files.
  3. Rollover the log repeated to created 2028 accounting files.
  4. Set the fileCount for accounting files to 32.
  5. Rollover the account log.
  6. Make sure the SBX has not crashed.

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-1181193

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-1168202

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: 

  1. Configure a set of SIP sigPorts.
  2. Unhide debug command.
  3. Issue a command "request sbx xrm debug command acl\ -stat", or "request sbx xrm debug command acl\ -cfg\ 50"

The code is modified to:

  1. Return the count of allocated ACL list.
  2. Specify number of entries to display, which is limited to <= 100. If user does not specify the number of entries, then we will default to 100.
  3. Display allocated ACL rules of each category, either from the beginning of the list, or continue from last entry of previous request.
  4. Have the user repeat the request multiple times to reach the end of the list. 

The change applies to both ACL config and stats.

Workaround: configure less than 10 signaling ports.

SBX-118131 | SBX-1173022

PortFix SBX-117302: The PRS Process and the SM Process is crashing.

ImpactThe PRS process was crashing while processing an MRSP message due to the first header line not being present.

"MSRP 0100543f85f SEND\r\n"
"To-Path: msrp://17000000000.example.com:10000/%s;tcp\r\n"
"From-Path: msrp://12.1.1.71:37001/1789102;tcp\r\n"
"Message-ID: 016f28000567\r\n"
"Byte-Range: 1-25/25\r\n"
"Success-Report: yes\r\n"
"Failure-Report: no\r\n"
"Content-Type: text/plain\r\n"


"Caller sent this message.\r\n"
"-------0100543f85f$\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-1179002

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-1177362

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:
set global signaling oldGsxSupport 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-1159942

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: 

  1. Make SIP-SIP call configuration using the PSX.
  2. At Egress zone, in addition with Egress TG, create three more TGs.
  3. On the SBC, configure the "ingressIpPrefix" of all three TGs (TG1, TG2, TG3) with different server IPs address (IP1, IP2, IP3).
  4. Send 3xx with three Contact headers.
  5. Configure same ingressIpPrefix address in Contact Headers of 3xx message so that the first Contact header is set to IP1, the second Contact Header is set to IP2 and the third Contact Header is set to IP3.
  6. Set "blockDirection" of TG3 to outgoing.
  7. On PSX, Enable "Force Re-query for Redirection" flag in IPSP of Egress Trunkgroup.
    For example:
    Contact: <sip:14135;tgrp=<trunk_group>;trunk-context=meta1001-1002.<domain_name>@IP1>;q=1
    Contact: <sip:14135;tgrp=<trunk_group>;trunk-context=10.xxx.yyy.zz@IP2>;q=0.9
    Contact: <sip:14135;tgrp=<trunk_group>;trunk-context=meta3001-3002.<domain_name>@IP3>;q=0.8
  8. Make an SIP-SIP call, send 3xx from Egress peer with these 3 Contact headers.
  9. The SBC sends INVITE to first Contact header through TG1.
  10. If the first Contact is not reachable, the SBC tries with the second Contact using TG2 and so on.
  11. Verify that after receipt of 3xx with multiple contact headers, the TRM debugs are logged in DBG with trunk group names of all 3 Contact headers and there is no TRM failure message.

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-1148182

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
comm
set addressContext default intercept callDataChannel LigCDC interceptStandard etsi ipInterfaceGroupName LIG
set addressContext default intercept callDataChannel LigCDC mediaIpInterfaceGroupName LIG
comm
set addressContext default intercept callDataChannel LigCDC vendorId utimaco
set addressContext default intercept callDataChannel LigCDC dsrProtocolVersion 1
comm
set addressContext default intercept callDataChannel LigCDC mediationServer dfxa media udp
set addressContext default intercept callDataChannel LigCDC mediationServer dfxa media udp ipAddress 10.xxx.yy.zzz
set addressContext default intercept callDataChannel LigCDC mediationServer dfxa media udp portNumber 37502
set addressContext default intercept callDataChannel LigCDC mediationServer dfxa media udp dscpValue 16
comm
set addressContext default intercept callDataChannel LigCDC mediationServer dfxa media udp mode inService
set addressContext default intercept callDataChannel LigCDC mediationServer dfxa media udp state ena
comm
set addressContext default intercept callDataChannel LigCDC mediationServer imsa signaling
set addressContext default intercept callDataChannel LigCDC mediationServer imsa signaling ipAddress 10.xxx.yy.zzz
set addressContext default intercept callDataChannel LigCDC mediationServer imsa signaling portNumber 38154
set addressContext default intercept callDataChannel LigCDC mediationServer imsa signaling dscpValue 16
set addressContext default intercept callDataChannel LigCDC mediationServer imsa signaling protocolType tcp
comm
set addressContext default intercept callDataChannel LigCDC mediationServer imsa signaling mode inService
set addressContext default intercept callDataChannel LigCDC mediationServer imsa signaling state ena
commit

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
195 03022022 092259.284953:1.01.07.14012.Info .SIPSG: sipsgCallProcCommonUtils.c (-6170) 4022. SipSgSelectTransportAndSigPort: Selected address 10.xxx.yy.zz:5061 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

  1. All messages toward the customer MUST be sent with a PCV header and use provisioned ioi values.
  2. ioi in the PCV header will be the customer's assigned value for the PARTNER generating it.
  3. When messages from PARTNER have a PCV with ioi, the ioi needs to be overwritten with the customer assigned PARTNER value.
  4. Messages from the SBC may have a PCV but without ioi params in it.

Partner network

  1. PCV may/may not be received from PARTNER with/without ioi params
  2. PCV is not sent toward PARTNER in most cases but some PARTNER networks may want this in the future
  3. So, this needs to be configurable and where applicable, provisioned ioi values used in the PCV in messages to the PARTNER
  4. However in testing, when the far end is not set to sendPCV, the 18x/200 OK back to the Ingress trunk does not get sent the Term-IOI value, only the Orig-IOI in the 18x/200 OK. However, on the 200 OK from the BYE there is both Term/Orig IOI.

Ingress TG:
generateOrReplacePCV {
state enabled;
origIOI orig.Toledo.iqntipx;
termIOI term.Toledo.iqntipx;
sendPCVHeader enabled;

Both SIPCORE TGs.
generateOrReplacePCV {
state disabled;
sendPCVHeader enabled;

Egress TG:
generateOrReplacePCV {
state enabled;
origIOI orig.cust.iqntipx;
termIOI term.cust.iqntipx;
sendPCVHeader disabled;


A Call Flow Partner Peer PARTNER TG on the SBC TG on the SBC peer
4 <------- INVITE w/o PCV -------
-------- 18x w/o PCV ---------> <------------ INV w/o PCV ----------
---- 18x w [PCV w prov term-ioi] -→

Root Cause: The following configuration must be enabled:

Ingress TG:
generateOrReplacePCV {
state enabled;
origIOI orig.Toledo.iqntipx;
termIOI term.Toledo.iqntipx;
sendPCVHeader enabled;

Both SIPCORE TGs.
generateOrReplacePCV {
state disabled;
sendPCVHeader enabled;

Egress TG:
generateOrReplacePCV {
state enabled;
origIOI orig.cust.iqntipx;
termIOI term.cust.iqntipx;
sendPCVHeader disabled;

The issue is noticed for the following call flow:

Call Flow Partner Peer PARTNER TG on the SBC TG on the SBC peer
4 <------- INVITE w/o PCV -------
-------- 18x w/o PCV ---------> <------------ INV w/o PCV ----------
---- 18x w [PCV w prov term-ioi] -→

Steps to Replicate: The issue can be replicated by configuring the following:

Ingress TG:
generateOrReplacePCV {
state enabled;
origIOI orig.Toledo.iqntipx;
termIOI term.Toledo.iqntipx;
sendPCVHeader enabled;

Both SIPCORE TGs.
generateOrReplacePCV {
state disabled;
sendPCVHeader enabled;

Egress TG:
generateOrReplacePCV {
state enabled;
origIOI orig.cust.iqntipx;
termIOI term.cust.iqntipx;
sendPCVHeader disabled;

The issue is noticed for the following call flow:

A Call Flow Partner Peer PARTNER TG on the SBC TG on the SBC peer
4 <------- INVITE w/o PCV -------
-------- 18x w/o PCV ---------> <------------ INV w/o PCV ----------
---- 18x w [PCV w prov term-ioi] --->

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.

Resolved Issues in 09.02.04R000 Release

The following Severity 1 issues are resolved in this release:

Severity 1 Resolved Issues


Issue IDSevProblem DescriptionResolution
1SBX-1165681

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: 

  1. Simulate ingress precondition interworking scenario with preconditions set to supported under trunk group configurations.
  2. Send mandatory preconditions in the SDP.
  3. Send multiple 18x towards ingress and do not send SDP in subsequent 18x messages.
  4. The second 18x message without SDP may contain Require preconditions.

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.

2SBX-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: 

  1. Start the SBC.
  2. Review the LCA log.

Skip the configuration process if there is nothing to configure.

Workaround: None

3SBX-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

4SBX-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: 

  1. The  UAC sends an INVITE to the SBC.
  2. The SBC sends an INVITE to the UAS.
  3. The UAS sends a 180 Ringing code without a SDP.
  4. The SBC starts playing a tone towards the UAC due to a delayed LRBT.
  5. The UAC sends an UPDATE for HOLD.
  6. The SBC stops playing the tone and sends a 200 OK for UPDATE code.
  7. The UAC sends an UPDATE for un-HOLD to the SBC.
  8. The SBC sends 200 OK for UPDATE code.

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.

5SBX-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: 

  1. Set sendSdpInSubsequent18x to disable.
  2. Set sendSdpInSubsequent18x to enable.
  3. Change the SDP in the first unreliable 180 and the second reliable 180.
  4. The SDP is queued.
  5. A 180 ringing code with current SDP is sent out to Ingress and an offeranswer is completed.
  6. The same SDP offeranswer in the first unreliable 180 and the second reliable 180 state is completed.

The code is modified to address the issue.

Workaround: None

6SBX-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: 

  1. Configure the rule to access a double quote string display name of URI header, or any parameter.
  2. After it is input, display the name.
    Example:
    From: "PhoneLite \\\"test1\\\"test2 " <sip:[field0]@dns.com>;tag=testing

The code is modified to address the issue.

Workaround: There is no workaround.

7SBX-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: 

  1. During a Leg A to Leg B call, Leg B successfully REFERS the call to leg C.
  2. Leg C attempts to REFER the call to leg D (or back to leg B).
  3. The SBC plays a ringtone towards leg A while the REFER is taking place.
  4. When Leg D rejects the call with a 480 "Temporarily not available" the SBC software is not correctly disabling the call context that is playing the tone and not correctly re-enabling the Leg A to Leg C call association.

Steps to Replicate: 

  1. The DLRBT is configured on ingress and egress of the SBC.
  2. Establish a Leg A to Leg B call via the SBC.
  3. Send a REFER from Leg B Leg C and complete the refer related signaling. This results in a Leg A to Leg C call.
  4. Send a REFER from Leg C to Leg D.
  5. Do not answer the call at Leg D, but reject it with a 480 "Temporarily not available".
  6. Verify that the SBC stops playing a tone towards Leg A and re-establishes the Leg A to Leg C call again and media can correctly flow between  Leg A and Leg C.

The code is modified to address the issue.

Workaround: Not available

8SBX-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.

9SBX-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.

10SBX-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: 

  1. Configure the call routing profile with new scripts and run a call.
  2. The ERE should send the script in policy response.
  3. The SBC should play the announcement .

Two new scripts are seeded:

  • RBBN_CALL_REJECT_217
  • RBBN_CALL_REJECT_ANN217

Workaround: None

11SBX-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: 
When the RTCP NAPT learning is completed before the RTP NAPT learning for the T.140 stream, the RTP port is set to 0 instead of 5004. 5004 is required for the RTP NAPT learning to continue.
As the remote RTP port is set to 0, instead of 5004 for the T.140 stream, the RTP NAPT learning is disabled, resulting in one way media for the stream.

Steps to Replicate: 

  1. Run a basic SIP to SIP call with multiple streams (Audio+T.140) and NAPT & RTCP enabled.
  2. Send the RTCP packets from the far end before the RTP packets to ensure that the RTCP NAPT learning happens prior to the RTP NAPT learning.

In a multiple stream scenario, when the RTP Port is 0, set it to loop back port 5004.

NOTE: The issue is observed only when the NAPT is enabled on both sides.

Workaround: 

  • Disable  the RTCP
    or
  • Ensure endpoint sends the RTP before the RTCP.
12SBX-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: 

  1. Perform an upgrade.
  2. Logs will show the model update being done on every restart.

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.

13SBX-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: 

  1. The UAC sends an INV to the UAS via GW1-GW2.
  2. The UAS sends a 180 Ringing.
  3. GW1 starts a tone play.
  4. The UAS sends a 200 OK with a sendonly.
  5. GW2 sends an ACK to UAS.
  6. GW1 sends a 200 OK for INV.
  7. The UAC sends an ACK.
  8. GW sends a Re-INV with a sendonly.
  9. The UAC sends a 200 OK with a recvonly.
  10. The UAS sends a Re-INV with a sendrecv.

The code is modified to address the issue.

Workaround: None

14SBX-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: 

  1. Leg A calls leg B.
  2. Leg B sends an ACK and reInvite.
  3. The ACK drops the peer response 491 for reInvite.
  4. The  SBC sends an ACK for 491.
  5. The Peer sends a 200 OK from the initial Invite.
  6. The SBC sends an ACK.

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: 

  1. Execute the TLS Session Status command with active TLS calls on the SBC.
  2. Session IDs will be printed with a zero instead of the valid Session IDs.

The code is added to print Session IDs in TLS Session Status command output.

Workaround: None

16SBX-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: 

  1. Login to the EMA.  
  2. Navigate to Monitoring > Alarm > Current Alarm.
  3. Alarm Severity shows as  Urgent instead of Critical.

The code is modified to address the issue.

Workaround: None

17SBX-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.

  • The SBC uses the MTU of the outgoing network interface as the Path MTU.
  • The SBC does not update IPv6 Path MTU properly even if a router in the path sends an "ICMPv6 Packet Too Big" message with a  smaller Path MTU value. The large IPv6 packets requiring fragmentation to fit the Path MTU from the SBC will not reach the SIP peer.

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: 

  1. The SBC sends IPv6 packets of 1500 bytes toward the SIP peer when a path to the peer has a smaller MTU (e.g. 1280 bytes).
  2. A router with the smaller MTU sends an "ICMPv6 Packet Too Big" to the SBC.

The code is modified for handling "ICMPv6 Packet Too Big" messages by adding:

  • ipInterfaceGroup
    and
  • addressContext 


Workaround: Add subnet routes on packet interfaces to the peer.

18SBX-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: 

  1. Create a SMM profile to select new a Ingress TG using sipParamBasedActionProfile.
  2. Attach a SMM profile to the expected original ingress TG.
  3. Enable a block direction feature on the expected new ingress TG.
  4. Run a basic call, registration, or any non-invite scenario.
  5. Once the new ingress TG  is selected using sipParamBasedActionProfile, The SBC should reject the INVITE or non-INVITE message with a 503.

The code is modified to address the issue.

Workaround: None.

19SBX-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:

set oam accounting admin eventAcctMethods [eventRegister | eventSubscribe | eventMessage | eventPublish | eventRefer | eventOptions ] [enable | disable]

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:

  1. Execute the following CLI command:
    set oam accounting admin eventAcctMethods eventOptions enable
  2. Send a SIP OPTIONs message.
  3. Options Ping get a 480 response.

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:

set oam accounting admin eventAcctMethods [eventRegister | eventSubscribe | eventMessage | eventPublish | eventRefer | eventOptions ] [enable | disable]

20SBX-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: 

  1. Bring up a SWe port redundancy setup.
  2. Configure the pkt0 and pkt1 interfaces with different VLAN's.
  3. Run a script for a long duration (2 -3 days) which would start/stop the  Tshark continuously on a tagged interface.
  4. Check that there is not a link down event reported.

The code is modified to address the issue.

Workaround: None.

21SBX-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: 

  1. Create an HFE2.0 set up with private endpoint in a subnet different from any of the HFE interfaces.

  2. Set the CUSTOM_ROUTE natvar to route to this endpoint using eth1,e.g. 10.x.xx.x/xx_eth1.

  3. During the startup, ensure that traffic is occurring between the SBC PKT1 and the private endpoint during HFE startup.

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.

22SBX-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: 

  1. The ingress SIP trunk has an enabled stiProfile assigned.
  2. Make a SIP-SIP call with a PSX query.
  3. The PSX does an LNP lookup to a SIP SCP which returns multiple routes.
  4. The second route has the "Undo LNP" flag checked on its IP signaling profile.
  5. When the SBC sends the INVITE on the first route, no response is received. This causes the second route to be selected.

The code is modified to address the issue.

Workaround: None.

23SBX-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: 

  1. Run a basic SBC and PSX configuration to allow SIP to SIP calls.
  2. On a PSX egress IP signaling profile, the following commands need to be enabled: 
    Egress IP Attributes > SIP Headers and Parameters > Flags > include CPC information
    Egress IP Attributes > SIP Headers and Parameters > CPC Mapping Flags > Map CPC when Presentation is Restricted
    Egress IP Attributes > SIP Headers and Parameters > CPC Mapping Flags > Send CPC Param In→PAI
    Egress IP Attributes > Flags > Disable 2806 compliance
    Egress IP Attributes > Flags > TTC ISUP Mapping
    Egress IP Attributes > Privacy > Privacy Information > P Assert Id
    Egress IP Attributes > Privacy >Flags > Include Privacy
  3. On the SBC ingress and egress TG’s, enable the cpcInterworkingForNNI, such as:
    set addressContext default zone ZONE2 sipTrunkGroup PCR5001_SBX_EXT signaling cpcInterworkingForNNI enabled
  4. Send a basic INVITE from peer A to SBX ingress TG.
  5. In addition to basic headers, the following should be included: 
    Privacy: id
    P-Asserted-Identity: "0363572050"<tel:+88888888888;cpc=ordinary>, "Anonymous"<sip:n363572050@username.xxxx.xx.xx>
  6. Verify that the SBC sends an INVITE to egress.
  7. The egress INVITE should include a PAI header with cpc=ordinary placed in the URI before the @<ip address>, such as: 
    P-Asserted-Identity: "Anonymous" <sip:363572050;cpc=ordinary@10.xx.x.xx:xxxx>, <tel:88888888888;cpc=ordinary>

The code is modified to address the issue.

Workaround: 

  • If "Disable 2806 compliance" is set to "disabled", the issue is not present.
  • If "Disable 2806 compliance" is enabled (as a requirement), there is no workaround.
24SBX-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

25SBX-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: 

  1. Execute a TLS Session Status command with active TLS calls on the SBC.
  2. Session IDs are printed as a zero instead of as valid session IDs.

The code is modified to address the issue.

Workaround: None

26SBX-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: 

  1. Make a simple SIP-SIP call and validate the CDR subfield 60.
  2. The Called Asserted Identity displays the  name as "%XXX CUSTOMER RD%".
  3. The Called Asserted Identity [sf:60] "CUSTOMER ROAD"
    NNI-Type [sf:61] <sip:+12345678912@162. xxx.yy.zzz;user=phone>.

The code is modified to address the issue.

Workaround: None

27SBX-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:

.SIPSG: sipsgSbyMsgProc.c (-863) 179922. UNRECOGNIZED message received on standby, message type=0x23D47, rcvIcm=0xF00E003E, txIcm=0xC0

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.

28SBX-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: 

  1. Modify a Sam Process source code to create several socket file descriptors to simulate a DoS condition.
  2. Perform the OCSP queries for SIP-TLS sessions. 

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.

29SBX-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: 

  1. Have relay of REFER message enabled in the IP signaling profile.
  2. Have a SIP transparency profile with an "all" entry assigned to the SIP trunk groups.
  3. Make a SIP to SIP call.
  4. From the UAS, send a REFER to perform a blind transfer.
  5. The REFER contains a Refer-To header with the URI User-To-User parameter.
    Example:
    Refer-To: <sip:+12345678@ john.smith.com?User-to-User=0059a390f3d2b7310023a2%3Bencoding%3Dhex>

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.

30SBX-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.


When a new hash entry is inserted into the hash table, the hash table logic tries to insert the new hash entry after the corrupted list. This results in a SAM coredump.

Steps to Replicate: 

  1. Make a SIP-SIP with an ERE call setup.
  2. Disable the "multipleContactsPerAor"
    set global signaling sipSigControls multipleContactsPerAor is disabled.
  3. Disable "surrogateRegistration".
    set addressContext <addressContext_name> zone <zone_name> ipPeer <peer name> surrogateRegistration state is disabled.
  4. Do a few SIP registrations and delete the entries.
  5. Deletion of SIP Registration works without any issue.

The code is modified to remove the cache entry from the hash table before freeing up the complete cache RCB block.

Workaround: None

31SBX-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.


Since the core is unused, it's function type(oam/sig/media/xcode/thirdparty) is not defined, rendering the field with a null value. The EMA reads this information from the backend and parses the fields incorrectly.  Field values are unintentionally shifted towards the left, resulting in a corresponding field's validation error.

Steps to Replicate: 

  1. reate an SBC SWe with an over-provisioned vCPU (depending on your traffic profile).
  2. Navigate to Monitoring > Dashboard > CPU Usage.
    A pop-up window appears.
  3. Observe the results.

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.
This issue is not observed on an SBC SWe when none of the vCPUs allocated to the SBC SWe VM are left unused.

32SBX-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

33SBX-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: 

  1. Make a call.  
  2. Enter a hostName in the From header that is longer than 64 bytes.

The code is modified to address the issue.

Workaround: None

34SBX-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: 

  1. Login to the EMA.
  2. Enable the CDR Viewer and SIP Ladder.
  3. Verify that all the parts of the SIP message are displayed as a single message in the ladder diagram.

The code is modified to address the issue.

Workaround: None

35SBX-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: 

  1. From the SBC CLI run: show table alarms historyStatus.
  2. A list of cleared alarms is displayed.
  3. Clear the alarm history by using the Request Alarms Clear History.
  4. In the EMA under section:  Monitoring > Dashboard > Alarms > Cleared Alarms. The list should be empty.

The code is modified to address the issue.

Workaround: None

36SBX-112945



1

The SRTP and the ENCRYPT "IN USE" counters leak for call flows with two transfers that use the INVITE with Replaces.

Impact: 

  1. In a multiple call pick-up (multiple INVITE w/ Replaces) scenario, "IN USE" counters of the SRTP and the ENCRYPT license do not decrement after the call termination, which causes the counter to leak.
  2. In a multiple call pick-up (multiple INVITE w/ Replaces) scenario, after the second call pick-up, the SBC-RTU "IN USE" counter decrements.

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.
This also affects the ENCRYPT and the SRTP licenses when the "IN USE" counter does not reset after a call termination.

Steps to Replicate: 

  1. Setup: Phonerlite (TLS/SRTP) - SBC - SIPp (UDP).
  2. Leg A calls Leg B.
  3. Leg C sends an INVITE with Replaces (Replace header contains the Call-ID, From, and To tags of Leg B) to replace Leg B. This makes the first call pick-up.
  4. Once the first call pick-up completes, Leg B drops out of the call making Leg A - Leg C in the active call.
  5. Leg D sends an INVITE with Replaces (the Replaces header contains the Call-ID, From, and To tags of Leg C) to replace Leg C. This makes the second call pick-up. The second pick-up call is established between Leg A - Leg D.
  6. Observe that the SBC-RTU "IN USE" counter is reset to 0 after the second pickup is successful.
  7. Use the licenseInfo CLI command.
  8. Leg A disconnects the call by sending a SIP BYE.
  9. The Call is terminated gracefully.
  10. Observe that the ENCRYPT and the SRTP license "IN USE" counter does not decrement after the call termination.
  11. Use the licenseInfo CLI command.

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.

37SBX-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: 

  1. In the Ingress Invite of the offer SDP, add the m=application line along with audio m line.
  2. At the Egress, the SBC should do a DNS lookup (cache should be cleared before, so that the SBC queries the DNS.)

The code is modified to address the issue.

Workaround: Use the actual IP address in the IP peer, instead of the FQDN.

38SBX-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

39SBX-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.
The issue only happens if 6 or more Diversion headers are received but fewer than 5 of them are unique.

Root Cause: Removing duplicate Diversion headers from information sent to the PSX causes a crash.

Steps to Replicate: 

  1. Configure the stiProfile by enabling and assigning to the Ingress trunk group.
  2. Send a SIP INVITE containing 6 Diversion headers, but only 2 of them are unique. 

The code is modified to address the issue.

Workaround: None.

40SBX-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: 

  1. Enable the LRBT with no transcode support.
  2. The Ingress is 0 18.
  3. The Egress is 0 18.
  4. The Egress responds with a 180, and a trigger tone.
  5. The Egress sends a 180 with a 0 on the Ingress.
  6. The Egress then sends a 200 with a 18.
  7. The Call is cleared by the SBC.

The code is modified to address the issue.

Workaround: None

41SBX-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:

  1. Leg A is an Audio and Video Call.
  2. Leg B rejects the Video by putting the media Port to "Zero."
  3. Then Leg B REFERs Leg C to Leg A, without putting Leg A on Hold.
  4. The SBC offers a Leg with both Audio and Video.
  5. Leg C also answers back with both Audio and Video.
  6. The SBC is not able to map the video legs after the Refer.

Steps to Replicate: 

  1. Make  an Audio and Video Call from Leg A to Leg B.
  2. Reject the Video from Leg B.
  3. Send a REFER from Leg B, referring Leg C to Leg A.
  4. From Leg C, answer with both Audio and Video,

The code is modified so that the SBC can now map to the correct video leg post REFER.

Workaround: None

42SBX-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: 

  1. In a GW-GW call, GW2 receives a Re-INVITE with a G711A from the Egress peer.
  2. The Ingress GW auto answers.
  3. "Minimize Relaying Of Media Changes From Other Call leg" and "Lockdown Preferred Codec" is enabled in the Ingress IPSP of GW1.
  4. GW2 sends a 200 OK response with a G711A  and correct payload type 8.

The code is modified to address the issue.

Workaround: None

43SBX-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

44SBX-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.

45SBX-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: 

  1. Run a G711<=>OPUS call beginning the call as a PCMU.
  2. Send a re-invite on the G711 leg to change the call to a PCMA.
  3. This triggers a modify on both the legs, with the modifyAudioCodec flag set.

The code is modified to address the issue.

Workaround: None

46SBX-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

47SBX-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: 

  1. Configure an SMM variableScope rule on an output message, Egress (Leg B and Leg C).
  2. Leg A calls Leg B.
  3. Leg B redirects to Leg C.
  4. Memory will increase slowly over time.

The code is modified to address the issue.

Workaround: Remove the SMM rule

48SBX-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: 

  1. Configure the DNS server with a DSCP value.
  2. The DNS server blacklisting is enabled.
  3. The DNS query is configured to the DNS server.
  4. The DNS server should be down during this process.
  5. The configured DNS server is blacklisted and sending a DNS probe packet towards the DNS server with a configured DSCP value.

The code is modified to set a configured DSCP value for the packets, including the DNS probe packets.

Workaround: None

49SBX-1171221

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.

Look for these messages in the logs:

MAJOR .SIPSG: sipsgRedund.c (-2424) 2530. Ingress: Mirroring CallData for GCID 0x443B48 failed: Available buffer space (msg size=64172) exhausted?
AND
MAJOR .EVLOG: SYS ERR - Error 0x3a3c Line 2426 File /sonus/p4/ws/release/release.we.sbx5000_V08.02.03A012/marlin/SIPSG/sipsgRedund.c.

Then attempt and upgrade and look for this message in the logs:
MAJOR .SIPSG: sipsgRedund.c (-1613) 1967147514. Syncing CallData for gcid 0x1E0E4D36 failed: Available buffer (size 27204) exhausted

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.

50SBX-1144581

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.

51SBX-1161561

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.

52SBX-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.

53SBX-1171871

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: 

  1. Create a digitParameterHandling dmPmRule with a subRule type of uri.
  2. Set the uriParameterManipulation->userInfoManipulation->replacement->type field to noChange.
  3. Export the configuration through the EMA.

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.

54SBX-1164681

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: 

  1. Enable transparency contact header.
  2. The Iad register to registrar where contact header has +sip.instance and reg-id.
  3. The Iad did not send refresh in time trigger SBC to send unregister to registrar.

The code is modified to address the issue.

Workaround: None.

55SBX-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

56SBX-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: 

  1. The soft link can be manually created:
    ln -s /bin/kmod /sbin/insmod
  2. Then the instance can be rebooted.
57SBX-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:

  1. Create an announcementPackage test_pkg_1 with an element test_element_1.
    Example:
    set profiles media announcementPackage test_pkg_1 packageId 101 element test_element_1 segmentId 11111
  2. Show the announcementPackage to verify it is created correctly. 
    Example:
    Show the profiles media announcementPackage test_pkg_1.
    It should display as:
    packageId 101;
    element test_element_1 {
    segmentId 11111;
    }
  3. Delete a test_element_1 from the package. 
    Example:
    Delete the profiles media announcementPackage test_pkg_1 element test_element_1
  4. Show the announcementPackage to verify test_element_1 is removed. 
    Example:
    Show the profiles media announcementPackage test_pkg_1.
    It should display as (without any elements)
    packageId 101
  5. Delete the package and verify it is successfully deleted. 
    Example:
    Delete the profiles media announcementPackage test_pkg_1.

The code is modified to address the issue.

Workaround: The announcement package can be deleted and then re-created without the required element.

58SBX-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.

59SBX-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:

  • honorEmbeddedHeadersin3xx
  • includeEmbeddedPAIheaderInRedirectedInvite
60SBX-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: 

  1. Create the HFE PKT1 with a public IP on the eth1.
  2. Verify that the HFE_PKT1 successfully comes up and does not have error logs in the /opt/HFE/log/HFE_conf.log.

The code is modified to add the default route through eth1.

Workaround: 

  1. Create an HFE without a public address.
  2. Attach a public address after the HFE instance configures.

The following Severity 2-4 issues are resolved in this release:

Severity 2-4 Resolved Issues


Issue IDSevProblem DescriptionResolution
1SBX-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: 

  1. Log in to the EMA.
  2. Navigate to Routing and click the Route tab.
  3. Create a route with & and @ in Destination National.
  4. Edit the same and change the Routing label.


The code is modified to address the issue.

Workaround: No workaround.

2SBX-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.

3SBX-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.

4SBX-1170512

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.

5SBX-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.

6SBX-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: 

  1. Enable sendSbcSupportedCodecsForLateMediaReinvite in ingress TG IPSP and with multiple codecs supported in PSP, make a late media call.
  2. Prack from ingress endpoint has a codec different from the first codec in late media offer sent by the SBC with multiple codecs in 180.
  3. Check tone is with the selected codec in Prack.

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.

7SBX-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: 

  1. Have an IMS LI setup ready.
  2. Make a complete Registration. (Reg,401,Reg,200).
  3. Delete the Registration by a De-Reg from client.
  4. Retransmit the same De-reg from client (we can have some pause of say 10 secs) 

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.

8SBX-114151 | SBX-1169462

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.

9SBX-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: 

  1. Bring up an HA setup.
  2. Run a basic Registration.
  3. Perform a switchover.

Expected Results:
After a switchover, all the RCBs should be present in new active box.

Actual Results:
Not all RCBs are not synced to the SBC box.
Log message being seen:
.SIPSG: sipsgRedund.c (7734) 1621. SipsgRedundLoadRegAgentData: insufficient Buffer Size(15972) Required Size is (20195)

The code is modified to address the issue.

Workaround: None.

10SBX-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.

11SBX-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.

12SBX-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: 

  1. Configure AD sync.
  2. Set the time to 1:00 AM on the day of the current year where daylight saving time ends.
  3. After 2:00 AM on that day, turn on info level logging.
  4. Observed in the debug logs that the message:
    DAP_CONFIG: Performing Sync Interval AD Sync Success appears.

The code is modified to return a time greater than the passed-in time when switching from Daylight Saving Time.

Workaround: None.

13SBX-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:

  1. Send a 200 OK for re-INVITE from EGRESS PEER without SDP.
  2. Send a 200 OK for re-INVITE from EGRESS PEER with SDP but changed CODEC.
  3. Send a 200 OK for re-INVITE from EGRESS PEER with SDP.
  4. Send a 4xx (for re-INVITE) from EGRESS PEER.

The code is modified to add SDP in ACK for late media cases.

Workaround: None.

14SBX-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:

  1. Enable honorSdpClockRate TG flag.
  2. Disable different2833palyloadtype flag.
  3. Configure multiple codecs including EVRCB0(103) in Egress Route-PSP.

To re-create the issue:

  1. Ingress offer received by the SBC:
    m=audio 48820 RTP/AVP 102 0 103 105 97 8
    102 AMR-WB/16000 (b/w efficient / open mode-set)
    0 PCMU/8000
    103 telephone-event/16000
    105 telephone-event/8000
    97 AMR/8000 (b/w efficient / open mode-set)
    8 PCMA/8000
  2. Egress offer sent by the SBC on the egress

m=audio 5096 RTP/AVP 102 97 0 110 101 107 103 98 96 105
102 AMR-WB/16000 (b/w efficient, mode-set=0,1,2)
97 AMR/8000 (b/w efficient / open mode-set)
0 PCMU/8000
110 AMR-WB/16000 (octet-align, mode-set=0,1,2)
101 AMR/8000 b/w efficient / open mode-set)
107 EVRCB/8000
103 EVRCB0/8000
98 EVRC/8000
96 EVRC0/8000
105 telephone-event/8000

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.

15SBX-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: 

  1. Send a SUBSCRIBE from the UAC.
  2. Send a challenge SUBSCRIBE without a to-tag.

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.

16SBX-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:

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 attempts to send 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:
set addressContext default zone <zone name> sipTrunkGroup <TG name> signaling doNotAutoAnswer <enable/disable>

The code is modified to only print the logs at INFO level.

Workaround: None.

17SBX-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.
set global signaling sigOnlyMode sigOnlyModeValue global

If the sigOnlyMode flag is set to global, copy the local IP information.

Workaround: Disable the following control:

set global signaling sigOnlyMode sigOnlyModeValue off

18SBX-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: 

  1. Login to EMA. Generate an alarm by disabling PSX_LOCAL_SERVER.
  2. Navigate to Monitoring > Alarms > Current Alarms. Alarm will appear in the Current Alarms screen.
  3. Clear the alarm by enabling PSX_LOCAL_SERVER.
  4. Navigate to Monitoring > Alarms > Cleared Alarms. Alarm cleared will appear

The code is modified to retrieve the alarms from CDB and return them to UI for display purpose.

Workaround: No workaround.

19SBX-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: 

  1. Run the following configuration:
    sipTrunkGroup IAD signaling callingPalingParty enabled
    Incoming msg has:
    P-Asserted-Identity: "12345 test user " <tel:+18038830789;rn=214960>, "12345 test user" <sip:+18038830789;rn=214960@test.com>
  2. Use the outgoing INVITE
    From, contact userpart is 12345

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.

20SBX-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: 

  1. Start up the SBC with an ASAN build.
  2. Ensure that the SBC comes up.
  3. In non-ASAN builds, this does not prevent the SBC from starting up although it could be accessing previously freed memory.

Store the IP parameter in a location that is not freed before the call was made to send the trap.

Workaround: None.

21SBX-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: 

  1. Make a A-B Normal call.
  2. Send 200 OK from User B.
  3. Send ACK towards User B.
  4. Send BYE from A and terminate the call.

The code is modified to avoid unwanted flow to get executed.

Workaround: None.

22SBX-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: 

  1. Enable the maskportforRcb Flag and on ingress side set require registration to required.
  2. Send register and receive a 200 OK with p-Associated URI (To create child RCB) on UDP.
  3. Send an INVITE with child user on TCP without specifying the port.
  4. Verify that the RCB is found and INVITE is routed properly.

Update the child information correctly based on the masking flags, then mirror to standby.

Workaround: Not available.

23SBX-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
CVE-2021-45105 and CVE-2021-44832 are reported against log4j 2 versions 2.16 and prior.

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.

24SBX-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. 

25SBX-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: 
set oam eventLog typeAdmin acct compressionSupport only

Rollover the accounting log twice
request oam eventLog typeAdmin acct rolloverLogNow
request oam eventLog typeAdmin acct rolloverLogNow

Verify that the timestamp in .ACT.gz file in the log file directory has a timestamp of the form: yyyymmddhhmmss

The code is modified so the file name form is now yyyymmddhhmmss
Ex: 20220118125936
18th January 2022 12:59:36
The hours are in 24 hour format

On a Nto1 system, the filename is of the form:

<Actual Server Name>_yyyymmddhhmmss_<SequenceNumber>.ACT.gz
The Actual Server Name can be viewed with the cli command
show table system serverAdmin <Server Name> actualCeName

Workaround: The timestamp in the logs can be converted to a human reading form with the linux command
date -d@<linux style timestamp>

26SBX-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.

27SBX-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.

28SBX-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.

29SBX-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: 

  1. Establish a scenario in which NICE server starts/stops multiple recording sessions for each call.

  2. Monitor memory on the Standby to see if is growing.

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.

30SBX-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

or

request addressContext <context name> zone <zone name> sipArsEndpointRecoveryByIp ipAddress <ip> port <port>

31SBX-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: 

  1. Configure a radius authentication server to point to a radius server that is unavailable.
  2. Configure the outOfService time to be 60 minutes.
  3. Run the ssh into the CLI.
  4. Run a show status oam radiusAuthentication radiusServerStatus and verify that the availableAt time is one hour in the future.

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

32SBX-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.
But if ACK sending failed due to DNS resolution, then the SBC does not trigger BYE during call cleanup and in this case call control block is not getting freed, causing a memory leak.

Steps to Replicate

Basic call with SIP Rec feature enabled.
Simulate the SIP Rec server to send FQDN in 200 OK (200 OK of INVITE) and make sure DNS resolutions fails and this causes memory leak.

The code is modified to clear call control bock when a cleanup timer expires.

Workaround: Not applicable.

33SBX-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: 

  1. Run a direct media call.
  2. Enable the sendPtimeInSdp and preferPtimeInSdp.
  3. Send ptime value of 20 in ingress INVITE.

The code is modified so the doNotAnswer field is the right value.

Workaround: None.

34SBX-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.

35SBX-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.
Customers can state disable and state enable the ipPeer(s) pathCheck state.

36SBX-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.

  1. A call B, B refer to C, with tone places and various codec setup.
  2. Once the LegC received 183 with the SDP, it triggers the SBC to send UPDATE to legC.
  3. LegC answer 200 OK INVITE, 200 OK Update.
  4. LegC sends keepalive trigger a re-INVITE to legA.

The SBC is unable to sends ACK to legA.

The code is modified to address the issue.

Workaround: Disable the e2eAck.

37SBX-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: 

  1. UAC will send an INVITE towards the SLB/SBC.
  2. The SLB/SBC sends the INVITE towards UAS.
  3. UAS will send 183 response messages with merged the VIA headers (including received param) after From and To header towards the SLB/SBC.
  4. The 183 should be routed to the SBC and then towards UAC.

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.

38SBX-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: 

  1. Configure the SBC to run LRBT (local ringback tone).
    config
    set profiles media toneAndAnnouncementProfile EXAMPLE localRingBackTone signalingTonePackageState enable
    set profiles media toneAndAnnouncementProfile EXAMPLE localRingBackTone makeInbandToneAvailable enable
    set profiles media toneAndAnnouncementProfile EXAMPLE localRingBackTone flags useThisLrbtForIngress enable
    commit.
    set addressContext default zone <IngressZone> sipTrunkGroup <IngressTG> policy media toneAndAnnouncementProfile EXAMPLE
    set profiles media toneProfile defRing generationMethod singleTone singleTone tone1Power 0 tone1Frequency 200
  2. Run a G711<=>G711 call such that the Egress Leg sends a 200 OK after some delay. During this Delay, LRBT will be played using TPAD.
  3. Capture the media on UAC and analyze the tone generated for its power.

The code is modified to properly configure the tone Power at DSP.

Workaround: Not applicable.

39SBX-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:
On Cloud SBC or N-to-1 SBC with VLAN packet interfaces, check CE_Node2.log and observe "ioctl: No such device" message for each VLAN interface.
[root@vsbcSystem-ISBC 172.16.16.39 ~]# hwinfo | grep -v "==="
Device Description : Virtual Platform
Chassis Serial : 855f41ee-68be-46c0-8e7a-9e9911a689f4
Product Name : Sonus SBC SWe
Platform : OpenStack Compute
System Memory : 10237248 kB
System Hard Disk : 80 GiB
54.7 GiB

With VLAN the interfaces configured, look for ioctl message in CE_Node logs:
[root@vsbcSystem-ISBC 172.xxx.yy.zz openclovis]# cat CE_Node2.log
Wed Sep 1 17:30:34.337 2021: Welcome to OpenClovis SAFplus Availability/Scalability Platform! Starting up version openclovis-safplus-sdk-6.0-202001031351_42f5846
This file is the standard output of all applications.
ioctl: No such device
ioctl: No such device
[root@vsbcSystem-ISBC 172.xx.xx.xx openclovis]#

B. Show the fix through logs:
CE_Node2.log does not have "ioctl: No such device". Instead DBG log file has the ioctl messages from Sma.
[root@vsbcSystem-ISBC 172.xx.yy.zz ~]# glog
[root@vsbcSystem-ISBC 172.xx.yy.zz openclovis]# cat CE_Node2.log
Wed Sep 1 20:11:19.001 2021: Welcome to OpenClovis SAFplus Availability/Scalability Platform! Starting up version openclovis-safplus-sdk-6.0-202001031351_42f5846
This file is the standard output of all applications.
[root@vsbcSystem-ISBC 172.xx.yy.zz openclovis]# grep Sma /var/log/sonus/sbx/evlog/1000016.DBG | grep ioctl
116 09012021 201307.968434:1.01.00.00115.MAJOR .SMA: *SmaIfIoctl: ioctl returned errno=19. request=35123. ret=-1.
116 09012021 201308.996176:1.01.00.00139.MAJOR .SMA: *SmaIfIoctl: ioctl returned errno=19. request=35123. ret=-1.
[root@vsbcSystem-ISBC 172.xx.yy.zz openclovis]#

The code is modified to log the benign error messages in DBG logs instead of CE_Node log.

Workaround: None.

40SBX-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

41SBX-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.

42SBX-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: 

  1. On egress ipSignalingProfile, enable transparencyFlags warningHeader and relayFlags statusCode4xx6xx:

    1. set profiles signaling ipSignalingProfile DEFAULT_SIP commonIpAttributes transparencyFlags warningHeader enable

    2. set profiles signaling ipSignalingProfile DEFAULT_SIP commonIpAttributes relayFlags statusCode4xx6xx enable

Procedure
--------------

  1. Send an INVITE to the SBC that should be routed to egress endpoint.

  2. On receipt of an INVITE, respond from egress endpoint with 603 Decline including the following warning header:

    Warning: 307 [2607:fxxx:c:xxxx::xx]:xxxx "Session parameter 'foo' not understood", 399 [2607:fxxx:c:xxxx::xx]:xxxx "Robocall Block pl String 1"

  3. Verify that 603 Decline is forwarded to ingress side with the same warning header including the square brackets around both the IPv6 addresses

The code is modified to include square brackets around IPv6 addresses in a Warning header.

Workaround: None.

43SBX-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):

  1. Ingress DSP reason.
  2. Egress DSP reason.

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: 

  1. Run 20k A---B Transcoded call with ingress DSP reason as DTMF.
  2. Change the configuration to pass-through.
  3. Check the logs to see Ingress DSP reason is populated as "No DSP inserted" for a pass-through call.

The code is modified so that the junk value is not populated to the fields.

Workaround: None.

44SBX-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

  1. Set e2eAck to enabled.
  2. A calls B.
  3. B answers with a 18x message.
  4. C replaces A.
  5. B answers with a 200 OK message.

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.

45SBX-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: 

  1. Configure the PC2.0 LI/IMSLI for egress interception.
  2. The delayed RBT is configured for 183 with SDP with RTP Monitoring enabled on Egress Leg.
  3. An INVITE followed by a 180 without an SDP followed by 183, with an SDP followed by RTP followed by 200 OK.

When a 183 is received, the SBC plays the Delayed Ring Back Tone towards the UAC.
When a 200 OK INVITE is received, the SBC stops the Tone and does the media cut through.

The code is modified to not stop the main media along with intercepted media for the this call.

Workaround: Not applicable.

46SBX-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: 

  1. Establish a call over Gw-Gw with codec negotiated as G711.

  2. Send T38 re-INVITE from UAC to SBC1.

  3. The SBC2 sends out this T38 re-INVITE to UAS.

  4. UAS responds back with 488 Not Acceptable.

  5. The SBC2 sends ACK to UAS.

The SBC2 is failing to send a fax fall back re-INVITE to UAS.

Initialization code is added for the new field.

Workaround: None.

47SBX-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.

48SBX-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.

49SBX-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: 

  1. Enable DBG INFO level logging.
  2. Create two TLS profiles as described in the example below:
    set profiles security tlsProfile TEST_ACCESS cipherSuite1 rsa-with-aes-128-cbc-sha
    set profiles security tlsProfile TEST_ACCESS allowedRoles server
    set profiles security tlsProfile TEST_ACCESS authClient false
    set profiles security tlsProfile TEST_ACCESS v1_0 enabled
    commit
    set profiles security tlsProfile TEST cipherSuite1 rsa-with-aes-128-cbc-sha
    set profiles security tlsProfile TEST allowedRoles clientandserver
    set profiles security tlsProfile TEST authClient false
    set profiles security tlsProfile TEST v1_0 enabled
    commit
  3. Assign a second profile to one of the sipSigPort.
  4. Send PDU through the sipSigPort used in Step 3.
  5. Check DBG log and look for error messages and compare the profile ID assigned in Step 2.

The code is modified for both TLS and DTLS profile lookup by name routines to return the requested profile.

Workaround: None.

50SBX-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. 

51SBX-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: 

  1. The UE initiates Late media convert call.
  2. The SBC sends out 200 answer with the below SDP:
    m=audio 1338 RTP/AVP 0 96 100 101
    a=rtpmap:0 PCMU/8000
    a=rtpmap:96 AMR-WB/16000
    a=fmtp:96 mode-set=0,1,2;mode-change-capability=2;max-red=0
    a=rtpmap:100 telephone-event/8000
    a=fmtp:100 0-15
    a=rtpmap:101 telephone-event/16000
    a=fmtp:101 0-15
    a=sendrecv

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.

52SBX-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: 

  1. Perform an A-B call, (Audio + Fax), where Audio is core stream and Fax is non-core stream.
  2. Check for callMediaStatus, once the call is stable.

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.

53SBX-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: 

  1. Spawn a OAM-MSBC setup as seen in the reported case and configure an SNMP trap target.
  2. Perform a sbxrestart on the MSBC standby node.
  3. Verify that the reported logs are not seen.
  4. Verify the timeline for enabling of northbound interface from .SYS log and the timeline for flushing of queued traps from the level log and ensure the difference between them to be >=15 seconds.

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.

54SBX-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: 

  1. Create a OAM/SLB cluster and bring up up nodes in this cluster.
  2. Navigate Administration-> License Management-> Nodes.
  3. Select the node and select few licenses and click on set selected.

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.

55SBX-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: 

  1. Configure the SBC for a basic call.
  2. Configure the Egress precondition interworking related settings.
  3. Run an egress precondition call flow.

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.

56SBX-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: 

  1. UAC sends an INVITE with Audio and Image.
  2. The SBC sends an INVITE with Audio to UAS due to Advertizeaudio flag is enabled.
  3. UAS responds 200 OK with Audio and call gets connected as audio.
  4. UAS sends re-INVITE with Image.
  5. The SBC sends a re-INVITE with both Audio and Image muted causing call teardown.

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.

57SBX-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.
Configure the DLRBT.
Configure "Peer Absence Action" as "Trap and Disconnect" in the PSP.

  1. Send INVITE with SDP(PCMU)from A.
  2. Send from B 180 with SDP.
  3. Send PRACK from A and respond with 200 OK for PRACK from B.
  4. Do not send any RTP from A & B.
  5. Send 200 OK for INVITE from B and send ACK from A.
  6. Do not send any RTP from A & B.

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.

58SBX-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: 

  1. Configure the DNS server with two routes for the FQDN route.
  2. Make an A-to-B call.
  3. The SBC sends an INVITE to first DNS record of and B sends 18x and the 503.

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.

59SBX-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: 

  1. Bring the Application up in the SBC.
  2. Set up the SBC to run the Transparent precondition interworking and downstream forking scenario.
  3. Run a multiple 18x scenario with a delay in the Prack 200 OK response.

The code is modified to release the queued Update in the 200 OK Prack Delay Scenario.

Workaround: None

60SBX-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:
INV(a=inactive)->
INV(a=inactive)->
<-180(no sdp)/prack/200 OK
180(a=inactive)/Prack/200 OK<-
<--x-no media for tone as expected
Update(a=sendrecv)
->200 OK(a=sendrecv)
<-no media for tone though DPM changed to sendrecv

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.

61SBX-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:

  1. Configure the PSX scripts under the psxScriptProfile CLI command:
    Set profile signaling psxScriptProfile <pspname> scriptName1 ATT.xml scriptName2 <name2> scriptName3 <name3>
  2. Associate the psxScriptProfile to the TrunkGroup
    set addressContext <acname> zone <zonename> sipTrunkGroup <tgname> signaling psxScriptProfile <pspname>
  3. Configure the tonepackage having toneProfile as DefaultRingBack and DefaultDialTone.
    set profiles media tonePackage <TonePackagename> packageId <Id> toneType dialtone toneProfile defDial
    set profiles media tonePackage <TonePackagename> packageId <Id> toneType ringbacktone toneProfile defRing
  4. Ensure the 100rel support is enabled
    set addressContext default zone <Ingress_Zone> sipTrunkGroup <IngressTG> signaling rel100Support enabled
  5. Run the preconditionIntwkUsing183 enabled on ingressTG
    set addressContext default zone <Ingress_Zone> sipTrunkGroup <Ingress_TG> services preconditionIntwkUsing183 enabled
  6. Configure term-ioi parameter in the SIP signaling service group
    set addressContext <acname> zone <zonename> sipTrunkGroup <tgname> signaling termIOI <termioiname>


Run the PSX configuration:

  1. Precondition Profile PP_ACCESS associated to Ingress TrunkGroup config:-
    * Preconditions Support If Egress IPTG:disabled
    * Preconditions Strength Mandatory: Policy: enabled ; Priority: 1
    * Preconditions Strength Optional: Policy: disabled ; Priority: 1
    * Use UPDATE when Signaling Preconditions Locally Met:Policy: disabled ; Priority: 1
  2. Configure the RoutingLable with the customer script for terminating the call at PsxScriptProfile

The customer script should be configured with DefaultDialTone and DefaultRingBackTone profiles.

Run the following call:

  1. Make a call that matches the routinglable configured previously with offer having the precondition attributes as follows:
    a=curr:qos local none
    a=curr:qos remote none
    a=des:qos mandatory local sendrecv
    a=des:qos mandatory remote sendrecv
    INVITE should contain : P-charing vector header with orig-ioi.
  2. Verify that the SBC sends p-charing vector with term-ioi in 18x response to ingress EP.

The code is modified to send term-ioi when it is configured without having dependency on the operator Id.

Workaround: None.

62SBX-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: 

  1. Configure a Level 4 call trace to match all messages.
  2. Configure a SMM rule to modify the 100 Trying sent by the SBC.
  3. Make a SIP-SIP call.

The code is modified so that the correct GCID value is printed in both PRE and POST-SMM traces.

Workaround: None.

63SBX-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.

64SBX-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.
2. Apply the same customer configuration. (primarily having same set of ACLs)
3. Verify that the SBC is stable after the configuration.

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.

65SBX-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.

66SBX-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: 

  1. Run a customer call scenario.
  2. Run the scenario with SIP_FW.
  3. Respond to the INVITE with 183 (Dialog-1) from UAS.
  4. Send an UPDATE from UAC, by updating the precondition attributes.
  5. Respond to the UPDATE message with the 200 OK from UAS.
  6. Send back two back-to-back 183(Dialog-2) and 183(Dialog-3) from UAS. The SBC sends an UPDATE message to UAC for the Dialog-2.
  7. Once precondition done for 183 (Dialog-2), the SBC generates a UPDATE for 183 (Dialog-3).
  8. Respond to the UPDATE message from UAC and complete the preconditions for 183 dialog-3 from UAC.
  9. The SBC generates the UPDATE towards the UAS, Send the 200 OK for that UPDATE and complete the preconditions.
  10. Send 200 OK with the Dialog-2 from the UAS.

The call should be established.

The code is modified so the 183 message is released correctly before releasing the second 183 message. 

Workaround: None.

67SBX-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.

68SBX-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.

69SBX-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: 

  1. Bring up 1:1 on cloud.
  2. Import certificates on the Active instance and configure for TLS calls.
  3. Make calls to the active instance.
  4. Perform a switchover.
  5. Make calls to instance that become active.

Expected Result:

  1. Check configuration is successful.
  2. TLS calls on active and standby should be successful.

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.

70SBX-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: 

  1. Bring up SBC with the 10.1 Release.
  2. Configure the P-Charging-Vector related configuration.
  3. Send term-ioi in the 200 OK Response.

The code is modified to save the term ioi in a 200 OK Response.

Workaround: we can try adding missing term-ioi by SMM.

71SBX-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.

72SBX-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.

73SBX-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
From: "phoneLite" <sip:1245@son.com;tag=legA
Use regsub to add missng '>' after .com.

set profiles signaling sipAdaptorProfile FIX_MISSING_GT rule 1 criterion 1 type message
set profiles signaling sipAdaptorProfile FIX_MISSING_GT rule 1 criterion 1 message messageTypes request
set profiles signaling sipAdaptorProfile FIX_MISSING_GT rule 1 criterion 1 message methodTypes invite
set profiles signaling sipAdaptorProfile FIX_MISSING_GT rule 1 criterion 1 message condition exist
set profiles signaling sipAdaptorProfile FIX_MISSING_GT rule 1 criterion 2 type header header name From condition regex-match regexp string > numMatch notmatch
set profiles signaling sipAdaptorProfile FIX_MISSING_GT rule 1 action 1 type header operation regsub
set profiles signaling sipAdaptorProfile FIX_MISSING_GT rule 1 action 1 regexp string ";tag"
set profiles signaling sipAdaptorProfile FIX_MISSING_GT rule 1 action 1 from type value value ">;tag"
set profiles signaling sipAdaptorProfile FIX_MISSING_GT rule 1 action 1 to type header value From
set profiles signaling sipAdaptorProfile FIX_MISSING_GT state enable
commit

The code is modified to address the issue. 

Workaround: No workaround.

74SBX-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: 

  1. Enable the Call Notification feature (or SIPREC recording on egress TG).
  2. Configure SMM profile for outbound messages on egress TG.
  3. Make a basic call.

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.

75SBX-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: 

  1. Late media pass-through call and PRACK is supported only on the ingress leg.
  2. Send Invite without SDP offer from ingress side.
  3. Send 18x without SDP offer from egress side.
  4. After receiving 18x with SDP, respond with PRACK from ingress side.
  5. Send 200 OK from egress side with SDP "a=sendrecv".
  6. Respond with 200 OK with ACK on the ingress side.

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",
ACK is sent with "a=inactive".

So a fix is given to send a re-invite on egress side with "a=sendrecv".

Workaround: Not applicable.

76SBX-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:

  1. A calls B, C replaces A.
  2. C re-Invite to B.
  3. The Ack from C fails to trigger the SBC to send Ack to B.

The code is modified to address the issue.

Workaround: Disable the e2eAck.

77SBX-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.

78SBX-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.

79SBX-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:
--> INVITE (with SDP and P-Early-Media: supported)
<-- 100 Trying
<-- 183 Session Progress (with SDP and no P-Early-Media)
--> PRACK
<-- 200 OK (for PRACK)
--> UPDATE (with SDP)
<-- 200 OK (for UPDATE with SDP)
<-- 183 Session Progress (no SDP but P-Early-Media: sendrecv)
--> PRACK
<-- 200 OK (for PRACK)
<-- 200 OK (for INVITE) (This message gets queued forever)

The code is modified to eliminate the race condition.

Workaround: None.

80SBX-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: 

  1. Call is established between A and B with codec PCMU.
  2. User A initiated a fax a re-INVITE and the call is transitioned to fax.
  3. User B initiates a re-INVITE with change in IP/Port.

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.

81SBX-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.

82SBX-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:

  1. The ingress endpoint is behind NAPT, media NAT learning is enabled on the ingress sipTrunkGroup.
  2. The called party answers the call as "recvonly" and switches to "sendrecv" by sending a re-INVITE.
  3. The ingress endpoint sends RTP packets from the UDP port number 5004.

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.

83SBX-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.

84SBX-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.

85SBX-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: 

  1. Enable transparency for PIDF body at ingress side (Gateway 1).
  2. Run GW-GW call sending PIDF MIME Content with unknown content header "content -ID" from ingress.
  3. Check logs at Gateway 2 to verify the unknown headers in MIME are relayed to Gateway 2.

The code is modified to address the issue.

Workaround: No workaround.

86SBX-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.

87SBX-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: 

  1. Set debug log filterLevel to info.
  2. Configure a call trace filter to match a call.
  3. Make the call.
  4. Set debug log filterLevel to major.
  5. Make the call.
  6. Compare the two traces.

The code is modified to decouple the generation of NRMA call trace logs from the filtering of debug logs.

Workaround: None.

88SBX-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:

MAJOR .EVLOG: SYS ERR - Error 0x3a3c Line 6304 File /sonus/p4/ws/jenkinsbuild/sbx923R0fix/marlin/SIPSG/sipsgRedund.c.

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:
set oam accounting admin eventAcctState enabled
Include five Contact headers

Look for this message in the logs:
MAJOR .EVLOG: SYS ERR - Error 0x3a3c Line 6304 File /sonus/p4/ws/jenkinsbuild/sbx923R0fix/marlin/SIPSG/sipsgRedund.c.

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:
set oam accounting admin eventAcctState enabled

89SBX-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.
2. Start the application.
3. Check the DBG log.

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.

90SBX-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: 

  1. Establish STUN/ICE/DTLS call with two candidates.
  2. Check the audio.

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

91SBX-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
Observe that the SBC does not shutdown.

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

92SBX-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.

93SBX-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.

94SBX-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: 

  1. Create a PKI certificate object and import a certificate that's going to expire soon.
  2. Once the certificate expires, use the "show table system security pki certificate" command to check its status.

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.

95SBX-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: 

  1. Make a SIP-SIP Japan call setup.
  2. Configure a sipJJ9030InterworkingProfile with sipFlavor as JJ9030 along with origIoi and termIoi.
  3. Attach sipJJ9030InterworkingProfile to the ingress TG.
  4. Set the ingress TG's flag "blockDirection" to "incoming".
  5. Make the call and check the presence of the term-ioi paramter in the PCV header of the outgoing SIP 503 response.

The code is modified to update the term-ioi in a call control block from locally configured sipJJ9030InterworkingProfile.

Workaround: No workaround.

96SBX-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.

97SBX-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.
On the KVM, when user hits Enter the system boots up.

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: 

  1. Install the SBC on the SWe.
  2. Wait for the system to boot and the SBC app to be up and running.
  3. Reset the system. (Pull the plug)
  4. Wait for the system to boot.
  5. The system should boot up fine with the SBC app up and running.

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.

98SBX-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.

99SBX-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: 

  1. Create a DNS group , make entries and configure ipAddress, transportProtocol, priority, weight.
  2. Go to unhide debug. Give following commands to make the DNS requests.
    request sbx dns debug command "dig _sip._udp.gateway-us.redmatter.com Google_DNS_Group srv"
    request sbx dns debug command "dig G01-103.redmatter.com Google_DNS_Group a"
    request sbx dns debug command "dig S02-1.redmatter.com Google_DNS_Group a"
    request sbx dns debug command "dig S01-2.redmatter.com Google_DNS_Group a".
  3. Give the following command to display the populated data of DNS Entry Data Status table in the CLI.
    "show table addressContext default dnsGroup <dns_group_name> dnsEntryDataStatus".
  4. Check the DNS Entry Data Status in the EMA, the DNS Entry Data Status table reflects with the data that is there in the CLI.

The code is modified to 1 byte.

Workaround: No workaround.

100SBX-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: 

  1. Configure ingress and egress SIP trunk groups to have variantType q1912.
  2. Make SIP-SIP call. In the initial INVITE, include:
    From: "Anonymous" <SIP URI>
    P-Asserted-Identity: "display name" <SIP URI>
    Privacy: user,id

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.

101SBX-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.
The SMM details are written when STI profile is disabled.

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.
Check for the SMM in CDR.

The code is modified to control SipSgSendAcctUpdateToCc.

Workaround: None.

102SBX-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: 

  1. Set up an SBC 1to1 system.
  2. Failover to the standby.
  3. Take pkt0 out of service.
  4. Run a show table show table system ethernetPort portMonitorStatus.
  5. Ensure that the failure count for pk0 is 1, not 2.

The code is modified to detect and reject duplicate registrations.

Workaround: None.

103SBX-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.

Test scenario:

  1. Bring up a SWe instance with the fixed build.
  2. Create two IP interface groups in two different address contexts with different VLANs but with the same packet port. Which makes two different VLAN interfaces from the same packet port.
  3. Disable one of the IP interface groups and run a ping test (network reachability) from the other VLAN interface.

    Observations: The SBC packet port was reachable in another address context.

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.

NOTE: The customer first needs to upgrade the SBC software with the fix and then upgrade i40en VMWare host driver to version 1.10.9.0 or above along with compatible NIC firmware upgrades.

Workaround: Make IP interfaces OOS/disabled in all address context of the packet port and then enable the required IP interface.

104SBX-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.

set oam traps admin sonusSbxNodeResourcesMaxSysCallLimitSetNotification state enabled
set oam traps admin sonusSbxNodeResourcesMaxSysCallLimitSetNotification priorityLevel default

set oam traps admin sonusSbxNodeResourcesMaxSysCallLimitClearNotification state enabled
set oam traps admin sonusSbxNodeResourcesMaxSysCallLimitClearNotification priorityLevel default

The code is modified to generate traps for Max System Call Limit Set/Clear.

Workaround: None.

105SBX-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.

106SBX-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.

107SBX-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: 

  1. Enable NAPT learning on ingress side.
  2. Run SIP-TLS to SIP-UDP call load, small load should be ok.
  3. Check badRidCb in DBG log.

The code is modified to address the issue.

Workaround: None.

108SBX-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.

109SBX-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.

110SBX-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.
This counter was not reset once we are done fetching all routes, so it was causing issue for subsequent 3xx dips.

Steps to Replicate: 

  1. Configure a routing label for the first number containing more than 10 routes.

  2. Configure another routing label (for 3xx) with a second number containikng more than 10 routes.

  3. Make a call with the first number, and send 3xx with the second number in the contact header.

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.

111SBX-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.
The log rotation criteria has been modified from daily/weekly for the /var/log files to 50M size based and the size of the files are checked hourly.

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.

112SBX-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:

Case Procedure:
1. Configure MRF Routing type as IpAddress in MRF cluster Profile.
2. Initiate a EVS passthrugh call between User A and User B.
3. User A initiates a call with AMR-NB, AMR-WB and EVS codec
m=audio 50012 RTP/AVP 115 104 102 105
Media Attribute (a): rtpmap:115 EVS/16000
Media Attribute (a): fmtp:115 br=5.9-128;bw=nb
Media Attribute (a): rtpmap:102 AMR/8000/1
Media Attribute (a): fmtp:102 mode-set=7
Media Attribute (a): ptime:20
Media Attribute (a): rtpmap:104 AMR-WB/16000/1
Media Attribute (a): fmtp:104 mode-set=2
Media Attribute (a): rtpmap:105 telephone-event/16000
Media Attribute (a): a=fmtp:105 0-15
Media Attribute (a): maxptime:240

4. User B responds with EVS codec.
m=audio 50012 RTP/AVP 115 105
a=rtpmap:115 EVS/16000
a=fmtp:115 br=5.9; bw=nb
a=rtpmap:105 telephone-event/16000
a=fmtp:105 0-15
a=sendrecv
a=ptime:20

5. Call is established as EVS-EVS Passthrough call.
6. Media is exchanged between User A and User B.
7. User A initiates BYE to tear down the call.

The AMRWB-IO mode-set initialization is set correctly

Workaround: Not applicable

113SBX-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:
configure 2 sip sigport with same IP address, different UDP ports in the same LIF group
turn on INFO debug logging
for the first fix:
1. bring down pkt port associated with the LIF group
2. restart application to trigger the configuration restore
3. if on SBC7k, check nspmgr log in NP to make sure not -1 error associated with that IP address. Otherwise, check sip sigPort operational status.
for the second fix
1. find out which sigport is added first, for example, sigport 1
2. OOS and disable sigport 1
3. re-enable and inservice sigport 1
4. check DBG log for below message logged from NrsLAddrAllocate() and make sure laddrHndl !=0. The example message here is without fix.
143 03092022 161237.124306:1.01.00.39320.Minor .NRS: *NrsLAddrAllocate(): 682, refCount 2 found CPS laddrHndl 0 for la 0xc0a87eea lifGroup 3

Two fixes added
1. fix to avoid sending multiple add ACL rule requests to NSP manager before packet port(s) UP.
2. added code to update logical address ID in binding structure when a logical address is being deleted.

Workaround: no workaround


Resolved Issues in 09.02.03R003 Release

The following Severity 1 issues are resolved in this release:

Severity 1 Resolved Issues

Issue IDSevProblem DescriptionResolution
SBX-112374 | SBX-1149451

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: 

  1. In the offer SDP present in ingress Invite, add m=application line along with audio m-line.
  2. At egress, the SBC should do a DNS lookup (the cache should be cleared before so that the SBC queries DNS.)

The code is modified to address the issue.

Workaround: Use an actual IP address in IP peer instead of a FQDN.

SBX-113238 | SBX-1149631

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: 

  1. Run a basic SBC and PSX configuration for a SIP to SIP calls to test the scenario.
  2. On a PSX egress IP signaling profile, the following commands must be enabled:
    Egress IP Attributes->SIP Headers and Parameters->Flags->include CPC information
    Egress IP Attributes->SIP Headers and Parameters->CPC Mapping Flags->Map CPC when Presentation is Restricted
    Egress IP Attributes->SIP Headers and Parameters->CPC Mapping Flags->Send CPC Param In→PAI
    Egress IP Attributes->Flags->Disable 2806 compliance
    Egress IP Attributes->Flags->TTC ISUP Mapping
    Egress IP Attributes->Privacy->Privacy Information->P Assert IdEgress IP Attributes->Privacy->Flags->Include Privacy
  3. On the SBC ingress and egress TGs, enable the cpcInterworkingForNNI, such as:
    set addressContext default zone ZONE2 sipTrunkGroup PCR5001_SBX_EXT signaling cpcInterworkingForNNI enabled
  4. Send basic INVITE from peer A to the SBC ingress TG, in addition to basic headers, the following should be included:
    Privacy: id
    P-Asserted-Identity: "0xxxxxxxxx"<tel:+8xxxxxxxxx;cpc=ordinary>, "Anonymous"<sip:n3xxxxxxxxx@username.xxxx.xx.xx>
  5. Verify that the SBC sends an INVITE to egress. The egress INVITE should include PAI header with cpc=ordinary placed in the URI before the @<ip address>, such as:
    P-Asserted-Identity: "Anonymous" <sip:3xxxxxxxx;cpc=ordinary@10.xx.x.xx:xxxx>, <tel:8xxxxxxxxxx;cpc=ordinary>

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-1149471

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"
NNI-Type [sf:61] <sip:+1xxxxxxxxxx@xxx.xxx.xx.xxx;user=phone>

The code is modified to escape non-alpha numeric characters in the calling name.

Workaround: None.

SBX-113986 | SBX-1149561

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: 

  1. Perform a relay of REFER message enabled in the IP signaling profile.
  2. Run a SIP transparency profile with an "all" entry assigned to the SIP trunk groups.
  3. Make a SIP to SIP call. From the UAS, send REFER to perform blind transfer. The REFER contains Refer-To header with URI User-To-User parameter, e.g.:
    Refer-To: <sip:+1xxxxxxx@john.smith.com?User-to-User=0059a390f3d2b7310023a2%3Bencoding%3Dhex>

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-1145961

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-1151891

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:

  1. Add four IP Peers.
  2. Delete all four IP Peers.
  3. Add the IP Peers back, but in a different zone.

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-1148311

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: 

  1. Establish a call over Gw-Gw with codec negotiated as G711.
  2. Send T38 re-INVITE from UAC to SBC1.
  3. The SBC2 sends out this T38 re-INVITE to UAS.
  4. UAS responds back with 488 Not Acceptable.
  5. The SBC2 sends ACK to UAS.

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-1148421

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:

  1. Create announcementPackage test_pkg_1 with element test_element_1 .
    set profiles media announcementPackage test_pkg_1 packageId 101 element test_element_1 segmentId 11111
  2. Show announcementPackage to verify it is created correctly.
    show profiles media announcementPackage test_pkg_1
    should display
    packageId 101;
    element test_element_1 {
    segmentId 11111;
    }
  3. Delete test_element_1 from the package. 
    delete profiles media announcementPackage test_pkg_1 element test_element_1
  4. Show announcementPackage to verify test_element_1 is removed.
    show profiles media announcementPackage test_pkg_1
    should display (without any elements)
    packageId 101;
  5. Delete the package and verify it is successfully deleted.
    delete profiles media announcementPackage test_pkg_1

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 IDSevProblem DescriptionResolution
SBX-114303 | SBX-1149782

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
sipTrunkGroup IAD signaling callingPalingParty enabled
Incoming msg has:
P-Asserted-Identity: "12345 test user " <tel:+1xxxxxxxxxx;rn=214960>, "12345 test user" <sip:+1xxxxxxxxxx;rn=214960@test.com>

outgoing INVITE
From, contact userpart is 12345

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-1151202

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)

  1. Ingress DSP reason.
  2. Egress DSP reason.

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: 

  1. Run 20k A---B Transcoded call with ingress DSP reason as DTMF.
  2. Change the configuration to pass-through.
  3. Check the logs to see Ingress DSP reason is populated as "No DSP inserted" for a pass-through call.

The code is modified so that the value is not populated to the fields.

Workaround: None.

SBX-114020 | SBX-1151212

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. 

Resolved Issues in 09.02.03R002 Release

The following Severity 1 issues are resolved in this release:

Severity 1 Resolved Issues

Issue IDSevProblem DescriptionResolution
SBX-113305 | SBX-1144251

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: 

  1. Configure DNS server with a DSCP value.
  2. Ensure the DNS server blacklisting is enabled.
  3. Ensure the DNS query is configured DNS server.
  4. Shut down the DNS server during this process.

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-1143201

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-1145681

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: 

  1. With DLRBT configured on ingress and egress of SBC. Establish an A-to-B call through the SBC.
  2. Send a REFER from B to refer the call to C and complete the refer related signaling. This results in an A-to-C call.
  3. Send a REFER from C to refer the call to D. Do not answer the call at D but reject it with a 480 "Temporarily not available" message.
  4. Verify that the SBC stops playing tone towards A and re-establishes the A-to-C call again and media can correctly flow between A and C.

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-1144271

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 IDSevProblem DescriptionResolution
SBX-112547 | SBX-1144052

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: 

  1. Configure the DNS server with two routes for the FQDN route.
  2. Make an A-to-B call.
  3. The SBC sends an INVITE to first DNS record of and B sends 18x and the 503.

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:
--> INVITE (with SDP and P-Early-Media: supported)
<-- 100 Trying
<-- 183 Session Progress (with SDP and no P-Early-Media)
--> PRACK
<-- 200 OK (for PRACK)
--> UPDATE (with SDP)
<-- 200 OK (for UPDATE with SDP)
<-- 183 Session Progress (no SDP but P-Early-Media: sendrecv)
--> PRACK
<-- 200 OK (for PRACK)
<-- 200 OK (for INVITE) (This message gets queued forever).

The code is modified to eliminate the race condition.

Workaround: None.

SBX-113614 | SBX-1145463

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-1145284

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.

Resolved Issues in 09.02.03R001 Release

The following Severity 1 issues are resolved in this release:

Severity 1 Resolved Issues

Issue IDSevProblem DescriptionResolution
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-1138531

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: 

  1. Configure the stiProfile, enable, and assign to ingress trunk group.
  2. Send an SIP INVITE containing six Diversion headers but only two of them are unique. In other words, send in two Diversion headers repeated three times.

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 IDSevProblem DescriptionResolution
SBX-1140192

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.
set addressContext default zone <zone name> sipTrunkGroup <TG name> signaling doNotAutoAnswer <enable/disable>.

The code is modified to only print the logs at an INFO level.

Workaround: None.

Resolved Issues in 09.02.03R000 Release

The following Severity 1 issues are resolved in this release:

Severity 1 Resolved Issues

Issue IDSevProblem DescriptionResolution
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: 

  1. Configure an IKE Protection Profile without any algorithms.
  2. Run a call that will use this profile.

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:

  1. Ingress sends LM Invite.
  2. Egress sends 18x with SDP.
  3. Ingress sends SDP in Prack.
  4. Once call is established, send LM re-Invite request from Egress.
  5. Ingress responds with 200 Ok and receives ACK with SDP.
  6. Ingress sends LM re-Invite request towards egress.

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: 

  1. Bring up an MSBC 4-1 cluster.
  2. Restart the standby instance.
  3. Immediately after the standby instance is fully up, restart one of the active instances.
  4. After the standby instance is fully up as the active instance, in the CLI run the following command:

unhide debug
show table global icmpGeneralGroupCurrentStatistics

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: 

  1. Enable the SIP Rec.
  2. Make a blind/attended call transfer and after successful transfer, perform a call hold and unhold.

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: 

  1. Create the SMM Profile using the following command strings:

    set profiles signaling sipAdaptorProfile ESMM state disabled
    set profiles signaling sipAdaptorProfile ESMM advancedSMM disabled
    set profiles signaling sipAdaptorProfile ESMM profileType messageManipulation
    set profiles signaling sipAdaptorProfile ESMM rule 1 applyMatchHeader one
    set profiles signaling sipAdaptorProfile ESMM rule 1 criterion 1 type message
    set profiles signaling sipAdaptorProfile ESMM rule 1 criterion 1 message
    set profiles signaling sipAdaptorProfile ESMM rule 1 criterion 1 message messageTypes requestAll
    set profiles signaling sipAdaptorProfile ESMM rule 1 criterion 2 type header
    set profiles signaling sipAdaptorProfile ESMM rule 1 criterion 2 header
    set profiles signaling sipAdaptorProfile ESMM rule 1 criterion 2 header name WWW-Authenticate
    set profiles signaling sipAdaptorProfile ESMM rule 1 criterion 2 header condition exist
    set profiles signaling sipAdaptorProfile ESMM rule 1 criterion 2 header numberOfInstances number 1
    set profiles signaling sipAdaptorProfile ESMM rule 1 criterion 2 header numberOfInstances qualifier equal
    set profiles signaling sipAdaptorProfile ESMM rule 1 criterion 3 type parameter
    set profiles signaling sipAdaptorProfile ESMM rule 1 criterion 3 parameter
    set profiles signaling sipAdaptorProfile ESMM rule 1 criterion 3 parameter condition exist
    set profiles signaling sipAdaptorProfile ESMM rule 1 criterion 3 parameter paramType generic
    set profiles signaling sipAdaptorProfile ESMM rule 1 criterion 3 parameter name realm
    set profiles signaling sipAdaptorProfile ESMM rule 1 action 1 type header
    set profiles signaling sipAdaptorProfile ESMM rule 1 action 1 operation regsub
    set profiles signaling sipAdaptorProfile ESMM rule 1 action 1 headerInfo headerValue
    set profiles signaling sipAdaptorProfile ESMM rule 1 action 1 from
    set profiles signaling sipAdaptorProfile ESMM rule 1 action 1 from type value
    set profiles signaling sipAdaptorProfile ESMM rule 1 action 1 from value 172.xx.xx.xxx
    set profiles signaling sipAdaptorProfile ESMM rule 1 action 1 to
    set profiles signaling sipAdaptorProfile ESMM rule 1 action 1 to type header
    set profiles signaling sipAdaptorProfile ESMM rule 1 action 1 to value WWW-Authenticate
    set profiles signaling sipAdaptorProfile ESMM rule 1 action 1 regexp
    set profiles signaling sipAdaptorProfile ESMM rule 1 action 1 regexp string "
    "
    set profiles signaling sipAdaptorProfile ESMM rule 1 action 1 regexp matchInstance all
    commit
  2. Run the following CLI command to export the configuration:
    user-config-export test.xml /profiles/signaling/sipAdaptorProfile
  3. Delete the exported profile from the CLI with the following command:
    delete profiles signaling sipAdaptorProfile ESMM
    commit
    user-config-import test.xml
  4. Run the following command:
    show configuration profiles signaling sipAdaptorProfile | display set | match string
  5. Check if the Regex string field, and restore the original value.

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: 

  1. Enable the sendSbcSupportedCodecsInLateMediaReinvite on the TG towards UAC.
  2. Send a direction attribute a=sendonly/recvonly/inactive from the UAS.
  3. Send the 200 OK to UAC should have direction attribute as expected (a=sendonly/recvonly/inactive respectively) and media is as per expectation.
    UAC---------------------------------SBC------------------------------------------------UAS
    INV(no sdp)->
    INV(a=sendrecv)->
    <-200 OK(a=sendonly/recvonly/inactive)
    <-200 OK(a=sendonly/recvonly/inactive)
    ACK(sdp)->
    ACK(no sdp)->

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: 

  1. Ensure the end-to-end PRACK is supported.
  2. Make a SIP-SIP call that routes and 18x is received on the first route. As a result, the PRACK procedure is successful.
  3. Have the call fail on the first route, e.g. with 404, and the SBC configured to crank-back to a second route.

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: 

  1. Configure the SBC with SIP Rec server.
  2. Run a basic call with "tel" URI in From and To header.

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: 

  1. Have a HA setup.
  2. In IPSP, enable "Minimize relay of media changes from other call leg" flag and "lockdown preferred codec" is enabled.
  3. Establish a call with dynamic codec like AMR.
  4. Perform a switchover, once standby becomes active send a call hold request.
  5. After a short period of time, send an call-un-hold request.

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: 

  1. Set up a SIP-SBC-SIP.
  2. Enable trace logging with level4 and key "peerIpAddress"
  3. Run a SIP-SIP call, send INVITE with malformed syntax to pkt1 SIP signaling IP address such that the SBC sends a 400 Bad Request.
  4. Verify that in the TRC log, for 400 Bad request PDU, the local IP value is pkt 1 SIP signaling IP address, same source IP where the INVITE message lands.

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

  1. Make a G711-G711 GW-GW call.
    The SBC will send BYE to peers. The call will fail.
    Test Case 2: Non GW-GW Scenario
  2. Configure below PSPs on ingress and Egress legs
    Ingress PSP:
    G729, G711U, G711A
    This Leg – G711U, G711A, EFR, EVRC,
    Other Leg – G711U, G711A,
    Enable Transcode if different pktsize, dtmf, silence suppression and honor preference.

    Egress PSP:
    G711SS
    This Leg – G711U, G711A,
    Other Leg – G711U, G711A,
    Enable Transcode if different pktsize, silence suppression
  3. Make a G711-G711 call.

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: 

  1. Configure ARS Retry-After profile.
  2. Enable callRouting useRouteSet received in ingress and egress trunk groups.
  3. Use the UAC to send an INVITE containing Route without port number:
    Route: <sip:172.xx.xxx.xx;lr;dtg=SBX_EXAMPLE>

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-1077531

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: 

  1. Perform an upgrade (LSWU/standalone).
  2. If upgrade has failed, verify that the apache has come up properly with default keys and cert.
  3. If upgrade has succeeded, verify that first Apache came up properly with default keys, then after app start, the installed keys and certs are being used by the Apache.

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-1124471

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
185 08192021 154751.375973:1.02.00.26913.Minor .SIPSG: SIPRec Recording failed for EGRESS call with GCID 291518377 for Recorder 10.xx.xxx.xx:xxxx. Trunkgroup of Recorder: NICE_PRI_TG

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.

  1. Main Call (CS) session established.
  2. SIPREC session (RS) is established.
  3. CS call goes for modification with re-INVITE (Hold/Codec change).
    A SIPREC re-INVITE is triggered (based on CS re-INVITE).
  4. The SRS does not respond for SIPREC re-INVITE.
  5. Before the SRS answers the re-INVITE, a CS call triggers yet another modification with re-INVITE (unhold/codec change).
  6. The SBC attempts to trigger SIPREC RE-INVITE again even when the previous transaction is pending and results in SRS session failure.

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-1131961

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: 

  1. Pass in the trunk group and trunk context parameters that use FQDN information.
  2. Ensure the PSX returns 3 routes and no IP Peer IP or FQDN information.
  3. Return a crankback status code in response to the INVITEs sent on route 1 and route 2.
  4. Release the call.

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 IDSevProblem DescriptionResolution
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: 

  1. Send an INVITE from A to B. The SBC sends sendrev to egress.
  2. From B, send a 180 with recvonly.
  3. From B, send a 200 Ok with recvonly.

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.

admin@vsbxsus2> request global callTrace action command start

Sonus Networks, Inc.0000000001600000000000000000000128V08.02.06A002 0000000000000000000000000000TRC2021082014593700000000000000
072 08202021 145941.298910:1.01.00.00002.Info .NRM: Call Trace Reset

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: 

  1. Configure preconditions to transparent on both legs.
  2. Configure transmitpreconditions to supported on both legs.
  3. Run the script so that there is difference in precondition parameters in an INVITE and UPDATE messages from ingress.

    invite: a=des:qos mandatory local sendrecv
    a=curr:qos local none
    a=des:qos optional remote sendrecv
    a=curr:qos remote none

    (AS script)183 in Progress: a=curr:qos local sendrecv
    a=curr:qos remote none
    a=des:qos optional local sendrecv
    a=des:qos mandatory remote sendrecv
    a=conf:qos local sendrecv

    (IAD script)update : a=curr:qos local sendrecv
    a=curr:qos remote sendrecv
    a=des:qos mandatory local sendrecv
    a=des:qos optional remote sendrecv
  4. Send the update from the Ingress when the SBC is waiting for 200 of the previous update it sent to egress.

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: 

  1. Configure the ARS profile.
  2. Make a DNS server query with invalid format.
  3. Verify the alarm to check that the server is on a block list.
  4. Check after sending an ICMP message,the  server is on a permit list.

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: 

  1. Bring up the SLB-ISBC setup.
  2. Run a call load.
  3. Check in the SLB about current utilization of the I-SBC.

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: 

  1. A and B call is connected.
  2. B sends a REFER to the SBC.
  3. The SBC sends a new INV to transfer target C.
  4. C sends 180 Ringing to the SBC.
  5. A sends BYE to the SBC before C answers the call.

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: 

  1. Configure the SIPREC set up and Min-SE and Session-Expires in sipRecMetadataProfile.
  2. Receive an incoming INVITE without the support timer and no Min-SE, no Session-Expires.

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.
This resulted in an incorrect TAP ID being sent out for one of the intercepted leg in the Correlation-ID (CCID) and in the TAP ID AVP field (202) of the X2 messages.

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: 

  1. Configure the SBC with the PSX and EMS for IMSLI Lawful interception.
  2. Configure the IMSLI for both Leg and set targets using EMS with different TAP ID.
  3. Make a subscribe request with the same targets configured.
  4. Verify that TAP ID received for both legs are correct.

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: 

  1. Send an IMS-AKA registration request from a UE device.
  2. Ensure the IMS-AKA registration is successful.
  3. Let the registered user receive call from IMS network.
  4. When UE accepts the call, we can observe in the call progress response sent from the SBC towards the IMS Core will have the invalid port in contact/Record-Route headers.

    Flow: IMS Core --(SIP UDP)-> SBC ---(SIP IPSec TCP)--> Peer (UE)

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:

Case 1: Create ipInterfaceGroup,ipInterface and assign ipVarV4
Create 2nd ipInterfaceGroup,ipInterface and assign same ipVarV4 value, confd should throw an error for unique value in a address context.

Case 2: Create ipInterfaceGroup,ipInterface assign ipVarV4 and altIpVars same as the one in ipVarV4
should throw an error for unique value.

Case 3: Create ipInterfaceGroup,ipInterface assign ipVarV4 and altIpVars
Create 2nd ipInterfaceGroup,ipInterface assign ipVarV4 and same altIpVars value as previous
confd should throw error for unique value.

Case 4: Create ipInterfaceGroup,ipInterface assign ipVarV4 and altIpVars
Delete ipInterfaceGroup,ipInterface ipVarV4
Delete ipInterfaceGroup,ipInterface altIpVars
Delete ipInterfaceGroup,ipInterface
All combination of delete should work

Case 5: The same test to be done for ipVarV6.

Any other tests are related to ipVarV4/ipVarV6/altIpVars creation/deletion

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:


Case 1: Create ipInterfaceGroup,ipInterface and assign ipVarV4
Create 2nd ipInterfaceGroup,ipInterface and assign same ipVarV4 value, confd should throw an error for unique value in a address context.

Case 2: Create ipInterfaceGroup,ipInterface assign ipVarV4 and altIpVars same as the one in ipVarV4
should throw an error for unique value.

Case 3: Create ipInterfaceGroup,ipInterface assign ipVarV4 and altIpVars
Create 2nd ipInterfaceGroup,ipInterface assign ipVarV4 and same altIpVars value as previous
confd should through error for unique value.

Case 4: Create ipInterfaceGroup,ipInterface assign ipVarV4 and altIpVars
Delete ipInterfaceGroup,ipInterface ipVarV4
Delete ipInterfaceGroup,ipInterface altIpVars
Delete ipInterfaceGroup,ipInterface
All combination of delete should work

Case 5: The same test to be done for ipVarV6.
Once saveAndActivate is called data should reflect in SBC as well.

Case 6: Upgrade testing to be performed like from 9.x to 10.x.
case 7: error case for upgrade testing, configure ipVarV4/ipVarV6/altIpVars and use same values for different ipInterface within an address context and post upgrade should get an error log for contacting sonus customer service to make the values unique.

Run any tests related to ipVarV4/ipVarV6/altIpVars creation/deletion

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:

  • Main Call (CS) session established.
  • SIPREC INVITE (RS) is sent towards SRS.
  • SRS does not respond for SIPREC INVITE. (SBC - SRS INVITE transaction is pending).
  • CS call goes for modification with RE-INVITE. (Hold/Codec change).
  • SRS answers the initial SIPREC INVITE after Main CS Call RE-INVITE.

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: 

  1. Log into EMS.
  2. Launch the SBC Node.
  3. Click on Monitoring -> System and Software info tab.

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.
When the destination GW is an older GSX, the PDU may be larger than the buffer allocated on the GSX for receiving this PDU.

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.

To test the fix:

  1. Load the new code.
  2. Enable oldGsxSupport
    "set global signaling oldGsxSupport"
  3. Send an SBC-GW-GW-GSX call involving text (T140) streams (this is just 1 way to cause the large PDU to be sent).

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:

  1. Enable the call Notification feature both legs.
  2. Send different PAI headers in the 18x and 200 OK.

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: 

  1. Run a basic Basic transcoded HOLD/RESUME SRTP call with the flag enabled.
  2. Ensure that during a HOLD, only data-path-mode is changed to sendonly and recvonly respectively to trigger modify scenario and rest of the media attributes remains same.
  3. Validate the media packets for change in the SSRC.

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: 

  1. Login to EMA as an admin user.
  2. Go to Configuration->Configuration Wizards->Visual First Call Setup.
  3. Configure the fields in Carrier and save.
  4. Make changes to IP Interface Group and Save.
  5. Navigate to AllAdmin and then navigate back to Configuration->Configuration Wizards->Visual First Call Setup

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: 

  1. Run a EVS<=>AMRWB call.
    br=5.9-24.4; bw=nb-wb
  2. Stream a WB pcap with 13.2Kbps packets with CMR byte for 13.2 CA mode for the first 10s. After, the pcap has 24.4 Kbps packets without the CMR.

Results:
The mode of operation changes from 24.4Kbps to 13.2 Kbps with CA enabled on receiving the CMR. Once the Endpoint starts sending 24.4 Kbps packets without CMR, the SBC switches to Compact Mode while maintaining its bitrate as 13.2 Kbps with CA enabled.

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:

  • sudo systemctl status apt-daily.timer
  • sudo systemctl status apt-daily-upgrade.timer

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:

  • sudo systemctl stop apt-daily.service
  • sudo systemctl stop apt-daily.timer
  • sudo systemctl stop apt-daily-upgrade.timer
  • sudo systemctl stop apt-daily-upgrade.service
  • sudo systemctl disable apt-daily.service
  • sudo systemctl disable apt-daily.timer
  • sudo systemctl disable apt-daily-upgrade.timer
  • sudo systemctl disable apt-daily-upgrade.service
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: 

  1. Run an A(SRTP)-B(RTP) CALL.
  2. Run a leg A is G711 fax and B is T38. B sends a re-INVITE with t38 fax.
  3. Check the re-INVITE that goes out with SRTP to endpoint A.
  4. A party sends 200 ok with SRTP.
  5. End the call.

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.
This issue was introduced a previous fix listed in the 9.2.1 release.

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 called side does not sent any 18x response.

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
[disabled,enabled] (disabled): enabled
[ok][2021-08-19 17:12:13]

[edit]
admin@sbxsus12% com
Commit complete.


admin@sbxsus12% set oam eventLog typeAdmin debug filterLevel info
[ok][2021-08-19 17:14:51]

[edit]
admin@sbxsus12% com
The following warnings were generated:
'oam eventLog typeAdmin': Enabling INFO level logging can be service impacting. Do you want to continue?
Proceed? [yes,no] no
Aborted: by user
[ok][2021-08-19 17:15:41]

[edit]
admin@sbxsus12% com
The following warnings were generated:
'oam eventLog typeAdmin': Enabling INFO level logging can be service impacting. Do you want to continue?
Proceed? [yes,no] yes
Commit complete.
[ok][2021-08-19 17:15:46]

admin@sbxsus12% set oam eventLog typeAdmin system filterLevel info
[ok][2021-08-19 17:16:37]

[edit]
admin@sbxsus12% com
The following warnings were generated:
'oam eventLog typeAdmin': Enabling INFO level logging can be service impacting. Do you want to continue?
Proceed? [yes,no] yes
Commit complete.
[ok][2021-08-19 17:16:40]

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.
SIP_CALL_STR *pstCall is set as NULL when SipsTXNDownstreamMsgToFsm is called. Due to the NULL check of pstCall in later functions, the SipSgTraceDumpSipPdu() is not called to log ACK PDU in TRC log.

Steps to Replicate: 

  1. Set up: SIP-SBX-SIP.
  2. Create a dnsgroup and configure the external DNS IP Address. Attach dnsgroup with egress zone.
  3. Create a global calltrace filter with "level1" and key "calling".
  4. Start the global calltrace and roll trace log event.
  5. Run SIP-SIP call. 200 OK for the INVITE received on the egress call leg contains Record-Route with an FQDN.
  6. Verify that egress ACK PDU is logged in TRC log.

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:

  1. port range id not found from SipFePortRangeCnxSendDataReq()
    e.g. SipFePortRangeCnxSendDataReq 366] PORT_RANGE: id not found 412765
  2. port range id not found from SipFeRedundMirrorHashSync()
    e.g. SipFeRedundMirrorHashSync 1372] PORT_RANGE: failed to find Connection id in HAsh[4194719]

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:

  1. Add a profile with a future time value on the delayed sync leaf. Export the configuration.
  2. Clear the db.
  3. Import the configuration when the system time is greater than the configured delayed sync time.
  4. Import would fail without this fix.

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.

1. Create An AD Attribute Profile.
set profiles adAttributeMapProfile DEFAULT_AD_ATTRIBUTE_PROFILE adAttributeList adAttribute1 adAttributeName cn
set profiles adAttributeMapProfile DEFAULT_AD_ATTRIBUTE_PROFILE adAttributeList adAttribute2 adAttributeName displayName
commit

2. Create a domain controller profile
set global servers domainController dc0 userName DcUsername password DcPassword primaryAddress DcIpAddress searchScope base=engineering,dc=some,dc=com ldapQueryCriteria cn=*
commit

3. Create an AD profile:

set profiles adProfile DEFAULT_AD_PROFILE delayedSync 2021-09-29T14:00:00 syncInterval 1440 sync enable adServerList 1 dcServer dc0
commit

After 1-2 minutes of creating the AD profile, delete it.

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: 

  1. Create a GW-GW set up.
  2. From UAS send 183 with a=sendonly along with image and text lines with sendrecv.
  3. SBC sends 183 with audio line as a=sendonly (That is removed by the SMM).
  4. Send a 180 from the UAS that the SBC sends to UAC.
  5. Send a 200 from UAS without the sdp.
  6. The SBC sends a re-INVITE to ingress with audio m line sendonly along with image and text port as 0 (SMM changes the audio line to sendrecv).
  7. The SBC gets 200 for re-INVITE from UAC with audio line sendrecv.

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: 

  1. Run a test case with multiple trunk groups.
  2. Send in a subscribe message that is routed through the SBC and respond back with 500.

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-1137662

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-909892

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.

Resolved Issues in 09.02.02R004 Release

The following Severity 1 issues are resolved in this release:

Severity 1 Resolved Issues

Issue IDSevProblem DescriptionResolution
SBX-107747 | SBX-1126481

PortFix SBX-107747: During Cyclic switchover tests, a PRS Process coredump was observed on the MSBC1.

Impact: The application on both active and standby switched over and application reset in short order of each other. Core files were created on both sides of the HA pair.

Root Cause: The issue occurs during multiparty call processing, when the SBC tries to determine whether a message was destined for an ingress or egress call segment. As a result of running multiparty call processing, the code was accessing the pointer to the multi party call resource after it was freed up and set to NULL.

Steps to Replicate: This issue is not reproducible. Potentially due to a race condition in the code.

Check the multi party call pointer is not NULL before reading from it to avoid the coredump.

Workaround: There is no known workaround for this issue.

SBX-112561 | SBX-1128361

PortFix SBX-112561: The regexp string "\r\n" was not exported by “user-config-export”.

Impact: The \r\n in regex is lost while exporting a configuration using the user-config-export CLI command.

Root Cause: XML formatting trims empty node values.

Steps to Replicate:

  1. Create an SMM Profile using the following commands:
    set profiles signaling sipAdaptorProfile ESMM state disabled
    set profiles signaling sipAdaptorProfile ESMM advancedSMM disabled
    set profiles signaling sipAdaptorProfile ESMM profileType messageManipulation
    set profiles signaling sipAdaptorProfile ESMM rule 1 applyMatchHeader one
    set profiles signaling sipAdaptorProfile ESMM rule 1 criterion 1 type message
    set profiles signaling sipAdaptorProfile ESMM rule 1 criterion 1 message
    set profiles signaling sipAdaptorProfile ESMM rule 1 criterion 1 message messageTypes requestAll
    set profiles signaling sipAdaptorProfile ESMM rule 1 criterion 2 type header
    set profiles signaling sipAdaptorProfile ESMM rule 1 criterion 2 header
    set profiles signaling sipAdaptorProfile ESMM rule 1 criterion 2 header name WWW-Authenticate
    set profiles signaling sipAdaptorProfile ESMM rule 1 criterion 2 header condition exist
    set profiles signaling sipAdaptorProfile ESMM rule 1 criterion 2 header numberOfInstances number 1
    set profiles signaling sipAdaptorProfile ESMM rule 1 criterion 2 header numberOfInstances qualifier equal
    set profiles signaling sipAdaptorProfile ESMM rule 1 criterion 3 type parameter
    set profiles signaling sipAdaptorProfile ESMM rule 1 criterion 3 parameter
    set profiles signaling sipAdaptorProfile ESMM rule 1 criterion 3 parameter condition exist
    set profiles signaling sipAdaptorProfile ESMM rule 1 criterion 3 parameter paramType generic
    set profiles signaling sipAdaptorProfile ESMM rule 1 criterion 3 parameter name realm
    set profiles signaling sipAdaptorProfile ESMM rule 1 action 1 type header
    set profiles signaling sipAdaptorProfile ESMM rule 1 action 1 operation regsub
    set profiles signaling sipAdaptorProfile ESMM rule 1 action 1 headerInfo headerValue
    set profiles signaling sipAdaptorProfile ESMM rule 1 action 1 from
    set profiles signaling sipAdaptorProfile ESMM rule 1 action 1 from type value
    set profiles signaling sipAdaptorProfile ESMM rule 1 action 1 from value 172.12.34.567
    set profiles signaling sipAdaptorProfile ESMM rule 1 action 1 to
    set profiles signaling sipAdaptorProfile ESMM rule 1 action 1 to type header
    set profiles signaling sipAdaptorProfile ESMM rule 1 action 1 to value WWW-Authenticate
    set profiles signaling sipAdaptorProfile ESMM rule 1 action 1 regexp
    set profiles signaling sipAdaptorProfile ESMM rule 1 action 1 regexp string "\r\n"
    set profiles signaling sipAdaptorProfile ESMM rule 1 action 1 regexp matchInstance all
    commit
  2. Run the CLI command to the export configuration:
    user-config-export test.xml /profiles/signaling/sipAdaptorProfile
  3. Delete the exported profile from CLI with the command:
    delete profiles signaling sipAdaptorProfile ESMM
    commit
    user-config-import test.xml
  4. Run the following command:
    show configuration profiles signaling sipAdaptorProfile | display set | match string
  5. Check if the regex string field, restores the original value.

Use the external XML tool called xmllint. 

Workaround: Manually edit the field in xml file after export.

SBX-1127661

Details on "LAST RESTART REASON" under command "show table system serverStatus" are incorrect.

Impact: The LAST RESTART REASON is not updated with a correct reason of last restart.

Root Cause: Reading LAST TESTART REASON function is called twice and in second call, it is set to default.

Steps to Replicate: Check the LAST RESTART REASON from CLI show table system serverStatus
and call a different type of restart and verify LAST RESTART REASON set properly or not.

The code is modified to set the reading LAST TESTART REASON function to call only once.

Workaround: None.

The following Severity 2-4 issues are resolved in this release:

Severity 2-4 Resolved Issues

Issue IDSevProblem DescriptionResolution
SBX-111349 | SBX-1128832

PortFix SBX-111349: The SBC 7000 has a dual crash within 1 minute (old Active side - Fm, new Active - Scm).

Impact: The application on both active and standby are switched over and application reset in short order of each other. Core files are created on both sides of the HA pair.

Root Cause: Accessing a NULL pointer that leads to a coredump.

Steps to Replicate: Test switchover scenarios to replicate the issue.

The code is modified to address the issue. 
The ccbPtr->ccMultiCallMsgStrPtr is checked for not being NULL.

Workaround: None.

SBX-1128573

The VNFM response is timing out due to the timeout value length.

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 lead 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 5-second delay was originally considered adequate, but after taking multiple networks into account, the delay proved to be 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 increased to 20 seconds.

Workaround: None.

SBX-112493 | SBX-1127852

PortFix SBX-112493: The SBC is not decrypting IPsec packet when large PDU sent over IPv6 from Strongswan.

Impact: The SBC is not decrypting IPsec packet when large PDU sent from Strongswan IPsec endpoint.

Root Cause: The SBC SWe NP has an issue in the last fragment data length processing. This StrongSwan was fragmented first and encrypted the next combination IPsec packets handling, which caused ESP trailer offset being wrong and call failures.

Steps to Replicate: Make large SIP PDU calls with the StrongSwan IPSec endpoint.

The code is modified on the last segment length to work for all combinations.

Workaround: The customer and the SBC IPsec endpoints can be used if possible.

SBX-112153 | SBX-1126274

PortFix SBX-112153: An investigation found commits are not saved/activated on many SBCs.

Impact: Warnings displayed about inactive configurations on the managed VM.

Root Cause: The managed VM was checking the status on the OAM shared drive and reporting the inactive configuration warnings.

Steps to Replicate: Test on OAM and manage the VM.

The code is modified to only display the warning on OAM nodes.

Workaround: None.

SBX-1121172

There is a Wall LRA ISBC switchover after the applying ACLs.

Impact: Configuring certain combination of ACLs may exceed the hugepage requirement than available in the system. This will cause the ACL configuration to fail and SWe_NP to exit.

Root Cause: The code did not account for available hugepages during an ACL configuration.

Steps to Replicate: Bring up setup in ISBC profile. Apply the ACL configuration used by customer.

The code is modified to limit the hugepage memory use during an ACL build and ensure it is within the allocated limit.

Workaround: Use more than 64G RAM.

Resolved Issues in 09.02.02R003 Release

The following issue is resolved in this release:

Resolved Issues

Issue IDSevProblem DescriptionResolution
SBX-1053701

The Active Register per TG shows more than the total stable registration.

Impact: Under some condition(s), the ingress zone’s activeRegs count can be incremented and not decremented when the registration terminates.

The causes the ingress zone’s activeRegs count to grow incorrectly, and never reach ZERO (even after all registrations are terminated).

Root Cause: The SIPFE and SIPSG RCB allocation/deallocation become out of sync, indirectly causing the ingress zone's activeRegs count to increment and not decrement.

Steps to Replicate: Perform REGISTER/401 - REGISTER/403 until the ingress zone activeRegs count issue is detected.

The code is modified to correctly handle the SIPFE's registration bind timer expiration. 

Workaround: None.

Resolved Issues in 09.02.02R002 Release

The following Severity 1 issues are resolved in this release:

Severity 1 Resolved Issues

Issue IDSevProblem DescriptionResolution
SBX-111688 | SBX-1121261

PortFix SBX-111688: The Request-URI and TO fields in a SIP INVITE are incorrect and overwritten.

Impact: When the Diversion header presented in an Ingress INVITE and had no RN in Request-URI, the egress RURI would use the RN in username field, after a PSX LNP dip.

Root Cause: The fix for a previous issue broke the previous RURI username setting.

Steps to Replicate: 

  1. Set up the SBC with an external PSX to make LNP calls.
  2. Pay attention to the disableRn flag in egress IPSP in PSX and flag UseGAPwhenRnisDisabled in the SBC's egress TG. Test different combination of < disableRn, UseGAPwhenRnisDisabled >
  3. Ingress INVITE needs to contain Diversion header and no RN in the Request-URI.

Sample message could be found in the reproduced DBG logs and finalFix DBG logs.

The code is modified to ensure the RURI always contains the correct username.

Note: When the egress IPSP has "SIP TO Header Mapping" set to "Called Number", the TO header's username is the ingress TO URI. The number will not be globalized. If the customer would like it to be globalized, the globalization profile of the egress TG could be modified to globalize TO URI. Another way is using SMM to modify it.

Workaround: Use the SMM and use the Warning-21-00029918

SBX-111223 | SBX-1121941

Portfix SBX-111223: Memory leak since upgrading to 8.2.5R0.

Impact: High memory utilization.

Root Cause: Two leaks of the same structure exist:

  1. A memory leak is seen when a relayed SUSCRIBE message is cranked back and an Alternate Server cannot be found.
  2. The code that handles relayed messages may cause a leak in certain error scenarios.

Warning-21-00029922 pertains to this issue.

Steps to Replicate: This is a memory leak that may be triggered if a relayed SUBSCRIBE is cranked back and then an alternate route is not found.

  1. This memory leak that may get triggered if a relayed SUBSCRIBE is cranked back and then an Alternate Server is not found.
  2. We were unable to reproduce this error scenario which causes a leak of the Relay Control Block.
  1. The code is modified to take the correct path when an Alternate Server cannot be found while handling a relayed message that has been cranked back.
  2. Code has been added to start a timer when we begin processing a relayed messsage. In error cases, the Relay Control Block will be free when the timer expires - preventing the structure from leaking.

Workaround: None.

Once the memory utilization reaches 91%, an automatic switchover occurs. To avoid an automatic switchover, Ribbon recommends performing a manual switchover during a low traffic period. 

SBX-1123091

An LSWU on SWe (VMware/KVM) through the Platform Manager fails with the additional reboot of the standby.

Impact: An LSWU from 09.02.02R001 to any higher release 1:1 HA SWe (KVM/VMware) through the Platform manager fails because the standby instance undergoes an additional reboot during the upgrade procedure.

Root Cause: The Index Marker file was missing on the standby instance prior to the LSWU procedure.

The Index Marker file was missing on the standby instance due to when the application comes up with the standby role, the Index Marker is created only when there is a mismatch in the calculated and DB populated indices.

Steps to Replicate: 

  1. Create 1:1 HA SWe on KVM/VMware.
  2. After the HA application comes in sync, run clearDB on the standby.
  3. Perform an LSWU on the 1:1 HA SWe.

The code is modified so the Index Marker file is created on the standby instance irrespective of processor index mismatch in the calculated and DB populated indices.

WorkaroundBefore initiating the upgrade procedure (from PM or CLI), the user needs to run the following command as a root user from the linux shell of the active and standby instance.

touch /opt/sonus/conf/swe/capacityEstimates/.indexMarker

SBX-1122291

The term-ioi is not be set in the STOP record for a customer call flow.

Impact: When running a JJ90.30 to JJ90.30 call flow, the term-ioi value from the PCV header is not being stored in the ingress protocol variant string when the transitPCV control in the JJ90.30 interworking profile is enabled.

Root Cause: The original development work was only storing the term-ioi value in the egress protocol variant string.

Steps to Replicate: 

Make JJ90.30 to JJ90.30 call.
transitPcv is set to enabled in the customer's Interworking Profile.

Call 1:

INVITE --> (PCV with icid-value and orig-ioi)
<--- 180 (PCV with icid-value, orig-ioi, term-ioi)
<-- 200 OK (PCV with icid-value, orig-ioi, term-ioi)
--> BYE

Call 2:

INVITE --> (PCV with icid-value and orig-ioi)
<--- 180 (PCV with icid-value, orig-ioi, term-ioi)
<-- 200 OK (PCV with icid-value, orig-ioi, term-ioi)
<-- BYE

After a call, verify the CDR records. In both START and STOP records, the term-ioi is filled in ingress PVSD.

The code is modified to ensure the term-ioi value is stored in the ingress protocol variant string.

Workaround: None.

SBX-112381 | SBX-11244881

PortFix SBX-112381: The SBC had a Crash-Application in the rebooting loop.

Impact: A PRS Process core is occurring when the code is processing an ICE STUN packet and there are more than 20 Teams clients ringing. This could potentially happen in a simultaneous call group pickup scenario.

Root Cause: The root cause of the core is a bug in the code that handles the incoming STUN packet. This code is overwriting the end of array by writing too many entries into the array. This results in memory corruption and eventually a core.

Steps to Replicate: Run a call group pickup scenario with more than 20 users all having their Teams clients ringing at the same time.

The code is modified to prevent it from writing too many entries into the array.

Workaround: Disable media-bypass or reduce the number of users in the call group.

The following Severity 2-3 issues are resolved in this release:

Severity 2-3 Issues

Issue IDSevProblem DescriptionResolution
SBX-1117512

The SCM Process is coredumping.

Impact: The SBC is relaying multiple reason header instances in the amount of the quantity squared.

Root Cause: Logical error when multiple instances of a reason header on the same line. The SBC is relaying in the amount of quantity squared. 

Steps to Replicate: 

  1. Configure the transparency Reason header.
  2. Make a SIP-SIP call, Ingress sends BYE with multiples Reason header instances on the same line. The SBC sends instances in an amount of the quantity squared to the Reason header on Egress.

Note: If the ingress sends a large number of instances on the same line.

  • For old (pre 8xx), the SBC may core.
  • For 8xx and above, the SBC may be unable to send BYE on Egress.

The code is modified to address the issue.

Workaround: Disable the transparency of a reason header.

SBX-1119322

A restore on revision 1 failed in the standby OAM node.

Impact: A restore on revision 1 failed on the standby intermittently.

Root Cause: When the restore revision is requested, both OAM nodes restart. In a corner case, there is possibility of both starting as active and later one of the nodes will go down and not come up as standby.

Steps to Replicate: 

  1. Create a scenario with 1:1 OAM for the SSBC/MSBC/MRFP.
  2. In automation, keep the cleanStart as 1 so that the automation will trigger restore revision 1.

Both OAM should come up.

The code is modified to handle the corner case.

Workaround: Manually reboot the standby.

SBX-1120392

Uploaded onfig backup file is not available at gconfig.

Impact: The uploaded config backup file is not available on the gconfig.

Root Cause: The uploaded file was not moved in the config directory because the system name was not correct.

Steps to Replicate: 

  1. Log in to the EMA.
  2. Go to Administration -> System Administration -> File Upload.
  3. Upload the file.

The code is modified to read the correct system name.

Workaround: None.

SBX-1120853

The SFTP transfer is not working to CDR server that only supports AES128_CTR.

Impact: One customer has a CDR server that offers AES128_CTR for the server-to-client encryption. When the SBC offers AES256_CTR as the preferred option, the SBC encodes the packets with AES256_CTR, and receives the packets with AES128_CTR encryption. This scenario causes a decoding issue on the SBC that results in the termination of the connection.

Root Cause: An invalid encrypted data length is received from the CDR server.

Steps to Replicate: 

  1. Rollover the accounting file.
  2. Verify that the CDR transfer is successful.

The code is modified to offer up the AES128_CTR as the preferred encryption option, so both sides are using AES128_CTR.

Workaround: Disable the AES256 on the CDR server.

SBX-112267 | SBX-1123322

PortFix SBX-112267: The correct 92x serialization results in test failures.

Impact: When the registration control block is made redundant and the active/standby instances are running different software releases, the redundancy logic might not work correctly if the registration control block contains P-Charging-Vector (PCV) and/or P-Charging-Function-Addresses (PCFA) information. The redundancy logic will work correctly post upgrade when the 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-111659 | SBX-1123782

PortFix SBX-111659: The intercept is not working when P-Com.Session-Info is received in INVITE and tones are enabled.

Impact: When the lawful intercept target is specified in the P-com-session-info header of the INVITE message, the intercept does not occur if an announcement resource is applied to the call and then freed up. There is no issue if the P-com-session-info header is received in the backward direction.

Root Cause: This occurs when using P-early-media with tone profile and media monitoring profile applied to the call flow and the B-party sends P-early-media with a=inactive to start the media monitoring and does not provide RTP or does not send 200 OK prior to the monitoring timer expiring which results in the SBC playing RBT via an announcement resource. When the media path is later cut through and the announcement resource is released the intercept information was mistakenly freed up and the intercept did not occur.

Steps to Replicate: 

  1. Run a lawful intercept call flow using P-com-session-info header in the INVITE to indicate the target intercept point. The call should be configured with P-Early-Media, tone profile and monitoring profile to check for RTP packets received.
  2. In response to the egress INVITE, send back an P-early-media header with a=inactive and no RTP packets prior to the monitoring timer expiring so the SBC plays RBT.
  3. Answer the call and check that media is being sent to the intercept server.

The code is modified to ensure the intercept information is not freed up when freeing the announcement resource.

Workaround: None.

SBX-1124872

The LI connection to media server was not connected on a switchover.

Impact: When using the 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 transitions from standby to active so that the accurate interface information is available for LI processing.

Workaround: Bounce the interface e.g. ifup/ifdown that is used for LI connection would help to recover the connection.

Resolved Issues in 09.02.02R001 Release

The following Severity 1 issues are resolved in this release:

Severity 1 Resolved Issues


Issue IDSevProblem DescriptionResolution
1SBX-108317 | SBX-1117801

PortFix SBX-108317: The SBC switchover and isolation of node/SVWSBCD.

Impact: The PRS core was truncated because a second ABRT was sent to the process.

Root Cause: The PRS core was truncated because a second ABRT was sent to the process while it was in the process of writing the core.

Steps to Replicate: This issue is not reproducible.

The code is modified to prevent two ABRT signals from being sent to the same process.

Workaround: There is no workaround.

2SBX-111050 | SBX-111595


1

PortFix SBX-111050: There was a coredump during a reboot on a customer SBC. 

Impact: A misconfiguration of GW Signaling Ports, in which there is a Secondary GW Signaling Port configured but no Primary GW Sig Port configured, and can lead to a core and switchover.

Root Cause: When there is no Primary GW Signaling Port configured but there is a Secondary Signaling Port configured, we enter a code path that attempts to dereference a NULL pointer (pointer to Primary Sig Port) when it is attempting to get the dscp value to use for the socket.

Steps to Replicate: An SVT engineer should:

  1. Configure an SBC with a Secondary GW Signaling Port without configuring a Primary GW Signaling Port.
    i.e. gwSigPort of SBC1 should be in primary mode and SBC2 should be in secondary mode

  2. Send a GW-GW call from a remote GW through this SBC using the address of the Secondary GW Signaling Port on an SBC.

    Without the fix, this should cause a core.
    With the fix, there should be no issue.

The code is modified to prevent it from attempting to dereference a NULL pointer (pointer to Primary Sig Port) when it is looking up the dscp value to use for the socket.

Workaround: The workaround is to avoid configuring a Secondary GW Signaling Port without configuring a Primary GW Signaling Port.

3SBX-110199 | SBX-111474


1

PortFix SBX-110199: There was dbg log flooding with MAJOR .VNFR: *(VAgent) message

Impact: Event Logs are flooded with error message, when one of the OAM node or Managed VM goes down.

Log Message:.MAJOR .VNFR: *(VAgent): send error. rc=-1, error=Resource temporarily unavailable

Root Cause: The health check message send fails, when an instance is down.

Steps to Replicate: Run an LSWU from VNFM on an ISBC SWE instance in 1 to 1 HA mode.

The code is modified so the messages are only logged on the first error in health check. It is reset, when a message send succeeds.

Workaround: The error message stops automatically once the node is recovered and starts to respond to the health check messages.

4SBX-110884 | SBX-111318


1

PortFix SBX-110884: The logs are getting printed in openclovis.

Impact: If condition present, SCM is filling openclovis logs with this error message:
nprintf buffer too small. Need 306 Have 300 File: /sonus/p4/ws/release/sbx5000_V08.02.02R001/marlin/SIPSG/sipsgRegAgent.c Line: 2527

Root Cause: The error message is being logged because the code is attempting to write a debug log into a local buffer that is not big enough.

Steps to Replicate: No testing is required. This is no risk with/without fix.

The code is modified to increase the size of the local buffer.

Workaround: There is no workaround.

5SBX-109243 | SBX-111274



1

PortFix SBX-109243: The SBC sending 481 for CANCEL in dialog transparency.

Impact: When the dialog transparency is enabled and call loops back to the SBC, the SBC does not handle a CANCEL sent from ingress endpoint.

Root Cause: The SBC expects a CANCEL to have callinfo header.

Steps to Replicate: 

  1. Reproduce the issue.
    Dialog Transparency is enabled and the Call Loops back In.
    After adding PRACK, Ingress sends CANCEL without callinfo header.
    The SBC sends a 481.
  2. With a fix, the SBC sends 200 OK for CANCEL and relays to egress leg.

The code is modified to ensure the SBC finds the correct SG to handle the CANCEL even when the CANCEL does not have callinfo

Workaround: None.

6SBX-111100


1

Host check validation failing - Required GB RAM 6 but found 0.03125.

Impact: The few host machines in the AWS data center use different units for RAM, HostCheck script assumes that available memory is given in MB. The HostCheck script is fixed to calculate available memory based on unit of memory.

Root Cause: The HostCheck script does not have code to consider memory unit.

Steps to Replicate: Create VM with >=32 GB RAM, application should come up without complaining about memory in VM.

The code is modified to calculate available resources based on units.

Workaround: Create instance/VM that has < 32 GB RAM.

7SBX-107133 | SBX-111046


1

Portfix SBX-107133: Max FD limit is reached in SLB beyond 7,04,000 TLS connections (Access Registrations) tried.

Impact: Max FD limit is reached in the SLB beyond 7,04,000 TLS connections (Access Registrations) tried.

Root Cause: Observing the FD congestion at high load due to FD limits reached.

Steps to Replicate: Check the updated FD limits in /etc/security/limits.conf.

The code is modified for the max FD for the KVM and SLB.

Workaround: None.

8SBX-110350


1

The SBC is forming invalid packet where it is adding 00 in around all headers and parameters.

Impact: The SBC puts a NULL termination in every parameter and header of the message. In this case, there was a parser error on a parameter when the DNS translation was required.

Root Cause: During the parsing of the message after a DNS query, if a parser error occurs, then incorrect termination is put/left in the message when sent on the wire.

Steps to Replicate: 

  1. An incoming INVITE had a known syntax error related to alert_info, configuration was to parse through the filterProfile and not transparently forward alert_info. This resulted in parse error and bad formatting when DNS was executed.
  2. Configure the alertInfo to transparently pass on egress, and DNS function doing fqd/IP swap executes correctly and egress message is sent with good formatting.

The code is modified to:

  1. Log parse an error line number and pdu message.
  2. Apply the filterProfile when parsing the message. The customer needed to add filterProfile to transparently forward the parameter failing parsing on egress to avoid parse error and avoid incorrect parameter termination.

Workaround: On the Ingress, apply an SMM to rename alert_info to an unknown (x-alert_info), and rename back on the egress.

The following Severity 2-3 issues are resolved in this release:

Severity 2-3 Resolved Issues


Issue IDSevProblem DescriptionResolution
1SBX-1113942

The file upload is not working in the Platform Manager.

Impact: The file upload is not working in the PM.

Root Cause: The request URL length was too high as per-server configuration because that requested call was failed.

Steps to Replicate: 

  1. Log in to the Platform Manager.
  2. Go to Administration -> System Administration -> File Upload.
  3. Upload a file and save it.

The code is modified to make a request call successful.

Workaround: We can apply the same changes in a customer setup also and restart the apache server.

2SBX-1117002

Getting badRidCb errors during LSWU from 7.2.4R0 to 9.2.2A003

Impact: An upgrade from an older version to 9.2.0R0 and newer, the NP reported badRidCb error continuously: MAJOR .IPM: *NP 0 error counter badRidCb incremented: cnt 2310 last error 0x10002.

Root Cause: In version 9.2.0R0, Ribbon Protect streaming support was added. During an LSWU, new fields related to Ribbon Protect streaming were all initialized to zero in internal data structures, including the rbbnType. But in NP, rbbnType = 0 triggered NP to send RTCP_APP related statistics to Protect server, which caused the errors.

Steps to Replicate: Run an LSWU from any older version to 9.2.2 with call loads.

The code is modified to initialize the rbbnType to 'BRM_RBBN_PROTECT_STREAM_DISABLE' so that NP does not generate RTCP_APP to Protect server.

Workaround: No workaround.

3SBX-111211 | SBX-111652


2

PortFix SBX-111211 to 9.2.x - Get "violates foreign key constraint" error when assigning timeRangeProfile to a Route in EMA

Impact: Route creation fails when the name of time range profile contains numerals.

Root Cause: During the route creation, validation of time range profile was failing as it was containing numerals.

Steps to Replicate: 

  1. Create a time range profile with a name containing number ex test_1
  2. Create a route with test_1 as time range profile.
  3. Route creation should be successful.

The code is modified to consider numerals as valid a character.

Workaround: Create a Route from the CLI.

4SBX-108616 | SBX-111571


2

PortFix SBX-108616: Fora  Late Media Call, the SBC is not sending a second UPDATE towards ingress when the DLRBT is enabled.

Impact: In a late media convert call scenario, when the DLRBT is enabled, the SBC is not sending UPDATE towards the ingress with the list of codecs received from UAS.

Root Cause: The minimizing of media changes from other call leg functionality is suppressing the triggering of the UPDATE towards UAC.

Steps to Replicate: 

  1. The UAC sends INV without SDP to the SBC.
  2. The SBC sends INV with PCMA PCMU G729 101.
  3. The UAS sends 180 with PCMA G729.
  4. The SBC sends 180 with PCMA G729.
  5. The UAC sends PRACK with G729.
  6. The SBC starts playing tone with G729 towards ingress EP.
  7. The UAS sends 200 OK (for INV) without SDP.

The code is modified to identify this particular call scenario, such that, the SBC sends an UPDATE towards the UAC if the tone codec is different from the end to end negotiated codec.

Workaround: None.

5SBX-111502 | SBX-111566


2

Portfix SBX-111502: Metavar exchange continues even after the allocation is failed in the SBC.

Impact: The CHM processes the metavar request/response messages even when the application is going down, which results in failure messages.

Root Cause: The CHM does not check if the application is going down while processing the messages from the other nodes.

Steps to Replicate: Bring up the SBC in N:1 mode and then shutdown the application on one of the nodes while another node is starting the metavar exchange in CHM activation.

The code is modified to ensure that application is not going down before processing the metavar messages from other nodes.

Workaround: None.

6SBX-111469 | SBX-111565


2

Portfix SBX-111469: There are some problem causing MRFPs cannot recover from a restart

Impact: The standby SBC gets the already allocated metavars of an active node while coming up in an 'active' role.

Root Cause: The standby SBC is not checking for the condition to see if its the only node running in the redundancy group before allocating the last exchanged metavars of active node.

Steps to Replicate: Bring up the N:1, trigger a switchover so that assigned standby becomes active and while assigned active node is coming up in 'standby' role. Restart assigned standby and ensure the proper metavars are allocated to assigned standby node while its coming up in 'active' role.

The code is modified to check for the already allocated metavars before allocating the metavars to self node while coming up in the 'active' role.

Workaround: Restart assigned standby node if already allocated metavars are allotted to this node.

7SBX-111310 | SBX-111562


2

Portfix SBX-111310: Standby OAM is rebooting after orchestration.

Impact: The Standby OAM is restarting after a launch.

Root Cause: The Standby OAM is sending the serf event for 'startingStandby' with an older timestamp (which is fetched even before standby OAM is ready to come up) that results in discarding of the serf event by the active OAM node as its prior to member-join event for standby OAM node.

Steps to Replicate: Bring up both the active and standby OAM at the same time and then while standby OAM is coming up, disconnect and connect the HA port on active OAM to trigger member-failed and member-join events.

While sending the 'startingStandby' serf event, get the current timestamp so that its not discarded by the active OAM node.

Workaround: Restart the standby OAM application so that the startingStandby event is generated again with a current timestamp.

8SBX-109811 | SBX-111520


2

PortFix SBX-109811: The SBC uses port number RTP+1 for RTCP instead of the learned RTCP port number if the RTCP NAT learning completes before RTP NAT learning.

Impact: The SBC sends the RTCP packets to a destination port number RTP+1 for the RTCP instead of the learned RTCP port number if the RTCP NAT learning completes before RTP NAT learning.

Root Cause: The SBC overwrites the learned RTCP port number with the RTP+1 port number if the RTCP is learned before RTP.

Steps to Replicate: Send RTCP packets first then RTP packets to the SBC. After call is connected, verify the RTCP port number, if RTCP is learned before RTP.

The code is modified to use correct RTCP learned port when RTCP learning occurs before RTP, instead of comparing the RTP and RTCP addresses from callLeg structure.

Workaround: No workaround.

9SBX-89177 | SBX-1114682

PortFix SBX-89177: A call is torn down upon a Hold (OA expiry).

Impact: A call flow involving an early media, tone and late Crankback results in a call tear down by the SBC while processing the HOLD INVITE.

Root Cause: While processing a 200 OK for INVITE, one of the call processing module ends up setting wrong App-Context-Id as active. Later, while processing a HOLD INVITE, this causes a failure since this module is not working on the latest App-Context-Id.

Steps to Replicate: Call Scenario:

  1. Party A calls Party B through the SBC.
  2. Party B sends 183 with SDP resulting in media cut-through at the SBC.
  3. Later B sends 480.
  4. The SBC is configured for the Crankback and as a result sends INVITE to Party C.
  5. Party C sends 183 with SDP.
  6. Party C sends 180 without SDP resulting in tone.
  7. Party C sends 2xx with SDP for INVITE.
  8. Party C sends HOLD INVITE.

Expected behavior: The SBC successfully process the HOLD INVITE.

Actual Behavior (without a fix): The SBC tears down the call while processing HOLD INVITE.

The code is modified to have the correct app Context Id as active while processing 200 OK for INVITE.

Workaround: Disable the Tones at the SBC.

10SBX-110948 | SBX-111397


2

PortFix SBX-110948: Load configuration overwrites the local processor index values.

Impact: When we perform a load config operation on a 1:1 HA pair (SWe/Cloud), it ends up overwriting the local processor index estimates with the ones that are present in the config dump.

This leads to two issues:

  1. An incorrect index estimates being populated in the DB.
  2. There are discrepancy in estimations between active and standby instances.

Root Cause: The load config operation results in overriding the local processor index estimates with the ones that are present in the config dump. This results in standby consuming incorrect indices present in the DB thereby causing the discrepancy in estimates of the active and standby instances.

The DB should always reflect the estimated processor indices calculated by the active instance in 1:1 HA pair.

Steps to Replicate: On 1:1 HA SWe/Cloud instances, perform the following steps:

  1. Run the following command as root user on the active and standby instances. The following command should give same output on the active and standby instances.
    cat /opt/sonus/conf/swe/capacityEstimates/.index.txt
  2. Perform the load config operation.
  3. Run the following command as root user on the active and standby instances. The following command will give different output on the active and standby instances.
    cat /opt/sonus/conf/swe/capacityEstimates/.index.txt

    With the fix, this issue will not be observed.

The code is modified to ensure that the DB reflects the estimated processor indices calculated by the active instance in 1:1 HA pair.

If the processor indices values stored in the DB does not match with the indices calculated by the standby, then the standby goes for a reboot. From the next boot on-wards, the standby uses the indices stored in the DB for the session estimations.

The previously mentioned procedure ensures that the indices and sessions estimates are same on the active and standby instances.

Workaround: Run the following commands as root user on the active and standby instances.

1. The rm -f /opt/sonus/conf/swe/capacityEstimates/.indexMarker
2. Run a reboot

11SBX-111363


2

The SBC VNF cannot get to Ready after a VNFM Migration.

Impact: The VNF does not get ready after a migration to the new VNFM.

Root Cause: When the new VNFM is trying to send the curl request to the VNF, the request is getting rejected. When the VNF gets deployed, it contains the VNFM data in its user data and it makes one VNFM IPs allowed list. This allowed list is not getting updated for the new VNFMs. So, when VNF migrates to the new VNFM, new VNFM IP is not present in the allowed list.

Steps to Replicate: 

  1. Launch VNFM with https.
  2. Deploy a VNF and scale out the VNFM. Migrate the VNF to the new VNFM.
  3. The VNF state should be read and available.

The code is modified so whenever the new VNFM sends a request to VNF, it is accepted.

Workaround: 

  1. 1. Reboot the setup.
  2. 2. Add new VNFM IP in the /opt/sonus/conf/instanceLca.json before the application comes up.
  3. 3. Check the state of the VNF on VNFM.
12SBX-99253 | SBX-111358


2

SBX-99253: Customer ECGI to CA Mapping Enhancement.

Impact: The SMM Switch operation is not working after an SBC reboot.

Root Cause: The switchIndex is not being set properly during a config restore.

Steps to Replicate: 

  1. Configure SMM Rule consisting of switch operation.
  2. Run the Call.
  3. Perform an SBC reboot.
  4. Run the call (SMM will not be executed).

The code is modified to set correct the SwitchIndex during a config restore.

Workaround: After a reboot, we can delete the SMM profile and configure again.

13SBX-111339


2

CDR Viewer Download all button not working

Impact: The CDR Viewer download all button was not working.

Root Cause: An issue was caused when we changed the CSP. Due to that change, the content was made more strict and blob type were not allowed in Firefox and IE, resulting in a download failure.

Steps to Replicate: 

  1. Log in to the EMA.
  2. Navigate to CDR Viewer.
  3. Select the Sip Ladder and click Download All.
  4. Download is successful in Firefox/IE/Chrome.

The code is modified to allow the same to further processing.

Workaround: No workaround.

14SBX-110956 | SBX-111291


2

PortFix SBX-110956: Introduced the Upsampler for EVS in a EVS(wb)<=> NB codec scenario.

Impact: The WB will not be used for EVS encoding and as a result, the channel aware mode cannot be enabled in an IDP NB scenario though negotiated through the SDP.

Root Cause: There is an absence of an Upsampler in the Upstream path for EVS when WB is negotiated in an IDP NB scenario.

Steps to Replicate: Run a EVS<=>G711 call with bw=wb; ch-aw-recv-5;br=5.9-13.2.

In this case, the EVS encoder produces WB packets with channel aware mode enabled.

The code is modified for the EVS when the WB is negotiated in an IDP NB scenario.

Workaround: None

15SBX-109300 | SBX-111289



2

PortFix SBX-109300: The SBC should not accept cmr byte from discarded packets.

Impact: The SBC was accepting the CMR from discarded packets.

Root Cause: The CMR was being processed before Packet Validation.

Steps to Replicate: Run and EVS<=>EVS call. Let the peer send 32Kbps packets having CMR for 24.4Kbps.

In this case, the 32Kbps packets are discarded as we do not support transcoding beyond 24.4Kbps for EVS. Also since the packets are discarded CMR for 24,4Kbps is also not honored.

The code is modified to validate the packet first followed by the CMR processing.

Workaround: None.

16SBX-109304 | SBX-111286


2

PortFix SBX-109304: The 13.2 wb cmr is not accepted when the SBC is operating in channel aware mode.

Impact: The channel aware mode once enabled will always be enabled when the EVS encoder operates at 13.2Kbps and bandwidth WB. The only way to disable channel aware mode is to use a bitrate other than 13.2Kbps.

Root Cause: The code to disable the channel aware mode if enabled on receiving on 13.2 WB CMR was absent.

Steps to Replicate: Run a EVS to G711 call with br=13.2, ch-aw-recv-5; bw=wb.
Stream a pcap having CMR for 13.2 WB from the peer.

The call starts with 13.2 Kbps with Channel Aware mode being enabled. On receiving the CMR, the channel aware mode will be disabled while the bitrate is still 13.2.

The code is modified to address the issue.

Workaround: None.

17SBX-110439 | SBX-111280


2

PortFix SBX-110439: The DSP rejects CMR requesting channel-aware if localCodecMode is set to a value other than 13.2.

Impact: The SBC was rejecting a Channel Aware Mode CMR when the current mode of operation of EVS encoder was not 13.2Kbps WB.

Root Cause: A conditional check of the current Bandwidth and current Bitrate to honor a Channel Aware Mode CMR.

Steps to Replicate: Run a EVS to AMRWB call with the following SDP:

br=13.2-24.4; bw= nb-wb; ch-aw-recv=0

End point sends a CMR for Channel Aware Mode.

In this case, the call starts with EVS encoder encoding packets as 24.4Kbps and on receiving the CMR, the rate changes to 13.2Kbps with Channel Aware mode enabled.

The code is modified to check if 13.2Kbps is a part of the activeCodecSet and whether WB is present in the bandwidth range negotiated to honor a Channel Aware Mode CMR.

Workaround: None.

18SBX-110299 | SBX-111278


2

PortFix SBX-110299 to 9.2 - MRFP does not active EVS partial redundancy mode during the call when the remote offers "ch-aw-recv=0"

Impact: When the ch-aw-recv=0 is negotiated through the SDP, a CMR request for the Channel Aware mode with offset 2 and the priority HIGH was not being processed.

Root Cause: The root cause of this issue was a wrong initialization of the channel aware mode offset and priority in the code.

Steps to Replicate: 

  1. Run a EVS to G711 call with br=13.2; bw=wb;ch-aw-recv=0
  2. Stream a pcap with CA CMR for priority HI and offset 2.

Prior to the fix the CMR is not processed. With the fix, the CMR is processed and also honored.

The code is modified to address the issue.

Workaround: None.

19SBX-111270


2

The CDR record for DSP insertion/rejection reason field in 9.2.2R000 test execution has marked the call as “Transcoding” instead of “Transcoding due to DTMF”.

Impact: The CDR DSP insertion reason is showing as trancoded instead of the DTMF for transcoded call with difference in DTMF parameters on the ingress and egress leg.

Root Cause: The wrong code is present and overwrites the DSP insertion reason as transcoded.

Steps to Replicate: Make a successful transcoded call with AMR codec on both sides and the
DTMF parameter must be different in both ingress and egress.

The code is modified to set the DSP insertion reason based on the answered call leg.

Workaround: None.

20SBX-111256


2

The system level baseUdpPort is allowed to set higher than the range set at the IPTG level from the CLI.

Impact: It is possible to set the system media mediaPortRange baseUdpPort value to a greater value than the value assigned to all the associated trunk groups, which is invalid.

Example: set addressContext <name> zone <name> sipTrunkGroup <name> media
mediaIpInterfaceGroupName <IPIG name>media mediaPortRange baseUdpPort 1030

set system media mediaPortRange baseUdpPort 1050

Root Cause: With the introduction of the SBC and realms, the validation code was incorrectly looking for realm data to validate the system level baseUdpPort against rather than the zone/address context/trunk group information that is used in SBC configurations.

Steps to Replicate: Try to run the configuration below and check that an error report is now generated.

commit Aborted: 'system media mediaPortRange': System base UDP port cannot be greater than mediaPortRange configured at a trunk group

The code is modified to correctly use the zone/address context/trunk group information to validate the baseUdpPort information on the SBC configuration.

Workaround: Manually check the values on the trunk group before assigning the system level value.

21SBX-111218


2

Invalid value for "45.20 Reason Header value Q850" in the ACT record.

Impact: The invalid values populated in the CDR sub field 20 in ATTEMPT record.

Root Cause: In the Signaling Application, during Call Failure the value passed to CAM module to populate in the CDR for the sub field bit 20 was out of Q850 range. This is due to not mapping the internal CPC cause code to the corresponding Q850 standard values.

Steps to Replicate: Disable the Reason Header Q850 flag, and make a call. Reject the call with 607, where SIPTOCPC profile mapped as 607-216 post call release check the CDR Sub field - 20.

The code is modified to take care of mapping to right Q850 values.

Workaround: None.

22SBX-1111772

The SBC inccorectly interprets RTCP packets as RTP when using DLRBT.

Impact: The RBT (ring back tone) can be terminated early when the DLRBT (dynamic local ring back tone) is enabled and RTCP packets 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. As soon as SDP was received in 183, the SBC triggered cut through and the RBT was stopped even though the call was not answered. This left the A-party with silence until the call was answered.

Steps to Replicate: Make a PSTN to MS Teams call with DLRBT enabled. Leave the call in ringing state with MS Teams for a long time and check that the ring tone is continually generated.

The code is modified to correctly identify RTCP packets and not use this as an indication to media being learned so that the ring tone continues to be played until real RTP packets arrive.

Workaround: If RTCP is not required on the egress leg then disable it. If RTCP is required there is no work around.

23SBX-111163


2

Export/import of the syslog configuration fails.

Impact: The user-config-import command fails if the customer has configured the SBC to send the Linux level logs to a remote syslog server through the platformRsyslog configuration.

Root Cause: The child configuration objects under the platformRsyslog configuration were not being applied in the correct order during the import, which led to the configuration validation logic thinking there was no syslog server configuration and failing.

Steps to Replicate: Apply syslog configuration under the platformRsyslog and check that it can be exported and imported without errors.

The code is modified to correctly define the configuration order for platformRsyslog configuration so there are no errors during the import.

Workaround: If you edit the syslogState line in the xml file and change it from enabled to disabled, the import will complete correctly. Then manually apply the CLI command to enable the syslogState once the rest of the configuration is imported.

<platformRsyslog>
<syslogState>disabled</syslogState>
<linuxLogs>
<platformAuditLog>enabled</platformAuditLog>
<consoleLog>enabled</consoleLog>
<sftpLog>enabled</sftpLog>
<kernLog>enabled</kernLog>
<userLog>enabled</userLog>
<daemonLog>enabled</daemonLog>
<authLog>enabled</authLog>
<syslogLog>enabled</syslogLog>
<ntpLog>enabled</ntpLog>
<cronLog>enabled</cronLog>
</linuxLogs>
<servers>
<serverNo>server1</serverNo>
<remoteHost>2607:f160:10:4043:ce:ff0:0:35</remoteHost>
<protocolType>udp</protocolType>
</servers>
</platformRsyslog>

24SBX-110984 | SBX-111144


2

PortFix SBX-110984: The EVS CMR not honored when in dtx period.

Impact: If the SBC receives a CMR request when it is operating in DTX mode, the CMR was not being processed.

Root Cause: The rate or bandwidth change received through a CMR was not put into effect after coming out of the no transmission period.

Steps to Replicate: Run an EVS<=>EVS call with dtx enabled. On the Ingress leg, send a valid CMR while there is no media being sent on the Egress Leg. Send a CMR on the ingress leg when it is in the "no transmission period"

Once the Ingress Leg comes out of the no tx period, the bitrate or the bandwidth as requested by the CMR should be put into effect

The code is modified to address the issue.

Workaround: None.

25SBX-1111202

Customer Physical Server had a reboot failure.

Impact: In a SBC Redundancy Group if an instance contains an SM core that did not cause service outage, the instance can go down when a switchover occurs between two other instances of same RG.

Root Cause: The coreHandler/FacHandler process gets called to dump the core during a coredump on SBC if FAC feature is enabled. This process registered itself in sysIdList that is unintended and causes SM to crash while handling instance down event for other instances of same RG.

Steps to Replicate: Create a RG, run it for few days and wait for an SM core due to the NTP, which does not cause the SBC to go down. Perform a switchover in same RG between two other nodes. The current node should not go down with fix build.

The code is modified to ensure the FacHandler does not register in sysIdList.

Workaround: None.

26SBX-110850 | SBX-111020


2

PortFix SBX-110850: Alter CPU Affinity of Processes in 2vcpu Scenario

Impact: There are intermittent crashes of SWe_NP/SWe_UXPAD processes in 2 vcpu deployments.

Root Cause: The SWe_NP and SWe_UXPAD DPDK processes running on the same core caused memory corruption in mempools.

Steps to Replicate: 

  1. Bring up a 2 vcpu VM.
  2. Run a heavy transcode call load for long duration.

The code is modified to launch the SWe_NP and SWe_UXPAD processes on different cores.

Workaround: There is no workaround for this issue.

27SBX-111004


2

The SCM Process cores on the customer PSBCs PS40, PS41, and PS42.

Impact: A SCM Process coredump was observed because of Segmentation fault when a call was intercepted with PCSILI and media monitoring enabled.

Root Cause: The SCM Process dumped core while pushing request for splitter resources and media monitoring was enabled.

Steps to Replicate: 

  1. Configure the SBC and PSX for basic audio call.
  2. Configure the customer CLI on Egress Leg for basic call.
  3. Enable Media Monitoring on Egress leg for basic call.
  4. Enable the Tones on Ingress Leg.
  5. Perform an Interception based on PCSI_LI.

The code is modified to avoid the coredump.

Workaround: None.

28SBX-109211 | SBX-110945


2

PortFix SBX-109211: There was a design gap for AMR around dynamic codec transcoding.

Impact: The SBC is configured with restricted AMR/AMR-WB codec in Egress Route PSP along with Transcode "If Different DTMF PT" enabled then consider Egress endpoint selects the first pass-through restricted AMR/AMRWB payload in Offer in its 200 O.K answer. In such a case, if the DTMF attribute of the payload doesn't match then the SBC will try to match the Answered AMR/AMR-WB codec with the transcode-able AMR/AMR-WB codec. In such a case the DTMF attribute will match but the mode-set match fails that causes a call failure.

Root Cause:The SBC is configured with restricted AMR/AMR-WB codec in Egress Route PSP along with Transcode "If Different DTMF PT" enabled then consider Egress endpoint selects the first pass-through restricted AMR/AMRWB payload in Offer in its 200 O.K answer. In such a case, if the DTMF attribute of the payload doesn't match then the SBC will try to match the Answered AMR/AMR-WB codec with the transcode-able AMR/AMR-WB codec. In such a case the DTMF attribute will match but the mode-set match fails that causes a call failure.

The partial matching of AMR/AMR-WB codec in a Offer Answer cycle was allowed early, and that was what caused the issue.

Steps to Replicate: The SBC receives an INVITE with (AMR PT=96 and mode-set=1 and 2833 DTMF PT=101).
Egress route is configured with AMR mode-set=0, 1, 2, 3, AMR PT=126 and DTMF PT=110
Egress route is configured to transcode for Difference in 2833 PT
This causes the SBC to send out INVITE to UAS as follows:
96 (AMR mode-set=1)
126 (AMR mode-set=0,1,2,3)
110 (DTMF PT)

The code is modified so if the SBC transcodes the call due to Different DTMF, the transcoding is allowed and first offered payload type is used.

Workaround: None.

29SBX-110009 | SBX-110876


2

PortFix SBX-110009: The values in callsEstimate.txt differ between the Active and Standby SWe.

Impact: The session capacity estimate values differ in active and standby VMs upon an LSWU upgrade of 1:1 the SWe HA pair.

Root Cause: The following sequence of events resulted in the issue:

  1. The processor indices are re-calculated upon LSWU upgrade, which differs from the processor indices calculated by the SBC VM in the earlier version.
  2. The session estimates are calculated based on these new processor indices.
  3. Post upgrade, once the application comes up, the processor indices that are stored in DB(from the older version VM), are restored back to the /opt/sonus/conf/swe/capacityEstimates/.index.txt file.

As a result, the Active and Standby VMs obtained different session estimates upon upgrade.

Steps to Replicate: After subjecting the 1:1 SWe HA to LSWU upgrade, content of the following file in Active and Standby VMs would differ:
/opt/sonus/conf/swe/capacityEstimates/.callsEstimate.txt

The code is modified to retain the processor indices during the LSWU procedure.

Workaround: After completing the LSWU upgrade, once the active(VM-A) and standby(VM-B) VMs are in sync, following a set of operations would make sure that session capacity estimates are identical in Active(VM-A) and Standby(VM-B) VMs:

  1. Reboot the Standby (VM-B) VM.
  2. The standby (VM-B) VM comes up with correct session estimates. Wait for the completion of application sync.
  3. Now, reboot the Active(VM-A) VM. This results in application failover. Application running on the Standby(VM-B) VM takes over the active role.
  4. Active(VM-A) VM comes up with the correct session estimates and comes in sync with the application running on the Standby(VM-B) VM.
30SBX-105890 | SBX-110766


2

PortFix SBX-105890: On a disk failure, the correct failover is not triggered.

Impact: On an SBC that was running 6.2 code, the disks on the SBC got into a bad state and would not process read or write operations. Automatic attempts to reboot the SBC from the application code failed and manual intervention was required to recover.

Root Cause: Later software releases already had better handling for this sort of issue but the code was printing multiple logs as part of the automatic reboot process and it was suspected that these could have gotten hung and the system could not get to the reboot command.

Steps to Replicate: The issue was not reproducible.

The code is modified to remove the logs to avoid the potential or not getting to actual reboot command in the code.

Workaround: The SBC needs to be manually power cycled to recover.

31SBX-109591 | SBX-110172


2

Portfix SBX-109591: Reject the INVITE with 100Rel when TG flag rel100Support is disabled and E2E Prack is disable on that leg after PSX DIP.

Impact: The SBC does not tear down the call if the INVITE contains a Require: 100rel and the rel100Support flag is disabled on the ingress sipTrunkGroup, as per RFC3262.

Root Cause: When the rel100Support flag is disabled and INVITE contains Require: 100rel, the SBC was not rejecting the Invite with 420 Bad extension. This scenario was not handled.

Steps to Replicate: Set this flag:
set addressContext default zone ZONE_IAD sipTrunkGroup TG_IAD signaling rel100Support disabled

When the INVITE is received with Require: 100rel and endToEndPrack is disabled, the SBC should reject the call with a 420 Bad extension and the SBC should send header Unsupported:100rel toward the ingress.

The code is modified so that when rel100Support flag is disabled and endToEndPrack is disabled.

If the INVITE contains a Require: 100rel, the SBC will reject the INVITE with 420 Bad extension and the SBC will send header Unsupported :100rel toward the ingress.

Workaround: None.

32SBX-108410 | SBX-1093792

PortFix SBX-108410: [ASAN]: sanitizer.CE_2N_Comp_ScmProcess_3.8866:==CE_2N_Comp_ScmProcess_3==8866==ERROR: AddressSanitizer: heap-use-after-free on address 0x6190001c77dd at pc 0x558bcc9ff877 bp 0x7fea305f4e00 sp 0x7fea305f45b0

Impact: The ASAN reported a "AddressSanitizer: heap-use-after-free" error when a Subscribe request had a NULL character in a quoted string.
ie: From: "00 test"<sip:user1@host>

Root Cause: Invalid access of the freed memory occurred. Accessing memory after it is freed can cause unexpected behavior that may result in coredumps.

Steps to Replicate: Run the codenomicon subscribe-notify suite.

The code is modified so the SBC now logs a parser error If the SBC receives NULL character in a quoted string.

Workaround: None.

33SBX-107798


2

The one way audio when forked leg is MS Teams without ICE/NAT.

Impact: For an incoming call that is forked to multiple destinations and DLRBT is enabled, there is a possibility of audio flowing only in one direction when the call gets established.

Root Cause: When a 180 ringing is first received from one of the forked destinations, this triggering the SBC to play ringback tone, but if the call subsequently receives 18x messages and RTP media (for media cut through) from a different destination, the SBC fails to activate the RTP media flow resources correctly at the ingress leg of the call because these resources are already activated for playing the ringback tone for the other fork.

Steps to Replicate: Set up
---------
The SBC configured with call forking such that call from ingress (A) to be forked to egress (B) and egress (C).
The DLRBT should be enabled on ingress and egress trunk toneAndAnnouncementProfiles.

Procedure
--------------

  1. Initiate the call with an INVITE from A that should be forked to B and C.
  2. From the egress endpoint B respond with 180 and then from egress endpoint C respond with 180.
  3. From egress endpoint C respond with 183 with SDP.
  4. Send the RTP media packets back from C to cause media CUTTHRU.
  5. From egress endpoint C respond with 200 OK to connect the call.


Expected Results
-----------------------
1. The INVITE sent to B and C.
2/3. The SBC sends back 180 towards A and starts to play ringback tone towards A.
4/5. The call is established, the SBC sends CANCEL towards B, ringback tone should stop and media should flow in both directions between A and C.

Before the fix, media was not flowing from A to C.

The code is modified to re-activate the media resources after the call is answered on one of the forks and the remaining forks have been cleared.

Workaround: Not available, but the issue does not occur if the DLRBT is not enabled.

34SBX-1066013

PortFix SBX-105609: Add a check for /boot parition free space in pre-checks.

Impact: There was an upgrade failure due to insufficient disk space on /boot partition.

Root Cause: There was an upgrade failed due to failure to copy the new boot images as part of upgrade due to insufficient disk space in /boot partition.

Steps to Replicate: Upgrade to the fix build and ensure upgrade is successful.

The code is modified as part of pre-checks to ensure a minimum of 40MB free disk space is available on /boot partition.

Workaround: None.

35SBX-110292 | SBX-1107893

PortFix SBX-110292: A Registration structure update is needed to prevent hijacking/hacking of the user after being rejected with a 403 Forbidden error.

Impact: After a hack, the registers rejected with 403 Calls were not working.

Root Cause: Both a normal and hacker user had very similar Register messages, except that the hacker's Auth header did not include the correct username. Due to this username mismatch, the SBC rejected the hacker with a 403 message, set the Register into 'challenged' state and later deleted the message.

Steps to Replicate: There are 8 combinations of test cases. The major difference is in the username field Auth header.

Test1:

  1. Proper registration: Reg->401→Reg (with Auth)→200
  2. Hacker registration: Reg->401→Reg (with hacker Auth)→403
  3. Proper user refresh
  4. Hacker registration: Reg->401→Reg (with hacker Auth)→403

Check for all fields and expiration timer.


Test2:

  1. Proper registration: Reg->401→Reg (with Auth)→200
  2. Hacker registration: Reg->401→Reg (with hacker Auth)→403
  3. Proper user refresh
  4. Hacker registration: Reg (with hacker Auth)→403


Test3:

  1. Proper registration: Reg->401→Reg (with Auth)→200
  2. Hacker registration: Reg (with hacker Auth)→403
  3. Proper user refresh
  4. Hacker registration: Reg->401→Reg (with hacker Auth)→403


Test4:

  1. Proper registration: Reg->401→Reg (with Auth)→200
  2. Hacker registration: Reg (with hacker Auth)→403
  3. Proper user refresh
  4. Hacker registration: Reg (with hacker Auth)→403


Test5:

  1. Proper registration: Reg (with Auth)→200
  2. Hacker registration: Reg->401→Reg (with hacker Auth)→403
  3. Proper user refresh
  4. Hacker registration: Reg->401→Reg (with hacker Auth)→403

Check for all fields and expiration timer.


Test 6:

  1. Proper registration: Reg (with Auth)→200
  2. Hacker registration: Reg->401→Reg (with hacker Auth)→403
  3. Proper user refresh
  4. Hacker registration: Reg (with hacker Auth)→403


Test 7:

  1. Proper registration: Reg (with Auth)→200
  2. Hacker registration: Reg (with hacker Auth)→403
  3. Proper user refresh
  4. Hacker registration: Reg->401->Reg(with hacker Auth)→403


Test 8:

  1. Proper registration: Reg (with Auth)→200
  2. Hacker registration: Reg (with hacker Auth)→403
  3. Proper user refresh
  4. Hacker registration: Reg (with hacker Auth)→403

The code is modified so when the SBC rejects the hack because of a username mismatch in the Auth header, it reverts back to previous details and state (that is complete).

Workaround: None.

36SBX-103963 | SBX-1073873

PortFix SBX-103963: Both SBCs restarted at the same time and both mounted drbd0.

Impact: Both SBCs restarted at the same time and both mounted drbd0.

Root Cause: The PRS Process was not updating the syncStatus flag value, due to which the the standby was also rebooting thinking the sync is not complete yet.

Steps to Replicate: When both the the nodes are up and running, restart the standby. And while the standby is coming up, run a switchover from active CLI. The switchover should be successful.

The code is modified to use SMA API to check syncStatus instead of PRS and CHM local syncStatus flags.

Workaround: None.

Resolved Issues in 09.02.01R003 Release

The following Severity 1 issues are resolved in this release:

Severity 1 Resolved Issues

Issue IDSevProblem DescriptionResolution
SBX-107397 | SBX-1108611

Portfix SBX-107397: There was an SBC switchover DEADLOCK detected for sysID 62, task SIPSG.

Impact: An SIP call load can trigger a healthcheck timeout in the SIPSG module.

Root Cause: The problem was with the flags that is used for creation of shared memory between SCM process and fault avalanche handler process. As a result of incorrect setting of flags some of the writes to the shared memory was taking more time resulting in the SCM thread getting blocked and health check timeout.

Steps to Replicate: 

  1. Run a 50 cps SIP-SIP call load for an extended period of time.
  2. Ensure that the fault avalanche control feature is turned on.

"show system faultAvalancheControl facState" should be enabled.

The code is modified to disable fault avalanche control functionality by default.

Workaround: Disable the Fault Avalance control functionality using the following configuration control.

set system faultAvalancheControl facState disabled



SBX-1102481

The SBC SWe crashes when making a video call with a certain type of phone. 

Impact: The SBC SWe NP crashes when IPsec fragmented signaling packets scenario calls made by using IPsec crypto as NULL encryption.

Root Cause: During the IPsec crypto null processing of fragments (chained mbuf segments) by the SWe NP, an incorrect first segment length corrupted adjacent buffers, which resulted in a crash of the SBC SWe.

Steps to Replicate: Establish IPsec session with null encryption and make calls.

The code is modified to address the issue. 

Workaround: Use IPsec non-null encryption suites such AES/3DES.

SBX-1119661

The SBC/GSX fail to decode trigger response received from the PSX and leads to call failure.

Impact: Call failures are seen at the SBC when the STI Service is executed for a Trigger Request on the PSX.

Root Cause: For a two-staged call, the SBC performs a trigger request following an initial policy request to the PSX. If any STI service like signing or verification is executed for this trigger request, the SBC fails to decode a trigger response received from the PSX and leads to a call failure.

Compiled diameter Read methods for STI AVPs that are executed on the GSX and SBC are incorrectly looking for TRG_REQ(trigger request) tag while decoding TRG_RESP (trigger response), which is leading to decode errors on the GSX/SBC and resulting in a call failure.

Steps to Replicate: 

  1. Perform a two stage call flow with the STI service enabled.
  2. Ensure that the SBC sends a trigger request to the PSX for a two stage call call flow and perform the STI service.
  3. Observe that there are no diameter decode errors on the SBC that can lead to a call failure.

The code is modified to look for the correct TRG_RESP tag. The SBC builds updates to use new diameter read methods.

Note: This fix only stops the DIAMETER decoding errors and a further fix is being tracked under another JIRA for a future release to have the SBC pass STI information in the trigger request, as well as process the information in the trigger response to STI service works in conjunction with 2-stage calls.

Workaround: As a workaround, STI service escapes for a trigger request.

The following Severity 2-3 issues are resolved in this release:

Severity 2-3 Resolved Issues

Issue IDSevProblem DescriptionResolution
SBX-109013 | SBX-1107842

Portfix SBX-109013: Increase the healthcheck interval.

Impact: Coredumps are occasionally seen in the field due to the health check timer expiring when the process gets stuck.

Root Cause: In SWe environments, disk/CPU timing issues can lead to the process slowing down and hitting these health check issues.

Steps to Replicate: This issue was only reproduced using debug code.

The code is modified to be more forgiving to cope with short spikes. The health check ping interval is now 2 seconds and must have 15 consecutive non responses in order for the process to be declared deadlocked and a coredump initiated to recover.

Workaround: None.

SBX-109153 | SBX-1107762

Portfix SBX-109153: DTLS: A 503 Service Unavailable with GCM Ciphers.

Impact: The following ciphers could not be used with DTLS:

  1. ECDHE_RSA_WITH_AES_128_GCM_SHA256
  2. ECDHE_RSA_WITH_AES_256_GCM_SHA384
  3. RSA_WTIH_AES_128_GCM_SHA256
  4. RSA_WITH_AES_256_GCM_SHA384
  5. ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

Root Cause: The TLS profile had been updated with additional ciphers listed below but the DTLS code was not updated to support these.

Steps to Replicate: Use aDTLS client that support these ciphers make a connection to the SBC.

The code is modified to include support for these ciphers.

Workaround: None.

SBX-1102052

D-SBC: The calling party cannot hear disconnect treatment announcement if M-SBC is a N:1 cluster.

Impact: The connection IP is not updated when a different M-SBC is selected in clustered D-SBC deployment during disconnect treatment. The SBC was using the old connection IP which was causing the Ingress Peer endpoint not being able to hear the Disconnect Announcement.

Root Cause: The newly allocated M-SBC media IP during Disconnect Treatment is not used by NRMA due to incorrect validation check and the previous one is used which caused the one way audio issue.

Steps to Replicate: 

  1. Configure Disconnect Tone Treatment in the SBC with an M-SBC cluster.
  2. From the Ingress endpoint, send SIP INVITE to the SBC.
  3. From Egress side send SIP 404 USER NOT FOUND in response to the INVITE.
  4. Ensure Ingress side endpoint hears "Disconnect Tone TreatMent".

The code is modified to not use the newly allocated M-SBC media IP during Disconnect Treatment by the NRMA (due to incorrect validation check), and instead use the previous treatment that caused the one-way audio issue. 

Workaround: None.

SBX-1105583

A call hold from both ends causes a re-INVITE handling issue.

Impact: Call Holds received from both ends results in a re-INVITE handling issue.

Root Cause: UserA to UserB call is connected. UserA puts call on hold. Later, UserA triggers a latemedia re-INVITE, and the SBC sends 2xx with offer SDP with a=sendrecv, the local dpm mode changes to sendrecv. The ACK received from UserA with a=inactive. call is still on hold.

When userB also initiates the hold (ie., hold from other direction), it should be relayed to UserA. But the SBC not relaying the re-INVITE. Due to improper late media re-INVITE handling, the SBC media state changed, which blocks the relaying of hold re-INVITE from other direction.

Steps to Replicate: 

  1. UserA to UserB call is connected.
  2. UserA puts call on hold.
  3. UserA triggers latemedia re-INVITE, the SBC sends 2xx with offer sdp with a=sendrecv. The ACK received from UserA with a=inactive.
  4. UserB sends re-INVITE to put call on hold (ie., hold from other direction).
  5. Nothing will be sent to UserA.

The code is modified to relay the hold re-INVITE from the other direction.

Workaround: None.

Resolved Issues in 09.02.01R002 Release

The following Severity 1 issues are resolved in this release:

Severity 1 Resolved Issues

Issue IDSevProblem DescriptionResolution
SBX-109465 | SBX-1096861

Portfix SBX-109465: The Leadership algorithm workaround for the openclovis issue can cause a core dump.

Impact: The safplus_gms process crashes when coming out of split brain.

Root Cause: Incorrect/inconsistent data results in the code asserting.

Steps to Replicate: This issue is not easily reproducible and is caused by HA link instability/flapping.

The code is modified so that the data is consistent.

Workaround: Run HA link stability.

SBX-109893 | SBX-1099141

Portfix SBX-109893: The SBC frequently switches over with a coredump after 9.2.1R0 upgrade.

Impact: An SCM core occurred in code that is executed only when the STI feature is enabled.

The core was the result of the code in SipSgStiCopyDisplayNametoCPC() attempting to de-reference a NULL pointer.
The fix is to add a check for NULL before attempting de-reference the pointer.

Root Cause: The root cause is that there is code in an STI specific function that attempted to de-reference a NULL pointer. A NULL pointer check is missing in this code.

Steps to Replicate: Specific steps to reproduce this issue are not known.
The root cause and the fix were found by code inspection and core analysis.

The code is modified to check for NULL before attempting de-reference the pointer.

Workaround: The only known workaround is to disable the STI.

The following Severity 2-3 issues are resolved in this release:

Severity 2-3 Resolved Issues

Issue IDSevProblem DescriptionResolution
SBX-108469 | SBX-1090852

A registration issue with a switchover case.

Impact: Security Mechanism of Registration is set to the TLS in the RCB with two different scenarios. The scenarios are of basic registration, which does not have any security profile.

Root Cause: Cause is when Reconstruction of RCB happens during switchover by default security is set to TLS without verifying Digest structure. Also whenever the Digest structure is deleted for any reason the code is not setting security back to NONE.

Steps to Replicate: Test requires a HA setup.

Scenario 1:

  1. In Active Node make a successful registration. Send a Fake registration such that it gets rejected with 403 error from server side.
  2. Now perform a switchover and when standby node becomes active make another fake registration that gets rejected by 403 again.
  3. Verify the Security Mechanism in CLI using "show status addressContext default sipActiveRegisterNameStatus" and also try to make a call.

Scenario2: (This is for pre-present TLS security before upgrade)

  1. In Active node, make a successful registration with response code other than 200 ex: 202 Accepted. [send 202 instead of 200 in server script]
  2. Now, send a refresh register, it will be internally rejected with 403 from the SBC. In logs, you will see these statements "invalid state auth-rcvd" and "Refresh register did not meet security requirements". If you verify the security Mechanism it should show TLS.
  3. Upgrade the Standby node to 824R2 build. Perform a switchover and send a refresh register to verify the CLI for security mechanism if set to NONE. Try making a call or send a refresh register again both should be successful.

The code is modified so when RCB reconstruction occurs, it verifies the Digest structure whether to set security to TLS or NONE based of the DigestWithoutTLS variable. Whenever the Digest structure is deleted for any reason, the code sets security back to NONE.

Workaround: Try performing switchover twice.


SBX-109083 | SBX-1098202

Portfix SBX-109083: The SCM process core dumps during a SipSgAORHashRemove.

Impact: The SCM Process core dumps due to an entry corruption in the Registration hash table post switchover. This corruption is rare and occurs infrequently.

Root Cause: The result below is likely to core as a result of the core dump and SYS error logs.

The corrupted AOR entry in hash table was allocated during the reconstruction for an Active RCB from standby context after switchover. The SYS Err logs indicate the presence of duplicate AOR entry. This could potential lead to corruption.

Steps to Replicate: 

  1. Run a Basic Registration test with switchover.
  2. Test with application server sending more than one P-Associated URIs.

The code is modified to ensure that only one AOR entry exists in the hash table after a switchover on the Active SBC's cache.

If the AOR entry is not found during remove operation, manually remove the entry to avoid the corruption later.

Workaround: None.

SBX-1079602

The AWS IPs remain assigned to the standby SBC, causing unnecessary dual restarts.

Impact: If the communication between the active and standby is broken (over ha0 interface), both assume active roles (split brain). When this occurs, the standby node that becomes active, calls AWS APIs to move IP address to self. Once ha0 link is restored, the machine, which becomes active, does not call AWS API to move IP addresses, this might cause an issue when the node that has IP does not come up as active, in this case IPs are assigned on standby and another node becomes active.

Root Cause: The root cause of this issue is not calling a AWS switchover API (move IPs) during split brain recovery.

Steps to Replicate: Run a split brain test and recovery of SBC HA, and verify that API query is send by the active SBC after recovery.

The code is modified to call AWS APIs to move IP to current active machine during split brain recovery path.

Workaround: Manually move all secondary IPs to current active machine to restore calls.

SBX-70800 | SBX-1098222

Portfix SBX-70800: Observing that the metaVariable table is getting modified on loading the backup configuration file of one instance in other instance.

Impact: When loading the backup configuration from one SBC instance to another, the metavar table is getting populated with the list of metavars from both instances. This alone does not cause any issues so long as the metavars are unique, its just confusing to see the metavars for another instance in the table.

Root Cause: The code was not removing the existing metavars prior to loading the configuration of another instance. This meant the metavar table had both sets of information.

Steps to Replicate: 

  1. Create a backup configuration of one cloud instance (instance1).
  2. Loaded the backup configuration file into a new cloud instance (instance2).
  3. Check the metaVariables table and see if it contains the metavars from both instances.

The code is modified to flush the metavars for the existing instance prior to loading the configuration from another instance.

Workaround: None.

SBX-109694 | SBX-1098233

Portfix SBX-109694: The /node/actualCeName is not updated with new name when there is a change.

Impact: If a cloud instance is completely rebuilt with a new HA IP value and actualCeName, the new actualCeName is not getting updated into the CDB. The CDB is left with the original actualCeName value. This leads to the SBC being unable to process the new configuration data as it is still trying to read the metavar information based on the original actualCeName value. This in turn leads to the SBC application being unable to start.

This problem happens when the textual part of the actualCeName matches but the IP address is different.

Root Cause: The code was only using the textual part of the name to check if the data in CDB already existed and was not updating the full actualCeName if there was a match on the textual part of the name.

Steps to Replicate: 

  1. Rebuilt a cloud instance using the same node name but new IP address and then try to apply this configuration to an instance that is already up and running with the same node name.
  2. Check that the SBC application is up and running following the application of the new configuration.

The code is modified to correctly update the actualCeName, even if the node name (textual part of the name) already exists in the CDB.

Workaround: None.

SBX-108173 | SBX-1096853

Portfix SBX-108173: The openclovis split-brain recovery data was not always correct.

Impact: On recovery from split brain, a leader may not be properly chosen, and both machines could stay running for multiple minutes.

Root Cause: The data passed to the leader election algorithm does not properly indicate that both nodes are leaders.

Steps to Replicate: Repeatedly break and reconnect the HA connection, checking that the nodes realize they are coming out of split brain (through logs) and one node will properly restart to again become standby.

The code is modified so that the "isLeader" field is properly set and the leader election algorithm can properly detect we are coming out of split brain.

Workaround: None.

Resolved Issues in 09.02.01R001 Release

The following Severity 1 issues are resolved in this release:

Severity 1 Resolved Issues

Issue IDSevProblem DescriptionResolution
SBX-1085571

The SBC continuously core dumps for SCM process since upgrade to V09.02.01R000

Impact: The SCM Process may coredump due to memory corruption.

Root Cause: There is code that is using an invalid pointer when writing to a buffer. This code was only added recently in 9.2.1R0.

Steps to Replicate: This problem is triggered by the receipt of an invalid PDU and/or an SMM rule to reject the incoming Invite and an early ATTEMPT record was attempted to be written. The issue is random and depends on what info is not available when trying to write the accounting record, therefore the issue may not reproduce all the time.

The code is modified to address the issue.

Workaround: If there is SMM rule (ignore/reject the Invite), then the SMM rule needs to be disabled until patch is applied.

SBX-1076901

There was call failures observed on T140 load with various MAJOR logs in DBG.

Impact: Call fails due to RID Enable errors. (where RID = receiver ID and is mapped to an allocated resource)
DBG log shows many BrmAsnycnCmdErrHdlr logs with cmd 0x30 (RID Enable):
MAJOR .BRM: *BrmAsyncCmdErrHdlr: ERROR NpMediaIntf cmd 0x30 gcid 0x2128915e

Root Cause: When RTCP Generation is disabled, RTCP RID for the call is expected to be disabled by Network Processor (NP).

With introduction of SBX-86241 Streaming RTCP packets to Protect Server, there is now a case where RTCP Generation is enabled to stream RTCP packets to Protect Server but RTCP packets are not generated for the call and RTCP RID for the call is not enabled.

When RTCP Generation is disabled NP uses rtcpMode=RTCP Terminate to indicate RTCP RID needs to be disabled.
This is incorrect, since rtcpMode=RTCP Relay Monitor also has RTCP RID enabled and NP is expected to disable the RTCP RID.

If a call has rtcpMode=RTCP Relay Monitor and RTCP Generation is disabled, leak this particular RTCP RID resource.

The next time the particular RTCP RID is allocated, the NP returns an error indicating RTCP RID is already allocated.

Steps to Replicate: 

  1. Enable the Packet Service Profile //Resources/profiles/media/packetServiceProfile/rtcpOptions/generateRtcpForT140IfNotReceivedFromOtherLeg.
  2. On the SBC, set //System/media/mediaRtcpControl/t140RtcpMonitorInterval to 20 seconds.
  3. Start a T140 call but do not send RTCP packet. Terminate the call in 10 seconds.
  4. If you keep making this type of call, you will eventually see the Enable RID error. The DBG log will have the BrmAsynCmdErrHdlr entry.

The code is modified so that the BRM indicates the RTCP RID needs to be disabled or not. When the NP receives the command, it uses this new parameter to decide if RTCP RID should be disabled or not.

Workaround: Disable the RTCP and disable RTCP termination.

SBX-1085161

A call outage led to DSP errors.

Impact: The call fails due to the RID Enable errors.

The DBG log shows many BrmAsnycnCmdErrHdlr logs with cmd 0x30 (RID Enable):
MAJOR .BRM: *BrmAsyncCmdErrHdlr: ERROR NpMediaIntf cmd 0x30 gcid 0x2128915e

Root Cause: 

  1. A defect was found in the XRM redundancy processing code where xres->options field was not updated on the standby XRM.
  2. When modifying a media flow in NP if RTCP relay monitor is being modified, the XRM did not provide rtcpMode in the media flow modify command. And NP is assuming the RTCP relay monitor is enabled by default.

Steps to Replicate: Test with calls that use RTCP terminations and will set rtcp-xr-relay-drop to TRUE.

When processing media flow modify request, the code is modified to set the RTCP relay monitor state based on the value in NP_MEDIA_RTCP_REL_MON_STR.

Workaround: Disable RTCP and RTCP termination in the PSP.

Resolved Issues in 09.02.01R000 Release

The following Severity 1 issue is resolved in this release:

Severity 1 Resolved Issues

Issue IDSevProblem DescriptionResolution
SBX-101155 | SBX-1046201

Portfix SBX-101155: A DSP coredump occurred on the SBC.

Impact: The DSP faults with a memory fault in area that pulls buffers out of EMAC port. Suspicion is on buffer size which is reported by EMAC buffer. These errors result in a DSP reload, which is essentially ensures call continuation. Any calls which are using this DSP could have a small media outage while the DSP is reloaded.

Root Cause: Root cause is a speculation that EMAC system is occasionally is a incorrect bufSize, similar to a bit flip.

Steps to Replicate: This issue cannot be reproduced, it has been fixed based on code review and coredump backtrace analysis.

The code is modified to look for consistency in packet size and EMAC buffer size reported. In case an inconsistency is found, the packet is rejected, avoiding illegal memory access.

Workaround: There is no workaround.

SBX-104334 | SBX-1060561

PortFix SBX-104334: Call Drop when being placed on hold - IPv6.

Impact: The "anonymous.invalid" in IPv6 media is not considered as as a call hold, and is rejected.

Root Cause: There is no handling for "anonymous.invalid" while handling calls on hold.

Steps to Replicate:

  1. Establish a normal IPv6 media call.
  2. Send a reInvite with "anonymous.invalid" in the c line of the media.
  3. Check that the reInvite is not rejected and handled as call hold.

Check for "anonymous.invalid" and if present, consider it as call hold and avoid going for DNS resolution.

Workaround: Use the SMM to modify "anonymous.invalid" to "::" on the incoming side.

SBX-106452 | SBX-1072561

PortFix SBX-106452: The Standby SBC SWe on AWS is not coming up.

Impact: There are hard-coded references to the admin user in SBC LCA code whereby if the admin user is removed, bringing up the SBC may fail on virtual platforms.

Root Cause: The lack of exception handling to account for admin user usage caused the startup process to error out.

Steps to Replicate: Create a new Administrator user from CLI/EMA on the Cloud SBC and delete default admin user.
Reboot the SBC to check if the SBC comes back up as active or standby.

The code is modified to address the issue.

Workaround: Follow the MOP:

1. From Active's CLI: Create another Administrator user (e.g. newadmin)

CLI commands:
set oam localAuth user emsadmin accountRemovalState disabled
set oam localAuth user emsadmin passwordAgingState disabled accountAgingState disabled
set oam localAuth user newadmin group Administrator

2. From the Active's CLI, delete emsadmin user.

CLI commands:
delete oam localAuth user emsadmin

3. From shell of both instances, create admin user:

Shell command:
useradd -p Sonus@123 -G Confd,sftponly,upload,Administrator -s /bin/sh -d /home/sftproot/Administrator/admin admin

4. Reboot the standby instance.

5. Delete the admin user and group from both instances using shell command.

Shell commands:
userdel admin
groupdel admin

6. Login as 'newadmin' user and add 'admin' user

CLI commands:
set oam localAuth user newadmin accountRemovalState disabled
set oam localAuth user newadmin passwordAgingState disabled accountAgingState disabled
set oam localAuth user admin group Administrator
set oam localAuth user admin passwordLoginSupport disabled passwordAgingState disabled accountAgingState disabled accountRemovalState disabled
commit
request oam localAuth userStatus admin setRsaKey keyName adminKey rsaKey "<YOUR-PUBLIC-KEY-HERE>”

Execute the shell command below on both boxes to reset keep admin user value in cdb.

/opt/sonus/sbx/tailf/bin/confd_cmd -o -c "set /SYS:system/admin[0]/sftpUserPassword/keepAdminUser true"

7. Now, the admin user present in /etc/passwd file of both instances.

SBX-105687 | SBX-1061761

PortFix SBX-106175: An SBC 5400 post upgrade to 9.1, the SMM rule for options stopped working.

Impact: The SMM rules were not applied after an upgrade to 9.1.

Root Cause: The logic was modified to pick the same TG for request and response. In the Options ping scenario, request and respond with defaultiptg.

Steps to Replicate: 

  1. Upgrade from 8.1 to any later release.
  2. Attach the SMM at zone.

The code is modified to address the issue.

Workaround: NA

SBX-105961 | SBX-1064801

PortFix SBX-105961: The SBC reInvite with sendonly was causing a one-way audio.

Impact: The SBC unexpectedly sends out a 'reInvite sendonly' when the relay DPM is disabled.

Root Cause: Internal logical error to queue the SDP on ingress when egress send 18x (sendonly).

Steps to Replicate: Enable minimize and disable relay DPM on ingress.
A call B, B answer 183 (sendrecv), 183 (sendonly), 183 (sendrecv)...200 (sendrecv)

The code is modified so when subsequent 183 (sendonly) received on egress, the SBC updates the queue sdp (recvonly). Since the relay DPM is disabled, the SBC does not change the direction of datapath on ingress.

Workaround: n/a. This is an application bug per rfc, and the SDP should not change in subsequent 18x.

SBX-106178 | SBX-1061831

PortFix SBX-106178: There was a switchover // sonusCpSystemProcessCoredumpGeneratedNotification.

Impact: The SCM process has cored.

Root Cause: The SCM has cored when attempting to write a log message because the code is attempting to de-reference a NULL pointer to access information for the log message.

Steps to Replicate: There are no specific steps for reproducing this issue. This core will only occur in a multi-transfer scenario.

The code is modified to check that the pointer is non-NULL before de-referencing it.

Workaround: There is no workaround. This core will only occur in a multi-transfer scenario.

SBX-106611 | SBX-1071131

PortFix SBX-106611: The SBC sends a BYE message within dialog sometimes.

Impact: After a call is connected, if the SBC triggers internal re-INVITE due to minimizeRelayingOfMediaChangesFromOtherCallLegAll flag on one leg and at the same time. If the SBC receives late media re-INVITE on other leg, the SBC clears the call.

Root Cause: The internal offer answer state of call at the SBC SIP subsystem becomes invalid.

Steps to Replicate: Config:
minimizeRelayingOfMediaChangesFromOtherCallLegAll enabled.
lateMediaSupport -->passthrough
E2E Ack Enabled.
Egress PSP crypto and SRTP Enabled.

Call Flow:
Ingress ( RTP ), Egress ( RTP ).

  1. After call is connected, the SBC triggers internal re-INVITE to egress with one crypto.
  2. At the same time , Ingress peer sends late media re-INVITE.
  3. LateMedia will get queued up and processed after internal reinvite.
  4. But as SBC receives 200 OK from egress , it generates 200 OK to ingress as a response to late media re-INVITE from ingress.

This is wrong. The SBC also sends re-INVITE to egress ( late media ).
Due to this internal state gets messed up and after receiving ACK with SDP from Ingress, the SBC clears up the call.

With a fix, verified that the SBC correctly sends 491 Request Pending to ingress when handling internal re-INVITE transaction on egress leg.

When the SBC receives another late media re-INVITE on ingress leg , SBC sends it to egress and this second re-INVITE transaction completes successfully.

The code is modified to ensure if the SBC is handling internal re-INVITE on egress leg, late media re-INVITE on ingress leg is responded with 491 Request Pending with RetyAfter header.

After the egress re-INVITE transaction is completed, if the ingress peer send another late media re-INVITE it is sent to egress leg correctly and offer answer transaction succeeds for this second re-INVITE.

Workaround: Suppress the internal re-INVITE on egress leg.

SBX-106691 | SBX-1069181

PortFix SBX-106691: Adding IPSP fails with the application error.

Impact: Adding IPSP fails with application error when ipSignalingProfile destinationTrunkGroupOptions is includeDtg, but the error message is not descriptive.

Root Cause: ERE validates to ensure the check box 'Include DTG' is not selected in the IP signaling profile. The validation was done guiserver but error message was not set and return for why instead of meaningful error message, a very generic error message was coming.

Steps to Replicate: admin@SBXPLTF1H% set addressContext ADDR_CONTEXT_1 zone ZONE_IAD sipTrunkGroup TG_SIPART_IAD policy signaling ipSignalingProfile AANN
[ok][2021-02-02 19:22:08]

[edit]
admin@SBXPLTF1H% co
Aborted: 'sipServiceGroupExt TG_SIPART_IAD ipSignalingProfile': IP Signaling Profile Id 'AANN' cannot be assigned as it is DTG(Destination TrunkGroup) option is selected.

The code is modified to set the error message and and return to provide error message during configurations.

Workaround: N/A

SBX-106206 | SBX-106710


1

PortFix SBX-106206: An existing hairpin call gets silenced after a switchover.

Impact: A media loopback is not happening in after switchover.

Root Cause: There was extra check performed during NP incoming path for the combination of MAC address and loopback flag.

Steps to Replicate: 

  1. In the SWe SBC Active-Standby HA setup.
  2. Using AS/3GPP call flow scripts/setup establish a call that creates an SBC internal loopback media flow.
  3. Verify the media flow and then issue a switchover.
  4. Verify the media path on this existing active call.

The code is modified to address the loopback media issue and also saves the NP cpu cycles.

Workaround: None.

SBX-106968 | SBX-108087


1

PortFix SBX-106968: There was an abnormal switchover on a cluster SBC.

Impact: The PRS process cored due to accessing NULL destination ICM handle provided by DRM.

Root Cause: The DRM does not mirror txIcm handle in DRES data structure to standby and the code was not validating the pointer in one specific code path. The code intentionally crashed to identify the bad code.

Steps to Replicate: The problem could not be reproduced and the solution was found based on code review. There was Edge case timing issues where internal message sent before a switchover and response is processed after a switchover.

The code is modified to validate the tcIcm pointer that is not null before trying to use it and thereby avoids the intentional system error crash.

Workaround: No workaround

SBX-1067221

The S-SBC application goes down with a the MESSAGE call load of 11 cps or more.

Impact: Run the message call flow with the SMM configured with Dialog Scope variables on ingress and egress sides.

Root Cause: Memory corruption is occuring when we store ingress dialog scope variable id in the Relay CB as it is already freed.

Steps to Replicate: Run the message call flow with SMM configured with Dialog Scope variables on ingress and egress sides.

Run 10 CPS load.

Delaying Relay CB free until we send 200 OK for Message

Workaround: Disable the Ingress dialog Statefull variable for the SMM rules.

SBX-1075861

A SAM Process coredump occurred while executing DoS on an SBC SWe SIP signaling port with a malformed Register Message containing 80 multiple unique and spoofed IPs.

Impact: SIPSG is sending an update to SIPFE for deleting the RCB details with Username, Hostname and PhoneContext as 0 when Register is received with malformed PDU.

Root Cause: In this malformed Register PDU scenario SIPSG should not send a Delete update to SIPFE.

Steps to Replicate: Run a load with Register Malformed PDU from IXia or any test tool.

The code is modified for non zero phone context key in SIPSG for sending delete operation update to the SIPFE.

Workaround: Run in normal mode instead of sensitive mode.

SBX-1057641

A customer Teams core dump occurred in a TEAMS call flow.

Impact: A SCM Process core dump resulted for TEAMS call flow.

Root Cause: Null Pointer exception lead to a SCM Process core dump.

Steps to Replicate: The steps cannot be reproduced.

The code is modified to prevent the crash.

Workaround: None.

SBX-107853


1

The SCM process core dump was observed on the standby SBC while running a load with the SBC generated subscribe.

Impact: The SCm process cores on the standby while running the load for a Reg-Event subscription.

Root Cause: There is a leak on the standby for SIP dialog data structure, which is causing a SYS_ERROR on the standby.

Steps to Replicate:

  1. Enable the below configuration for Reg-Event feature.
    set profiles signaling ipSignalingProfile DEFAULT_SIP commonIpAttributes subscriptionPackageSupport supportRegEvent enable
  2. Run the load of REGISTRATION for Reg-Event subscription feature.

The code is modified to fix the leak of SIP dialog structure on the standby SBC.

Workaround: No workaround

SBX-1060581

Multiple coredumps were observed during a Load run for generated Subscription call Flow tested during Registration Display Enhancement feature.

Impact: Multiple coredumps were observed when Reg-Event Subscription feature flag gets enabled.

Root Cause: Core 1:
Incorrect type cast of a structure led to invalid memory access and core was observed.

Core 2:
During a switchover, the list "pendingCcDsIcmList" was never initialized; however, it was incorrectly getting freed.

Core 3:
Accessing of a NULL pointer led to this core.

Steps to Replicate: Load test for Reg-Event Subscription initiation.

Core 1:
The code is modified to point to valid memory.

Core 2:
In case of a switchover, the code is modified to initialize the list correctly.

Core 3:
Before accessing the pointer, the code is modified to resolve the issue.

Workaround: N/A

SBX-105905 | SBX-106000


1

PortFix SBX-105905: Observed the NP crash during an overload test.

Impact: Possible memory corruption in NP KNI request queue when KNI requests are not processed in time.

Root Cause: An older KNI request buffer in the KNI request queue could be concurrently overwritten by a new request while user-space NP logic is still processing it, leading to memory corruption. This issue is more frequent with Mellanox NICs, particularly with multicast mac programming flow.

Steps to Replicate: Perform an sbxrestart on the SBC with port redundancy enabled, and using a Mellanox-based NIC.

The code is modified to ensure currently handled requests are not overwritten by a new request from the KNI module.

Workaround: None.

SBX-105269 | SBX-107045


1

PortFix SBX-105269: An SBC crash during a call trransfer produced a coredump.

Impact: The SCM Process coredumped due to NULL pointer access for a pointer that was freed due to BYE and HOLD race condition in a transfer call scenario.

Root Cause: There was an illegal memory access, absence of NULL check, and exposed due to race condition.

Steps to Replicate: A calls B, B REFERs to C and now A and C talk. After sometime, A sends BYE and C sends re-INVITE with a=inactive at the same time.

The core is modified to address the issue.

Workaround: None.

SBX-105888 | SBX-1060601

PortFix SBX-105888: The SBC is sending the wrong TO tag to AS side.

Impact: The response 200 OK for Multi Notify has invalid ToTag.

Root Cause: Internal logical error when process the 2nd 200 OK Notify from AS. The application misinterpretation of the direction of the relay message as IAD. And passing down the wrong data down to SIPS for relaying 200 OK to AS.

Steps to Replicate: IAD Subscribe to AS. the AS sends multiple Notify immediately one after another.
The 2nd 200 OK of Notify sends to AS has wrong ToTag.

The code is modified so the correct data passes down to the SIPS.

Workaround: Peer can send 1 Notify at a time. N/A on the SBC.

SBX-108081 | SBX-108199


1

PortFix SBX-108081: Unable to see Video from Cisco 8865/9971 on ConnectMe BYOD client.

Impact: The SBC drops RTCP packets for video stream if audio stream is transcoded by SBC for a multi-stream call.

Root Cause: Non-RTCP binding resource was incorrectly picked by the SBC for video stream if audio is transcoded in a multi-stream call. The reason for picking this resource is, natively the SBC did not support audio transcode for a multi-stream call. As a result, the code assumed audio to be in pass-thru mode.

Steps to Replicate: Configuration:
---------------------

  1. Configure the SBC for Audio,Video Call.
  2. Enable the allowAudioTranscodeForMultiStreamCall in PSP.
  3. Enable the rtcp
  4. Configure thisLeg and otherLeg, so that audio call will be transcoded.


Procedure:
-----------------

  1. Place an Audio transcoded and Video Relay call through the SBC.


Without a Fix:
--------------
The SBC drops RTCP packets for video stream.


With a Fix:
------------
The SBC relays RTCP packets for video stream.

The code is modified to pick the RTCP binding resource for video stream irrespective of audio being pass-through or transcoded.

Workaround: Disable the allowAudioTranscodeForMultiStreamCall flag at Route PSP which would result in Audio pass-through call.

SBX-106329 | SBX-106862


1

PortFix SBX-106329: The SBC disconnects a call every few seconds after recovering a DNS server.

Impact: The SBC disconnects a call every few seconds after recovering a DNS server.

Root Cause: The DNS client sends a failed lookup response to a DNS agent ( SCM ID 03,01 ...) when a probe query fails to get a response for a blacklisted DNS server because a probe query and regular query were used the same FQDN, record type and zone id.

The timeout response for probe query in the DNS client process as triggered DNS failed response towards SCM process.

Steps to Replicate: DNS settings: Three DNS servers are configured. Each weight is set to 50.

DNS#1 10.xxx.x.xxx has RRs with ttl=5
DNS#2 10.xxx.x.xxx has RRs with ttl=0
DNS#3 10.xxx.x.xxx has RRs with ttl=0

<Time series>
DNS#1 10.xxx.x.xxx process was down (Pkt No.29615). DNS#2 and DNS#3 were available.
After few Seconds DNS#2 10.xxx.x.xxx process was down. Only DNS#3 was available.

The code is modified so the DNS probe query does not trigger any response towards a DNS agent from DNS client.

So do not send any failure response to the DNS agent in case of probe query failure.

Workaround: None.

SBX-105439 | SBX-106049


1

PortFix SBX-105439: The SBC does not check if “serverCertName” exists while configuring it as part of the TLS profile.

Impact: The SBC allows the configuration of the certificate, “serverCertName”, as part of the TLS profile even though that certificate is not present in the SBC.

Root Cause: The SBC is not validating that a certificate is present during configuration of “serverCertName” as part of TLS profile.

Steps to Replicate: Verify the SBC does not configure a certificate which is not installed.

Steps to verify issue:

  1. Bring up the instance.
  2. Configure the certificate that is not present in the below path.
    show system security pki certificate.
    set profiles security tlsProfile defaultTlsProfile serverCertName <Name>

Expected result:

The SBC does not allow configuring “serverCertName” as part of the TLS profile.

Steps to verify fix:

  1. Bring up the instance.
  2. Configure certificate that is present in the below path.
    show system security pki certificate.
    set profiles security tlsProfile defaultTlsProfile serverCertName <Name>

Expected result:

The SBC allows configuring “serverCertName” as part of the TLS profile.

The code is modified for the SBC to validate whether a certificate being configured is present or not on the SBC.

Workaround: None.

SBX-106224 | SBX-106481


1

PortFix SBX-106224: An SBC failover with the SCM process core dumps due to memory corruption.

Impact: When Prack is enabled on the ingress and advanced SMM for "variableScopeValue message" is enable, the SBC may core when the egress responds with 18x/2xx in quick succession, and the Prack is still pending.

Root Cause: When 18x/2xx is queuing on the ingress, the SBC did not allocate proper resources for "variableScope" data. By the time the SBC sends the data out, it accesses invalid data.

Steps to Replicate: This is random issue that is not easily reproducible.

  1. Egress: inbound config variableScopeValue message and send to ingress. For example: store "*99" in var1.
  2. Ingress: prack enable, outbound read the var1 and append to the userName of To Header.
  3. Egress: send multiple 18x/200 fast to trigger some delay on ingress for sending.
  4. Run a load.

The code is modified to properly allocate resource for "variableScope" data.

Workaround: Disable prack.

SBX-106476 | SBX-107115


1

PortFix SBX-106476: The ipAdaptiveTaransparencyProfile is not working for a re-INVITE coming from Egress.

Impact: When the sipAdaptiveTransparencyProfile is configured for Egress TG and re-INVITE comes from egress peer with change in P-ASSERTED-ID, the SBC does not relay the invite from egress to ingress.

Root Cause: The SBC code does not set service bit for reINVITE transparency for re-INVITEs coming from egress peer.

Steps to Replicate: Test case 1.

Configure the sipAdaptiveTransparencyProfile for Egress TG for re-INVITE.

config
set profiles services sipAdaptiveTransparencyProfile ADP2 sipMethod INVITE triggerHeader P-ASSERTED-ID action new-value trigger value-change
set profiles services sipAdaptiveTransparencyProfile ADP2 state enabled
set addressContext ADDR_CONTEXT_1 zone ZONE4 sipTrunkGroup SBXSUS7_LABSIP2 services sipAdaptiveTransparencyProfile ADP2
commit

When egress sends a re-INVITE with modified PAI after call is connected, no re-INVITE is generated towards the ingress side.


Test case 2

Verify the issue.

With a fix, the re-INVITE is relayed to ingress for both late and early media cases.

The code is modified to ensure the SBC sets the service bit for egress properly when the sipAdaptiveTransparencyProfile is configured for egress TG.

Workaround: None.

SBX-106920 | SBX-107730


1

PortFix SBX-106920: The FmMasterProcess dumped core after a switchover with stable call.

Impact: The FmMasterProcess core dumps during shutdown.

Root Cause: The FmMasterProcess may deadlock during shutdown due to receiving an event while trying to shutdown/finalize the event handling.

Steps to Replicate: This is extremely time-sensitive and requires publishing an event from AMF to FM at just the right time in the shutdown sequence. There is no way to consciously reproduce the issue.

The code is modified to avoid the possibility of the deadlock.

Workaround: No workaround.

SBX-107041 | SBX-107802


1

PortFix SBX-107041: The OAM and MRFP goes down due to component error time reset for SsreqProcess,SLwredProcess, and when the FmMasterProcess is going down.

Impact: The OAM and MRFP goes down due to component error time reset.

Root Cause: The NTP is not synced before the SBC comes up. As a result, when the sync occurs after the SBC comes up and the new time is older than the current time, the SBC goes down.

Steps to Replicate: 

  1. Launch the SBC with a time zone and the NTP in sbx.conf.
  2. Check if the NTP server was properly synced and there was no issue of "time getting reset to past" in the SBC logs.

Run NTP sync operations before starting serf to avoid any issue when the time sync occurs and time gets reset to past.

Workaround: No workaround.

SBX-106732


1

The CE_Node1.log is filling up quickly.

Impact: The CE_Node1.log file size grows to an excessive size cauing a hard disk space alarm.

Root Cause: An excessive number of log prints were coming from stack trace dumps on a SYS_ERR (EVLOG).

Steps to Replicate: Run a suite of REFER call scenarios and see that NrmaCpcCallVerifyTimerFunc is not being written in CE_Node log.

Converted the SYS_ERR( EVLOG ) event for the concerned log event to NrmaDlog, so the CE_Node.log file no longer contains the back trace.

Workaround: echo > CE_Node.log when it grows too big.

SBX-107439


1

The SWe_NP - KNI was out of memory

Impact: On the Azure platform with Mellanox ConnectX-3 accelerated NICs, the packet port interfaces may lose connectivity.

Root Cause: The buffer pool associated with Packet interfaces was getting exhausted due to lazy free logic in DPDK's driver for Mellanox ConnectX-3 NIC.

Steps to Replicate: Route few calls to the same packet interface as incoming and some calls to the other packet interface.

The code is modified in order to alleviate stress on the buffer pool.

Workaround: None.

SBX-1073971

After an SBC switchover, a DEADLOCK was detected for sysID 62, task SIPSG.

Impact: The SIP call load can trigger healthcheck timeout in SIPSG module.

Root Cause: The problem was with the flags that is used for creation of shared memory between SCM process and Fault Avalanche handler process. As a result of incorrect setting of flags, some of the writes to the shared memory was taking more time resulting in the SCM thread getting blocked and health check timeout.

Steps to Replicate: 

  1. Run a 50 cps SIP-SIP call load for an extended period of time.
  2. Make sure that the fault avalanche control feature is turned on.
    "show system faultAvalancheControl facState" should be enabled.

The code is modified to disable Fault Avalanche control functionality by default.

WorkaroundDisable the Fault Avalance control functionality using the following configuration control:

set system faultAvalancheControl facState disabled

The following Severity 2-3 issues are resolved in this release:

Severity 2-3 Resolved Issues

Issue IDSevProblem DescriptionResolution
SBX-106815 | SBX-107963


2

PortFix SBX-106815: The PES process was leaking memory.

Impact: In certain circumstance with high enough call rate, the SBC may experience PES memory leak.

Root Cause: The newly ported Postgres code mishandled Postgres DATABASE cursor and counter.

Steps to Replicate: This problem has been fund and reproduced in lab, when they were testing their call load.

The colde is modified in cursor and counter area.

Workaround: Lower call rate should lower the risk.

SBX-107593 | SBX-107595


2

PortFix SBX-107593: There is DTLS support for version 1.2.

Impact: The SBC did not support DTLS clients which only supported DTLS version 1.2 to connect.

Root Cause: The SBC was hardcoded to only support DTLS version 1.0.

Steps to Replicate: Make a call from the DTLS client that only supports DTLS version 1.2 and check that the SBC is able to establish the call.

The code is modified to allow support for up to DTLS version 1.2.

Workaround: None.

SBX-105483 | SBX-105739


2

PortFix SBX-105483: There was a malformed P-charging vector.

Impact: P-Charging-Vector was not passed transparently to egress on SIP-I to SIP call, when Create P-Charging-Vector is selected on egress IP profile and Store P-Charging vector is selected on ingress IP profile.

Root Cause: The SIP-I INVITE contains IAM with a bad parameter and no parameter compatibility, causing the SBC to send 183 with CFN message and not transit the P-Charging-Vector.

Steps to Replicate: 

  1. Make SIP-I to SIP call.
  2. SIP-I IAM contains an unrecognized parameter with no parameter compatibility information.
  3. Ingress IP profile has Store P-Charging-Vector.
  4. Egress IP profile has Create P-Charging-Vector.

Correct code to ensure P-Charging-Vector is passed to egress in this case

Workaround: Disable support for the CFN message in ISUP signaling profile.

SBX-105674 | SBX-105892



2

PortFix SBX-105674: Turk Telecom coverity issues part2.

Impact: While processing SUBSCRIBE messages the coverity tool has highlighted that the code could dereference a pointer that is potentially null. Although no bad behaviour has been observed during testing there is a small chance that it could result in coredumps if the pointer really was null.

Root Cause: Based on other validation in the code coverity highlighted that some legs of code could result in accessing a pointer that might be null. Derefencing null pointers can cause unexpected behaviour and in the worst case coredumps.

Steps to Replicate: Run various SUBSCRIBE related test cases.

The code is modified to validate that the pointer is not null before using it to avoid any potential issues/coredumps.

Workaround: None.

SBX-105497 | SBX-107250



2

PortFix SBX-105497: The wrong format of the SIP 400 BAD REQUEST.

Impact: When the SBC received a message that is unable to find the required headers, the SBC responses 400 with syntax errors itself.

Root Cause: The peer intentional sending garbage message.

Steps to Replicate: Incoming request with have required headers as part of content body section.

The code is modified so the SBC discards the message.

Workaround: Use the SMM to drop the message.

SBX-102277 | SBX-106516



2

PortFix SBX-102277: The debug command caused ScmP to coredump

Impact: We are hitting a Healthcheck timeout when displaying the output of the following debug command:
"request sbx sipsg debug command "svcgrp -ce 0 -scm <x> -1""

Root Cause: The Heathcheck timeout is because it is taking too long to display the data for all of the service groups when there are very large number of trunk groups configured.

Steps to Replicate: 

  1. Configure the 1000 TGs
  2. Issue the following command:
    "request sbx sipsg debug command "svcgrp -ce 0 -scm <x> -1""

The code is modified to only display up to 50 service groups in order to prevent this Healthcheck timeout.

Workaround: To prevent this issue: Avoid using the following command if there are large number of TGs configured:
"request sbx sipsg debug command "svcgrp -ce 0 -scm <x> -1""

SBX-105160 | SBX-107902


2

PortFix SBX-105160: There was a CHM process coredump on standby OAM after reboot.

Impact: The SBC application continues to come up even when asp.py zap (zapAsp() call in sbxCleanup.sh) is invoked from sbxCleanup.sh script. When we try to access ceNum in one of the places, since it is not properly set due to failure in sbxCleanup.sh, it results in CHM coredump

Root Cause: The SBC application continues to come up even when asp zap is called.

Steps to Replicate: Fail sbxcleanup in one of the places and ensure the SBC in not being brought up.

The code is modified to avoid the SBC bring up if any errors are reported in sbxCleanup.

Workaround: The issue is fixed, no workaround is required.

CHOR-7376 | SBX-107023


2

PortFix CHOR-7376: There was a Swe_UxPad coredump observed during Teams Testing.

Impact: The SWe_UXPAD process crashes due to the health check failure in extra-low memory SWe configuration on Microsoft Azure with presence of outgoing STUND/DTLS traffic.

Root Cause: The root cause was identified to exhaustion of an internal buffer pool during the presence of STUN/DTLS traffic.

Steps to Replicate: Launch a 6GB SWe instance in Azure using accelerated NIC. Run a Teams test suite for multiple iterations which would trigger STUN/DTLS traffic to go out from SWe.

The code is modified to adjust the internal buffer pool size in order to account for additional requirements of STUN/DTLS traffic.

Workaround: No workaround.

SBX-107420 | SBX-107880


2

PortFix SBX-107420: Failed to download the Call Diagnostics file.

Impact: Unable to download a large size call diagnostics log file.

Root Cause: When we tried to download a large size call diagnostics log file. It was failing with JAVA heap error because IOUtils toByteArray API was created internally ByteArrayStream to store file data into byte format. Due to java memory restriction, we were getting a Heap error from ByteArrayStream.

Steps to Replicate: Steps to reproduce the issue:

  1. Login into EMA.
  2. Troubleshooting > Troubleshooting Tools > Call Diagnostics.
  3. Click on Save Call Diagnostics button to generate the log file.
  4. Go to the Call Diagnostics Data Files section and try to download the tar file.
  5. If the file size is more than 400MB, it should get failed with a proxy error.

The code is modified to internally copies the data from inputStream into OutputStream.

Workaround: NA

SBX-105290 | SBX-108092


2

PortFix SBX-105290: The SBC CDR: Redirecting digits captured incorrectly.

Impact: The redirecting number recorded in the CDR was not correct if the first policy dip route was used for the call but there was an updated redirecting number from a later route in the policy dip.

Root Cause: The code was incorrectly using the last per route redirecting number from the policy response to overwrite the redirecting number from the received INVITE message and using this to populated the redirection information field in the CDR record.

Steps to Replicate: Configure the PSX routing label with two different route with two different ingress trunkgroups, and in each trunk add a DM rule for RDN. Now, make a call check what is the RDN from the CDR logs. If the call gets success with route 1 then it should have RDN according to DM rule in route1.

The variations in tests:

Test1 => route1 has DM/PM rule to remove CC in RDN and OCN, route 2 has DM/PM rule to modify RDN and OCN. CALL SUCCESS with Route1

TEST2 => route1 has DM/PM rule to remove CC in OCN No rule for RDN, route 2 has DM/PM rule to modify RDN and OCN. CALL SUCCESS with Route1

TEST3 => route1 has DM/PM rule to remove CC in RDN No rule for OCN, route 2 has DM/PM rule to modify RDN and OCN. CALL SUCCESS with Route1

The code is modified to populate the CDR using the per route redirecting number digits or the contain received from the INVITE.

Workaround: Not Applicable.

SBX-105901 | SBX-106712


2

PortFix SBX-105901: There is a heap-buffer-overflow in the ASAN build for SIPS module.

Impact: Observing the heap buffer overflow in SCM process for info level log while decrypting the ROUTE header. Reading memory beyond the end of the allocated buffer can result in memory access faults and coredumps.

Root Cause: A heap overflow occurs because the debug statement is trying to print from a string variable that is not null terminated.

Steps to Replicate: Execute a test case where INVITE message contains encrypted route-header and verify that there are no failures.

The code is modified to create a local variable of type character array, which gets dynamically created and is always null terminated. This variable is used in the info log.

Workaround: Not Applicable.

SBX-103183 | SBX-106171


2

PortFix SBX-103183: The SBC incorrectly formatted the rport in the VIA header.

Impact: The SBC incorrectly formats the rport value in the header of the response message when rport has a valid port number and is at the end of VIA header of request message.

Root Cause: The code does not verify that rport has a valid port number. If rport is the last parameter in VIA header, the SBC appends "=<source port>".

Steps to Replicate: 

  1. Setup: SIPp - SBX - SIPp
  2. Send Register message with "rport=1111" in VIA header from client SIPp script with to the SBC. "rport" is at the end of VIA header
  3. Run the client script with -p 30333
  4. Verify that the SBC replaces rport port number (1111) with its own rport (30333) in VIA header of 200 OK response.


The code is modified so that it checks for any port number in rport parameter (rport is at the end of through the header of request message), it replaces the port number and appends it's own rport.

Workaround: Use the following SMM as a workaround:

set profiles signaling sipAdaptorProfile HeaderModifications rule 1 applyMatchHeader one

set profiles signaling sipAdaptorProfile HeaderModifications rule 1 criterion 1 type message message messageTypes response statusCode 200

set profiles signaling sipAdaptorProfile HeaderModifications rule 1 criterion 2 type header header name Via condition exist

set profiles signaling sipAdaptorProfile HeaderModifications rule 1 action 1 type header operation store

set profiles signaling sipAdaptorProfile HeaderModifications rule 1 action 1 headerInfo headerValue

set profiles signaling sipAdaptorProfile HeaderModifications rule 1 action 1 from type header value Via

set profiles signaling sipAdaptorProfile HeaderModifications rule 1 action 1 to type variable variableValue var4

set profiles signaling sipAdaptorProfile HeaderModifications rule 1 action 2 type variable operation regsub

set profiles signaling sipAdaptorProfile HeaderModifications rule 1 action 2 from type value value "rport="

set profiles signaling sipAdaptorProfile HeaderModifications rule 1 action 2 to type variable variableValue var4

set profiles signaling sipAdaptorProfile HeaderModifications rule 1 action 2 regexp string "rport=[0-9]*=" matchInstance one

set profiles signaling sipAdaptorProfile HeaderModifications rule 1 action 3 type header headerInfo headerValue

set profiles signaling sipAdaptorProfile HeaderModifications rule 1 action 3 operation modify

set profiles signaling sipAdaptorProfile HeaderModifications rule 1 action 3 from type variable variableValue var4

set profiles signaling sipAdaptorProfile HeaderModifications rule 1 action 3 to type header value Via

SBX-104975 | SBX-106101


2

PortFix SBX-104975: The MCF id sent back to the ingress as MPS during T.38 Fax to G.711 transmission.

Impact: Some fax T.38 endpoints send an entire DCS V.21 signal in one packet as opposed to 1 octet per packet. This can causes fax failures.

Root Cause: A burst of octets in a single packet is essentially a burst, and causes potential problems as these packets get queued for modulation and cause delay and later TCF (high speed) signal some packets get dropped.

Steps to Replicate: Refer to unit test description in the JIRA.

The code is modified to accommodate such larger bursts.

Workaround: This bug is a specific interoperability problem with such endpoints which exhibit burst single packet DCS signals. For such endpoints, a workaround is not available unless some configurations are available on those devices to modify this behavior.

SBX-106269 | SBX-106800


2

PortFix SBX-106269: RTT-TTY uppercase behavior is inconsistent.

Impact: Sometimes ASCII letters received in a T140 packet are sent as numbers and figures characters on g711 baudot side.

Root Cause: Baudot has two modes - LTRS mode and FIGS mode. After transmitting 72 characters continuously in one mode, the recommendation requires to repeat LTRS or FIGS baudot tone to reassert the current mode.

LTRS and FIGS mode have some common baudot codes such as 0 (BKSP),2(LF), 4(SPACE) and 8 (CR). There is no need to change mode when any of these common characters need to be transmitted.

The issue is that when in LTRS mode 72nd character is received as one of common characters mentioned above, then the SBC incorrectly sends FIGS mode baudot tone. As a result, all subsequent LTRS characters are interpreted as FIGS and show incorrectly on screen of receiving phone

Steps to Replicate: Create a t140 pcap with characters in each packet (per line) such as this. Note there is LF character after each line.

AAAAAAAA
BBBBBBBB
CCCCCCCC
DDDDDDDD
EEEEEEEE
FFFFFFFF
GGGGGGGG
HHHHHHHH
00000000
11111111
BBBBBBBB
CCCCCCCC
DDDDDDDD
EEEEEEEE
FFFFFFFF
GGGGGGGG
HHHHHHHH
IIIIIIII
AAAAAAAA
BBBBBBBB
CCCCCCCC
DDDDDDDD
EEEEEEEE
FFFFFFFF
GGGGGGGG
HHHHHHHH
IIIIIIII
AAAAAAAA
BBBBBBBB
CCCCCCCC
DDDDDDDD
EEEEEEEE
FFFFFFFF
GGGGGGGG
HHHHHHHH
IIIIIIII

Before the fix, the following appeared on g711 baudot side:
AAAAAAAA
BBBBBBBB
CCCCCCCC
DDDDDDDD
EEEEEEEE
FFFFFFFF
GGGGGGGG
HHHHHHHH
00000000
11111111
BBBBBBBB
CCCCCCCC
DDDDDDDD
EEEEEEEE
FFFFFFFF
GGGGGGGG
HHHHHHHH
IIIIIIII
--------
????????
::::::::
$$$$$$$$
33333333
!!!!!!!!
++++++++
========
88888888
--------
????????
::::::::
$$$$$$$$
33333333
!!!!!!!!
++++++++
========
88888888


After fix the T140 characters are displayed correctly.

After 72 characters of same mode (LTRS or FIGS) the stack sends LTRS/FIGS baudot code. If 72nd characters is common code such as BKSP, SPACE, CR or LF and the if previous mode was LTRS, stack sends FIGS baudot tone.

Fix to check current LTRS/FIGSmode and send the LTRS/FIGS baudot code.

Workaround: There is no workaround as such.

SBX-106822 | SBX-107399


2

PortFix SBX-106822: There was a crash observed in Four GPU Codec Scenario.

Impact: The G.729AB GPU codec may crash when packets are lost in the incoming G.729AB stream which, in turn, leads to SWe_UXPAD crash and an SBC application restart.

Root Cause: An uninitialized stack variable in GPU G.729AB decoder code was identified as the root cause.

Steps to Replicate: 

  1. Set sweActiveProfile to use GPU, and sweCodecMixProfile to use G.729.
  2. Make a G.729AB to G.711U call, and don't send the media.
    RESULT: SWe_UXPAD may crash and the SBC application restarts.

NOTE: The issue is not always reproducible.

The code is modified to initialize the stack variable appropriately.

Workaround: No workaround.

SBX-105413 | SBX-105956


2

PortFix SBX-105413: Support for 3072-bit long RSA keys is missing.

Impact: The SBC needs to support 3072-bit RSA keys in certificates.

Root Cause: A feature change is required to support 3072-bit RSA keys in certificates in addition to 2048-bit and 4096-bit RSA keys.

Steps to Replicate: 

  1. Test 3072-bit RSA key certificate on client. Make SIP-TLS call from the client to the SBC acting as TLS server.
  2. Configure remote certificates with 3072-bit RSA key.
  3. Configure local certificates with 3072-bit RSA key.
  4. Test 3072-bit RSA key certificate on SBC acting as SIP-TLS server.

The code is modified to provide support for 3072-bit RSA keys in certificates.

Workaround: None.

SBX-106149 | SBX-106641


2

PortFix SBX-106149: The PSP QoS non-zero value of msrpDscp cause PES to crash.

Impact: The PES process crashes when apps starting up if msrpDscp in PSP QoS values configured with non-zero.

Root Cause: A debug statement tried to print a integer as a string, causing memory problem.

Steps to Replicate: 

  1. Configure the non-zero msrpDscp value.
  2. Restart the SBC.

Before the code change, the PES will crash.

After the code change, the PES will not crash.

The code is modified to print integer as integer.

Workaround: Do not configure a non zero msrpDscp.

SBX-107348 | SBX-107360


2

PortFix SBX-107348: The SIP LM call re-Invite sent in the 18x-PRACK stage on ingress.

Impact: The SBC sends a reInvite to the late media while the call is still in prack pending state.

Root Cause: Logical error that fail to detect the state of call not connect yet and the SBC tries to send the reInvite out.

Steps to Replicate: 

  1. Configure the LRBT.
  2. Incoming late media with prack support.
  3. Egress 180 trigger play tone, 180 again again, and 200 OK(sdp).
  4. Ingress delay sending prack for 5secs.

The code is modified to  validate the state of the call before reInvite out.

Workaround: Disable prack or disable LRBT.

SBX-104113 | SBX-105070


2

PortFix SBX-104113: The mediationServer signaling channel was online even interface went down.

Impact: Without this fix, the LI - mediationServer signaling channel stays online even after ipInterfacegroup attached to call data channel(CDC) is disabled post a switch-over.

Root Cause: The SBC code, handling the LI - mediation server signalling socket functionality did not register for ipInterfaceGroup operational status in standby mode.
As a result, post switch-over it does not get any notification when ipInterfaceGroup attached to CDC toggles. The signaling connection towards mediation server is not closed.

Steps to Replicate: 

  1. Create CDC and configure it for IMSLI and validate that the LI signaling channel is inService.
  2. Perform a switch-over.
  3. Disable the ipInterfaceGroup attached to the CDC.

The code is modified to register for the ipInterfaceGroup that is attached in CDC in standby mode as well so that if and once it becomes active due to switch-over it would get operational status of the ipInterfaceGroup attached to CDC.

Workaround: N/A

SBX-105711 | SBX-105924


2

PortFix SBX-105711: There was a ASAN MRFP: CE_2N_Comp_CpxAppProc leak during disable and enable of pkt port

Impact: Creating an H248 signaling port results in a small memory leak.

Root Cause: While processing the H248 signaling port creation command when metavars are defined for the IP value, the SBC allocated memory to hold the metavar value from CDB internally for processing, but never freed up this memory block at the end of the port creation action resulting in a small leak.

Steps to Replicate: Create an MRFP instance where metavars are used to define the IP value for the H248 signaling port.

The code is modified to correctly free the memory block at the end of processing the signaling port creation.

Workaround: None.

SBX-103306 | SBX-107647


2

PortFix SBX-103306: Allocated bandwidth for opus call is 1032kb and 1028kb for single call.

Impact: If "transcoderFreeTransparency(TFT)" is enabled at Route PSP, then extra bandwidth is allocated for opus call in case maxaveragebitrate attribute is not received in SDP from the endpoints.

Root Cause: If maxaveragebitrate is not received in SDP, then the SBC was using the max value of 510kbps as the default value (which was not as per RFC). Later, this bitrate value gets intersected with Route PSP configured value. However, for TFT calls, this intersection with route PSP does not happen. As a result, the SBC continues to maintain this value as 510kpbs, which results in extra bandwidth allocation.

Steps to Replicate: Configuration:

  1. set profiles media packetServiceProfile DEFAULT packetToPacketControl transcode transcoderFreeTransparency
  2. set profiles media packetServiceProfile DEFAULT secureRtpRtcp flags enableSrtp enable allowFallback enable (Ingress)

To re-create the issue:

  1. UAC sends INVITE with OPUS codec and SDP does not contain "maxaveragebitrate" attribute.
  2. Since "maxaveragebitrate" is not received from UAC, the SBC defaults to max value of 510kbps and sends the same to UAS.
  3. UAS responds 200 OK with OPUS codec and SDP does not contain "maxaveragebitrate".
  4. The SBC sends out 200 OK with maxaveragebitrate=510kbps to UAC.

Test Result without a fix:

Since maxaveragebitrate defaults to 510kbs, the SBC ends up allocating more bandwidth than expected.

If "maxaveragebitrate" is not received in SDP, then derive the default value according to RFC using "maxPlayBackRate" and mode(mono/stereo).

Workaround: None.

SBX-107611 | SBX-107612


3

PortFix SBX-107611: The AMRWB bit-exactness problem in case of mixed mode test.

Impact: Degraded audio in AMRWB stream when AMRWB (GPU) call load is running, particularly when each call uses different mode.

Root Cause: Root cause was identified to an issue with context rearrangement code of GPU AMRWB codec.

Steps to Replicate: 

  1. Set sweActiveProfile to use GPU and sweCodecMixProfile to use AMRWB.
  2. Make AMRWB to G711U call load using multiple AMRWB clients, each client using different mode.

    RESULT:
    Some of the calls may have degraded audio in AMRWB stream.

The code is modified to address the issue.

Workaround: No workaround.

SBX-107924 | SBX-107931


2

PortFix SBX-107924: The OAM services are not coming up with 6GB Ram with network interface mapping error.

Impact: The SWe_NP process fails to come up in a 6GB OAM instance configured with only 2 interfaces (ha0 and mgt0).

Root Cause: Lack of sufficient huge pages in this particular scenario causes SWe_NP initialization failure.

Steps to Replicate: Bring up a OAM node with 6GB RAM instance and configure two interfaces (without any pkt interfaces). The OAM instance would fail to come up.

The code is modified to reserve enough huge pages required for SWe_NP.

Workaround: Configure OAM instance with >= 16GB.

This is the officially supported configuration for OAM instance.

SBX-60855 | SBX-106922


2

PortFix SBX-60855: The OPTIMA FTTH Stat for TG-A and TG-C Stat mismatching.

Impact: The active register count on ingress TG is not decremented when a bad refresh REGISTER is received. Due to this there is difference in count of total stable registrations across zones.

Root Cause: When the load of bad Refresh or initial REGISTERs received, at SBC for some of the registers not getting userNPhoneContextKey due to this the code that is responsible for reducing activeRegCount is not executed.

Steps to Replicate: 

  1. First make one active Registration.
  2. After active registration send one bad refresh REGISTER.

Expected Result:

After bad refresh REGISTER, the SBC sends 400 Bad to Refresh REGISTER and also reduces the activeRegCount on ingress Side but it will not reduce count on egress side,

The code is modified to address the issue. 

Workaround: None.

SBX-102700 | SBX-106306


2

PortFix SBX-102700: The number mapping (translated, RDI, To hdr, R-URI) is unexpected.

Impact: The SBC is not adding translated number received from PSX to RequestURI when Diversion header is present in the ingress Invite.

Root Cause: If the ingress Invite does not contain Diversion header, then the SBC is adding translated number to RURI. So same result is expected when diversion header is present.

Steps to Replicate: 

  1. Make a SIP call by sending an Invite with Diversion header from UAC.
  2. Configure PSX to return "translated number" for the called party number in policy response.
  3. The SBC includes the translated number in Request URI and routes the call.

The fix is to populate the RequestURI with the translated number even when the Diversion header is present in the initial Invite.

Workaround: None.

SBX-104507 | SBX-106552


2

PortFix SBX-104507: The SBC is not passing URI parameter while History to Diversion interworking

Impact: The SBC is not passing URI parameter "user=phone" while interworking History-Info header to Diversion header.

Root Cause: The SBC was not adding "user=phone" during interworking History-Info header to Diversion header for the SIP uri.

Steps to Replicate: 

  1. On the ingress leg, enable acceptHistoryInfo.
  2. On the egress leg, enable diversionHistoryInfoInterworking.
  3. Run a basic call with History-Info header having SIP uri and "user=phone" parameter.

The code is modified to add "user=phone" during interworking History-Info header to Diversion header for the SIP uri.

Workaround: None.

SBX-106042 | SBX-108135


2

PortFix SBX-106042: The RCB(s) can be hijacked and effect on registered users/EPs.

Impact: Issue 1: When the register is sent to the registrar, the SBC creates a RCB for that particular User. When a fake/hijacked register is rejected with 403, some of the parameters in RCB are being modified and users were unable to make a call due to security mechanism being set to TLS.

Issue 2: If a timeout on the RCB leads to it moving to a terminated state and a refresh register arrives, subsequent calls are rejected.

Root Cause: Issue 1: When a Register request is rejected with a 403, it moves to the terminated state. Also, when a register is received, the RCB details are modified irrespective fo the response received from the registrar.

Note: A register is considered fake when we receive a 403 response for that.

Issue 2: When the RCB was moved to the terminated state, the code was partially deleting internal memory that led to reporting the RCB mechanism as TLS, and not rejecting the TLS calls.

Steps to Replicate: Use the conas mentioned in the description and use the config file attached for reference:

  1. After config make a successful registration, later make a register so that it gets rejected with 403 error.
  2. Verify the parameters in RCB using this command:
    show status addressContext default sipActiveRegisterNameStatus
  3. Check for all the displayed parameters and also check for sipSigPort and other essential parameters in Debug logs.

The code is modified for:

  1. When we receive a fake register and 403 response the RCB should remain in previous state with the previous information. The RCB contents are backed up so they can be restored on failure.
  2. Remove the security mechanism of TLS when the RCB is in terminated state.

Workaround: No Workaround.

SBX-102726 | SBX-106883


2

PortFix SBX-102726: The Diameter RX had the wrong data in media-component AVP post T.38-488.

Impact: Sending the wrong data in media-component AVP (codec-data) when T.38 failback fails.

Root Cause: Instead of sending last negotiated codec, the SBC was sending previous offer-answer data in the media-component AVP of AAR message.

Steps to Replicate: 

  1. Configure PSPs for faxfallback and enable Rx feature.
  2. Run transcode call (A(PCMA) and B(PCMU)).
  3. The B sends fax tone, on detecting fax tone the SBC sends T.38 Re-INVITE towards A and A rejects with 488.
  4. When a fallback happens, the SBC sends G711 Re-INVITE towards A and gets 200 OK. On getting 200 OK. The SBC sends final AAR that should contain last negotiated SDP information.

The code is modified to address the issue.

Workaround: Not Applicable.

SBX-105450 | SBX-106573


2

PortFix SBX-105450: A failure to delete remote server configured with FQDN for multiple commits.

Impact: Failure to delete remote server configured with FQDN for multiple commits.

Root Cause: The confd iter stops on returning failure for not finding any child remote servers for the first remote server and we fail to process the delete request for the second remote server that leaves the child remote servers of the second remote server as is.

Steps to Replicate: 

  1. Configure multiple FQDN remote servers such that first server fails to resolve FQDN and the second server creates child remote servers.
  2. Disable both the remote servers.
  3. Delete the first remote server and then the second in a single commit.
  4. The remote servers created by second remote server fails to delete.

Return success from delete remote server function so that next CDB operation is processed. Failure to find a server is anyways logged and is not shown on the CLI as an error.

Workaround: Delete the remote servers in separate commits.

SBX-106913 | SBX-107027


2

PortFix SBX-106913: There was a SCM process coredump for register with timeout from Application server with no response.

Impact: The coredump observed when the SBC logs account info incase of register timeout.

Root Cause: There was a NULL check miss in the code so coredump observed when we try to access account information.

Steps to Replicate: 

  1. Send a REGISTER from UAC, the SBC sends towards AS.
  2. The AS sends 302 to REGISTER.
  3. The SBC sends redirected REGISTER to next AS and tries for 5 times since there is reply from AS.

The code is modified to address the issue.

Workaround: Not applicable.

SBX-105050 | SBX-105675


2

PortFix SBX-105050: The SBC DRBD mount not visible on active the SBC.

Impact: The SBC DRBD mount was not visible on the active SBC.

Root Cause: When the sbxrestart is issued from platform manager, DRBD gets mounted on apache's mountspace.

Steps to Replicate: 

  1. Bring up both the nodes.
  2. Do an SBC restart from pm on active.
  3. The new active must have drbd mounted.

Modify the apache service file and set the resposible parameter (PrivateTmp) to false.

Workaround: None.

SBX-105736 | SBX-106560


2

PortFix SBX-105736: Sending the m=application 0 UDP/BFCP (null) in case of UPDATE.

Impact: The SBC sends m=application line in incorrect format in SIP UPDATE message.

Root Cause: The SBC does not format m=application line for UDP/BFCP when sending UPDATE message.

Steps to Replicate: Test case

1. Reproduce the issue.

The SBC sends a INVITE with SDP(with audio and video lines and m=application) and receives rel 18x with SDP(with audio and video lines only) followed by final 200 OK with SDP (with audio and video lines and m=application) if flag is enabled then SDP of 200 OK should be ignored by the SBC.

UPDATE message content: m=application 0 UDP/BFCP (null).

2. Verify the issue. Repeat step 1. 

UPDATE message content: m=application 0 UDP/BFCP *

The code is modified to ensure the SBC sends m=application line in correct format.

Workaround: None.

SBX-104851 | SBX-105142


2

PortFix SBX-104851: The SBCb is down and the standby registration with active failed, error 160004.

Impact: The standby is not allowed to join cluster and fails to start

Root Cause: The safplus checkpoint file is corrupt and the section needing to be overwritten is not found.

Steps to Replicate: The root cause of the checkpoint corruption is unknown/cherckpoint corruption cannot be forced and therefore, directly testing this fix is not possible.

The code is modified to re-add the missing section if it is not found.

Workaround: A complete outage is required as the active must be restarted.

SBX-102469 | SBX-106294


2

PortFix SBX-102469: Time zone is defaulting to EST/EDT on the SBC instances while using image based instantiation.

Impact: Time zone is defaulting to EST/EDT on the SBC instances while using image based instantiation because the timezone details passed during launch are not being applied when the SBC is brought up.

Root Cause: The timezone details passed during launch are not being applied when the SBC is brought up.

Steps to Replicate: Launch the SBC on the SWE. Provide values for timezone and NTP in sbx.conf. Check if proper timezone values and NTP configuration is applied on launch.

The code is modified to update timezone with value in sbx.conf.

Workaround: No workaround other than setting timezone manually in cli.

SBX-106231 | SBX-107398


3

PortFix SBX-106231: The Metallic noise present in the stream coming out from G722 side.

Impact: Metallic noise in G722 stream when GPU G722 to Narrow band codec call is made.

Root Cause: Resampled output is incorrectly copied in GPU G722 Encoder upsampling (narrowband to wideband) code.

Steps to Replicate: 

  1. Set sweActiveProfile to use GPU and sweCodecMixProfile to use G722.
  2. Make G722 to G711U call.

RESULT:
G722 stream contains metallic noise.

The code is modified to properly copy the resampled output.

Workaround: No workaround.

SBX-106343 | SBX-107400


2

PortFix SBX-106343: The GPU EVRCB decoder asserts in Erasure frames simulation test.

Impact:The GPU EVRCB decoder may crash when there are lost packets in the incoming EVRCB stream, which in turn leads to SWe_UXPAD crash and the SBC application restart.

Root Cause: Precision errors in the floating point comparison in EVRCB decoder code was identified as the root cause.

Steps to Replicate: 

  1. Set sweActiveProfile to use GPU and sweCodecMixProfile to use EVRCB.
  2. Make EVRCB to G711U call and do not send the media.

RESULT:
SWe_UXPAD will crash and the SBC application restarts.

NOTE: The issue is not always reproducible.

The code is modified to handle precision errors.

Workaround: No workaround.

SBX-107613 | SBX-107618


2

PortFix SBX-107613: The AMRWB encoder produces corrupted output when channel is reused by lower mode.

Impact: Degraded audio in AMRWB stream when AMRWB (GPU) call load is running, particularly when each call uses different bitrate.

Root Cause: Problem occurs when the same codec context is reused and the previous used was for higher bitrate, the root cause was identified due to reinitialization logic for an internal buffer.

Steps to Replicate: 

  1. Set sweActiveProfile to use GPU and sweCodecMixProfile to use AMRWB.
  2. Make AMRWB to G711U call load using multiple AMRWB clients, each client using different mode.

    RESULT:
    Some of the calls may have degraded audio in AMRWB stream.

The code is modified to appropriately reinitialize the internal buffer.

Workaround: Problem does not occur when all channels use the same bitrate.

SBX-106004 | SBX-106239


2

PortFix SBX-106004: The EMA display error when SMM deleted through the CLI.

Impact: When a rule is deleted from SMM through CLI and if we try to load the SMM from EMA, an error is displayed in the UI.

Root Cause: EMA checks the ordering of the rules and if the Order is not continuous then an error is shown in the UI.

Steps to Replicate: 

  1. Delete any SMM rule (other than the last) from CLI.
  2. Login to EMA.
  3. Navigate to Profiles > Signaling > SIP Adaptor Profile.
  4. Select the SMM whose rule was deleted from CLI.
  5. SMM is shown without any error.

The code is modified to address the issue. 

Workaround: N/A

SBX-105387 | SBX-105936


2

PortFix SBX-105387: LeakSanitizer:SCMP_3 gave memory leaks at MemAlloc2 and same gave Heap overflow issue, both from the same caseID.

Impact: Heap use after free detected in ASAN for a downstream forking call flow. Accessing memory after it has been freed can cause unexpected behavior and in the worst case potentially coredumps.

Root Cause: When copying multiple contacts from different downstream forking response, the username of the contact header was not updated from the call block to sip message handle. The Sip Message handle was holding a address that was already freed.

Steps to Replicate: 

  1. Run Downstream Forking Call Scenario.
  2. UE sends Initial INVITE towards UAS through the SBC.
  3. The SBC receives multiple 18x with different to tag and different username in the Contact header.
  4. The SBC receives 200 OK for any of the downstream forking dialog.

The code is modified with the correct username from the call block for every downstream forking response.

Workaround: None.

SBX-106167 | SBX-106808


2

PortFix SBX-106167: The call ends up in one-way audio after the called party puts the call on hold and off hold twice.

Impact: Call ends up in one-way audio after the called party puts the call on hold and off hold twice

Root Cause: As a result of call-modify a couple of times, RTCP NAPT learning completes before RTP NAPT learning.

This results in RTCP Remote Address being updated, which has remote RTCP Port.

Due to incorrect code in RTCP modify flow, remote RTCP port, gets assigned to RTP port. This results in one-way media.

Steps to Replicate: 

  1. Run basic SIP to SIP call with NAPT and RTCP enabled.
  2. Hold/Unhold the call a few times to check for proper 2-way audio.

Set the correct RTP Port as part of RTCP modify flow.

Workaround: Since the issue is caused to RTCP NAPT learning completed before RTP during multiple hold/unhold scenario. Work around could be:

  1. Disable RTCP or
  2. Disable NAPT.
SBX-105804 | SBX-107918


2

PortFix SBX-105804: The CDR field is not populated even though the SBC writes the value to CDR field for '200 Ok of BYE' received/sent.

Impact: The CDR field added by SMM is not present in the ‘STOP’ record.

Root Cause: The SBC was not adding CDR field in the STOP record that was added during the process of 200 response of BYE method.

Steps to Replicate: 

  1. Attach the SMM profile which will add the CDR field for 200 response of BYE method.
  2. Enable endToEndBye flag.
  3. Run a basic A-B call.

The code is modified for updating the CDR field in the STOP record during the processing of response of BYE method.

Workaround: Add the CDR field in the SMM for BYE method instead of 200 response of BYE method.

SBX-103570 | SBX-1065462

PortFix SBX-103570: Observed major logs flooding for "MAJOR .SIPSG: sipsgMsgProc.c (-19034) 49487. SipSgRemoveDblTrackingEntry, Hash entry not found"

Impact: Flood of Error logs are seen during load testing of TLS/TCP Registration and certain Register messages are under the scanner of DBL.

Root Cause: The DBL has limitations on the offenders list. When this limitation is reached, due to certain bug in the code, the DBL was sending unintended messages to other modules. Due to this message, the flood of logs were observed.

Steps to Replicate: 

  1. Execute a 600K TLS/TCP Registration at 1000 rps.
  2. Let all the endpoints register.
  3. Start the Supported call load (here Approx 20K, 254cps * 90cht= 22860). 50% from the registered Endpoints and 50% from Peering EPs.
  4. Ext to Ext IntraSBC Call load of 5000, 50cps*100cht from SIPP.
  5. The DBL applied/removed for Registered endpoints should deny entries to 10% of registration/call load. Repeat this for 10 times.
  6. Let the load run for 3 hours.
  7. Do operator initiated CLI switch-over and revert.

The code is modified to address the issue.

Workaround: Not Applicable.

SBX-99258 | SBX-108094


2

PortFix SBX-99258: For OOD NOTIFY, SBC sending 481-Call Leg/Transaction Does Not Exist when same SBC acting as P-CSCF and IBCF.

Impact: SBC fails to send NOTIFY if the User part is not present in the To Header.

Root Cause: SBC is not able to find the entry in the hash-table as to-tag is not parsed properly, because of user part being absent in the To header.

Steps to Replicate: 

  1. Make a basic Subscribe-Notify call, ensure that in From header of subscribe and To header of NOTIFY does not have User part.
    eg: To: sip:10.xx.x.xx;tag = abcd-1234-012
  2. See that for Notify, the SBC will respond with 481 call leg does not exist.
  3. Try the same with Fixed build, notify should reach the subscriber.

The examples below are To headers that were tested in the Notify:

  1. To: sip:10.xx.x.xx;tag = abcd-1234-012
  2. To: <sip:10.xx.x.xx>;tag = abcd-1234-012
  3. To: sip:xxxx@10.xx.x.xx;tag = aabcd-1234-012
  4. To: <sip:xxxx@10.xx.x.xx>;tag = aabcd-1234-012

The code is modified to fetch the tag properly even if the user part is not present in To header.

Workaround: No Workaround.

SBX-88007 | SBX-106099


2

PortFix SBX-88007: The call flow should work with 5 video and 1 audio streams, which is not working, but when one video stream is removed then the callflow is working.

Impact: The call fails if peer SDP contains six streams (5 video and 1 audio) and directMedia along with ICE is enabled at the SBC.

Root Cause: Memory allocated for this SDP was not enough during inter process communication resulted in the failure.

Steps to Replicate: Configuration:
Test requires ingress TG in Zone1, egress TG in Zone2 and AS TG on the SBC, with call to be routed as follows:

UE1 -> ingress TG -> AS TG -> AS peer (sipp) -> AS TG - egress TG -> UE2
Enable Direct Media on the ingress and egress TG's (but not on AS TG):
TG - media directMediaAllowed enable
PSP for all TG's should have DM flag enabled
PSP - flags useDirectMedia enable
Enable ICE (webrtc) on the ingress and egress TG's:
TG - services natTraversal iceSupport iceWebrtc
Enable DTLS on the ingress and egress. TG's and PSP's
TG - media dtlsProfileName defaultDtlsProfile
PSP - dtlsCryptoSuiteProfile DEFAULT enableDtlsSrtp enable
Set the directMediaGroupId on ingress and egress TG's to be same e.g. 200 and AS to be different e.g. 400
e.g. TG - media directMediaGroupId 200
Enable Direct Media Anti Trombone on AS TG:
TG - media directMediaAntiTrombone enable

Steps:

  1. From UE1 send an INVITE with ICE and DTLS in the SDP with 5 video and 1 audio stream to ingress TG and route towards the AS TG
  2. From the AS send back an INVITE to AS TG of the SBC, the C line of the sent SDP must match the C line of the received SDP.
  3. From UE2, send 180 with no SDP followed by 200 OK with ICE and DTLS in the SDP (UE2-sdp 1 audio and 5 video).
  4. From the AS send the 180 followed by 200 OK back towards the SBC.

    Expected Result: The call succeeds.

    Actual Result: The call fails.

The code is modified so the memory buffer size is increased to accommodate six streams.

Workaround: None.

SBX-103539 | SBX-105934


2

PortFix SBX-103539: Observed flooded Logs for refresh registration in the Standby SBC restart stop for sometime "sipsgRegSecurity.c (-2745) 1752. SipRaDigestTlsProcessRefreshRegister: No Digest TLS negotiation in progress"

Impact: The DBG logs were filling up with the following MAJOR level log.
167 09142020 143342.220452:1.01.05.41210.MAJOR .SIPSG: sipsgRegSecurity.c (-2745) 1753. SipRaDigestTlsProcessRefreshRegister: No Digest TLS negotiation in progress

Root Cause: This is an information message and should not have been getting generated at MAJOR level.

Steps to Replicate: Run registration call flows.

The code is modified to address the issue.

Workaround: None.

SBX-106170 | SBX-106189


2

PortFix SBX-106170: The AddressSanitizer: heap-use-after-free on address 0x60f000047d38 at pc 0x562fcd2973a5 bp 0x7f3963983f40 sp 0x7f3963983f38 READ of size 20 at 0x60f000047d38 thread T7.

Impact: The ASAN reported of accessing a structure pointer that is already freed.

Root Cause: The SBC is trying to access structure pointer to get socket address, but that structure pointer is already freed in other function.

Steps to Replicate: Use ASAN build for testing.

  1. Send INVITE from UserA, respond from the DNS1 with RCODE error 4 for A query and respond from DNS2 with RCODE 0 with proper DNS answer for A query and check dnsServerStatistics.
  2. Run a show command to check the dnsFallback flag and ednsFailures stats:
    show addressContext <addressContext_Name> dnsGroup <dnsGroup_Name> dnsFallback
    show table addressContext default dnsGroup <dnsGroup_Name> dnsServerStatistics

The code is modified so now getting socket address from pstSrcAddr structure.

Workaround: No workaround.

SBX-102115 | SBX-106504


2

PortFix SBX-102115: The SBC modifies the Replaces parameter with wrong Call-ID and tags if the Replaced call was looped back to the SBC through a SIP Proxy that does not modify SIP Call-ID and tags

Impact: Relay refer with replaces for loopback call, the SBC picks up the wrong call leg.

Root Cause: The SBC query for the replaces callId, and found matching both legs (loopback). The SBC pick up the wrong leg.

Steps to Replicate: This is specific to customer call flow.

If loopback is detect, only pick the one with to-tag match local-tag. This is per RFC-3891, section 3.

Workaround: None.

SBX-106200


2

The DSP is coring and the system unstable

Impact: Some Fax T.38 IAD calls (T.38 protocols version 3) result in a DSP crash and reload and calls are not successful.

Root Cause: This condition is caused because this specific V3 IAD is sending CM messages with incrementing UDPTL seq numbers. Typically, repeated messages carry same UDPTL seq number to indicate that they are redundant. Packets with unique seq numbers are assumed to be independent and data from these is causing an unchecked buffer overflow in 3rd party T.38 stack code.

Steps to Replicate: The main cause of the crash based on core inspection seems to be multiple CM messages with incrementing UDPTL seq numbers Rx by stack.

As a result, the test case involves a setting up G711 to V3 call with such CM packets.

UAC: start call in G711 and reinvite to V3 and send CM
g711v3t38_cmseq.xml
UAS: start in g711 and accept a re-invite to silsup-off
uas_reinvite_g711.xml
PCAP: cmt38seq.pcap

Delete beforefix.PKT and afterfix.PKT entries because they refer to files attached to the JIRA, which customers don't have access to.

Before fix: The call is set up, and a DSP coredump occurs with a single DSP reload.

After fix: The call continues without crash.

The code is modified to address the issue.

Workaround: Use Version 0 for T.38 calls.

SBX-106429



3

The EMA Configuration Script and Template import page file list doubles each time the search magnifier is used

Impact: When the search magnifier is hit, the entries are doubled.

Root Cause: Table with old data is not cleared before starting a new search. As a result, entries were doubled in dataTable.

Steps to Replicate: 

  1. Have some entries in the table.
  2. Apply a filter and click search button.
  3. Entries are not doubled.

The code is modified to clear the data in the table before starting a new search.

Workaround: No Workaround.

SBX-106583


2

With the Q1912 in a 302 Redirect msg, the SBC sends rn and npdi even though the Contact Header in 302 does not have rn and npdi.

Impact: When making a call where the INVITE contains NPDI/RN parameters and the SIP variant on the ingress trunk group is set to Q1912 when the call goes through 3xx processing the wrong called party number is sent in the subsequent INVITE.

e.g.
The initial INVITE contains
INVITE sip:11111111;npdi;rn=222222@<IP>:<PORT>

The policy dip performs an ENUM query and gets a new called party number of 33333333

The initial INVITE goes out with
INVITE sip:33333333@<IP>:<PORT>

The end point responds with 3xx and the subsequent INVITE then contains
INVITE sip:1111111@<IP>:<PORT>
because when using the Q1912 the TOA_PORTED_NUMBER of 11111111 is passed up to in the second policy dip and confuses the routing logic.

Root Cause: When processing the 3xx and making a second policy dip, the code was meant to remove the generic number parameter of type TOA_PORTED_NUMBER. The code assumed there would only ever be one generic number parameter present. However, when the ingress SIP variant is set to Q1912 the SIP code internally creates a generic number parameter of type additional calling party number based on the contents of the FROM header. In this scenario, the code was unable to delete the generic number of type TOA_PORTED_NUMBER and this was passed back to the PSX in the second policy dip and resulted in routing confusion and unexpected parameter content in the INVITE following the 3xx.

Steps to Replicate: Perform a call where the SIP variant on the ingress trunk group is set to Q1912 and the INVITE contains the npdi/rn parameters e.g.
INVITE sip:1111111;npdi;rn=222222@<IP>:<PORT>
The initial INVITE goes out with
INVITE sip:3333333@<IP>:<PORT>
The end point responds with 3xx and the subsequent INVITE then contains
INVITE sip:3333333@<IP>:<PORT>

The code is modified to correctly delete the generic number parameter of type TOA_PORTED_NUMBER associated with the number translation information from the first policy dip to avoid routing confusion on the second policy dip.

Workaround: If possible change the SIP variant on the ingress trunk group to be "sonus" instead of "Q1912" to avoid the creation of the generic number parameter of type additional calling party number based on the FROM header contents.

SBX-103950


2

There are PAI differences between the SBC and GSX.

Impact: The SBC was using the ingress calling URI information to create the egress PAI header contents, even when the calling party number digits are all removed using DM/PM rules in PSX.

Root Cause: Because the SBC supports additional functionality that is not present on the GSX, the SBC can use the contents of the calling URI from the ingress side of the call even when the PSX does not set the username mask flag in the calling URI parameter in the policy response.

Steps to Replicate: Configure the PSX to generate the PAI header on the egress INVITE, but remove all the calling party digits, all the calling URI username digits and the generic name parameter. Then make a basic call and check that the SBC does not include PAI in the egress INVITE.

The code is modified to check that the PAI header contains username and/or displayname parameters before adding it into the egress INVITE. On the PSX, when the customer wants to delete the calling party number digits, they also need to remove the calling URI username and the generic name information.

Workaround: Need to use SMM to remove the PAI header.

SBX-106197


2

The PKT port manualSwitch triggered twice.

Impact: Executing port switchover command from CLI triggers port switchover twice.

Root Cause: Link detection sub system on standby node subscribes to port switchover action command with CDB (Confd) twice:

  1. When the node comes up as standby.
  2. When it initiates switchover to become active.

    When standby node becomes active, executing port switchover command from CLI results in notifying link detection sub system twice due to duplicate subscription. This results in initiating port switchover twice.

Steps to Replicate: 

  1. Bring up nodes with port redundancy in HA mode.
  2. Initiate CE switchover to make sure standby node becomes active.
  3. Execute port switchover command on new active node and validate the behavior.

The code is modified to not subscribe for action command when the node is in standby mode and subscribe only upon switchover when it transitions from standby to active.

Workaround: None.

SBX-107372


2

Observing lot of errors in DGB files since upgrading to 9.2.0R001.

Impact: Recently, a fix was added in the SBC for updating the subscription timer on getting a NOTIFY message with the value of expires param in Subscription-State header. But as per RFC 3265 this param is a "should" and is not mandatory.

Root Cause: When the SBC updated the subscription timer on receiving a NOTIFY message, the case for the expired param missing was not considered.

Steps to Replicate: Create a subscription on the SBC, with SUBSCRIBE relay.

  1. From UAC send SUBSCRIBE to the SBC, which it relays to UAS.
  2. Send a NOTIFY without expires param to the SBC from UAS.
  3. The log "SipSgStartUpdatedSubscriptionTimer: Invalid subscription timer 0 second for callId" should not be seen after fix.

The code is modified to address the issue.

Workaround: If it is really required, SMM could also be used to send some expires param in NOTIFY Subscription-State header.

SBX-107999


2

The LeakSanitizer: CpxDnsCreate leaks observed during SBX-85432/<redacted> E2E C-SBC automation run.

Impact: There is a small memory leak in the Cpx process when DNS elements are added or deleted.

Root Cause: As part of adding/deleting DNS entries the Cpx process reads in the interface group name from CDB and stores it in a local buffer but does not free it when finished processing.

Steps to Replicate: Add DNS server entries.

The code is modified to correctly free up the local buffer at the end of the configuration logic.

Workaround: None.

SBX-107978


2

There are coverity issue in the SIPSG.

Impact: There are coverity issues for NULL check.

Root Cause: The null pointer dereferences while handling a session refresh.

Steps to Replicate: Run a call where re-INVITE does not contain SDP.

The code is modified to add the NULL check before accessing the pointer.

Workaround: No workaround.

SBX-105105


2

Adjust the MAX_LEN_REALM in camRfAppRedund.h to correct length.

Impact: If the realm string under realmRoute of a diamNode configuration is configured with more than 129 characters, there is a possibility of the string value not being retrieved correctly from the cdb after the SBC restarts or not being made redundant correctly on a HA system.

Root Cause: The maximum size for the realm string was incorrectly defined as 129.

Steps to Replicate: 

  1. On a HA SBC system, Configure diamNode with a realmRoute that has realm string greater than 129 chars. For example:
    set addressContext default diamNode DIAMNODE realmRoute RX.EXAMPLE.COM realm ims111111111122222222223333333333444444444455555555556666666666
       7777777777888888888899999999990000000000111111111122222222223333333333
    mnc094.mcc235.3gppnetwork.org peer RX.EXAMPLE.COM appId rx
  2. Show addressContext default diamNode to verify configuration has applied correctly and realmRoute has realm value string as configured.
  3. Perform a switchover the SBC.
  4. On the newly active SBC, show the addressContext default diamNode to verify configuration is the same and realmRoute has realm value string as configured.

The definition of maximum size for the realm string is  modified to 257.

Workaround: The realm string should be limited to 129 characters.

SBX-106687


2

The Platform Interface Status was incomplete.

Impact: In the Network Tools, the Platform Interface Status section can be used to display the status of Interface selected from the left side section.
For certain interfaces like pkt0, pkt1, mgt0, mgt1 the status message was incomplete.

Root Cause: For interfaces like pkt0, pkt1, mgt0, mgt1 the status message displayed in textarea element, had more than one < and > characters and so the text within them was considered as HTML block by the browser and it was hidden.

Steps to Replicate: 

1. Login to EMA, open Administration > System Administration > Network Tools.

2. Select interfaces in the "Platform Interface Status" section and ensure that the displayed status message matches with the status message from CLI.

The code is modified from <textarea> to <pre> to address the issue.

Workaround: Not Available.

SBX-104439


2

The SBC is not generating the UPDATE message towards the UAC for the 183 Dialog-2 when there is delay in PRACK message.

Impact: A call failure was observed during the processing of second dialog provisional response with SDP for downstream forking scenarios when PRACK is delayed at ingress.

Root Cause: When the SBC needs to send UPDATE at ingress during downstream forking for codec re-negotiation while PRACK is pending, it tries to formulate an internal auto answer. If the UPDATE is offered with a new codec other than previously locked, the SBC while forming such local answer adds the previously negotiated codec. This created a mismatch in offer-answer state machine resulting in call failure.

Steps to Replicate: 

  1. Enable customer configurations.
  2. Send 183 Dialog-2 from UAS.
  3. Once 183 Dialog-2 received to UAC, Send PRACK for that 183 after 2 seconds delay.
  4. Check if the SBC sends UPDATE for the second dialog 18x.

The code is modified to consider presence of "doNotAutoAnswer" TrunkGroup flag to decide if a local answer needs to be formed or wait until PRACK comes to release the UPDATE.

Workaround: Not Applicable.

SBX-104591


2

The SBC is releasing the call during customer-1-1-4 call flow when 200 OK answered with dialog-1 and delay in ACK from UAC

Impact: Call failure observed during processing of second dialog provisional response with SDP for downstream forking scenarios when PRACK is delayed at ingress

Root Cause: When the SBC need to send UPDATE at ingress during downstream forking for codec re-negotiation while PRACK is pending, it tries to formulate an internal auto answer. If the UPDATE is offered with a new codec other than previously locked, the SBC while forming such local answer adds the previously negotiated codec. This created a mismatch in offer-answer state machine resulting in call failure.

Steps to Replicate: 

  1. Enable customer configurations.
  2. Send 183 Dialog-2 from UAS.
  3. Once 183 Dialog-2 received to UAC, Send PRACK for that 183 after 2 seconds delay.
  4. Check if the SBC sends UPDATE for the second dialog 18x.

The code is modified so consider the presence of "doNotAutoAnswer" TrunkGroup flag to decide if such local answer need to be formed or wait until PRACK comes to release the UPDATE.

Workaround: Not Applicable

SBX-108066


2

The /opt/sonus/sbx/bin/opensslSelftest cmd failed in the SBC 7000.

Impact: When the FIPS mode is enabled on hwType SBC 7000 (7k), services will fail to come up and the SBC becomes inaccessible.

Root Cause: After enabling the FIPS mode when FIPS selfTests run, opensslSelfTests fails due to using a deprecated SSL engine on SBC 7000.

Steps to Replicate: 

  1. Enable FIPS mode from CLI.
  2. Ensure the SBC services are accessible after reboot.

The code is modified to remove the deprecated SSL engine from opensslSelfTest and this allows FIPS mode to function as expected.

Workaround: None.

SBX-107486


2

The EMA display error when the SMM is having criteria with reg-exp like "cpm.msg|cpm.largemsg".

Impact: The EMA display error when SMM is having criteria with reg-exp like "cpm.msg|cpm.largemsg".

Root Cause: The EMA is not checking whether nonmatch value is present in database or not.

Steps to Replicate: 

  1. Log into the SBC from CLI.
  2. Configure the profile rules provided in the Description in the DB.
  3. Log into the EMA GUI.
  4. Navigate Profiles->Signaling ->sipAdaptorProfile.
  5. Edit the Configured profile that is done from the CLI.
  6. There we can see the issue is fixed.

The code is modified to address the issue.

Workaround: Not Applicable.

SBX-104685


2

The SBC is not triggering UPDATE to ingress and egress for 183 Dialog-2 during E2E precondition interworking. Issue with ISBC(SIP_FW)

Impact: The SBC was not sending UPDATE towards ingress while process downstream forking call.

Root Cause: Precondition values are not properly updated in the data structures, resulting in failure to send the UPDATE.

Steps to Replicate: 

  1. Bring up customer E2E setup.
  2. Transparency precondition scenario.
  3. Send 18x dialog-2 with same SDP that of 1st dialog 18x.

The code is modified so now the SBC processes the precondition values and triggers an UPDATE to ingress.

Workaround: None.

SBX-104624


2

The SBC is not generating UPDATE message for 183 Dialog-2 when 183 Dialog-1 and 183 Dialog-2 having same SDP.

Impact: The SBC was not sending UPDATE towards ingress while process downstream forking call.

Root Cause: Precondition values are not properly compared at egress, resulting in failure to send the UPDATE.

Steps to Replicate: 

  1. Bring up customer E2E setup.
  2. Transparency precondition scenario.
  3. Send 18x dialog-2 with same SDP that of 1st dialog 18x.

The code is modified to compare the precondition values and if there is change an indication message is sent to ingress leg which further triggers an UPDATE.

Workaround: None.

SBX-108029


2

The SIPSG_MSG_PARAM_SIPSG_REDUND_ACT_STR is not registered for serialization correctly before 10.0 release

Impact: After LSWU, some of the event record fields are not serialized properly for the calls related to Register and OOD messages.

Root Cause: Event record accounting details are not registered for Serialization.

Steps to Replicate: 

  1. The SBC is an older release(< 9.2.1).
  2. Configure to generate event record for Register.
  3. Make a Register call.
  4. Send a Refresh register.
  5. LSWU to 9.2.1.
  6. Complete the registration call.
  7. Check the details of generated event record.

The code is modified to address the issue.

Workaround: None.

SBX-108025


2

Receiving an unexpected CANCEL in the SBX-SBX GW early media case.

Impact: 503 is sent for Update because of Server Request not present for Update Request

Root Cause: Update Server Request is removed from SIP Dialog Structure because we are unable to send a 200 OK for the Update.

Steps to Replicate: In this scenario Update is received from Egress and it is sent to ingress. In the Ingress, the 200 OK for this Update is delayed and not sent immediately.

In the mean time, there is one more Update is received from egress. This is rejected with 500 Internal Error stating request already pending.

Now, the 200 OK for the First Update is received from ingress and it is being sent to egress

The code is modified to  not remove an Update request from Server request list in the SIP dialog request.

Workaround: None.

SBX-107243


2

The mid call tracing is collecting only MGSG logs.

Impact: If the C3 sends MODIFY command with only CallTraceActReq=ON and without any media parameters, then the media logs are not captured in TRC file even if media parameters are changed in subsequent MODIFY command from C3.

Root Cause: Whenever the MRFP/MGSG receives MOD command with only CallTraceActReq=ON, the MGSG does not send any MODIFY command to NRMA and as a result call tracing info is not updated in NRMA and other media related modules.

Steps to Replicate: 

  1. Establish a MRFP call.
  2. Send MODIFY command from C3 with only callTraceActReq=ON, no change in media parameters.
  3. Send MODIFY command from C3 with changes in media parameters.
  4. Verify that .TRC file contains logs from NRMA, XRM and other media related modules.

The code is modified to send modify command to NRMA whenever MGSG receives MOD command with only callTraceActReq=ON.

Workaround: No Workaround.

SBX-107642


2

The SBC terminates a call as 491 does not get relayed.

Impact: Run a Scenario with Re-invite without SDP and send 491 request pending for that re-invite. 491 is not being relayed even though relay4xx-6xx is enabled and E2E Re-invite is enabled.

Root Cause: Even though Re-invite is received from the Network the following bit bIsE2ENtwkReInviteReq in the SIP call structure is not set to true. This is causing 491 to be handled locally.

Steps to Replicate: Run a Re-invite without SDP scenario and send 491 for that re-Invite.

The code is modified to address the issues.

Workaround: None.

SBX-104266


2

The SBC is rejecting the call when 200 OK of INVITE is answered with Dialog-1 .Dialog-1 is having the AMR-WB codec and Dialog-2 having the EVS codec

Impact: Call failure observed during certain downstream forking scenarios when 200 OK of initially negotiated dialog comes.

Root Cause: When the SBC need to send Re-Invite at ingress during downstream forking for codec re-negotiation while ACK is pending, it tries to formulate an internal auto answer. If the INVITE is offered with a new codec other than previously locked, the SBC while forming such local answer adds the previously negotiated codec. This created a mismatch in offer-answer state machine resulting in call failure.

Steps to Replicate: 

  1. Enable customer configurations.
  2. Send 183 Dialog-1 with the AMR-WB codec.
  3. Send 183 Dialog-2 with the EVS codec.
  4. 200 OK of INVITE sent with the dialog-1.

The code is modified to consider presence of "doNotAutoAnswer" TrunkGroup flag to decide if a local answer needs to be formed or wait until ACK comes to release the Re-Invite.

Workaround: Not Available.

SBX-93922


2

The SBC is sending Min-Expires header twice to endpoint for 423 Interval Too brief response.

Impact: The Min-Expires header is sent twice in the REGISTER response.

Root Cause: The Min-Expires header was sent twice as it was getting added by the application and the transparency profile.

Steps to Replicate: 

  1. Enable Min-Expires headers in the Transparency profile.
  2. Send a REGISTER message to SBC from UAC.
  3. UAS sends 423 response to REGISTER message received from SBC.

The code is modified to address the issue.

Workaround: Remove the Min-Expires headers from the Transparency profile.

SBX-106995


2

The SBC is not relaying the 183 Dialog-2 towards UAC when it receives UPDATE with preconditions from UAS for Dialog-1.

Impact: The SBC was not relaying the second dialog 18x to ingress after the completion of preconditions UPDATE for first dialog during downstream forking scenario

Root Cause: The SBC was consuming the second dialog 18x at egress and skipped further processing. When P-Early-Media value received as part of second dialog 18x had less precedence than that of previous dialog, the SBC did not process the second dialog 18x.

Steps to Replicate: 

  1. Bring up the customer E2E setup.
  2. From UAS sent 183 Dialog-1 with preconditions.
  3. The SBC would send the UPDATE message for the preconditions met for dialog-1
  4. UAS sends 183 Dialog-2 with P-E-M sendonly.

The code is modified to follow second dialog 18x and not to consider P-Early-Media value precedence during this process.

Workaround: Modify the value of P-E-M header to sendrecv using SMM.

SBX-104253


2

The "Deleting the a=maxptime" SMM is not working after an SBC restart.

Impact: SMM with sdpContent not getting applied after restart.

Root Cause: At time of restart CPX trying to read SMM with sdpContent from the wrong path.

Steps to Replicate: 

  1. Spawned an HA setup.
  2. Configured SMM rule with sdpContent and run the scenarios.
  3. Switchover the system and re-run the scenario.
  4. Switchover again and re-run the scenario.

Fixed the path from where sdpContent will be read for a SMM action.

Workaround: Delete the SMM rule and configure again.

SBX-105544


2

Dialog scope variable is not present after SMM reject on re-invite message.

Impact: Dialog scope variable is not present when it is saved in the request which is rejected by SMM reject Operation.

Root Cause: Dialog scope saved in case of rejected request seems to be not inserted in hash and freed.

Steps to Replicate: Run a Re-invite call flow and reject the re-invite with 488 and have a SMM Rule to store dialog scope variables for that re-invite,

The code is modified to address the issue.

Workaround: None.

SBX-108278


2

Enabling the facstate flag can cause healthcheck timeout in SBC.

Impact: The 'facState' flag if enabled, may result in some potential crash that is caused by health check timeouts.

Root Cause: The thread that is writing per call key elements in to the file is taking more time and resulting in health check failures.

Steps to Replicate: Run the calls at 100cps rate for around 5 to 6 hours with flag enabled may hit the health check failure problem.

The code is modified to address the issue.

Workaround: Disable the facState flag.

SBX-1073883

Multiple threads are writing to same socket and causing issues.

Impact: In case of CE_switchover, active went down and standby did not come up as new ACTIVE which led to unstable state until the active becomes stable again.

Root Cause: To track a healthcheck, the VNFR used a ZMQ mechanism to send/receive messages from VNFCs. As a result, multiple threads tried to write at same time, which caused failure to send messages from VNFR to VNFCs.

Steps to Replicate: Run multiple CE switchovers with fix.

The code is modified to use the mutex to avoid  concurrent writing at same time with its lock/unlock mechanism.

If one thread is writing then other threads need to wait in queue until the previous one is not done.

Workaround: None.

SBX-1068503

The eventLog combined log size calculation does not consider the disk size properly.

Impact: For the SBC5400 product, the user is allowed to configure the maximum accounting file size and the maximum number of accounting files so that those files can consume up to 150GB of diskspace. However, the maximum amount of disk space allowed should be 80GB.

Root Cause: The code that calculates the limit did not properly compute the disk limit if the product was the SBC 5400.

Steps to Replicate: 

On an SBC 5400,
set oam eventLog typeAdmin acct fileSize 65535 fileCount 2047
[ok][2021-02-17 15:02:03]

commit
Aborted: 'oam eventLog typeAdmin': The fileSize and fileCount values configured for the event logs would result in a potential combined log file usage of 128.4GB, which exceeds the maximum of 80.0GB allowed
[error][2021-02-17 15:02:06]

The preceding error message should be displayed indicating that the maximum log file usage is 80GB.

The code is modified to properly compute the limit for the disk limit if the product was the SBC 5400. The disk limit is 80GB.

Workaround: Ensure that the sum of the filesize*fileCount for each of the SBC log files does not exceed 83886080.

SBX-1071623

There was an error when dumping System Diagnostics md5 files on the EMA.

Impact: The checksum files were not shown while generating a system dump through the EMA/PM.

Root Cause: The EMA/PM only searches for sha256 checksum files now, but the checksum generated was md5, so it was not visible in the list present in EMA GUI.

Steps to Replicate: Use the EMA/PM to generate System Dump, and verified the presence of sha256 checksum file for every tarball generated.

The code is modified so the System Dump program now generates a sha256 checksum, instead of md5. This is visible to EMA/PM.

Workaround: None.

Resolved Issues in 09.02.00R002 Release

The following Severity 1 issue is resolved in this release:

Severity 1 Resolved Issues

Issue

Sev

Problem Description

Resolution

SBX-106989 | SBX-1070171

Portfix SBX-106989: Multiple Switchovers occurred because of a DSP core after an Upgrade to V09.02.00R000.

Scenario: A transcoded call with any Codec<=>G711 and RFC2833 DTMF relay enabled on both legs of a call, and the media probe is disabled.

Impact: If a peer device sends a RFC2833 without EOP packet (end-of-digit marker), then a DSP crash occurs.

Root Cause: The code tried to add an error condition (LOST_EOP flag) to media probe data structure without checking whether a media probe was enabled or not. This resulted in a NULL pointer access and a subsequent memory protection fault resulting in a dsp core dump.

Steps to Replicate: The customer case had a G711A<=>G711A transcoded call with RFC2833 enabled on both legs

Use the following setup:

SipP UAC=>SBX 5x10 => SipP UAS
G729AB(RFC2833) <=> G711(RFC2833)
show configuration system media mediaProbe state
state disabled;
From UAC send dtmf_2833_1_noEop.pcap with '1' digit w/o EOP packets

This resulted in dsp core dump before the fix and no core dump was observed after the fix and digit '1' was correctly sent to g711 side.

The code is modified so if the media probe is enabled and not write to media probe structure if media probe is disabled.

Workaround: Use RFC2833<=>Inband digits or RFC2833<=>SIP Info instead of RFC2833<=>RFC2833.

SBX-103881 | SBX-1057401

PortFix SBX-103881 to 9.2.x - MEO: Qseries CDR field not matching Qseries format

Impact: When rn parameter is received as part of SIP R-URI, this value is being used to populate field 10 of the QSBC format CDR record, rather than the received Called Number

Root Cause: In case of rn parameter received, source for field 10 of QSBC CDR is incorrect

Steps to Replicate: Send SIP INVITE with R-URI including rn parameter.

Change code such that if rn is received, field 10 of QSBC is populated with the "Called Number Before Translation" (field 24 of Ribbon format CDR). For other scenarios, field 10 is populated as before.

Workaround: None.

SBX-106206 | SBX-1070181

Portfix SBX-106206: An existing hairpin call gets silenced after a switchover.

Impact: When switchover occurs in the SWe SBC Active-Standby HA with the SBC internal loopback media calls flows, the media loopback is not working in existing calls. The looped back media is dropped internally in the SWe NP, because packet skb was not including the internal loopback flag set condition in the NP incoming path validation checks from the internally looped back media for the existing calls.

Root Cause: When a switchover occurs in the SWe SBC for existing medial calls, a loopback occurs in the SWe NP based on the matching SA. 

The DA IP address was configured in BRES by setting an internal loopback flag for packet work/skb, even though MAC DA is not updated in BRES flows to the new active instance interface MAC Address to match SA MAC.

However, this internal skb loopback flag settings was removed in the release 9.0 release NP refactoring code which caused the packet drops in incoming packet checks for MACs at NP from the looped back media of existing calls. The new calls will not have this issue post-switchover.

Steps to Replicate: With the SWe SBC Active-Standby HA setup, using AS/3GPP call flow scripts/setup, establish a call that creates the SBC internal loopback media flow. Verify the media flow and then Issue a switchover and verify the media again on this existing active call.

The code is modified to save NP the CPU cycles also while addressing the loopback media issue after a switchover issue for existing calls.

Workaround: None.

SBX-105269 | SBX-1070441

Portfix SBX-105269: The SBC crashed and a core dump created.

Impact: The SCM processes coredump due to NULL pointer access on a pointer that has been freed due to BYE and HOLD REINVITE in a transfer call scenario.

Root Cause: There was an illegal memory access, absence of NULL check, exposed due to REINVITE.

Steps to Replicate: A calls B, B REFERs to C and now A and C talk. After sometime, A sends BYE and C sends re-INVITE with a=inactive at the same time.

The code is modified to address the issue. 

Workaround: None.

Resolved Issues in 09.02.00R001 Release

The following Severity 1 issue is resolved in this release:

Severity 1 Resolved Issues

Issue

Problem Description

Resolution

SBX-106080

Release 9.2.0 should have CAM version of "00610000".

New CDR fields were added in the 9.2.0R0 release, but the CAM version in the top of the ACT header file was not updated to "00610000". It was still set to ""00600000", which was used for release 9.1.0R0.

Impact: Incorrect CAM version in the top of the ACT header file.

Root Cause: The code to increment the CAM version was missed.

Steps to Verify Fix: Run a basic call and check the ACT log header to confirm the CAM version is set to "00610000"

The code is updated to correctly set the CAM version to "00610000".

Resolved Issues in 09.02.00R000 Release 

The following Severity 1 issues are resolved in this release:

Severity 1 Resolved Issues

Issue

Problem Description

Resolution

SBX-101451

The DSP Threshold setting is not generating a trap on SBC 5400.

Impact: The g711PacketThreshold, g729Threshold, and g726Threshold onset and abate traps are not sent.

Root Cause: The NRM did not receive CLI updates to the g711PacketThreshold, g729Threshold, and g726Threshold, and the trap generation code used wrong trap names.

Steps to Replicate: 

  1. Provision the threshold levels:
    set oam traps dspAdmin dspAvailabilityTrap g729Threshold 40
    set oam traps dspAdmin dspAvailabilityTrap g726Threshold 60
    set oam traps dspAdmin dspAvailabilityTrap g711PacketThreshold 80
    commit 
    set oam traps admin sonusSbxDspAvailG729OnSetCrossThresholdNotification state enabled
    commit
    set oam traps admin sonusSbxDspAvailG729AbateCrossThresholdNotification state enabled
    commit
    set oam traps admin sonusSbxDspAvailG726AbateCrossThresholdNotification state enabled
    commit
    set oam traps admin sonusSbxDspAvailG726OnSetCrossThresholdNotification state enabled
    commit
    set oam traps admin sonusSbxDspAvailG711OnSetCrossThresholdNotification state enabled
    commit
    set oam traps admin sonusSbxDspAvailG711PacketAbateCrossThresholdNotification state enabled
    commit
  2. Configure the trap target: set oam snmp trapTarget EMS160 ipAddress 10.xxx.xx.xxx port 162 trapType v2 state enabled commit.
  3. Limit the compression resources to make the issue readily occur: set system mediaProfile tone 98 compression 2 commit.
  4. Perform a bunch of transcoded (e.g. G711 to G729) calls that exceed threshold limits, and see onset traps are sent to the trap target.
  5. Clear the transcoded calls, and see abate traps are sent to the trap target.

The code is modified to support g711PacketThreshold, g729Threshold, and g726Threshold values.

Deprecated the support for allThreshold, as it was never implemented in the SBC.

Workaround: None.

SBX-102833


Calls are dropping when placed on hold through MS Teams.

Impact: When MS Teams puts a call on hold and then attempts to retrieve it while the microphone is disabled, the action results in the call being cleared.

Root Cause: MS Teams performs the call retrieve by sending an INVITE with a replaces message to the SBC and when the microphone is disabled this message includes a=recvonly.

The SBC send 200 Ok response to the INVITE with replaces with a=sendrecv while Teams is expecting a=sendonly that causes the call to be cleared by MS Teams.

Steps to Replicate: 

  1. Establish a PSTN to Teams call through the SBC.
  2. Place call on hold from Teams.
  3. Disable the microphone in browser running Teams and then retrieve (place off hold) the call.
  4. The call should retrieve should be successful.

The code is modified to respond to an INVITE with replaces containing a=recvonly, with 200 OK containing a=sendonly.

Workaround: None.

SBX-103974


The STI sends 2 Identity fields in Contact header, but SBC only passes one

Impact: In the case where multiple "Identity Headers" are present as embedded headers in a 3xx "Contact Header", the SBC sends out only 1 Identity Header for the re-directed INVITE.

Root Cause: The SBC did not support handling of the scenario where SIP headers are repeated in embedded contact headers in 3xx. The SBC would end up the sending only the last of the repeated headers in the re-directed Invite.

Steps to Replicate: 

  1. The SBC is configured with ERE, set the config required for handling embedded headers in 3xx as shown below.
    "set profiles signaling ipSignalingProfile DEFAULT_SIP egressIpAttributes redirect flags forceRequeryForRedirection enable honorEmbeddedHeadersIn3xx enable"
  2. Run a UAS script with 302 redirection and add multiple "Identity headers"
    as shown below.
    Ex- Contact: 9710622482<sip:9710622482@10.xx.xx.xx:xxxx?Identity=test1&Identity=test2&Identity=test3>
  3. Run a 2nd UAS Script to handle the Redirected INVITE.
  4. Run SIPP call, trigger UAC script.

    Expected Result: The redirect INVITE shall contain both the Identity headers received in 3xx as embedded contact header.

The code is modified to support repeated SIP headers.

Workaround: None.

SBX-103645



A customer SBC upgrade had a spiltbrain SBC boot issue

Impact: One of the customer SBCs in N:1 mode is not coming up after upgrade.

Root Cause: The customer SBC node went for multiple reboots due to config profile change and split brains after upgrade exceeding max limit for reboot.

Steps to Replicate: Upgrade all customer SBC nodes in one shot so that they all come up together.

The code is modified to avoid split brain due to nodeId/serviceId collision by informing the peer nodes about the self node's nodeId/serviceid as soon as its allocated.

Workaround: Restart the customer SBC application manually on the node which has exceeded max reboot limit.

SBX-99850



The BYE message was sent to the wrong port.

Impact: When endpoint is registered over TLS initiates a calls and after call is established, endpoint sends refresh register from modified port and also sends refresh INVITE with no SDP change, the SBC does not send BYE to modified port upon call disconnect.

Root Cause: The SBC does not update remote connection address when refresh INVITE is received from different port.

Steps to Replicate: 

  1. Register endpoint over TLS.
  2. Endpoint initiates a call, call gets connected.
  3. Endpoint sends refresh register from modified port.
  4. Endpoint sends refresh re-INVITE from modified port.
  5. Called party disconnects the call.
  6. Verify SBC sends BYE to modified port towards caller.

The code is modified to ensure the SBC update remote address when the refresh INVITE is received from modified port.

Workaround: None.

SBX-86293


PreInstall Check improvements for file permissions.

Impact: PreUpgrade checks failure due to permission issues on external directory.

Root Cause: Pre-checks script failed to run commands on peer due to permission issues.

Steps to Replicate: Perform upgrade to the fix version and verify that upgrade is successful.

The code is modified to ensure permissions/ownership are set properly before running through pre-checks/upgrade.

Workaround: Set the right ownership for external directory as:
chgrp -R upload /opt/sonus/external/

SBX-103057



The IAC:terraform apply output is displaying only mgt Active and Standby IP's. I

Impact: When orchestrating a HFE 2.0 or HFE 2.1 setup in Azure using Ribbon RAF modules, the Terraform output does not show any information about HFE node(s) created, even thought the HFE nodes are started correctly.

Root Cause: Terraform was missing the configuration to tell it to output the information about the HFE node(s).

Steps to Replicate: Create a HFE 2.0 or HFE 2.1 setup using Ribbon RAF modules.

The code is modified so that Terraform outputs the management IP and instance name for each HFE node when the orchestration is successful.

Workaround: None.

SBX-103571



There are call failures due connection toggling between the SBC and SLB.

Impact: The SBC's can lose connectivity to the HFE nodes when there is high amounts of traffic on the network in Azure.

Root Cause: The health check timeout from the HFE to SBC is too small, therefore was not receiving the replies back from the SBC, causing HFE to switchover

Steps to Replicate:

Increased the timeout from 20ms to 100ms

Workaround: Manually edit the following line in HFE_AZ.sh from:
$FPING -c 3 -t 20-p 200 ${ACTIVE_SBC_IP_ARR[0]} &> /dev/null
to:
$FPING -c 3 -t 100 -p 200 ${ACTIVE_SBC_IP_ARR[0]} &> /dev/null

SBX-103058



The IaC is creating same NSG for all the network interfaces created. Recommended SGs should be created for each interface.

Impact: IaC is creating single NSG for all the 4 sbc interface.

Root Cause: Iac is creating one NSG and using same for all sbc interfaces created.

Steps to Replicate: Provided option to create different NSG for different interface created for the SBC.

Option available in terraform.vars Ex:
sbc_security_group_names = ["TF-SVT-SG-MGT0", "TF-SVT-SG-HA", "TF-SVT-SG-PKT0", "TF-SVT-SG-PKT1"]

The code is modified to create different NSG for different interface of the SBC.

Workaround: None

SBX-103277


The Active SLB failed in the LCA to coming up "getInterfaceInfoFromMDS: Could not get the interface details in the metadata information!"

Impact: If the Azure fails on the request when verifying the authorization of the managed identity, then the cloud-init immediately fails.

Root Cause: The cloud-init is missing tolerance when testing the authorization.

Steps to Replicate: TBD

Add retries if the connection is reset or times out to address the issue.

Workaround: Reboot the instance after cloud-init has failed.

SBX-103781



The LeakSanitizer detected memory leaks on various processes for a t140 Call.

Impact: Small memory leak while configuring SNMP trap targets.

Root Cause: While processing the configuration requests the SBC code was reading content from CDB into local memory blocks but failed to release the memory blocks at the end of the configuration action.

Steps to Replicate: Configure the SNMP trap targets.

The code is modified to correctly free the internal memory blocks used to hold the temporary CDB configuration data.

Workaround: None

SBX-104494



The PES Process cored while testing Flex AD support with the ERE (SBX-72926).

Impact: PES process dumps core while executing AD service.

Root Cause: While executing the AD service, PES fetches the AD profile from cache. Since there is no AD profile was configured in this case, cache shall return NULL. The code was missing to check for NULL for the AD profile pointer.

Steps to Replicate: Configure a AD number translation criteria with ingress TG as the trigger criteria type. Make a call on the ingress TG. While executing the AD service, PES process will core dump.

The code is modified to check for a NULL for AD profile and AD attribute profile. If there is no profiles configured, the control returns and the service is marked as failed.

Workaround: Configure an AD Profile and AD Attribute profile so that the existing code can be executed further.

SBX-104769



The SCM Process cored while testing SBX H323 Conformance and Interworking.

Impact: The SCM Process cored while running SIP-H323 interworking call to verify rfc2833 to inband DTMF.

Root Cause: Accessing of a NULL pointer caused the core dump.

Steps to Replicate: Run a SIP-H323 interworking call with SIP side RFC 2833 and H.323 side inband DTMF being enabled.

The code is modified to check for NULL pointer before accessing it.

Workaround: None.

SBX-105263

Observed a PRS Process core followed by a "DsPr, Ssre, Cpx" core on both active and standby box, for the Openstack S-SBC HA pair and "Ccsp" process core on the TSBC active while running calls on the 2CPS with the ASAN build.

Impact: There was a memory leak detected by the ASAN in the active S-SBC while running the G.711 to G.729 transcoding load on the D-SBC.

Root Cause: A code analysis of the ASAN reported function revealed that in some corner scenarios, the SBC may end up leaking the memory related to the place holder used to store the remote DSP resource.

Steps to Replicate: Re-run the same load in ASAN and ensure no memory leaks are detected

The code is modified to free this memory.

Workaround: None.

SBX-102082



The SCM Process core dump was observed when REGISTER is received and useRandomUserInfoInContactHdr is enabled.

Impact: Invalid memory access issue when both embeddedRegInfoinUserPart and useRandomUserInfoInContactHdr flag were enabled

Root Cause: In the SBC, the appropriate memory was not allocated for contactUrl puchUsername in case both embeddedRegInfoinUserPart and useRandomUserInfoInContactHdr flag were enabled, due to this invalid memory access was happening.

Steps to Replicate:

  1. On SLB - Enable remoteDeviceType to access
  2. On SBCs enable the embeddedRegInfoinUserPart flag as:-
    set addressContext <ADDRESS_CONTEXT> zone <ZONE> sipTrunkGroup <TG> signaling embeddedRegInfoinUserPart enabled
  3. On SBCs enabled useRandomUserinfoInContactHeader as :-
    set addressContext <ADDRESS_CONTEXT> zone <ZONE> sipTrunkGroup <TG> signaling useRandomUserInfoInContactHdr enabled

The code is modified to allocate appropriate memory for puchUsername based on embeddedRegInfoinUserPart or useRandomUserInfoInContactHdr enable case.

Workaround: As per the SBC design, any of the flags below should be enable not both.
embeddedRegInfoinUserPart or useRandomUserInfoInContactHdr flag

SBX-98177 | SBX-104816

PortFix SBX-98177: The SBC 7000 TCP window size.

Impact: Add CLI support to set the kernel parameter net.ipv4.tcp_window_scaling.

Root Cause: In certain SBC deployment scenarios (a large number of devices running SIP-TLS), the tcp_window_scaling caused small TCP window size.
In such cases, the customer had to use Linux command to disable tcp_window_scaling on each SBC node.

Steps to Replicate: 

  1. Show initial setting for tcp_window_scaling on both active (SBCSWE01a) and standby (SBCSWE01b)
    [root@SBCSWE01a ~]# cat /proc/sys/net/ipv4/tcp_window_scaling=1
    [root@SBCSWE01b ~]# cat /proc/sys/net/ipv4/tcp_window_scaling=1

  2. Use CLI to change the kernel param value and display the changed value on both active and standby.
    admin@SBCSWE01a% set system admin SBCSWE01 kernelParams tcpWindowScaling disable
    admin@SBCSWE01a% commit
    Commit complete.

    [root@SBCSWE01a ~]# cat /proc/sys/net/ipv4/tcp_window_scaling=0

    [root@SBCSWE01b ~]# cat /proc/sys/net/ipv4/tcp_window_scaling=0

The code is modified for setting the kernel parameter net.ipv4.tcp_window_scaling. The Linux command is no longer needed.

Workaround: Use Linux command to set the kernel parameter on both active and standby.
[root@SBCSWE01a ~]# sysctl net.ipv4.tcp_window_scaling=1
[root@SBCSWE01a ~]# sysctl -w net.ipv4.tcp_window_scaling=0
[root@SBCSWE01b ~]# sysctl net.ipv4.tcp_window_scaling=1
[root@SBCSWE01b ~]# sysctl -w net.ipv4.tcp_window_scaling=0

To be persistent across SBC restart and system reboot, use Linux the following shell command on both active and standby.
[root@SBCSWE01a ~]# echo "net.ipv4.tcp_window_scaling=0" >> /etc/sysctl.conf
[root@SBCSWE01b ~]# echo "net.ipv4.tcp_window_scaling=0" >> /etc/sysctl.conf

SBX-105351 | SBX-105366

Portfix SBX-105351: The 823R0 SCM Process cored.

Impact:The SCM cores after a long extensive load of the OOD relay.

Root Cause: The SBC accesses an invalid pointer of link list when the cleanup relay control block.

Steps to Replicate:System required HW_TYPE_SBS5000 and max support Relay per SCM is 4194304.

Run the OOD relay load (Notify). After a long period time (at least 4m relay per SCM).

The code is modified to properly initialize the link list.

Workaround: None.

SBX-105019 | SBX-105184

Portfix SBX-105019: A crosstalk issue seen on the SBC 5400.

Impact: When there is a transcoded call with Opus codec and Opus termination does not send any packets to the SBC, then other termination of opus call, may hear audio from another unrelated opus transcoded call or it may hear white noise.

This occurs on SBC5x10/5400/7K but not on SWe platforms. This problem only happens if no opus packet is received. When the decoder receives first opus packet, subsequently problem does not happen for that call.

Root Cause: Initially, when no packet is received, Opus decoder is not called. As a result, the decoder's output buffer is uninitialized and it happened to be stale buffer of another opus call or a leftover buffer of a previous Opus call on that DSP. That buffer is used to encode data for other leg of the Opus call and that results in cross talk audio or distorted noise to other termination of Opus call.

Steps to Replicate: 

  1. Make two sipp Opus<=>g711 calls, say call 1 and call 2 on SBC5x10/5400/7K
  2. These two calls have to land on same DSP core. So issue a unhide debug command 'request sbx drm debug command "loadbalance disable" before making two calls. Without this command, both calls may not land on same DSP core and you may not see same problem.
  3. Call 1 sends audio packet (.pcap) from Opus termination but call 2 does not send any packets to the SBC from it's Opus termination.
  4. Call 2's g711 termination will hear audio from call 1's opus termination.

The fix is to clear the buffer (with silence) when the Opus decoder is not primed with any packet.

Workaround: 

  1. Use a different codec other than Opus.
  2. Use SWe platform instead of h/w SBC5x10/5400/7000.
SBX-102122 | SBX-104540

Portfix SBX-102122: SAM Process core dumps with v06.02.01 F012.

Impact: The SAM and PRS process cored in the Standby node.

Root Cause: The DRBD split brain lead to DRBD GI reset. This leads to a DRBD full sync, increasing the i/o congestion and ultimately causing a healthcheck timeout.

Steps to Replicate: To test, run "drbdadm disconnect mirror". Once we get "standby split-brain" log in DBG logs, run "drbdadm disconnect mirror" again so that DRBD does not connect automatically and we get into the block which we need to test. Run "drbd-overview" and check if drbd does not went for full sync.

The code is modified to perform the DRBD checks after DRBD split-brain recovery.

Workaround: None.

SBX-102625 | SBX-104065

PortFix SBX-102625: The SIP calls stop in receiving 183 (Precondition).

Impact: Call stopped working after 183 received without SDP.

Root Cause: As part of egress precondition interworking, to negotiate the SBC should send an UPDATE to the egress endpoint. When 183 received without SDP, SBC should not try to send UPDATE. SIPSG call state assumed UPDATE is sent. Therefore, when the next 183 is received it tried to queue the 183 assuming UPDATE is in progress.

Steps to Replicate: As mentioned in the JIRA

The code is modified to avoid this state transition when 183 received without SDP.

Workaround: Remove the 183 without a SDP message using SMM.

SBX-102837 | SBX-104152

PortFix SBX-102837: The fra-tdg-sonus-01 SipSignalingPorts became OutOfService after a switchover.

Impact:The SIP sigPorts stuck in the OOS after a switchover.

Root Cause: The customer had the network/pkt port issue, on one of their HA node, which caused pkt port(s) to bounce randomly, i.e. pkt port went DOWN and came back UP within 2 to 3 seconds. So they have been keeping that node as standby node. They also have link detection enabled for pkt port(s) and have around 100 LIFs per pkt port, one per SIP SIGPORT. When the pkt port went down, NRS delays the port down event processing for 2 second to allow link failure detection to be ready and also to avoid the race condition between NRS and LVM. When a 2 second delay timer is up, the NRS starts to take down affected LIFs and notifies local SIPCM and SIPFE so they can take down affected SIP SIGPORTs.

In SIPCM, all the sockets on the affected sigPort are put in a delete pending table and starts a 1 tick timer. Then the socket(s) is being deleted after 1 tick timer is up.
When pkt port came back up, NRS processes the event with no delay and notifies SIPCM and SIPFE as well. Since there are around 100 LIFs, there were many messages exchanges between NRS/XRM/SIPCM/SIPFE. NRS LIF FSM has the mechanism in place to handle the timing issue and LIFs were all back in service. But SIPCM failed to activate some SIP SIGPORT(s) while binding the socket(s). These error messages indicated that SIPCM tried to activate the SIGPORT while it was still pending delete. Therefore SIGPORT got stuck in OOS(broken state) in both SIPCM and SIPFE on standby node. If there was a switchover happened later, user would then noticed one or more SIGPORTs were OOS. They have to manually bounce those SIGPORTs to bring them back in service.

Steps to Replicate: The nature of the problem was the timing caused race condition. There is no good way to re-create/verify the fixes.

Suggest to run regular SIP related regression tests.

The code is modified to:

  1. Introduce a new 1 tick timer in SIPCM_DATA_STR, activateRetryTimerId.
  2. The deletePendingSocketTable and if the sigPort is found in the table, then start the 1 tick timer. When the timer is up, SipCmActivateCallSigPort() is invoked again. Once the sigPort is activated successfully, SIPCM notifies SIPFE as usual.

Workaround: No workaround.

SBX-101161 | SBX-103677

PortFix SBX-101161: A memory leak was observed in the SAM process.

Impact: A memory leak was observed in the SAM process.

Root Cause: There is race condition in the code that handles CALL_AUDITs and CALL_CLEANUPs that can cause a memory leak.

If the response to a CALL_AUDIT takes to long, the code that handles the "late" response has allocates memory for a structure that may never get freed.

Steps to Replicate: This issue is caused by a race condition that cannot be forced - therefore we cannot specify steps to reproduce this issue.

The code is modified to add a timer every time a fault structure is allocated. When the timer expires, if the the structure still exists it will be freed.

Workaround: There is no workaround.

SBX-104802 | SBX-105186

PortFix SBX-104802: Enabling the Dialog Transparency causes calls to fail.

Impact: The call fails for the dialog transparency and forking.

Root Cause: When the ingress support PRACK and multiple 18x fork, the SBC fails to send 200 OK to ingress.

Steps to Replicate: Configure dialog transparency and downstream forking on egress.
Ingress support PRACK, egress not support PRACK.

The Egress answers 180fork1, 180fork2, 180fork3, and 200 OKfork2 simultaneously.

The code is modified so the SBC resets the PRACK pending status properly, causing 200 OK stuck in the queue.

Workaround: Disable the dialog transparency.

SBX-104761 | SBX-105065

PortFix SBX-104761: A SM Process coredump occurred on the server.

Impact: The SM Process crashed while executing the "show table system syncStatus" command.

Root Cause: The shell script used to get the oracle sync status - PolicyDBSyncStatus.sh - did not return within 10 seconds, causing a healthcheck timeout that caused the coredump.

Steps to Replicate: This problem is not reproducible.

The code is modified to disable heathchecks while fetching the syncStatus.

Workaround: There is no workaround.

SBX-103553 | SBX-105277

PortFix SBX-103553: The SBC does not proceed multiple 183.

Impact: The GSX-GW-SBX call erroneously queues 183 message at SBX when X-Service-Type precondition is received and downstream forking enabled.

Root Cause: An interaction between downstream forking and GW-GW code.

Steps to Replicate: Make GSX -> SBX SIP-GW-SIP call.
Egress trunk group has X-Headers supported.
Egress trunk group has downstream forking enabled.

INVITE -->
<-- 183 with X-Service-Type: cf,precondition and SDP
<-- 183 with X Service-Type: cf,precondition and different SDP
<-- 180 with X Service-Type: cf and SDP
<-- 183 with X Service-Type: cf and no SDP
This final 183 is queued.

The code is modified to not perform the queueing in GW-GW scenarios.

Workaround: None.

SBX-104443 | SBX-105071

PortFix SBX-104443: The SM Process and Cpx cores prevented fra-tdg-sonus-01-1 to come back up as standby after switchover

Impact: The SM Process and Cpx processes cored on slot 1 after LDG triggered switchover to slot 2.

The SM Process was deadlocked while retrieving peer NTP status.

The Cpx cores happened after SM Process coredump, when writing SMM profiles into shared memory.

Root Cause: The root cause was SM Process deadlock.

Steps to Replicate: This is time sensitive issue. The steps cannot be re-produced or verified.

Suggest to run full regression test with switchovers.

The code is modified to release smNtpLock_ after issuing a NTP restart command because we certainly do not need the lock while doing the restart.

Workaround: No workaround.

SBX-103254 | SBX-104839

PortFix SBX-103254: The call setup delay with the Option Ping 40+ endpoints SBC SWe.

Impact: The configuration support to disable Path MTU Discovery by setting kernel parameter net.ipv4.ip_no_pmtu_disc (ipNoPmtuDisc). When ipNoPmtuDisc is to 2, the DF bit in IP packet header will be set 0.

Root Cause: The secure network does not support Path MTU Discovery per RFC-1191.

Steps to Replicate: Testing on a Standalone SBC SWe:

1. Start packet capture, and make SIP call (SIP-TLS). Verify Path MTU Discovery is enabled by checking outgoing IP packet's DF bit is 1.
- Test to show the issue
[root@SBCSWE03 ~]# date; tshark -t a -i pkt0 -f "ip host 10.x.xx.xx" -w t_tshark_pkt0_10.x.xx.xx_1127_pmtu_1027_01.pcap
Tue Oct 27 16:21:11 EDT 2020
Capturing on 'pkt0'
35 ^C
[root@SBCSWE03 ~]# tshark -V -r t_tshark_pkt0_10.7.20.29_1127_pmtu_1027_01.pcap | more


Internet Protocol Version 4, Src: 10.x.xx.xx (10.x.xx.xx), Dst: 10.xxx.xx.xxx (10.xxx.xx.xxx)
Version: 4
Header Length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..00 = Explicit Congestion Notification: Not-ECT (Not ECN-Capable Transport) (0x00)
Total Length: 60
Identification: 0x0000 (0)
Flags: 0x02 (Don't Fragment)
0... .... = Reserved bit: Not set
.1.. .... = Don't fragment: Set
..0. .... = More fragments: Not set
Fragment offset: 0

[root@SBCSWE03 ~]#
--> The DF bit was set to 1.

2. Disable Path MTU Discovery.
admin@SBCSWE03% set system admin sbcswe03 kernelParams ipNoPmtuDisc ?
Description:
Configure /proc/sys/net/ipv4/ip_no_pmtu_disc (0 (default; disable); 1,2,3 (enabled modes))
1: when frag-required ICMP is received, PMTU to this destination is set to min_pmut 552.
2: implicitly setting IP_PMTUDISC_DONT on every created socket - outgoing IP packet DF is set to 0.
3: hardened pmtu discover mode. Please refer to Linux kernel document.

Possible completions:
<int, 0 .. 3>[0]
admin@SBCSWE03% set system admin sbcswe03 kernelParams ipNoPmtuDisc 2
admin@SBCSWE03% commit
Commit complete.
[ok][2020-10-27 16:36:27]

3. Restart the SBC. (If using HA, restart both nodes)
[root@SBCSWE03 ~]# date; sbxrestart
Tue Oct 27 16:36:56 EDT 2020

4. Start packet capture, and make SIP call (SIP-TLS). Verify Path MTU Discovery is disabled by checking outgoing IP packet's DF bit is 0.
[root@SBCSWE03 ~]# date; tshark -t a -i pkt0 -f "ip host 10.x.xx.xx" -w t_tshark_pkt0_10.x.xx.xx_1127_noPmtu_1027_02.pcap
Tue Oct 27 16:42:32 EDT 2020
Capturing on 'pkt0'
26 ^C
[root@SBCSWE03 ~]# tshark -V -r t_tshark_pkt0_10.x.xx.xx_1127_noPmtu_1027_02.pcap | more
...
Frame 2: 74 bytes on wire (592 bits), 74 bytes captured (592 bits) on interface 0
...
Internet Protocol Version 4, Src: 10.x.xx.xx (10.x.xx.xx), Dst: 10.xxx.xx.xxx (10.xxx.xx.xxx)
Version: 4
Header Length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..00 = Explicit Congestion Notification: Not-ECT (Not ECN-Capable Transport) (0x00)
Total Length: 60
Identification: 0xe881 (59521)
Flags: 0x00
0... .... = Reserved bit: Not set
.0.. .... = Don't fragment: Not set
..0. .... = More fragments: Not set
Fragment offset: 0
...

[root@SBCSWE03 ~]#
--> The DF bit was set to 0, and Path MTU Discovery is disabled.

Disable the Path MTU Discovery by setting kernel parameter net.ipv4.ip_no_pmtu_disc to 2. When set to 2, the DF bit will be set to 0 for the transmitted packets on every created socket. The configuration parameter is "system admin <name of system> kernelParams ipNoPmtuDisc".

Workaround: The workaround is a hack. It can be used one time test only. The hack will not survive Linux reboots.

  1. Make changes on the current Standby (assuming SBC1 is currently active, and SBC2 is currently standby)
    [root@SBC2 ~]# date; cat /proc/sys/net/ipv4/ip_no_pmtu_disc
    [root@SBC2 ~]# date; echo “2” > cat /proc/sys/net/ipv4/ip_no_pmtu_disc
    [root@SBC2 ~]# date; sbxrestart
  2. Wait until SBC2 is up and synched. Ensure the p_no_pmtu_disc is set to 2.
    [root@SBC2 ~]# date; sbxstatus | tail -4
    [root@SBC2 ~]# cat /proc/sys/net/ipv4/ip_no_pmtu_disc 2
    [root@SBC2 ~]#
  3. Make changes on the current Active.
    [root@SBC1 ~]# date; cat /proc/sys/net/ipv4/ip_no_pmtu_disc
    [root@SBC1 ~]# date; echo “2” > cat /proc/sys/net/ipv4/ip_no_pmtu_disc
    [root@SBC1 ~]# date; sbxrestart
  4. Wait until the SBC1 is up and synched. Ensure the p_no_pmtu_disc is set to 2.
    [root@SBC1 ~]# date; sbxstatus | tail -4
    [root@SBC1 ~]# cat /proc/sys/net/ipv4/ip_no_pmtu_disc 2
    [root@SBC1 ~]#
  5. May perform a switchover to make the SBC1 to be active.
  6. Run your tests.
SBX-95982 | SBX-104938

PortFix SBX-95982: The SBC was running version 6.2.2 and cannot capture media with MCT.

Impact: The MCT reload of configuration (sbx restart or switchover) will not succeed.

Root Cause: Missing small logic during the restart in order to properly reload the MCT configuration.

Steps to Replicate: Retest MCT reload and switchover scenarios.

The code is modified to properly reload the MCT configuration.

Workaround: User can delete the MCT config and reconfigure it after any restart/switchover.

SBX-103948 | SBX-103977

PortFix SBX-103948: The SBC Application is crashing when CPaaS to PSTN call is made.

Impact: The SBC cores after a reboot/upgrade.

Root Cause: The issue was introduced when the SBC try to support 10000 SMM rules in 8.2.0.

Steps to Replicate: Configure the customer rules (delete SDP line). Major logs trigger but the rule still success.

After a reboot/upgrade, the core occurs.

The code is modified to address the issue. 

Workaround: Disable the delete SDP rule.

SBX-105156 | SBX-105239

PortFix SBX-105156: The SBC was sending m=application 0 UDP/BFCP (null).

Impact: The SBC generates the syntax error m line UDP/BFCP in 183.

Root Cause: The SBC accesses the initialize data when format m line for UDP/BFCP

Steps to Replicate: Incoming call with m-line UDP/BFCP. ERE/PSX using script NO_ROUTE and trigger announcement. The internal 183 has m-line UDP/BFCP with an invalid syntax.

Make the m-line initialize properly to address the issue.

Workaround: Use the SMM to correct m-line syntax error.

SBX-96239 | SBX-105068

PortFix SBX-96239: The display-name in the Diversion header or History-info header is deleted during the interworking.

Impact: The SBC does not send display name present in ingress INVITE's diversion header in history info header in egress INVITE.

The SBC does not send a display name present in ingress INVITE's history info header in egress INVITE's diversion header.

Root Cause: The SBC does not consider display name when interworking between diversion header and history info header.

Steps to Replicate: Ensure the display name is sent in history info header of egress INVITE when the SBC is converting diversion header to history info header.

Also, the SBC should send the display name in diversion header of egress INVITE when the SBC is converting history info to diversion header.

The code is modified to ensure the display name is sent when the SBC is interworking history info and diversion header.

Workaround: None.

SBX-104225 | SBX-105154

PortFix SBX-104225: Both servers are registered but offline, and the SBCs cored after routing the changes from the customer.

Impact: The S-SBC Core dump with PEM enabled call-flow.

Root Cause: With PEM enabled, M-SBC performs NAPT learning for 1st RTP Packets. Upon receiving the Napt Indication for egress-leg from the M-SBC, the NRMA on the S-SBC performs flowChange/modification on both ingress and egress leg.

As part of this flowChange/modification in ingress-leg, the ingress is NULL, resulting in coredump.

The cktInfo on ingress should never be NULL, unless the call is being teared down.

In this case, the ingress-leg has received a CANCEL, resulting in the call being taken down, as part of this call tear-down, ingress-leg cktInfo is reset to NULL, and then the de-alloc indication for ingress-leg is sent to the M-SBC, while the S-SBC is waiting for response of this tear-down, it processes the NAPT indication on egress-leg from the M-SBC. This results in the NULL cktInfo pointer getting accesses for ingress-leg.

Steps to Replicate: 

  1. Setup a D-SBC transcoded call with MRF.
  2. Enable PEM on egress.
  3. Ensure PRACK is enabled.
  4. Ensure 180 without SDP, followed by 183 with SDP is received from UAS.
  5. Ensure CANCEL is received from UAC, while 200 OK from MRF is received, such that the timing of RTP NAPT learning processing and CANCEL processing match.

    NOTE: This is a very tricky issue to recreate, as the timing may vary every time we attempt, it is a matter is few milliseconds.

The code is modified to address the issue.

Workaround: Disable NAPT or PEM. This workaround will ensure that we do not get to the race condition.

SBX-104561 | SBX-104936

Portfix SBX-104561: The 8.1R5 customer SBC OAMs reaches 90% memory util and then restarts.

Impact: The memory leak was observed on the OAM node.

Root Cause: 

  • The XRM and MRM are sending messages through the ICM to NRM.
  • The NRM is not present/running on OAM.
  • Since these are non-discardable messages, they will queue forever until we run out of memory.

Steps to Replicate: 

  1. Deploy the fix.
  2. Monitor memory usage of PRS process.
  3. Validate that PRS memory is not increasing.

The code is modified so that these messages are not sent on OAM node.

Workaround: Before this fix, the workaround is to restart OAM app to recover the memory.

SBX-104484 | SBX-104614

PortFix SBX-104484: The SBC is rejecting the second Update message from the Egress as 500 result into call failure.

Impact: The SBC rejects 2nd Update from egress due to DLRB feature.

Root Cause: The first Update SIPS response locally 200 OK but not clear the server request message. As result the second Update, trigger the SIPS answer 500.

Steps to Replicate: Configure the DLRB, Egress response 183 without the SDP, first Update, and the second Update.

The code is modified so after a 200 OK response, the SIPS clears the server request so it can handle the subsequent one.

Workaround: Disable the DLRB.

SBX-104146 | SBX-104303

PortFix SBX-104146: The DNS Process observed a coredump when responding with a RCODE 1 error from the DNS server and deleting a DNS Group in the SBC.

Impact: The DNS Process dumps core after getting RCODE errors 1,2,4 for a EDNS query and the DNS Group is deleted immediately on the SBC in the monitoring Interval specified in the "ednsRetryAfter" configuration has values ranging from 60 to 180 seconds with 180 being default.

Root Cause: The EDNS failure timer callback is invoked, upon encountering an EDNS query failure based on the "ednsRetryAfter" configuration. The timer call back function is missing NULL check for the DNS Group

Steps to Replicate: 

  1. The SBC configured with EDNS support.
  2. The DNS server is configured to respond with the RCODE 1/2/4 error for EDNS query.
  3. Make a SIP Call that triggers the EDNS query.
  4. Disable the DNS Server and delete the DNS group within 180 seconds.

The code is modified to cancel the EDNS-failure timer, whenever the DNS Group is deleted and the NULL pointer check is added for the timer callback for robustness.

Workaround: None.

SBX-103207 | SBX-103580

Portfix SBX-103207: The SBC SWe duplicates the audio from call B to call A.

Impact: If the CN is not negotiated for G711 codec and remote peer still sends CN packets that match default CN payload type (13) then user on other end may hear cross talk audio of completely unrelated channel or hear own reflect audio.

Root Cause: When a g711 side does not negotiate CN in signaling, the DSP does not initialize Comfort Noise Generation object. However, if remote peer still sends a CN packet that matches the g711 SID payload type configured in PSP (default 13), DSP accepts the packet. It processes that CN packet incorrectly and as a result uses stale voice buffer that happens to be of another channel. This continues until next voice packet for that channel arrives. As a result, we see cross talk audio from the other call during silence period. In some cases, the user may hear own audio also and that is different manifestation of the same problem. This issue is specific to SWe.

Steps to Replicate: Follow the step described in problem statement of JIRA.

The code is modified to initialize the comfort noise object even though the CN is not negotiated and process CN packets correctly.

Workaround: 

Work around 1:

Change the default payload type of comfort noise from 13 to something else (say 15) in PSP of peer that is sending CN packets. This will make DSP drop CN packets because payload type will not match.

Work around 2:

Enable silence suppression on PSP of peer that is sending CN packets and keep CN payload type that matches with CN payload type.

SBX-102704 | SBX-103869

PortFix SBX-102704: Unable to Add or Edit route with # in Destination National, CLI or EMA.

Impact: User is not able to store few special characters for the destination number field in the route entity.

Root Cause: The pattern defined for the destination number filed did not allow special characters.

Steps to Replicate: Create a route with special character like #123 for the destination number filed in the route entity.

The code is modified to allow only few specific special characters.

So, reverted back the pattern to same as before 8.1 release, so that no customers face similar issue again who have configured special characters prior to 8.1.

Workaround: None.

SBX-102290 | SBX-104913

PortFix SBX-102290: The DBG file was filling up with messages "SIPCM: *ThreadPool: messageSequence".

Impact: The DBG logs can be overrun with "SIPCM: *ThreadPool: messageSequence" messages.

Root Cause: The DBG logs can be overrun with "SIPCM: *ThreadPool: messageSequence" messages, when Double CRLF "pings" are received by the SBC over UDP transport.

Steps to Replicate: Send Double CRLF "pings" over UDP to the SBC.

The code is modified to properly dispose of Double CRLF "pings" received by the SBC over UDP.

Workaround: Inhibit the transmission (or reception) of Double CRLF "pings" over UDP.

SBX-104934 | SBX-105024

PortFix SBX-104934: The SBC generates the same ICID for more than 1 call, porting the fix for SBX-101887 into 8.2.3F1 did not help

Impact: Duplicate the ICID generated for two different calls.

Root Cause: The instance specific value is set to 0 every other call causing the ICID generation to always use 0 in all instances. This results in the same ICID generated in more than one SCM instance when the calls land within the same microsecond

Steps to Replicate: Configure the SBC to generate ICID on the egress side. Run call load and check for duplicate ICIDs.

The code is modified to manipulate the last octet of the MAC address used in ICID generation.

Workaround: None.

SBX-105417 | SBX-105583

Portfix SBX-105417: During an S-SBC and M-SBC cyclic switchover, the S-SBC app did not come up after few switchovers.

Impact: The service did not come up after a switchover due to inconsistent encryptedStore.

Root Cause: The store became inconsistent after the oam_config got applied, the time taken during deletePeerEntries should also be reduced to allow a ChmClearEncryptedStoreOfPeers to finish faster during startup.

Steps to Replicate: Perform multiple switchovers and ensure that:

  1. ChmClearEncryptedStoreOfPeers does not take too long during startup.
  2. The deletePeerEntries runs in background and does not take too long either.
  3. The service comes up, role is assigned successfully and store is consistent.

The code is modified so:

1. deletePeerEntries run in background
2. decryptStore validates if decryption was successful to ensure the store is not inconsistent/corrupt.

Workaround: None.

SBX-103629 | SBX-103654

PortFix SBX-103629: The SIP registrations are failing, and the SBC reporting REGISTER_PARSE_ERROR and replies with SIP 500 when it receives retransmitted initial REGISTER (CSEQ 1) followed by REGISTER with Authorization header (CSEQ 1).

Impact: When the SBC recv rexmit of registration (cseq=1) after sending 401/407, the SBC relay to AS. At the same time, the IAD sends new registration(cseq=2) for authentication. It triggers race condition to the SBC and response 500.

Root Cause: The SBC should relay rexmit (cseq=1) registration to application server.

Steps to Replicate: The IAD send registration(cseq1) to AS, AS response 401 to IAD, IAD rexmit the same sceq1, and send a new sceq2 with auth header.

The code is modified to response rexmit request (cseq=1). So that a subsequent one cseq=2 can handle properly relay to AS.

Workaround: None.

SBX-105486

The SBC 9.1 MD5 check sum.

Impact: The SBC qcow2 image is shipped along with a sha256 checksum but Openstack glance supports only md5 checksum. Unable to validate the image in an automated way.

Root Cause: Checksum was updated from md5 to sha256 as md5 is weaker compared to sha256 algorithm and there are reported attacks on md5.

Steps to Replicate: With the fix build, ensure qcow2.md5 is one of the build artifacts.

The code is modified to facilitate openstack glance image verification.

Workaround: User can manually create md5 checksum by running below command:
md5sum sbc.qcow2 > sbc.qcow2.md5

SBX-104284

The SNMPv3 traps from the MRFP are not displayed in EMS Fault Management.

Impact: The traps were not getting displayed in EMS.

Root Cause: The SBC generates Engine ID at the time of ISO installation. Due to this, all cloud instances share same engine id from the qcow2 generation time.

When same engine id is returned by two SBCs in different cluster, the EMS is unable to differentiate between them.

Steps to Replicate: Launch instances from qcow2 in different clusters. Traps generated should be shown correctly now.

Engine ID is created at the time cloud instance launch now to address the issue.

Workaround: None.

SBX-104688

Configure the import issue.

Impact: The fields that supports \r like regex fields, changes it after a configuration Import(XML based).

Root Cause: The \r is not xml encoded when parsing intermediate xml file.

Steps to Replicate: 

  1. Create SMM Profile with regex that has \r export configuration as xml-tar clear DB.
  2. Import the configuration.
  3. Verify SMM profile regex field.

The code is modified to handle \r as a special case.

Workaround: None.

SBX-104463

Observed a SCM Process coredump in the gcored while running the 30 SWOs on 7000 Platform.

Impact: In case of switchover and switchback while running load, we expect some stale entries in SIPSG and CC control blocks. Such entries are cleared on the audit, but while clearing the SIPSG is sending accounting message to CC.

This SIPSG was reconstructed, but in CC the index corresponding to this GCID was allocated to some other GCID.

When the CC receives such message, the mismatch occurs and it logs a crash in sensitive mode.

Root Cause: During load run with multiple switchovers, various call modules get reconstructed when standby transitions to active. Due to this some stale entries are expected. If one of these stale entries sends some message (e.g accounting message) and if index for that call was allocated to another call, this error can happen. In case of such mismatch the SBC logs a crash in sensitive mode.

Steps to Replicate: Load run with multiple switchovers.

If the GCID sent from SIPSG module in accounting message is different from the GCID received in CC module, for switchover case do not do a sensitive crash. Instead add a major log to address the issue.

Workaround: Run load scenarios in normal mode instead of sensitive mode.

SBX-104526

The emssftp fails in the 9.1R1.

Impact: The emssftp login was failing.

Root Cause: The sequence of asking for a password and keep credentials in sync caused the emssftp password failed.

Steps to Replicate: Checking login, after multiple reboots, rebuild with 1:1 and N: 1, along with 1-2 EMS registered.

The code is modified on the mode(HA vs standalone), included a new script to handle password request and updated for some HA cases.

Workaround: None.



The following Severity 2 and 3 issues are resolved in this release:

Severity 2-3 Resolved Issues

Issue

Sev

Problem Description

Resolution

SBX-104962 | SBX-104989
2

Portfix SBX-104962: The HFE setInterfaceMap() can be incorrect.

Impact: The HFE_AZ.sh script can configure the HFE node incorrectly if the IP of an interface is a contained with in another.

Root Cause: The logic used to determine which interface associates while the NIC can find the incorrect interface.

Steps to Replicate: Create a HFE where the eth0 address contains either eth1 or eth2 IP address.

The code is modified to verify it the only the correct IP address is used.

Workaround: Request an updated HFE_AZ.sh script from Ribbon. Replace the HFE_AZ.sh in the storage account and reboot the HFE node(s).

SBX-104156 | SBX-104571
2

Portfix SBX-104156: The RTT-TTY support verifies the call flow in the SBC.

Impact: Lower case characters from t140 packet were not getting converted correctly to Baudot (tty). Also, some other characters were not getting converted as per V.18 A2 table.

Root Cause: The translation table from T140 to Baudot(TTY) only accounted for the subset of characters that were present in the Baudot (TTY) character set.

Steps to Replicate:

  1. Setup a T140=>Baudot (AMRNB=>G711) call.
  2. Create t140 pcap file with all UTF8 characters (128) and validate the baudot generation.
  3. Create a t140 pcap file with multi-byte sequence and validate the baudot.

The code is modified to:

  • The t140=>Baudot translation table as per V.18 Annx2. 
  • Validate multi-byte (2,3 and 4 bytes).
  • Handle the Byte Order Mark (BOM).
  • Ignore an invalid byte sequence and substitute the valid but unknown multi-byte seq with an apostrophe.

Workaround: None. Instead of lower case letters use upper case letters.

SBX-96783 | SBX-104926
2

PortFix SBX-96783: Some counts in the callCurrentStatistics keep incrementing.

Impact: The "activeRegs" counter provided by the CLI zone callCurrentStatistics/ callIntervalStatistics command may continuously increase.

Root Cause: Badly formed SIP REGISTER messages received by the SBC
(i.e., a REGISTER message that the SIP parser determines is bad)
will increment the "activeRegs" counter and never decrement it.

Steps to Replicate: Send bad SIP REGISTER message(s) to the SBC, and see that the
"activeRegs" counter provided by the CLI zone callCurrentStatistics / callIntervalStatistics command increases (and does not decrease).

Decrement the "activeRegs" counter when the SIP REGISTER message fails the SIP parser to address the issue.

Workaround: None.

SBX-102364 | SBX-1046572

Portfix SBX-102364: The SBC behavior is inconsistent with the isfocus parameter handling.

Impact: 

Issue 1: The SBC is not transparently passing the complete Contact header in 200 OK of SUBSCRIBE when there is a isfocus parameter.

Issue 2: The SBC is not adding the Record-Route in any message when doing a full Contact header transparency

Root Cause: 

Issue 1: The SBC passes contact header transparently only when the isfocus is present in request as well as response and would not send the contact header transparently only when the contact header in response has isfocus parameter.

Issue 2: The code to add a record route for notify and its response is not present.

Steps to Replicate: 

  1. Configure the SBC for A to B call.
  2. Enable the flag contactTransparencyForIsFocusMediaTag on both TGs.
  3. Make a SUBSCRIBE-NOTIFY call flow.

Issue 1: The code is modified to check if the service bit is not set (for the response) and check if the contact header has the isfocus parameter, if the parameter is present, set:

SIP_SERVICE_TYPE_CONTACT_TRANSPARENCY_
    FOR_ISFOCUS_PARAM

for a single contact scenario.

Issue 2: The code is modified to add the record route for notify and its response if isfocus parameter is present.

Workaround: None

SBX-103988 | SBX-1045472

Portfix SBX-103988: The ICE not working after upgrade to V08.02.03A950.

Impact: When a call with ICE changes from direct media to passthrough, ICE learning does not get enabled on the call.

Root Cause: The code was not re-enabling the ICE FSM to start ICE learning when changing from direct media to passthrough.

Steps to Replicate: 

Test 1
--------

  1. Establish a call with ICE on ingress and xdmi on egress.
  2. Send re-invite from egress without xdmi and complete the re-invite related signaling.
  3. Send stuns to ingress media to complete ICE learning and verify call state changes to established and media can be exchanged between ingress and egress.

The code is modified to re-enable the ICE FSM when changing from direct media to passthrough to allow the receipt and processing of stun messages to complete ICE learning.

Workaround: None.

SBX-103496 | SBX-1038062

The MGT0 cannot reach the GW.

Impact: The mgt0 interface appears to be inactive. The user cannot ping the gateway from the SBC 5400.

The ethtool -S mgt0 shows the tx_pause count rising rapidly.

Root Cause: This problem is specific to the SBX 5400 fix.

The SBC 5400 has a backpressure mechanism for management ports so that when the receive buffer exceeds a certain level, Design sends pause packets out to the interface to ask the switch/router to pause transmission momentarily.

The receive buffer count is incremented by a hardware module and decremented by software.
The notification was sent from Network Processor to application about sRTP Rollover Counter (ROC) reset is specifying the wrong interface so software decrements the wrong receive buffer count.

This causes the receive buffer count to wrap around, resulting in a high value. This triggers the back-pressure mechanism and Design continuously send out pause packets.

Steps to Replicate: 

  1. Set up a pass-thru SRTP call.
  2. The call should be a long duration call so that the Rollover Counter (ROC) in the sRTP packet becomes non-zero.
  3. Modify the call so that the sRTP packet's the SSRC changes.

Update:

  1. Do a long duration sRTP call (about 30 minutes.)
  2. Hold the call.
  3. Unhold the call.
  4. As a result, this causes an SSRC change and triggers the problem.

Set the correct interface information in the notification to address the issue.

Workaround: Please contact Ribbon support for a script that will restore contact to the management interface.

SBX-103922 | SBX-1046492

Portfix SBX-103922: There was a PRS Process coredump on an active/A node in the middle of an upgrade.

Impact: The PRS Process cored during the LSWU while syncing ICE call data.

Root Cause: The ICE redundancy code is taking a long time to sync the call data with the standby during LSWU, causing a Healthcheck timeout and a core dump.

Steps to Replicate: The issue cannot be reproduced easily. 

The code is modified so the ICE syncs the call data to standby and addresses the issue. 

Workaround: None. 

SBX-104704 | SBX-104907
2

PortFix SBX-104704: Duplicate the audio entries in the route PSP.

Impact: The duplicate codec entry is being sent in the policy response.

Root Cause: The function popPSPCodecEntryHlp that populates the codec entry was called twice, and as a result the codec entry was getting populated twice in the TLV.

Steps to Replicate: Add more then 4 codec entries in the ingress PSP and egress PSP. This will cause the issue to be reproduced.

The code is modified so that the duplicate codec entry is not passed on the d+ response.

Workaround: None.

SBX-101575 | SBX-104914

2

PortFix SBX-101575: There was an offline upgrade failure from 8.2.1 to 8.2.2

Impact: An offline upgrade on a HA setup failed for the upgrade from 8.2.1 to 8.2.2.

Root Cause: An offline upgrade failed due to presence of a model update marker files that should not get created in case of offline upgrades.

Steps to Replicate: Perform an offline upgrade on a HA setup to the fix build and ensure upgrade is successful.

The code is modified to ensure nodeB is powered-off/shutdown (instead of the sbxstop) while upgrading a nodeA. This ensures that the model update related markers files do not get created.

Workaround: None.

SBX-104668 | SBX-105128
2

PortFix SBX-104668: The SNMP PM collection is not working for newly added KPIs.

Impact: SNMP stats collection at EMS for G711_WITHOUT_XCODE_RES_PEAK_COUNT and G711_WITHOUT_XCODE_RES_AVG_COUNT of DspResDspUsageIntervalStats failed.

Root Cause: Some of the KPI stats fields are made obsolete as they are no longer supported. Due to this change EMS is not able to collect the stats through SNMP.

Steps to Replicate: Verify EMS SNMP walk should not fail when queried to the SBC.

  1. Bring up SBC.
  2. Register SBC to EMS.
  3. Enable the sonusDspResDspUsageIntervalStatistics.

Expected Result:
The EMS fetches stats from the SBC.

The code is modified so the EMS is able to collect stats using SNMP.

Workaround: None.

SBX-103175 | SBX-103652
2

PortFix SBX-103175: The large microflow profile was not getting enabled in the Custom Traffic Profile.

Impact: There are multiple issues:

  1. For a default profile, max subs was always set to 256K.
  2. For the custom and standard traffic profiles, the micro flow count in the NP resource was not proper.
  3. Limited support of the 2M micro flows for standard profiles.

Root Cause:

  1. The large micro flow support was not there for the custom traffic profiles.
  2. For standard and default traffic profiles, there was restricted/incomplete support of large micro flow that is made generic as part of this issue.

Steps to Replicate:

  1. Create an instance with 10GB memory and 16vpcu with the default traffic profile.Check microflow limits using "/opt/sonus/bin/cpsi -d summary" command.
  2. Increase the memory to 50GB memory and check the microflow limits using "/opt/sonus/bin/cpsi -d summary" command.
  3. Create a instance with 20GB memory and 16vpcu. Create and activate a custom traffic profile with access enabled in call mix. Check microflow limits using "/opt/sonus/bin/cpsi -d summary" command.

The code is modified to:

  1. Introduce a new estimation parameter maxSubs based on the micro flow count is decided and the NP hugepages are reserved.
  2. Enable the large micro flow support for all the standard/default profiles where mem > 48GB and vcpu_count >10.

Workaround: No workaround available. Need to use the build after the fix.

SBX-104347 | SBX-104735
2

PortFix SBX-104347: The resource mem congestion level 3 is approaching threshold 90 sample 82.

Impact: The SIPCM is leaking a structure that is associated with the SIPMM functionality.

Root Cause: The code to free this memory under certain error/edge scenarios is missing.

Steps to Replicate: Since the exact call flow is not know that caused the customer to hit the error condition, no test steps can be used.

The code is modified to free the SIPMM related structure in error scenarios.

Workaround: Since the exact call flow is not know that caused the customer to hit the error condition, we cannot suggest a workaround.

SBX-102707 | SBX-104911


2

PortFix SBX-102707: The network interfaces are not renamed as expected after an upgrade from 820R2 to 821R0.

Impact: Network interfaces are not properly mapped when the system is abruptly brought down after the first boot and rebooted.

Root Cause: Cloud-init service runs in parallel to sonusudev service and can cause issues with the network interface mapping as it tries to rename the interfaces.

Steps to Replicate: Reboot the system after sonusudev is run on first bootup.

The code is modified to start only after the sonusudev has run and mapped the interfaces properly.

Workaround: Reboot the instance again to recover from the issue.

SBX-99208 | SBX-1026662

PortFix SBX-99208: The SBC has the same issue as SBX-86420, this time for an outgoing REGISTER messages.

Impact: When the TLS port is not sent from the PSX, the SBC is not sending the DNS SRV query to the DNS server.

Root Cause: The root cause was the SBC just increments the port number by 1 sent by the PSX even if peer port was Zero.

Steps to Replicate: 

  1. Configure the SBC and PSX to send a register and subscribe SIP request to relay.
  2. Configure the serve FQDN and zero for the FQDN port.
  3. Send a register/subscribe request.
  4. The SBC should send SRV query to the DNS server.

If port number sent by PSX is zero then do not increment it by +1 by default for selecting TLS port to address the issue.

Workaround: None.

SBX-103561 | SBX-103793


2

PortFix SBX-103561: The "tgrp" parameter are not passing transparently when the SIP in the core is enabled.

Impact: The SipCore calls is passing the wrong TGRP parameter value.

Root Cause: There was missing logic to support the SipCore.

Steps to Replicate: Configure the SipCore feature. Both the IPSP core and egress leg have "originating Trunk Group Options" set to "Include Tgrp with IP address"
Make a SipCore call.

The code is modified to support the SipCore feature.

Workaround: None.

SBX-103852 | SBX-103978


2

PortFix SBX-103852: The SBC sent an unnecessary 481 for PRACK when the CANCEL is received.

Impact: The SBC sends unnecessary 481 for PRACK when received CANCEL.

Root Cause: The issue was introduced by intercept feature (SIP_EVENT_PRACK_INTERCEPT_RCVD).

When the SBC received PRACK, it save the message into the server list. Later the CANCEL arrives, UasCancelRequestCmd, the UAS found the message in server list, and thought PRACK is not completed therefore it try to send 481.

Steps to Replicate: A calls B, B response 180 and send 180 to A with PRACK required.
After 32 seconds A sends a CANCEL, the SBC sends an unnecessary 481 PRACK.

Once the 200 OK for PRACK has send out, the SIPS deletes the PRACK message in the server list to address the issue.

Workaround: Enable the e2e PRACK if the egress also supports PRACK.

SBX-96788 | SBX-103979


2

PortFix SBX-96788: The DTMF 2833 PT change (in offer) has incorrect OA SBX handling (wrong answer PT).

Impact: When the peer offer with new PT, the SBC is unable to process and respond to the previous one.

Root Cause: There was a logical error that checking the wrong field to detect PT change.

Steps to Replicate: A call B and connect with "0 100". An INVITE with an offer new PT "0 101". The SBC responds with "0 100".

The code is modified to check the correct field for PT change.

Workaround: None.

SBX-105428 | SBX-105440


2

PortFix SBX-105428: Error when attempting to delete negative cache record upon a probe response.

Impact: The DNS query was not out sent from the SBC if a call is made immediately after the DNS server is recovered from a blacklist.

Root Cause: Due to record is in the negative cache entry from earlier DNS dummy query, the SBC was not sending a query.

Steps to Replicate: 

  1. Configure the SBC with a basic call and also configure the DNS group.
  2. Ensure that DNS server does not respond to the DNS query or stop DNS server.
  3. Now make call and SBC query for DNS server for resolving FQDN, but DNS server is down and there no response from DNS server.
  4. After retransmission's timeout value. DNS server will be blacklisted.
  5. Now the SBC keep probing DNS server.
  6. Bring the DNS server up.
  7. The SBC receives probe response, DNS server is removed from Blacklist.
  8. Immediately make SIP call.

Expected Result:

  • The SBC selects a DNS query.

As soon as the DNS server is removed from blacklist entry, those records involved with the DNS Dummy query is removed from the negative cache and resolves the issue.

Workaround: None.

SBX-105010 | SBX-105155


2

PortFix SBX-105010: Observed a congestion for the G711 to G711 transcode calls even before the CPU resource limit is exhausted.

Impact: The G711-G711 transcoded capacity test shows a lower capacity.
(Test is Pump make and break g711 to g711 transcode calls on one of the active instances with 50cps, 90 CHT and 4500 calls).

Root Cause: The root cause is an incorrectly built libfmtd.a that was built with a debug option and makes the FMTD module take more cycles. This bug was addressed originally in SBX-104122.

Steps to Replicate: Perform a test indicated in SBX-105010.

The code is modified to remove the -g flag and using -O3 flag for compilation (Port of SBX-104122).

Workaround: None.

SBX-105072 | SBX-105150


2

PortFix SBX-105072: Password padding with random characters by the SBC causes the RADIUS server to reject the password.

Impact: The radius password sent to the server has no zero characters at the end following the password and a NULL.

Root Cause: The radius passwords are padded to 16 characters. The existing implementation did not set those padded characters to 0.

Steps to Replicate:

  1. Configure a radius authentication server.
  2. Use a password that is less than 15 characters long for the external radius user.
  3. Set the externalAuthententication to true.
  4. Run a tshark session.
  5. Login to the CLI.
  6. Stop the tshark.
  7. View the radius password element in wireshark after configuring the shared secret in wireshark under protocol preferences.

The padded characters are now set to 0 to address the issue.

Workaround: Use 15 or 16 character passwords.

SBX-66831 | SBX-103723


2

PortFix SBX-66831: Need to update/add proper warning message when deleting the ipInterface.

Impact: The warning message does not display in the cloud SBC when deleting the IP interface, but there is no problem with functionality.

Root Cause: This is working fine in the hardware SBC. We have the problem in the cloud SBC because when displaying the warning message, we checked few values if that values are matching. Then, show the warning popup but in case the cloud SBC values index are different and check is failing because of that, we are unable to show the warning popup when we delete IP Interface.

Steps to Replicate: 

  1. Login to EMA.
  2. Go to All -> Address Context ->IP Interface Group -> IP Interface.
  3. Click on New IP Interface button.
  4. Fill the correct info in text field, select state as enable, Mode as In Service and click on save button.
  5. The creation should be successful.
  6. Select the same entry from IP interface list section and click on delete button.
  7. We should be able to see warning popup like "'addressContext PPP_AC ipInterfaceGroup PPP_IG ipInterface': Deleting ipInterface while in dryUp action can
    cause problems with calls on the ipInterface. Use force action to clear existing calls on the ipInterface before deleting. Do you wish to continue?"

The code is modified to handle the Cloud SBC scenario.

Workaround: None.

SBX-100286 | SBX-103102


2

PortFix SBX-100286 to 9.2: The trace file containing SIP Rec PDU was not imported in Ribbon Protect properly.

Impact: When a level 4 call trace is active, if a SIP PDU is too large to fit on a single trace line, it is split over multiple lines. However, the Ribbon Protect only reads the first line - there is no way for it to know subsequent lines are continuation lines.

Root Cause: Design issue.

Steps to Replicate: 

  1. Enable level 4 call trace.
  2. Send a SIP PDU to be traced towards the SBC of total size 2000 bytes.

The code is modified to put the same header onto each level 4 trace line. Include in the header two new fields, the MSG ID and PART to allow Ribbon Protect to recombine multiple trace lines to recover the original message. The equivalent Jira VIGIL-17137 is required for Ribbon Protect compatibility.

Workaround: None.

SBX-100590 | SBX-104867


2

PortFix SBX-100590: The wrong "Egress Zone Name" in ATTEMPT CDR for a GW-GW call.

Impact: For a call with multiple routes that include one or more local routes followed by routes on another gateway (for GW-GW) scenario, if the local routes fail and then other gateway route is selected, the resulting ingress gateway CDR for the call has incorrect egress zone name and ID.

Root Cause: When there are multiple routes, when a route fails the call cranks back to use the next route. When selecting the next route the code is not clearing the internal CDR information for the egress zone. So if the next route selected is on another gateway, the CDR information retains the egress zone information from the previous attempt rather than being blank.

Steps to Replicate:

  1. With the SBC GW-GW setup create two routes for a call such that:
    - route 1 is routed through local egress trunk group on SBC1.
    - route 2 is routed through egress trunk group on SBC2.
    - Set crankback profile to enable attemptRecordGeneration and add reason 41 (503 is mapped to 41 in default SIP to CPC mapping profile).
  2. Send a valid INVITE to the SBC1 ingress that will first select route1 and route out through the egress trunk group on the SBC1. From the egress endpoint reject that call attempt with a 503 Service Unavailable.
  3. The call will crank back and re-route using route2 through the SBC2 egress trunk group. From the egress endpoint reject that call attempt with a 503 Service Unavailable.
  4. Check there are two Attempt CDR records for the call on SBC1.
    1. ATTEMPT1 - should have the "Egress Zone Name" and "Egress Zone ID" fields populated correctly with zone information for zone of SBC1 egress.
    2. ATTEMPT2 - should have the "Egress Zone Name" empty and "Egress Zone ID" as 0 because this is an attempt for GW-GW route.

The code is modified to clear the internal CDR information for the egress zone when one route fails and the next route is selected.

Workaround: None.

SBX-74991 | SBX-104980


2

PortFix SBX-74991: Saving changes to a SMM profile after doing an edit/update operation is taking long time[8 to 16 minutes].

Impact: The SIP Adaptor Profile with 250+ rules takes lot of time to create a profile including the update as well.

Root Cause: When the SIP Adapter Profile with more than one rule is created, each rule is committed individually. However, after each commit EMA internally retrieves all the SIP Adapter Profiles along with their rules, though this is not required it is causing slowness of both create and update operation.

Steps to Replicate: 

  1. Login to EMA.
  2. Navigate to Sip Adapter Profile Screen.
  3. Create a profile with 200+ Rules.
  4. Click on Save button.

The code is modified to prevent retrieval of sip adapter profiles after each commit

Workaround: The only workaround is to create the profile from the CLI.

SBX-101769 | SBX-104912


2

PortFix SBX-101769: The SBC sends the wrong SDP in 200 OK for UPDATE received from the Ingress during tone play(LRBT).

Impact: The SBC responds with wrong codec in the answer to UPDATE received on ingress/calling side while local ring back tone is playing. As a result, the UPDATE is being used to change the codec on ingress. In this case, the SBC continues to play the RBT using the previously agreed codec.

Root Cause: There was a logical error in the code that was picking the currently active packet service profile to answer instead of honoring the modify.

Steps to Replicate: Configuration:

  1. Configure SBC to make a Basic A-B call.
  2. Configure PSX with G711 and G729 in codecEntry and this Leg/other Leg configuration.
  3. Configure LRBT, and attach to Ingress TG.

Procedure:

  1. Send an INVITE from UAC with G711.
  2. Send an 180 from UAS, with no SDP.
  3. Send an UPDATE from UAC, with G729.
  4. Receive the 200 OK from INVITE from UAS.

The code is modified to address this issue.

Workaround: None.

SBX-103771 | SBX-104825
2

PortFix SBX-103771: There are special characterss in DN hinders EMA display.

Impact: The EMA does not display route with destination national containing special characters.

Root Cause: The support for special characters was not available in EMA.

Steps to Replicate: 

  1. In the SBC 7.2.4 R0, create a Route with Destination National containing special characters.
  2. Upgrade to 8.2.4 R0.
  3. After the upgrade, the EMA should display the route.

The code is modified to support special characters in the EMA.

Workaround: The CLI can be used to view route details.

SBX-104247 | SBX-104644


2

PortFix SBX-104247: The resource memory congestion level 3 is approaching the threshold 90 sample 81.

Impact: There was a SAM Process is leaking memory when AKA is being used.

Root Cause: There was a SAM Process is leaking an AKA related structure when the code is handling an error case scenario.

Steps to Replicate: The issue cannot be reproduced.

The code is modified to correctly free the AKA structure in all scenario.

Workaround: There is no known workaround.

SBX-93898 | SBX-104516


2

PortFix SBX-93898: The "request sbx xrm debug command sec -stat gcid <gcid>" was not showing ENC and DEC details on the SBC SWe.

Impact: This debug command in unhide section is not showing all the required fields populated in the SWe SBC.

Root Cause: NP response is not framed in expected order to application layer.

Steps to Replicate: Run the SRTP call and issue this debug command for internal use.

The code is modified so the NP Response is correctly framed in expected order to application layer.

Workaround: This debug command is to see SSN field value with the RoC, all other details can be seen from show call mediastatus.

SBX-103599 | SBX-103893


2

PortFix SBX-103599; The SBC is sending multiple re-INVITEs to the ingress and egress leg during a 200 OK of INVITE answered with Dialog-1.

Impact: The SBC is sending multiple re-INVITEs to the ingress and egress side if the first forked leg is answering with a 200 OK.

Root Cause: When the 200 OK is coming without SDP, we were taking last received SDP and that precondition attributes to further processing.

Steps to Replicate: Precondition Transparency is set on both the Ingress and Egress
Steps:

UAC sends INVITE with Supported: precondition and SDP with precondition attributes.

First forked UAS sends 183 with SDP with preconditions.

Second forked UAS sends 183 with SDP with preconditions.

First forked leg send 200 OK without SDP.

Expected Behaviour:

  1. The SBC transparently passes precondition attributes in SDP.
  2. The SBC gets first forked 183 with SDP with preconditions.
  3. The SBC forwards the 183 to ingress with preconditions.
  4. The SBC sends an UPDATE to ingress and egress to complete precondition state.
  5. The SBC forward second the 183 to ingress with preconditions.
  6. The SBC sends an UPDATE to ingress and egress to complete precondition state.
  7. The SBC forwards 200 OK and get ACK.
  8. The SBC completes reINVITE-200-ACK towards egress.

The code is modified to address the issue.

Workaround: None.

CHOR-6320 | SBX-1052862

PortFix CHOR-6320: The UxPAD coredump observed on the media container while pumping 2X overload of G711U to G711U DSP (media transcoding disabled) call load.

Impact: The SWe_UXPAD crash was seen during an overload transcode test in a 2 vcpu SWe deployment in the public cloud.

Root Cause: Potential corruption in the packet buffers due to issues related to concurrency specifically in the 2 vcpu transcode overload scenarios.

Steps to Replicate: 

  1. Configure a 2 vcpu instance.
  2. Run 700 G711-G711 transcode sessions for overnight/long duration.
  3. Check if there is any UXPAD/NP crash seen.

The code is modified to fix concurrency issues in transcode call scenarios in the 2 vcpu SWe deployments.

Workaround: No workaround apart from avoiding overload scenarios for transcoded calls.

SBX-105182 | SBX-105414


2

PortFix SBX-105182: After the SBC receives RCODE = 2 from the DNS server, the SBC makes a strange query request to the DNS and subsequent new calls are rejected.

Impact: When RCODE error received for the DNS query and no other servers were available, the record was never being deleted from cache and this remained as a RECORD in "RESOLVING STATE" that impacted further queries with this domain and resulted in call failures.

Root Cause: This particular test scenario's was not covered during the testing feature.

Steps to Replicate: 

  1. Setup with EDNS supported and DNS fall back disabled.
  2. The single DNS server configured for the DNS Group.
  3. The DNS Server configured to return RCODE Error 2 for SRV Query.
  4. Setup a call that trigger NAPTR, SRV and A Query and the DNS Server responds with RCODE 2 for SVR.
  5. Modify the DNS Server to return successful RCODE for SRV.
  6. Make another call for the same domain. The call fails because the SRV record is in "RESOLVING STATE" in the cache.

The code is modified to delete cache entry (which is in "RESOLVING STATE") when the RCODE error is received.

Workaround: NA

SBX-103255



2

Enhance the sbxPerf on the SBC for lesser resource consumption.

Impact: The SBC performance monitoring tools like top and top2 at times take 20% of a CPU core there by reducing total available CPU resources for management activities on the SBC.

Root Cause: The sbxPerf that contains list of tools such as top, mpstat, and iostat currently runs periodically without any linux value configured. This can cause these processes to get prioritized and scheduled ahead of other management processes such as ConfD and SSH.

Steps to Replicate: Install fix build and ensure processes such as top, top2, mpstat sbxPerf are running with corrects value of 15 using the top command.

The code is modified so that priority of these processes are less compared to other management processes on the SBC.

Workaround: None.

SBX-74155


2

The ACL rule is missing on the SBC in LD triggered switch-overs and link recovered after.

Impact: When an IPACL rule is created that references an IP interface, but that IP interface has been down since the system started up, the rule is not successfully created.

Root Cause: When an IP interface is failed on system startup, the system does not add that interface to the kernel. When an IPACL rule is added that references that IP interface, it fails to be added to the NP.

Steps to Replicate: Start an SBC with an IP interface failed, that also has one or more IPACL rules that have been configured that reference that IP interface. Bring up the IP interface and logs will show the IPACL rules have been successfully added.

The code is modified to detect this situation and maintain a retry list. Once the IP interface comes up, it will retry the associated IPACL rules that were previously failed.

Workaround: This issue can be worked around by having IPACL rules that do not reference the IP interface.

SBX-90854


2

There was a customer call forwarding MRF interaction failure on the receipt of an UPDATE.

Impact: The SBC sends INVITE towards MRF upon receiving UPDATE from Egress End Point

Root Cause: In some situations when there is delay in incoming PRACK request (In this situation PRACK from Ingress Endpoint), some internal logic of the SBC queues the SDP on ingress leg and let's SBC answer to egress, thereby unblocking the egress peer which can send a new offer using SIP UPDATE.

This causes the SBC to send INVITE towards MRF, even before sending an UPDATE out towards the Ingress.

Steps to Replicate: Configure the PSPs accordingly:

  1. UAC sends Invite with AMR-WB, AMR, telephone-event.
  2. UAS sends 183 with SDP with AMR-WB with 100rel.
  3. UAC sends PRACK/200 OK.
  4. UAS sends 180 without SDP without 100 rel.
  5. PRACK for 180 is pending on Ingress.
  6. UAS sends UPDATE with PCMU, telephone-event.


Expected Results:
==============

  1. Upon receiving an UPDATE with PCMU, the SBC will not auto answer towards UAS.
  2. The SBC will wait for PRACK to be received from UAC, then will relay UPDATE towards UAC.
  3. Based on answer in 200 OK (Update) from UAC, the SBC will send INVITE towards MRF for reserving transcoding resources.

The code is modified to ensure that SBC does not auto answer to egress.

Workaround: None.

SBX-91111


2

The No Way Video after A/V calls is resumed after hold.

Impact: No way video after audio video call is resumed using late media re-INVITE.

Root Cause: The SBC does not send "sendrecv" in 200 OK to late media re-INVITE, instead sends the same datapath mode that was negotiated last - that is - inactive.

Steps to Replicate: Setup an audio and video call. Put the call on hold by sending a=inactive in audio and video SDP. Then, send a late media re-INVITE to take the call off-hold. The idea is that the SBC will send SendRecv for audio and video in 200 OK and let the remote end choose if it wants to remain in hold or come out.

The code is modified to send sendrecv in other streams too when call is being "may be" resumed after hold.

Workaround: Do not use late media re-INVITE to come out of hold.

SBX-92066


2

Observed a PRS process core dump "systemerror healthcheck timeout"

Impact: A PRS coredump was found due to healthcheck timeout upon executing a CLI debug command

Root Cause: The CLI debug command was taking a long time due to too many ACL entries resulting in a health check timeout.

Steps to Replicate: 

  1. Add more than 1000 ACL entries
  2. Execute below debug command:
    Run CLI debug command "request sbx xrm debug command acl\ -stat"

    NOTE: The debug commands are not available on customer sites.

The code is modified to process only 200 ACL entries to allow CLI to recover sooner.

Workaround: As we do not run debug commands on customer sites, this error should not  occur.

SBX-98843


2

There was a problem with management of the maxptime and ptime in the Direct Media mode.

Impact: There was a problem with management of maxptime and ptime in the Direct Media mode.

Root Cause: Generally, the SBC ignores the ptime value if only maxptime attribute is present in incoming SDP, If "sendPtimeInSdp" IPSP flag is enabled and peer is sending both ptime and maxptime, SBC is preferring maxptime value while sending ptime,
The existing IPSP flag "sendPtimeInSdp" makes the SBC to send out a=ptime irrespective of what we receive from the peer.

Steps to Replicate: 

  1. Do a basic call from A to B.
  2. A sends ptime=20 and maxptime=40 towards the SBC.
  3. An INVITE going out from the SBC should contain ptime=20 as we enabled both "sendPtimeInSdp" IPSP flag and "preferPtimeInSdp" TG flag.

A new flag "preferPtimeInSdp" is introduced under SBC CLI Trunk Group signaling.
If this new flag "preferPtimeInSdp" is enabled, the SBC prefers ptime value received in a=ptime over a=maxptime in incoming SDP.

This new flag "preferPtimeInSdp" needs be enabled in conjunction with existing flag "sendPtimeInSdp". If the SBC is configured to send a=ptime, then preferPtimeInSdp should be enabled on the incoming trunk and vice versa.

Workaround: None.

SBX-103704


2

The RTP sourceAddressFiltering is not working (call leg dependency).

Impact: The source address validation is not done if call flow does not involve NAPT learning. For calls that want source address validation but does not have NAPT enabled, the SBC would not validate the source address and end up forwarding the RTP packet to the other endpoint.

Root Cause: There is no way for application to inform Network Processor to validate source if NAPT learning is not enabled.

Steps to Replicate: Involves a CISCO MOH server but probably something else can be used.

The code is modified to validate source even when NAPT learning is not enabled to address the issue.

Workaround: Enable NAPT learning for the call.

SBX-102827


2

The SBC5210 upgrade failure during Starting DB_RESTORE stage.

Impact: An upgrade failure during Starting DB_RESTORE stage.

Root Cause: Creation of foreign key fails on table packet_service_profile column CODEC_ENTRY_FK9, as it had "0" in one of its rows and dbimpl.codec_entry table did not have this value.

Steps to Replicate: Upgrade a dump that has "0" in packet_service_profile.CODEC_ENTRY_FK9, it should be successful.

Before add the referential keys, the data is checked and ant value that is not there in parent table is nullified to address the issue.

Workaround: None.

SBX-103669


2

Empty "Egress Local Signaling IP Addr" field in the CDR

Impact: When an incoming call is routed out of the SBC but is then rejected by the SBC with cause 132 Module failure before a backwards response message has been received, the resulting attempt CDR has an empty "Egress Local Signaling IP Addr" field.

Root Cause: The SBC currently populates the "Egress Local Signaling IP Addr" CDR field when it processes a backwards response message for the call, and as a result the field remains empty until a backwards response message is received and processed.

Steps to Replicate: 

  1. Initiate a call by sending a valid INVITE to the SBC ingress TG to route towards the egress TG.
  2. Once the INVITE is sent to egress by SBC, put the signaling port to egress out of service.
  3. The SBC will clear the call by sending a 503 message towards egress. The resulting attemptCDR should have valid address in "Egress Local Signaling IP Addr" field.

The code is modified to populate the "Egress Local Signaling IP Addr" CDR field on sending out the egress INVITE message.

Workaround: None.

SBX-104705


2

There was a memory leak on the glusterfsd.

Impact: The OAM application cores.

Root Cause: Memory leak is observed for the glusterfsd process, that is the brick process. The use of the "gluster volume heal info" function causes the process memory usage to increase and not go down afterward.

Steps to Replicate: Ensure both Active and Standby OAM are running.
Monitor glusterfsd memory usage on both nodes.

Use the "gluster volume heal statistics heal-count" command to determine the gluster bricks heal state to address the issue.

Workaround: Reboot the OAM node.

SBX-103593


2

The SBC is ignoring Use Max Bitrate Only flag.

Impact: The SBC is ignoring Use Max Bitrate Only flag.

Root Cause: During Re-Invite answer processing, NrmaAdjustPeerT38MaxBitRate() routine is doing T38MaxBitRate adjustment based on packet size that is changing T38MaxBitRate value from 14400 to 4800.

Steps to Replicate: Call Flow:

  1. Do a basic call between UAC and UAS.
  2. The UAS sends fax re-invite to UAC with T38MaxBitrate set to 14400.
  3. The SBC sends Invite out with T38MaxBitrate set to 14400.
  4. The UAC answers with T38MaxBitrate set to 14400 in 200 OK.
  5. The SBC sends out 200 OK with T38MaxBitrate set to 4800.


Actual Result:

------UAS(Re-Invite) ---------------------------> SBC --------------------------> UAC
T38MaxBitRate:14400 T38MaxBitRate:14400
-----UAC(200 OK for Re-Invite) --------------> SBC ---------------------------> UAS
T38MaxBitRate:14400 T38MaxBitRate:4800

Expected Result:

------UAS(Re-Invite) ---------------------------> SBC --------------------------> UAC
T38MaxBitRate:14400 T38MaxBitRate:14400
-----UAC(200 OK for Re-Invite) --------------> SBC ---------------------------> UAS
T38MaxBitRate:14400 T38MaxBitRate:14400

The code is modified to relay the T38MaxBitRate in SDP, which is received from peer for Direct Media calls.

Workaround: None.

SBX-104560


2

The redirection NOA set wrong in the CDR.

Impact: The "Redirecting Orig Cd Num - NOA" subfield of "Redirection Feature Spec Data" is not set correctly in CDR record if the the Redirecting Original Called Number - NOA value has been modified by PSX.

Root Cause: The existing code was not updating the value for the CDR record based on route specific information returned from the PSX.

Steps to Replicate: Test Setup
========

  1. Test requires call routing through the PSX.
    Routing on PSX, setup to route incoming call through routing label with two routes:
    - route 1, through local egress trunk group 1 on SBC to UE2.
    - route 2, through local egress trunk group 2 on SBC to UE3.
  2. On egress trunk group 1 only, associate a DM/PM rule to change the "Number Type" to International for "redirecting Original Called Number".
  3. Set the crankback profile to enable attemptRecordGeneration and add reason 41 (503 is mapped to 41 in default SIP to CPC mapping profile)
    set profiles callRouting crankbackProfile default attemptRecordGeneration enabled reason 41

Test Procedure
============

  1. Send INVITE to the SBC ingress, INVITE should include a diversion header e.g.
    Diversion: <sip:+4969667740185@xxx.xxx.xxx.xxx>;privacy=off;screen=no;reason=unknown;counter=1
  2. Call is routed using route 1, respond from first egress with 503 Service Unavailable
  3. Call is re-routed using route 2, respond from second egress with 503 Service Unavailable
  4. Check the CDR records for call on the SBC that should have two attempt records -
    1. ATTEMPT1 - should have "Redirection Feature Spec Data" that has subfield 22 "Redirecting Orig Cd Num - NOA" as 3 (Unique International Number), because the number was updated by PSX to international.
    2. ATTEMPT2 - should have "Redirection Feature Spec Data" that has subfield 22 "Redirecting Orig Cd Num - NOA" as 2 (Unique National Number), because the number was not updated by PSX

The code is modified to populate the CDR value from the route specific data returned from PSX.

Workaround: None.

SBX-103986


2

There was an incorrect RTP time stamp in the SBC packet capture.

Impact: After an SBC upgrade to V09.01.00R001, RTP/RTCP time stamp in the SBC packet capture shows the year 2036.

Root Cause: Present logic was not considering the edge cases while checking the last modification time of the NTP log.

Steps to Replicate: 

  1. Configure a remote syslog server:
    set oam eventLog platformRsyslog linuxLogs ntpLog enabled
    set oam eventLog platformRsyslog servers server1 port 10514 protocolType udp remoteHost <remote host ip>
    com
    set oam eventLog platformRsyslog syslogState enabled
    com
  2. Create a second dummy NTP server (just to trigger some logs to be written to ntp.log):
    set system ntp serverAdmin 1.2.3.4
    com
  3. Delete the dummy NTP server:
    del system ntp serverAdmin 1.2.3.4
    com
  4. Wait at least several seconds.
  5. Repeat steps 2 and 3.

The code is modified for the edge case of NTP log last modification time.

Workaround: None.

SBX-94798


3

The MS Teams with FLRBT enabled hangs the call.

Impact: When the Force Local Ringback Tone is applied on a call that has been through SIP replace followed by SIP refer procedure, and the final trunk group has downstream forking enabled. The final 200 OK response may be queued indefinitely, meaning the call does not get completed.

Root Cause: Interactions between Force Local Ringback Tone, multi-party and downstream forking.

Steps to Replicate: 

  1. Make a SIP to SIP call.
  2. A calls B.
  3. B' replaces B.
  4. B' refers to C.
  5. The trunk for A has Force Local Ringback Tone applied.
  6. The trunk for C has downstream forking enabled.
  7. C responds with 180 with no SDP, 183 with SDP, then 200 OK.

The code is modified to prevent the queuing.

Workaround: None.

SBX-99306


3

The SIPCM (SAM) deadlock reported on SNMP request.

Impact: The SAM Process cores when getTlsStatus command is executed.

Root Cause: The issue is because when fetching the TLS Status, we were trying to access sessData that was no longer valid.

Steps to Replicate: Execute getTlsStatus command when running TLS load. SAM process cores randomly.

The code is modified to fetch the status from socketPtr instead of sessData.

Workaround: None.

SBX-100086


3

The sbxAutoBackup.sh changes for AWS SWE.

Impact: The Cloud SBC uses default system name 'vsbcSystem' when creating system backups, making it difficult to distinguish between setups.

Root Cause: The Cloud SBC configuration file backup logic uses the system name to create the back up file instead of the specific name.

Steps to Replicate: Run /opt/sonus/sbx/scripts/sbxAutoBackup.sh on the SBC running in a cloud (e.g. AWS) that has SystemName configured too something specific in user-data.

Use the actual system name (configured in user-data) in the configuration backup filename to address the issue.

Workaround: None.

SBX-910163

Unable to see the signaling messages on the PKT log file.

Impact: The Packet capture does not work properly for pkt ports.

Root Cause: The version of libpcap0.8 library in Debian9 had a defect that resulted in the capture not working.

Steps to Replicate: 

  1. Login to the SBC and run a basic call configuration.
  2. Create a signaling packet capture filter: set global callTrace signalingPacketCapture state enable devices pkt0 0.
  3. Run the SIPP calls.

Expected Results:

  1. The SBC should capture all the signaling messages on the pkt0 port in a PKT file under the gsxlog directory.

Update the libpcap0.8 to a newer version to address the issue.

Workaround: None.

SBX-74709


3

The SBC REST API. pam phase authorization failed to login through a PAM: timeout

Impact: Too many requests on the REST API interface causes 401 error.

Root Cause: Issue with third party tool ConfD that is used for configuration management.

Steps to Replicate: 

  1. Send REST API requests for long duration.
  2. Open some CLI session for some time to cause max session limit.
  3. REST APIs start failing with 401 error due to session limit, as expected.
  4. Close the CLI sessions.
  5. REST APIs keep failing, even after keeping CLI sessions under max limit.

The code is modified to fix the issue.

Workaround: None.

SBX-101408


3

The SIPREC was not working. No request sent to recorder.

Impact: Without this fix, SBC is generating INVITE towards the SIPREC SRS with bad format on SDP header line 'label'. The 'label' header is missing the CR in the CRLF line break.

Root Cause: The code that formed the SDP header line "label" does not add CR character for CRLF line break.

Steps to Replicate: Make a call that would match the configured SIPRec criteria and thus triggering a SIPRec session for the corresponding Communication Session.

The code is modified to add CR character for CRLF line break, for SDP header line "label" .

Workaround: None.

SBX-104324


3

The reenableOsAccount silently sets an account expiration to 30 days.

Impact: Using the reeanbleOsAccount will add account aging to any OS account.

Root Cause: The logic does not take into account the state of OS account aging or if OS account aging should be applied (e.g. root).

Steps to Replicate: Run with an OS account aging enabled:

  1. Test root:
    1. ReeanbleOsAccount for user root.
    2. Check no aging has been applied at OS level: chage -l root.
  2. Test the Confd user:
    1. Create user through CLI.
    2. ReeanbleOsAccount for this CLI user.
    3. Check no aging has been applied at OS level: chage -l <CLIUser>.
  3. Test OS user with a password:
    1. Create OS user with a password.
    2. Disable and then Enable OS account aging state.
    3. ReeanbleOsAccount for this OS user.
    4. Check correct aging has been applied at OS level: chage -l <OSUser>.

The code is modified in the OS account aging is enabled and is applied to the account.

Workaround: None.

SBX-97555


2

The active OAM node for the Signaling SBC generates header-only ACT files and pushing it to the billing server, where the OAM node should be responsible for the configuration only.

Impact: The active OAM node generates header-only ACT files and pushing it to billing server.

Root Cause: The SBC does not check whether it is OAM node or Managed VM while generating ACT files.

Steps to Replicate: Spawned a Nto1 OAM node, check whether .ACT files exist or not. Restart active Node, Check if any .ACT file gets created. Restart the current Active again (assigned role Standby) and check whether any .ACT file is present on OAM node or not.

Check whether VM is OAM before creating the ACT files to address the issue.

Workaround: None. 

SBX-102501


2

The SBC fails to relay embedded header in Contact of 3xx with statusCode3xx relay enabled

Impact: The SBC fails to relay embedded header in Contact of 3xx with statusCode3xx relay enabled

Root Cause: The code required to send the embedded part in contact of 3xx was not present

Steps to Replicate: 

  1. Configure the SBC for A to B call.
  2. Enable the flag statusCode3xx on egress TG IPSP.
  3. Send an INVITE from UAC.
  4. Send 300 Multiple Choice from UAS with below Contact header that has embedded headers.

The code is modified so the contact header transparency is set in the relay 3xx scenario that is now being changed to full contact header transparency and set the SIP_HEADER_URI_HEADERS so that the embedded contact header is transparently passed in the 3xx. A new header type is introduced that is set only in the relay 3xx case to send the entire contact header transparently.

Workaround: None.

SBX-102234


2

The SubsystemAdmin filter affects calltrace (TRC) logging showed useless logs.

Impact: After creating then deleting an entry in the oam eventLog subsystemAdmin, the original behaviour is not restored. INFO level events for that subsystem are no longer logged, even if the oam eventLog typeAdmin filterLevel is info.

Root Cause: Deleting an entry in oam eventLog subsystemAdmin does not restore settings back to default.

Steps to Replicate: 

  1. Create an entry for a subsystem in the oam eventLog subsystemAdmin table.
  2. Delete the entry.

The code is modified to process to deleted the oam eventLog subsystemAdmin entry so that settings are put back to default values.

Workaround: None.

SBX-86090


2

Our SIPREC implementation is prone to failure to record a stream and to tear down the SRS call leg when SRS (SIP Recording Server) sends a re-INVITE to SBC

Impact: SIPREC handling had race conditions issues in the scenario where a RE-INVITE was received on the main call and also RE-INVITE was received from SRS server at the same time.

This resulted in recording failure and the SBC sent out BYE towards SRS.

Root Cause: This race condition of RE-INIVITE from the main call end point and SRS server simultaneously was not handled on the SBC.

Steps to Replicate: 

  1. Make a SIPREC call.
  2. Send RE-INVITE with codec change/hold on main call (either from UAC or UAS) this triggers a RE-INVITE towards SRS.
  3. SRS also sends RE-INVITE at the same time when SBC receives 200 OK for main call RE-INVITE.

The RE-INVITE triggered/sent towards SRS due to the main call RE-INVITE is queued in the situation where the SIPREC leg is in middle of processing the RE-INVITE that was received from the SRS. The queued RE-INVITE would be sent once the RE-INVITE transaction received from the SRS was completed. 

Workaround: The SRS can avoid sending immediate hold RE-INVITE if no media is observed on SIPRec leg.

SBX-104093


2

The EMA codec entry screen was not usable.

Impact: The EMA codec entry screen was not usable.

Root Cause: The method call place mismatched.

Steps to Replicate: 

1. Log into EMA.
2. Navigate to Profiles > Media > Codec Entry
3. See that the screen is working correctly.

The code is modified so the EMA codec entry screen is placed at the appropriate position.

Workaround: None.

SBX-74907


2

A SIPREC Codec issue.

Impact: Without this fix, the wrong codecs are negotiated with SRS when communication sessions is renegotiated.

Root Cause: Because of wrong conditions in code, the codec information that is to be sent towards SRS is fetched from peer packet service profile rather than active service profile from the communication call leg.

Steps to Replicate: 

1. The SBC receives INVITE with G711A, G711U
2. Egress leg responds with A law and RTP stream is A law.
3. The SBC sends an INVITE to SIPRec server with G711A law and SIPRec servers responds with A law.
4. Egress leg sends re-INVITE and changes the order of codecs, G711U and G711A respectively.
5. The SBC relays the re-INVITE to ingress peer with G711U, G711A respectively and ingress peer responds with G711A.
6. The SBC was sending re-INVITE with G711U codec to SIPRec Server.
With this fix, SBC now sends re-INVITE with G711A codec to SIPRec server.

The code is modified to fetch correct codec information from the communication session and the same is sent in recording session.

Workaround: None

SBX-102993


2

The "numMatch notmatch" gets auto converted to "numMatch match" when SMM profile is modified/saved from GUI

Impact: The "numMatch notmatch" gets auto converted to "numMatch match" when SMM profile is modified/saved from GUI

Root Cause: The numMatch field was not there in the EMA.

Steps to Replicate: 

  1. Navigate SipAdaptorProfile screen. (Profiles→Signalling→SipAdaptorProfile).
  2. Create profile with the selection numMatch field.
  3. Create profiles with all possible values.
  4. Here the numMatch field was newly added.
  5. Verify whether all field values are coming properly or not.

The code is modified to address the issue.

Workaround: None.

SBX-103692


2

The SWe application will not start: The memory mismatch after a AWS instance restart.

Impact: The standby SBC shuts down if the memory product capability mismatches with the active SBC.

Root Cause: The SBC checks for a minimum required memory with the memory allocated to peer and it should be either equal or greater than the peer SBC.

Steps to Replicate: Launch the SBC HA pair on AWS to see if the memory allocated to the standby SBC is lower than an active SBC.

The code is modified to change the memory from 'Minimum required' to 'Informational' to not shut down the app in case of a mismatch and only raises a trap.

Workaround: Try rebooting in case memory allocated to standby the SBC is lower than the active SBC.

SBX-104552


2

After a switchover, the MRFP does not send a Goodbye packet for the Text stream.

Impact: When a call is using T140/TTY interworking, after a switchover RTCP bye is not sent toward the T140 stream endpoint.

Root Cause: In a T140/TTY interworking, the resource for T140 stream is not mirrored properly to standby causing deactivating does not work after a switchover.

Steps to Replicate: 

  1. Make call with T140/TTY interworking (for example, AMR-WB+T140 - PCMU).
  2. Once call is established, switchover.
  3. After a switchover was successful, end the call and see that RTCP bye is sent properly to T140 stream.

The code is modified to mirror resource correctly for T140 stream in T140/TTY interworking.

Workaround: None.

SBX-104563


2

The SBC is not updating the DNS servers order in DnsServerStatistics on deleting and creating a fresh DNS Group.

Impact: The SBC was showing the incorrect DNS Servers Index in DnsServerStatistics command "show table addressContext default dnsGroup <dnsGroupName> dnsServerStatistics " when the DNS Servers were deleted and re-created in a different order with the same server IPs.

After creating 128 DNS Servers with different unique IPs are and then deleting some of them such that the total number of DNS Servers is less than 128, no new DNS servers created post the delete operations shall have the corresponding statistics information, even though the total number of servers is less than 128 on the system.

As an example, if on the SBC we create a DNS Server with IP1 and then delete it and then proceed on to repeat the create and delete operations with different IPs say IP2 to IP128, then from the IP128 onwards, no statistics shall be displayed, even though there is only one DNS Server on the system.

Root Cause: The DNS Server Statistic blocks are not deleted when the DNS Servers are deleted and continues to remain hashed with the IP with that it was created.

Steps to Replicate: 

  1. Configure the DNSGROUP.
  2. Add the 1st DNS server with IP1 to DNSGROUP.
  3. Add the 2nd DNS server with IP2 to DNSGROUP.
  4. Check the DnsServerStatistics.
    show table addressContext default dnsGroup <dnsGroupName> dnsServerStatistics
  5. Delete the DNSGROUP.
  6. Configure the DNSGROUP.
  7. Add the 1st DNS server with IP2 to DNSGROUP.
  8. Add the 2nd DNS server with IP1 to DNSGROUP with weight1.
  9. Check the DnsServerStatistics.
  10. The IP2 should have 3 as Index and IP1 should have 4 as index in dnsServerStatistics.

The code is modified to delete the DNS Server Statistics block and remove it from the IP hash when the DNS Server is deleted.

Workaround: None.

SBX-103732


2

The  AddressSanitizer: heap-buffer-overflow on address 0x61d001429c18 at pc 0x556c876cf74c bp 0x7fb14f64fab0 sp 0x7fb14f64f260 READ of size 3488 at 0x61d001429c18 thread T21 in the SAM Process.

Impact: In a D-SBC environment while processing the remote media data command message, the SAM process could read off the end of the received message. Reading off the end of the allocated message block could, in the worst case, result in a coredump.

Root Cause: The SAM process was assuming that the size of the received message was larger than it actually was and this resulted in reading off the end of the received message buffer. In most cases, this does not cause a problem but in could potentially result in a coredump if the associated buffer is at the end of the addressable memory space.

Steps to Replicate: Run the RFC4117 test case for audio transcoding and video relay.

The code is modified to not read off the end of the received memory block.

Workaround: None.

SBX-102175


2

The HA SBC Admin Connection failure issue within sometime for the ASAN build.

Impact: In an HA setup, the standby SCM process can read off the end of a memory block. Reading off the end of allocated memory blocks can cause unexpected behaviour and in the worst case, it could result in coredumps. This problem only impacts the standby server so will not be service impacting.

Root Cause: While making P-Asserted-Id header information redundant between active and standby, the standby was reading off the end of the allocated memory buffer because the active instance had passed over a bad data length value for P-Asserted-Id header.

Steps to Replicate: Run a call load where the INVITE messages contain P-Asserted-Id header in an HA setup.

The code is modified to correctly format the P-Asserted-Id header information with valid length when sending it to the standby to avoid the standby accessing invalid memory.

Workaround: None.

SBX-105280


2

The CPX Process had a memory leak for single call on the OAM node.

Impact: The CPX process can leak small amounts of memory when creating/modifying the SNMP configuration.

Root Cause: While processing the SNMP configuration commands, the SBC was creating the temporary internal memory blocks to read and write information from/to the CDB. But it was not freeing up this memory at the end of the configuration action.

Steps to Replicate: Modify the SNMP configuration.

The code is modified to correctly free the temporary memory allocated during the configuration process.

Workaround: None.

SBX-105542


2

Fix the Customer Telecom coverity issues.

Impact: While processing the SUBSCRIBE messages, the coverity tool has highlighted that the code could dereference a pointer that is potentially null. Although no bad behaviour has been observed during testing, there is a small chance that it could result in coredumps if the pointer really was null.

Root Cause: Based on other validation in the code, the coverity highlighted that some legs of code could result in accessing a pointer that might be null. Derefencing null pointers can cause unexpected behaviour and in the worst case coredumps.

Steps to Replicate: Run various SUBSCRIBE related test cases.

The code is modified to validate that the pointer is not null before using it to avoid any potential issues/coredumps.

Workaround: None.

SBX-91127


2

The leaksanitizer had an CpxAaaGetNextEntry.

Impact: While processing the requests to display the user information/status, the Cpx process was leaking memory.

Root Cause: While processing the requests to display user information/status, the Cpx process had to allocate the internal memory blocks to collect information from CDB and was not freeing up this memory at the end of the request.

Steps to Replicate: From the CLI, run commands to request user information.

The code is modified to free up the memory at the end of the processing request.

Workaround: None.

SBX-105389


2

De-reference after a NULL check and de-reference the NULL return value.

Impact: The coverity scanning tool identified a potential edge case scenario, where the lawful intercept code could potentially access a NULL pointer leading to unexpected behaviour and potentially a coredump.

Root Cause: While the code was performing X2 peer status updates, it retrieved the peer information from a hash table but did not verify that the pointers inside the record it retrieved were valid. It would be an extreme error case for this to result in reading of a null pointer and would likely need to be due to another problem. But coverity highlights it as an edge case issue to fix up.

Steps to Replicate: Run test cases for lawful intercept using packet cable V2.0 configuration.

The code is modified to validate the pointer is not null before using it and avoid any error scenarios.

Workaround: None.

SBX-100225


2

The AddressSanitizer: detected heap-use-after-free in UasProcessMsgCmd on address 0x623000187198 at pc 0x5623cc7b3b42.

Impact: The SCM process is accessing memory after it has been freed during the timer expiry handling when there is no response to an OPTIONS message that was triggered due to debug optionsPing using an FQDN. Accessing memory after it has been freed can cause unexpected behavior and in the worst case, this potentially causes coredumps.

Ex:"request addressContext default cmds optionsPing peerFQDN bats3.gsxlab.com peerPort 14090 sigPort 2 transport udp"

Root Cause: The SIP dialog memory block was being removed in two places while handling the timeout for the debug optionsPing command, which could result in unexpected behaviour and potentially result in coredumps.

Steps to Replicate: 

  1. Run debug optionsPing command
    "request addressContext default cmds optionsPing peerFQDN bats3.gsxlab.com peerPort 14090 sigPort 2 transport udp"
  2. The OPTIONS message will be sent out.
  3. Let the options timeout. (do not send any response).

The code is modified to address the issue.

Workaround: Do not use this debug command, or use it with an IP instead of an FQDN.

SBX-105591


2

Observed that PRS process heap buffer overflow issue on 9.2 ASAN build 63

Impact: The BRM process was accessing memory after it had been freed. As the memory is being read immediately after being freed, then it is unlikely this would cause a problem.

Root Cause: If the BRM process received an unexpected message, then it was trying to print a debug message to indicate the message type. However, the message had already been freed up because it was unexpected. This was observed on the standby server and  generated at the point of switchover.

Steps to Replicate: Run a normal call load and perform switchovers.

The code is modified to collect the message type information before the message is freed so that the debug log content can be safely generated without accessing freed memory.

Workaround: None.

SBX-103650


2

The SCM Process cores when the targets set for OPTIONS/MESSAGE.

Impact: Without this fix, the SBC will core dump when the Out Of Dialogue messages like OPTIONS/MESSAGE are intercepted.

Root Cause: Double free of a data structure is causing the code dump.

Steps to Replicate: 

  1. Provision packet cable 2.0 Targets corresponding to the out of dialogue OPTIONS that will be sent to the SBC.
  2. Send the OPTIONS to the SBC.

The code is modified to avoid double freeing of the corresponding data structure. Also, addressed couple of memory leaks concerned with the same data structure in error cases such as ARS blacklisting.

Workaround: None.

SBX-103788


2

The LeakSanitizer: detected memory leaks in CpxAppProcess.

Impact: Small memory leak when making configuration changes to the GW signaling port.

Root Cause: The configuration logic was reading the interface group name from CDB into a temporary local variable in order to perform validation logic but never freed up this memory at the end of the validation.

Steps to Replicate: This issue is highlighted in the engineering lab when performing GW sig port configuration changes on an ASAN enabled build.

The code is modified to correctly free the temporary memory to avoid the leak.

Workaround: None.

SBX-105412


2

The MRFP: CE_2N_Comp_CpxAppProc leak for port SWO (BFD).

Impact: There was a small memory leak during the configuration of packet port with BFD configuration associated.

Root Cause: The configuration code was reading information from the CDB and storing information in an internal memory block but not freeing it up.

Steps to Replicate: With a BFD configuration on the SBC, disable and enable the pkt port by setting mode OOS and state disabled and then enable the pkt port again.

The code is modified to correctly release the internal memory block at the end of the configuration action.

Workaround: None.

SBX-105496


2

Fixing the NRMA coverity issue CID:11149.

Impact: The coverity scanning tool identified a potential code leg where a null pointer could be dereferenced and could potentially result in a coredump, although not observed in internal testing.

Root Cause: While trying to allocate resources for PCMU to PCMA call where the ingress leg is being tapped, there is a possibility the code could access and invalid pointer resulting in unexpected behaviour and in potential coredumps.

Steps to Replicate: This part of the code could be triggered for PCMU to PCMA call where the ingress leg is being tapped.

The code is modified to verify the pointer is not NULL before trying to use it to avoid potential coredumps.

Workaround: None.

SBX-105200


2

The AddressSanitizer: detected heap-use-after-free on address 0x6080002177a0 at pc 0x55a942cce5b1 bp 0x7fb90b2df190 sp 0x7fb90b2df188.

Impact: There were two types of issues identified in this Jira:

  1. There was a memory leak when putting a virtual media gateway in service.
  2. The MRFP is accessing memory after it is freed while cleaning up a call following an internal resource allocation failure. Accessing memory after it has been freed can have unexpected behavior and in the worst case result in coredumps.

Root Cause: 

  1. The MRFP was allocating internal memory while performing validation of the request to put a virtual media gateway inservice, but the memory was not being freed up at the end of the configuration action leading to a small memory leak.
  2. In case of internal call failure, the call data was being deleted but the memory was being access later on in the clean up procedure.

Steps to Replicate: 

  1. Configure a virtual media gateway in service.
  2. Configure the MRFP without licenses and then try to make some calls.
  1. The code is modified to free the memory at the end of the configuration action.
  2. The code is modified to no longer access the call data after is free.

Workaround: None.

SBX-104118


2

The LeakSanitizer detected memory leaks in the SCM Process.

Impact: While relaying REGISTER messages, the SBC may leak memory blocks allocated to hold the record-route header information.

Root Cause: The SBC allocates memory blocks to hold the contents of the record-route headers in the REGISTER message. But if the record-route header information is associated with the SBC IP address, then the SBC does not correctly free up the memory blocks causing a leak.

Steps to Replicate: Run test cases for stateless REGISTER relay call scenarios where the IP information in the record-route header is the SBC's IP.

The code is modified to correctly freed up memory allocated to store the record route header information.

Workaround: None.

SBX-1058502

The MRFP failed to come up after an sbxstart.

Impact: At startup of the SBC, there is a possible race condition where the SBC processes may go for an additional restart before they come up and restore the configuration. data.

Root Cause: The race condition in the code between threads.

Steps to Replicate: Installation and startup on the various platforms.

The race condition in setting some common variables is avoided by using static path of binaries to address the issue.

Workaround: None.

SBX-103626


2

Due to the Adaptive Codec Change, the MRFP does not disable the text stream although there is conflict between the payload types that the non audio and text streams use.

Impact: In a audio and T140 call setup, with Adaptive Codec Change enabled and the MRFP does not disable the text stream when there is conflict between the payload types that the audio and text streams use.

Root Cause: In the Adaptive Codec Change handling, the code does not validate if the payload type used in the T140 stream are in conflict with payload types being used in the audio stream codecs. As a result, the T140 stream is created in the media plan that should be disabled in this scenario.

Steps to Replicate: 

  1. Enable Adaptive Codec Change in the VMG configuration.
  2. Setup a call audio and T140 media streams from both call terminations: A- side AMRWB and text 140 to B side, AMR, text T140, and Telephone event.
  3. At the mid call, send a Re-Invite to change B's side to AMRWB, T140 and Telephone Event with its payload type is the same as the T140's payload type.
  4. Verify that MRFP should disable the T140 stream by setting the t140 stream port number to zero in the reply to MGC(C3).

The code is modified to check the conflict for T140 payload types against the payload types being used in an audio stream, and reject T140 stream when a conflict is found.

Workaround: None.

SBX-105039


2

The SBC fails to perform Alert-Info to PEM interworking when the relayPemState is disabled on the ingress.

Impact: The SBC fails to perform Alert-Info to PEM interworking when the relayPemState flag is disabled on the ingress TG.

Root Cause: The relayPemState flag implementation was not considered for Alert-Info to PEM Interworking scenarios.

Steps to Replicate: Configuration:

  1. The relayPemState flag is disabled on the Ingress TG.
  2. The iToPemInterworking flag is enabled on the Egress IPSP.
  3. The acceptAlertInfo flag is enabled on the Egress IPSP.
  1. The UAC sends an Invite with the SDP with PEM: supported to the SBC.
  2. The UAS sends 180 without the SDP with an alert-info as rt to the SBC.
  3. The SBC should interwork the alert-Info to PEM and insert PEM:inactive while sending 180 responses towards UAC.

The code is modified to consider the Alert-Info to PEM Interworking scenarios when the relayPemState flag is disabled.

Workaround: None.

SBX-65509


2

The preferred payload number was not used for either dtmf or amrwb when the "different2833PayloadType" transcode option is enabled.

Impact: The preferred payload number was not used for either dtmf or amrwb when the "different2833PayloadType" transcode option is enabled.

Root Cause: Both the AMR-WB and dtmf do not use 101, as 101 was being neglected and thinking the other one was using it. So at the end, it was not being considered and was not being populated.

Steps to Replicate: Make a SIPP call using AMR-WB codec with dmtf
enable different2833palyloadtype flag.
enable honorSdpClockRate flag.
set preferredRtpPayloadType as 101
set preferredRtpPayloadTypeForDtmfRelay 101

Check for the Preferred payload number.

The code is modified to scan even the workingDynamicPtSet and verify that 101 is not being used and is considered.

Workaround: The workingDynamicPTSet represents a more accurate information w.r.t the PTs used. As a result, that condition is being added to scan workingDynamicPtSet along with peer PSP and Route PSP.

SBX-104471


2

There was a CE_node error "glusterSetup.sh Abort: Mount is in bad state!!"

Impact: A glusterSetup.sh script error log showing in CE_Node log file.

Root Cause: A glusterSetup.sh script error text is printed to the terminal.

Steps to Replicate: 

  1. Shut down the Standby OAM.
  2. Ensure there is no glusterSetup.sh log appear in CE_Node log file on managed node.

The error text already captured in two separate log files, so remove the output to terminal to address the issue.

Workaround: None.

SBX-101406


2

Implement SAN validation for cert authentication in VNFR REST Server

Impact: The VNFM request did not have SAN validation in addition to a cert chain verification.

Now, the SAN validation checks against IPv4 and IPv6 both if present in userData.

Root Cause: The SAN validation was not implemented.

The SAN validation used to work only in mode(either IPv4 or IPv6) depending upon the SBC instantiation mode.

Steps to Replicate: 

  1. Bring VNFR(running HTTPS) from VNFM GR.
  2. Perform a successful reassignment.
  3. Do a sbxrestart.
  4. Again perform a successful reassignment.
  5. Bring up a dual stack VNFM, and spawn IPv4 and IPv6 SBC.
  6. Register VNFR successfully in a simplex VNFM.

Implemented SAN validation using GnuTLS that is also used for cert chain verification.
Loading both IPv4 and IPv6 from userdata addresses the issue.

Workaround: No workaround.

SBX-94760


2

The cinder volume detach/attach required a reboot from Openstack to bring up all the functioning related to the SBC.

Impact: In the case of Openstack, if cinder volume is detached from the running the SBC instance, it does not cause the SBC system to shutdown properly.

Root Cause: The shutdown triggered on the volume detach from a running instance was not going through successfully due to failure to run abnormal reboot command.

Steps to Replicate: Test cinder volume detach from a running instance and ensure the node goes for a reboot and if running on active, should switchover to standby successfully.

The code is modified to update the command to forcefully reboot the node on volume detach from a running instance.

Workaround: None.

SBX-93790


2

A TEAMS user was unable to resume the call when transfer is failed, when the call is initiated in beginning by PSTN user.

Impact: During a Refer, if the transfer target sends early answer in 18x but then rejects the call, the SBC fails to resume the previously active call.

Root Cause: During call transfer, after tone play, while processing early answer in 183, the SBC wrongly freed the previous cut-thru context and instead retains the previously activated tone context (for A-B call).

As a result, after transfer target rejects the call, the SBC attempts to resumes the previously active call (A-B) which fails due to unavailability of correct context.

Steps to Replicate: 

1. PSTN1 to TEAMS call
TEAMS transfer call to PSTN2
PSTN2 rejects the call
TEAMS resume the call

2.PSTN1 To TEAMS call
TEAMS transfer call to PSTN2
PSTN2 does not answer the call
TEAMS resume the call

The code is modified to retain the previously activated cut-thru context and free the previously activated tone context if current tone context is more recent.

Workaround: No

SBX-104331


2

Observed the "NrmUpdateLicensesForXferFeatureType cant get origGCID" MAJOR Logs on the 5400 Platform while running a call with Multiple INVITE Replace.

Impact: The Call Pickup logs were incorrectly printing a major error event.

Root Cause: The Call Pickup logs were incorrectly printing a major error event.

Steps to Replicate: None.

The code is modified to address the issue.

Workaround: None.

SBX-104738


2

The outputAdaptor profile rule gets applied after the clearDB.

Impact: The SMM rule was not applied after the upgrade from 8.2 or 9.0 or 9.1 to 9.2, even the same issue is observed during restart or switchover.

Root Cause: The SMM rule was not applied due to wrong path in the switchover scenario.

Steps to Replicate: Configure the SMM profile in the SBC.

Perform any of the of the below steps.

  1. Restart the SBC.
  2. The SBC performs a switchover.
  3. Upgrade from 8.2/9.0/9.1 to 9.2.

The code is modified to address the issue.

Workaround: ClearDB and load the configuration.

SBX-95677


2

The SBC is not feeding the delayed RBT on monitoring a failure in a late media passthrough scenario in the CLOUD ISBC and SWE ISBC.

Impact: The SBC is not feeding delayed RBT on monitoring the failure in a late media passthrough call.

Root Cause: The fix for the SBC was not feeding delayed RBT on the monitoring failure in a late media passthrough scenario was applicable only when bToneAsAnnc flag is enabled.

Steps to Replicate: Procedure:

  1. An INVITE is received without SDP and no "PEM: supported" from the UAC.
  2. The UAS sends the 183 with SDP and no PEM having PCMU, AMR.
  3. The UAC send PRACK with SDP PCMU,G729 and UAS sends 200 OK for PRACK.
  4. The UAS sends an authorized RTP.
  5. The UAS sends 180 without SDP and no PEM.
  6. The UAC send PRACK and UAS sends 200 OK for PRACK.

After a RTP Monitoring failure, the SBC should play the tone.

The code is modified to address the issue.

Workaround: None.

SBX-104136


2

Unable to login to the CLI session.

Impact: The SWe Active profile configuration may cause a password change commit to hang.

Root Cause: The Internal Configuration change related to sweActiveProfile leaves the changes in the candidate database. This causes another commit from the SM Process deadlock, as sweActiveProfile change subscription needs the SM Subscribers acknowledged.

Steps to Replicate: This cannot be recreated through User Interfaces. This was an internal error condition.

The code is modified to revert the changes from the candidate database, if the sweActiveProfile commit fails.

Workaround: None.

SBX-102958


2

The Audit Compliance issues are found in the MRFP Setup.

Impact: The Nessus Scan with the CIS Plugin shows compliance failures on the SBC.

Root Cause: The failures were due to a missing a user directory and bad file permissions.

Steps to Replicate: Run the Nessus scan with the same policy and verify that the failed compliances do not exist.

Below changes are made to meet the CIS requirements.

  1. Set nologin shell for cwagent
  2. Change remoteExecution.log file permission.

Workaround: None.

SBX-1032732

Dual NUMA support in the SWe.

Impact: The SWe does not come up in the VMs having multiple NUMA nodes except for the signaling traffic profile (SLB, S-SBC, SO-SBC).

Root Cause: Due to a deliberate software restriction to not allow multiple NUMAs, the issue was shown.

Steps to Replicate: 

  1. Configure a KVM instance with the dual NUMA and install in Non-Gold/Non-GPU setup.
  2. Let it come in default traffic profile.
  3. Verify that the SBC would come up fine without any HostCheck errors.

The code is modified to allow multiple NUMA irrespective of the personality and profile.

Workaround: None.

SBX-103627


2

The BFD status is not up for the MGMT port (the BFD packets are seen though the LDG state is disabled).

Impact: Even after disabling Link Monitor on the MGMT port, the BFD packets are still seen on the MGMT port.

Root Cause: The issue was that when state is disabled and the BFD session was deleted. A timer is started so the expiry initiates a BFD session.

Steps to Replicate: 

  1. Create BFD session for MGT port.
  2. Check the status of BFD session.
  3. Disable the BFD session.
  4. Observed the BFD packets even when the BFD session is disabled.

The code is modified to check for the Link Monitor state before initiating the BFD session.

Workaround: None.

SBX-103489


2

The LeakSanitizer: detected memory leaks at the confd_malloc.

Impact: The small memory leak during the configuration of lawful intercept server.

Root Cause: The configuration code was reading information from the CDB and storing information in an internal memory block but not freeing it up.

Steps to Replicate: Create a lawful intercept server and make configuration changes.

The code is modified to correctly release the internal memory block at the end of the configuration action.

Workaround: None.

SBX-103387


2

The Video NAT learning is failing on the D-SBC cloud.

Impact: The Video NAT learning failed in the D-SBC.

Root Cause: On the D-SBC, NAT learning for video stream was not processed successfully and as a result caused the video packets to be dropped by the SBC.

Steps to Replicate: 

  1. Configure the SBC for an Audio and Video call.
  2. Enable the Signaling NAT and Media NAT in the Ingress and Egress Trunk Groups.
  3. Make an Audio and Video call between the NATed EndPoints EP1 and EP2.
  4. After a call gets established, the EP1 and EP2 sends Audio and Video packets.
  5. NAT learning happens for Audio and Video and then the packets are sent and received from EP1 and EP2.

The code is modified to process the NAT learning for the video stream in the D-SBC.

Workaround: None.

SBX-103353


2

The AddressSanitizer: detected heap-use-after-free

/localstore/ws/jenkinsbuild/sbxmainasan/marlin/SIPSG/sipsgCallNotification.c:1123

in

SipSgSendCallNotificationApi(SIPSG_CCB_STR*, SIPSG_CALL_NOTIFY_TYPE_ENUM, sip_nameaddr_str*).

Impact: While freeing up a SIP call, the code is accessing the SIP call control memory block immediately after it has been freed up in the same processing loop.

Root Cause: This issue was detected using ASAN images, it has not been proven to cause bad behaviour using regular production images, but accessing memory after it has been freed can cause unexpected processing to happen which might potentially result in coredumps.

Steps to Replicate: Run regular call scenarios with ASAN images.

The code is modified to avoid using the memory block after it is free.

Workaround: None.

SBX-104016


2

Anomalies were observed after decoding a ACT File by sbxCamDecoder.pl.

Impact: 

Issue 1: The camDecoder script "sbxCamDecoder.pl" does not decode a reboot, the switchover records.

Issue 2: It does not display the field names under the "Ingress Signaling Information" and "Egress Signaling Information" for an EVENT records as shown below.

26. Ingress Signaling Information :
26.1 : "sip:7587339665@10.xx.xxx.xxx
26.2 : 1-23946@10.xx.xx.xxx
26.3 : <sip:sipp@10.xx.xx.xxx:xxxx>;tag=23946SIPpTag011
26.4 : <sip:7587339665@10.xx.xxx.xxx>
26.5 :
26.6 : sip:sipp@10.xx.xx.xxx:xxxx
26.7 :
26.8 :
26.9 :
26.10 : 0
26.11 :
26.12 :
26.13 :
26.14 : 1
26.15 :
26.16 :
26.17 :
26.18 :
26.19 :
26.20 :
26.21 :
26.22 :
26.23 :
26.24 :
26.25 : "

Root Cause: The sbxCamDecoder script was not updated to support the reboot, on switchover records.

Also, the script was not updated to decode "Ingress Signaling Information" and "Egress Signaling Information" for EVENT records.

Steps to Replicate: 

Issue 1: The switchover record issue.
Setup: The SBC HA
Procedure:

  1. Perform a switchover the SBC.
  2. Decode the latest ACT log that contains "SWITCHOVER" record by using the sbcCamDecoder.pl.

Issue 2: REBOOT Record issue.

  1. Reboot the SBC.
  2. Decode the latest ACT log that contains the "REBOOT" record, by using sbcCamDecoder.pl.

Issue 3:

  1. Send an OOD message (OPTIONS).
  2. Decode the latest ACT log that has the event RECORD by using the sbxCamDecoder.pl.

sbxCamDecoder was updated to support decoding REBOOT,SWITCHOVER records and the "Ingress Signaling Information" and "Egress Signaling Information" in the EVENT Records.

Workaround: Decode the record manually.

SBX-103894


2

The AddressSanitizer: detected heap-use-after-free on address 0x61b000018f84 at pc 0x556c7afd4213 bp 0x7fcbf0905680 sp 0x7fcbf0905678.

Impact: An invalid memory access of a termination object after it's been deleted. Accessing the memory after it has been freed can result in unexpected behaviour and in the worst case coredumps.

Root Cause: In the call teardown processing, after the last termination is deleted, the calltracing function was accessing the already deleted call termination object to retrieve the context ID.

Steps to Replicate: 

  1. Setup a call in MRFP.
  2. Teardown the call.
  3. The previously mentioned invalid memory access occurs in handling the deletion of the last termination of the call.

In the same function, retrieve the context ID from the context object instead to address the issue.

Workaround: None.

SBX-103814


2

The RECORDING CDR does not have correct value for the SRTP field during switchover scenario.

Impact: For the SIPREC sessions with SRTP, after a switchover the "RECORDING" CDR generated had values as 0 in the SRTP statistics fields as shown below:

24.7 ingress SRTP info1 : 0:0:0:0
24.12 egress SRTP info1 : 0:0:0:0

Root Cause: The standby processing code did not support copying the SRTP information into the SIPREC Standby data blocks and as a result was lost during a switch over.

Steps to Replicate: 

  1. Execute a SIPREC call, with a SIPREC Session over the SRTP.
  2. Perform a switchover.
  3. Verify the RECORDING CDR for SRTP Statistics in the following fields:

    24.7 ingress SRTP info1 : 0:0:0:0
    24.12 egress SRTP info1 : 0:0:0:0

The code is modified to process the SIPREC SRTP information is added.

Workaround: None.

SBX-103807


2

The SBC disables the SRTP for an audio when the EP disables and re-enables the audio.

Impact: The SBC disables the SRTP for audio when EP disables and re-enables the audio.

Root Cause: During the modify offer processing, the SRTP value is taken from previous Active security PSP without checking if the SRTP is valid or not.

Steps to Replicate: Test Procedure:

Setup Audio+Video RTP to SRTP pass-Thru call between UAC-UAS:

  1. UAC sends invite with Audio and video.
  2. UAS responds with Audio and Video cryptoline.
  3. UAC sends re-invite to disable Audio stream port=0 and inactive and Video with valid media port and sendrecv.
  4. UAS responds 200 OK with port=0, a=inactive and no crypto line for audio and video with valid port and crypto line.
  5. UAC sends re-invite to add Audio stream back with valid media port and sendrecv and video with valid media port and sendrecv.
  6. UAS responds 200 OK with valid Audio and Video crypto lines.


Expected Result:

  1. RTP-SRTP A+V call gets established.
  2. The SBC disables audio stream and sets up RTP-SRTP call with video stream.
  3. The SBC re-establishes Audio+Video RTP-SRTP call.

Actual Result:

  1. RTP-SRTP A+V call gets established.
  2. The SBC disables audio stream and sets up RTP-SRTP call with video stream.
  3. The SBC re-establishes re-Invite without SRTP for audio stream.

The code is modified to copy the Active security PSP only if the SRTP admin state is enabled.

Workaround: None.

SBX-1053102

There was a SM Process leak for the MRFP call on the MRFP active.

Impact: The redundancy group manager (RGM) that is used in conjunction with N:1 deployments has a memory leak.

Root Cause: The RGM handles the switchover and fault messages in N:1 deployments and it was not freeing up the ICM message after processing that results in a memory leak.

Steps to Replicate: This issue was observed in an MRFP configuration especially when restarted instances.

The code is modified to correctly free the ICM messages.

Workaround: None

SBX-1036032

The LeakSanitizer: detected memory leaks in the MrfRmProcessTrmAllocRpyMsg.

Impact: While testing call scenarios for RTCP for T.140 Pass-through functionality, it was observed that the SCM process could leak memory for calls associated with an MRF (external media transcoder).

Root Cause: The SBC was allocated memory while processing the SDP associated with this call but was not always freeing up the memory at the end of the call.

Steps to Replicate: Run various call scenarios with MRF where the SBC is using the SIP to allocated media resources on an external media transcoder (MRF) or T-SBC.

The code is modified to correctly free all the memory allocated for the call.

Workaround: None.

SBX-1037312

The AddressSanitizer: detected heap-buffer-overflow on address 0x61a0000cb9d9 observed in the SAM Process while running OCSP feature.

Impact: When the OCSP stapling feature is enabled on the SBC and the code was processing the response it writes to unallocated memory and in the worst case this could result in process coredumps.

Root Cause: While processing OCSP response the code was allocating a memory buffer large enough to hold the response, but then incorrectly writing one byte off the end of the memory buffer while attempt to try and null terminate the string.

Steps to Replicate: Setup - UAC > Dut<>Adapter -> UAS

  1. Create an OCSP profile by configuring the defaultResponder and stapling enabled.
  2. Attach the OCSP profile to the TLS profile configured.
  3. From Endpoint A, Intiate the TLS call with Client Hello from the SIPP UAC having OCSP parameter in it.
  4. The SBC should send server hello certifciate to the user client.

The code is modified to correctly terminate the OCSP response string without writing off the end of the memory buffer allocated to hold the response.

Workaround: None.

SBX-1038012

Observed the run time error in M-SBC "runtime error: load of value 42, which is not a valid value for type 'bool'"

Impact: The M-SBC could potentially configure the wrong data path mode for a call.

Root Cause: No issues were observed while running this functionality on a regular deployment image. But while testing with ASAN, it highlighted that some of the fields used in a call resource allocation message were not always initialized correctly, which could potentially lead to unexpected behaviour e.g. SYS_ERRs, wrong datapath mode setup.

Steps to Replicate: This issue was highlighted while while running test suite related to RFC-4117 MRF Mid-Call modification Enhancement

The code is modified to correctly initialize the resource allocation request fields to avoid issues.

Workaround: None.

SBX-98024


2

The contact header is not transparently passed when the Ingress and Egress had different transport types.

Impact: Contact header is not passed transparently from Ingress, when egress side has different transport type, even when the IPSP flag 'passCompleteContactHeader' is enabled on both ingress/egress Trunk Groups.

Root Cause: In API SipSgCheckAndSetContactHeaderTrasparency(), irrespective of transparency control is enabled/disabled, if the egress Sig Zone is MS Teams,
then contact header was not transparently passed to egress.

Steps to Replicate: 

  1. Configure, IPSP flag 'passCompleteContactHeader to enable.
  2. Attach the IPSP to both ingress/egress TG's.
  3. Set Ingress transport to TCP / Egress to TL.
  4. Create pathCheck profile with hostName 'sip.pstnhub.microsoft.com' and attach to the Teams side.
  5. Make a successful call.

The code is modified so regardless of MS Teams zone, if the transparency control flag is enabled then pass the contact header transparently to the egress.

Workaround: None.

SBX-101937


2

The one medium vulnerability found after the Qualys Scan.

Impact: A medium vulnerability found after the Qualys Scan in Jquery 3.4.1 version.

Root Cause: The jquery 3.4.1 version has security issue.

Steps to Replicate: Run a Qualys Scan and vulnerability was not shown.

The code is modified to address the issue.

Workaround: No workaround.

SBX-1027182

The Confd updateAdmin user's configuration was failing.

Impact: In cloud deployments, when a new user is created, it throws the error:
"Cannot change accountAgingState to disabled while accountRemovalState is enabled"
even though accountAgingState is set from disabled and accountRemovalState to disabled.

Root Cause: The validation logic for user creation was done along with transformation callbacks. This makes the validation logic to be order dependent.

Steps to Replicate: 

  1. Launch a cloud standalone instance.
  2. Create a new user with accountAgingState to disabled and accountRemovalState to disabled:
    commit fails with error "Cannot change accountAgingState to disabled while accountRemovalState is enabled"

The code is modified to make an order independent.

Workaround: None.

SBX-103634


2

The LeakSanitizer: detected memory leaks in DCmRestoreAllMetaVarsToStandbyContext.

Impact: A small memory leak was observed in the SAM process while performing a switchover from standby to active box.

Root Cause: The standby instance stores information about the metavars associated with signaling ports configured on the active instance. During the conversion from standby to active, the standby data is moved into active structures but the original standby memory blocks are not freed up correctly resulting in a memory leak.

Steps to Replicate: Perform a switchover from standby to active while running a basic call, no memory leak will be observed in the SAM process.

The code is modified to correctly free the memory associated with the standby data when it gets transitioned to active to avoid the memory leak.

Workaround: None.

SBX-104360


2

The SWITCHOVER ACT Records are not generated in the SBC with HA mode set as Nto1.

Impact: On an N to 1 system, the SWITCHOVER record is not written to the accounting file on the new active node after a switchover.

Root Cause: The SWITCHOVER record is sent to the ENM process before it has opened the accounting file, so the record is not written.

Steps to Replicate: 

  1. Perform a switchover a system.
  2. Check that the switchover record is written to the accounting file.

The SWITCHOVER record is stored and then written out when the accounting file is opened to address the issue.

Workaround: None.

SBX-104826


2

The SBC fails to relay to 3xx and picks the next route when Ethe nhancedLocalRedirection and StatusCode3xx flags are enabled.

Impact: The SBC fails to relay the received 3xx to the ingress side and picks the next route when the EnhancedLocalRedirection and StatusCode3xx flags are enabled with 2 routes.

Root Cause: When both the StatusCode3xx and EnhancedLocalRedirection are enabled for the 2 routes scenario, the performCrankback is set to true which leads to this issue.

Steps to Replicate: Procedure:

  1. Configure the SBC for A to B call over ERE.
  2. Configure the ERE to return two routes for Initial call R1, R2.
  3. Enable the flag statusCode3xx, EnhancedLocalRedirection on TG IPSP.
  4. Send the INVITE from UAC.
  5. Send the 300 Multiple Choice from UAS with Contact header and embedded headers.

The code is modified to ensure that performCrankback is not set to true when both the EnhancedLocalRedirection and StatusCode3xx are enabled.

Workaround: None.

SBX-91592


2

The DRBD tuning is not optimal.

Impact: On the non-cloud 1:1 SBCs, due to non-optimal tuning of the DRBD, the DRBD connection between active was getting disconnected leading to full sync and high i/o on the DRBD partition.

Root Cause: Due to the peer not responding within a certain time (ko-count * timeout), ko-count feature of DRBD was disconnecting the peer leading to full sync.

Steps to Replicate: The following are the steps to test the changes:

  1. Decrease the timeout value in the DRBD conf file.
  2. Restart the DRBD service.
  3. Resume the DRBD sync if not already enabled.
  4. Check syslog, the DRBD must not get disconnection logs.

The DRBD ko-count feature is disabled on the SBC to address the issue.

Workaround: None.

SBX-101743


2

The SBC start is showing some errors related to a serf file and config-version file.

Impact: Missing the file error printed to terminal.

Root Cause: The gluster setup script does not redirect output of 'cat' command.

Steps to Replicate: Run the sbxstop; sbxstart

The 'cat' command error output is redirected to NULL to fix the issue. 

Workaround: None.

SBX-91799


2

The segfault in pamValidator during PM login with incorrect credentials.

Impact: The segfault in pamValidator on a failed login for locked user.

Root Cause: The pamValidator defines a conversation function that is called by pam modules to exchange values. The pam module was freeing a struct member in the first call and accessing the same freed value in another call to the conversation function that was causing segmentation fault.

Steps to Replicate: Perform following steps on any of the SBC deployment and verify that segmentation fault does not happen:

## TEST 1: Ensure success for correct username and password:

  1. Encode username and password to base 64 and set as environment variables USER and PSWD example: export USER="YWRtaW4=" ; export PSWD="U29udXNAMTIz"
  2. Run pamValidator and verify it returns success.


##TEST 2: Authentication Failure for username and incorrect password:

  1. Encode the correct username and incorrect password to base64 and export as env variables USER and PSWD.
  2. Run pamValidator and verify it returns "Authentication Failure".
  3. Run pamValidator again multiple times (atleast 3 more) and verify the authentication failure and no segmentation fault.
  4. Wait for 30 seconds and try TEST#1 with the correct password and verify it succeeds.

The code is modified so the pam_response struct properly in between calls to the conversation function.

Workaround: None.

SBX-105152


2

While expecting a 200 OK to ingress endpoint, the SBC was sending BYE to the Egress endpoint.

Impact: If the Media inactivity/activity monitoring is enabled on media leg, and if media is not received at all on that leg in initial 10 seconds, then the NP sends a media inactive notification to up layer.

But later even if media starts coming to the SBC on that leg, the NP is not sending media is active now in notification to Application layer.

As a result, the application layers were closing the call based on the action configured for media inactivity (peerAbsenceTrapAndDisconnect).

Root Cause: In the call, if the media is preceded by no media for few seconds.
The call can be terminated if the peerAbsenceAction is peerAbsenceTrapAndDisconnect.

Steps to Replicate: 

  1. Configure the peerAbsenceAction as peerAbsenceTrapAndDisconnect in the PSP.
  2. After the call is established, do not stream the media for initial few seconds (this duration should be less than inactivityTimeout), start it only after few seconds.
    > set system media mediaPeerInactivity inactivityTimeout 20
    > set profiles media packetServiceProfile DEFAULT peerAbsenceAction peerAbsenceTrapAndDisconnect
  3. In this case, the pause should be less than 20 seconds.
  4. With the fix, the calls will not be terminated.

The code is modified to fix the Inactive to Active detection functionality and address the issue.

Workaround: If media is expected to come late, they should not configure the peerAbsenceAction action in PSP to peerAbsenceTrapAndDisconnect. The action can be selected as the peerAbsenceTrap or none.

SBX-1056792

The ASAN leaksanitizer detected errors in the CPX and SCM.

Impact: The SCM and CPX processes have a small memory leak while changing the IPsec and IP interface group configuration.

Root Cause: While processing configuration related commands, the SBC was reading information from CDB into temporary memory blocks but failed to release the memory at the end of the configuration action, resulting in a small memory leak.

Steps to Replicate: Make the configuration changes to IPsec and IP interface group.

The code is modified to ensure the memory is correctly freed up to avoid the leak.

Workaround: None.

SBX-1056372

The AddressSanitizer: detected heap-buffer-overflow on address 0x61b000013128 at pc 0x55e3eea0419e bp 0x7ff7a52768a0 sp 0x7ff7a5276898 in ScmProcess_0.

Impact: There was invalid memory access when the SBC receives the 500 Internal Error to REGISTER.

Root Cause: The root cause of this issue is accessing invalid memory while accessing callData, trying to read off the data from the end of memory block. It can potentially cause the coredumps if the memory block is at the edge of the accessible memory region.

Steps to Replicate: Testcase:
Description:

  1. Clean up SAs if unexpected response received

Procedure:

  1. Monitor the exchange.
  2. Send an initial reg message.
  3. Receive the 401 challenge.
  4. S-CSCF responses with 500.

Expected Results:

  1. Verify IPsec SA's deleted (ip xfrm state).

The code is modified to access the respective application data (It can be call data, registration data or subscription data) based on type of SIP message.

Workaround: None.

SBX-104990


2

In a secure call, the SBC does not increment the port number in R-URI after processing Refer.

Impact: In a secure call with TLS configured, if the call is REFERed with a REFER-TO header containing a FQDN and port number, the SBC sends out a new INVITE to specified FQDN and port number. If that INVITE fails and the SBC then sends a subsequent INVITE on the next route, it does not correctly increment the RURI port number for the TLS.

Root Cause: The SBC code does not take into account that a re-route after a REFER-TO with FQDN and port number target needs to increment the port number for TLS, if the target after the re-route is different to the original target specified in the REFER-TO.

Steps to Replicate:

  1. With the recommended SBC configuration for MS Teams with TLS enabled between the SBC and MS Teams, establish a call from the PSTN to MS Teams
  2. Send a REFER from MS Teams that includes following header: 
    REFER-TO: <sip:sip2.pstnhub.microsoft.com:xxxx;transport=tls>
  3. Based on the REFER, the SBC should route the call and send an INVITE to sip2.pstnhub.microsoft.com using port xxxx
  4. Reject this INVITE from MS Teams with a 503.
  5. The SBC should then send an INVITE out using the second route to sip3.pstnhub.microsoft.com using port xxxx.
  6. Complete the call signaling and verify referred call is established correctly.

The code is modified to increment the RURI port number for TLS if performing a re-route to a target FQDN and port number that is different to the original target specified in the REFER-TO.

Workaround: None.

SBX-104671


2

The CpxAppProc leak for the MRFP call.

Impact: During the SBC startup, the CPX process has a small memory leak.

Root Cause: During the SBC startup processing, the CPX process reads various CDB configuration and performs DB schema upgrade validation logic. As part of this processing, it was creating temporary internal memory blocks but not releasing them at the end of initialization.

Steps to Replicate: Restart the SBC after it has been configured.

The code is modified to correctly release the temporary memory blocks used for initialization processing.

Workaround: None.

SBX-105339


2

The LeakSanitizer: detected memory leaks on the active OAM.

Impact: The CPX process was leaking small amounts of memory while processing BFD configuration changes.

Root Cause: The CPX process was allocating memory in order to interact with the CDB while process BFD configuration changes. But it was not freeing up the memory at the end of the configuration action, resulting in a memory leak.

Steps to Replicate: Make configuration changes to the BFD profile.

The code is modified to correctly free the memory required to process the BFD configuration changes and avoid the memory leak.

Workaround: None.

SBX-105262


2

The SBC is sending an unexpected re-INVITE to the Egress side in the SRTP early media scenario.

Impact: The SBC is sending an unexpected re-INVITE to the Egress side in the SRTP early media scenario.

Root Cause: This issue is caused as a side-effect of SBX-103807.

Steps to Replicate: Run the following call flow:

  1. The UAC sends an INVITE with 100 rel required.
  2. The UAS sends 18x with SDP and SRTP( SHA-1-32).
  3. Ingress sends PRACK with SDP and SRTP( SHA-1-32).

Copy an active security PSP only if audio stream is present to address the issue.

Workaround: None.

SBX-104537


2

Observed SIPFE MAJOR logs on the n1-standard-4 SBC_HA_HFE_SPLIT instance.

Impact: The log was printed as major, when stale calls are present and whenever we start cleaning the stale calls, then the log is seen.

Root Cause: This log is expected when clearing any stale calls.

Steps to Replicate: Run call load and if any stale calls are seen, then this log issue is seen (only when the Minor logging is enabled).

The code is modified to address the issue.

Workaround: None.

SBX-103851


2

Observed an error "runtime error: index -20 out of bounds for type 'uint8_t [16]' " on UXPAD when running T140 call with out-of-order of T.140 packets.

Impact: If the T140 packet contains any T140block that has more than 16 characters, then a debug buffer to display the ASCII characters of T140 packet may write beyond its size.

Root Cause: The debug buffer to display ASCII characters of T140 packet is 16 bytes in size. It saves the 16 bytes of last T140block. However, the T140 packet SBC accepts allows a maximum T140block size of 36 characters. The code did not properly limit the size of buffer to copy to 16 characters.

Steps to Replicate: 

  1. Make a SIPP call (AMRNB=>G711) with t140=>baudot enabled.
  2. Send PCAP with the T140 from AMRNB termination having T140block in packet exceeding 16 bytes.
  3. There may not be any observable effect, but the debug buffer that displays ASCII characters writes beyond its bounds and corrupts some other fields in the structure.

The code is modified to limit the size of ASCII buffer to copy to 16 characters.

Workaround: None.

SBX-105270


2

There was a CpxAppProc leak for MRFP calls.

Impact: The small memory leak occurs on the SBC/MRFP nodes when action/status/stats under the node branch is accessed through the OAM node CLI or EMS.

Root Cause: Resource references are cleared mistakenly after serving the request from the OAM node.

Steps to Replicate: Execute a node branch command repeatedly and monitor the CPX process size on the target node.

The resource references are cleared only when the system is shutting down. The resources are now getting reused by subsequent requests to address the issue.

Workaround: Avoid using the node branch commands in automated/periodic operations. Manual use should work as the leak is small.

SBX-1051142

The usage of a kill command output in the active and standby CE_node logs.

Impact: The kill command usage gets printed in the CE_Node log file of the managed nodes.

Root Cause: No glusterfs process is present when the kill command is executed by the glusterSetup.sh script called by sbxConfigUpdater.sh.

Steps to Replicate: 

  1. Reboot the Standby OAM.
  2. Ensure that kill usage does not appear in the CE_Node log file of the managed nodes.

Redirect the kill command error output to /dev/null to address the issue.

Workaround: None.

SBX-105395


2

There are coverity issues in the OAMNODE.

Impact: When processing a show list command under the node branch from the OAM node, if the target node fails to read the command path in the request, the code will access memory immediately after freeing it. While in most cases this should not cause issues, accessing memory after it is freed is not good behaviour and could result in unexpected behaviour, potentially causing coredumps.

Root Cause: The error handling flow in the code is incorrect. The handling code hits some code for the success flow.

Steps to Replicate: Enter the CLI commands like "show table/status node SSBC-1 <path to some list> <partial key>" and hit "tab" for auto completion on a system with an unreliable HA network. Repeat until the target node showing this error in its DBG log:

CPX ConfdProxy::worker: could not deserialize parameter for PROXY_FIND_NEXT_REQ

The code is modified to address the issue.

Workaround: None.

SBX-103103


2

The BFD packet forwarded by the router is not received by the MRFP.

Impact: Once the BFD session is established on a port (either primary or secondary),
an immediate port switch over is followed due to the BFD packets dropped at NP for a brief amount of time (~1 second). This eventually triggers a node switchover.

Root Cause: A race condition in ACL lookup is the cause of this issue.

Steps to Replicate: 

  1. Ensure the BFD session is up on a port (either primary or secondary).
  2. Initiate a port switchover.
  3. Monitor if the BFD session comes back on the switched-over port and an immediate port switch over is not followed.

The code is modified to address the issue.

Workaround: A user ACL can be added as a workaround.

SBX-1039842

For an existing call trace, when the call trace feature is disabled on the MRFP, the MRFP should reject the trace request (in MODIFY with CALLTRACE/TRACEACTIVITYREQUEST=ON) from the C3 by sending a NOTIFY to the C3 with RES=FAILURE.

Impact: When the call trace feature is disabled in the MRFP (using CLI command: set global callTrace state disabled), and the C3 tries to enable call trace using the MODIFY command with CALLTRACE/TRACEACTIVITYREQUEST=ON, then the MRFP should reject the trace request from C3 by sending NOTIFY to C3 with {CALLTRACE/TRACACT{Stream=1,RES=FAILURE}}.

However, the MRFP (9.1 R0) is not sending any NOTIFY message for the Call Trace request received in the MODIFY command.

Root Cause: The issue was seen only when the MODIFY command does not have any SDP.

Steps to Replicate: 

  1. Disable the call trace feature, using the CLI command: set global callTrace state disabled.
  2. Establish a MRFP call for the SBC from C3 by sending two ADD termination commands.
  3. Send MOD termination command from C3 with: CALLTRACE/TRACEACTIVITYREQUEST=ON.termId ip/1/intf/3523215361{ Media { Stream = 1 { LocalControl { Mode=SendReceive,CALLTRACE/TRACEACTIVITYREQUEST=ON } } } ,Events = 1 { NT/NETFAIL , ADID/IPSTOP { DT=50 } , HANGTERM/THB { TIMERX=1800 } } ,Signals { } }
  4. Since call trace is disabled at the SBC, verify that the SBC sends a NOTIFY with res=Failure after sending a MODIFY reply.

The code is modified to send a NOTIFY for TRACEACTIVITYREQUEST when the MODIFY command does not result into any change in media parameters. The MRFP now sends a NOTIFY with RES=SUCCESS/FAILURE (based on call trace configuration) after sending reply for the MODIFY command.

Workaround: None.

SBX-104325

2

A SCM core dump was observed when multiple gateway TGs are created in a GW-GW call on a HA setup.

Impact: On a HA setup, the Standby box SCM Process dumps core when the Standby starts to sync from Active post a switch over and as a result, the switchover occurs after a scenario where Gateway TG's are created and then a GW TG with a lower index (created earlier) is deleted.

Example:

  1. Create GWTG1, GWTG2 and GWTG3.
  2. Delete GWTG2
  3. Switch over.

Root Cause: The coredump is caused due to difference in indexing the gateway TG's in active and standby boxes.

The GW TG indexes were out of sync between the Active and Standby. Active SBC had holes in the indices of the GW TGs after deletion. The Standby SBC does not have holes for the GW TGs that are present post deletion and occupy a different index when compared to active.

Steps to Replicate: 

  1. The HA setup with GW-GW configurations.
  2. Create 3 Gateway Trunkgroups: GWTG1, GWTG2 and GWTG3.
  3. Delete the GWTG2.
  4. Perform a switchover.

The code is modified to ensure that the GWTG indexes on the Active and Standby are in sync.

Workaround: None,

SBX-1046932

When multiple codecs are received in descriptor, the call is getting rejected if license of the first preferred codec is not present in the license bundle.

Impact: When the MRFP receives an ADD termination command with a list of codecs in the audio stream from the MGC, it rejects call if the license of first preferred codec is not present in the license bundle, even though MRFP could have succeeded the call with other codecs on the list.

Root Cause: The MRFP's codec filtering function chooses the first allowed codec from the list and send it to media plane without check the codec license, so that the media plane returns error in case of codec license validation failure. The call failed as a result.

Steps to Replicate: 

  1. Ensure the MRFP is up and running
  2. Generate a license xml with ONE unit of MRFP-RTU, MRFP-DSP-RTU MRFP-DSP-AMR and ZERO units MRFP-DSP-AMRWB. Install the license bundle b1 in MRFP.
  3. Place a call from endpoint with AMRWB and AMRNB in SDP in same m line
  4. Validate the call should be succeeded with AMRNB codec being used.

The code is modified so it always chooses a codec with a valid license to the media plane.

Workaround: None.

SBX-103281


2

The route data was lost after offline PM upgrade from 625R0 to 823A13.

Impact: The special character data (e.g. ?,*,#,$) is not getting migrated from the Oracle version to postgres version.

Root Cause: Special characters were causing issues with Postgres data loading.

Steps to Replicate: 

  1. Create 100+ routes that have special characters in the DN field (Domain Name) in the SBC 6.2.5.R0.
  2. Upgrade to the SBC through the PM offline upgrade to 8.0 or above.
  3. After upgrade all route data was lost while other data are unaltered.

The code is modified to address the issue.

Workaround: No workaround.

SBX-1024452

The media port range threshold alarm is not triggered after a switchover.

Impact: The sonusMrfpRealmMediaPortRangeThresholdExceededNotfication alarm does not get raised on a newly active box following a switchover, even if the conditions for the alarm are met.

Root Cause: The realm status is not getting properly mirrored to the standby box.

Steps to Replicate: 

  1. Run calls such that 90% of the ports are used and alarm is triggered.
  2. Trigger a switchover from the active MRFP.
  3. Alarm should be triggered in new active MRFP.
  1. The code is modified to check the UDP port usage, and to raise the alarm if appropriate.
  2. The code is modified to mirror realm status so that, it can be used to raise alarm when transitioning to active or when new call on SBY arrives.

Workaround: None.

SBX-104963


2

The createConfigDrive.py --file option throws an error when executing.

Impact: In the case of KVM/VMware deployments with qcow2/OVA/vmdk, the createCOnfigDrive.py script that creates the config-drive is not working with the '--file' option.

Root Cause: There was an error in handling the '--file' option

Steps to Replicate: Generate a configuration drive with the '--file' option.

The code is modified to address the issue.

Workaround: Use the '--cli' option to generate a configuration drive.

SBX-103761


2

The createConfigDrive.py --cli throws an IndentationError.

Impact: When deploying on the KVM/VMware using qcow2/OVA/VMDK and generating config-drive using createConfigDrive.py with '--cli' option, the script returns with an error.

Root Cause: There was an indentation issue in the Python code.

Steps to Replicate: Generate a config-drive with the '--cli' option and verified the generated config-drive.

The code is modified to address the issue.

Workaround: None.

SBX-1036822

The LeakSanitizer: detected memory leaks at confd_malloc

Impact: The ASAN detected memory leaks while processing the E164 profile configuration changes.

Root Cause: The code was allocating memory while processing E164Profile configuration changes but not releasing the memory at the end of the configuration action, resulting in a small memory leak.

Steps to Replicate: Create and modify the E164Profile configuration.

The code is modified to release the internal memory block at the end of the configuration action.

Workaround: None.

SBX-1038212

The AddressSanitizer: detected heap-use-after-free on address 0x6180000ed180 at pc 0x5619a742719d bp 0x7f3b04960310 sp 0x7f3b04960308.

Impact: While the MRFP node is shutting down, it can access memory after it has been freed, this could result in unexpected behaviour and in the worst case a coredump. But would have limited impact as it only occurs when shutting down.

Root Cause: During the sbxstop/sbxrestart or switchover because of race-condition, when the SBC is in deactivation the oamNodeRegisterRetry can access already deallocated resource leading to a core dump.

Steps to Replicate: 

  1. Setup a build with HA MRFP using OAM.
  2. Do the sbxrestart/switchover of an active instance.

The code is modified to handle this race condition.

Workaround: None.

SBX-105312


2

The trunkgroups are not displayed while assigning the SMM profile to TG on the EMA.

Impact: The trunkgroups are not displayed while assigning the SMM profile to TG on the EMA.

Root Cause: The dropdown height is limited, and as the result the last entry is not visible.

Steps to Replicate: 

  1. Create more than one TG.
  2. Create a SMM profile on EMA.
  3. Click on Assign SIP Adaptor Profile.
  4. Under 'Assign Message Manipulation Profile to TGs', check for Input Adaptor and Output Adaptor.

All the options should be available after performing the test steps.

The code is modified to show all the options to select.

Workaround: None.

SBX-98283


2

The SBC is unable to find the TG for in-dialog NOTIFY message when received from different IPs and the dialogTransparency flag.

Impact: When the indialog NOTIFY comes from different source IP, then the SBC is dropping the NOTIFY.

Root Cause: The existing design for OOD does not support the indialog NOTIFYs when it comes from a different source.

Steps to Replicate: 

  1. Initiate a SUBSCRIBE dialog.
  2. Send an indialog NOTIFY from a different source.

The code is modified to accept the indialog requests when the source is different.

Workaround: None.

Known Issues 

The following known issues exist in this release.


Issue ID

Sev

Problem Description

Impact/Workaround                            

SBX-1226642SRTP attributes are overlapping on RTP leg when a refresh invite comes after switchover in a HA pair

Impact Statement: When there is no security PSP attached to the RTP leg while processing, the SRTP leg is modified first. The SBC ends up retaining the SRTP attributes for the RTP leg when the standby box becomes active and no security PSP is attached to the RTP leg.

Workaround: You can remove the core from the SBC core directory. No other action is required since these types of cores do not cause the SBC's services to go down.

SBX-1119732On a LRBT with lateCrankback, the call is torn down upon Hold.

Impact Statement: If a call route advances after lateCrankback and LRBT is enabled, the call is torn down upon egress connect (200 OK) after hold/resume request.

Workaround: None.

SBX-1113512The CHM process is coring after recovering from a splitbrain.

Impact Statement: While successfully recovering from a split-brain in a specific scenario, it is sometimes noticed that a CHM coredump is created.

Workaround: None. The system does recover correctly without any manual intervention.

SBX-1101343For a T140 call - one-way audio observed if NAPT enabled on egress.

Impact Statement: If NAPT for media is enabled, the dest media port (NAPT media) stays set to 0.

Workaround: None.

SBX-103724

2

The RECORDING CDR does not have Media data and stats field in a REFER scenario case. 

Impact Statement: The Media Stats are not present in the Recording CDR when we record the C Leg.

Workaround: None.

SBX-1012262The OAM should not configure the same IP and port for two different VMGs.

Impact Statement: The mis-configuration that was using the same IpVar for two different VMGs does not throw an error in the OAM CLI.  

Workaround: None. The mis-configuration recovery requires a reboot.

SBX-1058242The glusterfs had a core dump on the Active OAM for the T-SBC post upgrade.

Impact Statement: The OAM node is using the third party package glusterfs and we are using version 3.8.8-1.  During a scenario where both OAM nodes are starting up, we may encounter an intermittent core from the glusterfs process. The OAM functionality is not impacted by this core and it does not impact the shared directory that is mounted by the gluster process. The call processing nodes that are managed by the OAM are not impacted and their configurations are unaffected.

Workaround: No workaround. The core maybe be produced during simultaneous reboot of OAM nodes but the functionality of the OAM nodes is not impacted.

SBX-1059213Reduced the configuration limits that need to be used for certain fields.

Impact Statement: The CDB schema supports larger strings than the SBC application code can currently support for the following configuration objects. This issue is due to the SBC application code not allowing for one additional character to include the string null terminator if the configuration in CDB actually contains the maximum number of characters.

The application supports the following maximum configuration limits even though the CDB schema allows an additional character.

  • addressContext/diamNode/realmRoute/realm - 128 characters
  • global/genericCodec/audioEntry/name - 49 characters
  • system/policyServer/remoteServer/fqdn - 255 characters
  • global/signaling/srvcc/stnSr - 30 characters
  • global/signaling/srvcc/eStnSr - 30 characters
  • global/signaling/srvcc/pstopSti - 30 characters
  • profiles/services/testCallNumberProfile/testCallNumber/number - 23 characters

In a future release, the application code will either be extended to allow for one more character or validated to put in place to restrict the character size to one less.

Workaround: Use the reduced size for the fields as mentioned in the Impact Statement.

SBX-990232The CE_2N_Comp_Sm Process is dumping core.

Impact Statement: The SBC coredump directory shows a SM Process coredump, but services are not affected and they keep running.

Workaround: You can remove the coredump from the SBC coredump directory. No other action is required since these types of cores do not cause the SBC services to go down.

Known Limitations

The following limitations exist in this release:

The VLAN tagged SRIOV packet interfaces are unable to ping endpoint Gateway IPs in the VMware platform because of an issue with VMware.


Description
1

The Access Control List (ACL) is not installed to configure SNMP traps for accepting traffic. A dynamic ACL is added to configure SNMP traps. An ACL must be installed for SNMP traps for accepting traffic.

2

The physical NIC connectivity must be in active state at the hypervisor level before starting the SWe instance on the SBC SWe platforms. In case of SWe instance with SR-IOV interfaces, manual restart of the SWe instance is required if physical NIC connectivity goes down while the instance is in progress.

3

The Antitrombone feature is not supported on the D-SBC.

4

The EMS identifies the nodes based on the VNFC-ID. While instantiating SBC/PSX cloud nodes, ensure that you use a unique VNFC-ID only. If you reuse an existing VNFC-ID, EMS treats this as a re-registration request and overwrites the existing data on the cloud node.

5

While configuring the SBC SWe Cloud instances, the CLIs commits successfully even if any metaVariable provided is incorrect. The SBC SWe Cloud instance cannot validate the CLIs, as the CDB configuration file is stored in the OAM Node and is shared among all the other SBC SWe Cloud instances in the cluster.

6

Editing the IP Interface is not reflected in the if configuration (ifConfig). This behavior is observed only on the S-SBC when action is set to "dryup" mode on the IP Interface. The IP address changes are not updated in the kernel and will not be displayed when ifconfig linux command is executed. In case of S-SBC, if the ipInterface configuration needs to be modified and if the action is set to "dryup" in ipInterface configuration, it must be set to "force" before disabling the ipInterface and making any changes.

7

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.

8When upgrading SBC SWe cloud instances to release 9.2.x, you must update your Heat template userdata section to include mandatory SSH key information. An issue in OpenStack requires that you use the stack-update process rather than re-launch after updating the template, which leads to a new UUID for the instance. As a result, you must regenerate and apply new license bundles to the upgraded instances during the upgrade.

Refer to Upgrading SBC SWe N:1 HA Nodes on OpenStack using Heat Templates for the relevant procedure.