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

Related Documentation

The SBC Core 08.02.xx documentation is located at the following Wiki space: SBC Core 8.2.x Documentation.

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, Westford, MA-01886, 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:

  • Warning-17-00022847: The DNS configuration parameters within the address contexts may cause certain configurations to fail during an upgrade
  • Warning-17-00022689: Duplicate Trunk Group or Zone names can cause unexpected behavior
  • 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 for SBC's deployed in a Distributed SBC (D-SBC) architecture.
  • Bulletin-18-00028529: The System Security Intrusion Detection AIDE Reports False Positive Alarms

  • Warning-20-00029689: Impact on SWe Live Software Upgrade from SBC version 8.x to 8.x
  • Warning-20-00029690: The X710 SR-IOV PKT Interface on the SBC Stops Receiving Packets Leading to Connectivity Loss with the SBC and other SBCs
  • Warning-21-00029972: The SBC upgrade may truncate the SQL configuration database due to too many historical alarms.

To view/download Ribbon announcements, do the following:

  1. Log on to the Ribbon Support Portal (https://ribboncommunications.com/services/ribbon-support-portal-login).
  2. From the Quick Access menu, click and download the "Ribbon Support Portal User Guide", and navigate to the "ANNOUNCEMENTS tab" section for instructions to search for and view announcements.

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.

Interoperability

The SBC Core software interoperates with the following:

  • SIP/H.323 compliant IADs and IP-PBXs
  • PSX Policy Server Softswitch via SIP redirects and/or Diameter+ protocol
  • SBC 9000 through SIP call signaling and Networks MCS protocol

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 SBC Core Portfolio Interoperability Matrix for the latest and minimum compatible product versions supporting the 08.02.04R000 release or refer to the following table:

08.02.04R000 SBC Core Compatibility Matrix

Compatible Ribbon Products by VersionEMSPSXGSX 9000DSINetScoreSBC 1K/2K/SWe Lite
Latest12.02.04R00012.02.04R00012.02.02R00012.00.00R0P405.01.01R00008.02.04R000
Minimum11.00.00R00009.03.06R00009.02.07R00009.03.00R00005.01.01R00007.00.00

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 .md5 files separate from the SBC Core application installation and upgrade files:

  • cloudTemplates.tar.gz
  • cloudTemplates.tar.gz.md5

SBC SWe Cloud Requirements for OpenStack

The system hosting the SBC SWe Cloud must meet the below requirements for OpenStack:

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

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

S-SBC SWe Requirement

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.

M-SBC SWe Requirement

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.

OpenStack Requirements

The SBC SWe supports the following OpenStack environments:

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

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

SBC SWe Requirements for KVM

The following table lists the server hardware requirements.

KVM Hypervisor 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, and 82599 Ethernet adapters are supported for configuring as SR-IOV and DirectPath I/O pass-through devices.


Ports

Number of ports allowed:

SBC SWe Requirements for VMWare

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:

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, and Mellanox Connect - 5x. 

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

Number of ports allowed:

Requirements for Using the Infrastructure as Code Environment with SBC SWe

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

  •  iac-1.1-20190808-060356.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 51x0/52x0, SBC 5400 and SBC 7000 software and firmware versions are required for this release. For 5xx0, the BIOS is installed during application installation; whereas, for 5400 and 7000, the BMC/BIOS is included in the firmware package and installed during the firmware upgrade. 

Required Software and Firmware Versions

Components

Software/Firmware

Version

SBC Platform

  

SBC 51x0/52x0 BMC

V03.22.00-R000

SBC 51x0/52x0 BIOSV2.7.0
SBC 5400 Firmware

BMC: V03.22.00-R000

BIOS: V1.18.0

SBC 7000 Firmware

BMC: V03.22.00-R000

BIOS: V2.14.0

SBC Application

 


Operating System (OS) Version

V07.02.04-R000
SonusDB

V08.02.04-R000

SBC Application

V08.02.04-R000

Note

The firmware package of SBC 5400 and 7000 series 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 bundle is available for download from the Customer Portal:

  • SBC5x7x_8.2
  • SBCSWe_8.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:

SBC 5000 Series (51x0/52x0) Firmware

  • firmware-5XX0-V03.22.00-R000.img

  • firmware-5XX0-V03.22.00-R000.img.md5

  • bmc5X00_v3.22.0-R0.rom.md5sum

  • bmc5X00_v3.22.0-R0.rom

SBC 5400 Firmware

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

SBC 7000 Series Firmware

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

Note

Execute the Method Of Procedure (MOP) only for upgrading the FPGA image of an SBC 7000 DSP-LC card when the SBC 7000 DSP-LC FPGA version is 0x14. The MOP can be applied at any version time, with the only restriction being that the BMC firmware version is at least 1.25.0. However, if the SBC application is running version V05.01.00R000 or higher, then the DSPs will be set to disabled and transcoding and transrating calls will fail if the SBC 7000 DSP-LC FPGA version is 0x14. Therefore, it is necessary to upgrade the SBC 7000 DSP-LC FPGA if the version is 0x14, before upgrading the SBC to 5.1.0. However, the MOP can be applied if the application version is higher than 5.1.0. Click Here to view the 550-06210_DSP-LC_FPGA_Upgrade_MOP.

SBC Core Operating System Installation Package

The ConnexIP Operating System installation package for SBC Core:

  • sbc-V08.02.04R000-connexip-os_07.02.04-R000_6_amd64.iso
  • sbc-V08.02.04R000-connexip-os_07.02.04-R000_6_amd64.iso.md5

Note

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

SBC Core Application Package

The SBC Application installation and upgrade package for SBC Core:

  • sbc-V08.02.04R000-connexip-os_07.02.04-R000_6_amd64.qcow2
  • sbc-V08.02.04R000-connexip-os_07.02.04-R000_6_amd64.qcow2.md5
  • sbc-V08.02.04R000-connexip-os_07.02.04-R000_6_amd64.ova
  • sbc-V08.02.04R000-connexip-os_07.02.04-R000_6_amd64.ova.md5
  • sbc-V08.02.04-R000.x86_64.tar.gz
  • sbc-V08.02.04-R000.x86_64.md5
  • sbc-V08.02.04-R000.x86_64.signature

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

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-V08.02.04R000-connexip-os_07.02.04-R000_6_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

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.

Note

Release 8.2 requires additional user account security practices for SBC SWe deployments in Openstack cloud environments. During upgrade of SBC SWe cloud instances deployed using Heat templates, you must use a template that includes SSH keys or passwords for the admin and linuxadmin accounts. The example Heat templates have been updated to include information on how to specify this type of data in the userdata section of a template.

Note

Once the installation or upgrade completes on the SBC 51x0 and SBC SWe platforms, the copy of the installation package (SBC Core Installation and Upgrade Package) is automatically removed from the system.

Note

Customers using network licensing mode will be converted to node locked mode (formerly legacy mode) after upgrade to the SBC 8.0.0 Release.

Note

The SBC 8.0 5xx0 and 7000 platforms may exhibit a 7% degradation of CPU performance relative to earlier releases. This is attributable to the Spectre/Meltdown security patches.

Note

For the procedure specific to SBC SWe upgrades on KVM Hypervisor or VMware to take advantage of performance improvements due to hyper-threading, refer to MOP to increase vCPUs Prior to Upgrading SBC SWe on VMware or KVM Hypervisor.

Note

In the case of a Live Software Upgrade (LSWU) from 6.0.0R000/6.0.0R001/6.0.0F001/6.0.0F002 to 8.2, The action “Perform Pre-Upgrade Checks” from PM is not supported. Please contact Ribbon Support.

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

The SBC 51xx and 52xx systems require 24GB of RAM to run 6.x code or higher. 

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:


08.02.04R000 Upgrade Information

Warning

Prior to performing an upgrade to release 08.02.04R000, usernames that do not conform to the new SBC user-naming rules must be removed to prevent upgrade failure. Upgrade can proceed successfully after removing all invalid usernames. The following user-naming rules apply:

  • Usernames can 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 in release 8.2.4R000

Warning

Prior to performing an upgrade to the 8.2 release, the dnsGroups with type mgmt must be specified/updated with the "interface" field. The steps are included in announcement "W-17-00022847".
If the above MOP is not run, the LSWU process may fail because of duplicate trunk group or zone names.

Warning

Prior to performing an upgrade to 8.2 release, the duplicate trunk groups or zones must be removed. The steps are included in announcement "W-17-00022689".

If you are upgrading from any SBC version with ePSX configuration to the 08.02.04R000 release, execute the Method of Procedure, MOP to Reconfigure SBC (with ePSX) to External PSX Prior to an Upgrade to 06.00.00R000 Release prior to performing an upgrade. For a list of supported LSWU paths, refer to Supported Upgrade Paths.

SBC SWe Pre-Upgrade Requirements

VM CPU resource allocation requirements

Starting with 4.2.4R0 release, CPU resource allocation requirements for SBC SWe VM are strictly enforced contrary to previous releases. You must review and verify these VM settings (including co-hosted VMs) against the documented "VM Configuration Recommendations" on the For VMware page in the Hardware and Software Requirements section before upgrading. If you encounter a problem, correct the CPU reservation settings as specified in step 6 of the "Adjust Resource Allocations" procedure on Creating a New SBC SWe VM Instance with VMXNET3. CPU reservation should be set as “number of vCPUs assigned to VM * physical processor CPU frequency". If VM uses the same number of vCPUs as the number of physical processors on the server, this reservation may not be possible. In this case, reduce the number of vCPUs assigned to VM by one and set the CPU reservation to the appropriate value.

When using the show table system serverSoftwareUpgradeStatus command during the upgrade, the Standby server's LSWU status will always display "Upgrading" even though the upgrade may have failed due to host checker validation. To check if host validation failed for the Standby, check for HostCheck Validation Failed message in the upgrade.out log.

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)

Warning

Prior to performing a Live Software Upgrade (LSWU), verify if the system and the databases are in sync. The steps are included in announcement "Warning-14-00020748".

Note

In this release, LSWU infrastructure is added to the Platform Manager (PM), providing the ability to perform LSWU upgrades to later releases using the PM. However, this feature is not currently supported in 4.2.x releases and should not be used at this time.


Warning

Customers who are using the SBC to interop with MS Teams need to review and compare their configuration against the latest configuration guide especially the SMM as it might result in call failures after upgrade if the older SMM is left in place. For more information, refer to SBC 8.2 - MS Teams Solution Guide.


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.


The SBC Core supports Live Software Upgrade from releases listed in the table below:

Supported Upgrade Paths

V06.xxV07.xxV08.xx
V06.00.00R000V07.00.00R000V08.00.00R000 
V06.00.00R001V07.00.00F001V08.01.00R000
V06.00.00F001V07.00.00F002V08.01.00R001
V06.00.00F002V07.00.00F003V08.01.00R002
V06.00.00F003V07.00.00F004V08.01.00R003
V06.00.00F004V07.00.00F005V08.01.00R004
V06.00.00F005V07.00.00F006V08.02.00R000
V06.00.00F006V07.01.00R000V08.02.00R001
V06.00.00F007V07.01.00R001V08.02.00R002
V06.00.00F008V07.01.00R002V08.02.00F001
V06.00.00F009V07.01.00R003 V08.02.00F002
V06.00.00F010V07.01.00R004V08.02.01R000
V06.00.00F011V07.01.00F001V08.02.01F001
V06.00.00F012V07.01.00F002V08.02.01F002
V06.00.00F013V07.01.00F003V08.02.01F003
V06.00.00F014V07.02.00R000V08.02.01R001
V06.01.00F001V07.02.00R001V08.02.02R000
V06.01.00F002V07.02.00R002V08.02.02R001
V06.01.00F003V07.02.00S809V08.02.02R002
V06.01.00R000

V07.02.00S810

V08.02.03R000
V06.01.00R001V07.02.01R000V08.02.03R001
V06.01.00R002V07.02.01R001V08.02.03F001
V06.01.00R003V07.02.01R002
V06.01.00R004V07.02.01R003
V06.01.00R005 V07.02.01R004
V06.01.00R006V07.02.01F001 
V06.01.00R007V07.02.01F002 
V06.01.00R008 V07.02.01F004 
V06.01.00R009V07.02.01F005 
V06.02.00R000V07.02.01R005
V06.02.01R000V07.02.01R006
V06.02.01R001V07.02.01R007
V06.02.01R002 V07.02.01R008
V06.02.01F001V07.02.01R009
V06.02.01F002V07.02.01R010
V06.02.01F003V07.02.02R000
V06.02.01F004V07.02.02R001
V06.02.01F005V07.02.02R002
V06.02.01F006V07.02.02R003
V06.02.01F007V07.02.02R004
V06.02.01F008V07.02.02R005
V06.02.01F009V07.02.03R000
V06.02.01F010V07.02.03R001
V06.02.01F011V07.02.03R002
V06.02.01F012V07.02.03R003
V06.02.01F014V07.02.03R004
V06.02.02R000V07.02.04R000
V06.02.02R001V07.02.04R001
V06.02.02F001V07.02.04R002
V06.02.02F002V07.02.04R003
V06.02.02F003V07.02.04R004
V06.02.02F004V07.02.05R000
V06.02.02F005V07.02.05R001
V06.02.02F006V07.02.05R002
V06.02.02F007

V06.02.02F008

V06.02.02F009

V06.02.02F010 

V06.02.02F011

V06.02.02F012

V06.02.02F013

V06.02.02F014

V06.02.02F015

V06.02.03R000

V06.02.03F001

V06.02.03F002

V06.02.03F003

V06.02.03F004

V06.02.03F005

V06.02.03F006

V06.02.03F007

V06.02.04R000

V06.02.04F001

V06.02.04F002

V06.02.05R000




New Features

New Features in Release 08.02.04R000

The following table lists and describes the new features in this release.

New Features

Issue IDFeatureDescription
SBX-94996The SBC responds incorrectly to UPDATE with mode inactive

When an ingress UPDATE message is received with a=inactive in SDP, a 2xx response for UPDATE to be sent as a=inactive in SDP.
There are two possibilities:

  • When ingress UPDATE (inactive) is received, the SBC is in tone playing state. Then the SBC will stop the tone. Ingress 2xx for update will be sent with inactive.
  • When ingress UPDATE (inactive) is received, we are not in tone playing state. Ingress 2xx for update will be sent with inactive
SBX-96989Pass Thru call, transcode on re-invite

A new SBC CLI flag is introduced as part of this JIRA, so that, when the flag is enabled, SBC sends a single codec in answer and also in modify answer towards the peer.

$$ set addressContext default zone <Zone> sipTrunkGroup <Trunk Group> signaling sendOnlySingleCodecInAns enabled/disabled

SBX-103908FQDN support for remote policy server after a switchover for hardware SBCSupport for the FQDN was originally added only for cloud-based SBCs. The SBC is enhanced to extend FQDN support to hardware-based SBC.
SBX-105965SgOaMinimizeMedia Rework

Enhancements done in the existing offer-answer minimizing logic, such that, if the SBC receives any re-INV/UPDATE on a call leg and if it identifies any difference in data path mode, codec order, new codec being added, or old codec deleted between the last sent SDP and the new SDP towards the peer, then it effectively forwards that Re-INV/UPDATE to the peer.

The above functionality can be enabled by the following SBC CLI flag as below. When the flag is disabled, the SBC works by default as per the existing offer-answer minimizing logic.

$$ set addressContext default zone <Zone> sipTrunkGroup <Trunk Group> signaling effectiveRelayOfMediaChangesFromOtherCallLeg enabled

SBX-96284 | SBX-96772 The SBC offers only the initial codec and does not relay the INVITE

For late media convert calls, the IPSP flag "Send SBCSupported Codecs For Late Media Re Invite" will be enabled to achieve the behavior below:

  • When an Invite without SDP is received, the SBC sends all possible pass thru and transcode-able codecs from the route PSP in the initial offer towards the ingress peer based on the answer from the egress peer. The SBC retains the egress answer codec precedence and add the transcode-able codecs for an Ingress leg after the pass thru codecs in 18x or 200 O.K offer towards ingress.
  • When the SBC receives Late Media REINVITE, it offers the 200 OK with all supported route PSP codecs towards the peer. The last negotiated codec for that leg(preferred codec) would be offered first followed by the rest of the codecs in the 200 O.K Offer. Once the peer answers with ACK, then the SBC sends out a REINVITE on other leg with all possible pass thru and transcode-able codecs if need be.

Note: 

With "Send SBC Supported Codecs For Late Media Re Invite" flag enabled in IP signaling profile, there is a change in the codec ordering in late media offer generated by the SBC to a late media re-invite. The last negotiated codec on that leg will be offered first, followed by the other supported codecs on that leg.

This was to optimize the offer-answer negotiation for modify call flows by offering the last negotiated/preferred codec from initial offer answer in the 200OK modify offer generated by the SBC for a late media re-invite with the aim of reducing any subsequent re-invites generated by the SBC.

SBX-104168Vulnerability in Use of JavaScript LibraryUpgraded the javascript library version to 3.4.1 to fix the vulnerability. To upgrade this javascript library, we had to upgrade jquery-ui(1.12.1) and dataTables (1.10.20).
SBX-96285Delayed offer from the called party, and the call cleared if new codec

With the feature flags enabled, for a late media Re-INVITE, the SBC allows the transition from an previously negotiated codec to a new codec.

For a late media calls, the IPSP flag "Send SBCSupported Codecs For Late Media Re Invite" can be enabled for the behavior below:

  • The SBC sends all possible pass through and transcode-able codecs from the route PSP in the initial offer towards the ingress peer based on the answer from the egress peer.
  • The SBC retains the Egress answer codec precedence and add the transcode-able codecs for Ingress leg after the pass through codecs in 200 O.K Offer towards the Ingress.
  • When the SBC receives a Late Media REINVITE, it offers the 200 OK with all supported route PSP codecs towards the peer. The last negotiated codec for that leg (preferred codec) would be offered first followed by the rest of the codecs in the 200 O.K Offer. Once the peer answers with ACK, then SBC sends out a REINVITE on another leg with all possible pass thru and transcode-able codecs if need be.

The "sendSBCSupportedCodecsForLateMediaReInvite" indication from SIPSG is passed to NRMA as part of SipSgFsmSendNrmaAlloc and it is stored under callLeg->flags for each leg.

If the flag is enabled, considering a late media invite was received on ingress leg, the offer to be sent in 200OK is generated by intersecting and augmenting the working PSP formed on an associated leg with the current leg route PSP and finally reordering the result PSP by setting the selected/preferred codec first in the codec list, followed by rest of the codecs. In case the Ingress Peer selects a different codec other than previously negotiated codec, a MODIFY OFFER is sent by SIPSG to NRMA. This results in re-INVITE with a full list of codecs towards the Egress.

SBX-96283The SBC closes a the call if the re-INVITE has a different codec than on previous established call

A call is established with one codec (say G.711a). If the INVITE comes with different codec than what is in already established codec, the SBC sends BYE instead of relying INVITE and re-negotiating on new codec.

Customer Configuration Flags:

  • Send the SBC supported codecs in late media REINVITE Enabled.
  • Send a single codec in the answer Enabled.
  • Send only Preferred codec disabled.
  • Send All allowed codec for Late/Reinvite disabled.

The existing "SendOnlyPreferredCodec" flag is not meeting the normal media and late media call requirements for the customer configuration. The above problem arises when SendOnlyPreferredCodec feature is enabled.

The customer has also requested to limit the answer path codec list from the SBC to the peer irrespective of the number of codecs in answer SDP of other leg. This feature can be enabled and disabled by the new ERE flag "SendOnlySingleCodecForAnswer" and applies to both the initial session and session modify and corrects the problem.

New Features in Previous Releases

For lists of the features in previous 8.2.x releases, refer to the following release notes:

Resolved Issues

Resolved Issues in 08.02.04R000 Release 

Severity 1 Resolved Issues

The following Severity 1 issues are resolved in this release:

Resolved Issues


Issue IDSevProblem DescriptionResolution
1SBX-1052691

The SBC crashed and a coredump occured.

Impact: The SCM process coredumps due to NULL pointer access on a pointer that has been freed due to BYE and HOLD race in a transfer call scenario.

Root Cause: There was an illegal memory access, absence of NULL check, exposed due to race condition.

Steps to Replicate: A calls B, B REFERs to C and now A and C talk. After sometime, A sends BYE and C sends re-INVITE with a=inactive at the same time.

The code is modified to address the issue.

Workaround: No workaround.

2SBX-1011611

A memory leak was observed in SAM process.

Impact: A memory leak was observed in the SAM process.

Root Cause: There is race condition in the code that handles CALL_AUDITs and CALL_CLEANUPs that can cause a memory leak.

If the response to a CALL_AUDIT takes to long, the code that handles the "late" response has allocates memory for a structure that may never get freed.

Steps to Replicate: This issue is caused by a race condition that cannot be forced and therefore we cannot specify steps to reproduce this issue.

The code is modified to add a timer every time a fault structure is allocated. When the timer expires, if the the structure still exists it is freed.

Workaround: N/A

3SBX-95983 | SBX-1033641

Portfix SBX-95983: The Customer SBC was seeing STEAL_WARNING:

Impact: Getting a steal warning at login.

Root Cause: The filtering criteria for a high steal value was not well defined.

Steps to Replicate: The script runs as a cron job. This can also be manually tested by making changes in mpstat logs.

The code is modified to detect and warn about high %steal value.

Workaround: N/A

4SBX-103629 | SBX-1036531

Portfix SBX-103629: The SIP registrations are failing. The SBC was reporting REGISTER_PARSE_ERROR and replies with SIP 500 when it receives retransmitted initial REGISTER (CSEQ 1), followed by REGISTER with Authorization header (CSEQ 1).

Impact: When the SBC recv rexmit of registration (cseq=1) after sending a 401/407, the SBC relays to the AS. At the same time, the IAD sends new registration(cseq=2) for authentication. It triggers a race condition to the SBC and response 500.

Root Cause: The SBC should relay rexmit (cseq=1) registration to the application server.

Steps to Replicate: The IAD send registration(cseq1) to AS, AS response 401 to IAD, IAD rexmit the same sceq1, and send a new sceq2 with auth header.

The code is modified to response rexmit request (cseq=1). As a result, a subsequent one cseq=2 can properly handle the relay to AS.

Workaround: N/A

5SBX-1026251

SIP calls stop when receiving a 183 (Precondition).

Impact: A call stopped working after a 183 received without SDP.

Root Cause: As part of egress precondition interworking, to negotiate the SBC should send an UPDATE to egress endpoint. When 183 received without SDP, the SBC should not try to send UPDATE. The SIPSG call state assumed an UPDATE is sent. As a result, when the next 183 is received it tried to queue the 183 assuming UPDATE is in progress.

Steps to Replicate: 

  1. Configure the SBC for precondition egress interworking call flow.
  2. Send an initial INVITE from the ingress without precondition attributes.
  3. The INVITE is sent with preconditions to egress endpoint.
  4. (1) INVITE ====>
    (2) <======= 100
    (3) <======= 181 (without Require)
  5. Send the first 183 Session progress without SDP
    (4) <======= 183 (without Require)
  6. Send the second 183 Session progress with SDP and precondition attributes.
    (5) <======= 183 (Require: 100rel,precondition)

The above 183 is not processed due to bug in the code. As a result, retransmissions are observed.
(6) <======= 183 ((5) is re-sent)
(7) <======= 183 ((5) is re-sent)

The code is modified to avoid this state transition when 183 received without SDP.

Workaround: Remove the 183 without SDP message using SMM.

6SBX-1027041

Unable to add or Edit route with # in Destination National - CLI or EMA.

Impact: User is not able to store some special characters for the destination number field in the route entity.

Root Cause: The pattern defined for the destination number field did not allow all special characters.

Steps to Replicate: Create a route with special character like #123 for the destination number field in the route entity. It should be successful after this fix.

The code is modified to allow all special characters in this field.

Workaround: N/A

7SBX-102833 | SBX-1036971

Portfix SBX-102833: MS Teams calls are dropping when placed on hold.

Impact: When MS Teams puts a call on hold and then attempts to retrieve it while the microphone is disabled, this results in the call being cleared.

Root Cause: MS Teams actions the call retrieve by sending an INVITE with replaces message to the SBC. When the microphone is disabled, this message includes a=recvonly.

The SBC sends a 200 Ok response to the INVITE with replaces with a=sendrecv, while MS Teams is expecting a=sendonly. This causes MS Teams to clear the call.

Steps to Replicate: 

1. Establish a PSTN to MS Teams call through the SBC.
2. Place call on hold from MS Teams.
3. Disable the microphone in the browser running MS Teams, and then retrieve (place off hold) the call.
4. The call is dropped.

The code is modified to respond to an INVITE with replaces containing a=recvonly with 200 OK containing a=sendonly.

Workaround: N/A

8SBX-90251 | SBX-1033621

Portfix SBX-90251: An SM process healthcheck timeout occurred during a configuration restore on the Cloud SBC.

Impact: The SM process crashes due to a healthcheck failure.

Root Cause: As part of a load configuration, the configuration tar file needs to be untared. The untaring is taking longer than the healthcheck time out, when the size is big.

Steps to Replicate: 

  1. Save the configuration.
  2. Load the configuration.
  3. Check if healthcheck failed and the SM crashed.
  4. The SM process should not have crashed and the load configuration must have been completed succesfully.

The code is modified for the running tar command so that the healthcheck does not fail during a load configuration.

Workaround: Override the healthcheck for the tar command.

9SBX-103207 | SBX-1035791

Portfix SBX-103207: The SBC SWe 8.2.0F1 duplicates audio from call B to call A.

Impact: If CN is not negotiated for G711 codec and remote peer still sends CN packets that match default CN payload type (13), then user on other end may hear cross talk audio of completely unrelated channel or hear own reflect audio.

Root Cause: When a g711 side does not negotiate CN in signaling, DSP does not initialize Comfort Noise Generation object. However, if remote peer still sends CN packet that matches the g711 SID payload type configured in PSP (default 13), DSP accepts the packet. It processes that CN packet incorrectly and as a result uses stale voice buffer which happens to be of another channel. This continues until next voice packet for that channel arrives. Hence, we happen to see cross talk audio from other call during silence period. In some cases, the user may hear own audio also and that is different manifestation of the same problem. This issue is specific to SWe.

Steps to Replicate: 

  1. Run the CN in signaling.
  2. The DSP will not initialize Comfort Noise Generation object.
  3. Send a remote peer to the CN packet that matches the g711 SID payload type configured in PSP (default 13) and the DSP accepts the packet.
  4. Process that CN packet and as a result, uses stale voice buffer that happens to be of another channel.
  5. This continues until next voice packet for that channel arrives.

The code is modified to initialize the comfort noise object even though CN is not negotiated and process the CN packets correctly.

Workaround: There are multiple workarounds for this issue:

1. Change the default payload type of comfort noise from 13 to something else (say 15) in PSP of peer that is sending CN packets. This will make DSP drop CN packets because payload type will not match. Run the PSP configurationshow

configuration profiles media packetServiceProfile G711_NONE_NONE_NONE..silenceInsertionDescriptor {g711SidRtpPayloadType 13;heartbeat enable;}

2. Enable the silence suppression on PSP of peer that is sending CN packets and keep CN payload type that matches with CN payload type.

10

SBX-94491

1

It takes 7 seconds for the standby server to detect a switchover triggered by a reboot thus delaying to time to become active (OpenStack 1:1 HA).

Impact: A switchover triggered by the reboot takes 7 seconds to be detected by the standby, increasing the switchover time and causing media takeover issues.

Root Cause: The transport protocol is responsible for noticing the peer has gone away, and with the UDP protocol used for SWe, this process takes too long.

Steps to Replicate:This does not explain the steps to take to replicate the issue. 

The code is modified to alert the peer to take over rather than relying on the transport protocol health check to timeout.

Workaround: None.

11SBX-101628 | SBX-1027091

Portfix SBX-101628: The CPX process leaks memory for a call load.

Impact: There was a memory leak in MsgClient message queue.

Root Cause: The dispatcherAgent's MsgClient was not instantiated properly, causing messages to be queued and never deleted.

Steps to Replicate: Perform traffic test with ASAN load to confirm that memory leak is no longer present.

Instantiate DispatcherAgent's MsgClient properly and to not use the message queue. Run a clear message queue in destructor of MsgClient to address the issue.

Workaround: None.

12SBX-102737 | SBX-1034831

Portfix SBX-102737: The SM Process experiences a core dump on both the active and standby after an sbxrestart.

Impact: The SM Process cores at startup due to healthcheck.

Root Cause: System_i::fillSavedConfigurations is trying to read /mnt/gfsvol1/config-versions.txt, but it is taking too long.

Steps to Replicate: 

  1. Set up the MRFP system with OAM.
  2. Perform an upgrade.
  3. Perform a system restart.

Pause healthcheck in System_i::fillSavedConfigurations to address the issue.

Workaround: Reboot the failing node.

13SBX-91476 | SBX-997001

Portfix SBX-91476: The PEM header contains a gated parameter.

Impact: The SBC is sending a gated parameter in the PEM sendrecv toward the Ingress
P-Early-Media: sendrecv gated.

Root Cause: By design if the Early Media is gated by a peer or gated locally, the SBC adds the gated parameter towards the Ingress.

Steps to Replicate: 

  1. On the Egress Leg, the earlyMedia method should be pEarlyMedia.
  2. An INVITE should be received with the P-Early-Media: supported. The tone criteria is configured to play tone with 183 message.
  3. The 183 is recvd with the P-Early-Media: inactive.
  4. The SBC starts playing the tone as tone criteria matches.
  5. The SBC sends a P-Early-Media: sendrecv,gated toward Ingress in 183.

A new flag "suppressGatedParam" is added at the TG level.
If this flag is enabled, the SBC does not add gated param towards the Ingress.

set addressContext default zone <ZONE_INGRESS> sipTrunkGroup <TG_INGRESS>media earlyMedia suppressGatedParam <enabled/disabled>

Workaround: N/A

14SBX-103948 | SBX-1039761

Portfix SBX-103948: The SBC Application is crashing when a CPaaS to PSTN call is made.

Impact: After a reboot/restart, the CPX process could not read the sdpContent values from "action/from" and "action/to" SMM definitions, as a result while applying the action during a call it does not find the sdpContent and causes a core to happen due to processing a null or incorrect value.

Root Cause: After a reboot/restart, the CPX process is unable to read/action/from/sdpContent and /action/to/sdpContent due to wrong path/invalid pointer.

Steps to Replicate: Configure the SMM rules to delete the SDP line and generate traffic to confirm it works correctly.

The code is modified to read and store the from/sdpContent and to/sdpContent correctly in the SCM Process cache.

Workaround: Disable the SMM that deletes the SDP.

15SBX-101765 | SBX-1022941

Portfix SBX-101765: The SBC is going down when running NNIProfile CLI

Impact: When the application code was reading the NNI profile from CDB, there was a memory overwrite problem.

Root Cause: The local variables that were used to store the information being read from the CDB were not large enough resulting in memory being overwritten.

Steps to Replicate: Replicate in lab environment only.

The code is modified to use large local variables to avoid the memory overwrite.

Workaround: None.

16SBX-1028371

The SipSignalingPorts OutOfService after switchover.

Impact: The SIP sigPorts stuck in OOS after a switchover.

Root Cause: Customer had the network/pkt port issue, on one of their HA node, which caused pkt port(s) to bounce randomly, i.e. pkt port went DOWN and came back UP within 2 to 3 seconds. So they have been keeping that node as standby node. They also have link detection enabled for pkt port(s) and have around 100 LIFs per pkt port, one per SIP SIGPORT. When pkt port went down, NRS delays the port down event processing for 2 second to allow link failure detection to be ready and also to avoid the race condition between NRS and LVM. When 2 second delay timer is up, NRS starts to take down affected LIFs and notifies local SIPCM and SIPFE so they can take down affected SIP SIGPORTs.

In SIPCM, all the sockets on the affected sigPort are put in a delete pending table and starts a 1 tick timer. Then the socket(s) is being deleted after 1 tick timer is up.
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.

The code is modified in the following manner:

  1. Introduced a new 1-tick timer in SIPCM_DATA_STR, activateRetryTimerId.
  2. In SipCmActivateCallSigPort(), added deletePendingSocketTable so that if sigPort is found in the table, then the 1-tick timer starts. When the timer is up, SipCmActivateCallSigPort() is invoked again. Once the sigPort is activated successfully, SIPCM notifies SIPFE as usual.

Workaround: None.

17SBX-101922 | SBX-1033701

Portfix SBX-101922: GUI CDR Configuration screen - Syslog server field can not be configured.

Impact: The server section is appearing on the CDR configuration, but the configuration does not participate in configuration.

Root Cause: The child object was added. As default behavior of the EMA, the added child object was not needed.

Steps to Replicate: Log in to the EMA and configure the CDR and ensure the Syslog configuration is not listed on the CDR configuration page.
configuration--> system provisioning --> Base provisioning --> CDR configuration.

Restricted the child object in this particular case to address the issue.

Workaround: None.

18SBX-1040151

The RE-REGISTAR was shorter than 3600 secs due to a child AoR. 

Impact: When the 200 OK response to REGISTER request contains a P-Associated-URI header, the SBC creates a child AOR and forwards all REGISTER refresh requests to the registrar (effectively disabling the SBC fast refresh response).

Root Cause: The creation of child AORs cause all REGISTER refresh requests to be sent to the registrar (effectively disabling the SBC fast refresh response).

Steps to Replicate: 

  1. Configure the SBC to perform registration.
  2. The 200 OK response to REGISTER request contains a P-ASSOCIATED-URI header.
  3. In the error case, the refresh REGISTER requests are all forwarded to the registrar.

Removed the child AOR check from SipRaRegisterRequestCompletedAorNfy(), permitting the SBC to send fast refresh responses.

Workaround: N/A

19SBX-103645 | SBX-1041871

Portfix SBX-103645: There was a a customer 81.R5 upgrade with a spiltbrain M-SBC boot issue.

Impact: One of the M-SBCs in N:1 mode is not coming up after an upgrade.

Root Cause: The M-SBC node went for multiple reboots due to a configuration profile change and split brains after an upgrade exceeding the max limit for reboot.

Steps to Replicate: Upgrade all M-SBC nodes at one time so that they all come up together.

The code is modified to avoid split brain due to nodeId/serviceId collision by informing the peer nodes about the self node's nodeId/serviceid as soon as it is allocated.

Workaround: Restart the M-SBC application manually on the node that has exceeded max reboot limit.

20SBX-98243 | SBX-997021

Portfix SBX-98243: The SIPREC Status command is not showing all four SRS servers after upgrade completes

Impact: The SIPREC status does not correctly display all SIPREC servers if the SBC does a SYNC on an HA set up when more than one SIPREC recording is active. The SYNC occurs when the standby box is restarted while the active remains up. This is not an issue if a new SIPREC call is started while the HA set up is already running in active/standby mode. This problem only impacts the status screen and not the processing of the SIPREC call.

Root Cause: After a SYNC, only one SIPREC entry is maintained in the SIPREC status on the standby server. So if a switchover then occurs, the status screen only shows one active call, although all the other active SIPREC calls are maintained correctly.

Steps to Replicate: 

  1. The HA Set up with the SIPREC (Quad or single).
    If the Quad Recording, single call is sufficient.
    If there is a Single recording, there is multiple calls with SIPREC.
  2. Trigger the SYNC (Restart the standby box).
  3. After SYNC is complete, switch over.
  4. Check the status of the recordings.

The code is modified to maintain the status information of all the SIPREC calls from the active server.

Workaround: Do not restart the standby server while there are SIPREC calls running on the active server.

21SBX-1044841

The SBC is rejecting the second Update message from the Egress as a 500 result into a call failure.

Impact: The SBC rejects the second Update from the egress due to a DLRB feature.

Root Cause: The First Update SIPS response locally 200OK but not clear the server request message. As a result, the second Update triggers a SIPS answer 500.

Steps to Replicate: Configure the DLRB, the Egress response 183 with the SDP, the first Update, and the second Update.

The code is modified so after a response 200OK, the SIPS clears the server request so it handles the subsequent one.

Workaround: Disable the DLRB.

22SBX-1011551

A DSP core occurred on the SBC.

Impact: The DSP faults with a memory fault in area that pulls buffers out of EMAC port. Suspicion is on the buffer size that is reported by EMAC buffer. These errors result in a DSP reload which is essentially ensures call continuation. Any calls which are using this DSP could have a small media outage while the DSP is reloaded.

Root Cause: The root cause is a speculation that the EMAC system is occasionally is a incorrect bufSize, similar to a bit flip.

Steps to Replicate: This issue cannot be reproduced, it is fixed based on code review and coredump backtrace.

The code is modified to look for consistency in packet size and EMAC buffer size reported. In case an inconsistency is found, the packet is rejected, avoiding illegal memory access.

Workaround: None.

23SBX-101394 | SBX-1033651

Portfix SBX-101394: The SBC restarts after receiving 3xx with the embedded Identity in Contact header.

Impact: Global-buffer-overflow error when the SBC received a 3xx with the Identity header embedded in the contact header.

Root Cause: The root cause here is that the number of elements in pstKnownTypes array are less than the length on that the loop was running on.

Steps to Replicate: 

  1. The UE1 sends an Invite to the SBC.
  2. The SBC sends an Invite to the customer UAS.
  3. The UAS-1 sends a 3xx with the Identity header embedded in the contact header.
  4. The SBC sends an ACK.

Honor Embedded Headers and Enhanced Local redirection flag are enabled in the egress TG's IPSP.

The code is modified to use the actual length of pstKnowTypes array rather than using the SIP_HEADER_MAX. Calling the SipHdrTranspGetNumKnownTypes() function returns the actual number of elements in pstKnownTypes array.

Workaround: None.

24SBX-99134 | SBX-1000381

Portfix SBX-99134: There was a SCM process coredump after a second switchover while establishing the SIP-GW-H323 call load.

Impact: During a switchover and switchback while running a load, there may be some stale entries in the SIPSG and CC control blocks. Such entries are cleared on an audit but while clearing, the SIPSG is sending CC_SG_UPD_ACCT_NFY_MSG_STR to the CC. Since the load is running a corresponding entry for the CC, the index may be allocated to a new call. As a result, the msgPtr-> gcid is not matching with the ccbPtr->gcid and the gcid stored in the SIPSG.

When the CC receives this message, the mismatch happens and it logs a SYS_ERR(SE_EVLOG, SE_CC_UNEXPECTED_DATA))

Root Cause: While performing a switchover during a high load run, the SBC should be run in normal mode instead of sensitive mode.

Steps to Replicate: In this scenario, the HA pair and a standalone SBC are used.

  1. Use the External PSX to establish SIP->GW calls on the active SBC and GW->SIP calls on a stand alone SBC.
  2. Configure the IPv4 GW Trunkgroup between an active SBC and a stand alone SBC. Originate the IPv4 SIP->GW call load on an active SBC.
  3. Terminate the IPv4 SIP call load on a stand alone SBC to handle the GW->SIP signaling call load.
  4. Successfully establish the required call load (28000 sessions).
  5. Restart the active SBC.
  6. After restart, successfully establish a required call load (28000 sessions).
  7. Then perform a second restart on the currently active SBC.
    The default active SBC should not go down.

The code is modified to not use a sys error if the GCID sent from the SIPSG in a msgPtr is different from the GCID in the ccbPtr during a switchover.

Workaround: N/A

25SBX-99600 | SBX-1000251

Portfix SBX-99600: After a switchover on SBC 5400 platform, the SCM process is coredumping, due to hitting a SYS_ERR while running in sensitive mode.

Impact: When performing a switchover and switchback while running a load, there may be some stale entries in SIPSG and CC control blocks. Such entries are cleared during an audit, but while clearing these entries, the CC is sending SG_CC_DISC_RSP_MSG to SIPSG. Since the load is running a corresponding entry of the CC , the index might be allocated to a new call. As a result of this issue, the msgPtr-> gcid is not matching with the ccbPtr->gcid in SIPSG.

When the CC receives a message, the mismatch happens and the CC logs the SYS_ERR(SE_EVLOG, SE_CC_UNEXPECTED_DATA))

Root Cause: While performing a switchover during a high load run, the SBC should be run in normal mode instead of a sensitive mode.

Steps to Replicate: 

  1. Establish total sessions of 141K call load on the Active box.
  2. Perform multiple switchovers.

Observed SCM process coredump should not be seen.

If the GCID sent from the CCin msgPtr is different from the GCID in ccbPtr during the case of a switchover, do not use a sys error to address the issue.

Workaround: N/A

26SBX-102472 | SBX-1033741

Portfix SBX-102472: ImPr Process core dumped for Default LI with IPSEC.

Impact: When a call is intercepted during switchover, the SBC throws SYS error SE_SYS_HASH_EXISTS and causes coredump.

Root Cause: If a call is intercepted during switchover, the standby SBC may have the duplicate info of the intercepted call. So it throws SYS error "SE_SYS_HASH_EXISTS"
The coredump is due to the above SYS error.

Steps to Replicate: 

  1. The SBC is configured for Default LI.
  2. Run a load of 5 cps of intercepted calls and trigger switchover on the primary SBC.
  3. The secondary SBC comes up as active but the primary SBC dumps core.

The fix is given to handle the duplicate call data of the intercepted call on the Standby SBC.

Workaround: Disable the coredump level.

27SBX-97424 | SBX-996781

Portfix SBX-97424: The SCM process core observed in the M-SBC after a switchover with the SIPREC.

Impact: The SCM Process coredump is observed in the M-SBC after a switchover when the SIPRec occurred with a stable call and BYE for the main call is triggered post switch-over.

Root Cause: The recorderType field (field describing the type of recording happening in the SBC) is not mirrored. Post switch-over once the main call is terminated, the SIPREC delete command goes from an S node to M node but this does not carry the recorderType field. When the command reaches M node from S node with recorderType set to zero, the M node accesses a NULL pointer (call data channel).

Steps to Replicate: 

  1. Establish a stable SIPRec call.
  2. Perform a switch-over.
  3. Terminate the main call.

Send a recorderType for all type of monitor commands. Add a Call Data Channel NULL check in the M node while processing a MonitorCommands.

Workaround: N/A

28SBX-1014511

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 transcoded (e.g. G711 to G729) calls that exceed threshold limits, and verify that 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: N/A

29SBX-103254 | SBX-1047741

Portfix SBX-103254: The SBC SWe experiences a call set up delay when all remote IP PEERS are provisioned with SIP OPTION Ping.

Impact: The configuration support disables the Path MTU Discovery by setting kernel parameter net.ipv4.ip_no_pmtu_disc (ipNoPmtuDisc). When the ipNoPmtuDisc is set to 2, the DF bit in IP packet header will be set 0.

Root Cause: The secure network does not support Path MTU Discovery per RFC-1191.

Steps to Replicate: Testing the Standalone SBC SWe: 

The code is modified to disable the Path MTU Discovery by setting kernel parameter net.ipv4.ip_no_pmtu_disc to 2. When set to 2, the DF bit is set to 0 for the transmitted packets on every created socket. The configuration parameter is "system admin <name of system> kernelParams ipNoPmtuDisc".

Workaround: The workaround is a hack. It can be used as a one time test only. The hack will not survive Linux reboots.
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 the SBC 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 SBC 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 SBC to be active.
6. Run customer tests.

30SBX-962391

The display-name in the Diversion header or History-info header is deleted during interworking.

Impact: The SBC does not send display name present in ingress INVITE's diversion header in history info header in egress INVITE.

The SBC does not send display name present in ingress INVITE's history info header in egress INVITE's diversion header.

Root Cause: The SBC does not consider display name when interworking between the diversion header and history info header.

Steps to Replicate: 

  1. Ensure the display name is sent in history info header of egress INVITE when the SBC is converting diversion header to history info header.
  2. The SBC should send 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.

31SBX-103492 | SBX-1035851

Portfix SBX-103492: Performance: Observed "Scm" Process core on standby box while running the load on Openstack ISBC HA.

Impact: The SCM process cores after a switchover on Standby (new active) node when running the TCP-TCP load at 100 CPS with 10 secs call hold time.

Root Cause: The issue is due to not setting the "prtSigZoneEntry->nextMnsPortPtr" when the SIP signaling port is removed.

Steps to Replicate: Perform switchover when running TCP-TCP load at 100 CPS with 10 secs CHT.

The code is modified so whenever the SIP signaling port is removed, set the prtSigZoneEntry->nextMnsPortPtr to NULL.

Workaround: None.

32SBX-104494 | SBX-1047241

Portfix SBX-104494: The PES process cored while testing the Flex AD support with ERE.

Impact: The PES process dumps core while executing an Active Directory (AD) service when no AD profile and/or AD attribute profile configured.

Root Cause: While executing the AD service, PES fetches the AD profile from cache. Since there is no AD profile was configured in this case, cache shall return NULL. The code was missing to check for NULL for the AD profile pointer and dereferencing the NULL pointer results in a coredump.

Steps to Replicate: Configure a AD number translation criteria with ingress TG as the trigger criteria type, but with no AD profile and/or AD attribute profile configured. Make a call on the ingress TG.

The code is modified to check for NULL for an AD profile and AD attribute profile. If there is no profiles configured, the control returns and the service is marked as failed.

Workaround: Configure an AD Profile and AD attribute profile so that the existing code can be executed further.

33SBX-104773 | SBX-1048001

Portfix SBX-104773: The SBC is not coming up on the VMWare when using two NUMAs.

Impact: The SBC fails to come up in the VMWare dual NUMA configuration. (cps service failed to come up)

Root Cause: As part of the CPS service, there is one init script that calculates the performance indices. In the VMWare dual NUMA scenario, the index calculator binary gets launched in the last core, which happens to be on the 2nd NUMA. Since the huge pages are reserved on NUMA0, so the index calculator binary fails (saying fails to create mbuf pool). As a result, the CPS fails to come up.

Steps to Replicate: 

  1. Install an ISO in VMWARE dual NUMA instance. Ensure the number of vcpu should be large enough so that we get 2 NUMAs in the instance.
  2. Verify if the CPS comes up by "service cps status" command.

The code is modified to always launch on the second core, to ensure the NUMA0 is always used.

Workaround: None.

34SBX-1047611

SM Process core on the Server.

Impact: The SM Process crashed while executing the "show table system syncStatus" command.

Root Cause: The shell script used to get the Oracle sync status - PolicyDBSyncStatus.sh - did not return within 10 seconds, causing a healthcheck timeout that caused the coredump.

Steps to Replicate: This problem is not reproducible.

Disable healthchecks while fetching the syncStatus to address the issue.

Workaround: None.

35SBX-959821

The SBC running version 6.2.2 cannot capture the media with MCT.

Impact: The MCT reload configuration (SBC restart or switchover) will not succeed.

Root Cause: Logic was missing during the restart in order to properly reload the MCT configuration.

Steps to Replicate: The steps are not easily producible. 

The code is modified to properly reload the MCT configuration.

Workaround: User can delete the MCT config and reconfigure it after any restart/switchover.

36SBX-911621

The PRS process cored, backtrace shows the PrsNpCoreStatusProc(), and the XSC core is spinning.

Impact: Only one customer reported this peculiar issue where the Network Processor (NP) hangs due to an interrupt generated by the internal hardware module because a zero length packet request was sent.
This caused the module to lock up and NP is no longer able to transmit any packets.

Root Cause: We were never able to find anything in the code that would send a packet with zero length.

Steps to Replicate: You really cannot test this change without damaging the Network Processor.
The zero-length check was tested by adding debug code that would force a zero-length check and handle the interrupt.

The code is modified to log the event and not submit the zero length packet to the hardware module. The added code also handles the interrupt and continue running.

Workaround: None.

37SBX-1044431

The SM process and CPX cores prevented the server to come back up as standby after switchover.

Impact: The SM process and CPX processes cored on slot 1 after LDG triggered switchover to slot 2.
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. I do not have steps to re-produce or verify the fix.
Suggest to run full regression test with switchovers.

The code is modified to release the smNtpLock_ after issued NTP restart command.

Workaround: None.

38SBX-104769 | SBX-1050811

Portfix SBX-104769: The SCM process cored while testing the SBX H323 Conformance and Interworking.

Impact: The SCM process will core for the RFC 2833 to Inband DTMF in SIP to H323 interworking call scenario.

Root Cause: Accessing of a NULL pointer caused the core dump.

Steps to Replicate: Run a SIP-H323 interworking call with SIP side rfc2833 and the H323 side Inband DTMF being enabled.

The code is modified to check the NULL pointer before accessing it.

Workaround: None.

39SBX-1051561

The SBC was sending m=application 0 UDP/BFCP (null).

Impact: The SBC generates the syntax error m-line UDP/BFCP in 183.

Root Cause: The SBC accesses initializes data when the format m-line for UDP/BFCP.

Steps to Replicate: An incoming call with the m-line UDP/BFCP. ERE/PSX using script NO_ROUTE and triggers an announcement. The internal 183 has m-line UDP/BFCP with invalid syntax.

Make m-line initialize properly to address the issue.

Workaround: Use the SMM to correct m-line syntax error

40SBX-1050191

Crosstalk issue on the SBC 5400.

Impact: When a transcoded call with Opus codec and the Opus termination does not send any packets to the SBC, then another termination of Opus call may hear the audio from another unrelated Opus-transcoded call or it may hear white noise.

This occurs on the SBC5x10/5400/7K but not on the SWe platforms.

This problem only occurs if no Opus packet is received. When the decoder receives the first Opus packet, then subsequently the problem does not happen for that call.

Root Cause: Initially, when no packet is received, the Opus decoder is not called. As a result the decoder's output buffer is uninitialized and it happened to be a stale buffer of another Opus call or a leftover buffer of a previous Opus call on that DSP. That buffer is used to encode data for other leg of the Opus call and that results in cross talk audio or distorted noise to other termination of Opus call.

Steps to Replicate: 

  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 the same DSP core and you may not see the same problem.
  3. Call 1 sends audio packet (.pcap) from Opus termination but call 2 does not send any packets to the SBC from its Opus termination.
  4. Call 2's g711 termination will hear audio from call 1's Opus termination.

Clear the buffer (with silence) when the Opus decoder is not primed with any packet to address the issue. 

Workaround

  1. Use a different codec other than Opus.
  2. Use SWe platform instead of h/w SBC5x10/5400/7K
41SBX-1048021

Enabling the Dialog Transparency causes calls to fail.

Impact: A call fails for dialog transparency and forking.

Root Cause: When the ingress support prack and multiple 18x fork, the SBC fails to send 200OK to ingress.

Steps to Replicate: 

  1. Configure the dialog transparency and downstream forking on egress.
  2. The Ingress support prack, egress not support prack.
  3. The Egress answer 180fork1, 180fork2, 180fork3, and 200OKfork2 simultaneously.

The code is modified to address the issue.

Workaround: Disable the dialog transparency.

42SBX-103553 | SBX-1051581

Portfix SBX-103553: The SBC does not allow multiple 183.

Impact: A GSX-GW-SBX call erroneously queues a 183 message on the SBC when the X-Service-Type precondition is received and the downstream forking is enabled.

Root Cause: The interaction between the downstream forking and GW-GW code.

Steps to Replicate:

  1. Make a GSX -> SBX SIP-GW-SIP call.
    The Egress trunk group has X-Headers supported.
    The Egress trunk group has downstream forking enabled.
  2. 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
  3. The final 183 is queued.

The code is modified to not perform queueing in GW-GW scenarios.

Workaround: None.

43SBX-1053511

The SCM process cored.

Impact: The SCM process cores after long extensive load of an OOD relay.

Root Cause: The SBC accesses an invalid pointer of link list when the cleanup relay control block.

Steps to Replicate: The issue is not easily reproducible.

The code is modified to properly initialize the link list.

Workaround: None.

44 SBX-104934 | SBX-1052541

Portfix SBX-104934: The SBC generates the same ICID for more than 1 call, porting the fix for SBX-101887 into 8.2.3F1 did not help.

Impact: Duplicate the ICID generated for two different calls.

Root Cause: The instance specific value is set to 0 every other call causing the ICID generation to always use 0 in all instances. This results in the same ICID generated in more than one SCM instance when the calls land within the same microsecond.

Steps to Replicate: Configure the SBC to generate ICID on the egress side. Run a call load and check for duplicate ICIDs.

The code is modified to manipulate the last octet of the MAC address used in ICID generation.

Workaround: None.

45SBX-104688 | SBX-1053901

Portfix SBX-104688: There was a configuration import issue.

Impact: The fields that support \r like regex fields, changes it to \n after configuration Import (XML based).

Root Cause: The \r is not xml encoded when parsing the intermediate xml file.

Steps to Replicate: 

  1. Create SMM Profile with regex that has \r.
  2. Export the configuration as xml-tar.
  3. Clear the DB.
  4. Import the configuration.
  5. Verify SMM profile regex field.

The code is modified to handle the \r as a special case.

Workaround: None.

46SBX-1054101

The SBC does not select DNS servers in the correct ratio when all weights are set to a value of 1 or 100.

Impact: When multiple DNS Server in a DNS Group are configured with weight = 1 then one of the DNS Sever does not get any traffic.

Root Cause: Off by one error in handling of DNS load distribution logic.

Steps to Replicate: 

  1. The SBC is configured with DNS Group which has 2 DNS servers with priority = 0 and weight = 1.
  2. Make multiple calls that requires FQDN resolution to reach out DNS Servers.
  3. Monitor the DNS server Statistics and note one of the DNS sever is not used.
    show status addressContext default dnsGroup DnsGrp dnsServerStatistics.

If the weight = 1 for all the server SBC does not do a hard round robin for load balancing.

The load balancing depends on the random value generated but it is expected that for a large number of samples the load will be almost evenly distributed between the servers.

The code is modified to handle this scenario.

Workaround: Avoid configuring DNS servers with weight = 1 and recommended to use higher weight values as workaround.

47SBX-1038811

The Qseries CDR field not matching Qseries format.

Impact: When the rn parameter is received as part of SIP R-URI, this value is being used to populate field 10 of the QSBC format CDR record, rather than the received Called Number

Root Cause: In case of rn parameter received, the source for field 10 of QSBC CDR is incorrect.

Steps to Replicate: Send a SIP INVITE with R-URI including rn parameter.

The code is modified so if the rn is received, field 10 of QSBC is populated with the "Called Number Before Translation" (field 24 of Ribbon format CDR). For other scenarios, field 10 is populated as before.

Workaround: None.

48SBX-1052411

The SCM Process core dumped in the SIGABRT.

Impact: The SCM has cored due to a memory corruption issue.

Root Cause: The SCM core is the result of a memory corruption caused by a function that is overwriting the end of the buffer that it allocated.

Steps to Replicate: This issue is not reproducible.

The code is modified to prevent the function from overwriting the end of the buffer it allocated.

Workaround: N/A

49SBX-102082 | SBX-1055561

Portfix SBX-102082: An SCM coredump observed when the REGISTER is received and the useRandomUserInfoInContactHdr is enabled.

Impact: There was an invalid memory access issue when both embeddedRegInfoinUserPart and useRandomUserInfoInContactHdr flag were enabled.

Root Cause: In the SBC appropriate memory was not allocated for the contactUrl puchUsername in case both embeddedRegInfoinUserPart and useRandomUserInfoInContactHdr flag were enabled, due to this invalid memory access was happening.

Steps to Replicate: 

  1. Enable the remoteDeviceType to access.
  2. Enable the embeddedRegInfoinUserPart flag as:-
    set addressContext <ADDRESS_CONTEXT> zone <ZONE> sipTrunkGroup <TG> signaling embeddedRegInfoinUserPart enabled
  3. Enable the useRandomUserinfoInContactHeader as :-
    set addressContext <ADDRESS_CONTEXT> zone <ZONE> sipTrunkGroup <TG> signaling useRandomUserInfoInContactHdr enabled

The code is modified to allocate the appropriate memory for puchUsername based on embeddedRegInfoinUserPart or useRandomUserInfoInContactHdr enable case.

Workaround: As per the SBC design anyone of the below flags should be enable not both.

50SBX-1058881

The SBC is sending the wrong TO tag to the AS side.

Impact: The response 200OK for multiple Notify's has an invalid ToTag.

Root Cause: There was an internal logical error when processing the second 200OK Notify from AS. The application had a misinterpretation of the direction for the relay message as an IAD and through passing down the wrong data down to SIPS for relaying 200OK to AS.

Steps to Replicate: Subscribe the IAD to AS. The AS sends multiple Notify immediately one after another.
The second 200OK of Notify sends to AS has a wrong ToTag.

The code is modified so that the SBC passes the correct data down to SIPS.

Workaround: The peer can send 1 Notify at a time. N/A on the SBC.

51SBX-1059891

After a cleanDb, a user is unable to login to the KVM SBC as an admin user using keys.

Impact: The datasourceList was set to 'None' for KVM platform. After running the clearDB, the cloud-init was not having any datasource to read the ssh keys.

Root Cause: The change introduced as part of Jira SBX-88682 caused this issue.

Steps to Replicate: Instantiate VM on KVM with ssh keys configured for access to linuxadmin and admin. Perform clearDB and try to login with in ssh keys to admin and linuxadmin.

The code is modified to use 'NoCloud' Data source to address the issue.

Workaround: Remove '/etc/cloud/cloud.cfg.d/99-datasource.cfg' file before doing clearDB.

52SBX-1059171

The SBC fails to relay 4xx-6xx responses when IPTG authentication is enabled after 100 trying

Impact: When IPTG authentication is enabled, the SBC maps all 4xx-6xx SIP codes to CPC 176. As a result, the SBC is unable to relay cause code from egress to ingress endpoint. Example: 486 Busy Cause code was not relayed to ingress side.

Root Cause: When IPTG authentication is enabled, the SBC maps all 4xx-6xx SIP codes to CPC 176.

Steps to Replicate: 

  1. Reproduce the issue. With IPTG authentication feature enabled as below, the SBC sends INVITE with Authorization header as response to 407 from egress. However, when the egress sends 486 BUSY as a response to Authorization INVITE, the SBC does not transparently send 486 towards ingress endpoint.
  2. Verify the issue. The SBC correctly sent 486 BUSY received from egress to ingress.

The code is modified so the SBC, upon receipt of error code other than 401 and 407 clears the authentication flag and relays the actual cause code from egress to ingress

Workaround: Use CPC mapping to map CPC code 176 to required SIP cause code.

53SBX-1061781

There was a switchover // sonusCpSystemProcessCoredumpGeneratedNotification.

Impact: The SCM process has cored.

Root Cause: The SCM has cored when attempting to write a log message because the code is attempting to de-reference a NULL pointer to access information for the log message.

Steps to Replicate: There are no specific steps for reproducing this issue. This core will only happen in a multi-transfer scenario.

The code is modified to check that the pointer is non-NULL before de-referencing it.

Workaround: There is no workaround. This core will only happen in a multi-transfer scenario.

54SBX-1052761

Filtering does not work on the Cleared Alarm List.

Impact: Filtering does not work on the Cleared Alarm List.

Root Cause: There is an order mismatch before applying the time filter and after applying the filter.

Steps to Replicate: 

  1. Log in to EMA.
  2. Navigate to Monitoring->Alarms->Cleared Alarms.
  3. After that, apply the time filter (from -time -> to- time). Then we are able to see the correct order of time.

The code is modified to address the issue.

Workaround: None.

55SBX-103974 | SBX-1042121

Portfix SBX-103974: The STI sends 2 Identity fields in Contact header, but SBC only passes one

Impact: In the case where multiple "Identity Headers" are present as embedded headers in a 3xx "Contact Header", the SBC sends out only 1 Identity Header for the re-directed INVITE.

Root Cause: The SBC did not support handling of the scenario where SIP headers are repeated in embedded contact headers in 3xx. The SBC would end up the sending only the last of the repeated headers in the re-directed Invite.

Steps to Replicate: 

  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: 1234567890<sip:1234567890@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.

56SBX-1062241

The customer SBC failover with SCM Process core due to Memory corruption.

Impact: When prack enable on ingress and advanced SMM for "variableScopeValue message" enable, the SBC may core when Egress responses 18x/2xx too fast trigger delay on ingress due to prack pending.

Root Cause: On ingress when 18x/2xx is queuing, it did not allocate proper resources for "variableScope" data. By the time it start to send out, the SBC access garbage data.

Steps to Replicate: This is random issue so may/may not reproducible.
In the Egress: inbound config variableScopeValue message and send to ingress.
In the Ingress: prack enable, outbound read the var1 and append to the userName of To Header.
Egress: Send multiple 18x/200 fast will trigger some delay on ingress for sending. Run load.

Properly allocated resource for "variableScope" data to address the issue.

Workaround: Disable prack.

57SBX-1059611

The SBC reinvite with sendonly causing one-way audio.

Impact: The SBC unexpectedly send out reInvite sendonly when relay DPM is disabled.

Root Cause: There was an internal logical error to queue the sdp on ingress when egress send 18x (sendonly)

Steps to Replicate: 

  1. Enable minimize and disable relay DPM on ingress.
  2. 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 disable, the SBC should not change the direction of datapath on ingress.

Workaround: n/a. This is application bug per rfc, and the SDP should not change in subsequent 18x.

58SBX-1064781

A SAM Process core dump was seen while executing OCSP stapling feature.

Impact: The SAM Process cores randomly when running a TLS call with the OCSP Stapling enabled.

Root Cause: Periodically, the SIPCM finds socketPtr to be NULL that is causing an invalid access of a NULL pointer.

Steps to Replicate: Running a TLS call with OCSP Stapling enabled.

The code is modified to check a NULL for the socketPtr.

Workaround: When the OCSP Stapling is disabled, the SAM process does not core.

59SBX-100237 | SBX-1034821

Portfix SBX-100237: The CpxApp process is dumping the core on the managed node when callMediaStatus CLI is run from OAM node.

Impact: There was a CpxAppProc core when accessing the callMediaStatus of managed VMs from OAM through the node branch.

Root Cause: There was a data serialization bug that caused the issue.

Steps to Replicate: Access the callMediaStatus of managed VM from OAM through node branch.

The code is modified to address the core issue.

Workaround: None.

60SBX-101407 | SBX-1034811

Portfix SBX-101407: The CpxApp process is dumping the core on the managed node when we get the NTP from OAM node.

Impact: The CpxProcess cores on an application shutdown.

Root Cause: There was an improper ConfdProxy object destruction.

Steps to Replicate: Stop the application while the traffic load is running is best to reproduce.

The code is modified to properly delete the ConfdProxy object.

Workaround: None.

61SBX-104015 | SBX-1042751

Portfix SBX-104015: The RE-REGISTAR was shorter than 3600 secs due to the child AoR. There needs to be more detail about this behavior.

Impact: When the 200 OK response to REGISTER request contains a P-Associated-URI
header, the SBC creates a child AOR and forwards all REGISTER refresh requests to the registrar (effectively disabling the SBC fast refresh response).

Root Cause: The creation of child AORs cause all REGISTER refresh requests to be sent to the registrar (effectively disabling SBC fast refresh response).

Steps to Replicate: 

  1. Configure the SBC to perform registration.
  2. The 200 OK response to REGISTER request contains the P-ASSOCIATED-URI header.
  3. In the error case, the refresh REGISTER requests are all forwarded to the registrar.

Removed the child AOR check from SipRaRegisterRequestCompletedAorNfy(), permitting the SBC to send a fast refresh responses.

Workaround: None.

Severity 2-4 Resolved Issues

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

Resolved Issues

Issue IDSevProblem DescriptionResolution
SBX-921143

Calculated the size of a buffer as too small and error logs were being generated post upgrade.

Impact: Removes this incorrect log message:

SipsRedGetCallControlSizeCmd()
Minor .SIPSG: *SipsRedMirrorCallControlCmd: Potential for buffer
format ERROR. Available:16076 Calculated:383 Packed:277

Root Cause: This message is logged incorrectly when the code is calculating the size for a Redundancy message.

Steps to Replicate: The steps cannot be replicated.

The code is modified to remove this incorrect log message:

SipsRedGetCallControlSizeCmd()
Minor .SIPSG: *SipsRedMirrorCallControlCmd: Potential for buffer
format ERROR. Available:16076 Calculated:383 Packed:277

Workaround: N/A

SBX-102629

2

PRS process memory leak for object based messages.

Impact: There was a slow memory leak in PRS.

Root Cause: Object based messages are not properly being deallocated. This leaked both fm fault notifications and fp stats request messages.

Steps to Replicate: Overtime watch PRS memory size increase.

The code is modified to properly free the messages.

Workaround: No workaround.

SBX-1021152

The SBC modifies the Replaces parameter with the wrong Call-ID and tags if the Replaced call was looped back to the SBC through a SIP Proxy that does not modify SIP Call-ID and tags.

Impact: Relay a refer with replaces for loopback call, the SBC picks up the wrong call leg.

Root Cause: The SBC query for the replaces callId, and found matching both legs (loopback).The SBC pick up the wrong leg.

Steps to Replicate: This is specific to customer call flow.

If loopback is detected, only pick the one with to-tag match local-tag. This is per RFC-3891, section 3.

Workaround: N/A

SBX-1032812

The Route data lost after the offline PM upgrade from 625R0 to 823A13.

Impact: The special character data was not getting migrated to postgres version.

Root Cause: The special character was causing issues with the Postgres data loading.

Steps to Replicate: 

  1. Created 100+ routes that have special chars in its DN in 625R0.
  2. Upgraded to 823A13 through the PM offline upgrade.
  3. After an upgrade, all route data was lost while other data are unaltered.
  4. System is up and services are running but no clue of route data.

The code is modified to escape the special characters.

Workaround: No workaround.

SBX-100910 | SBX-1033672

Portfix SBX-100910: A CE_2N_Comp_CcsP coredump is seen in SWE after disabling the interface.

Impact: A CCS Process coredump was observed due to a healthcheck failure. This occurred while the software was establishing a connection to the third-party software serf, which it starts up to detect and communicate with other nodes in the cluster.

Root Cause: The healthcheck failure occurs when a software object does not respond quickly enough to a health check message. This occurs because the software was waiting for serf to finish starting up and did not respond to the message in time.

Steps to Replicate: Stop/start the SBC with the networking down or disable/enable the interfaces on a running system. These steps will trigger the code to start up serf and reconnect to it.

The code is modified to introduce a new timer for when the serf is started up, to allow the software to remain responsive to other messages. As an added precaution, healthchecks are temporarily disabled while connecting to serf, to avoid any chance of a healthcheck failure.

Workaround: N/A

SBX-101803 | SBX-1033822

Portfix SBX-101803: The SBC is not sending a 400 Bad request for the From tag length more than 272.

Impact: The SBC is not sending a 400 Bad request when the From tag has length more than 272, though the logs show 095 07132020 161318.327763:1.01.00.45444.Info .SIPCM: *SipsParseMessage: from tag too long.

Root Cause: As part of SBX-89384 fix, the SipCmSendIncomingPduUind is modified to add a dscpValue. But in the case of a SIP parse failure, while calling the SipCmSendIncomingPduUind in SipCmProcessRemotePdu, the DSCP value is wrongly placed in the position of receiveFlags. The receiveFlags is setting the value of the DSCP, which is 46, enables the SIP_AKA_SECURITY_ENABLED and the value of receiveFlags is wrongly given to the cmFeFlags. As a result, the flag is set and it is dropping the pdu before sending 400.

Steps to Replicate: 

  1. Configure the SBC for the SIP-SIP call listed below:
    EP1 --> SIP --> SBC --> SIP --> EP2
  2. The client sends an INVITE message to the SBC with a From tag length equal to 273 and a DSCP value.

The code is modified to correct the position of a DSCP value while calling the SipCmSendIncomingPduUind in SipCmProcessRemotePdu.

Workaround: N/A

SBX-1035602

There was a content type pattern match failure in an INVITE sent to the second SBC in a GW GW call.

Impact: The message body is not sent transparently for the Resource/Lists, QSIG Content-Type: multipart/mixed when the HTP is enabled for all.

Root Cause: A fix to SBX-100989 jira broke the existing functionality and caused this issue.

Steps to Replicate: TEST SET UP

===========UAC ==> SBC5xx0 --SBX 5xx0 ==> UAS

Prerequisite:
============

  1.  Create the GW-GW set up (SBC-SBC).

Test Specific Configuration:
=========================

  1.  Create a header transparency profile on the second SBC and attach to the egress TG.
    set profiles services transparencyProfile HTP1 sipMessageBody all
    set addressContext default zone ZONE2_TRANSGW sipTrunkGroup PERTRANSGW_SBX_EXT services transparencyProfile HTP1

Test Steps:
==========

  1.  Run a basic call over SBC-SBC (GW-GW) and check if the resource/lists, QSIG content type header is transparently passed in the outgoing INVITE towards egress side.

Expected Results:

  1. The SBC-SBC (GW-GW) call should be successful.
  2. Check if the transparency is successful over the GW-GW.

The code is modified for the Allow message body QSIG Content-Type: multipart/mixed, Resource/Lists across GW-GW.

Workaround: N/A

SBX-103098

2

The To tag in To header is corrupted when the SBC forwards the OOD Message.

Impact: The To Tag in OOD messages from the registered users are getting corrupted when relayed.

Root Cause: This is because of a logic issue in the stack function.

Steps to Replicate:

1. Register an End Point.
2. Send a MESSAGE request from same source IP/Port from registered endpoint.
3. Perform a switchover.
4. Send a MESSAGE request from same source IP/Port from registered endpoint.
5. Send a MESSAGE request from different source IP/Port.

The code is modified in stack function and also rejected the OOD messages from the Registered users with "To Tag", similar to SBX-76003 that was done as part of recent customer requirement.

Workaround: No workaround.

SBX-102992 | SBX-103001

2

The SBC is blacklisting a peer when the mid dialog request gets timed out even though "midDialogArsScreenLevel" flag is set to "never" in sipArsProfile.

Impact: The SBC is blacklisting peer when a mid dialog request gets timed out even though the midDialogArsScreenLevel flag is set to never in sipArsProfile.

Root Cause: The original design only covered original INVITE messages and not mid-call INVITE messages.

Steps to Replicate:

1. Make a call from UAC.
2. Answer the call on UAS.
3. When the call is stable send a Re-INVITE request from UAC.
4. The SBC forwards this Re-INVITE request to UAS.
5. Do not send any response to this Re-INVITE from UAS.
6. The SBC sends BYE and terminates the call.
7. Check the "sipArsStatus" on egress zone.

The code is modified to correctly handle mid-dialogue INVITE's as well as original INVITEs.

Workaround: None.

SBX-85825 | SBX-1033892

Portfix SBX-85825: The SBC Application fails with LCA errors on an initial EMS Cluster Configuration push.

Impact: There was a packet drop between the SBC and EMS while downloading the configuration.

Root Cause: Due to small fill rate and bucket size, traffic between the SBC and EMS is flow controlled.

Steps to Replicate: Reboot the SBC so that it registers with the EMS and download the configuration from EMS. Capture the packets between the two to ensure that there is no drop.

Increased the fill rate and bucket size to accommodate large configuration size (~40MB).

Workaround: N/A

SBX-102401 | SBX-1034263

Porfix SBX-102401: The encryptedStore confd_cmd GET operations taking too much time during switchover (Nto1).

Impact: The encryptedStore confd_cmd GET operations were taking too much time during a switchover (Nto1)

Root Cause: The confd_cmd GET calls were taking too much time to return during a switchover if the confd was under stress.

Steps to Replicate: 

  1. Launch Nto1 set up (preferably with a big configuration).
  2. Perform a switchover on active.
  3. On standby (becoming active) verify (during switchover) that:
    1. The confd_cmd get cmds are not taking too long to return (ideally ~ 0.2 sec)
    2. The ChmProcessIntanceData does not take too long to finish.
    3. The ChmClearEncryptedStoreOfPeers returns immediately but encryptedStore.sh deletePeerEntries continues in background and finishes relatively faster (than before).
    4. EncryptedStores are consistent on standby and actives.

Use the confd_cmd -f option with an empty string argument
while running the encryptedstore script in background to save some time and address the issue.

Workaround: N/A

SBX-668312

The warning message needs to be updated/have a proper ending when deleting the ipInterface.

Impact: A warning message does not display in the cloud SBC when deleting the IP interface. But there is no problem with functionality.

Root Cause: This is working fine in the hardware SBC. The problem is in the cloud SBC when the warning message is displayed, a few values are checked to see if they arr matching and then we show the warning popup. In the case of the cloud SBC, the values index are different and the check is failing because we are unable to show the warning popup when we delete the IP Interface.

Steps to Replicate: 

  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. Creation should be successful.
  6. Now 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 as well.

Workaround: N/A

SBX-993063

The SIPCM (SAM) deadlock reported on the SNMP request.

Impact: The SAM process cores when getTlsStatus command is executed.

Root Cause: The issue is because when fetching tls Status, Design was trying to access sessData that was no longer valid.

Steps to Replicate: Execute the getTlsStatus command when running TLS load. The SAM process cores randomly.

The code is modified to fetch the status from socketPtr instead of the sessData.

Workaround: N/A

SBX-98954 | SBX-1033952

Portfix SBX-98954: Unable to configure HW/SWE SBC's into an SLB deployment.

Impact: The SLB cannot be supported with the H/W SBCs.

Root Cause: The CPX validation check prevented configuration on the H/W SBCs to configure the SLB.

Steps to Replicate: 

  1. Configured the SLB.
  2. Configured HW/SWE SSBC in the order below:
    1. Enabled the SLB usage.
    2. Configured the SLB common Interface.
    3. Configured the 'slbAddress' and 'ipAddress'.
    4. Attempted configuring the zone and ssp.

The code is modified to allow configuration of SLB on the H/W SBCs.

Workaround: N/A

SBX-101887 | SBX-1037272

Portfix SBX-101887: The SBC was generating duplicate ICID for different calls.

Impact: The same ICID value was generated for two different calls.

Root Cause: The clock resolution used was 10ms leading to using the same timestamp when subsequent calls were received within 10ms.

Steps to Replicate: Run load with CDR enabled. Check no two calls have the same ICID.

Use high resolution time tick of a 1 micro second and add a counter for achieving granularity of 100ns.

Workaround: N/A

SBX-102444 | SBX-103405

2

Portfix SBX-102444: The link does not get restored for the mgmt interface for an I-SBC in centralized mode.

Impact: The link state in the portMonitorStatus command does not show the correct state when the LDGs are disabled and enabled in a specific order.

Root Cause: In a HA set up, each instance (for example, Node A and B) maintains its own Port Monitor configuration where as both instances maintains the link monitors configuration of both nodes.

When the state of Link Monitor configured on Node B is modified, this CDB notification goes to both nodes A and B. As both of them have the configuration, they update the state and reset a link status maintained in a port monitor to UNKNOWN.

Then, ICMP Pings are sent only on node B. When it receives a response, it updates the link state of a portMonitor configured on that node and generates a event notification.

When the node A gets this event notification, it recognizes that this notification is from peer and only updates the Link Monitor fault state and port monitor link state remains as UNKNOWN on this node.

Steps to Replicate:

1) Instantiate the I-SBC in a centralized mode.
2) Configure the LDG for MGMT interface.
3) Disable the LDG for vsbc2.
4) Disable the LDG for vsbc1.
5) Enable the LDG for vsbc2.
6) Enable LDG for vsbc1.

The code is modified to not initialize link state of port monitor on local node when admin state of peer node LM configuration is changed.

Workaround: The sequence of the LDG state modification has to be changed.

SBX-1034962

The MGT0 cannot reach the GW.

Impact: The mgt0 interface appears to be inactive. The user cannot ping the gateway from SBC-5400.
The ethtool -S mgt0 shows the tx_pause count rising rapidly.

Root Cause: This problem is specific to SBX-5400 fix.

The SBC-5400 has a backpressure mechanism for management ports so that when the receive buffer exceeds a certain level, Design sends pause packets out to the interface to ask the switch/router to pause transmission momentarily.

The receive buffer count is incremented by a hardware module and decremented by software.
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. Run a long duration sRTP call (about 30 minutes) so that the Rollover Counter (ROC) in the sRTP packet becomes non-zero.
  3. Modify the call so that the sRTP packet's SSRC changes.
  4. Check the pause frames of mgt ports.

Set the correct interface information in the notification to address the issue.

Workaround

  1. Run the attached check_mgt0.py.txt (rename it to check_mgt0.py) python script from the Linux command.
  2. Recommendation is to add it as a cron job and run it every 20-30 minutes.
  3. How to add cronjob and run it every 20 minutes:
    copy check_mgt0.py to /opt/sonus/sbx/scripts
    As root running in Linux:
    crontab -e
    */20 * * * * /opt/sonus/sbx/scripts/check_mgt0.py
SBX-1035612

The "tgrp" parameter was not passing transparently when theSIP in the core is enabled.

Impact: The SipCore calls are passing the wrong tgrp parameter value.

Root Cause: There was missing logic to support the SipCore.

Steps to Replicate:

  1. Configure the SipCore feature.
    1. Both IPSP core and egress leg have "originating Trunk Group Options" set to "Include Tgrp with IP address"
  2. Make a SipCore call.

The code is modified to support the SipCore feature.

Workaround: N/A

SBX-100250 | SBX-1033912

Portfix SBX-100250: The KVM Direct-Single SBC not uploading configuration to the EMS.

Impact: 1:1 on KVM is not creating config store directory.

Root Cause: hwSubType variable value for KVM is not consider by lca.py script.

Steps to Replicate: Deploy the 1:1 on KVM.

Consider hwType variable value instead of hwSubType. This will work for all virtual deployment types to address the issue.

Workaround: N/A

SBX-101235 | SBX-1034882

Portfix SBX-101235: The OAM does not output the NTPQ command.

Impact: The NTP server CLI command not applied to the OAM.

Root Cause: The NTP server CLI command logic was skipped for OAM due to blind logic change from SmaIsConfigurator() to SmaIsOAM().

Steps to Replicate: CLI:

Configure:
set system ntp serverAdmin 169.254.120.4 state disabled
commit
set system ntp serverAdmin fd00:10:6b50:4500::11
set system ntp serverAdmin fd00:10:6b50:4500::11 state enabled
commit
<<<App on OAM nodes gets restarted>>>
request system admin vsbcSystem saveAndActivate
<<<App on managed nodes gets restarted>>>

Run the OAM prompt:
ntpq -p [is successful]

Remove erroneous check for OAM node type to address the issue.

Workaround: None.

SBX-101853 | SBX-1033902

Portfix SBX-101853: Observing an issue with the Restore operation in 9.1.

Impact: Restored the configuration is not applied to the Standby OAM and managed nodes.

Root Cause: Configuration updater scripts do not detect the restored revision and do not reboot to apply it. This occurs when only two revision entries are present in /mnt/gfsvol1/config-versions.txt

Steps to Replicate: Ensure only one revision entry is present in /mnt/gfsvol1/config-versions.txt.
Restore to a previous revision.

The code is modified to check the revisions available.

Workaround: None.

SBX-102123 | SBX-1034872

Portfix SBX-102123: There was a CpxA process core on the OAM upon configuring the NTP server.

Impact: The CpxProcess cores on an application shutdown.

Root Cause: There was an improper ConfdProxy object destruction.

Steps to Replicate: Stop the application while the traffic load is running is best to reproduce.

The code is modified to properly delete the ConfdProxy object.

Workaround: None.

SBX-101791 | SBX-1027112

Portfix SBX-101791: Observed the CpxA Process coredump on the SBC with 10% Packet loss introduced on HA interface.

Impact: The CpxProcess cores while traffic load is running.

Root Cause: Segmentation fault in MsgClient::checkBuffering.

Steps to Replicate: Execute the traffic run.

The code is modified to address the issue.

Workaround: None.


SBX-101555 | SBX-1034862

Portfix SBX-101555: An application timeout error for "show table node" on OAM.

Impact: The 'show table node' aborts with a timeout.

Root Cause: There is no handling for empty statistics.

Steps to Replicate: Execute a 'show table node'.

The code is modified for the empty statistics by returning an empty response.

Workaround: None.

SBX-96018 | SBX-1033882

Portfix SBX-96018: Configuration and Profile Import/Export fails on the OAM SBC nodes.

Impact: The OAM and managed nodes have access to user-config-import CLI command. Configuration issues can be introduced if this command is used as OAM manages the configuration.

Root Cause: There is no display condition check for the user-config-import CLI command.

Steps to Replicate: 

Test #1:
- Deploy the VNF with OAM.
- Check that user-config-import CLI command is not available on OAM and the managed nodes.

Test #2:
- Deploy the VNF without OAM.
- Check that user-config-import CLI command is available on nodes.

The code is modified for the user-config-import CLI command.

Workaround: Do not use the user-config-import command.

SBX-100805 | SBX-1034072

Portfix SBX-100805: The LCA does not exit even if the DRBD configuration fails in a 1to1 mode.

Impact: The LCA does not exit even if the DRBD configuration fails in a 1to1 mode.

Root Cause: The reConfigureHa.pl (Which configures DRBD) script's execution status was not checking in the LCA.

Steps to Replicate: Removed the DRBD disk and try to bring up the SBC. With the changes, the LCA run stopped.

The code is modified to check the status of execution of the reconfigureHa.pl script and when it fails, stop running of LCA.

Workaround: None.

SBX-102146 | SBX-1033752

Portfix SBX-102146: Observing the "FAC: *FacSendGetRecordRequest: Get Record request already Sent:192.xxx.x.xxx" major log on an overnight load.

Impact: Getting the FacSendGetRecordRequest major log during the overnight SBC load run.

Root Cause: The FacSendGetRecordRequest Log is made as a major log but ideally it should be info level log.

Steps to Replicate: Run the Overnight SBC load and check for FacSendGetRecordRequest major log.

The code is modified to address the issue.

Workaround: None.

SBX-103798 | SBX-1037992

Portfix SBX-103798: There was dual NUMA support in SWe.

Impact: The SWe does not come up in VMs having multiple NUMA nodes except for signaling traffic profile (SLB, SSBC, SO-SBC).

Root Cause: The root cause was due to deliberate software restriction to not allow multiple NUMAs.

Steps to Replicate: 

  1. Configure a KVM instance with dual NUMA and install in Non-Gold/Non-GPU set up.
  2. Let it come in default traffic profile.
  3. Verify that SBC would come up fine without any HostCheck errors.

The code is modified to allow multiple NUMA irrespective of personality and profile.

Workaround: No workaround except using single NUMA set up.

SBX-73003 | SBX-1016302

Portfix SBX-73003: A vulnerability in use of JavaScript Library To 8.2.4.

Impact: The vulnerability in use of the Javascript library.

Root Cause: When the Javascript library was using version 1.8.0., the vulnerability was reported.

Steps to Replicate: Verified the appropriate screens to test and it is success.

The code is modified to fix the vulnerability. To upgrade this Javascript library, upgrade the jquery-ui (1.12.1) and dataTables (1.10.20).

Workaround: N/A

SBX-967882

A DTMF 2833 PT change (in offer) was incorrect the OA SBX handling (wrong answer PT).

Impact: When there is a peer offer with new PT, the SBC is unable to process and response the previous one.

Root Cause: There was a logical error that checked the wrong field to detect PT change.

Steps to Replicate: 

  1. A call B and connect with "0 100".
  2. A Invite with offer new PT "0 101".
  3. The SBC responds with "0 100"

The code is modified to check the correct field for PT change.

Workaround: None.

SBX-1038522

The SBC sent unnecessary 481 for PRACK when the CANCEL is received.

Impact: The SBC sends unnecessary 481 for PRACK when receiving a CANCEL.

Root Cause: When the SBC received PRACK in response to a 18x message, it generated it was added to an outstanding transaction list. But it was not removed from the list when the SBC sent the subsequent 200 OK for the PRACK. When performing a CANCEL then it arrives, the SBC thought the PRACK was still an outstanding transaction and generated a 481 message.

Steps to Replicate: 

  1. A call B, B response 180 and send 180 to A with PRACK required.
  2. After 32 seconds A send a CANCEL, the SBC sends unnecessary 481 PRACK

The code is modified to remove the PRACK from the outstanding transaction list when the SBC sends back the associated 200 OK, so there is no extra 481 generated if CANCEL then arrives.

Workaround: Enable the e2e PRACK if the egress also support PRACK.

SBX-90884 | SBX-1027292

Portfix SBX-90884: Performance: Observed a SCM memory leak while running the STIR/SHAKEN with RPH Signing/Verification.

Impact: The memory leak is caused at the SCM process for a STIR-SHAKEN failure.

Root Cause: 

When a STIR-SHAKEN call is performed and the STIR-SHAKEN functionality resulted in failure, then the STIR-SHAKEN "Reason Code Text" is populated in order to know the reason for the failure.

As a result, the STIR-SHAKEN failure "Reason Code Text" is then communicated in backward messages.

While populating "Reason Code Text", the intended function will execute twice for a given call. For the second invocation, the existing "Reason Code Text" memory was neither reused or freed. Instead, the call was newly allocated each time for the same call.

This resulted in memory leak for every STIR-SHAKEN call failure.

Steps to Replicate: 

  1. Run the configuration and execution of a STIR-SHAKEN Call.
  2. The STIR-SHAKEN functionality to result in a failure.

The code is modified to fix the following:

  1. If "Reason Code Text" memory is already allocated before, then the same memory is reused again by resetting the memory.
  2. If "Reason Code Text" memory is not allocated previously, then new memory is allocated and used.

Workaround: None.

SBX-101727 | SBX-1033522

Portfix SBX-101727: The LeakSanitizer detected memory leaks in the SAM Process (DFe process).

Impact: When making configuration changes to the D-SBC profile, the SBC leaks a small amount of memory.

Root Cause: The SBC application code uses local buffers while reading profile changes from the CDB and this memory was not getting freed up correctly, leading to a leak.

Steps to Replicate: This problem is highlighted when using ASAN enabled build in the engineering lab and making DSBC profile changes.

The code is modified to correctly access the local buffers to avoid the memory leak.

Workaround: None.

SBX-102056 | SBX-1033552

Portfix SBX-102056: The AddressSanitizer detected a heap-buffer-overflow in SipsgRedundMsgParamLoadSubsCbStr.

Impact: While printing the debug messages as part of making subscriber data redundant, the SBC was reading off the end of a buffer.

Root Cause: Some of the buffers used to hold string information were not large enough to include a NULL terminator so when printing out debug messages, the printing code was reading off the end of the buffer.

Steps to Replicate: This problem is highlighted when using ASAN enabled images in the engineering lab.

The code is modified to ensure the strings for the subscriber data are NULL terminated to avoid the code reading of the end of the string buffer.

Workaround: None.

SBX-101597 | SBX-1033542

Portfix SBX-101597: The LeakSanitizer detected memory leaks in the CpxAppProcess.

Impact: When making changes to the D-SBC signaling port configuration, the SBC is leaking a small amount of memory.

Root Cause: While reading configuration changes from the CDB, the SBC application code allocates local buffers and they are not getting freed up at the end of processing leading to a small memory leak.

Steps to Replicate: The issue is seen when using ASAN enabled images in the engineering lab and making configuration changes to the DSBC signaling port configuration.

The code is modified to correctly free the memory allocated to the local buffers to avoid the memory leak.

Workaround: None.

SBX-103603 | SBX-1036362

Portfix SBX-103603: The LeakSanitizer: detected memory leaks in the MrfRmProcessTrmAllocRpyMsg.

Impact: While testing call scenarios for RTCP for T.140 Pass-through functionality, it was observed that the SCM process could leak memory for calls associated with an MRF (external media transcoder).

Root Cause: The SBC was allocated memory while processing the SDP associated with this call but was not always freeing up the memory at the end of the call.

Steps to Replicate: Run various call scenarios with MRF where the SBC is using the SIP to allocated media resources on an external media transcoder (MRF) or T-SBC.

The code is modified to correctly free all the memory allocated for the call.

Workaround: None.

SBX-103489 | SBX-1036372

Portfix SBX-103489: The LeakSanitizer: detected memory leaks at the confd_malloc.

Impact: The small memory leak during the configuration of lawful intercept server.

Root Cause: The configuration code was reading information from the CDB and storing information in an internal memory block but not freeing it up.

Steps to Replicate: Create a lawful intercept server and make configuration changes.

The code is modified to correctly release the internal memory block at the end of the configuration action.

Workaround: None.

SBX-102054 | SBX-1023052

Portfix SBX-102054: The LeakSanitizer detected an error in CpxAaaGetElem.

Impact: When adding new users, a small amount of memory leaked.

Root Cause: While processing the addition of new users, the code allocated temporary memory blocks to hold information retrieved from the CDB about existing users this memory was not getting completely released after use.

Steps to Replicate: This issue is observed when running with ASAN images in the lab.

The code is modified to ensure the temporary memory allocated is freed up after use.

Workaround: None.

SBX-102060 | SBX-1033562

Portfix SBX-102060: Leak detected while running the SBX-93279 HA cases, especially on the SCM and IM process.

Impact: When making a CAC profile configuration change, the SBC leaks a small amount of memory.

Root Cause: When reading configuration changes from CDB, the application code was storing information in local buffers and not freeing it up correctly, leading to a memory leak.

Steps to Replicate: This problem is highlighted when using ASAN enabled images in the engineering lab and making CAC profile configuration changes.

The code is modified to correctly free up the memory in local buffers to avoid the leak.

Workaround: None.

SBX-101504 | SBX-1036893

Portfix SBX-101504: The SPD for IPSec SA was created for the 3GPP IMS AKA should allow both the TCP and UDP transport protocols.

Impact: The Apple and Samsung phones run the IMS AKA registration over the TCP, but send an SMS (MESSAGE) over the UDP later, which was dropped on the SBC.

Root Cause: The SBC honors messages only on that transport for IPsec (established using the IMS AKA) that was used initially during registration.

Steps to Replicate: 

1. Set up SIP registration using IMS AKA on TCP.
2. Make SIP calls (INVITE) over TCP.
3. Exchange SMS (MESSAGE) over UDP.

The code is modified so the SBC now listens on UDP ports also, same ports that are exchanged during initial IMS AKA registration, along with the TCP ports.

Workaround: N/A

SBX-101749 | SBX-1021032

Portfix SBX-101749: The SBC incorrectly passed a complete contact header transparently without the presence of the isFocus parameter.

ImpactThe SBC incorrectly passed a complete contact header transparently without the presence of the isFocus parameter.

Root Cause: The SBC passed a complete contact header transparently without the presence of the isFocus parameter, with the contactTransparencyForIsFocusMediaTag enabled on both trunk groups.

Steps to Replicate: 

  1. Configure the SBC for A to B call.
  2. Enable the flag contactTransparencyForIsFocusMediaTag on both TGs.
  3. Make a SUBSCRIBE-NOTIFY call flow.
  4. Ensure the isFocus parameter is present in the Notify message, but is not present in the 200 OK response.

The code is modified to not transparently pass the complete contact header when the contactTransparencyForIsFocusMediaTag flag is enabled, and the isFocus parameter is not present in the 200 OK notification.

Workaround: N/A

SBX-88376 | SBX-1033862

Portfix SBX-88376: The SBC interop with Ribbon AS: Upstream Forking was not working consistently using the TLS.

Impact: For a non UDP transports, in an upstream forking scenario where as on ingress side, the SBC receives multiple INVITE with the same Call-Id, From, and To.
In such a scenario, the SBC is not sending all the received INVITEs out to the end points that are registered on same username.

Root Cause: The SBC used to drop off those forked INVITE's that are received during the processing of initial INVITE.

Steps to Replicate: On a non UDP transport, send multiple forked INVITE's towards the SBC with the same Call-Id, From, To, Request URI.

Queuing the subsequent forked INVITE's and processing them in the same order received solves the problem.

Workaround: None or use the UDP as transport.

SBX-103937 | SBX-1037753

Portfix SBX-103775: Changing the XRM to build ALL media RID’s static IP headers with the “Don’t Fragment” (DF) bit SET TO 0 instead of 1.

Impact: The SBC forwards the DTLS packets correctly but the large certificated packet does not reach the calling device.

Root Cause: The SBC has set the DF (do not fragment) bit in IPv4 header so routers cannot split the packet and it can result in the packet getting dropped.

Steps to Replicate: 

  1. Set up a Inter-work between Full ICE client and ICE Lite call flow with DTLS/SRTP relay.
  2. Caller send out large DTLS packets.
  3. Capture the packets, ensure the DF bit has not set (0x0000).

The code is modified to set the DF bit when the SBC builds the IP header for DTLS and STUN packets.

Workaround: N/A

SBX-103939 | SBX-1039453

Portfix SBX-103939: The NAPT timer was not armed properly in the MoH.

Impact: The NAPT timer did not started as the NRMA requested.

Root Cause: The RTP flow mode was xmt-only. Then, the NRMA requested flow change to enable the NAPT timer expiry because we have already learned source address. But the XRM did not start NAPT timer because it was a learning next request.

Steps to Replicate: Run NAPT regression tests to reproduce the issue.

The code is modified to start the NAPT timer for learning next if NRMA has set XRM_NAPT_MEDIA_NAPT_TIMER_ACT_ENAB.

Workaround: None.

SBX-1004263

The `imfile' in rsyslog.conf without freshStartTail="on" can cause the SBC switchover when enabled.

Impact: When certain logs (consoleLog, sftpLog, syslogLog, platformAuditLog, ntpLog) get enabled initially, high number of old logs can be sent to the remote syslog server. This can cause network issues which can cause the SBC to switchover.

Root Cause: If a log is enabled for the first time, the rsyslog will try to send the whole log to the remote syslog server at once.

Steps to Replicate: Fill up /var/log/syslog with messages. Enable syslogLog in the SBC application. Verify older messages are not sent to the remote system.

The code is modified so the rsyslog option only reads in latest logs when initially enabled.

WorkaroundUpdate the input rules in /etc/rsyslog.conf:

e.g.
#input(type="imfile" File="/var/log/session/session.*" Tag="console" Severity="info" Facility="lpr" escapeLF="on" addMetadata="on")

to:

#input(type="imfile" File="/var/log/session/session.*" Tag="console" Severity="info" Facility="lpr" escapeLF="on" addMetadata="on" freshStartTail="on")

SBX-1037633

The upgradeSBX.properties makes the EMA to show upgrade in progress forever.

Impact: An upgrade was completed but the Platform Manager Install/Upgrade screen gets stuck on previous upgrade and can not perform new upgrade operation.

Root Cause: We are facing this issue because we had updated the SBC upgrade steps as part of SBX-56893 Jira in 6.1.0. Whenever we upgrade the SBC from 6.0.x to 8.2.x, we will see the issue because there are different steps in 6.0.x and 8.2.x that is causing the issue.

When we upgrade the SBC using 6.0.x code that has the old upgrade steps once we execute the pre install check step, the PM API updates the upgradeSBX.properties file with next step (INSTALL_DB), the SBC goes for reboot and platform manager code gets replace with upgraded version which is 8.2.x.

Now, the PM API reads upgradeSBX.properties file to read the steps value that is INSTALL_DB and match the check but in 8.2.x PM code. There is no INSTALL_DB check in PM code because of that, we are unable to update the upgradeSBX.properties file with next steps.

Once an upgrade gets completed and the PM code updates upgradeSBX.properties file with FINISHED as steps, we move the upgradeSBX.properties file into upgradeSBX.properties.1, which is not happening and Platform Manager UI is unable to mark as complete and getting stuck on install/upgrade screen with previous upgrade.

Steps to Replicate: 

  1. Use the ISO/app to install SBC 6.0.0F6 on a HW box. Install the SBC as a standby SBC on a SBC5110.
  2. Go to EMA Administration > System Administration > Software Install/Upgrade and start an offline upgrade. Leave the browser alone, do not click anywhere in the EMA GUI once the upgrade has started.

The code is modified to handle the INSTALL_DB step check to mark upgrade as complete from Platform Manager UI.

Workaround: To perform again upgrade operation, delete the upgradeSBX.properties file from the SBC.

SBX-1035283

There are unwanted critical logs in HW SBC for:

"CRITICAL.SMA: *SmaIsCustomGPUProfile: Failed to read /opt/sonus/conf/swe/capacityEstimates/.activeCallMixInput.json".

Impact: The critical level log gets written into the DBG event log each application startup on Hardware Systems.

Root Cause: The system attempts to open a file that does not exist on Hardware Platforms.

Steps to Replicate: Startup the SBC application on a Hardware SBC. Verify the DBG log.

Stop the system from attempting to open the file on the Hardware Systems to address the issue. 

Workaround: None.

SBX-1040603

The DBG logs in the 7.2.4R0 SBCs filling up with the T38 logs.

Impact: When the call trace is enabled, the T38 messages are logged in a .DBG file. However, even after a call trace is disabled, T38 log messages continue to appear in .DBG file.

Root Cause: A gevelobal variable to set t38 log messages was set for call traces but never reset.

Steps to Replicate: 

  1. Enable call tracing and make a T38 fax call.
    See that .DBG file has T38 log messages.
  2. Disable call tracing and make a T38 fax call.
    T38 log messages do not appear in .DBG file.

The code is modified so after the call tracing is disabled, T38 log messages will not appear in .DBG file.

Workaround: Use 'unhide debug' command to disable T38 log message after call tracing is no longer needed.
> request sbx drm debug command "dspdebugt38 state disable"

SBX-102234 | SBX-1040073

Portfix SBX-102234: The SubsystemAdmin filter affects calltrace (TRC) logging showed useless logs.

Impact: After creating then deleting an entry in the oam eventLog subsystemAdmin, the original behaviour is not restored. INFO level events for that subsystem are no longer logged, even if the oam eventLog typeAdmin filterLevel is info.

Root Cause: Deleting an entry in oam eventLog subsystemAdmin does not restore settings back to default.

Steps to Replicate: 

  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-98024 | SBX-1040112

Portfix SBX-98024 The contact header is not transparently passed when the Ingress and Egress had different transport types.

Impact: Contact header is not passed transparently from Ingress, when egress side has different transport type, even when the IPSP flag 'passCompleteContactHeader' is enabled on both ingress/egress Trunk Groups.

Root Cause: In API SipSgCheckAndSetContactHeaderTrasparency(), irrespective of transparency control is enabled/disabled, if the egress Sig Zone is MS Teams,
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-1020592

Mismatch in the count of ipPeers on Routing page.

Impact: There was a mismatch in the Zone, and IpPeer counts on the UI.

Root Cause: The backend logic using the contained predicate that fetches all the related data.

Steps to Replicate: Go to the Route screen, select trunkGroup and verify the Zone, IpPeer counts.

The code is modified from contained to match, and is now only associated data being fetch based on the parent selected.

Workaround: None.

SBX-86293 | SBX-1041693

Portfix SBX-86293: PreInstall Check improvements for file permissions.

Impact: PreUpgrade checks failure due to permission issues on external directory.

Root Cause: Pre-checks script failed to run commands on peer due to permission issues.

Steps to Replicate: Perform upgrade to the fix version and verify that upgrade is successful.

The code is modified to ensure permissions/ownership are set properly before running through pre-checks/upgrade.

Workaround: Set the right ownership for external directory as:
chgrp -R upload /opt/sonus/external/

SBX-1019182

The Out of Memory caused an SBC switchover.

Impact: Memory leaks when 3xx relay and reject 3xx on egress IPSP

Root Cause: Contact Headers in 3xx memory did not free properly.

Steps to Replicate: 

  1. Enable 3xx relay and reject 3xx, trigger the SBC sends 503 to ingress.
  2. A call B, B response 3xx with contact headers.
  3. Or Enable 3xx relay and configure ingress "do not send 3xx", trigger SBC sends 503.

Ensure the memory of contact headers in 3xx are properly free when config to reject 3xx.

Workaround: Customer may using SMM to change the status 3xx to 503 instead.

SBX-1040223

The digitCriteria numberLength operation parameter was not configured after the first commit.

Impact: The digitCriteria numberLength operation parameter not configured after the first commit.

Root Cause: The value of the digitCriteria numberLength was overridden to 0 by the dpcIndicator during a Db update at first commit, which caused the issue. At the same time, the dpcIndicator was updating the value due to missing validation.

Steps to Replicate: Now in the first commit value digitCriteria numberLength should pick the value.

The code is modified to update the dpcIndicator only if the criteria type is URI. As a result, the digitCriteria numberLength is set expected value properly and issue got fixed.

Workaround: Committing twice will set the digitCriteria numberLength value.

SBX-1058382

There was an SM coredump, that was in communication with openhpi.

Impact: The SM took a bit longer to read all four DSP card version's info on the SBC7000. This leads to an SM coredump.

Root Cause: The SM took a bit longer to read all four DSP card version's info on the SBC7000.

Steps to Replicate: Test on the SBC7000 with all four DSP cards.

The SM time out value is increased from 90 sec to 120 sec to address the issue.

Workaround: None.

SBX-97650 | SBX-996862

Portfix SBX-97650: ERROR: The leakSanitizer detected memory leaks.

Impact: The leak sanitizer detected a memory leak for NRMA Session Desc as part of the leak sanitizer tool execution.

Root Cause: During the SDP to PSP conversion, the routine SipSgConvertSdpToPsp() is allocating memory for the NSD structure and not freeing the memory when the conversion fails.

Steps to Replicate: Run the leak sanitized tool to reproduce the issue.

Freed the memory allocated for the NSD structure in cases where the SipSgConvertSdpToPsp() fails.

Workaround: N/A

SBX-104723 | SBX-1037042

Portfix SBX-103704: The RTP sourceAddressFiltering is not working (call leg dependency).

Impact: The source address validation is not done if call flow does not involve NAPT learning. For calls that want source address validation but does not have NAPT enabled, the SBC would not validate the source address and end up forwarding the RTP packet to the other endpoint.

Root Cause: There is no way for application to inform Network Processor to validate source if NAPT learning is not enabled.

Steps to Replicate: Involves a CISCO MOH server but probably something else can be used.

The code is modified to validate source even when NAPT learning is not enabled to address the issue.

Workaround: Enable NAPT learning for the call.

SBX-100253 | SBX-1033572

Portfix SBX-100253: The SBC services are not coming up with an ASAN build.

Impact: On the SBC5100/5200, there was an ASAN flags error while processing the negative Boot Init Response received from the DSP.

Root Cause: While processing the Boot Init response, variables that are not defined for DSPs on SBC5100/5200 is being accessed. Since memory is not allocated to these variables, accessing them is invalid.

Steps to Replicate: None.

The code is modified where if it is SBC5100/5200 DSP, the mentioned variables are not accessed.

Workaround: None.

SBX-103255 | SBX-1050692

Portfix SBX-103255: Enhance the sbxPerf on the SBC for lesser resource consumption.

Impact: The SBC performance monitoring tools like top and top2 at times take 20% of a CPU core there by reducing total available CPU resources for management activities on the SBC.

Root Cause: The sbxPerf that contains list of tools such as top, mpstat, and iostat currently runs periodically without any linux value configured. This can cause these processes to get prioritized and scheduled ahead of other management processes such as ConfD and SSH.

Steps to Replicate: Install fix build and ensure processes such as top, top2, mpstat sbxPerf are running with corrects value of 15 using the top command.

The code is modified so that priority of these processes are less compared to other management processes on the SBC.

Workaround: None.

SBX-103593 | SBX-1047182

Portfix SBX-103593: The SBC is ignoring Use Max Bitrate Only flag.

Impact: The SBC is ignoring Use Max Bitrate Only flag.

Root Cause: During Re-Invite answer processing, NrmaAdjustPeerT38MaxBitRate() routine is doing T38MaxBitRate adjustment based on packet size that is changing T38MaxBitRate value from 14400 to 4800.

Steps to Replicate: Call Flow:

  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 200OK.
  5. The SBC sends out 200ok with T38MaxBitrate set to 4800.


Actual Result:

--UAS(Re-Invite) -----> SBC ----> UAC
T38MaxBitRate:14400 T38MaxBitRate:14400
--UAC(200ok for Re-Invite) ----> SBC ----> UAS
T38MaxBitRate:14400 T38MaxBitRate:4800

Expected Result:

--UAS(Re-Invite) ----> SBC ----> UAC
T38MaxBitRate:14400 T38MaxBitRate:14400
--UAC(200ok 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-105416 | SBX-1057032

Portfix SBX-105416: The glusterfs is failing on the standby OAM after a reboot.

Impact: The Gluster server on a Standby OAM fails to start.

Root Cause: The Gluster heal check conditions are wrong.

Steps to Replicate: 

  1. Reboot the Standby OAM node, wait 2 minutes, then reboot Active OAM node.
  2. Both Active and Standby OAM come up successfully.

The code is modified to obtain the expected result.

Workaround: None.

SBX-91799 | SBX-1037182

Portfix SBX-91799: The segfault in pamValidator during PM login with incorrect credentials.

Impact: The segfault in pamValidator on a failed login for locked user.

Root Cause: The pamValidator defines a conversation function that is called by pam modules to exchange values. The pam module was freeing a struct member in the first call and accessing the same freed value in another call to the conversation function that was causing segmentation fault.

Steps to Replicate: Perform following steps on any of the SBC deployment and verify that segmentation fault does not happen:

## TEST 1: Ensure success for correct username and password:

  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 (at least 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-103387 | SBX-1047172

Portfix SBX-103387: The Video NAT learning is failing on the D-SBC cloud.

Impact: The Video NAT learning failed in the D-SBC.

Root Cause: On the D-SBC, NAT learning for video stream was not processed successfully and as a result caused the video packets to be dropped by the SBC.

Steps to Replicate: 

  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-104560 | SBX-1050272

Portfix SBX-104560: The redirection NOA set wrong in the CDR.

Impact: The "Redirecting Orig Cd Num - NOA" subfield of "Redirection Feature Spec Data" is not set correctly in CDR record if the the Redirecting Original Called Number - NOA value is modified by PSX.

Root Cause: The existing code was not updating the value for the CDR record based on route specific information returned from the PSX.

Steps to Replicate: Test Set up
========

  1. Test requires call routing through the PSX.
    Routing on PSX, set up 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-103634 | SBX-1042302

The LeakSanitizer: detected memory leaks in DCmRestoreAllMetaVarsToStandbyContext.

Impact: A small memory leak was observed in the SAM process while performing a switchover from standby to active box.

Root Cause: The standby instance stores information about the metavars associated with signaling ports configured on the active instance. During the conversion from standby to active, the standby data is moved into active structures but the original standby memory blocks are not freed up correctly resulting in a memory leak.

Steps to Replicate: Perform a switchover from standby to active while running a basic call, no memory leak will be observed in the SAM process.

The code is modified to correctly free the memory associated with the standby data when it gets transitioned to active to avoid the memory leak.

Workaround: None.

SBX-103224 | SBX-1035892

Portfix SBX-103224: The ipsecSaStatus with local SPI is failing, as well as ikeSaStatus and ikeSaStatistics with ikeSaIndex is failing.

Impact: The show command for ikeSaStatus and ikeSaStatistics was not displaying information for the IPSEC calls of type ikev2 when trying to display with specific key field information.

Root Cause: The display logic was missing to output call information for the type ikev2 with specific parameters.

Steps to Replicate: Make IPSEC calls of type ikev2 and then run the status and statistics commands using the remoteSpi as a parameter.

The code is modified to correctly display information for the IPSEC calls of type ikev2 with specific parameters.

Workaround: The display prints out all information correctly when no parameters are specified.

SBX-98302 | SBX-997202

Portfix SBX-98302: The LeakSanitizer detected memory leaks.

Impact: The LeakSanitizer detected a memory leak in the SIPSG while processing the REGISTER messages.

Root Cause: While processing a REGISTER message, the SBC performs a PSX query and gets back the primary domain information in the policy response. The SBC allocates memory to hold this information in the registration control block (RCB) but it was not getting freed up when the RCB was later released.

Steps to Replicate: Configure the SBC with Primary Registrar Domain info and run a registration scenario with ASAN enabled images.

The code is modified to free the memory associated with primary domain information to avoid the memory leak.

Workaround: N/A

SBX-103732 | SBX-1040022

Portfix SBX-103732: There was an error AddressSanitizer: heap-buffer-overflow on address

0x61d001429c18 at pc 0x556c876cf74c bp 0x7fb14f64fab0 sp 0x7fb14f64f260 READ

of size 3488 at 0x61d001429c18 thread T21 in the SAM Process.

Impact: In a DSBC environment while processing the remote media data command message the SAM process could read off the end of the received message. Reading off the end of the allocated message block could in the worst case result in a coredump.

Root Cause: The SAM process was assuming that the size of the received message was larger than it actually was and this resulted in reading off the end of the received message buffer. In most cases this does not cause a problem but in could potentially result in a coredump if the associated buffer is at the end of the addressable memory space.

Steps to Replicate: Run RFC4117 test case for audio transcoding and video relay.

The code is modified to not read off the end of the received memory block.

Workaround: None.

SBX-97838 | SBX-1000512

Portfix SBX-97838: Unable to create a sipSigPort on the cloud SSBC when the IP metaVar is previously used for a different sipSigPort.

Impact: Unable to create a sipSigPort on the cloud SSBC when the IP metaVar is previously used for a different sipSigPort.

Root Cause: The root cause for this issue is there was a check to skip any validations if the instance is cloud based in the addIpAddressToMetaTable and deleteIpAddressFromMetaTable functions. As a part of SBX-59421 feature, in 8.1 the check was removed in the addIpAddressToMetaTable and as a result duplicate entries were not allowed to be configured. However, it was retained in deleteIpAddressFromMetaTable function. Even after sipSigPort is deleted, stale entries would still remain and the sipSigPort creation was failing with same metaVar as a result.

Steps to Replicate: The steps cannot be reproduced.

  1. Create a sipSigPort (with index 1) with ipVarV4 IF2.IPV4
  2. Delete the sipSigPort
  3. Create a sipSigPort (with different index 2) with same ipVarV4 as in step 1.

Error seen: addressContext default zone ZONE_IAD sipSigPort 2': IP address / port number must be unique within an address context

The check that was retained in deleteIpAddressFromMetaTable is removed.
Any further sipSigPort deletions will remove the entries from the metaTable as well.

WorkaroundIf the customer is not using 9.0 and still in older releases, the following procedure can be used to remove the stale entries:

  1. Perform an unhide debug
  2. Navigate to the configuration mode.
  3. Execute this command to remove the IP entries whose corresponding sipSigPorts have been deleted:
    #delete addressContext default sipSigPortAddrMeta <ipAddr> <port>
SBX-97832 | SBX-1000542

Portfix SBX-97832: Unable to delete the leaf node like ipVarV4 or ipVarV6 in the sipSigport configuration in the I-SBC.

Impact: Unable to delete leaf node like ipVarV4 or ipVarV6 in sipSigport configuration as shown in the example below:

admin@isbcSwe-192.168.2.21% delete addressContext default zone SBX_89017_KL_1 sipSigPort 5 ipVarV6
[ok][2020-03-09 06:04:15]

[edit]
admin@isbcSwe-192.168.2.21% commit
Aborted: 'addressContext default zone SBX_89017_KL_1 sipSigPort 5 ipVarV6': There is no value for parameter - ipVarV6
[error][2020-03-09 06:04:16]

Root Cause: In the SBC systems that were not using the metavar configuration, the deletion of ipAddress was allowed. This was due to a bug in the code that wrongly checked for the metavar value before allowing the IP address deletion.

Steps to Replicate: Configure and delete the leaf nodes of the sipSigPort.

The code is modified so the deletion is allowed.

Workaround: N/A

SBX-96436 | SBX-1000502

Portfix SBX-96436: The SBC was adding a reason header even when the verification is successful.

Impact: The SBC should only add a reason header and text when the verification service replied with a failure response.

Root Cause: The SBC was adding the reason header when it is received from the PSX without checking whether the verification is SUCCESS or not.

Steps to Replicate: 

  1. Configure the verification server to send a SUCCESSFUL response for STIR/SHAKEN.
  2. When the SBC receives verification service from PSX, then the SBC checks for verification status and adds the reason header in provisional/final response.

The code is modified so the SBC checks failure status then only adds the reason header if it is available.

Workaround: N/A

SBX-102827 | SBX-1041582

Portfix SBX-102827: The SBC 5210 experienced an upgrade failure during Starting DB_RESTORE stage.

Impact: Failure during upgrade while creating database referential keys.

Root Cause: Creation of foreign key fails on table packet_service_profile (Child Table) column CODEC_ENTRY_FK9, as it had "0" in one of its rows and dbimpl.codec_entry table (parent table) does not have this value.

Steps to Replicate: Upgrade a dump that has "0" in the following. It should be successful.

packet_service_profile.CODEC_ENTRY_FK9 

The code is modified to check the data and nullify any value that is not present in parent table before adding the referential keys,

Workaround: None.

SBX-104216 | SBX-1044772

Portfix SBX-104216: The SBC relays STUN packets in RTP streams on pass-thru calls (no transcoding); on RTP to SRTP calls, the relayed STUN packet causes the ROC to reset back to 0 and the remote peer discards the encrypted media packets.

Impact: Sending Non_RTP packets mixed/relayed in SRTP stream from the SBC resulted in one-way audio at the endpoints in longer duration calls.

Root Cause: These non-RTP packets relayed eg. STUN packet causes resetting of encryption ROC back to 0 on the SRTP stream sent out. This issue results in the remote peer discarding the encrypted media packet in long duration calls from the SBC, where ROC is expected to be non-zero.

Steps to Replicate: Run a SRTP passthrough call with media for more than 15 mins, with 10 ptime. Then send a non-RTP packet (STUN, UDP TL t.38) in that stream for pass-thru relay, and observe the media in that call.

The code is modified to not mix Non-RTP packets with SRTP encryption/decryption processing. As a result, SRTP media stream ROC does not reset with these mixed packets, and the endpoint will not have media issues in longer duration calls.

Workaround: If longer duration calls are expected to relay STUN messages as well, disabling the SRTP will solve media issue. However, if SRTP must be enabled for security reasons, there is no workaround for this.

SBX-103788 | SBX-1040422

Portfix SBX-103788: ASAN ERROR: LeakSanitizer: detected memory leaks in the CpxAppProcess.

Impact: There was a small memory leak when making the configuration changes to the GW signaling port.

Root Cause: The configuration logic was reading the interface group name from CDB into a temporary local variable in order to perform validation logic but never freed up this memory at the end of the validation.

Steps to Replicate: This issue is highlighted in the engineering lab when performing GW sig port configuration changes on an ASAN enabled build.

The code is modified to correctly free the temporary memory to avoid the leak.

Workaround: None.


2

CE_2N_Comp_ScmProcess_2==4455==ERROR: LeakSanitizer: detected memory leaks at confd_malloc.

Impact: ASAN detected memory leaks while processing a E164 profile.

Root Cause: The memory was released while processing a E164Profile at the end of the configuration action.

Steps to Replicate: Create and modify the E164Profile configuration.

The code is modified to release the internal memory block at the end of the configuration action.

Workaround: None.

SBX-96307 | SBX-997052

Portfix SBX-96307: The LeakSanitizer detected memory leaks at SipSgEmergencyProfileAddPrefix.

Impact: Observed a memory leak while adding and deleting the prefix/urnPrefix entries in an emergency profile.

Root Cause: On the deletion of prefix/urnPrefix entries, the memory not getting freed for the prefix list and this was causing the memory leak.

Steps to Replicate: 

  1. Create an emergency profile.
  2. Add the prefix entries.
  3. Delete the prefix entries (repeat step 2 and 3).

The code is modified to free the memory whenever the prefix entries is deleted from the emergency profile.

Workaround: To avoid the memory leak, delete and recreate the entire emergency profile rather than just deleting only the prefix entries from the profile.

SBX-103731 | SBX-1040012

Portfix SBX-103731: The AddressSanitizer: heap-buffer-overflow on address 0x61a0000cb9d9 observed in the SAM Process while running OCSP feature.

Impact: When the OCSP stapling feature is enabled on the SBC and the code was processing, the response it writes to unallocated memory and in the worst case this could result in process coredumps.

Root Cause: While processing a OCSP response, the code was allocating a memory buffer large enough to hold the response, but then incorrectly writing one byte off the end of the memory buffer while attempt to try and null terminate the string.

Steps to Replicate: 

Set up - UAC > Dut<>Adapter -> UAS

  1. Create OCSP profile by configuring the defaultResponder and stapling enabled.
  2. Attach the ocsp profile to the TLS profile configured.
  3. From Endpoint A, initiate the TLS call with Client Hello from the SIPP UAC having OCSP parameter in it.
  4. The SBC should send server hello, certificate 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-97904 | SBX-999612

Portfix SBX-97904: The AddressSanitizer detected a stack-buffer-overflow on the address 0x7f994bb18d30 at pc 0x56314564c886 bp 0x7f994bb18c10 sp 0x7f994bb183c0 WRITE of size 16 at 0x7f994bb18d30 thread T7.

Impact: A stack-Buffer-Address overflowed for a V6 Address.

Root Cause: As part "SBX-66765:Support for IPsec for Media with UDP transport for LI" feature,
when LI server is configured with V6 Address, the stack-buffer was overflowing and as a result some unidentified behavior can be observed in the feature SBX-66765.

Steps to Replicate: This problem is highlighted when testing the following scenario in the lab with ASAN enabled images.

  1. The SBC is configured with V6 Address for IMS LI UDP media.
  2. Make a call.
  3. The media Interception should happen.
  4. The IPsec connection should get established for the SBC and peer.

The code is modified to handle V6 Address overflow.

Workaround: N/A

SBX-103801 | SBX-1041052

Portfix SBX-103801: ASAN: Observed a run time error in the M-SBC "runtime error: load of value 42, which is not a valid value for type 'bool'"

Impact: The M-SBC could potentially configure the wrong data path mode for a call.

Root Cause: No issues were observed while running this functionality on a regular deployment image. But while testing with ASAN it highlighted that some of the fields used in a call resource allocation message were not always initialized correctly. This can potentially lead to unexpected behavior e.g. SYS_ERRs, wrong datapath mode set up.

Steps to Replicate: This issue was highlighted while while running test suite related to RFC-4117 MRF Mid-Call modification Enhancement.

The code is modified to correctly initialize the resource allocation request fields to avoid issues.

Workaround: None.

SBX-93898 | SBX-1045152

Portfix SBX-93898: The "request sbx xrm debug command sec -stat gcid <gcid>" was not showing the enc and dec details on the SBC SWe.

Impact: This debug command in unhide section is not showing all the required fields populated in the SBC SWe.

Root Cause: The NP response is not framed in expected order to application layer.

Steps to Replicate: Run a SRTP call and the issue this debug command. The debug command does not show all the populated fields.

The code is modified so the NP Response is correctly framed in expected order to application layer.

Workaround: This debug command is to see SSN field value with RoC, all other details can be seen from show call mediastatus.

SBX-96116 | SBX-997242

Portfix SBX-96116: The LeakSanitizer detected memory leaks at SipSgCopyRemoteAddressInfo.

Impact: Observed a memory leak during an early call termination.

Root Cause: Whenever a call terminated early at the ingress leg, some resources were not freed and it was causing the memory leak.

Steps to Replicate: Configure the SBC to reject an HPC call based on GETS-Feature Control Match and RPH header processing (For early termination).

The code is modified to free the memory during an early call termination.

Workaround: N/A

SBX-1043423

The SBC silently drops the second Notify when running the off board query for the eventDialog.

Impact: SBCs silently drop the second Notify within a Subscribe if it received simultaneously.

Root Cause: Currently, the SBC does not support multiple Notify when it requires an off board query for a dialogEvent of Notify.

Steps to Replicate: After a Subscribe, the Peer server sends multiple Notify (almost at the same time) with dialogEvent for an off board query.

The code is modified so the SBCs respond with 503 with retry-after for this case.

Workaround: None.

SBX-1039222

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

After the switchover, a large amount of the DBG messages generated.

Impact: When TG block direction setting is modified before a switchover, modified block direction setting does not reflect on SIP calls/message relays after switchover.

Root Cause: The SBC does not modify block direction correctly on the standby node.

Steps to Replicate: 

  1. Blocked the TG on SBC-a(ACT)
    SUBSCRIBE is blocked with error : 503.
  2. Switchover from SBC-a to SBC-b.
  3. Confirmed the status which TG was blocked from SBC-b(ACT).
  4. Switchover from SBC-b to SBC-a.
  5. Confirmed the status which TG was blocked from SBC-a(ACT).
  6. Unblocked TG on SBC-a(ACT).
  7. Switchover from SBC-a to SBC-b.
  8. Confirmed the TG status from SBC-b(ACT), it displayed unblocked, when SUBSCRIBE is tried, the SBC sends 503 back to ingress.

With a fix, at step 8, the SBC will relay SUBSCRIBE message correctly.

The code is modified to ensure the block direction configuration works correctly after a switchover.

Workaround

1. Apply following workaround to toggle block direction

set addressContext AC zone zone1 sipTrunkGroup SIPTG1 blockDirection incoming
commit
set addressContext AC zone zone1 sipTrunkGroup SIPTG1 blockDirection non
commit

SBX-1042472

Resource memory congestion level 3 is approaching threshold 90 sample 81.

Impact: The SAM Process is leaking memory when the AKA is being used.

Root Cause: The SAM Process is leaking an AKA related structure when the code is handling an error case scenario.

Steps to Replicate: Unable to reproduce this issue. The root cause was found by code inspection.

The code is modified to correctly free the AKA structure in all scenarios.

Workaround: None.

SBX-101668 | SBX-1033602

Portfix SBX-101668: The LeakSanitizer detects the memory leaks at the hdb_handle_create.

Impact: The leak sanitizer was reporting some memory leaks because of memory allocation done in the CcSetLiCdcMediaTypeFromDb() function in a ccCsv.c file.

Root Cause: The CcSetLiCdcMediaTypeFromDb() function in memory is dynamically allocated for the mediaIpInterfaceGroupName but not freed, which caused the memory leak.

Steps to Replicate: Run a 3xx call with LI configuration on an ASAN build and this leak should not appear.

The code is modified to free the memory allocated to mediaIpInterfaceGroupName after the use of this variable is completed.

Workaround: None.

SBX-102151 | SBX-1031532

Portfix SBX-102151: D-SBC is not sending the rtp packets to other end after transfer in a transcoded call.

Impact: On the D-SBC, one way media was observed with no media towards calling party A post call transfer by B to C for the scenario: First call (A-SBC-AS, AS-SBC-B), Second call (B'-SBC-AS, AS-SBC-C), where AS=Broadsoft application server.

From packet capture on A-SBC leg of the single DSP transcode call, the sequence number of packets sent by the SBC was reset to zero after A is put off hold. This issue is not seen on the I-SBC.

Root Cause: In the D-SBC, with every modify (ex: hold/resume) a new DSP(s) is allocated for a transcode call. The RTP sequence number and RTP timestamp from previous the DSP deactivation were not being passed to the subsequent DSPs allocated in the context of the same RTP stream (SSRC).

Steps to Replicate: Ways to replicate the issue:

1. A simple UAC (G711)-SBC-UAS (G729) transcode call on D-SBC platform which uses a single DSP.
Perform a call hold and resume from UAS and observe the RTP packets sequence numbers towards UAC.
The sequence number is reset to zero post resume leading to one way media (no media towards UAC post resume).
2. With call transfer:

Test Set up:
A1,A2,A3 -------------DSBC--------------NS,AS,MS (HOSTED)

Preconditions:
1. Endpoints A1, A2, and A3 are registered with operator AS through SBC5K (DSBC).
Procedure:
2. A1 calls A2, answer the call on A2.
3. User A2 initiates a attended transfer to User A3, User A3 answers the call.
4. Disconnect the call from A1/A3.
5. After A1 is put off hold after successful transfer, the sequence number would be reset to zero leading to one way media (no media towards A1).

The code is modified to ensure the RTP sequence number and the RTP timestamp statistics of both G711 side of DSP and non-G711 side of previous DSP deactivation are passed to the subsequent DSP, so that the sequence number continues incrementing sequentially within the same media stream/SSRC instead of restarting from zero for every modify.

Workaround: No workaround.

SBX-104156  | SBX-1045703

Portfix SBX-104156: The RTT-TTY support verify call flow in the SBC.

Impact: Lower case characters from the t140 packet were not getting converted correctly to Baudot (tty). Also, some other characters were not getting converted as per V.18 A2 table.

Root Cause: The translation table from T140 to Baudot (TTY) only accounted for subset of characters that were present in Baudot (TTY) character set.

Steps to Replicate: 

  1. Set up a T.140=>Baudot (AMRNB=>G711) call.
  2. Create a T.140 pcap file with all UTF8 characters (128) and validate baudot generation.
  3. Create a T.140 pcap file with multi-byte sequence and validate baudot.

The code is modified for:

  • The t140=>Baudot translation table as per V.18 Annx2.
  • Handling valid multi-byte (2,3 and 4 bytes).
  • Handling of Byte Order Mark (BOM).
  • Invalid byte sequence and substitute valid but unknown multi-byte seq with an apostrophe.

Workaround: Instead of lower case letters, use upper case letters.

SBX-98884 | SBX-996902

Portfix SBX-98884: The LeakSanitizer detected memory leaks at the IcmAlloc2.

Impact: The ASAN shows a memory leak when run with the surrogate registration.

Root Cause: A memory leak caused by the ICM request message since it did not free the SURROGATE task.

Steps to Replicate: 

  1. Install the ASAN build.
  2. Configure the surrogate registration.
  3. Once the registration complete, disable the surrogate conf and cleanup.
  4. Verify the ASAN leak report.

The code is modified so now the ICM memory is freed in the SURROGATE task when receiving a request from the SIPFE.

Workaround: N/A

SBX-100713 | SBX-1035872

Observing the major log "XrmAsyncCmdErrHdlr: ERROR NpMediaIntf cmd 2a gcid" in all nodes of the 2:1 cluster.

Impact: Observed the major log "XrmAsyncCmdErrHdlr: ERROR NpMediaIntf cmd 2a gcid" in all nodes of 2:1 cluster.

Root Cause: As the error did not have a valid GCID, the error log becomes unidentified, since there is no action taken by application based on this error message.

Steps to Replicate: Set up:

1. An SBC 2:1 cluster with flavor 32vCPU/32GB RAM/100GB disk /2GPU per instance.
2. OAM 1:1 . Flavor 4vCPU/6GB RAM/25GB disk.
3. C3 - MGC.
4. Pktart.
5. EMS.
6. AMRWB-G711U call flow.
7. Load sharing enabled in C3 to distribute the load between two active nodes.
8. Custom traffic profile and codec profile are configured.

Procedure:

1. Ensure the SBC1 and SBC3 are active nodes and SBC2 is a standby.
2. Place calls at 394 CPS and 62s as CHT.
3. Calls are distributed between SBC1 and SBC3.
4. The below log messages are found in all nodes of the 2:1 cluster.

The code is modified to move the error message below the GCID validity check.

During the validation if any issue is found, there is only valid points.

Workaround: None.

SBX-103154 | SBX-1034002

Portfix SBX-103154: The SBC:9.1 Comp_EnmProcessMain experienced a core dump.

Impact: Observed an EnmProcess core dump in a AWS instance when the license is applied immediately after the SBC comes up.

Root Cause: When the SBC comes up, the EMA loads default configurations on to the SBC (in this particular case it was loading the trap target configuration) and at the same time, the automation suite run by Design triggered the license installation. The race condition between the EMA trigger and the license command caused a deadlock because no command was able to proceed to completion and EnmProcess cored.

Steps to Replicate: To simulate the simultaneous trigger from EMA (REST API) and CLI, the following script was running to create and delete the trap target. While the script was running, a CLI session was opened and license installation command was run:


#!/bin/bash
while : ; do
curl -kisu admin:admin -XPUT -H "Content-Type: application/vnd.yang.data+xml" https://<EMA IP>/api/config/oam/snmp/trapTarget/target1 --data '
<trapTarget xmlns="http://sonusnet.com/ns/mibs/SONUS-ORCA/1.0">
<name>target1</name>
<ipAddress>127.0.0.1</ipAddress>
<port>8163</port>
<trapType>v2</trapType>
<targetUsername>admin</targetUsername>
<targetSecurityLevel>noAuthNoPriv</targetSecurityLevel>
<state>enabled</state>
</trapTarget>
'
curl -kisu admin:admin -XDELETE https://<EMA IP>/api/config/oam/snmp/trapTarget/target1
sleep .5;
done

The code is modified to handle license installation to a thread so that it is not blocked by any other command and it does not block any command.

Workaround: Delay the license installation for a few seconds after the SBC is up and running.

SBX-100938 | SBX-1017972

Portfix SBX-100938: An SCM process core dump was observed on the SBC for Blind Transfer no Answer from the customer when replied with 603 Decline.

Impact: On the refer failure tone was not aborted. Due to this, the media resources were in the wrong states. So when the SBC tried to revert to original call, it crashed.

Root Cause: Design was not aborting the tone on refer failure. This lead to issue in media handling.

Steps to Replicate: 1. Initiate a basic C2C from the customer app through KL user to Cisco EP1.
2. Call is answered.
3. Initiate a transfer call from the customer app to PSTN POLYCOM EP.
4. After REFER for Transfer is received on the SBC, KL will be out of call.
POLYCOM EP do not answer the call and sends 603 Decline.

At this point, a crash should not happen and the SBC reverts to the original call.

The code is modified to abort tone on refer failure.

Workaround: None.

SBX-100515 | SBX-1034022

Portfix SBX-100515: Calls are getting rejected with 403 instead of 480, when configured subscribeBurstMax is more than subscribeRateMax.

Impact: The subscriber request are getting rejected with 403 instead of 480, when configured, the subscribeBurstMax is more than subscribeRateMax.

Root Cause: The EndPoint Rate policy for the SUBSCRIBER request putting into OOD (OUT OF DIALOG) request bucket and request handling was treated as SUBSCRIBER, as a result it response causes the code mapping was not working for subscriber.

Steps to Replicate:

1. Configure the subsIngressEndPointRatePolicing in internalSipCauseMapProfile. [set profiles signaling sipCauseCodeMapping internalSipCauseMapProfile <profile_name> causeMap subsIngEpRatePolicing sipCause 480].
2. Configure the internalCauseString ex: "subscription rate exceeded" for subsIngEpRatePolicing [set profiles signaling sipCauseCodeMapping internalSipCauseMapProfile <profile_name> causeMap subsIngEpRatePolicing internalCauseString subscription rate exceeded].

3. Set TG level subscribe rate as 4 in ingress Cac [set addressContext default zone <Ingress_zone> sipTrunkGroup <Ingress_TG> cac ingress subscribeRateMax 4 subscribeBurstMax 6].
4. Send 8 subscribes per second to SBC from ingress Trunk group.

The code is modified to keep the EndPoint Rate policy for SUBSCRIBER in the SUBSCRIBER rate policy bucket.

Workaround: None.

SBX-1043472

Resource memory congestion level 3 is approaching threshold 90 sample 82.

Impact: The SIPCM is leaking a structure that is associated with the SIPMM functionality.

Root Cause: The code to free this memory under certain error/edge scenarios is missing.

Steps to Replicate: Since we do not know the exact call flow that caused the customer to hit the error condition, we cannot suggest Test Steps.

The code is modified to free the SIPMM related structure in error scenarios.

Workaround: Since we do not know the exact call flow that caused the customer to hit the error condition, we cannot suggest a workaround.

SBX-103634 | SBX-1042302

Portfix SBX-103634: The LeakSanitizer: detected memory leaks in DCmRestoreAllMetaVarsToStandbyContext.

Impact: A small Memory leak was observed in the SAM process while doing a switchover from standby to active box.

Root Cause: The standby instance stores information about the metavars associated with signaling ports configured on the active instance. During the conversion from standby to active. The standby data is moved into active structures but the original standby memory blocks are not freed up correctly resulting in a memory leak.

Steps to Replicate: Perform a switchover from standby to active while running a basic call, no memory leak will observed in the SAM process.

The code is modified to correctly free the memory associated with the standby data when it is transitioned to active to avoid the memory leak.

Workaround: None.

SBX-103988 | SBX-1045462

Portfix SBX-103988: The ICE not working after an upgrade.

Impact: When a call with ICE changes from direct media to pass through, ICE learning does not get enabled on the call.

Root Cause: The code was not re-enabling the ICE FSM to start ICE learning when changing from direct media to pass through.

Steps to Replicate: 

Test 1
--------

  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 pass through to allow the receipt and processing of stun messages to complete ICE learning.

Workaround: N/A

SBX-1030283

The PRS process cored in NP media interface function.

Impact: The PRS process cored in NP media interface function.

Root Cause: When examining the source code, we found the command sent to NP was not initialized properly.

Steps to Replicate: This cannot be easily reproduced.

The code is modified to initialize the command correctly.

Workaround: None.

SBX-98843 | SBX-1044482

Portfix SBX-98843: Problem with management of the maxptime and ptime in Direct Media mode.

Impact: Problem with management of the maxptime and ptime in Direct Media mode.

Root Cause: Generally, the SBC ignores the ptime value if only the maxptime attribute is present in incoming SDP. If "sendPtimeInSdp" IPSP flag is enabled and peer is sending both ptime and maxptime, the SBC is preferring maxptime value while sending ptime.

The existing IPSP flag "sendPtimeInSdp" makes the SBC send out a=ptime, irrespective of what we receive from the peer.

Steps to Replicate: 

R-i=20 R-e=20
-----INVITE--------> SBC -----INVITE-------->
ptime=20
maxptime=40 ptime=20

  1. Do a basic call from A to B.
  2. A sends ptime=20 and maxptime=40 towards the SBC.
  3. The Invite going out from the SBC should contain ptime=20 as we enabled both "sendPtimeInSdp" IPSP flag and "preferPtimeInSdp" TG flag.

The code is modified when this new flag "preferPtimeInSdp" is enabled, the SBC prefers ptime value received in a=ptime over a=maxptime in an incoming SDP.

This new flag "preferPtimeInSdp" needs be enabled in conjunction with existing flag "sendPtimeInSdp". If the SBC is configured to send a=ptime (isendPtimeInSdp is enabled on
outgoing trunk), then the preferPtimeInSdp is enabled on incoming trunk and vice versa.

Workaround: None.

SBX-97818 | SBX-103401 2

Portfix SBX-97818: The audio stream with port=0 appears in callDetailStatus.

Impact: The audio stream with a port=0 shows up in the .

Root Cause: Currently, for an audio stream, there is no condition for stream absent. As a result, an audio stream is retaining even if a port is 0.

Steps to Replicate: Video and Audio (Audio Port = 0)
1. Make a basic video only call from A-B.
2. On a re-invite, add a Audio stream with valid port.
3. On the final re-invite change Audio port to 0.
 
Existing Behavior:
When Audio port is 0, audio stream is displaying in callMediaStatus and callDetailStatus

New Behavior:
When the Audio port is 0 complete Audio stream is removed from callMediaStatus and callDetailStatus.

The code is modified for an audio stream so that in a Video and Audio (audio port = 0) call, the audio stream gets removed from callMediaStatus and callDetailStatus.

Workaround: None.

SBX-92770 | SBX-99738 2

Portfix SBX-92770: The SBC is not relaying the INFO coming with the message body to the other leg.

Impact: After a call transfer, an in-dialog SIP INFO messages were not relayed by the SBC.

Root Cause: The code was missing to handle the relay of the SIP INFO messages received on a transferred leg.

Steps to Replicate: 

  1. Establish an A--->SBC--->B call.
  2. A transfers a call to C. The call is now between B and C.
  3. Either Party B or C sends an in dialog SIP INFO message.

The code is modified to handle the relay of INFO messages received after call transfer.

Workaround: N/A

SBX-104670 | SBX-1048452

Portfix SBX-104670: Add the configStore information to the sysdump.

Impact: Missing the configStore data to properly investigate the configuration revision issues.

Root Cause: Missing the configStore directory content list in the configStore tarball produced by the sysDump.pl.

Steps to Replicate: Execute the sysDump.pl and check that virtualLogs/configStore tarbal contains the configStore directory content list.

Add a configStore directory content list in the configStore tarball produced by sysDump.pl to address the issue.

Workaround: Get the configStore directory content list directly from the node(s).

SBX-1005902

An incorrect "Egress Zone Name" in ATTEMPT CDR for a GW-GW call.

Impact: For a call with multiple routes that include one or more local routes followed by routes on another gateway (for GW-GW) scenario, if the local routes fail and then other gateway route is selected, the resulting ingress gateway CDR for the call has an incorrect egress zone name and ID.

Root Cause: When there are multiple routes, when a route fails the call cranks back to use the next route but when selecting the next route the code is not clearing the internal CDR information for the egress zone, so if the next route selected is on another gateway the CDR information retains the egress zone information from the previous attempt rather than being blank.

Steps to Replicate: 

  1. With SBC GW-GW set up create two routes for a call such that:
       - route 1 is through local egress trunk group on the SBC1.
       - route 2 is through egress trunk group on the 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 that there are two Attempt CDR records for the call on the SBC1:
    1. ATTEMPT1 should have "Egress Zone Name" and "Egress Zone ID" fields populated correctly with zone information for zone of the SBC1 egress.
    2. ATTEMPT2 should have "Egress Zone Name" empty and "Egress Zone ID" as 0 because this is 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-104741 | SBX-1047772

Portfix SBX-104741: An error message is not displayed while creating an IP Peer, Ingress Ip Prefix, Radius Server.

Impact: The error message is not displaying while creating an IP Peer, Ingress Ip Prefix, Radius Server.

Root Cause: The error message was not displayed because we handled that error in the code and are unable to send it to the UI.

Steps to Replicate: Steps to reproduce the issue:

  1. Login to the EMA as admin user.
  2. Click on All Menu.
  3. Expand Address Context > Zone > Ip Peer.
  4. Create Ip Peer with IpAddress "::1" and ipPort "7080".
  5. Click on Save.

The code is modified to throw an exception/Error to the UI.

Workaround: If we perform the same operation from CLI , we can get the same error message.

SBX-1047042

Duplicate audio entries in the route PSP.

Impact: If the number of codec entries in the packet service profile is more than 4, then the ERE was sending the codec entries 5-12 in the policy response twice. The duplicate entries could potentially cause problems when the SBC is performing codec intersection logic resulting in some codecs not being selected so the best audio match might not happen.

Root Cause: The ERE was incorrectly calling a function to populate entries 5-12 in the policy response twice.

Steps to Replicate: Populate the PSP with more than 4 codec entries in the ingress PSP and egress PSP and review the pes.logs to see the duplicate entries.

The code is modified to remove the functions that populated the codec entries 5-12 in the policy response so they only get return once.

Workaround: None.

SBX-102370 | SBX-1033352

Portfix SBX-102370: Subscription State is not updated as per expires parameter received in NOTIFY.

Impact: The subscription State is not updated based on the expired parameter received in the NOTIFY.

Root Cause: The SBC was not processing the expires in the Subscription-State header of the NOTIFY.

Steps to Replicate:

1. Run SUB-200 OK.
2. Send NOTIFY1 from UAS with expires parameter time t1.
3. Send NOTIFY2 from UAS with expires parameter time t2. (t2<t1)

The code is modified to consider the expires value in header, during the state "active" or "pending".

Workaround: None.

SBX-103669 | SBX-1048602

Portfix SBX-103669: Empty the "Egress Local Signaling IP Addr" field in the CDR.

Impact: When an incoming call is routed out of the SBC but is then rejected by the SBC with cause 132 Module failure before a backwards response message is received, the resulting CDR attempt has an empty "Egress Local Signaling IP Addr" field.

Root Cause: The SBC currently populates the "Egress Local Signaling IP Addr" CDR field when it processes a backwards response message for the call, and as a result, the field remains empty until a backwards response message is received and processed.

Steps to Replicate: 

  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 the 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 attempt CDR 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 when sending out the egress INVITE message.

Workaround: None.

SBX-102996 | SBX-1033322

Portfix SBX-102996: The wrong CSeq number was sent for BYE as part of a call termination after a SBC switchover.

Impact: The wrong CSeq number was sent for BYE as part of a call termination after an SBC Switchover.

Root Cause: When a In dialog Event INFO is received containing body/content type as 'media_control'. The SBC generates a new INFO request towards peer. Due to this the Cseq, in a dialog gets increased, this modified Cseq value was not mirrored to the SBY.

Steps to Replicate:

1. The call is established between PSTN User-B to Cisco User-A.
2. User-B initiates a Blind transfer call to PSTN User-C and answered on C.
3. Various INFOs are exchanged.
4. Perform SBC Failover after answering the call on User-C.
5. Send OOD Refer from Kandy Link having Refer-To header with method = BYE, valid Target-Dialog header and Request-URI points to SBC for Call Termination of PSTN User-C.
6. SBC sends BYE to both User C and User A.

The code is modified to the SBY during the INFO flow fixes the problem.

Workaround: Avoid the fail overs and use the stand alone set up.

SBX-73860 | SBX-1046922

Portfix SBX-73860: The SAM process coredumps after a restart during surrogate registration and deregistration.

Impact: The SAM process coredumps after a restart during surrogate registration and deregistration.

Root Cause: Accessing the pointer without a NULL check causes the core dump.

Steps to Replicate: 

  1. Enable the flag sendSurrogateUnRegAfterReboot using set global signaling sipSigControls sendSurrogateUnRegAfterReboot enabled.
  2. Enable surrogate registration the SBC starts sending REGISTER to registrar. Set the addressContext default zone zonein ipPeer PEER1 surrogateRegistration state enabled.
  3. Registrar responds with 401 Authentication header response.
  4. After receiving the challenge REGISTER that contains a valid Authorization header, the registrar responds with 200 OK.
  5. Switchover from active to standby using request system admin HA-5100 switchover.
  6. Switchover again using request system admin HA-5100 switchover.
  7. Restart both the HA-PAIR.
  8. Registrar responds with 200 OK for all the unREGISTERs sent by the active SBC when the services come up.
  9. After successful deregistration, the SBC starts sending REGISTER to registrar.
  10. Registrar responds with 401 Authentication header response.
  11. After receiving the challenge REGISTER that contains a valid Authorization header, the registrar responds with 200 OK.

The code is modified to avoid a segmentation fault.

Workaround: None.

SBX-749912

Saving changes to a SMM profile after doing an edit/update operation is taking long time[8 to 16 minutes].

Impact: A SIP Adaptor Profile with 250+ rules takes lot of time to create, including taking a lot of time to update.

Root Cause: When the SIP Adapter Profile with more than one rule is created, each rule is committed individually. However, after each commit EMA internally retrieves all the SIP Adapter Profiles along with their rules, though this is not required it is causing slowness of both create and update operation.

Steps to Replicate: 

  1. Login to the EMA.
  2. Navigate to the SIP Adapter Profile Screen.
  3. Create a profile with 200+ Rules.
  4. Click on Save button.

The code is modified to prevent the retrieval of SIP adapter profiles after each commit.

Workaround: The only workaround is to create the profile from the CLI.

SBX-100702 | SBX-1035862

Portfix SBX-100702: Observing the "ERROR : Channel 146 already in de-activated state" in the dsp log.

Impact: The dsp.log is overwhelmed with the "ERROR: Channel ## already in de-activated state" prints.

Root Cause: In the GPU design, as part of the command optimization, if there are more than one command for a channel in a particular time slot, the most recent command for the channel is sent to GPU for processing.

The call flow exercised, activates and de-activates the channel immediately, which could be potentially result in sending the activate command followed by de-activate command for the channel in the same time slot. Due to the command optimization mentioned above, the de-activate command is sent for the channel. Since the channel is already in de-activated state and an attempt is made to de-activate it, a message is printed.

Steps to Replicate: Activate and de-activate a channel immediately within 20ms.

The code is modified to disable the prints to not overwhelm the log and impact performance.

Workaround: None.

SBX-102745 | SBX-1033612

Portfix SBX-102745: The C_LIST macro for consistent memory was freeing.

Impact: When making changes to the local auth user configuration on the SBC, it was leaking small amounts of memory.

Root Cause: While processing the list of configured users, the application code was reading the CDB information into local buffers and then not freeing it, leading to a small memory.

Steps to Replicate: This issue is highlighted when make local user configuration changes in the engineering lab with ASAN images.

The code is modified with standard macros to delete the list structures in a generic manner to avoid this problem in the future.

Workaround: None.

SBX-1048512

The SBC is down and the standby registration with active failed, error 160004.

Impact: Standby is not allowed to join cluster and fails to start

Root Cause: The safplus checkpoint file is corrupt and the section needing to be overwritten is not found.

Steps to Replicate: The root cause of the checkpoint corruption is unknown/checkpoint corruption cannot be forced and therefore directly testing this fix is not possible.

The code is modified to re-add the missing section if it is not found.

Workaround: A complete outage is required in order to restart the active server.

SBX-1050722

The password padding with random characters by the SBC causes the RADIUS server to reject the password.

Impact: The radius password sent to the server has no zero characters at the end, following the password and a NULL.

Root Cause: The radius passwords are padded to 16 characters. The existing implementation did not set those padded characters to 0.

Steps to Replicate:

  1. Configure a radius authentication server.
  2. Use a password that is less than 15 characters long for the external radius user.
  3. Set 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 code is modified so the padded characters are now set to 0.

Workaround: Use 15 or 16 character passwords.

SBX-1041132

The LI mediationServer signaling channel was online even if the interface was down.

Impact: Without this fix, the LI mediationServer signaling channel stays online, even after ipInterfacegroup attached to call data channel (CDC) is disabled post a switch-over.

Root Cause: The root cause came from code handling the LI mediation server signaling socket functionality did not register for ipInterfaceGroup operational status in standby mode.

As a result, post switch-over it does not get any notification when ipInterfaceGroup attached to CDC toggles. The signaling connection towards mediation server is not closed.

Steps to Replicate: 

  1. Create the CDC and configure it for IMSLI and validate that the LI signaling channel is inService.
  2. Run a switch-over.
  3. Disable the ipInterfaceGroup attached to CDC.

The code is modified to register the ipInterfaceGroup that is attached in the CDC in standby mode as well so that if and once it becomes active due to switch-over, it is put into operational status of the ipInterfaceGroup attached to the CDC.

Workaround: None.

SBX-1041322

Incorrect indication for whether the SMM was applied or not required.

Impact: For machine parsing of trace logs, it is necessary to have a consistent field in the trace which indicates the message sent on the wire, regardless of whether the SMM is applied or not.

Root Cause: There was a design issue.

Steps to Replicate: 

  1. Make a SIP-SIP call with L4 call trace enabled.
  2. Messages sent on the wire have trace "SMM: OUTBOUND PRE-SMM"
  3. Make a SIP-SIP call with L4 call trace enabled and an outbound SMM active.
  4. Messages sent on the wire have trace "SMM: OUTBOUND POST-SMM"

When the SMM is applied to a message, the behaviour is unchanged.

When an SMM is not applied to a message, the L1-3 trace has "EXTRA_INFO: After SIPMM profile" and the L4 trace has "SMM: OUTBOUND POST-SMM".

When looking for messages as sent on the wire, the post SMM trace can always be used.

Workaround: None.

SBX-102501 | SBX-1050362

Portfix SBX-102501: The SBC fails to relay an embedded header in Contact of 3xx with statusCode3xx relay enabled.

Impact: The SBC fails to relay an embedded header in Contact of 3xx with statusCode3xx relay enabled.

Root Cause: The code required to send the embedded part in contact of 3xx was not present.

Steps to Replicate: 

  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 an 300 Multiple Choice from UAS with below Contact header that has embedded headers.

The code is modified to set only in the relay 3xx case to send the entire contact header transparently.

Workaround: None.

SBX-94798 | SBX-1042722

Portfix SBX-94798: MS Teams with FLRBT enabled hangs the call.

Impact: When Force Local Ringback Tone is applied on a call that been through SIP replace followed by SIP refer procedure, and the final trunk group has downstream forking enabled, the final 200 OK response may be queued indefinitely, meaning the call does not complete.

Root Cause: Interactions between Force Local Ringback Tone, multi-party and downstream forking.

Steps to Replicate: 

  1. Make a SIP to SIP call.
  2. A calls B.
  3. B' replaces B.
  4. B' refers to C.
  5. Trunk for A has Force Local Ringback Tone applied.
  6. 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-104826 | SBX-1050913

Portfix SBX-104826: The SBC fails to relay to 3xx and picks the next route when EnhancedLocalRedirection and StatusCode3xx flags are enabled.

Impact: The SBC fails to relay the received 3xx to the ingress side and picks the next route when EnhancedLocalRedirection and StatusCode3xx flags are enabled with 2 routes.

Root Cause: When both the StatusCode3xx and EnhancedLocalRedirection are enabled for the 2 routes scenario, performCrankback is set to true that leads to this issue.

Steps to Replicate: 

  1. Configure the SBC for A to B call over ERE.
  2. Configure ERE to return two routes for Initial call R1, R2.
  3. Enable the flag statusCode3xx, EnhancedLocalRedirection on TG IPSP.
  4. Send to INVITE from UAC.
  5. Send to 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-1042142

A SIPREC Codec negotiation issue occured.

Impact: Without this fix, the wrong codecs are negotiated with the SRS when communication sessions is renegotiated.

Root Cause: Because of the wrong conditions in code, the codec information that is to be sent towards SRS is fetched from peer packet service profile rather than active service profile from the communication call leg.

Steps to Replicate: 

  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 a re-INVITE with G711U codec to SIPRec Server.

With this fix, the SBC now sends a re-INVITE with G711A codec to SIPRec server.

The code is modified to fetch correct codec information from the communication session and the same is sent in recording session.

Workaround: None.

SBX-100864 | SBX-1033762

Portfix SBX-100864: The ASAN detected heap-use-after-free in DnsClientTcpSocketRecvMsg.

Impact: When a connection to a DNS server running on transport protocol TCP closes, memory is accessed after it is freed, potentially leading to unexpected behavior.

Root Cause: A connection to a DNS server running on transport protocol TCP closes.

Steps to Replicate: Address Sanitizer (ASAN) build is used to find the issue. Configure a DNS server with transportProtocol TCP. Run a call which requires DNS lookup.

The code is modified to correct management of DNS connections running on transport protocol TCP.

Workaround: None.

SBX-103814 | SBX-1047262

Portfix SBX-103814: The RECORDING CDR does not have correct value for SRTP field during a switchover.

Impact: The SIPREC related "RECORDING" CDR did not had correct values for SRTP related statistics fields during a switchover.

Root Cause: It was identified that there was a missing code that actually copies the SRTP related statistics fields data onto to the standby machine.

As a result, whenever the standby machine comes up as active the SRTP related data in RECORDING CDR was not populated correctly.

Steps to Replicate: 

  1. Execute a SRTP SIPREC scenario.
  2. Perform a switchover.
  3. Verify the RECORDING CDR.

The code is modified to copy the SRTP related fields data onto standby machine.

Whenever standby machine comes up as active, the SRTP related data in RECORDING CDR is populated correctly.

Workaround: None.

SBX-1042132

The SCM process cores when targets set for OPTIONS/MESSAGE.

Impact: Without this fix, the SBC will core dump when the Out Of Dialogue messages like OPTIONS/MESSAGE are intercepted.

Root Cause: The double freeing of a data structure is causing the code dump.

Steps to Replicate: 

  1. Provision packet cable 2.0 Targets corresponding to the out of dialogue OPTIONS that will be sent to the SBC.
  2. Send 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-76462 | SBX-997442

Portfix SBX-76462: The incorrect MaxAverageBitRate value is populated in the "ingress codecParams1" after a switchover.

Impact: The incorrect MaxAverageBitRate value is populated in the "ingress codecParams1" after a switchover.

Root Cause: Some of the codecs attribute values were being set to 0 after a switchover, and as a result those values were getting assigned to the default values.

Steps to Replicate: Run aSILK_NB to SILK_NB call.
After the switchover, the MaxAverageBitRate value is 0 instead of 20000 in the "ingress codecParams1 and egress codecParams1".

To fix the issue, those statements are removed and change the attribute fields as a result.

Workaround: Some of the codes use certain attribute fields as being defined. But after the switchover, these used attributes field values have been changed to 0. For those codecs, these statements have been eliminated.

SBX-95677 | SBX-1047252

Portfix SBX-95677: The SBC is not feeding delayed RBT on monitoring failure in a late media pass through scenario in CLOUD ISBC and SWE ISBC.

Impact: The SBC is not feeding delayed RBT on monitoring failure in a late media pass through call

Root Cause: The fix for SBC not feeding delayed RBT on monitoring failure in a late media pass through scenario was applicable only when bToneAsAnnc flag is enabled.

Steps to Replicate: 

  1. An INVITE received without SDP and no "PEM: supported" from UAC.
  2. UAS sends 183 with SDP and no PEM having PCMU,AMR.
  3. UAC send PRACK with SDP PCMU,G729 and UAS sends 200 OK for PRACK.
  4. UAS sends authorized RTP.
  5. UAS sends 180 without SDP and no PEM.
  6. UAC send PRACK and UAS sends 200 OK for PRACK.

After an RTP Monitoring failure, the SBC should play the tone.

The code is modified to address the issue.

Workaround: None.

SBX-97598 | SBX-1033662

Portfix SBX-97598: The LeakSanitizer detected memory leaks at SipSgGetHpcCallProfileFromDb.

Impact: There was a memory leak when configuring and updating the HPC Call Profile gets the Strings Feature Code, Access Number and Number Translation.

Root Cause: Configuring and Updating the CLI Hpc Call Profile gets the Strings Feature Code, Access Number and Number Translation.

Steps to Replicate: None.

The code is modified so while de-allocating the list's while retrieving the data in the Feature Code, Access Number and Number Translation.

Workaround: None.

SBX-102985 | SBX-1033932

Portfix SBX-102985: The CDR field 'Ticks from Set up Msg to Service Est.' of a START record is getting logged with the wrong value.

Impact: The CDR field 'Ticks from Set up Msg to Service Est.' of the START record is getting logged with the wrong value when the "End To End ACK" is enabled and "No CDR Change in End To End ACK" is disabled.

Root Cause: Since the E2E ACK is enabled and No CDR Change in E2E Ack is disabled, the call connect time was not getting updated during the 200 OK and the value is still '0'. Due to this issue, the time difference of a call attempt time and the connect time was coming as a huge value.

Steps to Replicate:

1. Enable IPSP flag "End to End ACK" on both TGs.
2. Disable the flag "No CDR Change in End to End Ack".
3. Make a call from A to B and let the call be connected with session refresh enabled.
4. Once the session refresh occurs, disconnect the call and check the CDR.

The code is modified to not trigger the CDR start record when NRM call stable notification is received. Instead, the modified code delays the CDR until the ACK is received from the ingress, so that, the call connect time gets recorded before generating the start record and addresses the issue.

Workaround: None.

SBX-103807 | SBX-1047222

Portfix SBX-103807: The SBC disables the SRTP for audio when the EP disables and re-enables the audio.

Impact: The SBC disables SRTP for audio when EP disables and re-enables the audio.

Root Cause: During the modify offer processing, the SRTP value is taken from previous Active security PSP without checking if SRTP is valid or not.

Steps to Replicate: Set up Audio and Video RTP to SRTP pass through call between UAC-UAS:

  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 200OK 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 200OK with valid Audio and Video crypto lines.

Copy the Active security PSP only if the SRTP admin state is enabled to address the issue.

Workaround: None.

SBX-101264 | SBX-1028222

Portfix SBX-101264: The ingressBearerType and egressBearerType is "multimedia", even though negotiation is only with a single audio codec.

Impact: The ingressBearerType and egressBearerType is "multimedia", even though negotiation is only a with single audio codec.

Root Cause: At present, the bearerType is set as audio only if Audio stream is present at the first index. As a result, audio only call with audio stream present at index>1 (say (video port=0) + audio (valid port)) gets marked as multi-media call.

Steps to Replicate: 

  1. Offer and answer contains video m line with valid port and audio m line with port 0.
    BearerType: Multimedia
  2. Offer and answer contains video m line with port 0 and audio m line with valid port.
    BearerType: Voice
  3. Offer and answer contains first audio m line with valid port and video m line with port 0.
    BearerType: Voice
  4. Offer and answer contains first audio m line with port 0 and video m line with valid port.
    BearerType: Mutlimedia
  5. Offer and answer contains multiple audio m-line.
    BearerType: Multimedia
  6. Initial Offer answer with multimedia and then send re-INVITE with only audio.
    BearerType: Multimedia
    BearerType after Re-INVITE: Voice
  7. Initial Offer answer with audio and then send re-INVITE with multimedia.
    BearerType: voice
    BearerType after Re-INVITE: Multimedia
  8. Initial Offer and answer contains video m line with valid port and audio m line with port 0 then send re-INVITE with audio m line with sendonly (This scenario is as per SBX-97358) BearerType: Multimedia. BearerType after Re-INVITE : Multimedia

The code is modified to set the bearerType as audio irrespective of the audio stream index if the only active stream present in SDP is audio.

Workaround: None.

SBX-100868 | SBX-1035882

Portfix SBX-100868: The OAM does not push the configuration after a switchover to the standby OAM.

Impact: The configuration changes on the standby OAM is not rejected. After a switchover, it would not take the same configuration changes as it is already done locally. It will not playback either the save and activate as there is no playback logs created. There is no way to push the changes to the managed nodes until another switchover.

Root Cause: Skipping the playback log creation on the standby OAM caused an inconsistent state between the local configuration store and the playback logs.

Steps to Replicate: Perform a switchover with the same configuration to reproduce the issue.

The code is modified so attempts to make configuration changes on the standby OAM node are now rejected.

Workaround: Switchover back to the original active and restart the standby node so that it resyncs with the active.

SBX-100483 | SBX-1033832

Portfix SBX-100483: Observed a coredump Comp_SamP after disabling the sipSigPort.

Impact: While disabling the SIP signaling port, the SBC dumped core due to system error.

Root Cause: In the SBC, the wrong context ID was used to fetch the metavar related information while configuring (enabling/disabling) the SIP signaling port. As a result, the SBC has generated a system error.

Steps to Replicate: Bring up a Public Cloud (AWS) 1:1 HA system. Restart the standby SBC node. Try to disable the SIP signaling port. The SBC generated the coredump due to system error.

The code is modified to pass the correct context ID information while fetching the metavar related information while configuring the SIP signaling port.

Workaround: Execute the disabling of the SIP signaling port when the standby is up and running.

SBX-102927 | SBX-1050292

Portfix SBX-102927: The problem with migration of table_version_info was causing the EVS codec attributes non-readable after upgrade from 7.2 to 8.2.

Impact: The upgrade fails to set the default value for maxChannel flag.

Root Cause: The table_version_info table was not getting populated.

Steps to Replicate: The table_version_info table should have data on fresh install.

The code is modified to address the issue.

Workaround: The value in db for attribute3 in code entry table should be modified to set the default value of maxChannels.

SBX-93308 | SBX-973142

Portfix SBX-93308: No DLRBT Tone Play can be heard on User-A phone in a Blind Transfer scenario using 180 ringing with SDP.

Impact: There is no DLRBT tone play heard on the transferee while transferrer does a blind transfer.

Root Cause: When 180 with SDP received from transfer target, SBC is trying to activate the tone resources towards transferee side. But, before this tone activation occurs, the CUT_THRU is received from the transferred leg that is causing to abort the tone.

Steps to Replicate: 

  1. Make a call from the customer to the Cisco phone User-A that is a passthrough call.
  2. Initiate the transfer call from the customer to the User B.
  3. After a REFER (Direct Media) on the User-A phone DLRBT is not played.

The code is modified so it ignores this CUT_THRU received from the transferred leg and as a result, the tone is not getting aborted. When a CONNECT or RTP packet is received, then the tone is aborted.

Workaround: N/A

SBX-1041492

The SBC fails to send ACK for a self generated re-Invite when the E2E ACK and E2E re-Invite flags are enabled.

Impact: The SBC fails to send ACK for a self generated re-Invite when the E2E ACK and E2E re-Invite flags are enabled.

Root Cause: When both the E2E re-Invite and E2E Ack are enabled, do not send the ACK re-enable, the SBC was not handling ACk properly for the self-generated re-Invite.

There are scenarios when E2e is received RCVD from the Network where the ACK does not need to be sent for a re-Invite from the SIPSG in race condition scenarios.

So there was no check to identify if the re-Invite is self generated or the RCVD from a network and wrong logic was executed for the self-generated Invite.

Steps to Replicate: Test Configuration:
=============

  1. Enable E2E ACK, E2E Reinvite, E2E PRACK, E2E UPDATE flags in IPSP.
  2. Enable flag "send sdp in 200 ok if 18x reliable" in IPSP.


Test Procedure:
===========

  1. UAC sends Invite with SDP.
  2. UAS sends 183 with SDP reliable.
  3. PRACK/200 OK is done.
  4. UAS sends UPDATE with SDP.
  5. UAC sends 200 OK with SDP.
  6. UAS sends 200 OK without SDP.
  7. UAC sends ACK.

The code is modified so if the re-Invite is self generated then send ACK.

Workaround: None.

SBX-99409 | SBX-996972

Portfix SBX-99409: The EMA is not displaying all recordings for the SIPREC status command.

Impact: The proper SIPREC status was not displayed when more than one recording going on for a specific call on EMA or when checking the status with all the set of keys on the CLI. The SipRecStatus command was updated with new keys (GCID, legId, Recorder IP:port) but the application had a issue that it looked up the data only based on the GCID.

Root Cause: When the status command is issued through the EMA, the EMA queries with all the keys and as a result, the application would end up fetching the first recording for each of the queries. Same thing happens when querying on CLI with all keys for specific entry we end up getting first entry for that GCID.

As an example, when a quad recording is in progress on GCID1, when the SipRecStatus is queried using EMA, the EMA would query based on keys for each of the recording, say
Recording1: {GCID#1, Ingress-leg, IP1}
Recording2: {GCID#1, Ingress-leg, IP2}
Recording3: {GCID#1, Egress-leg, IP3}
Recording4: {GCID#1, Egress-leg, IP4}.
For all of the above keys, the application would display the data corresponding to the first recording.

Steps to Replicate: 

  1. Set up the SBC with SIPREC Quad Recording for a single main call.
  2. Check the status of the recordings on EMA.

The code is modified to receive all the keys of the SIPREC status and display the correct information.

Workaround: Check the status on the CLI without specifying all set of keys for the SIPREC status,

SBX-104705 | SBX-1051072

Portfix SBX-104705: There was a memory leak on the glusterfsd.

Impact: During a soak test on OAM, it was observed that the third party software glusterfsd process was leaking memory. If this occurred over a long duration, the OAM could run out of memory and a core would occur to that process.

Root Cause: The memory leak is observed for the glusterfsd process, which is the brick process. The use of the "gluster volume heal info" function causes the process memory usage to increase and not go down afterward.

Steps to Replicate: 

  1. Ensure both Active and Standby OAM are running.
  2. Monitor glusterfsd memory usage on both nodes.

Use the "gluster volume heal statistics heal-count" command to determine the gluster bricks heal state.

Workaround: Reboot OAM node OR Execute: gluster volume stop gvol1; gluster volume start gvol1.

SBX-737 | SBX-1054132

Portfix SBX-737: The support for the 3072 bit long RSA keys is missing.

Impact: The SBC needs to support the 3072-bit RSA keys in certificates.

Root Cause: A feature change was required to support the 3072-bit RSA keys in certificates in addition to the 2048-bit and 4096-bit RSA keys.

Steps to Replicate: 

  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 a 3072-bit RSA key.
  3. Configure local certificates with a 3072-bit RSA key.
  4. Test a 3072-bit RSA key certificate on the SBC acting as SIP-TLS server.

The code is modified for the 3072-bit RSA keys in certificates.

Workaround: None. 

SBX-1053632

Unable to access any log with the Platform Manager and EMA.

Impact: Unable to access log with the EMA and PM.

Root Cause: The jquery.ui.datepicker was not removed as this is updated in the jquery-ui.min file.

Steps to Replicate: 

  1. Logged into the PM.
  2. Go to Troubleshooting => Call trace/Logs/Monitors => Log Management
  3. Select any categories to see logs.
  4. Should be able to access logs.

Remove the jquery.ui.datepicker from the html file to address the issue.

Workaround: None.

SBX-102364 | SBX-1054562

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: N/A

PSX-35183 | SBX-1046602

Portfix PSX-35183: Setting the PSP with transcode conditional and then change it back to the TFT, all the settings from ‘conditionsInAdditionToNoCommonCodec’ are not reset back to the default values and in some cases affect call processing.

Impact: When the transcoder free transparency (TFT) is enabled and some of the ‘conditionsInAdditionToNoCommonCodec" flags are enabled too, the call processing may be different than when only TFT is enabled.

Root Cause: In the original design, flags of "Conditions In Addition To No Common" are
only displayed and configurable when PacketToPacketControl's transcode is Conditional. When a PSP's transcode is changed to other values from Conditional, all flags values would be preserved.

Steps to Replicate: 

  1. Create a PSP, set transcode to Conditional.
  2. Configure flags of "Conditions In Addition To No Common", making some enable and some disable.
  3. Switch the transcode to "Transcoder Free Transparency".
  4. Switch the transcode back to Conditional.
  5. Check flags of "Conditions In Addition To No Common". They should be all disable.

The code is modified to set all flags of "Conditions In Addition To No Common" to disable whenever the PacketToPacketControl's transcode is set to "Transcoder Free Transparency".

Workaround: Before changing the transcode to "Transcoder Free Transparency".

  1. Set the transcode to Conditional.
  2. Set all flags of "Conditions In Addition To No Common" to disable.
  3. Set the transcode to "Transcoder Free Transparency".
SBX-104990 | SBX-1054652

Portfix SBX-104990: In a secure call, the SBC does not increment port number in R-URI after processing Refer.

Impact: In a secure call with TLS configured, if the call is REFERed with a REFER-TO header containing a FQDN and port number, the SBC sends out new invite to the specified FQDN and port number. If that INVITE fails and the SBC then sends a subsequent INVITE on the next route it does not correctly increment the RURI port number for TLS.

Root Cause: The SBC code does not take into account that a re-route after a REFER-TO with FQDN and port number target needs to increment the port number for TLS, if the target after the re-route is different to the original target specified in the REFER-TO.

Steps to Replicate: 

  1. With the recommended SBC configuration for MS Teams with TLS enabled between the SBC and MS Teams. Establish a call from PSTN to MS Teams.
  2. Send a REFER from MS Teams witch includes following header -
    REFER-TO: <sip:sip2.pstnhub.microsoft.com:5061;transport=tls>
  3. Based on the REFER, the SBC should route the call and send INVITE to sip2.pstnhub.microsoft.com using port 5061.
  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 5061.
  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 doing a re-route to a target FQDN and port number that is different to the original target specified in the REFER-TO.

Workaround: None.

SBX-1053192

The SBC is not able to parse MSRP media packet 200.

Impact: When the SBC received "200" as MSRP response, it did not forward the same to other end as it considers 200 as a invalid response in absence of "OK" string in 200.

Root Cause: The SBC was strictly parsing "200 OK" for MSRP success response due to that if it is received "200" as response, it did not forward the same to other end.

Steps to Replicate: 

Test 1:

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

Test 2:

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

The code is modified to consider 200 as valid MSRP response.

Workaround: There is no workaround at the SBC for this issue, UAC/UAS need to send MSRP response as "MSRP <transaction-id> 200 OK" to avoid this issue.

SBX-100122 | SBX-1049723

Portfix SBX-100122: There were various display issues related to media port range modifications.

Impact: Issue 1,2,3: The CLI display of mediaPortRangeUnassigned to TGs was not regulated by the system media port range setting, causing the mediaPortRangeUnassigned CLI command displaying the wrong ports.

Issue 4: If the basePorts for different TGs are the same in a same zone, their maxPorts will be added up in CLI display of mediaPortRangeAssigned. tcpPortRangeAssigned has the same problem.

Root Cause: Issue 1,2,3: The root cause was that the SBC had not considered the system media port range setting as restriction when calculating unassigned ports.

Issue 4: The root cause was that assigned media port range map had not been indexed by TG, but by basePort had been a mistake.

Steps to Replicate: While working on the SBC CLI

  1. Show configuration details system media mediaPortRange
  2. Show table addressContext addressContextName ipInterfaceGroup IG_name mediaPortRangeUnassigned
  3. Modify configuration details system media mediaPortRange to much smaller range.
  4. Repeat step 2, to make sure that mediaPortRangeUnassigned gives ports always within the range of "show configuration details system media mediaPortRange"
  5. Create multiple TGs in each zone. Assign mediaPortRanges to these TGs. Some range with the same basePort in the same zone. Some with different basePorts in the same zone.
  6. Repeat step 2 to make sure that mediaPortRangeUnassigned gives ports always within the range of "show configuration details system media mediaPortRange"
  7. Show table addressContext addressContextName ipInterfaceGroup IG_name mediaPortRangeByTGNameAssigned / mediaPortRangeUnassigned. Ensure that the outputs are correct.
  8. Repeat steps 2-7 with tcpPortRangeByTGNameAssigned / tcpPortRangeUnassigned
  9. Repeat the display steps above in EMA.

The code is modified for the following issues:

  1. Added system wide media port range into SBC SIPSG cache, so that the restriction will be checked before display of mediaPortRangeUnassigned.
  2. Changed the map of the assigned mediaPortRange to indexed by TG name, not basePort any more.
    Therefore, the CLI/EMA syntax becomes mediaPortRangeByTGNameAssigned/ tcpPortRangeByTGNameAssigned, instead of mediaPortRangeAssigned / tcpPortRangeAssigned.

WorkaroundIt is a display issue, does not impact call.

SBX-911112

There was a No Way Video after A/V calls is resumed after hold.

Impact: There was a No way video after a audio video call is resumed using a late media re-INVITE.

Root Cause: The SBC does not send "sendrecv" in 200 OK for late media re-INVITE, and instead sends the same datapath mode that was negotiated last, which could be inactive.

Steps to Replicate: Set up a audio and video call. Put the call on hold by sending a=inactive in audio and video SDP. Then send a late media re-INVITE to take the audio off-hold. The SBC will send SendRecv for audio and video in 200 OK and let the remote end choose if it wants to remain on hold or come out.

The code is modified to send a sendrecv for other streams when the audio in call is being resumed aftera  hold.

Workaround: Do not use late media re-INVITE to come out of hold.

SBX-105262 | SBX-1056352

Portfix SBX-105262: The SBC is sending unexpected Re-INVITE to egress side in SRTP early media scenario.

Impact: The SBC is sending unexpected Re-INVITE to egress side in SRTP early media scenario.

Root Cause: This issue is caused because of a side-effect of SBX-103807.

Steps to Replicate: Call flow:

  1. UAC sends Invite with 100 rel required.
  2. UAS sends 18x with SDP+SRTP (SHA-1-32).
  3. Ingress sends PRACK with SDP+SRTP (SHA-1-32).

Copy the active security PSP only if audio stream is present to address the issue.

Workaround: None.

SBX-105114 | SBX-1057012

Portfix SBX-105114: Usage of the kill command output in active and standby CE_node logs.

Impact: The kill command usage gets printed in the CE_Node log file of the managed nodes.

Root Cause: No glusterfs process is present when the kill command is executed by the glusterSetup.sh script called by sbxConfigUpdater.sh.

Steps to Replicate: 

  1. Reboot the Standby OAM.
  2. Ensure that kill usage does not appear in the CE_Node log file of the managed nodes.

Redirect kill command error output to /dev/null to address the issue.

Workaround: None.

SBX-104360 | SBX-1055622

Portfix SBX-104360: The SWITCHOVER ACT Records are not generated in the SBC with the HA mode set as Nto1.

Impact: On an N to 1 system, the SWITCHOVER record is not written to the accounting file on the new active node after a switchover.

Root Cause: The SWITCHOVER record is sent to the ENM process before it has opened the accounting file, so the record is not written.

Steps to Replicate: 

  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-86090 | SBX-1042362

Portfix SBX-104236: Our SIPREC implementation is prone to failure to record a stream and to tear down the SRS call leg when SRS (SIP Recording Server) sends a re-INVITE to SBC.

Impact: SIPREC handling had race conditions issues in the scenario where a RE-INVITE was received on the main call and also RE-INVITE was received from SRS server at the same time.

This resulted in recording failure and the SBC sent out BYE towards SRS.

Root Cause: This race condition of RE-INIVITE from the main call end point and SRS server simultaneously was not handled on the SBC.

Steps to Replicate: 

  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 the 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 is sent once the RE-INVITE transaction received from the SRS was completed.

Workaround: The SRS can avoid sending an immediate hold RE-INVITE if no media is observed on SIPRec leg.

SBX-1043252

There was a SCM coredump observed when multiple gateway TGs are created in a GW-GW call on a HA set up.

Impact: On a HA set up, the Standby box SCM Process dumps core when the Standby starts to sync from Active, post a switch over, and the switch over occurs after a scenario where the Gateway TG's are created and then a GW TG with a lower index (Created earlier) is deleted.

Example:

  1. Create GWTG1, GWTG2 and GWTG3.
  2. Delete the GWTG2
  3. Run a switch over.

Root Cause: The coredump is caused due to difference in indexing of gateway TG's in active and standby boxes.

The GW TG indexes were out of sync between the Active and Standby.

The Active SBC had holes in the indices of the GW TGs after deletion.

The standby SBC does not have holes for the GW TGs that are present post deletion and occupy different index when compared to active.

Steps to Replicate: 

  1. HA set up 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-1049752

The MCF sent back to ingress as the MPS.

Impact: Some fax T.38 endpoints send entire DCS V.21 signal in one packet as opposed to 1 octet per packet. This can causes fax failures.

Root Cause: A burst of octets in a single packet is essentially a burst, and causes potential problems as these packets get queued for modulation and cause delay and later TCF (high speed) signal some packets get dropped.

Steps to Replicate: This issue was reproduced with a T.38 capture from field that contains a DCS followed by a TCF and a page.

Without a fix, the high speed modulated page signals starts and then, there is a gap and it restarts. (Picture is loaded in broken_page.png).

After the fix, the high speed modulated page signal is correct, it does not show het gap and restart behavior for 7.2.

The code is modified to accommodate larger bursts.

Workaround: This bug is a specific interoperability problem with endpoints that exhibit burst single packet DCS signals. For such endpoints, we do not have a workaround, unless there is some configurations are available on those devices to modify this behavior.

SBX-1057362

Sending m=application 0 UDP/BFCP (null) in case of UPDATE.

Impact: The SBC sends m=application line in incorrect format in SIP UPDATE message.

Root Cause: The SBC does not format the m=application line for UDP/BFCP when sending UPDATE message.

Steps to Replicate: Test case 1: Reproduce the issue:

The SBC sends an INVITE with SDP(with audio and video lines and m=application) and receives rel 18x with SDP (with audio and video lines only) followed by the final 200OK with SDP (with audio and video lines and m=application) if flag is enabled then SDP of 200OK should be ignored by the SBC.

UPDATE message content:

m=application 0 UDP/BFCP (null)

Test case 2: Verify the issue the same scenario as test case 1.

UPDATE message content:

m=application 0 UDP/BFCP *

The code is modified to ensure the SBC sends the m=application line in correct format.

Workaround: None.

SBX-1056102

There were coverity issues in OAMNODE.

Impact: When processing a show list command under the node branch from the OAM node, if the target node fails to read the command path in the request, the code will access memory immediately after freeing it. While in most cases this should not cause issues, accessing memory after it is freed is not good behavior and could result in unexpected behavior and potentially in the worst case coredumps.

Root Cause: Error handling flow in the code is incorrect. It hits some code for the success flow.

Steps to Replicate: Run coverity tests to reproduce the issue.

The code is modified to address the issue.

Workaround: None.

SBX-105361 | SBX-1058813

Portfix SBX-105361: The SSH access was not re-enabled on SBC 5400 for the linuxadmin after an upgrade.

Impact: The SSH is enabled for root user in SBC5400 after LSWU or PM upgrade.

Root Cause: The getVirtualType function in sonusUtils.sh incorrectly set the virtual type on the SBC5400.

Steps to Replicate: Enable the SSH and run the LSWU, the SSH should not enable for root user.

Validate the previous virtual type in getVirtualType function to address the issue.

Workaround: None.

SBX-105270 | SBX-1056082

Portfix SBX-105270: There was a cpxAppProc leak for a MRFP call.

Impact: There was a small memory leak occurs on SBC/MRFP nodes when action/status/stats under the node branch is accessed through the OAM node CLI or EMS.

Root Cause: Resource references are cleared mistakenly after serving the request from the OAM node.

Steps to Replicate: Execute a node branch command repeatedly and monitor the CPX process size on the target node.

Resource references are cleared only when the system is shutting down to address the issue..

Workaround: Avoid using node branch commands in automated/periodic operations. Manual use should be ok as the leak is small.

SBX-102700 | SBX-1060672

Portfix SBX-102700: Number mapping (translated, RDI, To hdr, R-URI) is odd.

Impact: The SBC is not adding translated number received from PSX to RequestURI when Diversion header is present in the ingress Invite.

Root Cause: If ingress Invite does not contain Diversion header, then SBC is adding translated number to RURI. So same result is expected when diversion header is present.

Steps to Replicate: 

  1. Make an SIP call by sending an Invite with Diversion header from UAC.
  2. Configure the PSX to return "translated number" for the called party number in policy response. The SBC includes the translated number in Request URI and routes the call.

The code is modified to populate the RequestURI with the translated number even when the Diversion header is present in the initial Invite.

Workaround: None.

SBX-103222

2

The SBC is not sending an INVITE to the MRF for a modified transcode call.

Impact: Run a MRF call flow by configuring the MRF profile.

Root Cause: The MRF Profile values are not correctly read by the application.

Steps to Replicate: 1. Configure the System for doing the MRF call flows.
2. Try the MRF call flow, the MRF must be invoked.

The code is modified to read the values from a proper MRF path.

Workaround: The sbxrestart should solve the issue.

SBX-106004 | SBX-1062402

Portfix SBX-106004: The EMA display error when SMM deleted through the CLI.

Impact: The EMA display error when SMM deleted through the CLI.

Root Cause: In the EMA, we are checking the ordering of the rules. If the Order is not continous then we are throwing the error.

Steps to Replicate: 

  1. Log in to the EMA
  2. Navigate to Profiles > Signaling > SIP Adaptor Profile.
  3. Select one SMM rule and try to edit it.
  4. There we do not found the error if the rules are not continuous.

The code is modified to address the issue.

Workaround: None.

SBX-1047593

The IPv4 Path MTU Discovery (RFC1191) not working for the UDP.

Impact: The SBC uses the MTU of the outgoing network interface as the Path MTU when sending out SIP-UDP packets.

Without the fix, the SBC does not update Path MTU properly even if a router in the path sends "ICMP Destination Unreachable Fragmentation Needed" message with smaller Path MTU value. The large packets requiring fragmentation to fit the Path MTU from the SBC will not reach the SIP peer.

Root Cause: While handling "ICMP Destination Unreachable Fragmentation Needed" error message for UDP packet, route/fib lookup did not consider ipInterfaceGroup and addressContext. This resulted in not updating Path MTU of the proper route entry to the peer for sending SIP-UDP packets.

Steps to Replicate: The SBC sends SIP-UDP packets of length 1500 bytes toward the SIP peer when a path to the peer has a smaller MTU. A router with the smaller MTU sends "ICMP Destination Unreachable Fragmentation Needed" to the SBC.

Without the fix, the SBC keeps on sending SIP-UDP packets, and the router keeps on sending "ICMP Destination Unreachable Fragmentation Needed" to the SBC.

The SBC, with the fix, adjusts the Path MTU, performs the fragmentation on SIP-UDP packet and sends fragments to the SIP peer.

The code is modified to add ipInterfaceGroup and addressContext information in handling ICMP Destination Unreachable Fragmentation Needed message in the Linux kernel.

WorkaroundDisable Path MTU Discovery by setting ipNoPmutDisc value to.

admin@SBCSWE03% set system admin sbcswe03 kernelParams ipNoPmtuDisc 2
admin@SBCSWE03% commit

Note: The support for ipNoPmutDisc was added to 7.2.5R000, 8.2.4R000, and 9.2.0R001.

SBX-103986 | SBX-1044422

Portfix SBX-103986: There was an incorrect RTP time stamp in the SBC packet capture.

Impact: After an SBC upgrade, RTP/RTCP time stamp in the SBC packet capture shows the year 2036.

Root Cause: Present logic was not considering the edge cases while checking the last modification time of the NTP log.

Steps to Replicate: 

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

AddressSanitizer error: heap-use-after-free on the address 0x6190000ba218 at pc 0x56473eecd69f bp 0x7f27682167e0 sp 0x7f27682167d8

Impact: The heap use after free error while running the PC2 ingress leg interception on OPTIONS/200OK call SBC_8.2x ASAN Build.

Root Cause: For the 4C, is using memory that is free by previous code. For the 6, the leak due to a missing null check.

Steps to Replicate: 

  1. Create a ASAN Build.
  2. Set up a PC2 and run a call.

The code is modified in the following manner:

  • Added a calling function before freeing the memory.
  • Added a NULL check.

Workaround: None.

SBX-1061492

The PSP qos value msrpDscp non-zero causes a PES process crash.

Impact: The PES process crashes when the apps are starting up and if msrpDscp in the PSP QoS values are configured with non-zero.

Root Cause: A debug statement tried to print a integer as a string, causing memory problem.

Steps to Replicate: 

  1. Configure a 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: None.

SBX-1022772

The debug command caused the SCM process to core dump.

Impact: We are hitting a Healthcheck timeout when displaying the output of the following debug command:
"request sbx sipsg debug command "svcgrp -ce 0 -scm <x> -1""

Root Cause: The Heathcheck timeout error occurs due to taking too long to display the data for all of the service groups when there are very large number of trunk groups configured.

Steps to Replicate: 

  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-102478 | SBX-1033852

Portfix SBX-102478: An Automated Upgrade failure for the SLB/SBC from 9.0 to 9.1.

Impact: The newly upgraded OAM VM did not properly boot. On the investigation, it was seen that the Cluster IP was not set correctly, even though an upgrade was received from VNFM, which contained the correct Cluster IP.

Root Cause: The updated userData.json received from VNFM was overwritten with the initial boot userData.json (that did not contain the Cluster IP), even though there is code in convertVnfm.py specifically to prevent that from happening. On investigation, it was seen that a bad propagation of fixes from other releases into main introduced an indentation problem. Indentation is significant in python, and the bad indentation made the code that checked for an updated userData.json fail to work properly.

Steps to Replicate: Use different types of auto-upgrades should be tested, because they seem to expose the problem with non-updated userData.json more easily than a normal orchestration.

The code is modified so the correct indentation is restored.

Workaround: If the orchestration is failing without this fix, a restart of the VM should be manually triggered to have it re-run the code in question. This needs to be done before VNFM fails the upgrade (1 hour).

SBX-1037203

There is packet verification improvements for T.38 stack.

Impact: In some of the crashes from the field (e.g. SBX-101155), we have observed a frame in jitter buffer that has unreasonably large fld_cnt as compared to the size of the packet itself. This is a malformed packet and such packets may lead to crashes.

Root Cause: These malformed packets are the root cause.

Steps to Replicate: TBD

The code is modified to look for UDPTL packet size and frame size inconsistencies and to allow packets with inordinate field count to be accepted by the stack. This logic is improved to reject such packets.

Workaround: None.

SBX-1037712

Special characters in the DN hinders the EMA display.

Impact: Special characters in DN are throwing error in the EMA.

Root Cause: Special characters were not supported for the DN through the EMA UI.

Steps to Replicate: 

  1. Create Route with a special character in DN.
  2. Save/Edit/Delete the Route.

The code is modified to address the issue.

Workaround: None.

SBX-1065092

Restoring the backup SMM configuration is failing.

Impact: Restoring the backup configuration was failing.

Root Cause: This issue is caused because the loadConfig was failing because of errors in HwModuleServer.cpp file.

Steps to Replicate: Run a load configuration from the CLI, and configure the load properly.

The code is modified to address the issue.

Workaround: None.

SBX-1053403

The reenableOsAccount silently sets the account expiration to 30 days.

Impact: Using the reeanbleOsAccount will add account aging to any OS account.

Root Cause: The logic does not take into account state of OS account aging or if OS account aging should be applied (e.g. root).

Steps to Replicate: 

With the OS account aging enabled:

1. Test the root:
i. Set the reeanbleOsAccount for user root.
ii. Check there is no aging is applied at OS level: chage -l root.

2. Test the Confd user:
i. Create user through CLI.
ii. Set the reeanbleOsAccount for this CLI user.
iii. Check there is no aging is applied at OS level: chage -l <CLIUser>.

3. Test the OS user with a password:
i. Create the OS user with a password.
ii. Disable and then Enable OS account aging state.
iii. Set the reeanbleOsAccount for this OS user.
iv. Check the correct aging is applied at OS level: chage -l <OSUser>.

The code is modified to check in the OS account aging is enabled and is applied.

Workaround: None.

SBX-1062562

The Control Display of Table Columns is not working for the DiamNode EMA page.

Impact: The Control Display of Table Columns is not working for the DiamNode EMA page.

The options selected by the user were not retained and maintained properly when the user navigates to some other page

Root Cause: Missing Null Checks on a userName parameter while updating the columns in DiamNode Page.

Steps to Replicate: 

  1. Successfully verify the loading of the EMA Application.
  2. Successfully verify the rendering of the DiamNode Page.
  3. Successfully verify that the columns are displayed according to the show/hide logic set in the page.

The code is modified to ensure that exceptions are handled appropriately.

Workaround: None.

SBX-1031352

The SBC was sending an INVITE with incorrect b= line values.

Impact: The SBC sends the wrong RR and RS values in the outgoing INVITE for a transcoded call.

Root Cause: On the D-SBC, the NrmaComputeOfferPspForAnswerLeg() gets executed twice when intersecting. Once with ingress route PSP and once with egress Route PSP and even though we pass the right route PSP to the function, the rtpOptions passed to the function is wrong that results in the wrong computation of RR and RS values.

Steps to Replicate: The SBC is configured to make a SIP-SIP call procedure:

1. Configuration: Egress PSP: AMR (WB) Bandwidth efficient. Ingress PSP: AMR (WB) Bandwidth efficient.
2. RTCP is enabled only on egress PSP and RR/RS bandwidth is configured as 500.
3. Flag 'Send RR/RS in SDP' is enabled in IP signaling profile for Egress.
4. Initiate a SIP-SIP Audio call with the Audio codec as AMR WB without RTCP bandwidth related parameters (RR/RS not present in SDP).
5. Observe the SBC sending wrong RR and RS values in outgoing INVITE.

The code is modified to pass the correct rtpOptions for computing the RR and RS values.

Workaround: None.

SBX-1052562

The SBC was sending AMR-WB twice and the SBC was accepting codec in answer that is not present in offer

Impact: In a Late Media Call with HD Codecs configured in the Route PSP, the SBC was sending 2 HD codecs in its offer towards the Egress even when the "preventSameCodec" configuration flag is enabled in Trunk Group.

Root Cause: The SIPSG module was not passing the "preventSameCodecTransCode" flag to NRMA for Late Media calls.

Steps to Replicate: The steps cannot be replicated.

The code is modified to now pass the "preventSameCodecTransCode" flag for late media calls. For normal media calls, this is working in 8.2.3 releases

Workaround: None.

SBX-100320 | SBX-1052382

Portfix SBX-100320: There were SBC 9.1 coverity issues.

Impact: In several modules, coverity pointed illegal access of NULL pointer, that may cause a crash in code.

Root Cause: Illegal use of pointers, without checking whether they are NULL or not.

Steps to Replicate: After running the coverity, the illegal access of pointers were not encountered again.

The code is modified to correctly check the pointer, whether it is NULL or not. If it is NULL, then no further processing of that pointer is done

Workaround: None.

SBX-980152

LSWU. Call/Registration Data syncInProgress.

Impact: Issue#1: Upgrade failures with EDNS Feature

The LSWU Upgrade from the SBC from pre 8.2 release to a 8.2 or higher release fails when EDNS servers are configured.

When the ednsServer statistics table has non-zero values for the field “ednsFailures”, the SBC synchronizes the stats structure. Since the corresponding structure does not have serialization support, the sync is aborted and the upgrade fails. The ednsFailures stats are updated when the SBC encounters RCODE 1, 2 and 4 errors for EDNS qeueries.

Example pre-8.2 configuration causing this issue:

admin@PLUM> show status addressContext default dnsGroup DnsGrp
dnsServerStatistics 2
{ ipAddress 10.xx.xx.xx; queries 5; timeouts 0; errors 2; referrals 0; totalTcpConnection 0; tcpConnectionFailed 0; tcpConnectionSuccess 0; tcpConnectiontorndown 0; tcpFallback 0; ednsStatus supported; ednsFailures 1; }
[ok][2020-11-06 04:07:27]

Issue#2
The EDNS Server stats is lost during an upgrade from 8.2/9.0/9.1 to 9.2 because of an incorrect serialization code.

Root Cause: Issue#1: Upgrade failures with the EDNS Feature

There are multiple issues in serialization support for DNSC_REDUND_MIRROR_EDNS_SERVER_STAT_INFO_CMD_MSG_STR

  1. The DNSC was not registered for Serialization till 8.2. The DNSC was registered for serialization support in 8.2.0R0 with the feature SBX-75865.
  2. The postUnpack methods for the structures had wrongly updated the length of the message. This was also fixed in 8.2.0R0 with the feature SBX-75865.

Issue#2: The EDNS Status was lost
The wrong datatype was used for serializing DNSC_REDUND_EDNS_SERVER_STAT_DATA, i.e. VariableSizeOfVariableDataArrayOperations instead of VariableSizeArrayOperations.

Steps to Replicate: Procedure:

  1. Configure a SBC HA pair for basic call with 8.2 version.
  2. Configure the DNS Server with eDNS Monitor enabled and a FQDN IP Peer.
    set addressContext default dnsGroup DnsGrp ednsSupport enabled
  3. Make a call for same FQDN and send RCODE error(1,2 or 4) from DNS server.
  4. Check the DNS statistics.
    show status addressContext default dnsGroup DnsGrp dnsServerStatistics
  5. Upgrade the Standby box followed by active box with post 8.2 SBC version.
  6. Upgrade should be successful and DNS statistics should be proper.

The code is modified to handle the LSWU Upgrade of SBC from pre 8.2 release to a 8.2 higher release.

WorkaroundIssue#1: Upgrade failures with the EDNS Feature

Before upgrading a box that is older than 8.2R0, the following commands on all the DNS Groups needs to be issued before we upgrade.

Note: The ednsServer stats is lost as a consequence during the upgrade.

  1. Issue a 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
    set addressContext default dnsGroup DnsGrp ednsSupport disabled

Issue#2: The EDNS Stats was lost.

No workaround. 

SBX-1045332

The high CPU Utilization was observed on GPU UXPADs with 1152 chans/process.

Impact: The transcoded calls using FMTD (Fax and modem tone detection) require most CPU cycles than expected. As a result, in a loaded system higher than expected CPU utilization is observed.

Root Cause: Root cause for this is that the FMTD module code was checked in with a debug compiler flag. The debug flag results in code is less optimal and consumes higher number of CPU cycles.

Steps to Replicate: This requires a use of high load to observe the problem. Typical with GPU use, the expected numbers are about 18432 G729A-G711U calls with a max UXPAD utilization to be 80-81%. Due to this bug, 90% CPU utilization is observed with about 13k calls. As a result, the test steps are:

  1. Run a high load of transcoded calls with fix and observe CPU utilization.
  2. Run a high load of transcoded calls without fix and observe CPU utilization.

With a fix, the utilization should be same as that for 8.1.0R6 as a comparison.

The code is modified to make a file for the FMTD module to remove the debug flag and then rebuild the optimized library.

Workaround: None.

SBX-1048273

The SBC was terminating the call when a 491 response is received for the self generated Re-INV.

Impact: The SBC is terminating the call when a 491 response is received from a Peer for the self generated Re-INV.

Root Cause: When a 491 response is received from the peer for the self generated Re-INV, the SBC is treating this as an error response and as a result, generates a internal clear event and the call is getting terminated.

Steps to Replicate: IPSP flag configuration:

DML flag disabled.
relayStatus4xx6xx flag enabled.
Create a transparency profile and attach it to the egress TG.

  1. Make a call from user A to user B with offer containing multiple codec towards user B.
  2. Let user B answer with multiple codecs, such that, the SBC triggers a media lock down Re-INV.
  3. Let user B send 491 Request Pending.

The code is modified so that the call will not get terminated.

Workaround: None.

SBX-1009123

The search filter tab for Routing page in EMA is not working properly in 8.2.1R1.

Impact: When user try to perform search for # % & _ in filter tab of EMA route page, results were not fetched as expected.

Root Cause: The search values are not encoded before making a request to get results.

Steps to Replicate: 

  1. Navigate to the Route screen in the EMA.
  2. Entered values with special character to perform a search.
  3. Received the result as expected.

Encoding the values before making the request to get exact results addresses the issue.

Workaround: None.

Resolved Issues in 08.02.03R000 Release 

Severity 1 Resolved Issues

The following Severity 1 issues are resolved in this release:

Resolved Issues


Issue IDSevProblem DescriptionResolution
1SBX-101131 / SBX-1010571

Portfix SBX-101057 (Originated in Release 7.2.5): The iceSupport and SMM iptgStore coredumped.

Impact: The iceSupport and SMM iptgStore configuration, and an invalid incoming call may caused the SBC to core.

Root Cause: After a response failure to the invalid call, the SBC still tries to initiate set up call. As a result, it accesses the invalid address.

Steps to Replicate: Configure the iceSupport and SMM storeIPTG, incoming call with invalid candidate (no UDP).

The code is modified to not try to initiate set up call if the call fails.

Workaround: Use the SMM to drop an incoming call.

2SBX-1000881

There was a switchover after the TLS certificates were renewed.

Impact: When certificate is modified, an old certificate is freed and new certificate is updated. But after freeing the old certificate, the pointer is not set to NULL that can cause undefined behavior due to an invalid access.

Root Cause: The issue is when the customer modified the certificates through the CLI, it resulted in the SAM process to core. This is due to memory corruption.

Steps to Replicate: Changing the TLS certificates when the TLS load is running will result in memory corruption and the core can occur any time if there is active TLS load running and if the existing TLS calls try to access the certificates that were deleted already.

Set the pointer to NULL so that there is not invalid access to the pointer.

Workaround: N/A

3SBX-1010501

The SBC SWe was not generating a switch over trap-sonusCpRedundGroupSwitchOverNotification.

Impact: A switchover notification trap may not be generated.

Root Cause: The event, used to generate the trap, is incorrectly dropped due to the logic that thinks the event is stale.

Steps to Replicate: Perform switchover and ensure the trap is properly generated.

The code is modified to improve the event handling so that the necessary events process and do not mistakenly drop.

Workaround: The problem only occurs during slow processing. Avoid anything that can slow processing down like info level logging, or any external influences on the disk.

4SBX-981771

There was an issue with the SBC 7000 TCP window size. 

Impact: Add the CLI support to set kernel parameter net.ipv4.tcp_window_scaling

Root Cause: In certain SBC deployment scenarios (a large number of devices running SIP-TLS), tcp_window_scaling caused small TCP window size.

In such cases, the customer had to use Linux command to disable tcp_window_scaling on each SBC node.

Steps to Replicate: 

(1). Show initial setting for tcp_window_scaling on both active (SBCSWE01a) and standby (SBCSWE01b)
[root@SBCSWE01a ~]# cat /proc/sys/net/ipv4/tcp_window_scaling
1
[root@SBCSWE01b ~]# cat /proc/sys/net/ipv4/tcp_window_scaling
1
[root@SBCSWE01b ~]#

(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@SBCSWE01a ~]#

[root@SBCSWE01b ~]# cat /proc/sys/net/ipv4/tcp_window_scaling
0
[root@SBCSWE01b ~]#

The code is modified to fix the issue and the Linux command is no longer needed with the modified code.

WorkaroundUse the 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 the SBC restart and system reboot, use the 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

5SBX-977911

There was a switchover with the PRS process coredumping.

Impact: The PRS process coredumped due to memory corruption.

Root Cause: Customer encountered a PRS process core due to the memory corruption that happened earlier in processing. The core is the after effect of earlier corruption.

Steps to Replicate: None.

The code is modified to avoid the core, and to collect more diagnostic data if a core happens again.

Workaround: N/A

6SBX-101119 / SBX-1007791

Portfix SBX-100779 (Originated in Release 7.2.5): The SBC was adding an extra application/ISUP ACM content.

Impact: The 200 OK Bye has duplicated the ISUP body.

Root Cause: When the e2e Bye is enabled, 200 OK has duplicated the ISUP body.

Steps to Replicate:

  1. Configure the isupMimeBodyRelay and e2e bye.
  2. Run a sipi-sipi call, and the SBC sends 200 OK bye has duplicated isup body.

The code is modified so the SBC does not create an isup body internally for the e2e Bye and isupMimeBodyRelay.

Workaround: Disable the e2e Bye.

7SBX-1001641

There was a back-to-back coredump on the Server.

Impact: The SCM process cored due to memory corruption while parsing an INVITE with a very long and invalid CallId field, while the parseError trace logging was enabled.

Root Cause: The SCM process coredump is caused by memory corruption that is the result of the Trace Logging code overwriting a buffer.

This can happen when the SIP parser encounters an invalid CallId that is also very long.
It is also possible that other parsing errors can trigger this core, especially if the parse error was encountered for a particular header that is very long.

Steps to Replicate: This can be reproduced by enabling the parseError trace logging and then sending a INVITE that includes a badly formatted CallId, which is the maximum allowed size for a CallId:
"set global callTrace errorFilter errorType parseError"

The code is modified to not overwrite the end of the buffer when it is attempting to write a very long error message string.

Workaround: Disable the parseError tracing.

8SBX-998501

A BYE message was sent to the wrong port.

Impact: The SBC does not update remote connection address when refresh INVITE is received from different port.

Root Cause: When the endpoint is registered over TLS initiating a call and after the call is established, the endpoint sends a refresh register from a modified port. When a refresh INVITE is sent with no SDP change, the SBC does not send BYE to a modified port when the call disconnects.

Steps to Replicate: 

  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 that the SBC sends BYE to modified port towards caller.

The code is modified to ensure the SBC updates the remote address when refresh INVITE is received from modified port. This ensures when the registration is required and for a TLS connection, after the call is released BYE is sent to correct port.

Workaround: N/A

9SBX-1002231

The SMM for changing ISUP message inside SIP-I does not work properly.

Impact: When a message is received with mime content having single msgbody, then after the SMM application on the msg body, the SBC re-formats it as a normal msgbody instead on the mime content. The re-formating was not handled properly.

Root Cause: When a message is received with mime content having single msgbody, then after the SMM application on the msg body, the SBC re-formats it as normal msgbody instead on mime content. 

Steps to Replicate: 

  1. Add the SMM rules that applies on the message body.
  2. Send message with mime content having single msgbody in it.

The code is modified so that whenever the SBC re-formats the mime body after the SMM application it formats correctly.

Workaround: N/A

10SBX-101693 / SBX-1012941

Portfix SBX-101294 (Originated in Release 7.2.5): Intermittently, the SBC SWe accesses the sipSigPort for sending the SIP messages to the core side.

Impact: The relay options with registration may route to the wrong Sip Signaling Port and causing call fails from AS to IAD.

Root Cause: When the IAD sends a registration from SSP1 and relay options from an other SSP2. Since the options from the SSP2 do not match with RCB from SSP1, the SBC treats the options from the AS, triggering an invalid routing to the wrong destination.

Steps to Replicate: Configure the SSP1 and SSP2, and enable maskRcbPort. The registration from SSP1 succeeds. Options from the SSP2 will trigger a relay back to the IAD (not AS). Subsequent calls from AS may fail or refresh registration.

The code is modified to detect the relay messages from the IAD or AS based on RCB looks up (not just based on SSP).

Workaround: Disable the maskRCBPort. Or use the SMM to make the SBC respond to OPTIONs (not relay).

11SBX-100332 / SBX-100479 / SBX-1004801

Portfix SBX-100479/480: Observed DSP and MAJOR logs coredumps on the 7000 Platform while running the ICM Scaling suite.

Impact: The DSP and MAJOR logs coredumps on the 7000 Platform.

Root Cause: Certain variables used in the interrupt context were not protected while being modified outside the interrupt. This impacted the inter-core health-check logic at the DSP and incorrectly led to an error being reported, eventually leading to a coredump.

Steps to Replicate: From an HA Pair of fully loaded SBC-5100/5200/5110/5210/5400/7000

  1. Run a transcode load.
  2. Initiate a switchover.

The code is modified so variables are now interrupt-protected.

Workaround: N/A

12SBX-101676 / SBX-1015471

Portfix SBX-101547 (Originated in Release 8.2.2): There was a switchover and coredump after call placed on hold.

Impact: The code was dereferencing a null pointer and causing the SCM process to crash.

Root Cause: The customer had the passThruPrivacyInfo control enabled on both the ingress and egress privacy profiles. But the ingress side of the call did not pass through some expected information related to the INVITE message and it caused the code to dereference a null pointer.

Steps to Replicate: Unable to reproduce this issue, the code is fixed based on code review and coredump analysis.

The code is modified to validate the pointer is not null before trying to use it.

Workaround: Disable the passThruPrivacyInfo controls.

13SBX-1019341

The call is failing intermediately due to the Unsolicited Call Cleanup.

Impact: The call is failing intermediately due to the Unsolicited Call Cleanup

Root Cause: The affected call failed due to the XRM having received an error response from the NP for modify RID command, which was most likely the race condition in the NP. This issue occurred because the RID enable and modify commands were issued within the same seconds but from two different NP users.

Steps to Replicate: Due to the nature of race condition, it is not guaranteed to reproduce the problem.

The code is fixed based on a code review.

The code is modified to use the same NP interface user handle when sending the RID enable and modify commands to the NP for that special case.

Workaround: N/A

14SBX-100021 / SBX-995791

Portfix SBX-99579 (Originated in Release 9.0.0): Observed the Ema process core dump on the S-SBC during a sbxrestart. 

Impact: The EMA process may coredump and the application may not come up after an upgrade if the SWE/Cloud has a cinder volume attached for log storage.

Root Cause: While upgrading the SWE/Cloud platform attached with cinder volume, file ownership and permissions in the cinder volume are untouched causing wrong set of ownership on the EMA log file resulting in the EMA failing to start.

Steps to Replicate: Perform an upgrade from 7.x to 8.2.3R0 in cloud with cinder volume and check the sbxstatus and check for coredumps. With the problematic build, the EMA coredumps can be observed.

The code is modified so during an upgrade, the EMA log dir ownership is set to the sonusadmin:sonus to ensure the EMA process can access the log file and can start without issues.

Workaround: Manually change the ownership of the EMA log dir after an upgrade with below command:
chown -R sonusadmin:sonus /var/log/sonus/ema/

15SBX-102263 / SBX-1020061

Portfix SBX-102006 (Originated in Release 7.2.5): The SBC failed to send ACK to the right IP.

Impact: After a call was connected with egress received RR in 2xx, the SBC sends a reInvite, and received the rexmit of 2xx. Later on, the SBC sends ACK to the wrong destination.

Root Cause: A rexmit of 200OK, accidentally deletes the previous RR.

Steps to Replicate:

  1. A calls B.
  2. B responds with a 200OK with RR.
  3. A reInvite triggers the SBC reInvite to B.
  4. B responds with 2xx and rexmit 2xx.
  5. The SBC sends ACK to the wrong destination (based on contact not from previous RR received).

The code is modified so the SBC ignores updating the data of the dialog.

Workaround: N/A

16SBX-100023 / SBX-990201

Portfix SBX-99020 (Originated in Release 9.0.0): Observed Major logs with the error prints of 488 on the SBC 5210 platform while running direct media.

Impact: The calls stop working as LIF bandwidth is not freed.

Root Cause: In the case of a multi stream direct media call with the last media stream as non-RTP stream, the SBC does not release the session bandwidth even when the call is released. This leads to a leakage in interface bandwidth resulting in call failures after some time.

Steps to Replicate: Run direct media calls with multiple streams with the last media stream as a non-RTP stream (BFCP, MSRP).

The code is modified to release the session bandwidth even when the last media stream is non RTP stream in a direct media call.

Workaround: N/A

17SBX-101978 1

The call forking with the MS Teams and GW-GW fails.

Impact: The call forking with a GW-GW to might not work correctly.

Root Cause: The call forking logic was not copying all of the internal parameter information when grouping the routes based on each AoR tag. This meant the SRTP enabled information was lost and the call was initiated using plain RTP instead of the SRTP.

Steps to Replicate: Make a call forking call over GW-GW where one egress end point requires SRTP and the other does not. Check that the SRTP call is correctly set up.

The code is modified to correctly copy all of the route parameters between the PSX response and the forking queues.

Workaround: N/A

18SBX-102450 / SBX-958731

Portfix SBX-95873 (Originated in Release 7.2.2): The E-SBC JIAD622 crashed.

Impact: The problem occurred when the Version 3 T.38 fax is enabled. In this case, a CED 2100 Hz is sent to the SBC to G711 leg while it receives the T.38 ANSAM packets from T.38 side, the DSP hardware stack can crash.

Root Cause: The root cause has the incorrect initialization in 3rd party T.38 stack.

Steps to Replicate:

  1. The SBC should be configured for the ingress as G711 and egress G711 with T.38 for Version 3.
  2. Also configure ingress PSP as transcode only and make sure that codecs allowed for transcoding for ingress has G711 and egress has both G711 and T.38.
  3. Make a SIPP call. Before adding the fix, the DSP cores and reloads.

The code is modified to avoid crash.

Workaround: N/A

19SBX-1012841

The SBC Software Edition SWe was not sending media to the MS Teams client.

Impact: When there are more than 10 MS Teams endpoints that are potential media candidates for an outgoing ICE call to MS Teams, in some cases ice learning may not complete resulting in media path not being enabled when the call is answered.

Root Cause: For each outgoing call, the SBC has an internal nominated candidates list of up to 10 entries for storing ICE information received in stun requests from potential media candidates (which can be received before response with SDP) . On receiving SDP, stored entries are checked to see if ICE is learned for the media stream in the SDP. However, if the SDP media is from the 11th or higher endpoint to have sent a stun (which would not have been stored) that can result in ICE learning not completing.

Steps to Replicate: 

  1. Initiate a PSTN to MS Teams ICE call through the SBC.
  2. Before 200 OK with SDP from MS Teams, send ICE stun requests with use candidate from 80 different endpoints.
  3. Answer the call from the 80th endpoint to have sent a stun (so 200 Ok from MS Teams will have 80th endpoints media stream)
  4. Verify that voice media flows successfully in both directions on the call.

The code is modified to allow for up to 80 endpoints as potential media candidates.

Workaround: None if more than 10 teams potential endpoints are necessary for a call, but works fine for up to 10.

20SBX-101455 | SBX-960011

The SBC 7000 has wrong value for call duration

Impact: The call service duration (CDR field numbers 10 and 14) has the wrong values causing billing issue.

Root Cause: This issue is seen when there is mid call message in this case session refresh. Due to this session refresh, there are mid call messages(INV/200OK/ACK) happens end to end. This makes the "callServiceEstTime" in the function CcRelayInfoMsg() overwritten every time causing the CDR fields 10 and 14 to have wrong values.

Steps to Replicate:

1. Enable IPSP flag "End to End ACK" on both TGs.
2. Disable the flag "No CDR Change in End to End Ack" .
3. Make a call from A to B and let the call be connected with session refresh enabled.
4. Once the session refresh happens, disconnect the call and check the CDR.

The code is modified in the function CcRelayInfoMsg() so that the "callServiceEstTime" does not get overwritten once it is recorded initially during the initial offer-answer.

Workaround: 1. Enable the flag "No CDR Change in End to End Ack".

21SBX-1022901

The DBG file was filling up with messages "SIPCM: *ThreadPool: messageSequence".

Impact: The DBG logs can be overrun with "SIPCM: *ThreadPool: messageSequence" messages.

Root Cause: The DBG logs can be overrun with "SIPCM: *ThreadPool: messageSequence" messages, when there is a double CRLF "pings" received by the SBC over UDP transport.

Steps to Replicate: Send Double CRLF "pings" over UDP to the SBC.

The code is modified to properly dispose of Double CRLF "pings" received by the SBC over UDP.

Workaround: Inhibit the transmission (or reception) for Double CRLF "pings" over UDP.

22SBX-1020721

There was a malformed OTG after an upgrade to 7.2.4R2 on GW-GW calls.

Impact: In a SIP-GW-GW-SIP call, if the ingress SIP INVITE contains "tgrp" in the Contact header, the contents of the "otg" parameter in the egress SIP INVITE will be incorrect.

Root Cause: Design was using an incorrect pointer value when creating the OTG parameter.

Steps to Replicate: In the "Egress IP Signaling Profile", set the "Include OTG" in Originating TrunkGroup Options field.

  1. Send a SIP-GW-GW-SIP call with a Contact Header that includes a "tgrp" parameter.
  2. Look at the contents of the "otg" parameter in the "From" header in the egress INVITE. It should be garbage.
  3. Load up code with fix.
  4. Run the same call (with the same "Include OTG" configuration.

The "otg" in egress INVITE should be the originating TG on the originating GW.

The code is modified to use the correct pointer when creating the OTG parameter.

Workaround: Do not send the "tgrp" parameter in the ingress INVITE.

23SBX-102029 | SBX-102835 1

Portfix SBX-102029 (Originated in Release 8.1.0) There was an issue with Packet loss calculation on the NP.

Impact: The packet loss count for for a call is incorrect when packets are lost at the end (last 32 packets) of the call.

Root CauseThe packet loss algorithm did not include checking the last 32 packets of a call.

Steps to Replicate: Send an RTP stream that includes skips in the sequence number during the last 32 packets.

The code is modified to check if packets are lost in the last 32 packets.

Workaround: N/A

24SBX-1019491

The P-Early-Media header with sendrecv sent back to the ingress before the SDP established.

Impact: When the makeInBandToneAvailable is disabled, on a Tone And Announcement profile, the SBC sends 180 Ringing with PEM header as sendRecv even when egress 180 has no SDP. This causes ring back issues on ingress endpoints.

Root Cause: When the makeInBandToneAvailable is disabled, the SBC does not include SDP in 180 message sent to ingress but still sends PEM header as sendRecv.

Steps to Replicate: With a fix, the SBC is sending PEM header as inactive when makeInBandToneAvailable is disabled and egress 180 Ringing has no SDP.

The code is modified to ensure the SBC sends a PEM header as inactive when the makeInBandToneAvailable is disabled and egress 180 Ringing has no SDP.

Workaround: Enable makeInBandToneAvailable on Tone And Announcement Profile.

25SBX-1022361

The SBC CLI responds significantly slower while entering the ping command when one or more options are specified.

Impact: Attempting to run the SBC CLI commands ping, ping6, traceroute, traceroute6 or aaarule-display-generatecli with multiple parameters causes the CLI session to freeze.

Root Cause: Parsing of parameters on these CLI commands not correct.

Steps to Replicate: Try to run the following command from CLI:
ping -I mgt0 -c 5 1.2.3.4

The code is modified to address the issue.

Workaround: Use Linux equivalents to the commands, rather than using the SBC CLI or, if using the SBC CLI, limit the number of parameters.

26SBX-1028031

The SIP-I calls cause a platform switchover when the Map Calling party to the PAI is set.

Impact: The SBC may core when the configuration sipSigSrvcGrpURIPreference SIP on the egress but the incoming has tel and has pai (tel).

Root Cause: The SBC accesses the invalid diversion address.

Steps to Replicate: This is specific test case from customer, and cannot be reproduced.

The code is modified to validate the diversion address before access to it.

Workaround: Disable the feature sipSigSrvcGrpURIPreference.

27SBX-1021221

There was an SAM process core dump with v06.02.01 F012.

Impact: The SAM and PRS process cored in the Standby node.

Root Cause: The DRBD split brain lead to DRBD GI reset. This leads to the DRBD full sync, increasing the i/o congestion and ultimately causing a healthcheck timeout.

Steps to Replicate: To test, run "drbdadm disconnect mirror". Once getting a "standby split-brain" log in DBG logs, run "drbdadm disconnect mirror" again so that DRBD does not connect automatically and getting into the block that needs to tested. Run "drbd-overview" and check if drbd does not went for full sync.

The code is modified to perform DRBD checks after a DRBD split-brain recovery.

Workaround: N/A

28SBX-1032781

There was a double SBC SCM process coredump.

Impact: The SBC may core for an antiTromboneData feature.

Root Cause: The SBC may access null pointer in antiTromboneData feature.

Steps to Replicate: A call B, B(sdp) loop back to the SBC (Bprime). antiTromboneData is enable for B and Bprime.

NOTE The Bprime also has a replaces header to replace a call which does not exist in the SBC, causing SBC reply 481.

The code is modified to validate pointer before access and address the issue.

Workaround: N/A

29SBX-1032071

The SBC SWe 8.2.0F1 duplicates audio from call B to call A.

Impact: If CN is not negotiated for G711 codec and remote peer still sends CN packets that match default CN payload type (13), then user on other end may hear cross talk audio of completely unrelated channel or hear own reflect audio.

Root Cause: When a g711 side does not negotiate CN in signaling, DSP does not initialize Comfort Noise Generation object. However, if remote peer still sends CN packet that matches the g711 SID payload type configured in PSP (default 13), DSP accepts the packet. It processes that CN packet incorrectly and as a result uses stale voice buffer which happens to be of another channel. This continues until next voice packet for that channel arrives. Hence, we happen to see cross talk audio from other call during silence period. In some cases, the user may hear own audio also and that is different manifestation of the same problem. This issue is specific to SWe.

Steps to Replicate: 

  1. Run the CN in signaling.
  2. The DSP will not initialize Comfort Noise Generation object.
  3. Send a remote peer to the CN packet that matches the g711 SID payload type configured in PSP (default 13) and the DSP accepts the packet.
  4. Process that CN packet and as a result, uses stale voice buffer that happens to be of another channel.
  5. This continues until next voice packet for that channel arrives.

The code is modified to initialize the comfort noise object even though CN is not negotiated and process the CN packets correctly.

Workaround: There are multiple workarounds for this issue:

1. Change the default payload type of comfort noise from 13 to something else (say 15) in PSP of peer that is sending CN packets. This will make DSP drop CN packets because payload type will not match. Run the PSP configurationshow

configuration profiles media packetServiceProfile G711_NONE_NONE_NONE..silenceInsertionDescriptor {g711SidRtpPayloadType 13;heartbeat enable;}

2. Enable the silence suppression on PSP of peer that is sending CN packets and keep CN payload type that matches with CN payload type.

30SBX-1036291

The SBC was reporting REGISTER_PARSE_ERROR and replies with SIP 500 when it receives retransmitted initial REGISTER (CSEQ 1) followed by a REGISTER with Authorization header (CSEQ 1).

Impact: When the SBC recv rexmit of registration (cseq=1) after sending 401/407, the SBC relays to the AS. At the same time, the IAD sends new registration(cseq=2) for authentication. It triggers race condition to the SBC and responds with 500.

Root Cause: The SBC should relay the rexmit (cseq=1) registration to the application server.

Steps to Replicate: IAD send registration(cseq1) to AS, AS response 401 to IAD, IAD rexmit the same cseq1, and send a new cseq2 with auth header.

The code is modified to respond to the rexmit request (cseq=1) so that a subsequent one cseq=2 can handle properly relay to the AS.

Workaround: N/A

31SBX-1016521

The SIPFE lookup returned the rcb pointing to wrong SCM post-upgrade.

Impact: After an upgrade, registrations mirroring on SIPFE is corrupted. As a result, incoming traffic for the AOR may route to the wrong SCM and get rejected by the SBC.

Root Cause: The packing redundancy data structure that was sent to the standby were incorrect due to word alignment issue (using sizeof() to pack the data).

Steps to Replicate: Multiple of the same AOR registers from a different source. After an upgrade, call for register end point may route to the wrong SCM.

The code is modified to re-implement the packing logic and avoid using sizeof() to calculate the size of data structure.

Workaround: N/A

32SBX-96001 | SBX-1014591

Portfix SBX-96001 (Originated in Release 9.1.0) The SBC 7000 has the wrong value for call duration.

Impact: The call service duration (CDR field numbers 10 and 14) has the wrong values, causing a billing issue.

Root Cause: This issue is seen when there is a mid call message in this case session refresh. Due to this session refresh, there are mid call messages(INV/200OK/ACK) that happen end to end. This makes the "callServiceEstTime" in the function CcRelayInfoMsg() overwritten every time, causing the CDR fields 10 and 14 wrong values.

Steps to Replicate: 

  1. Enable IPSP flag "End to End ACK" on both TGs.
  2. Disable the flag "No CDR Change in End to End Ack".
  3. Make a call from A to B and let the call be connected with session refresh enabled.
  4. Once the session refresh occurs, disconnect the call and check the CDR.

The code is modified so that the "callServiceEstTime" does not get overwritten once it is recorded initially during initial offer-answer.

Workaround: Enable the flag "No CDR Change in End to End Ack".

33SBX-103948 | SBX-1039751

Portfix SBX-103948 (Originated in Release 8.2.1) The SBC Application is crashing when the CPaaS to PSTN call is made.

Impact: The SBC cores after a reboot/upgrade.

Root Cause: The issue was introduced when the SBC tries to support the 10000 SMM rules in 8.2.0.

Steps to Replicate: Configure the customer rules (delete sdp line). Major logs trigger but the rule still runs successfully. After a reboot/upgrade, the SBC cores.

The code is modified to fix the issue.

Workaround: Disable the delete sdp rule.

Severity 2-4 Resolved Issues

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

Resolved Issues


Issue IDSevProblem DescriptionResolution
1SBX-1004953

The EMA GUI is not showing the username of configured AD Domain Controller correctly.

Impact: Getting a Defined type NULL if it is "Direct type".

Root Cause: The EMA GUI is not showing the username of configured AD Domain Controller correctly.

Steps to Replicate: 

  1. Log on to EMA
  2. Navigate to Global > Servers > Domain Controller > Domain Controller ID
  3. See the All the user Names in the screen.
  4. Now the interface will the exact names that was assigned.

Platform/Feature: SBC

The code is modified to get the correct Defined Type.

Workaround: N/A

2SBX-988442

SDP attribute a=X-nat - duplicated (selective sdp relay).

Impact: Due to a new change in 8.2 we did not consider the b line length properly, so "a=X-nat" was added twice

Root Cause: Due to a new change in 8.2, we did not took the b line length into account while adding b line on egress. So we ended up adding "a=X-nat" line twice, once as part of b line and once as a line

Steps to Replicate: 

Send INVITE with b line and a line in SDP as below

v=0
o=Sonus_UAC 203537 229017 IN IP4 10.xxx.xxx.xxx
s=SIP Media Capabilities
c=IN IP4 10.xxx.xxx.xxx
b=AS:84
t=0 0
a=X-nat:0
m=audio 1086 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=sendrecv

"a=X-nat " line should not be added twice on egress side.

The code is modified to copy exactly b line bytes as part of adding b line on egress. So "a=X-nat" line is added only once as expected

Workaround: N/A

3SBX-100843 / SBX-1008393

Portfix SBX-100839: The GR-HA leader election could choose the starting node that is not in sync.

Impact: A race condition exists with the G-HA leader election algorithm whereby when coming out of split-brain so you could choose the node that is starting and not sync'd to be the leader. This causes a full outage.

Root Cause: The potential existed to check the wrong node's sync state when verifying the potential leader was in sync.

Steps to Replicate: Cluster is configured for enhanced leader election.
Both nodes are up and then a switchover so that the standby is promoted to active. While the active is coming up, force a split brain and then re-establish communication between the nodes. Verify that the booting node is chosen to restart even though it is the node that was active the shortest amount of time.

The code  is modified so that the proper nodes sync state is checked.

Workaround: N/A

4SBX-100512 / SBX-1004812

Portfix SBX-100481: Observed a jitter for more than 5ms in the passthrough call load.

Impact: More than a 5ms jitter and relatively high packet loss was observed in passthrough calls.

Root Cause: There was a segregation of media and non-media processes at initialization time that may fail occasionally, leading to non-media processes landing on vcpus meant for media processing.

This leads to a higher jitter and possibly higher packet loss.

Steps to Replicate: Issuing the following command show only yield kernel threads and SWe_NP processes:
cset proc -l root

The code is modified to function reliably.

Workaround: Reboot the instance.

5SBX-100667 / SBX-994142

Portfix SBX-99414: The 6ms of jitter is observed on the pktart side from the SBC while the accepted value of the jitter is 3ms for a transcoded call in a call mix load of direct media and a transcoding scenario.

Impact: More than 6ms of jitter was introduced in transcoded calls in call mix scenarios.

Root Cause: The primary and Secondary ATA Interrupts landing on media processing cores were causing processing jitter due to high volume of preemption.

Steps to Replicate: Verify that the IRQ 15 and 14 are incremented against core 0 only.

The code is modified to avoid the media processing cores.

Workaround: N/A

6SBX-1014002

The user creation/login validation issue in the EMA and Platform Manager.

Impact: When the username contain special characters for example: " - " , it will have problem to log into platform manager, but not in EMA. It also doesn't throw any error while creating user contain special character " - ".

Root Cause: EMA username supports underscore(-), when creating a new user, but when logging in to a platform manager, the platform manager does not support underscore(-) and login throws error authentication mismatch.

Steps to Replicate: 

  1. Login into EMA and create new user with username ribbon-eci.
  2. Login into EMA and platform manager.
  3. Platform manager login throws error.

The code is modified to fix the issue on the EMS supports.

Workaround: No workaround.

7SBX-101463 / SBX-965652

Portfix SBX-96565: The sbxstop on Active can lead to the /dev/drbd0 not mounted on new Active..

Impact: The sbxstop of Active can lead to /dev/drbd0 not mounted on new Active.

Root Cause: The Drbd was getting unmounted right after the mount when the switchover happens.

Steps to Replicate: The following are the steps that need to be followed to test this:

- On node A, run the switchover from platform manager
- B will become active, wait for A to become standby.
- Run sbxrestart on B so that A becomes active again.
- Check df or /proc/mounts for drbd mount status.

The code is modified so the cron job runs once whenever the node becomes active and mount the drbd partition.

Workaround: N/A

8SBX-1014742

Potential memory leak of ICM message in SG FSM when switching to secondary NIF for MS Teams call.

Impact: It is possible to get a small memory leak in an MS Teams media optimization configuration for each PSTN to Teams call that uses the secondary (public) media interface to teams endpoint. Over a large number of such calls (estimate 10,000 +) this could result in enough memory loss to cause new calls to fail to establish.

Root Cause: When an ICE call to MS Teams switches to the secondary media interface, the existing egress ICE context for the primary interface is replaced by a new one for the secondary interface. This context switching involves inter task messaging on the SBC, there was a potential path in the code where one of these messages was not releasing its used memory correctly.

Steps to Replicate: Establish and release a large number (10,000 +) of PSTN to MS Teams calls that use the secondary (public) media interface to teams endpoints.

Platform/Feature: SBC

The code is modified to remove the inter task message that could have lead to the issue.

Workaround: N/A

9SBX-1003732

The Standby SBC memory at 94% seems the SCM Process was leaking.

Impact: The SCM process on standby is running out of memory when the path headers are included in the Registration messages.

Root Cause: The SCM process on standby is leaking a SIP structure related to the path headers that are included in the Registration messages.

Steps to Replicate: This issue can be reproduced by running Registration load which includes path headers in egress Registration messages.

The code is modified to free the structure that had been leaking.

Workaround: N/A

10SBX-1009842

The TEAMS zone detection should be case insensitive.

Impact: The MS Teams zone detection logic may not work to provide native support for functionality.

Root Cause: In the 8.2 release, the SBC was updated to provide native support for MS Teams functionality previously implemented using SMM. This is done by reading the FQDN from the pathcheck logic in the zone. It was assumed that the FQDN would be in lower case but some customers have configured in upper case and the code is not matching this format, which results in the native functionality not being provided.

Steps to Replicate: Configure all the FQDNs in the patchcheck configuration in upper case e.g. SIP.PSTNHUB.MICROSOFT.COM and the native Teams functionality will not be triggered.

The code is modified to perform the non case sensitive checking for the pstnhub.microsoft.com FQDN.

Workaround: Change the sip.pstnhub.microsoft.com FQDN in the pathchk configuration to use lower case instead of uppercase or leave SMM in place from older releases.

11SBX-986462

The AddressSanitizer has heap-buffer-overflow on the address 0x607000326fe4 at pc 0x563429a99aac bp 0x7f371d414210 sp 0x7f371d4139c0.

Impact: When the END2END ACK control is enabled and making calls between the SBC and GSX, the GSX sends a bad parameter to the SBC and it causes the SBC to read invalid memory and occasionally coredumped.

Root Cause: The problem is due to the GSX using the wrong enumeration range for an internal CPC parameter type. The associated parameter it creates does not contain any data. This causes the SBC to think its a completely different parameter which is expects to contain mandatory parameter data. It reads the data, which results in it reading off the end of the message block. This is broken since original implementation and generally does not cause issues. But if the message memory block happens to be at the edge of the valid memory range then it can result in an invalid memory read which triggers a coredump.

Steps to Replicate: This issue is highlighted when using ASAN enabled images in the engineering lab, but it is known to cause occasional coredumps in production.

The code is modified to ignore the bad parameter information coming from the GSX to avoid reading invalid memory.

Workaround: Disable the END to END ACK control if possible.

12SBX-101426 / SBX-1002112

Portfix SBX-100211: The MIM Hash memory leak for an IMSLI call was in the DSBC only.

Impact: One of the modules(MIM) used for IMS Lawful Interception leaks a hash entry every time a IMS Lawful interception is triggered for a call.

Without this fix, there will be a continuous memory leak of an hash entry for each IMS Lawful intercepted call.

Root Cause: An IMS Lawful interception stop indication is not being propagated to One of the modules used for IMS Lawful interception as of a result of this, the hash entry created to achieve/keep track of IMS interception is not freed even after interception for that call stops.

Steps to Replicate: Make an IMS Lawful intercepted call.

The code is modified so that it can cleanup the concerned hash entries.

Workaround: N/A

13SBX-1007992

The SYS is filling up the "mcsEncodeCPC_MSG_INFO_STR: CPC_OP_STR parameter length mismatch".

Impact: The following log message is filling up the SYS log when the STIR/SHAKEN feature is in use:

MAJOR .GWCM: mcsEncodeCPC_MSG_INFO_STR: CPC_OP_STR parameter length mismatch: sizeof length 152: parameter length 216, parameter:397

Root Cause: There is code in the SAM that is checking for an internal inconsistency and logging this message when it detects an internal inconsistency.

In this specific case, the message is being logged unnecessarily and it does not indicate any impact on customer functionality.

Steps to Replicate: Set up the SBC and PSX for STIR/SHAKEN call flows and run a GW-GW call.

The code is modified to ensure that this message is no longer logged for in this very specific scenario.

Note: This specific message (for parameter:397) does not indicate any impact on customer functionality.

Workaround: There is no workaround. 

14SBX-1013153

During an SBC switchover, the SCM process coredumped as a result.

Impact: The SCM process cored due to double freeing of a SIP structure related to Subscriptions.

Root Cause: The SCM process cored due to double freeing of a SIP structure related to Subscriptions.

Steps to Replicate: The issue is not reproducible. 

The code is modified to ensure that it does not attempt to free the structure that has already been freed.

Workaround: N/A

15SBX-99204 | SBX-992743

Portfix SBX-99204 (Originated in Release 9.1.0) There was a TIPC log format change and needs to update CHM code for duplicate error detection.

Impact: Duplicate The TIPC address logic may fail to detect a duplicate TIPC address and nodes will fail to take the proper role and/or start.

Root Cause: The kernel message was being looked for has changed.

Steps to Replicate: Install both nodes as the primary node. When the second node is started, it should fail to start and report a standalone/HA pair configuration mismatch.

The code is modified to look for the proper error message.

Workaround: Proper install of the nodes as primary and secondary, and proper setting of the TIPC ID in a swe environment.

16SBX-100935 / SBX-976442

Portfix SBX-97644: The SBC is not sending the precondition parameter in Supported header in UPDATE message in 1-1-2 customer call flow in SBX-97644.

Impact: The SBC was not sending the preconditions option tag(in Require/Supported) in the UPDATE request generated towards the ingress endpoint during preconditions transparent settings.

Root Cause: While performing precondition transparency, the SBC uses the received message buffer to copy preconditions option tag transparently. But, since the UPDATE here was a locally generated one, the SBC was unable to get any option tag. Therefore precondition option tag was not sent.

Steps to Replicate: 

  1. The Egress endpoint has to send the 183 (Dialog-2) with “Require: precondition” header to SBC.
  2. The SBC has to send the 183 to ingress endpoint.
  3. After PRACK and 200 OK, the SBC has to send the UPDATE message to ingress endpoint with “Supported: precondition” header. But the SBC is not sending the precondition parameter in supported header.

The code is modified for the outgoing message(to maintain as much as transparency). When sending such UPDATES, refer to this state and add option tag accordingly.

Workaround: One workaround is to add SMM.

17SBX-100933 / SBX-976442

Portfix SBX-97644: The SBC is queuing the UPDATE message during the preconditions and downstream forking call flow(customer 1-1-2 call flow) in SBX-97644.

Impact: The SBC is queuing the 200 OK of UPDATE with downstreamForkingSupport enabled and UPDATE received on the egress.

Root Cause: In case of Downstream forking queuing mechanism, there could be chance that TYPE_STATUS can fall-thrugh to CASE_OTHER so that when calling the generic CMD, the callDirection,msgtype and msgStatus are not being sent out.

Steps to Replicate: This behavior is not always reproducible. Sometimes, the SBC is able to process the UPDATE message and forward to egress leg and call is successful.

The code is modified to send callDirection,msgtype and msgStatus in this case

Workaround: N/A

18SBX-1012092

The NVIDIA V100 Based GPU instance fails to come up in the VMWARE.

Impact: The NVIDIA V100 GPU Accelerated instance does not come up on the VMware host.

Root Cause: Due to large PCI memory requirements for V100 card, the V100 based VMware instance does not come up in legacy BIOS mode.

Steps to Replicate: Bring up the SBC VM with EFI BIOS instead of the legacy BIOS.

The code is modified so the V100 based VMware instance needs to be booted in EFI mode to work correctly.

Workaround: There is no workaround for this issue. V100 based VMware instance needs to be booted in EFI mode.

19SBX-101707 / SBX-1005612

Portfix SBX-100561 (Originated in 9.1.0): "Fac Total Block Count Stats" page was not loading in the EMA.

Impact: "Fac Total Block Count Stats" page was not loading in the EMA

Root Cause: In the SIPFE application, the "Global_facTotalBlockCountStats_keybuf" object was not registered with ICM. This led the ICM message send to SIPFE fail due to this EMA query failed.

Steps to Replicate: 

  1. Launch EMA.
  2. Go to All -> Global -> Fac Total Block Count Stats.

The missed object registration is done.

Workaround: N/A

20SBX-100084 / SBX-1006423

Portfix SBX-100642 (Originated in Release 9.1.0): The cloud instantiation is failing on the M-SBC2 as the LCA exits with an error.

Impact: In the SBC Cloud environment, the LCA fails to come up due to index exchange errors.

Root Cause: There was a race condition between LCA read and index-serf write on the platform.json.

Steps to Replicate: This issue is rarely observed.

* To reproduce the issue, launch a 4:1 I-SBC instance on Openstack, in such a way that a RG serf detects a service ID collision.

* This results in reboot of the instances.

* In the next boot, the LCA started the index exchange serf.

* Index exchange serf will be started and comes up in the running state.

* Index exchange serf detects the presence of a peer in the cluster, the index exchange serf tries to update the platform.json file.

* At the same time, the LCA module(setCPUIndices.py) tries to read the content of the platform.json file.

* The json load operation failed, since the content is not in proper json format.

* LCA exits out. The serf operations continues. Application will not be brought up.

The code is modified so the lock mechanism is reading and writing process of platform.json file.

WorkaroundReboot of the SBC instances which encounters this issue.

21SBX-99441 / SBX-867632

Portfix SBX-86763 (Originated in Release 9.0.0): The sipClientStatistics gets incremented on the SLB by 2 for a single call.

Impact: The sipClientStatistics gets incremented by 2 for a single call.

Root Cause: This issue is seen only after a switchover of SLB. After a switchover, there were two calls to register to the sipClientStatistics object because for each call, the statistics would get updated twice from the two registrations.

Steps to Replicate: Make a call before and after switchover of SLB and ensure that sipClientStatistics is updated properly

The code is modified to register only once to the sipClientStatistics object.

Workaround: N/A

22SBX-100258 / SBX-991972

Portfix SBX-99197 (Originated in Release 9.0.0): The ASAN set up CE_Node2.log file has errors.

Impact: There was invalid memory access while allocating the media tap resource for an audio stream.

Root Cause: There was an invalid index is used to access the array which caused this out-of-bound memory access.

Steps to Replicate: 

  1. Provision the SIPRec for a basic audio call.
  2. After the egress peer answers, the SBC sends INVITE towards a SIPRec server.
  3. SIPRec server answers the call.
  4. At this stage, the SBC allocates media tap related resources and that caused this invalid memory access.

Access the array only if the index is valid to fix the issue.

Workaround: N/A

23SBX-99155 / SBX-984182

Portfix SBX-98418 (Originated in Release 9.0.0): Deleting the system->slb->commInterface was not working as expected.

Impact: Deleting the /system/slb/commInterface was not working. Connections between the SBC and SLB still remain active.

Root Cause: The delete operation on the tree /system/slb is not handled separately as of now. For all operations on /system/slb, the cdb_get was being done and would fail for during the delete operation. So deletion was not being handled properly.

Steps to Replicate: Delete the system->slb->commInterface. Ensure the connections between the SBC and SLB are closed.

The code is modified to handle deletion of system->slb→commInterface.

Workaround: Disable and enable the SLB usage if the commInterface is changed. Disabling of SLB usage requires an SBC restart.

24SBX-100862 / SBX-971023

Portfix SBX-97102 (Originated in Release 9.1.0): During a direct dial to call queue and then while transferring to another agent, there was no RBT heard on the PSTN side.

Impact: While making a call from PSTN user to Teams Call Q when the Teams1 user later transfers the call to Teams2 user, there is no RBT heard.

Root Cause: Call control was not in the correct state to generate the RBT on the subsequent transfer from Teams1 to Teams2.

Steps to Replicate: Make a call from PSTN user to Teams Call Q, answer with Teams1 user and then transfer to Teams2 user and check that RBT is heard during the transfer.

The code is modified to ensure that call control transitions to the correct state in order to generate the RBT on the latest transfer.

Workaround: N/A

25SBX-101425 / SBX-1011562

Portfix SBX-101156 (Originated in Release 9.1.0): The SRTP context for video is omitted.

Impact: The SBC offers RTP context for video stream instead of SRTP during RESUME re-Invite after HOLD is performed with video mediaPort being zero.

Root Cause: Certain code was copying the SRTP info from previous active SDP in order to retain the same SRTP key in subsequent call modifications.

However, it does not handle the case if that particular stream is removed in between and then was added back.

Steps to Replicate: 

  1. Set up Audio and Video RTP to SRTP pass-Thru call.
  2. Ingress peer (RTP side) sends re-Invite to disable video stream (sends re-Invite with audio stream having valid media port and sendrecv AND video stream having port=0 and inactive).
  3. Ingress peer (RTP side) sends re-Invite to add video stream back (sends re-Invite with audio stream having valid media port and sendrecv AND video stream having valid media port and sendrecv).

Expected Result:
a) RTP-SRTP A+V call gets established.
b) The SBC disables video stream and sets up RTP-SRTP call with audio stream.
c) The SBC re-establishes Audio and Video RTP-SRTP call.

Actual Result:
a) RTP-SRTP A+V call gets established.
b) The SBC disables video stream and sets up RTP-SRTP call with audio stream.
c) The SBC re-establishes Audio and Video RTP-SRTP call.

The code is modified to copy SRTP info from previous active SDP only if stream is valid in that SDP.

Workaround: N/A

26SBX-100094 / SBX-991692

Portfix SBX-99169 (Originated in 9.0.0): The ASAN heap-buffer-overflow in the SipFeProcessSlbIncomingPdu - SBC ASAN build failure when testing epcac DBL with SLB.

Impact: The SBC was accessing call control memory block after the memory block had been freed.

Root Cause: The call control logic maintained a queue of call control blocks that had outstanding events, which needed processing. However, in some places the code processed the outstanding events and did not remove the call control block from the queue. While processing call cleanup events, it was possible that the same call control block got added to the queue twice. When the call control instance was released it removed one instance from the queue but later processing code then noticed there was still a call control block left in the queue and tried to read the memory to process it after it had been freed.

Steps to Replicate: This issue is only highlighted in engineering lab while running with ASAN enabled images. Run call load and trigger bulk call failure.

The code is modified to ensure that call control blocks are removed from the pending queue, when all outstanding events are processed to avoid accessing memory after it is freed.

Workaround: N/A

27SBX-101442 / SBX-1013554

Portfix SBX-101355 (Originated in Release 9.1.0): The SBC was not stable after the upgrade to 8.2.2R0 - serf.conf file corruption RCA.

Impact: On an upgrade of the SBC SWe to version 8.2, the primary upgrade status was not updated causing post-upgrade checks failure.

Root Cause: This issue was due to the missing peerHAIp entry(100.xxx.xx.x) in serf config file on primary node.

Steps to Replicate: Perform upgrade to the SBC SWe to fix version 8.2.2R1 and ensure HA IPs are updated in serf.conf file.

The code is modified to ensure the HA IPs of both nodes are added to the serf conf file.

Workaround: N/A

28SBX-101623 / SBX-1004542

Portfix SBX-100454 (Originated in Release 9.1.0): The SBC fails to transcode between the G711X in certain SIP - GW2GW scenarios with HDCodecPreferred and preferNBPassthruOverHDTranscode flags enabled.

Impact: The SBC fails to transcode between the G711X in certain SIP - GW2GW scenarios with the HDCodecPreferred and preferNBPassthruOverHDTranscode flags enabled.

Root Cause: If the HD flag is enabled, the ingress GW is using the egress codec as selectedCodecEntry instead of codec entry from audioEncode array. However, the selected Codec Entry is not fully qualified since it's not intersected with Route PSP.

Steps to Replicate: SIPA - SBC1 (Gw-Gw) SBC2 - SIPB

  1. SIP A is offering G711U along with other codecs
  2. SIP B is answering with G711A. Ingress Route PSP -> G711U,G729A,G722
    Gateway Route PSP -> G711U,G729A,G711A,G722
    Egress Route PSP -> G711U,G711A
  3. When SBC01 receives answer with G711A codec, it fails to transcode the call between G711U on the ingress SIP call leg and G711A on the egress GW2GW call leg. call is disconnecting with 488 error.

The code is modified to use the matching codec entry from audioEncode array instead of the selected codec in answer PSP on ingress GW.

WorkaroundTestcases:

Case-1. Disable diff in SS flag and keep HD flags enabled.

Case-2. Disable HD flags and keep Diff in SS flag enabled.

Enabled both HD and diff in SS flag:

Case-3: Ingress and Egress Route PSP has G711USS,G711ASS respectively and GW route PSP has G711-DEFAULT.

Case-4: Ingress and Egress Route PSP has G711USS,G711ASS respectively and GW route PSP has G711SS-DEFAULT.

29SBX-101987 / SBX-1018942

Portfix SBX-101894 (Originated in Release 9.1.0): The GCP: RTCP packets are not being sent and received by the SBC in UDP SRTP - UDP SRTP call scenario.

Impact: With a small SWe SBC profile in the GCP platform, when the SecureRTCP is enabled, RTCP packets were not generated/relayed by the SBC.

Root Cause: With the dynamic range of resources allocation based on SWe capacity model, media enc context range check was using a wrong value in packet processing, resulted in RTCP packet drops which required encryption with in the SBC.

Steps to Replicate: With GCP platform small SWe configuration, enable the RTCP relay/termination with SRTCP support and check the RTCP packets flow.

The code is modified to the right media enc range value for the SBC media packet processing to encrypt the RTP, RTCP packets.

Workaround: Enable RTCP relay/termination without SRTCP.

30SBX-993293

There was a race condition in handling of ccbPtr→bIsTonePlayingEgressFlag.

Impact: The SBC was incorrectly mapping re-INVITE with a=inactive to a=sendonly when 200OK arrives quickly after 180 without SDP and RBT configured.

Root Cause: When the ingress side is playing a tone it sends a message back to the egress side to let it know. The egress side is meant to clear this flag when the 200 OK message arrives. However, there was a race condition where the 200 OK could arrive before the ingress side is able to send the tone indication message to the egress side and then the flag is not reset.

The egress side uses this flag to update the SDP media direction to a=sendonly, when a hold indication arrives and tone is being played to allow the SBC to finish playing out the tone.

Steps to Replicate: With the SBC configured to generate ring back tone on the receipt of 180 without SDP. Make a call where the SBC sends out INVITE and the egress side responds with 180 without SDP and immediately followed by a 200 OK. Once the call is answered then send in an INVITE with a=inactive from the egress side and check that the SBC sends out INVITE with a=inactive on the ingress side.

The code is modified to no longer set the tone playing flag at the egress side if the 200 OK message is received.

Workaround: N/A

31SBX-100953 / SBX-995612

Portfix SBX-99561 (Originated in Release 9.1.0): The ASAN heap-use-after-free in CcProcCallFsmMsg - CLONE - The SBC ASAN build failure when testing the epcac DBL with SLB.

Impact: The SBC was accessing call control memory block after the memory block had been freed.

Root Cause: The call control logic maintained a queue of call control blocks which had outstanding events which needed processing. However, in some places the code processed the outstanding events and did not remove the call control block from the queue. While processing call cleanup events, it was possible that the same call control block got added to the queue twice. When the call control instance was released it removed one instance from the queue but later processing code then noticed there was still a call control block left in the queue and tried to read the memory to process it after it had been freed.

Steps to Replicate: This issue is only highlighted in engineering lab while running with ASAN enabled images. Run call load and trigger bulk call failure.

The code is modified to ensure that call control blocks are removed from the pending queue and when all outstanding events are processed to avoid accessing memory after it is free.

Workaround: N/A

32SBX-97175 / SBX-965182

Portfix SBX-96518 (Originated in Release 9.0.0): There was a memory leak that was detected for x headers.

Impact: Customers using the X-header capability on the SBC would see a small memory leak every time the SBC is creating the reason header based on the release information.

Root Cause: The could was double allocating a memory block by mistake resulting in a memory leak.

Steps to Replicate: Run a test case with the Japan X-header feature enabled and release the call so the SBC has to generate a reason header based on the internal cause value information to send along with the other X-headers.

The code is modified to avoid the memory leak.

Workaround: N/A

33SBX-99722 / SBX-991152

Portfix SBX-99115 (Originated in Release 9.0.0): Observing the MAJOR log "XrmMflowCmdSnoopBld cannot find Snoop Id 0" while running the SIPREC with 4 recorders on KVM-20vcpu set up.

Impact: Observing MAJOR log "XrmMflowCmdSnoopBld: Can't find Snoop Id 0" while running SIPREC with 4 recorders on KVM-20vcpu set up.

Root Cause: During the Modify, there is no check if the snoop is enabled before invoking resulting in ERROR log mentioned in the Jira.

During the Activate, there is a check for snoopId being enabled, missing during the Modify.

Steps to Replicate: Issue was observed with load testing with the SIPREC enabled.

Check if snoop is enabled for the modify flows to address the issue.

Workaround: N/A

34SBX-1015712

The AddressSanitizer detected a heap-use-after-free on the address 0x6110000a302c at pc 0x55bcb2c39996 bp 0x7fbf04828250 sp 0x7fbf04828248 READ of size 2 at 0x6110000a302c thread T9.

Impact: The "heap use after free" occurs when IP Peer is created.

Root Cause: This is because of accessing the memory which is already freed.

Steps to Replicate: Re-Create an IP Peer with the same name, Ip Address and IP Port to reproduce this issue.

The code is modified to fix this issue.

Workaround: Do not create same IP Peer with same Name, Ip Address and IP Port.

If required, delete the old Ip Peer and re-create the same.

35SBX-101840 / SBX-1018302

Portfix SBX-101830 (Originated in Release 9.1.0): The SBC services are going down while running the CLI to create toneCodecEntry.

Impact: The stack buffer overflow while executed on the toneCodecEntry for the AMR files.

Root Cause: This issue is from day one since USHORT was used instead of the ULONG for coding rate variable.

Steps to Replicate: Execute the toneCodecEntry CLI for AMR codec.

The code is modified to ulCodingRate(ULONG).

Workaround: N/A

36SBX-100458 / SBX-999962

Portfix SBX-99996 (Originated in Release 9.0.0): Observing the Major Logs in DBG logs while running the SIPREC on SBC 7000 and SBC 5400 set ups.

Impact: Observed the following code mentioned MAJOR logs when running the SIPREC load on HA set up.

117 05082020 152048.782437:1.01.00.09099.MAJOR .XRM: *NpMediaPnpsNpCmdSend: Cmd 0x29 failed, error code 0xffffffff
100 05082020 152048.782532:1.01.00.09100.MAJOR .XRM: *NpMediaFlowModify: Failed status 0xffffffff

Root Cause: To handle scenarios where mirrored snoop context is transitioning from disabled to enabled.

Modify the snoop even though snoopId is DISABLED.

By directly setting NP_MEDIA_FLOW_MOD_RTP_SNOOP_FLAG | NP_MEDIA_FLOW_MOD_RTCP_SNOOP_FLAG when invoking Modify for snoop flows.

Even though there is a check to modify snoop only when snoopId is NOT DISABLED, still end up sending the modFlags as it is to PNPS, resulting in PNPS errors for modifying invalid snoopId.

Steps to Replicate: Issue was found during load testing with SIPREC enabled.


Workaround: N/A

37SBX-915193

There are unnecessary alarms on media port.

Impact: The SBC 5400 experienced false alarms for unused packet interfaces.

Root Cause: Code was missing to avoid unnecessary alarms for the unused packet ports.

Steps to Replicate: On an SBC 5400, disconnect the packet port cables and remove the configuration from the IpInterfacegroup to verify that alarms are not generated for unused packet ports.

The code is modified to handle cases where the packet port is not connected/configured in the IpInterfaceGroup to avoid unnecessary alarms.

Workaround: Connect the unused Ethernet ports to avoid getting alarms.

38SBX-1018182

An SBC Memory Leak occurred.

Impact: When the inbound calls to the SBC are released early, the SCM Process leaks memory.

Root Cause: When the inbound calls are released early, the SCM Process does not release the memory allocated to store the SIP PDU.

Steps to Replicate: 

  1. Change the mode of the ingress TG to out-of-service.

  2. Send a high number of calls (10000+) to the ingress TG with 1 cps.
    All calls are rejected.

  3. Verify the issue: Check the memory of ScmP. Memory has leaked.

The code is modified to ensure the SCM Process releases memory after early attempt call fails.

Workaround: Run the fix configuration which is causing early attempt failure.

39SBX-1011542

Transcode percentage required to load DSPs in sweTrafficProfile.

Impact: On specifying 100% tonesPercent in custom profile without selecting any transcode percentage in swe Traffic profile, tpads are not loaded and dspStatus does not show any tones resource available.

Root Cause: This is due to an incorrect check that considers only the transcode percentage to allocate the DSP resource in custom profile activation script.

Steps to Replicate: 

  1. Create a custom profile.
  2. Allocate tone percent as 100.
  3. Load the profile.
  4. Check for show status system dspStatus.

This shows no toneAvailable.

Consider the transcode as well as tones percentage in the SWe traffic profile for allocating the DSP resources in custom profile activation script.

Workaround: Allocate some of the transcodePercent in the custom profile.

40SBX-102286 / SBX-1011882

Portfix SBX-101188 (Originated in Release 9.1.0): The SBC halts when the disconnectSignalSequenceProfile is configured.

Impact: Configuring the disconnectSignalSequenceProfile in ASAN build causes the SBC to halt.

Root Cause: A stack-buffer-overflow occurs when accessing wrong data type in NrmaDiscSigSeqProfileSsCreate,

Steps to Replicate: Configure the disconnectSignalSequenceProfile in the latest ASAN build, and SBC should not halt,

The issue is fixed by changing the the data type from UCHAR to int32 in NrmaDiscSigSeqProfileSsCreate.

Workaround: N/A

41SBX-101861 / SBX-1012292

Portfix SBX-101229 (Originated in Release 9.1.0): There was a stack-buffer-overflow in SipsGetSmmProfileForDlgScopehashUpdate.

Impact: There was a stack buffer overflow when 487 response is triggered toward ingress leg.

Root Cause: A stack buffer overflow occurs when accessing the freed memory in stack for hSipMsgHandle->pstlocalTsap.

Steps to Replicate: Repeat the CANCEL call scenario to reproduce the issue.

The code is modified to populate the right memory in hSipMsgHandle→pstlocalTsap.

Workaround: N/A

42SBX-1020692

There was a SCM Process memory leak.

Impact: The standby SBC is leaking a per call structure that is used for Relay calls.
This leak can carry over to active when there is a switchover.

Root Cause: The leak is occurring because the code is overwriting the pointer to the structure, thereby preventing this structure from being freed when the call is completed.

Steps to Replicate: Upstream forking with INVITE and OOD messages

The code is modified to free the structure before the field that stores a pointer to it is overwritten.

Workaround: N/A

43SBX-973922

Observed a SCM process memory leak on the SBC 7000 platform.

Impact: A memory leak is observed when there are multiple calls to the function SipRaCopyAOR in the same call, the issue is observed during the call.

Root Cause: The existing memory is not freed before copying the new info to the endPointAor by using the SipRaCopyAOR.

Steps to Replicate: This issue is observed during the registration and call load scenario.

Run some registrations and make a call to registered users and run some load.

The code is modified to freed the existing memory of the buffer before copying the information into sipEndPointAor structure

Workaround: N/A

44SBX-1021922

The CLI import's fail when uploading a CLI text file in the unix format.

Impact: The CLI import's fail when uploading a CLI text file in the unix format.

Root Cause: Removing the last character of each CLI line, which was making this issue.

Steps to Replicate: 

  1. Navigate to Administration > System Administration > File Upload.
  2. Click "Add Files to Queue", select CLI file to be import, and click "Upload All Files".
  3. Navigate to "Configuration Script and Template Import".
  4. Select .cli file from "Configurations" file list and click "Start Import".
  5. See "Script and Template Status Monitor".

The code is modified to avoid the deletion of the last character in each CLI line that is read from the CLI file.

Workaround: N/A

45SBX-992082

The SBC has the same issue as SBX-86420. The SBC does not send the 'srv' query to DNS when the egress peer is FQDN and egress transport preference is TLS for outgoing REGISTER messages.

Impact: When TLS port is not sent from PSX, the SBC is not sending DNS srv query to DNS server. 

Root Cause: The root cause was when the SBC increments the port number by 1 and was sent by the PSX even if peer port was zero.

Steps to Replicate: 

  1. Configure the SBC and PSX to send 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.

To fix the issue, if port number sent by the PSX is zero then do not increment it by 1 by default for selecting the TLS port.

Workaround: N/A

46SBX-102152 / SBX-1020812

Portfix SBX-102081 (Originated in Release 7.2.4): During the RTP-VTP 10 CPS, a 100 CHT G729 passthrough load was found on the CPU Congestion and CPU Spike multiple times.

Impact: There was intermittent CPU congestion reported for two vcpus overnight run.

Root Cause: When using 2 vcpus, there is no dedicated SIG core with both the MGMT core and signaling cores are shared, and the spikes in mgmt threads are causing the SIG congestion.

Steps to Replicate: Run two vcpu over night passthrough load.

The code is modified to disable the CPU congestion monitoring for < 3 vcpu, as it does not have any detrimental effect.

The momentary spikes of the MGT processes does not cause call failures, but raises false alarms of the CPU congestion.

Workaround: N/A

47SBX-101548 | SBX-1015493

The Update (recvonly or inactive or sendonly) and Reinvite (recvonly) should not be converted to the CPG on the SIP-I side.

Impact: The ISUP standard does not allow the callee to put call on hold before call is answered.
The SBC sends an UDPATE message before answer with MIME body with CPG parameter with out hold or retrieve indication. Certain endpoints do not accept such SIP message and send 400 back to the SBC.
The second issue is the SBC sending re-INVITE to ingress with MIME body with CPG parameter but no hold or retrieve indication. Certain endpoints do not accept, such re=INVITE message and send 400 back to SBC.

Root Cause: The SBC sends SIP message with MIME body with a CPG parameter, but no hold or retrieve indication.

Steps to Replicate: Send an Update (call hold) before call answer or Reinvite (recvonly) after call answer from egress SIP side and check messages on ingress SIP-I side.

The code is modified to ensure the SIP message sent by the SBC to SIP-I endpoint are correct. The SBC does not send UPDATE and re-INVITE with MIME body without hold or retrieve indication. The SBC sends re-INVITE/UPDATE with SDP without ISUP body in such scenarios after the fix.

Workaround: Use a SMM workaround.

48SBX-1022982

The SBC is sending unwanted UPDATE towards EGRESS leg with all the codecs.

Impact: The SBC is sending unwanted UPDATE towards EGRESS leg with all the codecs.

Root Cause: When the SBC receives a 200 OK(for UPDATE) from the UAC, the internal feature flag is not being set that causes MODIFY OFFER to be triggered, which causes the SBC to trigger UPDATE towards egress.

Steps to Replicate: 

  1. UAC sent AMR-WB, AMR, PCMA as Offer to the SBC.
  2. The SBC offered AMR-WB, AMR, PCMA to UAS.
  3. UAS sent 180 Ring without SDP to the SBC.
  4. The SBC started playing tone and sent 180 with SDP with AMR-WB.
  5. UAS sent 183 with SDP PCMA.
  6. The SBC sent 183 without SDP to UAC.
  7. The SBC sent UPDATE with SDP PCMA.
  8. UAC sent 200 OK (for UPDATE) with SDP PCMA to the SBC.

At this stage, the 200 OK(for UPDATE) from UAC, triggering a MODIFY OFFER towards NRMA causing the SBC to trigger an UPDATE towards the UAS that is not expected.

The code is modified so that, when 200 OK (for UPDATE) SDP is received from the UAC, the SG minimizes the media changes if there is no considerable SDP parameters change.

Workaround: N/A

49SBX-1018142

The SBC does not generate the sonusSbxNodeResEmerCallNoRouteNotification.

Impact: The SBC does not generate the sonusSbxNodeResEmerCallNoRouteNotification alarm when the PSX returns no route for 911 based call (sip code 404, cause code 150).

Root Cause: The code to generate the sonusSbxNodeResEmerCallNoRouteNotification was not present in the scenario where the PSX returns no routes for the 911 based call.

Steps to Replicate: 

  1. Make a basic SIP call using the PSX with no routes set for number starting with '911' on the PSX.
  2. Configure the SBC:

    set profiles services emergencyCallProfile EmergencyCalls prefix 911

    set addressContext ADDR_CONTEXT_1 zone ZONE2 sipTrunkGroup SBXSUS12_LABSIP1 services emergencyCallProfile EmergencyCalls

The SBC does not generate the sonusSbxNodeResEmerCallNoRouteNotification alarm.

The code is modified to generate a sonusSbxNodeResEmerCallNoRouteNotification alarm when the PSX returns a "No Route" for emergency based call on matching URI prefix.

Workaround: N/A

50SBX-102649 | SBX-1026172

Portfix SBX-102617 (Originated in Release 7.2.5): The SIPFE crashed causing corruption on the msgObject.

Impact: Using the SNMP to query ipPeer statistics may core if an invalid zone or ipPeer name is entered.

Root Cause: When there was an SNMP walk for invalid zone/ippeer, the SBC may double free memory (introduced by SBX-51006).

Steps to Replicate: Using snmptool to walk through the data:
snmpwalk -c admin -t 20 -v 2c -m all sbxsus5-1 1.3.6.1.4.1.2879.2.10.2.243.1.2.14.65.68.68.82.95.67.      79.78.84.69.88.84.95.49.5.90.79.78.69.50.4.84.78.84.49

The code is modified to avoid freeing memory twice.

Workaround: Ensure the valid zone/ippeer is entered when querying

51SBX-99745 | SBX-942072

Portfix SBX-94207 (Originated in Release 9.0.0): The 2 MSBC active set ups did not come up after the configuration restore through the OAM in 3:1 MSBC set up.

Impact: Multiple expected reboots queued up so that the reboot count increased so much, that the service was not starting.

Root Cause: When the multiple reboots or/and restarts the queue up and the limit count is reached the service will not start.

Steps to Replicate: Perform a split brain, restore the configuration and unit tests.

Decrease the reboot and restart then count marker by 1, when the cause of reboot is known.

Workaround: N/A

52SBX-102776 | SBX-1022252

Portfix SBX-102225 (Originated in Release 9.1.0) The SBCs fail to terminate call upon the receipt of BYE from MRFP due to the rtp inactivity timeout.

Impact: The SBC fails to terminate the call if the disconnection is received from the MRF for a session where the tone is played and egress peer has performed mid-call modification.

Root Cause: In this call flow, after receiving a disconnect from MRF, the SBC wrongly picked up the tone context instead of the MRF context resulting in failure to terminate the call.

Steps to Replicate:

1. Early answer in 18x resulting in MRF transcoded call.
2. UAS sends 180 resulting in the SBC playing tones.
3. UAS sends SIP UPDATE to perform mid-call modification to change the codec.
4. MRF is configured for RTP inactivity detection. Due to some reason, it does not receive any RTP packets. MRF sends BYE to the SBC.

Expected Result:
The SBC terminates the call gracefully after receiving BYE from MRF.

Actual Result:
The SBC is not terminating the call.

The code is modified to pick the correct context holding the MRF resource.

Workaround: None.

53SBX-1013042

The call load along with switchovers and provisioning coredumps.

Impact: The IPsec data is stored for all signalling ports. The ipsec state array size was different from signalling ports array. Due to this issue, the ipsec state array is being overwritten.

Root Cause: Overwriting an array beyond its size led to memory corruption.

Steps to Replicate: 

  1. While configuring the SBC, add a sigPort with index 4096.
  2. Load testing at 500 cps for 15 hrs.
  3. Run a switchover testing.
  4. Physical port redundancy testing during load.
  5. Customer configuration testing during load.

The crash should not happen.

The code is modified so that it holds the same number of entries as signalling Ports array.

Workaround: While adding sigPorts, do not add sigPort index 4096.

54SBX-99064 | SBX-99063 | SBX-100121 | SBX-1001242

The LRBT had an unexpected UPDATE with the AMR-WB codec sent.

Impact: The SBC is not playing the tone using the same codec as negotiated, when the 183 with SDP is received and the same is indicated to ingress with UPDATE.

Root Cause:  It is a race condition exposed under the following conditions:

1. A calls B and B sends a 180 without SDP causing the tone to be played to A.
2. Subsequently B sends 183 with SDP so that the SBC needs to send UPDATE out to A for changing the codec.
3. Soon after the 183 with SDP from ingress is received, a 180 without SDP causes the tone play to start.
4. The race condition can be visualized as the UPDATE's 200 OK with SDP trying to modify the system for CUT-THRU, but instead interferes with resource management subsystem's attempt to play tone.
5. As a result, the resource management subsystem picks the incorrect PSP's to play tone.

Steps to Replicate: This issue is not easily reproducible and requires a set of configuration that customer has:

  1. No DLRBT.
  2. No Downstream forking.
  3. The Ingress has AMR - WB and NB codec and some other NB codec.
  4. The Egress has only NB codec's.
  5. Transcode is not allowed b/w WB and NB codecs.

The code is modified to enforce that while picking the PSP's to modify when TONE is on, pick the latest PSP and not an earlier one.

Workaround: Providing for Transcode b/w WB-NB will a correct call.

55SBX-925842

The flag 'statusUpdateSupport' is not working.

Impact: The SBC includes the Accept and Allow headers while generating OPTIONS ping requests towards the peer even when the statusUpdateSupport flag is disabled.

Root Cause: The code was not setting the flag correctly and passed the "Accept" and "Allow" headers irrespective of the statusUpdateSupport flag.

Steps to Replicate: To replicate/verify the issue configure the path check profile and set the stausUpdateSupport flag disabled. The SBC does not send the Accept and Allow header in the OPTIONS ping towards the peer.

The code is modified to handle the statusUpdateSupport flag correctly.

Workaround: The customer can use the SMM rule to remove the Allow and Accept headers from the OPTIONS ping.

56SBX-102878 | SBX-1027672

Portfix SBX-102767 (Originated in Release 9.1.0): A call from the subscriber number was not allowed after multiple switchover/standalone restart.

Impact: Configured the subscriber list for a surrogate Aor is not restored if the SBC is restarted/Switchover/LSWU.
So a call from a configured subscriber for a surrogates Aor will fail.

Root Cause: When restoring the IpPeer configuration from shared memory as part of SBX-62864 (Optimizing config load time), the restoration surrogate subscribe was missed from the SIPFE module. Optimizing the configuration load time feature had very big changes.

Steps to Replicate: 

  1. Configure Surrogate Registration Profile and Aor with configured Subscriber list.
  2. Attach it to an IpPeer and enable surrogate registration state at Profile and IpPeer.
  3. Make call for a configured subscriber call will be allowed and 401 challenge will be authenticated.
  4. Restart the SBC.
  5. Make call for a configured subscriber call will be allowed and 401 challenge will be not be authenticated.

The code is modified so the surrogate Registration AOR subscription list is restored to the SBC restart/Switchover/LSWU.

Workaround: Perform a SBC restart/Switchover/LSWU disable and re-enable surrogate state at IpPeer.

57SBX-1000852

The SCM process coredumps SipSgHashLookup on the OOD OPTIONS/Subscribe.

Impact: The SCM process may coredump while doing a SipSgHashLookup on a OOD OPTIONS/Subscribe message.

Root Cause: The sipsgRelayCbHashTbl was corrupted where a list head is corrupted and there is not additional information to state what caused the corruption. The issue may have been caused by an entry added to the hash table twice (maybe with different keys).

Steps to Replicate: Not reproducible in the lab. 

The code is modified to ensure the hash table entry is explicitly removed from the hash table, even if the hashlookup fails and also avoids adding a duplicate entry.

Workaround: N/A

58SBX-98602 | SBX-1000362

Portfix SBX-98602 (Originated in Release 9.0.0): The AddressSanitizer detected the heap-use-after-free on the address 0x61100006da70.

Impact: When the SBC relayed messages (e.g. UPDATE, REFER etc.), it read a memory block after it was freed.

Root Cause: The code that held a pointer to location inside a larger memory block, the larger memory block got freed but then immediately afterwards the code was doing a read to check a value from the pointer.

Steps to Replicate: This issue is only highlighted when running with ASAN enabled images in the engineering lab.

The code is modified so that it no longer accesses memory after it is freed.

Workaround: N/A

59SBX-96729 | SBX-967782

Portfix SBX-96729 (Originated in Release 9.0.0): The AddressSanitizer detected the heap-use-after-free on the address 0x6180000bd500 while running the IPSECAKA-UDP suite.

Impact: While deleting the IPSEC configuration, the SBC was reading memory after it had been freed up.

Root Cause: There was some debug code that was printing information from the memory block, even after it had been freed up.

Steps to Replicate: This is problem is only highlighted when we run IPSEC delete configuration commands in the engineering lab with ASAN enabled images.

The code is modified not to read the memory contents after the contents are freed up.

Workaround: Do not delete the IPSEC configuration.

60SBX-96427 | SBX-1000482

Portfix SBX-96427 (Originated in Release 9.0.0): The AddressSanitizer detected a alloc-dealloc-mismatch (operator new vs free) on 0x603002288530.

Impact: As part of security related testing, when the memory was getting freed, instead of using delete the SBC code was using free to release the allocated memory.

Root Cause: In the SBC code, when the memory was allocated, the code used was new but during deallocation, it was using free instead of delete.

Steps to Replicate: This problem is only highlighted when running with ASAN enabled images in the engineering lab.

The code is modified to use delete for memory deallocation instead of free.

Workaround: N/A

61SBX-101401 | SBX-1016782

Portfix SBX-101401 (Originated in Release 8.2.2) The call disconnected when the 10 PSX routes are returned.

Impact: Run an Invite Call Flow with the customer configuration where the PSX returns 10 Routes in the call, the SBC is disconnecting the call.

Root Cause: The IcmParamInsert is failing for one of the paramtype in the NrmaCcSelectEgressSgCmd as the size is exceeding max size ( ICM_REQUEST_MAX_12)

Steps to Replicate: Run a call flow with the customer configuration where the PSX returns 10 Routes per call.

The maximum size is increased to ICM_REQUEST_MAX_14 to address the issue.

Workaround: N/A

62SBX-102927 | SBX- 1029283

Portfix SBX-102927 (Originated in Release 9.1.0) The EVS codec attributes are non-readable after an upgrade from 7.2 to 8.2.

Impact: The upgrade fails to set the default value for the maxChannel flag.

Root Cause: The upgrade fails to set the default value for the maxChannel flag.

Steps to Replicate: 

  1. Create the codec profile in with codec=evs in sbc<8.1.
  2. Upgrade the SBC.
  3. The maxChannels value should be shown in CLI as 1.

The code is modified to set the default values during an upgrade.

Workaround: The value in db for attribute3 in code entry table should be modified to set the default value of maxChannels.

63SBX-967832

Some counts in callCurrentStatistics keep incrementing.

Impact: The "activeRegs" counter provided by the CLI zone callCurrentStatistics / callIntervalStatistics command may continuously increase.

Root Cause: There are badly formed SIP REGISTER messages received by the SBC that 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.

64SBX-1009892

The SCM process coredumped.

Impact: The SCM process may coredump during the gateway to gateway calls using SDP transparency.

Root Cause: The software packed and unpacked unsupported content header types causing NULL pointer access.

Steps to Replicate: 

  1. Configure the SBC for gateway to gateway calls using an external PSX.
  2. Configure the transparencyProfile on both ingress and egress trunk groups enabling sipMessageBody all.
  3. Configure the direct media and SDP transparency on both ingress and egress trunk groups.
  4. Perform SIP gateway to gateway call flow: INVITE, 183 with SDP, PRACK, 200 (prack), 180 with SDP, PRACK, 200 (prack), 200 with SDP, ACK, BYE, 200.

The code is modified to prevent the unsupported content header types from being packed and unpacked.

Workaround: The sdpTransparency is not supported over the gateway to gateway, disable the signaling sdpTransparency sdpTransparencyState.

65SBX-102495 | SBX-1028892

Portfix SBX-102495 (Originated in Release 7.2.1R10) The authentication process is not performed when calling for OTT.

Impact: New calls from child subscriber numbers of a particular AOR would fail after deletion of one or more subscriber numbers from the same AOR.

Example: profiles->services->surrogateRegistrationProfile->aorUserName->subscriberNumbers has a set of 10 numbers. If one or more numbers are deleted from this list (but the entire list is not deleted), then new calls from the remaining numbers in the list for the particular AOR user name fails.

Root Cause:  The ConfD version was upgraded from 6.4 to 6.7 in the 7.2.0R0 release.

In the ConfD version 6.4, the addition or deletion of elements from subscriberNumbers list was being notified to the SBC application as MOP_VALUE_SET and the SBC was invoking the function to handle modification to the list. Deleting the entire list was notified as MOP_DELETED and the SBC would invoke the function to handle deletion of the entire list.

In the Confd version 6.5 and above, the addition of elements to subscriberNumbers list gets notified as MOP_CREATED and the deletion of elements gets notified to the SBC application as MOP_DELETED. So after upgrading to 7.2.1R9, when the user deleted a few elements from the list, the SBC was notified with MOP_DELETED and it invoked the function to handle deletion of entire list (as it used to do earlier).

Steps to Replicate: 

  1. Create a surrogate registration profile with the AOR and child subscriber numbers.
  2. Validate that call from a child subscriber number is working upon successful registration of the AOR.
  3. Delete a subscriber number from the AOR.
  4. Validate that call from the deleted subscriber number is not authenticated upon receiving challenge from the proxy.
  5. Validate that calls from remaining subscriber numbers are validated/authenticated by the SBC upon receiving challenge response from proxy.

The code is modified to handle MOP_CREATED and MOP_DELETED notifications from ConfD to handle cases of creation,modification and deletion to the subscriberNumbers list.

Limitation note: Multiple subscriber numbers can be provided in a single command but any subscriber list related command needs to be part of a separate commit* (There cannot be two subscriber list commands in a single commit)

Workaround: Delete the entire subscriberNumbers list:

delete profiles services surrogateRegistrationProfile <profName> aorUserName <aorName> subscriberNumbers
commit

Add back the subscriber numbers needed:
set profiles services surrogateRegistrationProfile <profName> aorUserName <aorName> subscriberNumbers <num1> <num2> <num3>
commit

66SBX-1002862

The trace file containing a SIP Rec PDU was not imported in Ribbon Protect properly.

Impact: When 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, Ribbon Protect only reads the first line as there is no way for it to know subsequent lines are continuation lines.

Root Cause: The root cause came from a 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, 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.

67SBX-101237 | SBX-1030853

Portfix SBX-101237 (Originated in Release 9.1.0) Incorrect callMediaStats for rfc2833-rfc2833 pass through call on the SBC.

Impact: There was an incorrect callMediaStats for rfc2833-rfc2833 pass through call on the SBC.

Root Cause: For Pass through calls, when multiple codecs are configured on both legs in "Codecs Allowed For Transcoding", Active PSP on ingress leg does not have fully qualified selectedAudioEncode. As a result, ingress dtmfmode value contains incorrect value.

Steps to Replicate: 

  1. Make a sip call A-B with codec G723 with DTMF relay set to RFC2833.
  2. Configue DTMF preferred payload type to 101 in both egress and ingress PSP.
  3. Enable multiple codecs including G723 on both legs in "Codecs Allowed For Transcoding" in the ingress and egress PSP.

The code is modified to use the matching codec entry from audioEncode array instead of the selectedAudioEncode, and as a result takes the right value for ingress dtmfmode of callMediaStatus.

Workaround: None.

68SBX-102906 | SBX-1029862

Portfix SBX-102906 (Originated in Release 9.1.0) The LSWU from 6.2.1R0_2 to 9.1.0R0_8904 fails.

Impact: An upgrade failed due to an unsupported timezone.

Root Cause: The customer timezones are no longer supported, but the upgrade of these timezones were not handled.

Steps to Replicate:

1. Configure one of the three customer timezones.
2. Do an upgrade to 9.1R0(with fix).
3. The upgrade should succeed.

The code is modified to support the customer timezones. After an upgrade, the customer's three timezones are upgraded to Asia/Riyadh.

Workaround: None.

69SBX-102976 | SBX-1029802

Portfix SBX-102976 (Originated in Release 9.1.0) The diam process crashed while doing Rf specific configurations.

Impact: The "revert" option should be used before proceeding when there is an error returned from the confd. The DiamProcess coredumps when diamNode is configured incorrectly and proceeded without "revert" option.

Root Cause: A missing NULL check is the root cause for this issue.

Steps to Replicate: None.

Added NULL check to fix the issue.

Workaround: The "revert" option can be used when the confd throws an error and then proceeds with the further configuration.

70SBX-91016 | SBX-1025023

Portfix SBX-91016 (Originated in Release 9.1.0): Unable to see signaling messages on the PKT log file.

Impact: The packet capture does not work properly for PKT ports

Root Cause: version of libpcap0.8 library in Debian9 has a defect which results in the capture not working

Steps to Replicate: 

  1. Login to SBC and do basic call config.
  2. Create a signaling packet capture filter: set global callTrace signalingPacketCapture state enable devices pkt0 0.
  3. Run SIPP calls.

Expected Results:

  1. The SBC should capture all the signaling messages on the pkt0 port in a PKT file under gsxlog directory.

The code is modified to a newer version to address the problem.

Workaround: None.

71SBX-1029742

The SBC does not transfer contents of /var/log/syslog to the remote server whenever the log file is rotated.

Impact: The syslogLog, sftpLog, consoleLog, ntpLog and platformAuditLog fail to send logs through the syslog, when file sizes are decreased (for example when logs are rotated).

Root Cause: If a file size decreases but inode stays the same, then rsyslog does not (by default) know that the there is new logs being written to the files, therefore will not send these new logs.

Steps to Replicate: 

1. Set up logging to remote server for log type.
2. Run logrotate: logrotate -f.
3. Verify if new logs are written to the remote server.

The code is modified to reopen a file if it detects the the file was truncated.

Workaround: Edit /etc/rsyslog.conf and add reopenOnTruncate="on" to all input() rules.

For example:

#input(type="imfile" File="/var/log/syslog" Tag="syslog" Severity="info" Facility="news" reopenOnTruncate="on")

72SBX-93790 | SBX-1030712

Portfix SBX-93790 (Originated in Release 9.2.0) The TEAMS user not able to resume the call when transfer is failed, when the call is initiated in beginning by PSTN user.

Impact: During a Refer call, if the transfer target sends early answer in 18x but then rejects the call, the SBC fails to resumes the previously active call.

Root Cause: During call transfer, after tone play, while processing early answer in 183, 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) that 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: N/A

73SBX-1030392

The SIPFE sg allocation calls that always land on the SCM0 until exhausted.

Impact: A call from the AS without a registration may always land on the SCM0.

Root Cause: The SBC accidentally selected prefer SCM0 when no registration was found.

Steps to Replicate: Configure the zone xxx remoteDeviceType appServer, incoming call to zone xxx and without registration. The call will route to the SCM0 until the system is exhausted.

If there is no registration, the SBC round robins the SCMs.

Workaround: N/A

74SBX-102470 | SBX-937202

Portfix SBX-102470 (Originated in Release 9.1.0) SAM Process memory leak while running the TLS/SRTP load on the Openstack I-SBC.

Impact: The SIP-TLS with an Client Authentication (authClient=true in tlsProfle) causes about 1.2 KB of memory leak per TLS handshake on the SBC.

Root Cause: After verifying the peer certificate, the SBC SAM process did not free memory allocated for accessing the public key.

Steps to Replicate:

1. Run 50,000 SIP-TLS sessions with Client Authentication, and observe the memory used by SamProcess.
2. Run another 100,000 SIP-TLS sessions with Client Authentication, and observe the memory used by SamProcess.
3. Compute the extra memory used for additional 100,000 SIP-TLS sessions.

The code is modified to free the memory allocated for accessing public key after its use.

Workaround: None.

75SBX-102747 | SBX-1030832

Portfix SBX-102747 (Originating in Release 9.1.0) The USAGE_LIMIT and IN_USE columns of SystemLicenseInfoStats are updated with double the actual value of all the features in the licenseInfo table.

Impact: After a cloud instance running in Nto1 switches over, the USAGE_LIMIT and IN_USE columns of the SystemLicenseInfoStats are updated with double the actual value of all the features in licenseInfo table.

Root Cause: The code was not correctly updating the list of SBC processes that are contacted to obtain stats.

Steps to Replicate:

1. Run an N to 1 instance with at least 2 nodes.
2. Failover the active.
3. Check that the license SystemLicenseInfoStats pms file does not contain double the number in the USAGE_LIMIT and INUSE columns that is reported in system licenseInfo.

The code is modified to properly update the list of SBC processes that are contacted to obtained stats.

Workaround: After the former active restarts, restart it again.

76SBX-102932 | SBX-1029562

Portfix SBX-102932 (Originated in Release 9.1.0) When the Egress leg is tapped, a request-uri parameter is not sent in the SIPREC Metadata.

Impact: The request-URI is not added into the callData section of metadata sent towards the SRS while tapping the egress leg, though it is configured in SipRecMetaDataProfile.

Root Cause: This is day one issue where the RequestURI addition was not handled while tapping the egress leg.

Steps to Replicate: Make A to B call.

The code is modified to handle the requestURI while tapping the egress leg.

Workaround: No workaround.

77SBX-103005 | SBX-1030462

Portfix SBX-103005 (Originated in Release 9.1.0) The RequestURI header content is not correct in SIPREC Metadata profile.

Impact: The request URI header populates in the metadata is not added the URI scheme.

Root Cause: This scenario was not handled from day one.

Steps to Replicate: Make A to B call.

The code is modified to fix the issue.

Workaround: None.

78SBX-103004 | SBX-1030472

Portfix SBX-103004 (Originated in Release 9.1.0) The Content-Length header is missing for the SIPREC Metadata message body.

Impact: The content-length header is missing for the SIPREC Metadata message body.

Root Cause: This was not supported from day one.

Steps to Replicate: Make A to B call.

The code is modified in the SIPREC Metadata message body to address the issue.

Workaround: No workaround.

79SBX-102795 | SBX-1031502

The configuration flag "Sdp100relIwkForPrack" behavior is incorrect.

Impact: In a latemedia passthrough call, the SBC is not sending ACK for 200 OK when an Asymmetric PRACK Interworking feature is used.

Root Cause: The SBC fails to relay 200 OK for UPDATE in late media passthrough and a reverse offer scenario. This issue is fixed but the given fix breaks the Asymmetric PRACK feature functionality.

Steps to Replicate: Configuration:
1. Set the flag lateMediaSupport to pass through on the ingress TG.
2. Enable the 100rel Support on the ingress TG.
3. Enable the flag Sdp100relIwkForPrack on the egress TG.

Procedure:
UAC sends the Initial INTIVE request to SBC without sdp and has 100rel in Require header
UAS sends the 180 towards SBC with no sdp after receiving offer less Invite.
UAC sends PRACK with SDP answer after receiving 180 with SDP offer.
UAS sends the 200 OK towards SBC with sdp offer.
UAC sends ACK after receiving 200 OK.

Expected Result:
The SBC should send ACK with SDP answer on the egress side.
After re-negotiation media communication should be done as per final offer answer communication

The code is modified to address the issue.

Workaround: None.

80SBX-101876 | SBX-1024602

Portfix SBX-101876 (Originated in the Release 9.1.0) Possible NRS ICM message leaks.

Impact: There is a small memory leak when adding and deleting ACL rules.

Root Cause: The internal ICM message that is used to trigger the addition and removal of ACL rules in the NRS subsystem is not being freed up.

Steps to Replicate: Add and remove ACL rules and check for memory increasing.

The code is modified to correctly free the ICM memory block after it is processed to avoid the memory leak.

Workaround: None.

81SBX-103006 | SBX-1030342

Portfix SBX-103006 (Originated in the Release 9.1.0) The SIPREC Metadata schema has wrong value for the nameID AOR tag.

Impact: The nameId AOR formed in the metadata is incorrect when the P-Preferred-Identity header with alphabets in the UserName is received.

Root Cause: Username of P-Preferred-Identity header is modified internally based on E164 format.
P-Preferred-Identity is copied for SIPREC metadata purpose after the above modification. As a result, this caused the issue.
NOTE: The P-Preferred-Identity header with the numeric UserName is handled already.

Steps to Replicate: Make a A-B call with the P-Preferred-Identity header sent from A party and A party is recorded.

The code is modified for SIPREC metadata purpose before the E164 modification.

Workaround: No workaround.

82SBX-103137 | SBX-1032572

Portfix SBX-103137 The Ingress SBC is tearing the call down by sending unexpected BYE to the ingress endpoint.

Impact: The HDCodecPrefered flag is not working as expected if the SDP contains the first two codecs as HD.

Root Cause: If the SDP has first two consecutive HD codecs and HDCodecPreferred flag is enabled, the SBC is incorrectly considering the second HD Codec as NB.
This results in the SBC treating a HD codec as NB while applying the HD rules.

Steps to Replicate: The HD Codec preferred flag enabled
The offer contains multiple HD codecs (the first two being HD)

1. Create the Codec entries with codec G722,G711,G722.1,G729.
2. Configure PSP HDPSP1 with codecs (G722,G711,G729,G722.1), gw PSP GWHDPSP with codecs (G722.1,G711,G729,G722) and HDPSP2 with codecs (G711,G722,G722.1,G729).
3. Enable the following flags:
a) 'HDCodecPreferred and SRPP' flags in gw PSP.
b) 'All Codecs Allowed For Transcoding' in PSPs.
4. Make a LRBT call in which UAC sends INVITE with G722,G722.1.
5. UAS reply '180' without SDP
6. UAS reply '200 OK' with G711.

Expected:
1. Egress side INVITE must have codecs as per the sequence below, G722.1,G722,G711,G729.
2. Ingress side '200 OK' must have codecs as per the sequence below,
G722.
3. A call should be successful with G722 to G711 transcode on ingress side and G711 passthrough on egress side.

Do not tear down the call, due to the SBC treating the second HDCodec as NB.

The code is modified to consider it as a HD codec.

Workaround: None.

83SBX-1032652

There was an error on a SBC application switchover.

Impact: When an emergency call is terminated with a delay and incoming TG is marked out of service, the SMC process may core.

Root Cause: When an emergency call is terminated with a delay and incoming TG is marked out of service, the SMC process may core.

Steps to Replicate: Run an emergency call and ensure the SBC does not core.

The code is modified to ensure the SIP service group pointer is checked before de-referencing.

Workaround: N/A

84SBX-1021262

An error occurred during the CLI input being executed in the customer SBC.

Impact: The SM process cored when the CDB is loaded with bulk configuration.

Root Cause: Running dmesg got blocked when bulk configuration was loaded into CDB leading to healthcheck failure.

Steps to Replicate: None.

Disable healthcheck when the dmesg command is running to address the issue.

Workaround: N/A

85SBX-1032592

The diameter connState is closed after a switch-over.

Impact: Without this fix for Hardware and 1:1 deployments after a switch-over from the new Active, the diameter connection towards the diameter peers will not be initiated.

Root Cause: During a transition of the standby to active, one of the data types present in fetching the diameter peer from CDB is wrong. Due to this issue, the diameter peer configurations are not fetched from the CDB.

Steps to Replicate: 

  1. In Hardware or 1:1 HA set up, establish diameter connection from the active SBC.
  2. Perform a switch-over.
  3. After the standby becomes active, connection towards the diameter peers are not initiated.

The code is modified so that the diameter peer configurations are fetched properly by the application.

Workaround: N/A

86SBX-1027072

The network interfaces are not renamed as expected after an upgrade from 820R2 to 821R0.

Impact: The network interfaces are not properly mapped when the system is abruptly brought down after a first boot and rebooted.

Root Cause: Cloud-init service runs in parallel to sonusudev service and can cause issues with network interface mapping as it tries to rename the interfaces.

Steps to Replicate: Reboot system after sonusudev is run on first bootup.

The code is modified to start only after sonusudev is ran and mapped the interfaces properly.

Workaround: Reboot the instance again to recover from the issue.

87SBX-1032232

The application restarted because of of a SCM process core.

Impact: For a NativeForking scenario, the SCM process may core while deactivating media resources.

Root Cause: Based on a core analysis for a NativeForking scenario, while trying to deactivate media resources, the call control block may trigger null pointer exception.

Steps to Replicate: Run basic call forking scenarios.

The code is modified to ensure the NRMA deactivation pointer is checked before de-referencing.

Workaround: N/A

88SBX-100752 | SBX-1033992

Portfix SBX-100752 (Originating in Release 9.1.0) The "Filter Status" page stuck in loading while selecting a value from the list.

Impact: The "Filter Status" page stuck in loading while selecting a value from the list.

Root Cause: The reload icon is not removed after the loading the screen.

Steps to Replicate:

1. Log in to the EMA.
2. Navigate to Administration -> Accounting and Logs -> Event Log -> Filter Status.
3. Try selecting a value from the "Filter Status list". After clicking on the radio button, the page is stuck in loading phase.

The code is modified to remove the reload icon.

Workaround: None.

89SBX-103175 | SBX-1037772

The large microflow profile was not getting enabled in the Custom Traffic Profile.

Impact: 

  1. For the default profile, max subs were always set to 256K.
  2. For custom and standard traffic profiles, the micro flow count in NP resource was not correct.
  3. limited support of 2M micro flows for standard profiles.

Root Cause: 

  1. Large micro flow support was not there for custom traffic profiles.
  2. For standard and default traffic profiles, there was restricted/incomplete support of large micro flow which is made generic as part of this JIRA.

Steps to Replicate: 

  1. Create a instance with 10GB memory and 16vpcu with default traffic profile. Check microflow limits using "/opt/sonus/bin/cpsi -d summary" command.
  2. Increase memory to 50GB memory and check 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. To introduce a new estimation parameter maxSubs based on which micro flow count is decided on and NP hugepages that are reserved.
  2. To enable large micro flow support for all standard/default profiles where mem > 48GB and vcpu_count >10

Workaround: N/A

90SBX-103273 | SBX-1037982

Portfix SBX-103273 (Originated in Release 9.2.0) There was dual NUMA support in the SWe.

Impact: Multiple NUMA were not allowed in general (except few cases).

Root Cause: Restriction was imposed not to allow multiple NUMA in HostCheck.

Steps to Replicate: 

  1. Configure a KVM instance with dual NUMA and install 8.2.3R0 in Non-Gold/Non-GPU set up.
  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 in general irrespective of personality and profile.

Workaround: N/A

91SBX-1011412

When the PAI does not have a userinfo and when "Prefer PAI" is enabled, the verstat does not get added either to PAI/ From header.

Impact: When PAI header does not contain userinfo part, the verstat is not added to PAI or From header with the control set to "Prefer PAI".

Root Cause: While using the verstat as an user param, while formating the PAI header without an userinfo, the vetstat is dropped.

Steps to Replicate: Configure the STI profile, and send in an INVITE with no userinfo part in the PAI header. Configure PSX STI profile Verification control for verstat to "Prefer PAI".

The code is modified to add a verstat to the From header when none of the PAI header have a userinfo part and the control is set to Prefer PAI.

Workaround: N/A

92SBX-97373 | SBX-989722

Portfix SBX-97373 (Originated in Release 9.0.0) The SLB was establishing the connection on a IPv4 and IPv6 at the same time.

Impact: The SLB was establishing the connection on a IPv4 and IPv6 at the same time.

Root Cause: When the SLB commIntf is changed, the UMS server thread was being stopped and restarted with new interface address but the registration data of current clients (SBCs) registered to the SLB were not being deleted. So the SBCs were still showing up as "Connection State: up" in the sipClientStatus command.

Steps to Replicate: Change the SLB or SBC commInterface and ensure old connections are deleted.

The code is modified to initiate a deletion of CNode on Cluster Manager, Agent and sync it to standby. From the SBC side, calling SipFeSlbClientShutdown to delete client connections from the SBC when commIntf is changed and call SipFeUtilStartSlbClient.

Workaround: N/A

93SBX-98695 | SBX-989743

Portfix SBX-98695 (Originated in Release 9.0.0) There was a possible memory leak seen in the standby SLB.

Impact: A memory leak in standby SLB SCM process. There was a stale TCP connection seen in the active SLB when the SBC goes down.

Root Cause: Code was not present on the standby SLB to delete the data structure that stores the SBC details, when the SBC disconnects from the SLB. The TCP connection was not cleared correctly when the SBC disconnects from the SLB after SLB usage is disabled.

Steps to Replicate: 

  1. Attach a valgrind to the SCM process on the standby SLB.
  2. Once the SBC is connected to SLB, shut down the SBC.
  3. Bring down the SLB too and check valgrind logs.

For TCP connection

  1. Disable SLB usage and do sbxstop on the SBC.
  2. Verify if all TCP connections between the SBC and SLB is deleted correctly.

The code is modified to delete the internal data structure on standby SLB when SBC disconnects from SLB.

Also clearing TCP connection when SLB usage is disabled because it may run a sbxrestart after disabling the SLB usage (so active TCP connection could be present).

Workaround: N/A

94SBX-1029783

There is a new BMC/BIOS version for 8.2.3.

Impact: The BMC and BIOS versions are not up to date.

Root Cause: The BMC and BIOS versions are not up to date.

Steps to Replicate: Upgrade BMC before start app install

The code is modified so the BMC and BIOS firmware images are updated.
Firmware-5XX0-V03.22.00-R000.img
Firmware-5400-V03.22.00-R000.img
Firmware-7X00-V03.22.00-R000.img

Workaround: N/A

95SBX-1037753

Changing the XRM to build ALL media RID’s static IP headers with the “Don’t Fragment” (DF) bit SET TO 0 instead of 1.

Impact: The SBC forwards the DTLS packets correctly but the large certificated packet does not reach the calling device.

Root Cause: The SBC has set the DF (do not fragment) bit in IPv4 header so routers cannot split the packet and it can result in the packet getting dropped.

Steps to Replicate: 

  1. Set up a Inter-work between Full ICE client and ICE Lite call flow with DTLS/SRTP relay.
  2. Caller send out large DTLS packets.
  3. Capture the packets, ensure the DF bit has not set (0x0000).

The code is modified to set the DF bit when the SBC builds the IP header for DTLS and STUN packets.

Workaround: N/A

96SBX-103883 / SBX-103942 2

Portfix SBX-103883 (Originated in Release 9.2.0) A low transcode capacity in 2 VCPU.

Impact: 

  1. The 2 VCPU SWe instance was not coming up in 8.2.3 release.
  2. The transcode capacity in a 2 VCPU instance was very less, only 40-45 calls were supported.

Root Cause: 

  1. There was a merge issue during 7.2.4->8.2.x merge, due to which one constant SESSIONS_SMALL_SWE was missing, so there was a script error and 2 VCPU was failing to come up.
  2. Even though 2 vcpu uses default profile, the capacity of UXPAD is specially handled to have full UXPAD capacity instead of 1/4th of 1 UXPAD capacity.

Steps to Replicate: 

  1. Bring up a 2 VCPU SWe instance in 8.2.3 release.
  2. Check "show table system dspStatus" CLI command and verify available transcode resource. Make a load run till 90% of utilization of transcode channels and verify the packet stats ( pktloss/jitter).

The code is modified to have full capacity of a UXPAD process.

Workaround: No work around is available. Need to pick the build after the fix.

97SBX-1035592

There was a content type pattern match failure in an INVITE sent to the second SBC in a GW-GW call.

Impact: The message body is not sent transparently for Resource/Lists, QSIG Content-Type: multipart/mixed when HTP is enabled for all.

Root Cause: A fix to the SBX-10089 JIRA broke the existing functionality.

Steps to Replicate: 

Testcase Procedure:

TEST SET UP
===========
UAC ==> SBC5xx0 --SBX 5xx0 ==> UAS

Prerequisite:
============

  1. Create the GW-GW set up (SBC-SBC).

Test Specific Configuration:
=========================

  1. Create a header transparency profile on the SBC2 and attach to the egress TG.
    set profiles services transparencyProfile HTP1 sipMessageBody all
    set addressContext default zone ZONE2_TRANSGW sipTrunkGroup PERTRANSGW_SBX_EXT services transparencyProfile HTP1

Test Steps:
==========

  1. Run a basic call over an SBC-SBC call (GW-GW) and check if the resource/lists, QSIG content type header is transparently passed in the outgoing INVITE towards egress side.

Expected Results:

  1.  The SBC-SBC(GW-GW) call should be successful.
  2.  Check if the transparency is successful over the GW-GW.

The code is modified to allow the message body QSIG Content-Type: multipart/mixed, Resource/Lists across GW-GW .

Workaround: N/A

98SBX-1022992

EMS SBC Manager import of SMM remains "In Progress" even if it is completed.

Impact: EMS SBC Manager import of SMM remains "In Progress" even if it is completed.

Root Cause: When a user performs a Start Import operation from the Configuration script and the template import screen, and stays on the same screen, the SBC Manager makes a getStatus API call which reads the status (using platform manager getStatus API) and updates into a map object. If the user switches to another screen (other than the Configuration and profile import/export screen) there will be no issue, but if the operator switches to the Configuration and profile import/export screen which makes platform manager getStatus API call which does not update the a map object. After completion of start import, we read the status from the map and display to the UI.

Steps to Replicate: 

  1. Log in to EMA.
  2. Navigate to Administration -> System Administration -> File Upload.
  3. Upload a CLI file.
  4. Navigate to Administration -> System Administration -> Configuration script and template Import screen.
  5. Select the uploaded the CLI file and click on start import.
  6. Navigate to Configuration and Profile Import/Export screen.
  7. Stay on that page until the START import is complete.
  8. Navigate to Administration -> System Administration -> Configuration script and template Import screen
  9. If the CLI executes successful or failed, we should be able to see the correct status.

The code is modified to make a difference in the EMA call or PM call.

Workaround: N/A

99SBX-1037283

The MS Teams Carrier Trunk MOH fails to resume after a sixth hold.

Impact: The CAC is incorrectly double counting on a call pickup when the SMM invokes a move TG.

Root Cause: During an SMM move of a TG, the call pickup information is lost, resulting in double CAC counting.

Steps to Replicate: 

  1. Run a TEAMS to PSTN call.
  2. Run a TEAMS put call on hold (MOH) more than 6 times.

The code is modified so when the SMM moves a trunk, the call pickup information is moved along with it.

Workaround: None.

100SBX-102714 | SBX-1028762

Portfix SBX-102714 (Originated in Release 9.1.0) 50% of calls are getting dropped after the SBC switchover.

Impact: The stable calls are getting dropped after an SBC switchover with GW-GW set up.

Root Cause: With the introduction of cloud, the slot ID selection was changed to 6th bit from 5th bit, but the GSX and SBC hardware and software still uses 5th bit for slot ID. This was affecting a stable call, when a switchover occurs. There will be a new GW-GW connection. The call info will be exchanged between the GW SBC's. Due to a mismatch in the call info, the detail calls are getting dropped.

Steps to Replicate: 

Scenario 1: The GW_GW link should be up between the D-SBC and GSX.

Scenario 2. Make three SBC_GSX calls.

Scenario 3. After calls are stabilized, run the SBC switchover.

Expected Results: All the calls should be stable after a switchover and properly completed.

By switching back to slot ID to the 5th bit, all flavors of the SBC use the sameslot ID bit.

Workaround: N/A

Resolved Issues in 08.02.02R000 Release 

The following Severity 1 issues are resolved in this release:


Resolved Issues


Issue IDSevProblem DescriptionResolution
1SBX-977601

The SBC was displaying the incorrect Routing info in the GUI and the correct info in CLI.

Impact: The GUI is displaying the incorrect routing information for the routing labels, memory usage, and the zone in the routing label.

Root Cause: Incorrect routing information for the routing labels occurs as few records are fetched for Routing labels list. The EMA application was taking the memory information in a wrong way from the free command.

Steps to Replicate: 

  1. Go to the routing page and create a Routing Label and edit the label.
  2. Correct the Routing label information should be shown.

Platform/Feature: SBC

The code is modified so the call to get routing labels list has no limit and gave the table option to select the Routing Label in route create/Edit form.

Workaround: N/A

2SBX-100592 / SBX-1002491

Portfix SBX-100249: The PRS process core occurred on the Standby Server.

Impact: The PRS process cored due to the XRM accessing a NULL pointer inside of the XRES data structure.

Root Cause: The root problem was that the pkt2 on standby node was stuck in the DOWN state due to possible network switch issue while the pkt2 on active node was functioning as normal. All activated XRESs selected on the LIFs of pkt2 were mirrored to the standby and got inserted in the deferredXresList waiting for standby pkt2 to be UP.
Then when one of those XRESs is reused for a different call and mirror to standby node, that XRES may still stuck in the deferredXresList because the deallocate request may have not been processed yet on the standby node. Then the PRS hit the coredump caused by the XRM accessing the NULL pointer inside of the XRES data structure.

Steps to Replicate: There is an SBC HA pair, an active node has pkt ports all UP, and standby node has at least one of the pkt port DOWN, for example, the pkt1 is DOWN.

Start a fairly high call load and to ensure calls are picking LIFs of pkt1 on an active node in the example, and to ensure XRES on the pkt1 are being re-used.

Note: The standby pkt1 should stay DOWN all the time during the test.

Platform/Feature: SBC

The code is modified to properly free the XRES in deferredXresList so that it can be re-used for the new call.

Workaround: Manually keep the pkt ports sync between active and standby nodes.

3SBX-100105 / SBX-999991

Portfix SBX-99999: The SCM Process coring when surrogateRegistration userPart is configured with 125 character.

Impact: Run the Surrogate Registration scenario with UserName at 127 characters . Then do show status addressContext ADDR_CONTEXT_1 sipActiveGroupRegStatus

Root Cause: Input Buffer is less so its causing a system error

Steps to Replicate: 

  1. Configure surrogate registration with just retry timer and regAuth password. Omit user part and enable the state.
  2. Disable the state.
  3. Configure userpart for ip peer as "SvttEsT$%&=". Enable the admin state of surrogate registration.
  4. Configure userpart for ip peer as "4569$suRR_Reg-/test". Enable the admin state of surrogate registration.
  5. Configure userpart for ip peer as "sip~5u6ser*.*parT%". Enable the admin state of surrogate registration.
  6. Configure maximum allowed characters for userpart which is 127 qwertyuiopasdfghjklzxcvbnmMNASDFGHJKL&2345678sdfghnjmkjukl=
    45+fsadsvydus/uwybwusniwudyw8dbniwu%$wiudnowisopwqmisPQ%,wydwyndwq9h
  7. Configure more than 127 characters for userpart. Enable the admin state of surrogate registration.

Platform/Feature: SBC

Input to StrnPrintf function is calculated based on the size remaining.

Workaround: Run the system in normal mode, it will not coredump. Only coredumps in engineering lab when running in sensitive mode to indicate potential truncation of data.

4SBX-99677 / SBX-993381

Portfix SBX-99338: A SCM process core dump was observed for the challenged invite call.

Impact: A SCM process coredump occurred when running and INVITE challenge call flow.

Root Cause: The buffer is becoming zero, and that is why the system is getting a the System Error and coring in sensitive mode.

Steps to Replicate: Run a call-flow containing challenging of INVITE.

Platform/Feature: SBC

The code is modified for greater than 0 for the formatparamvalue cmd.

Workaround: Run the system in normal mode, it will not coredump. Only coredumps in engineering lab when running in sensitive mode to indicate potential truncation of data.

5SBX-99390 / SBX-989911

Portfix SBX-98991: The AddressSanitizer detected a global-buffer-overflow on address 0x55c93b015fa4.

Impact: While checking for two IPs in the same direct media NAT table the code was reading off the end of an internal buffer.

Root Cause: While trying to process the net mask for the IP addresses the code was using an index of 33 and reading of the end of the internal table with 32 entries.

Steps to Replicate: This issue is only highlighted in the development lab when testing direct media NAT call flows with an ASAN enabled build.

Platform/Feature: SBC

The code is modified to no longer read of the end of the table.

Workaround: N/A

6SBX-99805 / SBX-99791 1

Portfix SBX-99791: The AddressSanitizer detected a heap-use-after-free on address 0x62a000396280 at pc 0x563d8352c45c bp 0x7f03c92740b0 sp 0x7f03c92740a8.

Impact: On a D-SBC set up when disabling the signaling port used for the S-SBC to M-SBC communication and then making further configuration changes it was resulting in invalid memory read.

Root Cause: When the signaling port was disabled, the code was freeing up a list of sockets that were using the port. However it did not set the primary socket pointer to be null when the associated socket memory was freed up. This resulted in an invalid read when trying to re-enable the signaling port.

Steps to Replicate: This issue is only highlighted in the lab when using ASAN enabled images and then disabling the signaling port and making further configuration changes.

Platform/Feature: SBC

The code is modified to ensure that the internal pointer to the primary sock used for the connection is set to null when the socket memory is released.

Workaround: Do not disable the signaling ports.

7SBX-100218 / SBX-1001521

Portfix SBX-100152: A core dump resulted on a basic call (softphone --> Teams) after enabling this flag "usePsxRouteforRegisteredInvite".

Impact: While testing PSTN to MS Teams call flows with surrogate registration and having the configuration flag usePsxRouteforRegistedInvite enabled it was resulting in SYS_ERR for attempt to free an ICM message which had already been freed.

Root Cause: In this particular call scenario the code was re-invoking itself multiple times and then hit a DNS failure. This caused the inner most functionality to free up and ICM message block. However as the stack unwound the initial invocation still had a pointer to the ICM message block and tried to free it.

Steps to Replicate: Make a call from PSTN to Teams without having a DNS server configured.

Platform/Feature: SBC

The code is modified to ensure the ICM message is only freed once.

WorkaroundEnsure the DNS lookups do not fail as this coredump only occurs when running in sensitive mode. Only SYS_ERR will be generated when running in normal mode.

8SBX-99570 / SBX-994571

Portfix SBX-99457: The AddressSanitizer detected the heap-use-after-free on the address 0x6070001153f0 at pc 0x5588611ec65d bp 0x7fbd2d86daa0 sp 0x7fbd2d86da98.

Impact: In an M-SBC deployment when making the M-SBC out of service, the code was accessing memory after it had been freed up.

Root Cause: As part of the deactivation processing, the M-SBC memory block was getting freed up in a child function but the parent function still had access to the pointer and was reading from it on returning back up the stack.

Steps to Replicate: This issue is only highlighted in engineering lab when using ASAN images and taking the M-SBC out of service.

Platform/Feature: SBC

The code is modified to avoid reading from the memory block after it is freed.

Workaround: Do not take the M-SBC out of service.

9SBX-99856 / SBX-997731

Portfix SBX-99773: The ASAN detected an heap-buffer-overflow in Ss7LibGenerateCarrierCode while running an SIP to SIP-I call with PCV header.

Impact: For a Customer ISUP when the code was generating the carrier information transfer (CIT) parameter, it was reading off the end of an allocated memory buffer.

Root Cause: If the PSX does not provide carrier code information to include in the CIT parameter, the SBC was not allocating a large enough memory block. The memory block was used to hold the potential CIT parameter being generated. The SBC was reading of the end of the memory block at the position where the CIT parameter would have been, to decide if a carrier code had been generated.

Steps to Replicate: This issue is only reproduced when running call flows with ASAN images in the engineering lab, it was observed when running regression for ttc-charging parameter in the P-charging-vector header.

Platform/Feature: SBC: Application

The code is modified to avoid reading off the end of the memory buffer.

Workaround: N/A

10SBX-99502 / SBX-985911

Portfix SBX-98591: The SCM process cored for cases when there is an embedded header in 3xx in 7.2.4R0. 

Impact: The SCM process coredumps when there are no generic parameters present in the Embedded Header of the contact in 3xx response message.

Root Cause: The root cause is because the ParamCount being increased even before parsing the parameter.

Steps to Replicate: 

  1. 'Honor embedded headers in 3xx' is enabled in IPTG.
  2. 'forceRequery' is enabled in IPSP.

    Run a SIP-SIP Call.
    Egress INVITE is re-directed with 3xx and Contact header has DTG and embedded Route header and end point's IP.

Platform/Feature: SBC

The code is modified so a new variable RealParamCount is increased when there is a valid parameter.

Workaround: N/A

11SBX-99737 / SBX-979441

Portfix SBX-97944: The ZMQ coredumps on the SLB when changing the common interface from IPv6 to IPv4.

Impact: When the user changes the interface used by the SLB for communications with the SBC's, the SLB may sometimes generate a core dump.

Root Cause: When the interface is changed, the SLB shuts down the existing messaging interfaces and threads that interact with a third-party library called zeromq. This shutdown procedure was not working properly and led to a core dump.

Steps to Replicate: Modify the interface used by SLB to communicate with the SBC's and verify that no core dumps are seen.

Platform/Feature: SBC

The code is modified so the software shuts down the threads on an interface with zeromq so that it is done correctly. 

Workaround: Do not modify the interface used by the SLB to communicate with the SBC's, or do so in a service window to minimize the impact of a potential reboot.

12SBX-99675 / SBX-996101

Portfix SBX-99610: The SBC is coring on the SCM process 3 on a switchover SBX31337.

Impact: The SCM process coredumped while relaying the UPDATE message.

Root Cause: The SBC was dereferencing a NULL pointer and causing the coredump.

Steps to Replicate: Execute a test case where an UPDATE message needs to be relayed through the SBC.

Platform/Feature: SBC

The code is modified to verify the pointer is not NULL before using it, to avoid the problem.

Workaround: N/A

13SBX-100624 1

The trunk group routing does not working when SIP-I call is received.

Impact: The tgrp/trunk-context information in the R-URI and contact headers of an INVITE are not passed to the PSX/ERE as originating and destination trunk group parameters if the INVITE contains the ISUP MIME content.

Root Cause: The parameter were only being processed when there was no ISUP MIME content. There was not a prior requirement for them to be used with ISUP MIME content.

Steps to Replicate: Send an INVITE message to the SBC that contains ISUP MIME contact as well as tgrp/trunk-context parameters in the R-URI / contact header and ensure they appear in the INPUT DATA section of the policy request.

Platform/Feature: SBC

The code is modified to process the tgrp/trunk-context information in the R-URI and contact headers and pass up in the policy request to PSX/ERE.

Workaround: The SMM can be used to convert the tgrp parameters to DTG/OTG parameters that are supported with SIP-I content.

14SBX-995942

The OAM SBC had a failover/switchover.

Impact: There as a recurring random OAM switchovers have been noticed at the customer site.

Root Cause: The VNFR REST message key and/or value may be NULL. This causes the std::string type instantiation to fail and bring down the SBC application.

Steps to Replicate: The problem cannot be reproduced, the issue was fixed based on coredump and core review.

Platform/Feature: SBC

The code is modified to handle the cases where the std::string is instantiated with a NULL value.

Workaround: N/A

15SBX-1004421

The SBC sends a 403 Forbidden message when receiving a Refresh SUBSCRIBE message.

Impact: Initially, the registration is done for the user. The SUBSCRIBE message came from a registered user and subscription is active
When subscription is active, the user got de-registered(or somehow the registration lost). After loss of registration, received a refresh SUBSCRIBE for existing subscription, the SBC is rejecting the refresh SUBSCRIBE saying the user should be registered.

Root Cause: The SBC rejecting refresh SUBSCRIBE when it comes with in a existing SUBSCRIPTION when registration is not available.

Steps to Replicate: 

  1. Register the user.
  2. Send a SUBSCRIBE from registered user.
  3. Cleanup the registration.
  4. Send a refresh SUBSCRIBE for the existing subscription from the same user.

Platform/Feature: SBC

The code is modified that when active subscription is available and registration is lost and then when getting the refresh SUBSCRIBE for the existing subscription, then accept the refresh SUBSCRIBE instead of rejecting it.

Workaround: SBC

16SBX-99034 1

A customer reported an issue in the EMA on the SBC Core 8.2.0R0.

Impact: 

Issue 1:
When creating a Routing Label, you are unable to view more than 15 IP Peers when trying to add a Routing Label Route to it.

Issue 2:
When creating a Route, the interface defaults the Call Parameter Filter Profile field to "CALL_MSG_TYPE_INFO" where as in earlier releases it was defaulting to "none".

Root Cause: By default, it is selecting the first option in the drop down.

Steps to Replicate: 

  1. Log into the EMA.
  2. Navigate to route and routing label screen(Configuration->System->Provisioning-> Routing).
  3. We can verify the issue in the screen.

Platform/Feature: SBC

The code is modified so by default, it shows "none" on the default drop down option.

Workaround: N/A

17SBX-1006501

An INVITE replaces a failure for only a G722 call.

Impact: The REFER call handling fails when only the G722 codec is selected in the packet service profile for all the required routes.

Root Cause: Originally, the SBC/GSX only supported a small subset of codecs Then additional codecs including ILBC and G722 were added in. When these new codecs were added the SBC/GSX started to pass a flag to the PSX that is supported the new codecs. This indicator bit is only being passed up when processing an INVITE and not when processing REFER message. This can result in call failures when processing REFER messages if the Packet service profiles being used for the new egress call leg only support codecs that are not in the list, because the PSX drops any other codecs if the REFER does not indicate that the newer codecs can be supported.

Steps to Replicate: Configure a call flow where the ingress and egress trunk groups only support G722 set up the A to B call and then try to do a REFER to C that should exist on either the ingress or egress trunk group.

Platform/Feature: SBC

The code is modified to pass an indicator to the PSX when processing the REFER that the SBC can support the newer codecs.

Workaround: N/A

18SBX-100161 / SBX-1000631

Portfix SBX-100063: The From header was wrongly impacted by SMM.

Impact: The SMM was adding the duplicated generic parameters in header with the tel scheme.

Root Cause: After the first rule, the treat header as URI, the 2nd rule treat as generic, the SMM format the 2nd rule actions with duplicated generic parameters.

Steps to Replicate: The first rule was testing with URI parameter type. The second rule store the header value into local var and create a new header based on local a local variation.

Platform/Feature: SBC

There were logical error on the second rule when trying to reconstruct the URI header into generic header that added the duplicated generic parameters.

Workaround: Avoid using the URI parameter from the first rule. One may want to use regex instead.

19SBX-1005361

The CLI input time may be delayed in the "V08.02.00R002" environment.

Impact: The SMM Profile, Rules, Criterions and Actions configuration was taking too long in the validation phase to check max limits.

Root Cause: The SMM Profile, Rules, Criterions and Actions configuration was taking too long in the validation phase to check max limits.

Steps to Replicate: Create the max SMMs allowed and test how long it takes as well to check the system Metadata entries. Delete some Profiles and check the entries present and respective Metadata.

Platform/Feature: SBC

The code is modified for the SMM rule, SMM Action and SMM criterions, which will check the cap limit.

Workaround: N/A


The following Severity 2 and 3 issues are resolved in this release:


Resolved Issues


Issue IDSevProblem DescriptionResolution
1SBX-979472

The pathCheck issue occurs when the TLS is in use, the SRV DNS lookup returns the port 5061 and the SBC increments it by 1 when initiating the TLS connection.

Impact: When the pathCheck is enabled on a FQDN based ipPeer, and the TLS transport is specified, the port number returned by the DNS SRV query for the TLS (_sips._tcp) is incremented by 1 causing the wrong port number to be used.

This problem only effects the transmission of the PATHCHECK OPTIONS pings when the TLS transport is specified, and the port number is obtained by DNS SRV query for TLS. There is no direct effect on SIP calls.

Root Cause: The SCM process incremented the port number passed to it by the PATHCHECK
when it should not have, in the case where the port number was obtained by a DNS SRV query for "_sips._tcp" (TLS).

Steps to Replicate: Define a pathCheck profile with the TLS as the transport preference:

Platform/Feature: SBC

The code is modified so that the port numbers obtained by a DNS SRV query for "_sips._tcp" (TLS) are not incremented.

Workaround: Configure the FQDN based ipPeer's pathCheck hostPort to the appropriate port number.

2SBX-980042

The M-SBC crashed due to memory congestion with no memdump/core.

Impact: Observed the resource memory congestion level 3 is approaching the threshold 90 sample 80 at the M-SBC.

Root Cause: When the Link detection is configured, the raw sockets are created to exchange the ICMP pings on an active port and ARP probe messages on the standby port.

Whenever a port switchover is initiated, these sockets are closed and re-opened as the role of the port changes.

Due to a bug in the code, these sockets were not getting closed and new sockets were opened. This leads to a memory leak due to stale sockets under the constant port toggling condition and eventually lead to a memory congestion.

Steps to Replicate: Create a link detection group with the link monitors configured on both ports in redundancy group.

Add the ACL to drop ICMP packets from the destination configured in Link Monitor. This results in constant port switchovers.

Platform/Feature: SBC: Call Control

The code is modified to make a standard system close () instead of the ACE close() to close the socket upon a port switchover.

Workaround: N/A

3SBX-1003312

After adding the second mgmt port in the 23vcpu ISBC (in RHEV platform 8.2.1 build), pkt and mgmt port messes up.

Impact: On adding the extra management port in the large instance without redundant PKT ports, SWe_NP process crashes.

Root Cause: A bug in the code polled a non-existent port id on adding the extra management port resulting in a crash.

Steps to Replicate: Make a large instance >15vCPU(default profile) without the redundant packet ports.
Add the extra management port and reboot.

Platform/Feature: SBC: Platform

The code is modified to fix the polling of extra management interface for large instances case in SWe_NP code.

Workaround: N/A

4SBX-985802

A response for the OPTION message received from TEAMS does not have a domain name in contact.

Impact: The contact header sent in the 200 OK response to out-of-dialog OPTIONS message in MS Teams Zone contains an IP address. It should contain a FQDN.

Root Cause: The Out-of-dialog OPTIONS message received in the MS Teams Zone.

Steps to Replicate: Send an Out-of-dialog OPTIONS message in the MS Teams Zone.

Platform/Feature: SBC: MS Teams

The code is modified to populate the zone domain into the contact header of a 200 OK.

WorkaroundUse the example SMM at the link below to work around the issue.

5SBX-954552

Unable to change the username of a configured AD Domain Controller through the EMA.

Impact: When creating a domain controller from the EMA, the username validation was failing for the special characters because of being unable to create a domain controller.

The CLI was accepting the special character for the username and was able to create a domain controller.

Root Cause: The username validation was failing because the username param was not part of the netconf request and the netconf was throwing error.

Steps to Replicate: TBD

Platform/Feature: SBC

The code is modified so the EMA validates the username param based on default regex that is in the yang file.

Workaround: N/A

6SBX-99650 / SBX-956792

Portfix SBX-95679: There are no trunks data on the live monitor.

Impact: The Zone and Trunk Group based live monitor charts does not show any data if the trunk group name contains a hyphen.

Root Cause: The Elastic Search interprets a 'hyphen' as a delimiter and as a result the string is broken down into tokens for indexing.

When querying the ElasticSearch for data with trunkgroup name containing 'hyphen', no data is retrieved as the Elastic Search has stored the data not with the actual trunkgroup name but with tokens.

Steps to Replicate: 

  1. Create a trunkgroup with the name containing hyphen.
  2. Enable the Live Monitor.
  3. Run calls and wait for sometime.
  4. Verify data is shown in the Zone and Trunk Group based charts

Platform/Feature: SBC

Before querying the ElasticSearch for data, check if the trunkgroup name contains a hyphen, if it does then it is broken into tokens and the token is used to query for data.

Workaround: N/A

7SBX-99498 / SBX-969532

Portfix SBX-96953: Investigate the PATHCHK process coredump.

Impact: The Pathcheck process may coredump (due to healthcheck timeout) when the zone tracerouteSigPort is enabled, and the traceroute takes longer than 45 seconds to complete (after the endpoint becomes BLACKLISTED).

Root Cause: The Pathcheck process coredumps due to a healthcheck timeout when the traceroute to the BLACKLISTED endpoint takes longer than 45 seconds to complete.

Steps to Replicate: Enable the zone tracerouteSigPort, and configure an ipPeer in that zone that will the become BLACKLISTED, and the traceroute to that ipPeer takes minutes to complete.

Platform/Feature: SBC

The code is modified to handle slower/longer traceroute completions.

Workaround: N/A

8SBX-99712 / SBX-962552

Portfix SBX-96255: The leakSanitizer detected memory leaks in the SipDialogResizeRouteSetCmd.

Impact: Detected a memory leak in SipDialogResizeRouteSetCmd when running a Subscribe Notify call flow.

Root Cause: The SipDialogResizeRouteSetCmd will cause a memory leak in the case of an error scenario.

Steps to Replicate: This issue is only reproducible when using ASAN images in engineering lab.

Platform/Feature: SBC

The code is modified to fix the memory leak in this function.

Workaround: N/A

9SBX-99682 / SBX-983192

Portfix SBX-98319: The AddressSanitizer detected heap-use-after-free in the MrfRmCallControlBlock.

Impact: Heap after free memory use is deleted when running the MRF Regression.

Root Cause: Free the mrfrmCcb in the OANULL::ntwkDiscHndl, as we access the mrfrmccb in mrfRmCallFsm.

Steps to Replicate: This issue is only reproducible when using ASAN images in engineering lab.

Platform/Feature: SBC

The code is modified not to free the MrfRmCcb in OANULL::ntwkDiscHndl, but setting a Destoy_ccb bit.

Workaround: N/A

10SBX-100041 / SBX-975762

Portfix SBX-97576: ERROR: The LeakSanitizer detected memory leaks at the SipDialogEnablePDUTrace.

Impact: There is a leak detected when running a Video Regression.

Root Cause: The memory is being allocated without checking whether it is allocated before or not.

Steps to Replicate: This issue is only observed when running call flows with ASAN images in the engineering lab.

Platform/Feature: SBC

The code is modified to free memory before allocating the new memory.

Workaround: N/A

11SBX-99741 / SBX-991582

Portfix SBX-99158: The CDR records for 230 and 231 subfields are not getting populated in the Video in bundle with rtcp-mux and ICE scenario.

Impact: In certain call scenarios with bundled media streams, when the additional streams are added to the existing bundle this results in the SBC media not being configured correctly, resulting in the call CDR STOP record not showing correct data for fields.

230. Media Stream Data - All the media streams data.

231. Media Stream Statistics - All the media streams statistics.

Root Cause: The policer mode for a bundle slave stream was not coded with the correct default value.

In the SBC release 8.1.0, additional validation checks were added to reject media configuration if the policer mode did not have the expected value, this resulted in media configuration failing when bundle slave stream is added.

Steps to Replicate: Testcase Procedure:

set iceSupport iceWebrtc
set sdpAttributeSelectiveRelay enabled

  1. Initiate a call with Video in a bundle with rtcp-mux and ICE.
  2. Response from farside accepts the offer with Video as part of the bundle.
  3. Send STUNs for the master Video stream for RTP only.
  4. Send a re-INVITE adding a audio stream to the bundle.
  5. Response from farside accepts the stream.
  6. Send a re-INVITE adding a slides stream to the bundle.
  7. Response from farside accepts the stream.
  8. Clear the call and check CDR stop record.

Expected Results:

Validate Bundling happens:

  1. INVITE contains bundle with Video.
  2. 200 OK from SBX contains Video in a bundle with rtcp-mux and ICE.
  3. ICE Completes for all streams on both sides.
  4. INVITE sent out with Audio and Video in a bundle with unique port and ICE information.
  5. Response sent with Audio and Video with matching bundle information.
  6. INVITE sent out with video+audio with matching bundle information and slides with unique port and ICE information.
  7. Response sent with Video+Audio+Slides with matching information
  8. CDR stop record should have sub-fields for fields 230 and 231 correctly populated.

Platform/Feature: SBC

The code is modified to set the correct default policer mode for bundled streams.

Workaround: N/A

12SBX-99714 / SBX-572002

Portfix SBX-57200: Implement the EMA Solution for the SBX-56878 issue: the CDR Viewer and Live Monitoring cannot be enabled/disabled.

Impact: Due to Red-Indices, the CDR Viewer and Live Monitoring cannot be enabled/disabled.

Root Cause: Due to Red-Indices, the CDR Viewer and Live Monitoring cannot be enabled/disabled.

Steps to Replicate: 

  1. Have a Red-Indices file.
  2. Try to enable/disable(Change state) of Live Monitor and CDR Viewer.
  3. Wait for scheduler to execute check if red-indices file deleted.
  4. Try to change the state.

Platform/Feature: SBC

The code is modified to check and delete if any Red-Indices present. Handle the class instead throwing exception, it catches.

Workaround: N/A

13SBX-100245 / SBX-999512

Portfix SBX-99951: When sending a message to the egress side, the SBC is sending a MIME-Version twice.

Impact: When the Mime Header is received along with the multipart method, the MIME header is going twice in the outgoing Message Method when the transparency is enabled.

Root Cause: The Two Headers are going to 1 because of Transparency and another one added by the SBC.

Steps to Replicate: Run a Subscribe call flow with the Multipart body and transparency enabled for Mime-Version header.

Platform/Feature: SBC

When the Multipart body is present, do not add header by transparency.

Workaround: The SMM can be used to remove duplicate header.

14SBX-100271 / SBX-986782

Portfix SBX-98678: The RE-INVITE for a 200 OK from the SBC is having two different m-lines with the sendonly for audio and sendrecv for video during a DM call.

Impact: The Re-INVITE for 200 OK from the SBC is having two different m-lines with the sendonly for audio and sendrecv for video during a DM call.

Root Cause: Due to some code in the SIPSG that blindly overwrites the video dpm to SEND RECV.

Steps to Replicate: 

Call flow:

  1. The initial call flow is pass thru A↔B.
  2. A transfers to C (Direct Media call from here)
  3. B sends hold to C by sending a=inactive and c=0
  4. B sends late media re-invite w/o SDP to C
    -> While responding locally to a late media re-INVITE, the SBC blindly copies
    DPM=SEND_RECV for video, which creates this inconsistency as audio is sent
    out by the SBC as per last SDP negotiated on that leg (that is inactive)
    but video=sendRecv always.

TEST CASES:

Enabled the latemedia pass through / e2e re-invite &e2e ACK flags(Tested both pass thru and DM calls by sending audio&video DPM as inactive/sendrecv)

case1:- SVT scenario

  1. SBC responds with inactive for both audio/video in response to late media re-Invite.

case2:- SVT scenario with following changes:

  1. After xfer, during HOLD, instead of inactive, B uses sendOnly with valid c-line IP to put call on HOLD.
  2. Party C responds with recvOnly to this HOLD INVITE.
  3. The SBC sends 2xx with recvOnly for both audio/video to Party B.
  4. Party B sends late media re-Invite.
  5. The SBC responds with recvOnly for both audio/video.

case3:- SVT scenario with following changes:

  1. a. After xfer, not sending any HOLD INVITE. Basically call continues as SEND_RECV DM call.
  2. Party B sends late media re-Invite.
  3. The SBC responds with SEND_RECV for both audio/video.

Platform/Feature: SBC

The code is modified so that if the condition only if the coreaudio Dpm also SEND_RECV.
It changes video DPM to SEND RECV only if the core audio DPM also SEND RECV.

Workaround: N/A

15SBX-100466 / SBX-1004142

Portfix SBX-100414: The Q.850 reason was cause a mapping issue.

Impact: When a invalid cause=parameter is received in Reason: Q.850 header, the SBC accepts an invalid cause value and converts into a valid value.

This results in incorrect cpc to the SIP causes a mapping and impact SIP messaging on other leg.

Root Cause: The SBC incorrectly validates the cause= parameter in the Q.850 reason header.

Steps to Replicate: 

  1. Send 600 Busy Everywhere from egress endpoint with cause = 600:

    Reason: Q.850;cause=600;text="Busy Everywhere"

    Due to a bug, the SBC maps invalid cause value 600 to 88 ( 0x58 )
    and when mapping CPC to SIP, the SBC sends 503 to the Ingress side.

  2. Verify the issue by using the same scenario.

The SBC sends 486 Busy Here to ingress as invalid Q.850 cause code is ignored.

Platform/Feature: SBC

The code is modified to ensure the SBC correctly validates cause= parameter in Reason header.

Workaround: Use the SMM to filter our Reason header with an invalid Q.850 cause parameter.

16SBX-100244 / SBX-1000752

Portfix SBX-100075: The AddressSanitizer detected a heap-use-after-free on address 0x6230000e31dc at pc 0x560c37742937 bp 0x7f62795d68d0 sp 0x7f62795d68c8.

Impact: In case of a scenario where the INVITE is rejected because it received more than 10 Route Headers, then the pstCall will be freed as a result, but application will still be using that pointer.

Root Cause: The pstCall is getting freed, but the pointer is not setting to null.

Steps to Replicate: This can be reproduced in house with ASAN Build.

Platform/Feature: SBC: SIP

Set the pstcall to NULL after freeing the call.

Workaround: N/A

17SBX-100260 / SBX-965672

Portfix SBX-96567: The AddressSanitizer detected a stack-buffer-overflow on address 0x7ff4a63c0da0 at pc 0x562fdc55b9f7 bp 0x7ff4a63c0c30 sp 0x7ff4a63c0c28.

Impact: An invalid read of 1 Byte is occurring when the SBC is trying for SRTP license.

Root Cause: The freed memory is being accessed after sending memory to the stack.

Steps to Replicate: This issue is only reproducible when using ASAN images in engineering lab.

Platform/Feature: SBC

The code is modified so that freed memory is not being accessed.

Workaround: N/A

18SBX-99718 / SBX-961472

Portfix SBX-96147: The AddressSanitizer detected a heap-use-after-free on the address 0x60400047f020 at pc 0x561f45771c9f bp 0x7f4227923c60 sp 0x7f4227923c58.

Impact: The heap-After Free memory is getting used in a scenario where the INVITE is getting rejected in UasReceiveCallCmd().

Root Cause: In case of the failure in the uacReceiveCallCmd, there may be error response sent.

When an error response is sent, a To Tag needs to be sent that is allocated in pstCall, so the pstCall must not be freed before sending that response.

Steps to Replicate: This issue is only reproducible when using ASAN images in engineering lab.

Platform/Feature: SBC

The code is modified not to free a pstCall in this case until an error response is sent.

Workaround: N/A

19SBX-99363 / SBX-990212

Portfix SBX-99021: The "Tag_From" is not added in the first 2xx response for Subscribe in the Ingress side of the SBC.

Impact: The Dialog Scope Variables are not working in case of a Subscribe Crank back scenario because of the From Tag Changes.

Root Cause: The From Tag is not being Updated in the dialog scope variable.

Steps to Replicate: 

  1. Create the SMM Profile 'Dialog_Variable'.
  2. Attach the SMM Profile as an Input and Output Adaptor Profile to the Ingress side of the SBC.
  3. SUBSCRIBE message is sent from UAC to the SBC.
  4. The SBC forwards to egress UAS (first route).
  5. The UAS1 sends 408 (first route).
  6. The SUBSCRIBE message is crankback to 2nd route which is in another Trunk group.
  7. The UAS2 will send 2xx to complete the subscription.

Platform/Feature: SBC

The code is modified to update the From Tag in the dialog scope variables.

Workaround: N/A

20SBX-100101 / SBX-997612

Portfix SBX-99761: The SBC stops running after this customer call flow.

Impact: Run a DLRBT and Downstream forking scenario where the Update is received from the Egress after the cuttru done.

Root Cause: De-allocating the memory but not setting a pointer to NULL.

Steps to Replicate: The DLRBT is enabled, the PRACK on both legs, the Forking was enabled for a non-forked call, UPDATE with the codec change received from Egress after 180, firstRtp - SR.

EXPECTED RESULT: The call should run successfully.

ACTUAL RESULT: The SBC stops running after receiving update (the SBC automatically restarts).

Platform/Feature: SBC

The code is modified to set the TempResponse to NULL.

Workaround: N/A

21SBX-99692 / SBX-985542

Portfix SBX-98554: The AddressSanitizer detected the heap-use-after-free on address:

0x630000850478 at pc 0x5566fba3b8ef bp 0x7f920ade3b50 sp 0x7f920ade3b48 READ

of size 1 at the 0x630000850478 thread T9.

Impact: The Heap Use after freeing memory is getting used in a scenario when the Initial INVITE is getting rejected because of the validation of route headers.

Root Cause: The SBC is accessing the To Tag from the freed pstCall Memory.

Steps to Replicate: This issue is only reproducible when using ASAN images in engineering lab.

Platform/Feature: SBC

The code is modified to not free that memory until the error response is sent.

Workaround: N/A

22SBX-100247 / SBX-997482

Portfix SBX-99748: The AddressSanitizer detected a heap-buffer-overflow on address

0x6060007e96d0 at pc 0x55c8b4f2b47b bp 0x7efe153ce020 sp 0x7efe153cd7d0 READ

of size 1 at 0x6060007e96d0 thread T9.

Impact: This issue is only reproducible when using ASAN images in engineering lab. The issue occurs on the SIP-I call where we access 18x msgHandle after freeing the memory.

Root Cause: The MsgHandle being used is already free.

Steps to Replicate: Run a SIP-I call in an ASAN Build.

Platform/Feature: SBC

The code is modified so moves above the problem causing code.

Workaround: N/A

23

SBX-97804 / SBX-99196 

2

Portfix SBX-99196: There was an incorrect FQDN routing.

Impact: There was an incorrect FQDN routing occurring that caused calls to route to the wrong destination.

Root Cause: This is occurring in some cases where the retransmitted DNS transaction id of earlier transaction matches with the existing transaction. This causes records to save for the incorrect FQDN.

Steps to Replicate: This problem could only be reproduced in the engineering lab by changing the code to force the issue.

Platform/Feature: SBC

The code is modified so whenever the DNS reply is processed, the FQDN matches what is received in the DNS reply and stored in a transaction.

Workaround: N/A

24SBX-100266 / SBX-999272

Portfix SBX-99927: The SBC is adding extra characters in a display name when the ingress INV contains the display name of length more than 55 characters in a GW-GW scenario.

Impact: When an INVITE has the PAI header with display name more than 55 characters is passed transparently on  the GW-GW, the SBC appends the username to the PAI displayname on the egress.

Root Cause: While reading the PAI header out of the message, the SBC allocates size of 48 characters for displayname on a flat buffers, but copies more than 48 characters.

The username is allocates from the same memory buffers starting from offset + displayname size and overwriting the display name NULL terminator with username.

Steps to Replicate: Send an ingress INVITE with PAI header containing displayname length more than 55 characters transparently on GW-GW.

Platform/Feature: SBC

The code is modified to only copy maximum of 48 characters into the PAI displayname buffer and strip down the rest.

Workaround: N/A

25SBX-100315 / SBX-1003072

Portfix SBX-100307: The ASAN detected a heap-buffer-overflow in SipFeDumpPdu (SipFeProcessSlbIncomingPdu).

Impact: The SIPFE was reading invalid memory while printing sent PDUs.

Root Cause: When the SIPFE module was printing SIP PDU content to the DBG log it was reading past the end of the PDU memory buffer.

Steps to Replicate: This problem can only be observed when using ASAN images in the development lab.

Platform/Feature: SBC

The code is modified to avoid reading past the end of the SIP PDU to avoid accessing invalid memory.

Workaround: Disable the info level logging.

26SBX-99728 / SBX-653932

Portfix SBX-65393: Calls fail after deleting an unrelated ingress IP prefix within a zone.

Impact: If the SBC is provisioned as follows, TGs within a zone are provisioned with duplicate ingressIpPrefix and one of the ingressIpPrefix has an invalid format.

When the duplicate ingressIpPrefix is deleted, calls to TGs that should have matched the ingressIPPefix fail.

Root Cause: The CLI was not rejecting an invalid ingressIpPrefix from being provisioned by the user.

Steps to Replicate: 

  1. Create a TG with ingressIpPrefix 0.0.0.0/0 (Named EXT).
  2. Verify ingress calls are selecting the correct ingress TG (EXT).
  3. Create second TG with ingressIpPrefix 10.1.1.1/0 (Named TEST_TG).
  4. Calls will still find the correct TG i.e. EXT, SBX will not use TEST_TG.
  5. Delete second TG’s ingressIpPrefix of 10.1.1.1/0 (i.e. TEST_TG ingressIpPrefix).
  6. Calls fail to find correct TG (EXT) now, the only TG with 0.0.0.0/0 ingressIpPrefix because the backend code does not have the 0.0.0.0/0 prefix to EXT mapping.

Platform/Feature: SBC: Call Control

The code is modified to reject invalid ingressIPPefix formats and to protect the SBC from users entering an invalid ingressIpPrefix.

Workaround: Do not add or delete invalid ingressIpPrefixs. Industry acceptable format of ingressIpPrefix needs to be entered in the CLI. 

27SBX-99970 / SBX-999642

Portfix SBX-99964: The AddressSanitizer detected a heap-use-after-free on nrmaMsgProc.c when running DSBC REFER.

Impact: While the SBC was processing resource allocation messages associated with DTMF relay handling it was allocating memory after the memory is freed up.

Root Cause: This is a day 1 issue and not known to cause any problems in the field. While generating a DBG log message, the code was trying to print the contents of a message block immediately after the block had been freed.

Steps to Replicate: This issue can only been reproduced in the lab while running with ASAN images.

Platform/Feature: SBC

The code is modified to no longer access the message content after processing the message to avoid accessing the memory after it is freed up.

Workaround: N/A

28SBX-99934 / SBX-996472

Portfix SBX-99647: There are XRM SBX_GoalwoPolicy coverity issues.

Impact: While processing the signaling port configuration the, the lifGroupId value was being read as a 32 bit value into a 16 bit storage location causing memory to be overwritten.

Root Cause: The code was using the wrong API to read the configuration resulting in potential memory corruption.

Steps to Replicate: This issue can only be reproduced using ASAN images in the engineering lab.

Platform/Feature: SBC

The code is modified to only read the lifGroupId as a 16 bit value.

Workaround: N/A

29SBX-99973 / SBX-998142

Portfix SBX-99814: The AddressSanitizer detected heap-buffer-overflow on the address:

0x60b0007c994a at pc 0x55758a639756 bp 0x7f1b8e3cd9a0 sp 0x7f1b8e3cd998

Impact: When the SBC is running as the T-SBC, it was reading invalid memory.

Root Cause: When the SBC is running as the T-SBC it was incorrectly reading off the end of the resource allocation message because it was reading information which is only present for the M-SBC.

Steps to Replicate: This issue is only observed when running with ASAN issues in the engineering lab.

Platform/Feature: SBC

The code is modified to verify whether the resource response message is for the M-SBC before trying to access the specific M-SBC information.

Workaround: N/A

30SBX-99314 / SBX-992262

Portfix SBX-99226: The AddressSanitizer detected an global-buffer-overflow error observed on:

SipSgRedirectedInviteHandleEmbeddedRepeatableUriHdrs

when sending embedded header in 3xx.

Impact: For a STIR/SHAKEN as a service call flow where PSX returns 3xx with embedded identity and PAI headers, the SBC was reading off the end of an internal buffer while trying to confirm of the embedded headers where "known" headers.

The issue would exist for other 3xx scenarios with embedded URI headers.

Root Cause: The name of a header was missed in one array, although the count of headers was correctly updated and this caused the code to read off the end of the names buffer.

Steps to Replicate: This issue is only highlighted in engineering lab while testing with ASAN enabled images.

  1. Made a signing call using PSX as Redirector (STIRaaS).
  2. The PSX sends 300 Multiple Choice.
  3. 300 Multiple header has embedded parameters.
  4. The SBC does a full dip to construct redirect INVITE.

Platform/Feature: SBC

The code is modified to ensure the internal buffer contains all the correct header names.

Workaround: N/A

31SBX-99694 / SBX-987962

Portfix SBX-98796: The AddressSanitizer detected a heap-buffer-overflow on the address:

0x6150043d0258 at pc 0x55c7b4ebab3c bp 0x7f6f282a51a0 sp 0x7f6f282a4950 READ

of size 432 at 0x6150043d0258 thread T8.

Impact: The HPC/GETS related call flows are resulting the code reading off the end of an internal memory block.

Root Cause: While processing HPC/GETS related calls the code was allocating an ICM message based on the size of 3 structures and then trying to copy it based on the size of 4 structures resulting in reading off the end of the memory block.

Steps to Replicate: The problem is only highlighted when running the HPC / GETS related call flows in the engineering lab with ASAN images.

Platform/Feature: SBC

The code is modified to allocate the correct amount of memory to avoid the issue.

Workaround: N/A

32SBX-99317 / SBX-984642

Portfix SBX-98464: The AddressSanitizer detected a heap-buffer-overflow on the address:

0x61100004c2a8 at pc 0x563b72b7b8cc bp 0x7f93b1edeff0 sp 0x7f93b1ede7a0 READ

of size 692 at 0x61100004c2a8 thread T9.

Impact: The SBC is reading of the end of the internal buffer when trying to pass STIR/SHAKEN information back to the ingress side of the call as part of the feature SBX-98464.

Root Cause: The code was storing the STI information that the PSX returned and did not take into an account, the scenario where the PSX returned an identity header that meant the parameter when signing was bigger then verification.

When it later tried to add the parameter into the backward messages, it was reading off the end of the memory buffer.

Steps to Replicate: This issue is only observed when using ASAN images in the engineering lab and running STIR/SHAKEN test with signing enabled and the PSX returns an identity header to include in the outgoing INVITE.

Platform/Feature: SBC

The code is modified to allocate the correct amount of memory to avoid reading off the end of the buffer.

Workaround: N/A

33SBX-100084 / SBX-1000682

Portfix SBX-100068: The SLB was going down after triggering a DBL entry for the event epCacAggrReject.

Impact: The SLB was reading invalid memory.

Root Cause: When the SLB was printing SIP PDU content to the DBG log, it was reading past the end of the PDU memory buffer.

Steps to Replicate: This problem can only be observed when using ASAN images in the development lab.

Platform/Feature: SBC

The code is modified to avoid reading past the end of the SIP PDU to avoid accessing invalid memory.

Workaround: N/A

34SBX-99425 / SBX-955842

Portfix SBX-95584: The LeakSanitizer detected memory leaks at at packet handler.

Impact: While reading the configuration data, the SBC was overwriting stack memory and also leaking small amounts of memory.

Root Cause: A number of fields in the SBC configuration where defined as boolean, however confd had implemented these as integers.

When reading the contents from CDB, the local variable store defined as boolean was not large enough to hold the configuration value and resulted in memory being overwritten.

While the SBC was processing configuration data for users and groups it was not freeing up all the memory that was allocated, resulting in a leak.

Steps to Replicate: These problems can only be reproduced in the development lab while testing with ASAN image.

Platform/Feature: SBC

The code is modified to use the correct size of local variable to avoid memory being overwritten.
The code is also modified to correctly free memory to avoid leaks.

Workaround: N/A

35SBX-99224 / SBX-983572

Portfix SBX-98357: The LeakSanitizer detected memory leaks at PathchkPingSessionAddEntry.

Impact: When making configuration changes to an existing path check object, it was causing a small memory leak.

Root Cause: As part of the modify logic, the code was reallocating a memory block and it was not freeing up the memory block that was allocated when the configuration was originally created.

Steps to Replicate: This problem was highlighted in engineering lab while running with ASAN images to highlight memory leaks and then making path check configuration changes.

Platform/Feature: SBC

The code is modified to correctly free the memory block as part of the update logic.

Workaround: Delete and recreate the path check configuration rather and modifying it.

36SBX-100252 / SBX-1000172

Portfix SBX-100017: While expecting an UPDATE, the SBC sending 503 to ingress side.

Impact: If the toneAsAnn is enabled, do not go for the DSP allocation for playing tones. But the SBC trying to allocate the DSP resource and fails.

Root Cause: A new flag introduced as part of other feature "end2endtonemodify" that overrides "toneAsAnn" flag.

Steps to Replicate: 

  1. The SBC configured to play tone. The toneAsAnn is enabled.
  2. Egress has sent 18x with the SDP, the SBC plays tone towards ingress.
  3. Ingress modify update is received. Then the SBC will handle the update and send to egress.

Platform/Feature: SBC

The "toneAsAnn" flag is given higher priority than "end2endtonemodify" flag.

Workaround: SBC

37SBX-99725 / SBX-965002

Portfix SBX-96500: The SMM Testing tool does not work.

Impact: The SMM test tool is not parsing through the selected profile.

Root Cause: The profile index value was incorrect, so it was picking the wrong profile index and the message was unaltered by SMM.

Steps to Replicate: When testing the same SMM in 7.1 code for example (with the same INPUT message), the test is successful. 

(Go to Test SMM for SBX-96500 for SMM details)

Platform/Feature: SBC

The code is modified to contain the correct profile index.

Workaround: N/A

38SBX-100095 / SBX-1000162

Portfix SBX-100016: The SBC does not forward 18x towards ingress leg after the egress precondition interworking is met.

Impact: In case of egress pre-condition, the UPDATE is generated even before response for PRACK is received. In such a case, where the UPDATE is triggered once response for PRACK is received, the 18x that is received from egress after preconditions is met, is not sent towards ingress.

Root Cause: The root cause is because of timing issue.

Steps to Replicate: 

  1. Make a call with SDP attribute "a=sendonly" or "a=recvonly" in the INVITE from UAC.

Platform/Feature: SBC

The code is modified to handle such timing issues and send the 18x towards ingress after preconditions is met.

Workaround: N/A

39SBX-99007 / SBX-945062

Portfix SBX-94506: The Data Path mode is always 'a = sendonly'.

Impact: Whenever the SRS put SIPREC call on hold with a=inactive, the SBC always acknowledged SIP 200 OK with a=sendonly.

Root Cause: A SIPREC call hold done by the SRS was not identified in terms of Signalling properly at the SBC.

Steps to Replicate:

  1. The main call is stable.
  2. The SRS put the call on hold by generating SIPREC REINVITE with a=inactive.
    Expected and Observed Behavior:-
    The SBC to respond 200 OK towards SRS with a=inactive.

Platform/Feature: SBC

Identified the CALL HOLD scenario that triggered by an SRS due to generation of RE-INVITE with a=inactive through appropriate CALL Hold Flag value for SIPREC.

Workaround:

40SBX-99727 / SBX-858522

Portfix SBX-85852: "Timeout detected – Forcing the read/write access during the switchovers.

Impact: The message "Timeout detected -- Forcing read/write access" is observed during switchovers.

Root Cause: This message is logged on NBI timer expiry (after 2mins) and config changes were allowed before DBs are in sync. This would happen when standby initialization takes longer.

Steps to Replicate: Install the SBC with the fix build and perform switchover. Ensure there is no timeout message and config changes are allowed only after configuration and Policy DBs are in sync.

Platform/Feature: SBC: Platform

The code is modified to allow configuration changes only when both the CDB and oracle DB are available for READ_WRITE and sync is completed.

Workaround: N/A

41SBX-99489 / SBX-943752

Portfix SBX-94375: The IpPeer authPeer fails to delete.

Impact: When the IPPeer modified either the zone/port/ip, the old authPeer data structure is not deleted.

Root Cause: There was a memory leak.

Steps to Replicate: 

  1. Create an IPPeer with port aaaa.
  2. Change the IPPeer with different port bbbb.
  3. Change the IPPeer back to port aaaa.
  4. Call may fail.

Platform/Feature: SBC: Provisioning

The code is modified to delete the old data structure.

Workaround: Delete the ipPeer and create a new one (not modify).

42SBX-99695 / SBX-945882

Portfix SBX-94588: The LSWU will fail/stall due to upgrade out permissions.

Impact: The LSWU would fail if the upgrade out file permissions are incorrect.

Root Cause: Permission of staging files were not being properly updated during the pre-upgrade checks, and failing to execute upgrade script if the permissions are incorrect.

Steps to Replicate: Perform the LSWU to the fix build and verify that upgrade is successful.

Platform/Feature: SBC: LSWU

The code is modified to properly update permissions of staging files during pre-upgrade checks so that the upgrade script executes successfully even if initial permissions are incorrect.

Workaround: N/A

43SBX-99823 / SBX-993612

Portfix SBX-99361: The customer SBC has a memory leak.

Impact: There is a bug in the “clearTcpConnectionsforRegistration" functionality that causes a memory leak.

Root Cause: This code that handles the clearTcpConnectionsforRegistration flag is allocating memory to store Hostname and Username, but it never freeing this memory.

Steps to Replicate: Set up the customer configuration with the “clearTcpConnectionsforRegistration” flag set.
Able to reproduce the leak by running load with Registrations and de-Registrations.

Platform/Feature: SBC

The code is modified to free the memory that is allocated to store Hostname and Username.

Workaround: N/A

44SBX-99820 / SBX-982002

Portfix SBX-98200: There was a SCM process memory leak (SIPSG), not freeing pSbyRcb→pcrfInfo.

Impact: Leaking PCRF related structures on the standby when processing the Registrations, if PCRF is configured on Trunk Group.

Root Cause: Memory that was allocated for the PCRF related structures is not being freed as part of de-registration processing.

Steps to Replicate: 

  1. Configure the pcrfCommitment to something other than none.
  2. Set the pcrf_signallingPath to enabled.
  3. Set the pcrf_provSignalingFlow to enabled.

Platform/Feature: SBC: SIP

The code is modified to free the memory that is allocated for PCRF related structures as part of de-registration processing.

Workaround: The workaround is to set pcrfCommitment to none.

45SBX-99746 / SBX-974332

Portfix SBX-97433: The bondingDevice0 port status was showing as noSignal.

Impact: The CLI highAvailabilityPort status command shows the OOS reason as “noSignal” for port bondingDevice0 even though it is up.

Root Cause: There was a code to check bond0 device status and parse the output required a fix.

Steps to Replicate: Install the fix build and run the CLI command "show table system highAvailabilityPort status" to ensure the OOS reason is displayed correctly.

Platform/Feature: SBC

The code is modified to ensure the proper display of an OOS reason in highAvailabilityPort status command.

Workaround: N/A

46SBX-100064 / SBX-755632

Portfix SBX-75563: The port number was in the DBG log.

Impact: For non-UDP calls, the peer IPs of all status messages sent from the SBC to the UAC in TRACE log will be displayed through the header's IP.

The messages themselves are sent to the right IP, that sent the request message to the SBC.

Root Cause: The original code overwrites the SipMsg's peerIp with through header. The PeerIp will be used to print in the trace log.

Steps to Replicate: 

  1. Set up TCP calls, and TLS calls.
  2. Make VIA header's IP different from UAC IP.
  3. Make the call, collect the TRC log. DBG log could be also collected as debug tool.
  4. Ensure that all out going msg are sent to right IP:Port in displayed in TRC log.

Platform/Feature: SBC: Platform/Media Services, SIP

The code is modified so for the non-UDP calls (TCP and TLS calls, SipMsg's peerIp) set to the source IP.

Workaround: N/A

47SBX-99583 / SBX-995152

Portfix SBX-99515: The X2 messages do not have the timestamp set correctly.

Impact: In Default LI, the X2 message does not have milliseconds in the time stamp captured as part BCID avp.
Without a fix, milliseconds in the time stamp field will be 000 and time stamp field will look like "Event Time: 20200429190440.000"

Root Cause: Milliseconds data was never captured in time stamp field for Default LI.

Steps to Replicate: Run a default LI call.

Platform/Feature: SBC

The code is modified to incorporate milliseconds. With the fix , the time stamp field looks like "Event Time: 20200429190440.541".

Workaround: N/A

48SBX-99938 / SBX-989962

Portfix SBX-98996: No audio on the SRTP calls.

Impact: Certain call scenarios (SRTP with ICE) intermittently start with one-way audio on encrypted leg(s) due to SRTP authentication failures.

Root Cause: Race condition in set up of encryption and decryption resource results in uninitialized ROC value being used to encrypt outgoing media packets.

Steps to Replicate: SVT ran the SRTP with ICE call load overnight and verified no authentication failures.

Platform/Feature: SBC

Eliminated race condition between encryption and decryption resource set up to ensure the encryption ROC begins at zero.

Workaround: N/A

49SBX-98388 / SBX-983562

Portfix SBX-98356: The AddressSanitizer detected SEGV on an unknown address 0x0000000000e5 (pc 0x5653a715fdde bp 0x7f84a52bfea0 sp 0x7f84a52bfe70 T9).

Impact: After a successful surrogate registration, if any configuration related to the IP Peers/TGs/Surrogate registration is deleted, the SCM process will coredump.

Root Cause: The code was dereferencing a NULL pointer as the trunk group configuration data was no longer present when the surrogate registration response came back.

Steps to Replicate: Trigger the SBC to send out surrogate registration request and delete all the associated trunk group configuration before sending back a response from the remote server.

Platform/Feature: SBC

The code is modified to check that the trunk group configuration exists before trying to read the configuration.

Workaround: Do not delete any Trunk Group's to avoid SCM cores.

50SBX-100005 / SBX-1000022

Portfix SBX-100002: The JIP parameter is not being sent in PAI header.

Impact: The JIP parameter received in the 3xx was not sent in PAI header.

Root Cause: This is because of the Enhanced Local Redirection changes done in 7.2.3 R1

Steps to Replicate: 

  1. Make a SIP-SIP call with JIP in jip parameter in PAI header.
  2. The egress send 302 Moved Temporarily message with a different JIP value.

Platform/Feature: SBC

The code is modified to fix the issue.

Workaround: N/A

51SBX-99902 / SBX-950832

Portfix SBX-95083: The SBC was terminating all the (Transfer Target and Transferee) call legs after call transfer on the Ppenstack / AWS.

Impact: The SBC was terminating all the (Transfer Target and Transferee) call legs after call transfer on the Ppenstack / AWS.

Root Cause: The SBC signaling plane was quickly reusing the same RTCP gen media resource with this call transfer modification scenarios, and the media plane rejecting the reuse of this resource resulting in call failures.

The media plane disables the original resource only after sending last RTCP packet from media plane, then only it allows the reuse.

Steps to Replicate: Enable the NoBye RTCP Gen options, test the call transfer, and modify scenarios as shown below:

  1. Make call from PSTN endpoint to Teams endpoint (simulated in SIPp).
  2. Answer the call as Teams client.
  3. Initiate blind transfer from Teams client to another Teams client.
  4. disconnect the call at PSTN endpoint.

Platform/Feature: SBC

The code is modified to allow this reuse with NoBye RTCP Gen option. Allowing the signaling plane to reuse the same media resource for these call transfer, modifications to work.

Workaround: Disabling the RTCP Gen/term from the SBC, and using RTCP relay will not have such issues.

52SBX-995942

The OAM SBC had a failover/switchover.

Impact: There as a recurring random OAM switchovers have been noticed at the customer site.

Root Cause: The VNFR REST message key and/or value may be NULL. This causes the std::string type instantiation to fail and bring down the SBC application.

Steps to Replicate: The problem cannot be reproduced, the issue was fixed based on coredump and core review.

Platform/Feature: SBC

The code is modified to handle the cases where the std::string is instantiated with a NULL value.

Workaround: N/A

53SBX-1003972

An mgt1 IP address appears on the mgt0 interface after a reboot of the SWe SBC.

Impact: After adding the second management, the interface was adding the second management IP in first management IP.

Root Cause: Not updating the /etc/network/interfaces file with second interface entry.

Steps to Replicate: Add the second management interface and ifconfig command must give proper output with separate IP for all management interfaces. 

Platform/Feature: SBC

The code is modified to update the second management IP.

Workaround: N/A

54SBX-1006342

The CDR file transfer fails with the 12.00.00R version of the DSI server.

Impact: The CDR file transfer fails with the 12.00.00R version of the DSI server.

Root Cause: The newer 12.00.00R000P1 version of the DSI server no longer supports the hmac-sha1 as a mac algorithm during the ssh key exchange. The hmac-sha1 is no longer considered secure so the most recent releases of many Linux operating systems have removed support for hmac-sha1.

Steps to Replicate: 

  1. Configure the CDR file transfer to a DSI server running the version 12.00.00R000P1 or later.
  2. Observed that the file transfer fails.
  3. In the /var/log/secure log on the DSI, note an error saying the authentication failed because hmac-sha1 is not available

Platform/Feature: SBC

The code is modified to offer the hmac-sha2-256 as the first choice for the mac algorithm. However, the hmac1-sha1 is also offered as a choice to support transfer of files to older systems that do not have hmac-sha2-256 available.

Workaround: Edit the /etc/ssh/sshd_config file on the DSI and add hmac-sha1 on the line starting with MACs

55SBX-956392

The RTP Inactivity Timer fires early upon performing a port switch-over on the M-SBC and duplicates a STOP Record as a result.

Impact: During the high call load if the SBC detects media inactivity, it generates a duplicate STOP record with the disconnect reason as Module Failure for a subset of calls.

Root Cause: When the RTP inactivity is detected for a call, the GCID of that call is added to a unsolicited call cleanup list.

When the call cleanup is invoked, if it finds that a previous call cleanup is going on then it generates STOP record for all the pending calls cleanups for which it has not received a cleanup reply. Thus causing duplicated STOP record generation for a few calls.

Steps to Replicate: 

  1. Set the RTP inactivity timeout value.
  2. Enable or disable the preventDuplicateEmptyStopRecOnInactivity​Detection.
  3. Run a call load such that RTP inactivity timeout occurs.
  4. Notice that when preventDuplicateEmptyStopRecOnInactivity​Detection is enabled there should be no duplicate STOP records for STOP records with disconnect reason as RTP inactivity.

Platform/Feature: SBC

The code is modified to configure whether the SBC generates duplicate stop record on inactivity detection or not.
Command: set oam accounting admin preventDuplicateEmptyStopRecOnInactivityDetection <enabled/disabled>

Disabled: Default: continue with existing behavior (to generate empty STOP record in case of RTP inactivity detection).
Enabled: To stop generation of empty STOP record in case of RTP inactivity detection.

Workaround: N/A

56SBX-996592

The SBC will increment the port number in the Request-URI of the outgoing INVITE, if the first non-SBC Route header of the incoming INVITE did not contain "transport" parameter and the SBC/PSX configuration determined the egress call leg transport type as TLS.

Impact: The call route in the received route and egress is the TLS, the RURI port is not increment by 1.

Root Cause: Missing the logic to increment port by 1.

Steps to Replicate: The configuration call received a route, the incoming call has route IP but no transport parameter. The SBC sends out an INVITE without increment port in the RURI.

Platform/Feature: SBC

The code is modified to increment port by 1.

Workaround: Have the SMM to increment port.

57SBX-1004852

There was an issue on link failures counts on the Port Monitor Status.

Impact: There was alinkFailure count in portMonitorStatus command was not getting incremented upon the link failures.

Root Cause: The counter was not getting incremented whenever a link monitor failure notification is reported.

Steps to Replicate: Simulate link failures and check for a linkFailure counter in portMonitorStatus command output.

Platform/Feature: SBC

The code is modified to increment the counter upon getting the link monitor failure notification.

Workaround: N/A

58SBX-1008692

The Egress SBC is not tearing the call down, even though the ingress SBC releases the call.

Impact: When making the GW-GW call flows between the SBC and either the SBC or GSX call flows and bulk call failures occur on one GW.

Root Cause: There was a code change in the 8.2.1R0 release that mistakenly removed processing of the GW multiple call clear message.

This message is used to send a list of multiple GCIDs that have failed on one GW, over to the other GW to clean up as a bulk. As the message is dropped, the calls will not be cleaned up until timers expire or the user hangs up the call.

Steps to Replicate: Run an SBX-GW-GW-SBX call flows with packet loss action set to trap and disconnect and do not provide any media so multiple calls are cleaned up in a single action. Check the calls are cleaned up correctly on both GWs.

Platform/Feature: SBC

The code is modified so multiple call failures are processed immediately.

Workaround: N/A

59SBX-1004532

The MS Teams zone detection needs to account for GCC and DOD deployments.

Impact: MS Teams uses special FQDNs for GCC and DOD network deployments and the SBC was not using these to recognise that it was a MS Teams zone.

This meant that some of the native functionality such as generating UserAgent headers did not happen.

Root Cause: The code was not checking for the special FQDNs of sip.pstnhub.dod.teams.microsoft.us and sip.pstnhub.gov.teams.microsoft.us.

Steps to Replicate: Configure the SBC in one of these networks and check that it is automatically sending UserAgent and other headers.

Platform/Feature: SBC: MS Teams

The code is modified to check for these deployments.

Workaround: Add a pathcheck to a regular MS Teams FQDN to get native support or implement the SMM to cover the functionality that is available natively, similar to the 7.2 configuration guide.

60SBX-986802

The response for the OPTION message received from TEAMS does not have domain name in contact.

Impact: The contact header sent in the 200 OK response to the out-of-dialog OPTIONS message in the MS Teams zone contains IP address. 

Root Cause: The out-of-dialog OPTIONS message received in the MS Teams Zone.

Steps to Replicate: Send an out-of-dialog OPTIONS message in the MS Teams Zone.

Platform/Feature: SBC

The code is modified to populate the zone domain into the Contact header of 200 OK.

Workaround: N/A

61SBX-1007862

The EMA /tmp is filling the "/var/log/sonus/ema/tmp".

Impact: The EMA /tmp is filling the "/var/log/sonus/ema/tmp"

Root Cause: Every time the SBC started up, it is not created a new tmp directory.

Steps to Replicate: 

  1. Restart the EMA.
  2. After connect to corresponding the SBC box.
  3. Navigate to /var/log/sonus/ema.
  4. Observe the newly created tmp directory.

Platform/Feature: SBC

The code is modified to fix the issue.

Workaround: N/A

62SBX-1004972

The Call/Registration Data is showing the syncInProgress after upgrading the Standby MSBC in 2:1 DSBC Set up.

Impact: The Call/Registration Data sync does not complete when the Active is running in the 8.20R001 and standby is running in 9.0R000 and the call load has PCSILI stable calls during sync.

Root Cause: For PCSILI, one of the redund messages is not registered to the ObjectFactory. As a result, the ObjectFactory is unable to provide serialization/de-serilazation

Steps to Replicate: Performing the LSWU from 8.2.0R001 to 9.0R000 with PCSILI calls will cause this issue.

Platform/Feature: SBC

All required redund messages for PCSILI are registered to the ObjectFactory to provide the serialization/de-serilazation.

Workaround: This is affected only for PCSILI calls' sync. Since the customer is not going to do the regular LSWU procedure as part of their upgrade, this issue will not be seen in the customer deployment.

Also, the upgrade is successful, if there is no PCSILI stable calls during the upgrade(sync time specifically).

63SBX-100363 / SBX-964722

Portfix SBX-96472: The SLB restarted on Jan29 / SSBC3, on Feb25 / TSBC1, on Feb 26 / TSBC4 on Mar 19.

Impact: The watchdog incorrectly kicks in and kills the service resulting in a restart of the service.

Root Cause: The pidof and ps commands are sporadically returning a false negative, indicating to the watchdog that the safplus_amf process is not running when in fact it is.

Some type of race condition with processes starting/exiting is causing the getdents call to skip processing some of the /proc file system.

Steps to Replicate: 

  1. Kill safplus_amf and ensure the watchdog properly detects it, kills all the components, and restarts the service.
  2. There is no way to validate that we do not restart due to a false negative without an unexpected failover happening and being analyzed back to the watchdog kicking in for no apparent reason.

Platform/Feature: SBC

When the watchdog detects that safplus_amf is not running, a second call is made to pidof to confirm that the process is completely gone.

Workaround: N/A

64SBX-100403 / SBX-1004002

Portfix SBX-100400: The OOM (Out Of Memory) threshold default value is not set correctly on a HA system.

Impact: In the 8.2 release, the default value of outOfMemory configuration was increased from 85% to 91% but the logic is not taking effect on freshly installed HA systems.

Root Cause: There was a bug in the code which meant the standby server was not reading the hardware details correctly and assigned the value of 85% instead of the value of 91% set on the standby server.

When the standby server then synced with the active server for the first time it resulted in the system value getting reset to 85%.

Steps to Replicate: Install a HA server and confirm that the default outOfMemory value is set to 91%.

Platform/Feature: SBC

The code is modified to correctly read the hardware details and set the outOfMemory configuration to 91% on the standby server to match with the active so that the overall system value is initialized to 91%.

Workaround: The user can manually set the outOfMemory configuration to 91%.

65SBX-99529 2

The call upgrade scenario failing in the DSBC (MSRP upgraded to MSRP and audio call).

Impact: The problem is that MrmModifyRpy on the MSBC is picking the SSBC GCID when it was supposed to pick the MSBC GCID and reply to the local NRMA on MSBC that leads to a call failure.

Root Cause: The root cause is that the SSBC GCID was being picked instead of the MSBC GCID to send the MrmModifyRpy.

Steps to Replicate: Run a basic MSRP call with re-invite and ensure the re-invite processing is successful, the media flows and tear down is successful.

Platform/Feature: SBC

Based on the MSBC check, pick the MSBC GCID in order to send the reply to the local NRMA on the MSBC that allows us to process the call modification/tear down smoothly.

Workaround: N/A

66SBX-100247 / SBX-997482

Portfix SBX-99748: The AddressSanitizer detected the heap-buffer-overflow on address:

0x6060007e96d0

  • at pc 0x55c8b4f2b47b bp 0x7efe153ce020 sp 0x7efe153cd7d0 READ
  • of size 1 at 0x6060007e96d0 thread T9.

Impact: This issue is only reproducible when using ASAN images in engineering lab.Issue happens on SIP-I call where accessing 18x msgHandle after freeing the memory.

Root Cause: The MsgHandle that was being used is already free.

Steps to Replicate: Run a SIP-I call in an ASAN Build.

Platform/Feature: SBC

The code is modified problem was causing code.

Workaround: N/A

67SBX-100263 / SBX-1000592

Portfix SBX-100059: After observing an overnight call load run, the ping with a size more than 1453 is not reaching to the SSBC.

Impact: The SBC SWe can get into a state where it cannot receive and reassemble fragmented packets.

Root Cause: For the fragmented packets that take close to 1 second to send the complete context, network processor could decrement the incorrect interface "current number of fragments context in use" counter.

The network processor has a maximum fragment context in use limit and once it hits that limit, it will not accept new fragmented packets.

Steps to Replicate: Send the fragmented packets that take 1 second to complete to pkt0, pkt1 or mgt1 port.
This may take some time but eventually the interface stops accepting fragmented packets without the fix.

Platform/Feature: SBC

Fix race condition and decrement the correct interfaces "current number of fragment context" counter.

Workaround: Try not to send a very large fragmented packet to the SBC.

68SBX-99716 / SBX-948382

Portfix SBX-94838: The securelink access was not working for the Standby server.

Impact: From an EMA PM, once the GateKeeper Access is enabled, it is getting updated as the 'disabled' instead of 'enabled'.

Root Cause: This issue was due to missing ACLs on third and fourth management ports.

Steps to Replicate: 

  1. Login to securelink.sonusnet.com
  2. Generate the registration codes for the Active SBC and the standby 5400 SBC.
  3. Login to the respective SBC EMA PM.
  4. Navigate to Secure Link ( Administration -> System Administration -> Secure Link).
  5. Provide the DNS IP address and Registration code(generated in step 2).
  6. Click on 'Enable GateKeeper Access'.
    Note: Enabling Gatekeeper access is done with different registration codes in Active and standby set up.
    From EMA PM, once the GateKeeper Access is enabled, the status should show as 'enabled'.

Platform/Feature: SBC

Support for setting ACLs for third and fourth management ports is added.

Workaround: N/A

69SBX-99486 / SBX-990982

Portfix SBX-99098: The SBC does not relay 200 OK for UPDATE in a late media passthrough and reverse offer scenario.

Impact: The latemedia relay call, the SBC may not able to respond to UPDATE if the previous 18x received is not prack.

Root Cause: There was a logical error due to previous 18x did not have prack support causing the SBC to be unable to send out 200OK for an UPDATE.

Steps to Replicate: During a latemedia relay, the Egress offers an SDP in 18x with prack, egress received subsequent 18x without prack, the egress received UPDATE with SDP. The SBC is unable to answer the UPDATE.

Platform/Feature: SBC

For a latemedia call, and if the SDP offer/answer completed, the SBC is able to answer the UPDATE.

Workaround: Use the SMM to drop 18x without prack if not SDP.

70SBX-99544 / SBX-988182

Portfix SBX-98818: There was an Upgrade failure from 8.2.0R0 to 8.2.0R2.

Impact: Impact on the SWe Live Software Upgrade for the upgrades from version 8.x to 8.x.

Root Cause: There may be a Live Software Upgrade failure while upgrading from versions 8.x to 8.x if a model marker(dynamicHANewComps) is present from the previous upgrade.

Steps to Replicate: Perform a Live Software Upgrade from 6.x to 8.x and further upgrade to 9.0 and verify the upgrade to 9.0 is successful.

Platform/Feature: SBC

The code is modified to ensure the removal of the model marker dynamicHANewComps after completion of upgrade on both nodes. Also, upgrading to 9.0 or later ensures removal of marker if a leftover from previous upgrade.

Workaround: While performing the Live Software Upgrade from 8.x to 8.x, remove the following marker file on both nodes if present.
"rm -f /opt/sonus/installUpgrade/log/dynamicHANewComps"

71SBX-99473 / SBX-967112

Portfix SBX-96711: Sometimes, a call on hold is followed by REFER fails.

Impact: A call onhold before blind transfer may cause a call teardown.

Root Cause: There is a race conditions in state machine during call transfer between transfer legs might cause offer answer timeout that tear down the call.

Steps to Replicate: 

  1. A calls B, B put on hold, B refer to C.
  2. C answers a fast connection. The B received the Notify connect, B send bye immediately.
  3. Small load may have caused call tear down due of offer answer timeout.

Platform/Feature: SBC

The code is modified so waiting for internal resources bridging is done before the notify peer transfer completed.

Workaround: If B can delay (200ms) before send bye.

72SBX-99924 / SBX-999182

Portfix SBX-99918: The contact header parameters are not passed transparently in the redirected Invite.

Impact: With the Enhanced Local Redirection flag enabled, the contact Header parameters received in 3xx are not sent as parameters in Request URI if they are not processed by the SBC.

Root Cause: When implementing the changes for this new flag in 723 R1, this flag check was missed.

Steps to Replicate: 

  1. The UAC sends INVITE towards the SBC over TG1.
  2. The SBC performs the D+ query and the Local Tagging is performed at PSX for the TG1 and returns the Redirector IP as part of the reply.
  3. The SBC sends the Egress Invite towards the SBC towards the Redirector.
  4. Redirector sends 3xx with the contact containing UAS IP and DTG info as mentioned below:

Contact: <sip:9894192190@10.34.166.40:5060;dtg=SBC2_INGRESS_TG>

Platform/Feature: SBC

The code is modified to fix the issue.

Workaround: Enable the honorEmbeddedHeadersIn3xx or includeEmbeddedPAIheaderInRedirectedInvite to fix this issue.

73SBX-100106 / SBX-981472

Portfix SBX-98147: The SSBC is not forwarding a 200 OK response of the OOD INFO to INGRESS SLB.

Impact: The INFO message response was not being sent to correct SCM and as a result, the SCM was not getting the related TCB and dropping the message there.

Root Cause: The INFO message in the "From" header Tag was not including SCM information and as a result, the SIPFE was unable to get the correct SCM to process this response.

Steps to Replicate: 

  1. Enable the non-invite relay configuration in TG.
  2. The UE Client Send INFO message to the SBC.
  3. The SBC will add the "From" header tag and forward it to UE server.
  4. The UE server will send 200 OK towards the SBC.

Platform/Feature: SBC

Added SCM information in the "From" header tag.

Workaround: This issue will not be seen in the SBC with single SCM process.

74SBX-100046 / SBX-906752

Portfix SBX-90675: The SBC inserts the port number 5060 in the Record-Route headers.

Impact: The SBC adds a default port as 5060 for transport TLS in Record Route header of 18x.

Root Cause: When the flag noPortNumber5060 in IPSP is disabled, the SBC adds the default port in the Record Route header of 18x if the INVITE does not contain a port in RR.

Steps to Replicate: Include Record Route header in INVITE as mentioned below:

Record-Route:<sip:10.54.81.110:4589;transport=tcp;lr>,
<sip:10.54.81.112;transport=tcp;lr>,

<sip:HHSIP@10.54.81.110;av-asset-uid=rw-75a842d6;lr;transport=tls>

Make the call and answer the call.

The SBC sends 18x towards ingress side.

Verify the Record Route in 18x.

Record-Route: <sip:10.54.81.110:4589;transport=tcp;lr>
Record-Route: <sip:10.54.81.112:5060;transport=tcp;lr>
Record-Route: <sip:HHSIP@10.54.81.110:5061;
av-asset-uid=rw-75a842d6;lr;transport=tls>

Platform/Feature: SBC

When the flag noPortNumber5060 in IPSP is disabled, the SBC adds the default port 5061 for TLS transport and 5060 for other transports in the record route headers if the corresponding request/response does not contain port in record route header.

Workaround: The flag noPortNumber5060 in IPSP will be enabled. Then the SBC will not add default port.

75SBX-99478 / SBX-974612

Portfix SBX-97461: Both the SBC CLI and EMA allows to configure an invalid regex under the sipAdaptorProfile (SMM) that causes an SCM Process coredump once the SBC performs the regex operation (regstore).

Impact: The SBC may core when config SMM with invalid regex action.

Root Cause: The invalid action did not delete from rule when detect invalid.

Steps to Replicate: Configure the regex for invalid action, incoming call with valid criteria and action taken might caused core.

Platform/Feature: SBC

Delete the invalid action from the rule.

Workaround: Avoid configuration regex with invalid action.

76SBX-100001 / SBX-998822

Portfix SBX-99882: The SBC coredumped due to a Path Check.

Impact: The Pathcheck process may coredump when the pathCheck is state disabled on a FQDN based ipPeer.

Root Cause: The Pathcheck process hit a race condition that can occur when the DNS query completes AFTER pathCheck (on the FQDN based ipPeer) was state disabled that can cause a NULL pointer access coredump.

Steps to Replicate: This is timing dependent issue, that is very difficult to reproduce.

Attempt to reproduce by defining FQDN based ipPeer(s) with pathCheck profiles state enabled.

Randomly state disable and state enable the ipPeer(s) pathCheck profiles.

Platform/Feature: SBC

The code is modified to protect against the NULL pointer access.

Workaround: N/A

77SBX-99248 / SBX-989492

Portfix SBX-98949: Observing the error prints of 504 and increase in a retransmission while running the IPSEC load with multiple IPSEC-Tunnels.

Impact: In a large SWe SBC distributed NP Model, when multiple IPSec SA tunnels are established from different peers, IPSec packets getting dropped with anti-replay errors.

Root Cause: In a large SWe SBC distributed NP Model, scope of an anti-replay local compute was not correct, caused corruption and resulted in false anti-replay drops.

Steps to Replicate: Establish multiple IPSec SA tunnels from different endpoints and send the IPSec traffic to a large SWe SBC with Rx distributed NP Model and observe SA stats.

Platform/Feature: SBC

The code is modified so the scope of per worker ipsec dec anti-replay local compute is fixed.

Workaround: N/A

78SBX-99880 / SBX-997832

Portfix SBX-99783: The SBC is sending the generic number with the Presentation restricted instead of allowed.

Impact: The generic Number parameter sent to PSX does not have a presentation set when the X-Headers are supported, the Generic Number digits are derived from P-Asserted-ID and no X-CALLING-NUM header is received.

If the call egresses on SIP-I, this results in the ISUP Generic Number having presentation restricted, rather than a presentation allowed.

Root Cause: The presentation for a Generic Number not defaulted to allowed.

Steps to Replicate: X-Headers are supported. Send INVITE with Privacy: none header, no X-CALLING-NUM header, no X-GENERIC-NUM header and P-Asserted-ID with SIP and TEL URIs.

Platform/Feature: SBC

The code is modified to default presentation if not already set.

Workaround: N/A

79SBX-99278 / SBX-991372

Portfix SBX-99137: The GSX is not complete address in IAM, which resulted in the GSX rejecting with 484.

Impact: The Generic Number was sent to the PSX is does not have presentation restricted when the Privacy: id header is received, if X-CALLING-NUM header is received with presentation allowed and Generic Number is derived from P-Asserted-ID.

Root Cause: The presentation for a Generic Number not derived from Privacy.

Steps to Replicate: X-Headers are supported. Send INVITE with Privacy: id header, X-CALLING-NUM header with presentation allowed, and P-Asserted-ID with SIP and TEL URIs.

Platform/Feature: SBC

The code is modified to derive Generic Number presentation correctly.

Workaround: N/A

80SBX-954552

Unable to change the username of a configured AD Domain Controller through the EMA.

Impact: When creating a domain controller from the EMA, the username validation was failing for special characters because of that unable to create domain controller but CLI was accepting special character to username and able to create the domain controller.

Root Cause: The username validation was failing because the username param was not part of netconf request and netconf was throwing an error.

Steps to Replicate: 

  1. Login into EMA.
  2. Go to All -> global->servers->domain controller.
  3. Click on New Domain controller button.
  4. Fill the value in all field but for username need to put special characters.
  5. Click on the submit button.

Platform/Feature: SBC

The code is modified so the EMA validates the username param based on default regex that is in the yang file.

Workaround: The backened code was modified so the workaround is not possible.

81SBX-99954 / SBX-999233

Portfix SBX-99923: The HW SBC GCM SRTCP encrypted packets dropped by the SWe SBC.

Impact: The HW SBC GCM SRTCP encrypted packets dropped by the SWe SBC.

Root Cause: The HW SBC is not including an E bit along with SRTCP index in GCM SRTCP encryption, that results in the SWe SBC decryption error drops.

Steps to Replicate: Test calls between the HW SBC and SWe SBC with GCM crypto suites, and verify SRTP/SRTCP packets are decrypted, relayed fine.

Platform/Feature: SBC

The code is modified to include an E bit along with SRTCP index in the GCM SRTCP encryption.

Workaround: N/A

82SBX-100226 / SBX-1001603

Portfix SBX-100160: the Serf log file is missing from the Logrotate.

Impact: One of the serf log files, serfOutputMembership.log, is missing from the Logrotate.

Root Cause: The file was missed from LogRoate configuration. Since this is not a rapidly growing logfile, risk of this log file was filling up disk is very minimal.

Steps to Replicate: Install the build on cloud/swe and check if the serfOutputMembership.log is listed in /etc/logrotate.d/serfLogRotate

Platform/Feature: SBC

The code is modified to the LogRotate configuration.

Workaround: Manually add the serfOutputMembership.log to serfLogRotate.

83SBX-1009802

Unable to create SIP SIG port on SBC5400 after upgrade to 8.2.1R0.

Impact: After an upgrade, additional the sipSigPort cannot be created on SBC5400 in certain ipInterfaceGroup configuration.

These SBC5400 configuration has an ipInterfaceGroup with ipInterfaces on packet ports on:

{pkt0,pkt2}, {pkt0,pkt3}, {pkt0,pkt2,pkt3}, {pkt1,pkt2}, {pkt1,pkt3}, or {pkt1,pkt2,pkt3} sets.

Root Cause: During an upgrade, the SBC5400 did not consider the fact that packet ports pkt0, pkt1, pkt2, pkt3 were all handled by the same Network Processor (NP). Instead SBC5400 behaved like SBC5200 - pkt0,pkt1 were handled by NP#0 while pkt2,pkt3 were handled by NP#1.

Steps to Replicate: 

  1. Configure an ipInterfaceGroup, LIG1, with ipInterfaces on pkt0 and pkt2 on SBC5400. Configure the sipSigPort 1 with ipInterfaceGroup LIG1.
  2. Configure another ipInterfaceGroup, LIG2, with ipInterfaces on pkt1 and pkt3 on SBC5400. Configure the sipSigPort 2 with ipInterfaceGroup LIG2.
  3. After an Upgrade to 8.2.2, add a new sipSigPort with ipInterfaceGroup LIG1.
  4. (Optional) After an Upgrade to 8.2.2, add a new sipSigPort with ipInterfaceGroup LIG2.

Platform/Feature: SBC

The code is modified so the SBC5400 correctly sets the packet port to NP mapping table entries.

Workaround: N/A

84SBX-1007312

There are extra stop records getting generated when calls are cleared due to the dryup timer expiry.

Impact: There are extra stop records getting generated when calls are cleared due to the dryup timer expiry.

Root Cause: The call cleanup was not working correctly, and the original call cleanup is done by using NRM unsolicited list, which was causing the issue.

Steps to Replicate: 

1. Make three calls.
2. Put the TG in Out of Service.
3. The dryup timer will expire and the calls will get cleared by the SBC.

After step 3, check for the stop records.

Platform/Feature: SBC

Cleanup the calls by using the takeDownCalls method instead of keeping in NRM unsolicited list to fix the issue.

Workaround: N/A

85SBX-100666 / SBX-999462

Portfix SBX-99946: The SBC is not sending the RR/RS:0 in a 200 OK during RE-INVITE answer.

Impact: The SBC is not sending the RR/RS :0/0 in a 200 OK for RE-INVITE towards the ingress.

Root Cause: The issue is due to SBX-96087 JIRA changes, which was to modify GWFE code to set RTCP send and receive bandwidth as CPC_RTCP_BW_UNKNOWN if CPC parameter is not received from the Ingress SBC or GSX.

Steps to Replicate: Test Set up:
The SBC and GSX is configured to make SBX-GSX SIP-SIP call.

Procedure:

  1. Configuration:
    Egress PSP: AMR (WB) Bandwidth efficient.
    Ingress PSP: AMR (WB) Bandwidth efficient.
    Transcode conditional flag enabled on both PSP
  2. The RTCP is enabled in both the Ingress and Egress PSP and the RR/RS bandwidth is configured as 100 in Ingress PSP and as 200 in Egress PSP.
  3. Flag the 'Send RR/RS in SDP' is enabled in IP signaling profile for both the Ingress and Egress.
  4. Initiate a SIP-SIP Audio call with Audio codec as the AMR WB with RTCP bandwidth parameters in SDP as:
    b=RR:400
    b=RS:400
  5. The Egress Answers with RTCP bandwidth parameters in SDP as:
    b=RR:300
    b=RS:300
  6. Ingress end point sends Re-Invite with RTCP bandwidth parameters in SDP as:
    b=RR: 0
    b=RS: 0

Platform/Feature: SBC

Revert changes made for the JIRA SBX-96087 to fix the issue.

Workaround: N/A

86SBX-1006623

The RTP Inactivity Timer fires early upon performing a port switch-over on the M-SBC and generates a duplicate STOP Record as a result.

Impact: During a high call load if thenSBC detects media inactivity, it generates a duplicate STOP record with the disconnect reason as Module Failure for a subset of calls.

Root Cause: When the RTP inactivity is detected for a call, the GCID of that call is added to a unsolicited call cleanup list.

When the call cleanup is invoked, if it finds that a previous call cleanup is going on then it generates STOP record for all the pending calls cleanups that it has not received a cleanup reply for.

As a result, this causes the duplicated STOP record generation for a few calls.

Steps to Replicate: 

  1. Set the RTP inactivity timeout value.
  2. Enable or disable the preventDuplicateEmptyStopRecOnInactivity​Detection.
  3. Run call load such that RTP inactivity timeout occurs.
  4. Notice that when preventDuplicateEmptyStopRecOnInactivity​Detection is enabled, there should be no duplicate STOP records for STOP records with disconnect reason as RTP inactivity.

Platform/Feature: SBC

The code is modified to configure whether the SBC should generate duplicate stop record on an inactivity detection or not.
Command - set oam accounting admin preventDuplicateEmptyStopRecOnInactivityDetection <enabled/disabled>

disabled (default): Continue with existing behavior (generate an empty STOP record in case of an RTP inactivity detection).
enabled: Stop the generation of empty STOP record in case of an RTP inactivity detection.

Workaround: N/A

87SBX-1004062

Modify the codec from the Ingress update is not sent in the RE-INVITE to egress.

Impact: The E2eupdate flag is enabled but peer does not support an update. On the ingress side, support the update. The call is put in connected state. When the ingress modify update is received on the ingress leg, the egress side SBC has to send a RE-INVITE for media change. But the SBC fails to send.

Root Cause: When the E2eupdate is enabled, the SBC tries to send update instead of a reInvite but it failed in stack layer since allowing the update is not supported on the egress leg.

Steps to Replicate: The E2eupdate flag is enabled but peer does not support the update (2xx for an invite does not have allow: update) but on the ingress side, support the update. Call is in the connected state. Send the ingress modify update on the ingress leg.

Platform/Feature: SBC

The code is modified to check the peer supports update and then sends the update or else it is needed to send a reInvite.

Workaround: N/A

88SBX-1005432

After a restart, the D2SSBC21 fails to register with the EMS.

Impact: The SBC is not registering with the EMS after a reboot.

Root Cause: The cloud-init is failing while processing a obj.pkl file and not fetching the user data. The LCA fails to find 'EmsPassword' entry in the existing user data file as it was removed by the keyKeeper on every boot up.

Steps to Replicate: Reboot the SBC and test that the SBC is getting registered with the EMS after a boot up.

Platform/Feature: SBC

Avoid the cloud-init failure by removing the obj.pkl file in the LCA.

Workaround: Remove the /var/lib/cloud/instance/obj.pkl file manually and reboot the system.

89SBX-977752

The VLAN tagged interfaces on the Guest instance are not reachable.

Impact: The VLANs on the guest does not work with the X-710 NIC SR-IOV mode in VMWare Set up.

Root Cause: There was issues with the i40en driver from VmWare that was fixed in 1.8.6 version. The SBC was not configuring the VLAN from the VF to the F properly, which was fixed.

Steps to Replicate: Configure the VLAN on the guest with X710 SR-IOV on VmWare Set up and the interface should be reachable.

Platform/Feature: SBC

The code is modified so the SBC configures the VLAN from the VF to the F correctly.

Workaround: N/A

SBX-97947 Steps to Replicate

admin@sbxsus1> show table profiles services pathCheckProfile OPTIONS_PING
protocol sipOptions;
sendInterval 15;
replyTimeoutCount 3;
recoveryCount 1;
transportPreference {
preference1 tls-tcp;
preference2 none;
preference3 none;
preference4 none;
}

Define the FQDN based ipPeer using the pathCheck profile:

admin@sbxsus1> show table addressContext default zone ZONE_SIPART_AS ipPeer OER2_fqdn
policy {
description "";
sip {
fqdn secure-sipconnect.ipfonie.de;
fqdnPort 0;
}
}
pathCheck {
profile OPTIONS_PING;
hostName secure-sipconnect.ipfonie.de
hostPort 0;
state enabled;
}


Configure access to (and use of) the DNS server:

config

# Use the mgmt interface mgmtGroup to access DNS Server on TNT
set addressContext default dnsGroup DNS_GROUP server TNT_DNS ipAddress 10.7.20.75 state enabled
set addressContext default dnsGroup DNS_GROUP type mgmt interface mgmtGroup useConfiguredDnsServer enabled
commit

# Use the ip interface LIG2 (10.7.x.x) to access TNT DNS Server (via pkt1).
#set addressContext default dnsGroup DNS_GROUP server TNT_DNS ipAddress 10.7.20.75 state enabled
#set addressContext default dnsGroup DNS_GROUP type ip interface LIG2 useConfiguredDnsServer enabled
#commit

# Assign a DNS Group to specific zones.
set addressContext default zone ZONE_SIPART_IAD dnsGroup DNS_GROUP
set addressContext default zone ZONE_SIPART_AS dnsGroup DNS_GROUP
commit

set addressContext default zone ZONE_SIPART_IAD sipTrunkGroup TG_SIPART_IAD services dnsSupportType a-srv-naptr
set addressContext default zone ZONE_SIPART_AS sipTrunkGroup TG_SIPART_AS services dnsSupportType a-srv-naptr
commit

set addressContext default zone ZONE_SIPART_IAD sipTrunkGroup TG_SIPART_IAD services dnsNaptrAlways enabled
set addressContext default zone ZONE_SIPART_AS sipTrunkGroup TG_SIPART_AS services dnsNaptrAlways enabled
commit

# Use Port Number returned by DNS SVR
set profiles signaling ipSignalingProfile DEFAULT_SIP commonIpAttributes flags noPortNumber5060 enable
commit

exit

* The DNS SRV record for the FQDN must specify TLS (_sips._tcp):
_sips._tcp.secure-sipconnect.ipfonie.de. 86400 IN SRV 10 10 5061 ns1.secure-sipconnect.ipfonie.de.

The PATHCHECK OPTIONS pings should be sent the to the TLS port number specified in the DNS SRV record for TLS "_sips._tcp" (5061).


SBX-98580 SMM Example:

% set profiles signaling sipAdaptorProfile Modify_Options state enabled
% set profiles signaling sipAdaptorProfile Modify_Options advancedSMM disabled
% set profiles signaling sipAdaptorProfile Modify_Options profileType messageManipulation
% set profiles signaling sipAdaptorProfile Modify_Options rule 1 applyMatchHeader one
% set profiles signaling sipAdaptorProfile Modify_Options rule 1 criterion 1 type message
% set profiles signaling sipAdaptorProfile Modify_Options rule 1 criterion 1 message
% set profiles signaling sipAdaptorProfile Modify_Options rule 1 criterion 1 message messageTypes response
% set profiles signaling sipAdaptorProfile Modify_Options rule 1 criterion 1 message methodTypes options
% set profiles signaling sipAdaptorProfile Modify_Options rule 1 criterion 1 message statusCode 200
% set profiles signaling sipAdaptorProfile Modify_Options rule 1 criterion 2 type header
% set profiles signaling sipAdaptorProfile Modify_Options rule 1 criterion 2 header
% set profiles signaling sipAdaptorProfile Modify_Options rule 1 criterion 2 header name Contact
% set profiles signaling sipAdaptorProfile Modify_Options rule 1 criterion 2 header condition exist
% set profiles signaling sipAdaptorProfile Modify_Options rule 1 criterion 2 header hdrInstance all
% set profiles signaling sipAdaptorProfile Modify_Options rule 1 action 1 type header
% set profiles signaling sipAdaptorProfile Modify_Options rule 1 action 1 operation regsub
% set profiles signaling sipAdaptorProfile Modify_Options rule 1 action 1 from
% set profiles signaling sipAdaptorProfile Modify_Options rule 1 action 1 from type value
% set profiles signaling sipAdaptorProfile Modify_Options rule 1 action 1 from value "<sip:user_input1:user_input2;transport=tls>"
% set profiles signaling sipAdaptorProfile Modify_Options rule 1 action 1 to
% set profiles signaling sipAdaptorProfile Modify_Options rule 1 action 1 to type header
% set profiles signaling sipAdaptorProfile Modify_Options rule 1 action 1 to value Contact
% set profiles signaling sipAdaptorProfile Modify_Options rule 1 action 1 regexp
% set profiles signaling sipAdaptorProfile Modify_Options rule 1 action 1 regexp string .*
% set profiles signaling sipAdaptorProfile Modify_Options rule 1 action 1 regexp matchInstance all
% commit


Resolved Issues in 08.02.01R001 Release 

The following Severity 1 issues are resolved in this release:


Resolved Issues


Issue IDSevProblem DescriptionResolution
1SBX-973051

There is a possibility of performance degradation on the 138 CPS with a high number of SMMs.

Impact: The loglevel is set to major and set the global callTrace configuration with level1, When the application invokes the debug function for the info level logging, the debug function is not filtering those logs and instead invokes the snprintf and calls eventHandler for logging. These logs are filtered at second level that has caused the performance congestion.

Root Cause: This is caused due to new changes done for the SIP_LOG_TRACE_L123 logging.

Steps to Replicate: 

  1. Set the loglevel to major.
  2. Set the global callTrace configuration with level1.
  3. Configure a high number of SMM rules.
  4. Run a load test on a basic call.

Platform/Feature: SBC

The code is modified to filter the logs with both the SIP_LOG_TRACE_DATA and SIP_LOG_TRACE_L123.

Workaround: N/A

Resolved Issues in 08.02.01R000 Release 

The following Severity 1 issues are resolved in this release:


Resolved Issues


Issue IDSevProblem DescriptionResolution
1SBX-973051

There is a possibility of performance degradation on the 138 CPS with a high number of SMMs.

Impact: The loglevel is set to major and set the global callTrace configuration with level1, When the application invokes the debug function for the info level logging, the debug function is not filtering those logs and instead invokes the snprintf and calls eventHandler for logging. These logs are filtered at second level that has caused the performance congestion.

Root Cause: This is caused due to new changes done for the SIP_LOG_TRACE_L123 logging.

Steps to Replicate: 

  1. Set the loglevel to major.
  2. Set the global callTrace configuration with level1.
  3. Configure a high number of SMM rules.
  4. Run a load test on a basic call.

Platform/Feature: SBC

The code is modified to filter the logs with both the SIP_LOG_TRACE_DATA and SIP_LOG_TRACE_L123.

Workaround: N/A

2SBX- 98494 / SBX-970791

Portfix SBX-97079: After the LDG triggered a switch over, the SBC is rejecting all the register message with 500 internal error.

Impact: The SCM process may coredump when the SIP signaling port being used during SIP registration call flow is state disabled.

Root Cause: The SCM process core dumped when it attempted to display a debug warning message that contained the disabled SIP signaling port number (but encountered a NULL pointer).

Steps to Replicate: The steps cannot be reproduced.

Platform/Feature: SBC

The code is modified to prevent accessing a NULL pointer, when attempting to generate the debug log message.

Workaround: N/A

3SBX-98239 / SBX-969961

Portfix SBX-96996: The SCM Process cored.

Impact: When the pathcheck timeout and the SBC is unable to find a zone, the SBC may core as a result.

Root Cause: Attempting to access the null pointer.

Steps to Replicate: The steps cannot be reproduced.

Platform/Feature: SBC

Check for a valid zone pointer before accessing the null pointer.

Workaround: Disable the pathcheck. 

4SBX-98044 /  SBX-979601

Portfix SBX-97960: Incorrect transparency functionality causes calls to fail.

Impact: The To header transparency and launching a successful ENUM query may causenan incorrect RURI format. 

Root Cause: The RURI build was based on the To header.

Steps to Replicate: Enable the To header transparency and the PSX ENUM LNP response may contain an empty “Called URI”

Platform/Feature: SBC

The code is modified so the RURI is independent of the To header.

Workaround: N/A

5SBX-977601

The SBC 5400 was displaying the wrong routing info in the GUI and correct info in the CLI.

Impact: The GUI is displaying wrong routing information for the routing labels, memory usage, and the zone in the routing label in the GUI.

Root Cause: The wrong routing information for routing labels when a few records fetched for Routing labels list the
EMA application taking the memory information in a wrong way from the free command.

Steps to Replicate: Go to the routing page, create a routing label and edit the same correct routing label information will be shown.

Platform/Feature: SBC

The code is modified to remove the limit in a call to get the routing labels list and give the table option to select Routing Label in route create/Edit form.

Workaround: N/A

6SBX-977541

A failover occurred because of a ScmP core.

Impact: The SBC may core when trying to send the 18x to Ingress, and when enabling the reason header transparency. The Egress may teardown too early, which can cause the Ingress to access an invalid pointer.

Root Cause: The SBC accesses an invalid pointer when attempting to check the transparency reason headers.

Steps to Replicate: Configure the reason header transparency, the egress answers with a 180 with SDP and the peer answers with a failure to PRACK. The SBC may require to run load as a result.

Platform/Feature: SBC

Validate the pointer before attempting to access the pointer.

Workaround: Disable the transparency reason header or the PRACK.

7SBX-97464 / SBX-960871

Portfix SBX-96087: The SBC is not sending RTCP to the egress Peer for a transcode only.

Impact: With the Ingress Peer -(ISDN)> GSX ---(GW2GW)-> SBC --(SIP)-> Egress Peer, with the PSP set as "transcode only" and with the RTCP enabled, the SBC does not send the RTCP packets towards the egress.

Root Cause: Due to changes made for the feature SBX-6366, the SBC does not mark the XRES resource as a duplex and marks it as receive only. As a result, the SBC does not send the RTCP towards egress.

Steps to Replicate: 

1. Reproduce the problem by using the following call flow:

Ingress Peer -- SIP -- GSX -- GW2GW -- SBC -- SIP -- Egress Peer

Use a transcode only call.

Result: No RTCP is sent by the SBC to the egress. 

2. Verify the issue by applying the SamP with a GWFE change but did not change in the ScmP. (Just debugging logs

Use the same set up. The RTCP traffic was sent from the SBC to egress.

Platform/Feature: SBC

The code is modified to set the RTCP send and receive the bandwidth as CPC_RTCP_BW_UNKNOWN if the CPC parameter is not received from the Ingress SBC or GSX. This ensures the RTCP mode for the XRES resource is duplex and the SBC sends RTCP towards the egress SIP endpoint.

Workaround: Enable the RTCP termination for pass through flag on the PSP

8SBX-97459 / SBX-971991

Portfix SBX-97199: The Wall Comcast PM-SBC memory was increasing.

Impact: There is a memory leak in the PRS. There are leaking structures associated with certain interprocess messages.

Root Cause: There are leaking structures associated with certain interprocess messages because these structures were not being freed.

Steps to Replicate: Unable to reproduce the issue, the problem was identified based on coredump and code analysis.

Platform/Feature: SBC

The code is modified to free the memory for certain interprocess messages.

Workaround: N/A

9SBX-974341

Inconsistent behavior in a specific call flow when the SMM tears down the call.

Impact: If the SMM teardown functionality is being triggered on a 200ok of UPDATE, without responding to pending update method, the final response is being sent to the initial invite.

Root Cause: Update handling before the call is connected was missing in the case of the SMM Teardown functionality.

Steps to Replicate: Write a SMM Rule to be triggered when receiving a 200 ok of update with a teardown action. Send the update before the 200 ok of invite is being received from the UAC and execute the test.

Platform/Feature: SBC

The code is modified for the UPDATE received before a call is connected.

Workaround: N/A

10SBX-97070 / SBX-923861

Portfix SBX-92386: The SBC running the 721R2 release is responding with 'a=inactive' instead of 'a=sendrecv' in the 200ok SDP to late media re-invite, resulting in no audio.

Impact: It was not RFC compliant to send a=inactive to the late media re-INVITE after the peer put the SBC on hold.

Root Cause: There was a missing requirement.

Steps to Replicate: The following scenarios were tested where – on receiving a re-invite from the ingress peer on a stable PCM-U passthrough fax call, the SBC will maintain this call in fax mode and suppresses any re-invites to the egress peer.

Ingress peer removes DTMF in re-invite
Ingress peer adds DTMF in re-invite
Ingress peer adds ss:off in re-invite
Ingress peer removes ss:off in re-invite

There are some explicit scenarios where the SBC will switch the call from fax back to voice. A DEV will need to add these.

Platform/Feature: SBC

The code is modified to send a=sendrecv to make it RFC compliant.

Workaround: N/A

11SBX-96966 / SBX-933111

Portfix SBX-93311: Send a local response for a reInvite in a Fax call.

Impact: For a G.711-T.38 Fax call, if the SBC receives a G.711 reInvite with a change in SDP from ingress peer, then the SBC sends a G.711 reInvite to egress peer. Users expect the SBC to stay in a Fax call and not send any reInvite to the Egress peer.

Root Cause: For a G.711-T.38 Fax call, if the SBC receives G.711 reInvite, or any other reInvite that has any changes in the SDP from ingress peer, then the SBC initiates an offer-answer negotiation and sends G.711 or any relevant codec reInvite to egress peer. In this case, the SBC also initiates a transition from fax to voice.

Steps to Replicate: 

- Ingress PSP: PCMU, 2833, FTT=FBG711, MTT=AFTT
- Egress PSP: PCMU, 2833, FTT=FRorFBG711, AFTT enabled in p2pControl

  1. A PCMU-PCMU voice pass through call is established.
  2. T.38 ReInvite received from egress peer.
  3. SBC sends PCMU ss:0ff reInvite to ingress peer.
  4. Ingress peer answers with PCMU, 2833 (no SS:off).
  5. PCMU-T.38 XCode call is established.
  6. After approximately six seconds, the ingress peer sends reInvite with PCMU (removes 2833).

Platform/Feature: SBC

The code is modified to handle the issue so that:

  • Whenever the SBC detects a change in the SDP for a fax call LEG.
  • If the codec active for that fax call LEG is G711.
  • There is no change in G711 LAW.

The SBC stays in the fax call and sends 200OK with an answer-SDP as per last offer-answer negotiation.

Workaround: N/A

12SBX-96919 / SBX-853741

Portfix SBX-85374: Empty the "Egress Local Signaling IP Addr" field in the CDR after an upgrade to V07.01.00R001.

Impact: "Egress Local Signaling IP Addr" field in the CDR is not populated during some race conditions.

Root Cause: When the disconnect Ind from the Egress SG is received, store the Egress Trunk Info that has the local IP signaling address.

Steps to Replicate: 

  1. The Ingress INVITE is received and the egressed out.
  2. The Ingress receive CANCEL and egress receive an error response at same time.
  3. Race condition between CANCEL and error response from egress for INVITE must be triggered.

Platform/Feature: SBC

Store the Egress Trunk Info that has the local IP signaling address.

Workaround: N/A

13SBX-96871 / SBX-964391

Portfix SBX-96439: There is an AD sync issue when having multiple DCs / adServerlist entries configured.

Impact: When there are more then domain controllers attached to an ad profile, the sync operation fails when the application fetches data from the second server.

Root Cause: Once the sync is complete with the first server, the application was freeing the ad attribute data structure that is needed for all the subsequent servers. Since the data structure was freed, the PES used to send wrong ldap query.

Steps to Replicate: Create two domain controllers with same data. Attach both the dc servers to the ad profile. Trigger a adManualSync event. This step will reproduce the issue.

Platform/Feature: SBC

Ensure that the ad attribute structure is freed after all the servers are synced.

Workaround: N/A

14SBX-96844 / SBX-952411

Portfix SBX-95241: A ScmP core occurred on the server.

Impact: The SBC was reading off the end of a memory block while trying to copy the call and the calling party host name.

Root Cause: The SBC code was copying the SIP hostname/username in the diameter code, but it was always copying a fixed number of characters regardless of the username size. This led to the SBC reading more memory than was allocated for the hostname.

If the memory block passed in was right at the edge of process memory, then it is possible this might cause a memory exception and a coredump.

Steps to Replicate: Perform a coredump analysis and code review.

Platform/Feature: SBC

The code is modified to not read more characters than are present in the hostname to avoid reading off the end of the memory block.

Workaround: N/A

15SBX-96750 / SBX-946101

Portfix SBX-94610: The Bye URI Messages do not include the domain.

Impact: When an incoming INVITE contains Contact header with GR tag and call flow (
SIP-SBC1 -- GW - GW - GSX- ISUP), the SBC includes the IP address in the reqURI of BYE message and not the FQDN present in the Contact of Ingress INVITE.

Root Cause: In the GW-GW scenario where the egress GW is GSX, the SBC sends an IP address in the ReqURI field of the BYE message.

Steps to Replicate: 

1. Reproduce the issue by using the following call flow:

When the incoming INVITE contains Contact header with GR tag
Contact: <sip:gw@gw0-1.new-york-1.pstn.jnctn.net;gr=gw0-1.new-york-1.pstn>

The call flow is listed as:
SIP-SBC1 -- GW - GW - GSX- ISUP, SBC includes IP address in reqURI of BYE message and not FQDN ( present in Contact of Ingress INVITE )

439 12202019 131244.050245:1.02.00.09411.Info .SIPCM: SipFeSocketSendMsg - msg = BYE sip:gw@10.158.70.250:5060 SIP/2.0
Via: SIP/2.0/UDP 10.158.130.58:5060;branch=z9hG4bK0cB0000efe682df85e5

2. Verify the issue. After a fix, the SBC sends the FQDN in the BYE sent towards an Ingress endpoint.

Platform/Feature: SBC

The code is modified to ensure the SBC sends FQDN (present in Contact header of an Incoming INVITE ) in the reqURI of a BYE message.

Workaround: N/A

16SBX-957411

The output of the CDR smmfield is null after the teardown, even though the SBC writes the values to the smmfield.

Impact: When the CDR update and the SMMTeardown action is being configured as part of the same SMM Rule, the SMM CDR fields are not being populated.

Root Cause: Before the SMM CDR data is being copied from SG Active context to CCB structure, the SMM CDR data is being cleared.

Steps to Replicate: Create a rule to the SMM CDR update and the SMMTeardown action being part of the same SMM Rule. Run the call to trigger the SMMTeardown action.

Platform/Feature: SBC

When SMM Teardown action is being selected, if SMM CDR data is there in active context, copy the data to CCB structure.

Workaround: Make a SMM CDR update and SMM Teardown part of the different rules.

17SBX-97500 / SBX-947361

Portfix SBX-94736: The SBC is converting two of the same rtpmap into 1 line.

Impact: Duplicated media payload may have caused a syntax error when the sdpSelectedAttribueRelay to the other side.

Root Cause: Duplicated attribute lines are merged into one line.

Steps to Replicate: Configure the sdpSelectedAttribeRelay and transcode free. An incoming sdp with a duplicated media payload may have caused syntax error when sent to the other leg.

Platform/Feature: SBC

The code is modified to ignore the duplicated media payload and attributes lines.

Workaround: N/A

18SBX-95662 / SBX-951141

Portfix SBX-95114: The SBC IgnoreTransparency cannot be set on the EMA V6,7.2 and 8+.

Impact: The SBC IgnoreTransparency cannot be set on the EMA V6,7.2 and 8+.

Root Cause: There is no check whether the "not" is applied to complete expression or not.

Steps to Replicate: 

  1. Log on the EMA.
  2. Navigate to All->profile->services->Transparency profile->SIP Header
  3. Select the transparency profile.
  4. Click on the New Sip Header. After performing this scenario, the "Ignore Transparency " field can be observed.

Platform/Feature: SBC

Created method for checking "not" is applied to whole expression or not.

Workaround: N/A

19SBX-952481

The SBC 8.2 behavior changes with the sendSdpInSubsequent18x enabled.

Impact: A behavior change was introduced on the 8.2.0 whereby the SIP 18x response messages will not include the SDP after a reliable provisional response had been sent, even when the "Send SDP In Subsequent 18x" was selected in the IP Profile. This was done to make the behavior consistent with the RFC 6337 but some customers wish to have the non-compliant behavior so that will remain the default.

Root Cause: There is a missed requirement for some customers to retain the non RFC 6337 behavior.

Steps to Replicate: Make a SIP-SBX-SIP call with multiple 18x responses. The ingress IP profile has Send SDP In Subsequent 18x selected. 18x messages after the first reliable response do not contain SDP.

Platform/Feature: SBC

The code is modified to configure the RFC 6337 compliance:
set addressContext default zone ZONE1 sipTrunkGroup TG1 signaling onlySendSubsequent18xSdpIfUnreliable enabled

When this control is enabled, the SBC only sends the SDP in subsequent 18x responses while they are unreliable.

Workaround: N/A

The following severity 2 and 3 issues are resolved in this release:


Resolved Issues


Issue IDSevProblem DescriptionResolution
1SBX-97363 / SBX-912082

Portfix SBX-91208: For the Egress Invite, the SBC will send the original dialed number in the user part and the new RN in the 'rn' parameter.

Impact: For the Egress Invite, the SBC will send the original dialed number in the user part and the new RN in the 'rn' parameter.

Root Cause: In the case of number translation, the SBC was returning the called number instead of dialed number and caused this issue.

Steps to Replicate: Enable the flag below to send the original dialed number in the Egress R-URI:

admin@TICKH% set global servers enumService TEST_0 flags sendOrigDialedNumOverEgress enable

Rerun test cases with the same configurations.

Platform/Feature: SBC: Application, Documentation

The code is modified to fix the issue. A new flag – sendOrigDialedNumOverEgress – is added to support backward compatibility. The default value of the flag sendOrigDialedNumOverEgress  is Disabled.

 
Workaround: N/A

2SBX-963482

The sonusDatabaseConfigPolicyDataSyncNotification continues to be output after reinstalling the SBC.

Impact: When the customer is using the Direct Single Mode, the system is sending an DbOutOfSync trap continuously.

Root Cause: After analyzing the code, it was found that there is a data mismatch in the PolicyDb and CDB .As a result, it is sending the tarp.

Steps to Replicate: The system being out of sync will not trigger the Direct SBC Mode.

Platform/Feature: SBC

The code is modified to restrict the DBSync check for the Direct SBC mode the same way as the OAM Mode.

Workaround: N/A

3SBX-98495 / SBX- 978512

Portfix SBX-97581: The SBC adds the media IP address in the outgoing SDP, even when the call is a direct media call.

Impact: When a direct media is enabled when handling re-INVITE from ingress endpoint without SDP change, the SBC sends a 200OK answer to ingress with the SBC's own media IP address. This causes a one way audio issue.

Root Cause: When a direct media is enabled, while handling re-INVITE relay transaction, the SBC does not update the SIPStack SDP correctly.

Steps to Replicate: 

  1. Reproduced the issue and checked that the 200OK to the ingress as response to re-INVITE has the SBC's media IP address.
  2. Verified that a 200OK response to ingress has the egress peer's IP address and not the SBC's media IP address.

Platform/Feature: SBC

The code is modified to ensure the SBC updates SIPstack SDP for direct media scenarios.

Workaround: Use SMM to force SDP modification in re-INVITE from ingress.

4SBX-98172 / SBX-978302

Portfix SBX-97830: The ipRecMetadataProfile does not work for a request-uri in the V07.02.02.

Impact: The Invite SIPREC may not have a request-uri beta or core.

Root Cause: A logical error that has access the wrong data structure.

Steps to Replicate: Configure the metadataProfile with a request-uri and enable the SIPREC on ingress.

Platform/Feature: SBC

The code is modified to correct the logical error.

Workaround: Do not configure the request-uri in metaDataProfile.

5SBX-97703 / SBX-976173

Portfix SBX-97617: The SBC application restarted twice.

Impact: The SCM cored due to a segmentation fault.

Root Cause: The SCM hit a Segmentation fault due to an attempt to de-reference a NULL pointer.

Steps to Replicate: The steps cannot be reproduced.

Platform/Feature: SBC

The code is modified to ensure that the pointer is not NULL before de-referencing it.

Workaround: N/A

6SBX-975132

The active calls count much larger than the stable calls count.

Impact: The active calls count is much larger than stable calls count under "show table global callCountStatus" after the memory upgraded from 12 GB to 24 GB.

Root Cause: The SBC 51xx with memory upgrade caused an incorrect GCID mask resulting in an incorrect active call count.

Steps to Replicate: The steps cannot be reproduced.

Platform/Feature: SBC

The code is modified to set the correct GCID mask after a memory upgrade for the SBC 51xx.

Workaround: N/A

7SBX-971652

The SBC does not send precondition attributes in the 200 OK of UPDATE.

Impact: The SBC does not send preconditions in the 200OK of UPDATE when the UPDATE is received in the egress LEG with the SDP same as that of 18x.

Root Cause: Precondition parameters were not getting updated as the processing is returned from SIP stack since there was no change in SDP.

Steps to Replicate: 

1. Perform the egress precondition interworking scenario.
2. Send an UPDATE from egress with SDP same as the 18x.
3. Precondition attributes are incorrect in the 200OK for this UPDATE.

Platform/Feature: SBC

The code is modified to process this UPDATE in the upper layers.

Workaround: N/A

8SBX-97119 / SBX-969922

Portfix SBX-96992: The TLS Call failures observed on the ATL1-CUSBC-05 due to a port value set to 1 instead of 5061.

Impact: The SBC uses Port 1 for sending an INVITE out for TLS protocol, when the route header was received without port.

Root Cause: When the route header is received without port in it, the SIPSG was incrementing the port for TLS. Since no port was received, the port received is considered as 0. So for the TLS, increment by 1 as a result. So when the port was incremented, the port becomes 1 and this gets used for send INVITE that is resulting in failed calls.

Steps to Replicate: Send a Route Header without a port Route: <sip:10.54.80.8:;lr>. The SBC will use port 1 for sending INVITE that is causing the issue.

Platform/Feature: SBC

The code is modified to check whether the port is received in the route header or not. If port is received, then increment the port for the TLS, or do not increment and allow the SIP stack to handle it.

Workaround: Sending the Route Header with a port will avoid this issue.

9SBX-96998 / SBX-967902

Portfix SBX-96790: The SBC 8.1 was missing the HPC_CTL_TFC_EXEM value in the CallCountIntervalStats.

Impact: The HPC_CTL_TFC_EXEM value was missing in CallCountIntervalStats.pms file.

Root Cause: The HPC_CTL_TFC_EXEM field was not present in the CallCountIntervalStats.pms file.

Steps to Replicate: 

  1. Enable the CallCountIntervalStats.pms file using the system fileStatisticsAdmin CLI command.
  2. Wait 15 minutes.
  3. Access the cd /var/log/sonus/sbx/statistics on the SBC.
  4. Untar the stats file.
  5. View the CallCountIntervalStats.pms.
  6. Verify that the HPC_CTL_TFC_EXEM is present in that file.

Platform/Feature: SBC

The code is modified to add the HPC_CTL_TFC_EXEM value to the CallCountIntervalStats.pms file.

Workaround: N/A

10SBX-968962

Upgrading to the 8.2 failed.

Impact: When two different IpPeers with same name are configured, one in CAPS and other in small letter, the SBC is coring as a result.

Root Cause: When the SBC tries to add a second IPPeer entry. It tries to bind the name for the IP Peer. Since there is already another IPPeer with the same name NamedInsert fails, after that, the SBC tries to delete the IP Peer entry from the hash.

While deleting the IpPeer Entry, the SBC tries to delete the response code stats hash table for the peer entry
SipSgDeleteIpPeerResponseHash(peerEntry);

In the routine:
SipSgDeleteIpPeerResponseHash(SIPSG_IP_PEER_STR *peerEntry)

responseHashPtr = HashFirst(peerEntry->responseStatsHashTbl);

At this point, the peerEntry->responseStatsHashTbl is not created and is NULL so this results in a coredump.

Steps to Replicate: Configure two IPPeer with the same name, one in capital letter and other in small letter.

Platform/Feature: SBC

The code is modified to add a NULL check for responseStatsHashTbl before deleting.

Workaround: N/A

11SBX-96850 / SBX-945792

Portfix SBX-94579: After an upgrade, all CNAM Trunks are set to a Subscribe Rate of 1.

Impact: When the LSWU upgrade completes, the SIP Trunk Group CAC ingress/egress subscribeRateMax and subscribeBurstMax are over written with the registerRateMax and registerBurstMax values.

Root Cause: This is functionality that was added in the SBC V3.1 when the SIP Trunk Group CAC ingress/egress subscribeRateMax and subscribeBurstMax were first added (but their value was not set).

Steps to Replicate: 

  1. Configure the SIP Trunk Group CAC ingress/egress subscribeRateMax and subscribeBurstMax.
  2. Perform an LSWU upgrade.

Observe that the SIP Trunk Group CAC ingress/egress subscribeRateMax and subscribeBurstMax are now set equal to registerRateMax and registerBurstMax values.

Platform/Feature: SBC

The source code that provides this functionality is removed, because it is no longer needed.

Workaround: If possible, configure the subscribeRateMax equal to registerRateMax, and the subscribeBurstMax equal to registerBurstMax.

12SBX-96848 / SBX-954702

Portfix SBX-95470: The SBC was using the incorrect SIP signaling port for a challenged Subscribe.

Impact: When the usePortRangeFlag is enabled, the SBC may use an incorrect SIP Signaling Port when handling a SUBSCRIBE request with an Authorization header, in REGISTER - SUBSCRIBE scenarios when the initial SUBSCRIBE request is challenged.

Root Cause: When the usePortRangeFlag is enabled, the application software uses the wrong connection Id when sending the SUBSCRIBE request with Authorization header to the egress peer.

Steps to Replicate: 

  1. Provision the SBC to support CUCM (Cisco Unified Connection Manager).
  2. Perform a REGISTRATION.
  3. Perform a challenged SUBSCRIBE.

Platform/Feature: SBC

The code is modified to use the proper connection Id, when the usePortRangeFlag is enabled, and the SUBSCRIBE request with Authorization header is sent to the egress peer.

Workaround: N/A

13SBX-96751 / SBX-925822

Portfix SBX-92582: A large increase in sonusSbxSscsRouteFailureWithoutGapNotification2 traps.

Impact: When the PSX has more than 10 routes configured and the SBC receives those routes in multiple PSX responses and if all the routes fail, the SBC still makes additional diameter query towards the PSX. This causes the PSX to send error: No Routes in Cache to SBC. The SBC logs a trap after receiving the No routes in cache error.

Root Cause: The SBC makes addition query to the PSX even after the PSX sent all the routes.

Steps to Replicate: 

  1. Configure more than 10 routes on PSX Routing Label ( 11 routes for example )
  2. All 10 routes fail.
  3. The SBC sends another query and get more route and those fail as well.
  4. The SBC still send additional query to the PSX that fails because the PSX have returned all of them.

Platform/Feature: SBC

The code is modified to ensure the SBC avoids sending additional Diameter query to the PSX when the PSX has returned all the routes.

Workaround: N/A

14SBX-96683 / SBX-910572

Portfix SBX-91057: The SBC fails to relay the 4xx-6xx responses when the IPTG authentication is enabled. All SIP causes get mapped to the CPC176 CPC_DISC_TG_AUTH_FAIL.

Impact: When the IPTG authentication is enabled, the SBC maps all the 4xx-6xx SIP codes to CPC 176. As a result, the SBC is unable to relay cause code from egress to ingress endpoint.

Root Cause: When the IPTG authentication is enabled, the SBC maps all the 4xx-6xx SIP codes to CPC 176.

Steps to Replicate: 

  1. Egress sends the 183 Session Progress
  2. Egress sends the 486 Busy Here.
  3. The SBC does not send the 486 Busy code to Ingress.
  4. Instead sends 599 that is mapping of 176 ( CPC_DISC_TG_AUTH_FAIL which is CPC code ) to Ingress.

With a fix, the SBC sends 486 buys to ingress correctly.

Platform/Feature: SBC

The code is modified to ensure the SBC upon receipt of provision response clears the authentication flag and relays cause the code from egress to ingress.

Workaround: Use the SMM Rule. 

15SBX-96415 / SBX-932622

Portfix SBX-93262: The SBC generates a RTCP goodbye to the ingress after a 200 OK.

Impact: When the Downstream forking is enabled, the Early Media Response is set to "last received SDP" and when the call gets answered, the resource chain will be re-built and the RTCP BYE will be generated.

Root Cause: Root cause comes from a feature done in SBX-32482. This Feature required that if ingress peer does not have 100 rel support, and egress gets multiple 18x's,then force the transcode even though pass through is possible to support codec change (expected behavior as a part of this feature enhancement is 2nd dialog early media must be transcoded without sending the SDP in subsequent 18x to ingress peer.

Steps to Replicate: 

  1. Enable Downstream Forking and the forking response as anything except the first prov response.
  2. Simulate the callflow .
  3. Keep PSP's set up to do transcode only ( but same issue might be observed otherwise also if initially the early media is set up as transcoded).

Platform/Feature: SBC

The code is modified to address the exact scenario that was presented in the previous customer Jira. Specifically:
1. Downstream forking enabled.
2. Early media behavior - non FIRST PROV RESP.
3. Only one forking dialogue.
4. No SDP sent in 2xx if 18x reliable.

WorkaroundSet Early Dialog as SIP_EARLYDIALOG_FORKING_BEHAVIOUR_FIRSTPROVRESP.


16SBX-963482

The sonusDatabaseConfigPolicyDataSyncNotification continues to be an output after reinstalling the SBC.

Impact: When customer is using Direct Single Mode, the system is sending a DbOutOfSync trap continuously.

Root Cause: After an analysis of the code, there is data mismatch in PolicyDb and CDB and is sending tarp as a result.

Steps to Replicate: Out of sync will not trigger for the Direct SBC Mode.

Platform/Feature: SBC

Confirm the customer is not using the ERE is the Direct SBC mode.  As a result, the code is modified to restrict the DBSync check for the Direct SBC mode same as OAM Mode.

Workaround: N/A

17SBX-962822

Unable to delete the User Session from the EMA.

Impact: Unable to delete the User Session from the EMA.

Root Cause: The issue occurred due to a missing value of the remove session call from the UI.

Steps to Replicate: 

  1. Login to EMA with the "admin".
  2. Navigate to Administration> Users and Session Management> click New User.
  3. Create a new user "Test".
  4. From different IP or from different browser, login with the "Test" user and provide necessary password changes.
  5. Ensure the "Test" it is logged in Successfully".
  6. In Admin, log into the browser and navigate to Administration> Users and Session Management
  7. Delete the "Test" user session. It will display "Delete successful".

Platform/Feature: SBC

The code is modified to add the missing call for removal of session.

Workaround: Copy ema-ui.war into /opt/sonus/ema/sbxema/deploy/ location.

18SBX-960912

The SBC SWe (VMware/KVM) second management interface to add.

Impact: Adding a second management port to the SWe VM after the ISO and application installation results into the PRS coredump.

Root Cause: Second management port info is not loaded into the CDB after it is added to the VM running with an already installed SWe application.

Steps to Replicate: Install the SWE ISO and application and shutdown the VM. Add second management port (5th interface), power on the VM and ensure application comes up correctly.

Platform/Feature: SBC

The code is modified to create seed XML data for a second management port and add it to the CDB, even if second management port is added after the SWe application installation.

Workaround: Need to manually create the XML seed data for second management port and load it into the CDB.

19SBX-95924 / SBX-917372

Portfix SBX-91737: The external PSX became active after a switch over, though it was OOS prior to the switch over.

Impact: When changing multiple remote policy servers's mode together in one "commit", some of the server's operational stats in the standby node might not be synced.

Root Cause: When one of the remote policy servers' mode was being changed from the OOS to active, the standby node did not try to register with this server, and the iteration of all mode change servers will be stopped. This would cause the rest of the servers, whose operStats have not been changed and remain unchanged. As a result, the operStats of these servers at standby node will be out of sync with the active node.

Steps to Replicate: 

  1. In a working HA, provision at least 3 working remote policy servers.
  2. While keeping the admin stat enabled, only keep 1 of the servers' modes as active, and rest as out of service.
  3. Change those servers' mode, commit only after all set commands are finished.
  4. Display the status using the 2 commands below:
    "show table system policyServer remoteServer"
    "show table system policyServer policyServerStatus"
  5. Perform a switch over
  6. Repeat step 4. The operStat will be different from step 4.
  7. Making call load when Node A is active, and then another call when Node B is active. When Node B is active, the policy request may still be sent to the remote server that is already OOS when Node A was active.

Platform/Feature: SBC

The code is modified in the standby node to be able to modify the operStats for all remote servers requested by the CLI users. The remote servers are unable to be registered even if the mode is being changed from OOS to active. As the result, the operStates at standby node keep synced with the active node.

Workaround: Restart the non-synced node. As a result, this will have traffic loss.

20SBX-95709 / SBX-945773

Portfix SBX-94577: The standby fails to start and connect to the active and shuts back down instead.

Impact: The standby fails to start and connect to the active and shuts back down instead.

Root Cause: The address of the middleware checkpoint is lost and the checkpoint cannot be updated with the arrival of the new node, leading to the standby shutting back down.

Steps to Replicate: The steps cannot be reproduced.

Platform/Feature: SBC

The code is modified to recover the checkpoint address if it is unknown.

Workaround: N/A

21SBX-95701 / SBX-931053

Portfix SBX-93105: The SIP OPTIONS are not responding after a failover.

Impact: A syntax error message during a switch over was unable to respond.

Root Cause: Internal messages drops due to other subsystems not being ready to process the message. Subsequent messages have been stuck in the queue.

Steps to Replicate: Use the ping Options messages during a switch over.

Platform/Feature: SBC

The code is modified so during switchover, the message drops.

Workaround: N/A

22SBX-95699 / SBX-942452

Portfix SBX-94245: The SBC picks up the incorrect TG for incoming, non-INVITE requests and responds to non-INVITE requests.

Impact: The SBC is picking up the wrong trunk group for incoming messages. This is specific for rare configuration when there is only 1 sigport sharing multiple trunkgroups, and the same peer source address was routing traffic to different trunkgroups.

Root Cause: When the SBC processes inbound/outbound msgs, it put the TG into the cache table for processing after the response. In this case, there are 2 trunkgroups that swap back and forth for the same peer address. As a result, a subsequent request OOD may pick up the wrong TG due to the registered end point.

Steps to Replicate: Have the following conditions set up to replicate the issue:

  1. Perform a configuration when there is only 1 sigport sharing multiple trunkgroups, and the same peer source address is routing traffic to different trunkgroups
  2. A call B sharing the same signaling port and same peer IP.
  3. A OOD to SBC and route back to A.
  4. Both cases the out bound is using different TG.

Platform/Feature: SBC

The code is modified to no longer put and outbound OOD in the cache table to avoid swapping the TG. The SBC puts the outbound OOD request in a different new hash table and later received a response from the request to look at new hash table for the TG.

Workaround: N/A

23SBX-984163

In the QSBC format CDR, fields 1, 106, 106, 123 contain date and time in UTC. These fields should contain date and time in local time.

Impact: The time stamp (field numbers 1, 106, 106, and 123) prints in UTC instead of local time.

Root Cause: Design issue.

Steps to Replicate: Make a call with QSBC format CDRs enabled.

Platform/Feature: SBC

The code is modified to use the local time instead of UTC.

Workaround: N/A

24SBX-956892

The SBC DatabaseIntegrity policies were not inSync after an Upgrade.

Impact: The database integrity table on the CLI shows 'notApplicable' for the SBC 1:1 HA mode.

Root Cause: The configure mode for SBC 1:1 HA is returned as a 'CONFIG_MODE_UNKNOWN' instead of the 'CONFIG_MODE_SBC', which sets the status to 'notApplicable'

Steps to Replicate: Launch the SBC 1:1 HA and run a Confd CLI command:
'show table system databaseIntegrity'

Platform/Feature: SBC

The code is modified to return 'CONFIG_MODE_SBC' in case of the SBC 1:1 HA mode.

Workaround: N/A

25SBX-955852

The route search by Routing Label was not functional in the 8.1 EMA.

Impact: The route search by Routing Label was not functional in the 8.1 EMA.

Root Cause: The issue occurred when trying to retrieve maximum of 20 labels.

Steps to Replicate: 

  1. Log on to the EMA.
  2. Click on Configuration->System Provisioning->Routing->Routes
  3. Click on the Routing label scroll bar.

Platform/Feature: SBC

The code is modified to adjust maximum limit for retrieving the routing labels.

Workaround: N/A

26SBX-872873

The logic responsible for updating zone -> callCurrentStatistics -> totalOnGoingCalls counter is flawed. The totalOnGoingCalls counter does not get decremented in some scenarios.

Impact: In certain scenarios, the zone->callCurrentStatistics->totalOnGoingCalls is not decremented and therefore it shows invalid values.

Root Cause: For early cancel scenarios, the code still considered the user was in an on-going call and displayed the incorrect totalOnGoingCall counter.

Steps to Replicate: To replicate the issue, receive the 180 ringing from UAS and then hang up before the UAS answers the call. The ongoing calls counter will get decremented.

Platform/Feature: SBC

The code is modified to correctly display the callCurrentStatistics for early cancel scenarios.

Workaround: N/A

27SBX-886443

The sysdump causes the SBC application shutdown due to a disk usage.

Impact: The sysdump causes the SBC application shutdown due to a disk usage.

Root Cause: Size of the sysdump was unknown and no check was present to verify the available space.

Steps to Replicate: Run the sysdump script in both normal and dryrun mode.

Platform/Feature: SBC

A new dryrun mode (-D) is introduced. When the script is run in dryrun mode, it calculates the approximate size of the final sysdump but not create the actual sysdump. For the ACT logs, a new option (-H) is introduced. Using this option, the user is able to give the number of hours for which the ACT logs to be collected in sysdump.

Workaround: N/A

28SBX-98372 / SBX-974152

Portfix SBX-97415: The SIP From header constructed in the SIP stack does not conform with the RFC.

Impact: The From header in ACK is not the same as shown in a previous Invite.

Root Cause: The issue is caused by SMM modifying the From header in the Invite and the SBC generating ACK based on the response.

Steps to Replicate: 

  1. Using the SMM to modify the From header in Invite Request.
  2. Peer answer 200OK, with the modified From header.
  3. The SBC generate ACK based on the From Header received in response.

Platform/Feature: SBC

The code is modified to send the From header in ACK based on the From original request.

Workaround: Use the SMM to restored From header in 200OK.

29SBX-966492

A failover occurred because of a SAM Process core.

Impact: There were reports of a SAM Process crash stack indicating a Cavecreek QAT driver API may have caused memory segmentation, causing a switchover on the SBC7000 while verifying a TLS client's certificates during a TLS handshake.

Root Cause: Incompatible third-party QAT crypto driver with the current OpenSSL version, Linux kernel, and cipher suites was used in the current certificates.

Steps to Replicate: After an App installation or an Upgrade, ensure that the QAT engine is no longer used by the SIMCM (SAM Process) by checking DBG log.

Example: The following DBG message should be seen:
[root@BF001 ~]# grep -i engine /var/log/sonus/sbx/evlog/1000003.DBG
087 06232020 062948.762154:1.01.00.00609.MAJOR .SIPCM: *Dynamic engine not supported
[root@BF001 ~]#

Platform/Feature: SBC

Due to Cavecreek QAT and its driver being End-of-Life and improved OpenSSL performance in RSA key operations, use the OpenSSL optimization in the RSA key operations to support TLS handshake. The QAT crypto engine is no longer used by the SAM Process and IkeProcess on the SBC7000 and SBC5400.

Workaround: None.

30SBX-1005432

After a restart, the SBC fails to register with EMS.

Impact: The SBC is not registering with EMS after reboot.

Root Cause: Cloud init is failing while processing a obj.pkl file and not fetching the user data. The LCA fails to find the 'EmsPassword' entry in an existing user data file as it was removed by keyKeeper on every boot up.

Steps to Replicate: Reboot the SBC and test that the SBC gets registered with EMS after boot up.

The code is modified to avoid the cloud-init failure by removing obj.pkl file in the LCA.

Workaround: N/A

31SBX-1018142

The SBC does not generate the sonusSbxNodeResEmerCallNoRouteNotification.

Impact: The SBC does not generate the sonusSbxNodeResEmerCallNoRouteNotification alarm when the PSX returns no route for 911 based call (sip code 404, cause code 150).

Root Cause: The code to generate the sonusSbxNodeResEmerCallNoRouteNotification was not present in the scenario where the PSX returns no routes for the 911 based call.

Steps to Replicate: 

  1. Make a basic SIP call using the PSX with no routes set for number starting with '911' on the PSX.
  2. Configure the SBC:
    set profiles services emergencyCallProfile EmergencyCalls prefix 911
    set addressContext ADDR_CONTEXT_1 zone ZONE2 sipTrunkGroup SBXSUS12_LABSIP1 services emergencyCallProfile EmergencyCalls

The SBC does not generate the sonusSbxNodeResEmerCallNoRouteNotification alarm.

The code is modified to generate a sonusSbxNodeResEmerCallNoRouteNotification alarm when the PSX returns a "Not Route" for emergency based call on matching URI prefix.

Workaround: N/A

32SBX-1015413

The platformRsyslog linuxLogs ntpLog feature was not transferring the ntp.log messages to the remote syslog server.

Impact: The platformRsyslog linuxLogs ntpLog feature was not transferring the ntp.log messages to the remote syslog server.

Root Cause: The ntp.log file was getting truncated and as a result, the logs were not getting transferred.

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 2nd 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 several seconds.
5. Repeat steps 2 and 3.

The code is modified to open and close the ntp.log file while getting the last change time of file and taking further action according to that.

Workaround: N/A

Resolved Issues in 08.02.00R002 Release 

The following issues are resolved in this release:


Resolved Issues

Issue IDSevProblem DescriptionResolution
SBX-97608 2

The error popup appears when the import configuration to the M-SBC.

Impact: The error popup appears when the import configuration to the M-SBC.

Root Cause: After sending a request from the SBC manager, it was getting a timeout when performing a start import operation. This operation calls the configTemplate internally for the api of the platform Manager. Using this api, execute the importCLI.pl script with required inputs. Once this script is complete, then the configTemplate api returns the response to the SBC manager that takes time depending on the cli file size.

Steps to Replicate: 

  1. Login into EMS and launch the SBC manager.
  2. Go to Administration --> System Administration -->File Upload and Upload .cli file.
  3. Go to Administration --> System Administration --> Configuration Script and Template Import.
  4. Select uploaded .cli file and click on startImport button.

Platform/Feature: SBC

The code is modified to provide an immediate response and the getStatus api read the current status of running the importCLI every 5 seconds to know about the process status.
Workaround: N/A
SBX-957352

The error popup appears when importing configuration to the SBC.

Impact: The error popup appears when importing configuration to the SBC.

Root Cause: After sending request from the SBC manager, it was getting a timeout due to performing a start import operation. This operation calls for the internal configTemplate api on the platform manager. When using this api, execute importCLI.pl script with the required inputs. Once this script is complete then the configTemplate api returns the response to the SBC manager.

Steps to Replicate: 

  1. Login into EMS and launch the SBC manager.
  2. Go to Administration --> System Administration -->File Upload and Upload .cli file 
  3. Go to Administration --> System Administration --> Configuration Script and Template Import
  4. Select the uploaded .cli file and select the startImport button.

Platform/Feature: SBC

The code is modified to provide an immediate response and get the Status api to read the current status of the running importCLI in every 5 seconds to know about the process status.

Workaround: N/A

SBX-970612

The SCM coredumps after PRACK.

Impact: The SCM coredumps because of the double free of Dialog Scope Variable Data.

Root Cause: Double free of Dialog scope variable data is happening when both the SipAdapter profile and Flexible Adapter profile is configured on the same TG.

Steps to Replicate: Please have a SMM Rule to store a dialog scope variable for all messages, with the flexible Adapter Profile with advanced SMM enabled and dialog scope variable rules for messages. Attach to the ingress TG both of them.

And run the 18x/Prack call flow. A coredump will occur.

Platform/Feature: SBC

Added a check for the flexible adapter profile not to use the dialog scope variable data.

Workaround: Do not enable the Advanced SMM on Flexible Adapter Profile.

SBX-97067 / SBX-959123

Portfix SBX-95912: The postgres was logging additional housekeeping.

Impact: An unlimited amount of postgresql log files are being created, which may lead to a disk space issue.

Root Cause: Each postgresql log file is written with a timestamp.

Steps to Replicate: Ensure the postgresql logs are re-rotated properly.

Platform/Feature: SBC

Remove the timestamp from the postgres log file and let the logrotate utility to rotate files weekly or once the files reach a 10M size.

Workaround: Edit the postgresql.conf file to remove timestamp and size restriction. Add a size restriction to logrotate configuration file for postgresql.

SBX-97493 / SBX- 969372

Portfix SBX-96937: Running the sysDump.pl command on Openstack restarts the SBC.

Impact: Running the sysDump.pl command on 8.2.0R0 on the SBC Openstack cloud platforms causes the SBC application to restart.

Root Cause: The Openclovis is monitoring some files as markers, using the notify and taking it down when the file open operations are done.

Steps to Replicate: Once the SBC is up and running, run the sysDump.pl command and enter the default inputs.

The SBC application will not go down.

Platform/Feature: SBC: Platform

As part of sysdump, backing up the /opt/sonus/sbx/openclovis/var/run/notify directory is excluded.

Workaround: N/A

SBX-974943

The PRACK rejected with a 405 error message.

Impact: When the E2Eprack is enabled and the ingress/egress 100relsupport is disabled, then the SBC was rejecting PRACK with a 405 bad request obtained from the ingress side.

Root Cause: "Enabling of PRACK support did not check on the EndToEnd Prack " was leading to the PRACK support to be disabled.

Steps to Replicate: To replicate the issue, make basic call configuration, and then disable 100relsupport on both ingress and egress side and enable endtoendprack. Run the scenario so the ingress invite has supported:100rel, and incoming 18x has required:100rel. As a result, the outgoing 18x will also have a required:100rel and PRACK will be end to end.

Platform/Feature: SBC

Add the EndToEnd PRACK to enable PRACK support.

Workaround: N/A

SBX-97492 / SBX-957411

Portfix SBX-95741: The output of the CDR smmfield is null after the teardown, even though the SBC writes the values to the SMMField.

Impact: When the CDR update and SMMTeardown action are being configured as part of the same SMM Rule, the SMM CDR fields are not being populated.

Root Cause: Before the SMM CDR data is being copied from SG Active context to CCB structure, the SMM CDR data is being cleared.

Steps to Replicate: Create a rule to SMM CDR update and SMMTeardown action being part of the same SMM Rule. Run the call to trigger the SMMTeardown action.

Platform/Feature: SBC

When SMM Teardown action is being selected, if SMM CDR data is there in active context, copy the same to CCB structure.

Workaround:

SBX-97491 / SBX-967402

Portfix SBX-96740: The "maxPduSizeValue: pdusize6kb" must be 6,000 bytes.

Impact: The MaxSipPDU size for "pdusize6kb" has to be 6,000 bytes.

Root Cause: The MaxSipPDU size for "pdusize6kb" is currently considered as 5998 bytes. The PDU received in the SBC with 6000 bytes will fail.

Steps to Replicate: Send a SIP message of size 6000 bytes. The call will not fail.

Platform/Feature: SBC

The MaxSipPDU size for the "pdusize6kb" is updated to 6000 bytes.

Workaround:

SBX-97489 / SBX-966312

Portfix SBX-96631: The dialog variable was not available after SMM Reject.

Impact: Run a Call where the Update is rejected with a 488 error message by the SMM, The Dialog Scope Variable is not available after that.

Root Cause: The Dialog Scope Variables are getting deleted after a Reject Operation.

Steps to Replicate: When the SBC rejects an early UPDATE with the SMM Reject, it clears the dialog variable info and cannot use the dialog variable after the SMM Reject. 

Platform/Feature: SBC

If there is an indialog message, do not delete the Dialog Scope variable for the Reject Operation.

Workaround:

SBX-972033

Improper neutralization of input during a web page generation.

Impact: There was a improper neutralization of input during a web page generation. ('Cross-site Scripting')

Root Cause: There was a missing content-type header in the HTTP Response.

Steps to Replicate: Load the URL with the invalid operation name.

Platform/Feature: SBC

The code is modified to send an appropriate content type and character set information for the requested resource.

Workaround:

SBX-972023

Improper input validation may expose the server.

Impact: Improper Input Validation: HTML forms with disabled validation can potentially expose the server to numerous types of attacks. Unchecked input is the root cause of vulnerabilities like cross-site scripting and SQL injection.

Root Cause: Novalidate was explicitly used in the login form.

Steps to Replicate:

  1. Login to EMA
  2. Go to Browser debug (F12) and to Sources: click on the main.bundle.js and verify if the novalidate is present.

Platform/Feature: SBC

For the Angular 2.x, it is required to manually add this novalidate attribute to ensure all validations are performed by Angular. With Angular 4+, the novalidate is automatically added behind the scenes.
Remove the novalidate attribute now, however Angular adds it internally.

Note: The login form is never used in app, so removed the login component.

Workaround:

SBX-96674 / SBX-951492

Portfix SBX-95149: Direct dial to the call queue and then transfer agent becomes disconnected automatically after 20 sec as TEAMS releases the call.

Impact: A disconnection occurs because the SBC does not acknowledge a message on the egress side.

Root Cause: This is due to some states stuck in the SBC call control.

Steps to Replicate:

1. The PSTN dials the CallQ number. TEAMS1 is configured in call queue.
2. TEAMS1 transfers the call to TEAMS2.

Platform/Feature: SBC

The code is modified so the state transition occurs correctly in the SBC and the message is acknowledged.

Workaround:

SBX-96669 / SBX-946622

Portfix SBX-94662: The SBC was unable to handle emergency calls (E911) when ICE is enable.

Impact: When the call limit for ordinary calls is already consumed on a trunk group, a new 911 emergency call on that trunk group does not complete using the emergency call bandwidth if ICE is also configured on the trunk group.

Root Cause: The issue in the software was not processing ICE data correctly when the call was transitioning from using ordinary bandwidth to using emergency bandwidth.

Steps to Replicate: With the SBC trunk group configured with ordinary call limit and additional emergency call limit and ICE enabled,

1. Establish as many calls as required, routed through the trunk group to consume the ordinary call limit on that trunk group.
2. While the previous calls are active, initiate a new 911 emergency call to be routed through the trunk group and verify if the call succeeds.

Platform/Feature: SBC: Media, SIP

The code is modified to process the ICE data correctly when call is transitioning to using emergency bandwidth.

Workaround:

SBX-964482

ICE not getting completed when the simultaneous ringing enabled.

Impact: When simultaneous ringing is enabled to multiple MS Teams endpoints, in certain cases where ICE stun request are received by SBC before an SDP is received in signaling messages, ICE is not getting completed for the endpoint that answers the call resulting in media to and from that endpoint not flowing via the SBC.

Root Cause: SBC answers first stun message with use candidate and completes ICE learning for that endpoint, subsequent stun messages from other endpoints with use candidate were answered but ignored for ICE learning.

Steps to Replicate: With simultaneous ringing enabled to two MS Teams endpoints, initiate call through SBC to MS Teams and verify that irrespective of which endpoint answers the call voice media can flow via the SBC. Test should be repeated around 10 times and call answered from different end point each time.

Platform/Feature: SBC

Software is updated such that after receiving SDP with ICE ufrag in signaling message the SBC will only complete ICE learning against stun requests that have the same remote ufrag as that received in the SDP.

Workaround:

SBX-97054 / SBX-957112

Portfix SBX-95711: SMM rule failed to be applied at the outgoing 200 OK on the ingress leg.

Impact: When 18x and 200 OK is received Simultaneously from egress, 200 OK will be queued on ingress side until 18x Prack Transaction is completed. So in this scenario 200 OK message Scope variable is being lost

Root Cause: Message Scope Variable Header is lost when 200 OK is queued on the ingress Side

Steps to Replicate: The ingress call leg supports 100rel while the egress call leg does not. The terminating party returned a 180 and then 200 OK after it received INVITE. After the ingress call leg completed the 100rel procedure (received PRACK and returned 200 OK for the PRACK), it failed to apply SMM rule to the outbound 200 OK for the INVITE.

Platform/Feature: SBC

Message Scope Variable Header is stored in the Prack Entry and retrieved when we de-queue again

Workaround:

SBX-97057 / SBX-961702

Portfix SBX-96170: When SBC executes "Teardown" to UPDATE request by SMM, To header and From header of response are malformed.

Impact: Write an SMM Rule to do teardown on Update Request and Error Response has Malformed headers

Root Cause: When we save the server request of Update request we are not saving the optional headers

Steps to Replicate: Write a SMM rule to tear down update request with 415 and issue will be reproduced

Platform/Feature: SBC

The code is modified to save the headers when saving Update message as a server request

Workaround:

SBX-97066 / SBX-967232

Portfix SBX-96723: Zone SMM Profile not working when we do sbxrestart/reboot.

Impact: Attach a Zone Profile with fixed order, and run a call, Zone SMM profile will be applied, do sbxrestart and run the call, Zone SMM is not getting applied

Root Cause: Zone SMM profile is not being restore during sbxrestart

Steps to Replicate: Attach a Zone Profile with fixed order, and run a call, Zone SMM profile will be applied, do sbxrestart and run the call, Zone SMM is not getting applied

Platform/Feature: SBC

The code is modified modified to restore Zone SMM Profile during sbxrestart.

Workaround:

SBX-96696 / SBX-915702

Portfix SBX-91570: Call from MS Teams, and audio loss for 30 seconds and switchover.

Impact: MS Teams to PSTN call flow with DLRBT enabled on a software SBC. If there is an SBC switch-over after the call is established there can be a delay (e.g. 30 seconds) in re-established the media from PSTN to MS Teams direction.

Root Cause: The stored SSN value doesn't get updated before the SBC switch-over occurs, and it cause the SSN jump backwards after switch-over, which cause the one way audio issue for sometime until the SSN value increments past the previously sent value.

Steps to Replicate: MS Teams to PSTN call flow with DLRBT enabled on a software SBC. Perform a switch-over after the LRBT is played and check there is no one way audio issue.

Platform/Feature: SBC

After the LRBT is played the latest SSN value is sent to the standby SBC so it can correct jump the SSN forward on switch-over and media flow continues without delay post switch-over.

Workaround:

SBX-97068 / SBX-959932

Portfix SBX-95993: Generating unexpected re-INVITE request on SBC.

Impact: Extra/Unexpected Re-Invite going out towards INGRESS

Root Cause:

Before Receiving PRACK on INGRESS side, 200OK INVITE received on Egress and processed. Because of it, queuing of SDP is happening.
Just after receiving ACK from Ingress, SIPS will check for any pending local SDP(queued) to send out. If SDP in 200OK sent and Queued are same, it will ignore it. When E2E Update enabled, because of internal logical issue; it is bypassing all other stuff and triggering queued SDP as offer Out.

Steps to Replicate:

Ingress PRACK supported and Egress Not
Enable E2E Update
Before receiving PRACK on Ingress, Trigger 200OK for INVITE on Egress.

Platform/Feature: SBC

Adding check for identifying UPDATE actually received from other leg or it is generated internal while UPDATE processing will solve this issue. As this will have control while sending queued SDP forcefully because of End-To-End Update flag because this has to happen only when UPDATE is received from other Leg and not for internally generated offer.

Workaround:

SBX-97065 / SBX-956731

Portfix SBX-95673: SBC adding bandwidth parameter RR & RS while sending INVITE out.

Impact: SBC adds RR:0 & RS:0 parameters in SDP if there are more than 1 media line.

Root Cause: SIPSG was setting RR & RS to default values only for the first media line and for other media lines it was initialized to 0. Since 0 being a valid value, SIPSG sends RR & RS in the outgoing SDP.

Steps to Replicate: Test with multiple media lines in the SDP as mentioned in the JIRA, the issue will get reproduced.

Platform/Feature: SBC

The fix is set RR & RS to default values for all media lines. If RR & RS is set to default values SBC will not send the RR & RS parameters in the outgoing message.

Workaround: N/A

SBX-97069 / SBX-923861

Portfix SBX-92386: SBC running 721R2 is responding with 'a=inactive' instead of 'a=sendrecv' in 200ok SDP to late media re-invite causing no audio.

Impact: It was not RFC compliant to send a=inactive to the late media re-INVITE after peer put SBC on hold.

Root Cause: Missed requirement.

Steps to Replicate:

Step 1: Generate sipp scripts for the above call flow
Step 2: Set up 7.2.1 system without fix.
Step 3: Run the call flow to see that the problem is observed.

To Verify:
Step 4: Change ScmProcess with release having the fix.
Step 5: Make call to observe that SBX is sending a=sendrecv in 200 OK.

Platform/Feature: SBC

The code is modified to send a=sendrecv to make it RFC compliant.

Workaround: N/A

SBX-97052 / SBX-942522

Portfix SBX-94252: Memory usage exceeds 90%.

Impact:

CLI issue-
Create a new overload profile and attach it to levelMC2 and make the congestion levelMC2 inService. This will throw a CLI error Invalid values: overlapping ranges are not allowed. This is because the values for memory thresholds are zero in a default overload profile and this is lesser than the defaultMc1 profile thresholds which is against the congestion mechanism.
Alarm issue -
Machine congestion alarm was being raised by NRM for breaching memory thresholds. This should not be the case because memory is not part of congestion control.

Root Cause:

CLI issue -
Memory threshold validations are still in place and that should not be done since they are no part of the congestion profile anymore.
Alarm issue -
Memory not being part of adaptive congestion control this should have been removed from the parameters being checked to raise the machine congestion alarm

Steps to Replicate:

CLI tests:
Create a new overload profile and attach it to levelMC2 and make the congestion levelMC2 inService. This will throw a CLI error Invalid values: overlapping ranges are not allowed. This is because the user defined over load profile has memory parameters set zero while the other two default levels have some default values set which are greater than zero. With the fix this issue is not seen since validation in CPX for memory thresholds have been removed.
Alarm test - As we breach each congestion level memory congestion we see two alarms Node Machine Congestion(by NRM) and Resource congestion(by FM). Machine congestion alarm should not be raised because memory is not part of congestion control. As part of this code change the change in memory congestion levels is ignored which will in turn fail to trigger this alarm. Only Resource congestion alarm will be triggered by FM.
- Behavior for defaultMC level settings
Resource congestion for memory is reported only when SBC crosses 90% of memory utilization.
124 01162020 041539.958425:1.01.00.00288.CRITICAL.FM: Resource mem congestion level 3 is approaching threshold 90 sample 89
102 01162020 041543.961601:1.01.00.00289.MAJOR .FM: Node Resource congestion, resource mem level 2.
157 01162020 041544.099152:1.01.00.00290.CRITICAL.FM: .FM .PsAmfHandler: reporting component error, reason: Memory Utilization 91% exceeded threshold of 90%
082 01162020 041548.808371:1.01.00.00291.MAJOR .NRS: Got AMF deactivate command

Platform/Feature: SBC

CLI issue -

Validation in CPX for memory thresholds have been removed.
Alarm issue -
Memory congestion levels have been ignored which will in turn fail to trigger this alarm in NRM. Only Resource congestion alarm will be triggered by FM when the memory breaches 90%.

Workaround: N/A

SBX-96811 / SBX-947322

Portfix SBX-94732: SBX must send FQDN in contact header for MS Teams.

Impact: MS Teams calls should have FQDN in Contact header but in messages sent in response to reINVITE, IP address is used, even when "Use Zone Level Domain Name In Contract" is set in IP Profile.

Root Cause: IP Profile "Use Zone Level Domain Name In Contract" not applied after reINVITE.

Steps to Replicate: Make a SIP - SIP call. Send reINVITE in an MS Teams zone for one of the call legs. The reINVITE succeeds but Contact header in response messages, e.g. 200OK, has IP address, rather than FQDN.

Platform/Feature: SBC

Changed processing so that for MS Teams calls, all responses to a reINVITE have FQDN in Contact.

Workaround: N/A

SBX-97059 / SBX-962651

Portfix SBX-96265: Differential treatment depending on status code of re-INVITE response.

Impact: When 404 Response is received for Re-Invite SBC is Tearing down the call

Root Cause: When 404 Response is received for Re-invite, SBC is sending Internal Error Event rather than Ans-Rej

Steps to Replicate: Run a Re-Invite Scenario and send 404 Response for that

Platform/Feature: SBC

The code is modified to send Ans_Rej Event for Re-invite 404 Response.

Workaround: N/A

SBX-97064 / SBX-963912

Portfix SBX-96391: Session refresh UPDATE should terminate with "E2E UPDATE" flag enabled.

Impact: Run a Call flow where Session Refresh Update is received from Ingress side, and E2E Update flag is enabled, This Update is locally answered and not being relayed

Root Cause: SIP_SERVICE_TYPE_RELAY_UPDATE_WO_SDP bit is not being set on ingress when E2E Update flag is enabled

Steps to Replicate: Run a Call flow where Session Refresh Update is received from Ingress side, and E2E Update flag is enabled.

Platform/Feature: SBC

The code is modified to set SIP_SERVICE_TYPE_RELAY_UPDATE_WO_SDP bit when E2E Update flag is enabled.

Workaround: N/A

SBX-96681 / SBX-933602

Portfix SBX-93360: SBC sending INVITE with SRTP instead of RTP.

Impact: SBC is sending SRTP instead of RTP

Root Cause: The intersection of working psp and peer psp doesnt take place for Stream absent. Hence,SRTP values are never updated.

Steps to Replicate:

  1. Create a UAC with RTP
  2. Create two UAS with SRTP param
  3. Send port =0 for hold response
  4. Check if SBC is misbheaving while sending invite to release hold from far end

Platform/Feature: SBC

The updation for SRTP values for stream absent case is taken care.

Workaround: N/A

SBX-97063 / SBX-963231

Portfix SBX-96323: MIME-Version header is removed on SBC even though the transparency enabled.

Impact: Run a OOD message call flow with Mime Header and Transparency is enabled for Mime Header , Mime Header is not going in the egress message

Root Cause: MIME header is ignored by SIP Parser

Steps to Replicate: Run a OOD Message call-flow with Mime header

Platform/Feature: SBC

Made Parser changes to add MIME header as Transparent header.

Workaround: N/A

SBX-97209 / SBX-968962

Portfix SBX-96896: Upgrading to 8.2 failed.

Impact: When Two Diff IpPeer with same name is configured one in CAPS and other in small letter SBC is coring

Root Cause:

When SBC tries to add second IPPeer entry ,It tries to bind the name for IP Peer,Since there is already another IPPeer with the same name
NamedInsert fails .After that SBC tries to delete the IP Peer entry from the hash.
While deleting IpPeer Entry
SBC tries to delete the response code stats hash table for the peer entry
SipSgDeleteIpPeerResponseHash(peerEntry);

In the routine
SipSgDeleteIpPeerResponseHash(SIPSG_IP_PEER_STR *peerEntry)


responseHashPtr = HashFirst(peerEntry->responseStatsHashTbl);

At this point peerEntry->responseStatsHashTbl is not created and is NULL so this result to coredump

Steps to Replicate: Configure Two Ippeer with the same nam .one in capital letetr and other in small letter

Platform/Feature: SBC

 So the solution is to add a NULL check for responseStatsHashTbl before deleting.

Workaround: N/A

SBX-97114 / SBX-969922

TLS call failures were observed due to a port value set to 1 instead of 5061.

Impact: The SBC uses Port 1 for sending an INVITE out for the TLS protocol when the route header was received without a port.

Root Cause: The issue is because when the route header is received without a port in it, the SIPSG was incrementing the port for the TLS. Since the port was not received, the port received is considered as 0. For the TLS, increment by 1. When incremented, the port becomes 1 and this gets used for send an INVITE that is resulting in calls failing.

Steps to Replicate: Send the Route Header without port Route: <sip:ipaddr:;lr>. The SBC will use port 1 for sending an INVITE that is causing the issue.

Platform/Feature: SBC

The code is modified to check when the port is received in route header or not.
If port is received, then increment the port for the TLS. If it is not received, then increment and allow the SIP stack to handle it.

Workaround: N/A

SBX-96690 / SBX-945391

Portfix SBX-94539: Calls disconnected with 132 after switchover.

Impact: XRES uses altMediaIpAddress got freed unexpectedly in standby XRM when LIF is created.

Root Cause: When standby XRM is notified with LIF allocate request from NRS, it only receives LIF's IP address. Any altMediaIpAddress will not be populated until XRM has replied back to NRS. So when XRM is activating any XRES in the deferred activate list, the activation of XRES using altMediaIpAddress will be failed and freed.

Steps to Replicate: refer to /sonus/sw/Specs/TSBX-94539.txt

Platform/Feature: SBC: CDR, Redundancy

The code is modified skip the XRESs using altMediaIpAddress when LIF is created in standby XRM. And walk through the deferred activate list one more time when altMediaIpAddress is added in standby XRM.

Workaround: N/A

SBX-97914 / SBX-973881

Portfix SBX-97388: After an upgrade to the V08.02.00F001 Inbound calls hold/off-hold and auto attendant call queue failure.

Impact: In certain circumstances, an A to B call gets referred by the B to C. Once the refer is completed, a re-invite from C can result in the SBC generating a re-Invite to A. This re-Invite for the particular scenario and configuration was not being generated in the pre 8.2 SBC releases.

Root Cause: A fix for another scenario where a re-Invite to A was necessary when switching a call out of playing ring back tones, in combination with an additional media stream having been added to the call had a knock on effect of generating the re-invite for other scenarios as well.

Steps to Replicate: Created a required SBC configuration and run following signaling sequence:

  1. Set up call from A to B.
  2. B refers call to C and all signaling to C completes.
  3. C sends re-INVITE to SBC.

Verify that after a fix, the SBC is not sending a re-Invite to A as a result of step 3.

Platform/Feature: SBC

The code is modified to check that number of media streams is changing before instigating checks on the session parameters to decide if a re-Invite is generated.

Workaround: N/A

SBX-959191

The Max Forward Header Support feature is not working for requests from the terminating side.

Impact: The Max Forward Header Support feature is not working for requests from the terminating side. The SBC does not subtract 1 in the Max-Forwards header despite if the rfc7332ValidateMaxForwards is set to enabled.

Root Cause: This issue is caused when a BYE request comes from the terminating side. Any other requests from the originating side are decreased correctly including a BYE request. Handling a Bye from the terminating was not taken care of.

Steps to Replicate:  Enable fc7332ValidateMaxForwards on both TG.

  1. Initiate a call from A to B. The B sends a 200ok to connect the call.
  2. The B send the Bye request. The SBC sends the Bye request to A. Max forward header in the Bye is set to 70.
  3. Check the Max forward, the SBC sends to A. Max forward header must be decremented by one.

Platform/Feature: SBC

When the rfc7332ValidateMaxForwards is enabled and when the Bye is received from the terminating side, decrease the max forward header by one.

Workaround: N/A

SBX-951262

The SCM coredumps after a PRACK.

Impact: The SCM coredumps because of a double free of Dialog Scope Variable Data.

Root Cause: There was a double free of Dialog scope variable data is occurring when both the SipAdapter profile and Flexible Adapter profile is configured on the same TG.

Steps to Replicate: Please have an SMM Rule to store a dialog scope variable for all messages, the flexible Adapter Profile with advanced SMM was enabled and for the dialog scope variable rules for messages. Attach to the ingress TG both of them and run 18x/Prack call flow. A core will occur as a result. 

Platform/Feature: SBC

The code is modified to not access the dialog scope variable data.

Workaround: Do not enable the Advanced SMM on Flexible Adapter Profile.

SBX-947091

There is a "Media Type" length restriction for the SBX-73083.

Impact: Before the fix, the fmt parameter was restricted to only 8 Characters. The customer requested the support for fmt parameters to be up to 255 characters.

Root Cause: This is a new requirement from customers to support the 255 characters for fmt parameter in the media line.

Steps to Replicate: Test by sending a "m=application 16980 TCP xyz121y432i23i4" to the SBC. The SBC will send the fmt parameter "xyz121y432i23i4" as it is to egress leg.

Platform/Feature: SBC

The code is modified to support 255 characters for fmt line.

Workaround: If the fmt parameter is less than 8 characters, there will not be any issue.

SBX-972303

The E2E Prack and the 100rel interworking. The PRACK rejected with 405.

Impact: When the E2Eprack is enabled and ingress/egress 100relsupport is disabled, then the SBC was rejecting the PRACK with 405 bad request obtained from the ingress side.

Root Cause: "Enabling of PRACK support did not check on the EndToEnd Prack " was leading to the PRACK support to be disabled.

Steps to Replicate: To replicate the issue:

  1. Make basic call configuration, and then disable 100relsupport on both ingress and egress side.
  2. Enable the endtoendprack.
  3. Run the scenario where the ingress invite has supported:100rel.
  4. The incoming 18x has required:100rel.
  5. As a result, the outgoing 18x must also have required:100rel and prack should be end to end.

Platform/Feature: SBC

Check that the EndToEnd Prack added to enable PRACK support.

Workaround: N/A

Resolved Issues in 08.02.00R001 Release 

The following issues are resolved in this release:


Resolved Issues

Issue IDSevProblem DescriptionResolution
SBX-94345 2

Development to allow early RTP ICE learning for the MS Teams DLRBT media bypass scenarios.

Impact: In a media bypass call flow with DLRBT enabled, if the MS Teams client takes a long time to answer the call then the ICE processing does not complete. The MS Teams client never sends STUN with useCandidate = 1 because it did not receive responses to the previous stun messages in the first ten seconds for the call.

Root Cause: For an outgoing call, the SBC was not enabling ICE learning and was not responding to stuns until an answer SDP was received.

Steps to Replicate: With MS Teams media bypass and DLRBT configuration on the SBC, make a call from PSTN to MS Teams and delay answering of the call for 30 seconds.

Platform/Feature: SBC

When the SBC receives the first 18x response for the outgoing call, as well as starting the ring back tone based on DLRBT, it also enables ICE learning and does respond to stuns on RTP port.
SBX-944882

Observed a PrsNp coredump in the ISBC when the pkt cable was unplugged from the box with a VmWare platform.

Impact: A cable pull-and -lug of packet ports results in a healthcheck failure causing the SWe to coredump, resulting in a node switchover.

Root Cause: On cable pull, the SWe detects no link on the packet port and calls the ifconfig down to make the VF administrative state down. This may take more time resulting in a healthcheck failure.

Steps to Replicate: Do multiple cable-pulls and -plugs of the packet port on host.

Platform/Feature: SBC

Disable the healthcheck while calling the ifconfig script from the code. 
SBX-944902

Unable to ping the gateway from pkt interfaces of an ISBC instance after unplug-plug of the X540 SRIOV pkt interface cable on the VMware platform.

Impact: Cable unplug-plug of packet ports with a VLAN tag on the VmWare sr-iov set up causes ping loss.

Root Cause: A cable unplug-plug causes the SWe to call an ifconfig down/up, which causes a kernel to send a VLAN del/add notification with vid 0 if the tag exists on the interface. The VMware PF does not reject this VLAN add with 0 and reconfigures the NIC's VLAN filter table resulting in ping loss.

Steps to Replicate: On the VMware sriov packet port, perform a cable unplug-plug of the packet port on a host with a VLAN tag. The ping will stop working.

Platform/Feature: SBC

Reject the request of VLAN del/add with a VLAN id 0 by the kernel.
SBX-963742

Use the correct nif_id in a rx_packet_loop.

Impact: On the VMWare platforms, in distributor model, a call load can have a random signalling packet loss.

Root Cause: Incorrect calculation of the NIF id to derive the signalling or media queue from the distributor to the workers.

Steps to Replicate: On the VMWare, set up the port redundancy with distributor architecture and run the maximum load.

Platform/Feature: SBC

The code is modified to fix the NIF id calculation.
SBX-96333 / SBX-931032

Portfix SBX-93103: No relay of an UPDATE with SDP when the media mode changed and the DRBT is configured.

Impact: When Downstream Forking and DLRBT are enabled, the UPDATE received from ingress are not going out to egress (UPDATE received after the media cut-thru has occurred because of the receipt of the RTP from egress).

Root Cause: SBX-67242 modified the code logic that when an 18x with SDP is received from a particular dialog, it is marked as OA_COMPLETE. If it is marked as OA_COMPLETE, the UPDATEs received are sent to the other leg if that other leg is 100rel/PRACK supported. This issue was caused due to some of the legs not being marked as OA_COMPLETE due to incomplete implementation.

Steps to Replicate: The steps cannot be reproduced.

Platform/Feature: SBC

The code is modified to mark OA_COMPLETE at all those places where the parallelRingPsp is being appended with new SDP's received in 18x's.
SBX-95948 / SBX-927782

Datora:EMA: The edit route action was taking a long time to complete.

Impact: The edit route action was taking long time or failing.

Root Cause: The use of special characters such as # in the Destination National field cause the failure of edit route action.

Steps to Replicate:

  1. Create Route with a special character in Destination National.
  2. Select the Route, which is created in Special Character.
  3. Edit Form is load.

Platform/Feature: SBC

The code is modified to allow a few more special characters to support Destination National field in Edit route.
SBX-96431 / SBX-932622

Portfix SBX-93262: The SBC generates the RTCP goodbye to the ingress after 200 OK.

Impact: When the Downstream forking is enabled and the Early Media Response is set to "last received SDP" - when the call gets answered, the resource chain will be re-built and the RTCP BYE will be generated.

Root Cause: The root cause is from a feature done in SBX-32482. This Jira required that if the ingress peer does not have 100 rel support, and the egress gets multiple 18x's, then force transcode even though the pass through is possible to support the codec change ( expected behaviour as a part of this feature enhancement is 2nd dialog early media should be transcoded without sending SDP in subsequent 18x to ingress peer. )

Steps to Replicate: The steps cannot be replicated.

Platform/Feature: SBC

The code is modified to address the exact scenario that was presented in the previous Jira. Specifically -
1. Downstream forking is enabled.
2. Early media behavior - non FIRST PROV RESP.
3. Only one forking dialogue.
4. No SDP sent in 2xx if 18x reliable.

SBX-955852

Route search by Routing Label was not functional in the 8.1 EMA.

Impact: Route search by Routing Label was not functional in the 8.1 EMA.

Root Cause: Retrieving maximum of 20 labels.

Steps to Replicate:

  1. Log on to EMA.
  2. Click on Configuration->System Provisioning->Routing->Routes.
  3. Click on Routing label scroll bar.
  4. Observe the number of routing labels.

Platform/Feature: SBC

Remove the maximum limit for retrieving the routing labels.
SBX-96430 / SBX-921551

Portfix SBX-92155: The SBC was releasing the call with 504 when the DLRB and Downstream Forking are enabled.

Impact:

  1. Tested with FLRBT and Downstream forking and calls passed.
  2. Downstream forking enabled – calls passed correctly.
  3. If DLRBT and Downstream forking was enabled, the SBC is releasing the call at the moment it receives 200ok for the INVITE and it is sending 504 to ingress and releasing the calls.

Root Cause: Race condition was not handled properly. When the SBC received the first 180 without SDP, the forking list was updated and stored the message. The second time a 18x with SDP is received, the forking list was updated and store the new 18x received. But since RTP learning occurred before, the forking list was not being updated.

Steps to Replicate: The steps cannot be replicated.

Platform/Feature: SBC

If the RTP learning occurs before the corresponding 18x with SDP is received, save the SDP into a queue of possible SDP's to cut-thru for use while the 200 OK is received just in case the 200 OK does not have SDP.
SBX-962822

Unable to delete the User Session from the EMA.

Impact: Unable to delete the User Session from the EMA.

Root Cause: Caused by not removing the session call from the UI.

Steps to Replicate:

Step 1: Login to the EMA with "admin".
Step 2: Navigate to Administration> Users and Session Management> click New User.
Step 3: Create a new user "Test".
Step 4: From a different IP or from different browser, login with "Test" and provide the necessary password changes.
Step 5: After logging in with "Test", it will be logged in "Successfully".
Step 6: In Admin with the logged in browser, navigate to Administration> Users and Session Management
Step 7: Delete the "Test" user session. It will display "Delete successful".

Platform/Feature: SBC

The code is modified to add the missing call when removing the session.
SBX-95662 / SBX-951141

Portfix SBX-95114: The SBC IgnoreTransparency cannot be set on the EMA V6,7.2 and 8+.

Impact: The SBC IgnoreTransparency cannot be set on the EMA V6,7.2 and 8+.

Root Cause: There was no check whether the "not" is applied to a complete expression or not.

Steps to Replicate:

  1. Log on the EMA.
  2. Navigate to All->Profile->Services->Transparency profile->SIP Header
  3. Select a transparency profile.
  4. Click on New SIP Header.

After the previous steps, the "Ignore Transparency " field will become visible.

Platform/Feature: SBC

The code is modified to check if "not" is applied to a whole expression or not.
SBX-96334 / SBX-935461

Portfix SBX-93546: Call transferring a call to the PSTN fails for the second time when the MOH is played in the initial call.

Impact: After multiple times on hold and resume, if the first call transfer fails due to a reject by transfer target, then the transferee and transferor are reconnected successfully. For any subsequent call transfer, the SBC is rejecting the call transfer request.

Root Cause: When the first call transfer fails, the SBC tries to reconnect the original call. As part of this, the original call is not moving to the stable state. Any call transfer request in an unstable state is being rejected by the SBC.

Steps to Replicate:

  1. TEAMS to PSTN1 call.
  2. TEAMS hold and resume the call.
  3. TEAMS transfer call to PSTN2.
  4. PSTN2 rejects the call.
  5. TEAMS resume the call and transfer again to PSTN2.

Platform/Feature: SBC

The code is modified to move the original call state to the stable state during re-connection.
SBX-964042

A link verification through link monitoring fails, causing the link status to bounce frequently.

Impact: In the SWe with port redundancy, Link Monitors bounce on standby ports when there is lot of broadcast traffic.

Root Cause: There is a CLI configuration to allow/disallow broadcast ARP traffic on the standby ports.

admin@vsbc1% set system admin <systemName> linkDetection allowArpBroadcastProbeReply
Possible completions:
disabled enabled

This flag is disabled by default.

This feature was initially supported on the SBC 7K in 5.1 as part of previous bug (SBX-69409). In the SBC 7K, the NP was not allowing broadcast ARP traffic by default and as a result, the application did not need to explicitly set the default value of this flag. However in the SWe, the ARP broadcast traffic was allowed by default and a knob to control this traffic was provided in a hidden file even before this CLI was supported:

standby_rx_broadcast_enable in /opt/sonus/conf/swe/capacityEstimates/.miscConfigSwe.txt

When this feature was extended to the SWe, when application does not set this flag, the NP is referring to this file and enabling it by default.

Steps to Replicate: Bring up the SWe instance with port redundancy and configure the Link Monitors on all ports. Run tshark on standby ports and check if they are receiving any broadcast traffic.

Platform/Feature: SBC

The code is modified to notify the NP of the default setting.
SBX-961232

Observed the NP log flood during a transcode call load in a X710 NIC card.

Impact: Intermittent flooding of the NP log with mbuf exhaustion messages when X710 NICs are used in large SWe/Cloud T-SBCs.

Root Cause: There was a reduction in count of the free mbufs available for the an NIC PMD.

Steps to Replicate: To replicate this issue, on a 32vCPU TSBC instance using X710 VFs for PKT interfaces, run the estimated call capacity using a single PKT interface (either PKT0 or PKT1).

Platform/Feature: SBC

The code is modified to reduce the stress on available mbufs in a high transcode scale deployment.
SBX-962591

Memory leak observed while running an overnight load of a Call Flow with 302 redirection.

Impact: Memory leak in the SWe_NP. The RSS memory of the SWe_NP process increased by 250MB for an over-night run.

Root Cause: In the configuration, the cdr-server configuration was triggering the ACL add/delete frequently. On every add/delete of ACL rule, the SWe_NP spawns a new thread and rebuilds the DPDK trie. There can be two threads running: one for ipv4 and one for ipv6. These threads are not detachable threads. As a result, the default memory allocated for a thread (ulimit -s) does not get back to OS on thread exit, which was causing regular memory leak.

Steps to Replicate:

1. Create a scenario by adding an ACL rule and deleting the same rule in regular time interval in a loop.
2. Observe the SWe_NP memory.

Platform/Feature: SBC

The threads are made detachable by using pthread_detach(pthread_self()), which the memory is freed immediately after the thread exit.

Resolved Issues in 08.02.00R000 Release 

The following issues are resolved in this release:


Resolved Issues

Issue IDSevProblem DescriptionResolution
SBX-878793

When signalingNapt is disabled on the ingress TG, the SBC populates the "PeerIP/Port" with the IP address and port from the Contact header of the incoming INVITE. When signalingNapt is enabled on the ingress TG, the SBC populates the "PeerIP/Port" with the IP address and port where the INVITE came from.

The expected behavior is that the PeerIP/Port would always be populated with the real IP:port where the INVITE came from.

Impact: PeerIP/Port is populated inconsistently.

Root Cause: The SBC is populating PeerIP/Port incorrectly based on whether signalingNapt is enabled or disabled.

Steps to Replicate: N/A

Platform/Feature: SBC

The code is modified to pick IP and port from where the invite is received from
despite signalingNat being enabled or disabled.
SBX-94820 / SBX-915671

PortFix SBX-91567: The RX/TX PDUs/BYTEs not getting updated correctly in the SBC stats file for "SipSigPortStatisticsStats"

Impact: Statistics for the signalling port were not getting updated correctly in the .pms file.

Root Cause: Statistics were not fetched from SIPCM, which is where statistics are maintained. Instead, fields were directly updated from the SIPFE perspective and as a result, the stale counters were observed in the .pms file.

Steps to Replicate:

T1: Configured 2 signalling ports, 1 at ingress and the other at egress then made some calls and observed the .pms file without running the CLI.
T2: Configured 1024 signalling ports at ingress and 1024 signalling ports at egress then made some calls at 100th, 500th and 1000th signalling port, respectively and ensured proper update of statistics in the .pms file.

Platform/Feature: SBC

The code is modified to fetch the statistics from SIPCM and writing to the .pms file correctly.
SBX-947482

(Disable NP Policing based on feature flag) fix was not working on the D-SBC.

Impact: With the spikeAction set to Alarm, the SBC must not discard the non-confirming policer packets. However, on the D-SBC, the SBC was still discarding these packets.

Root Cause: On the D-SBC, the "spikeAction" configuration is found on the M-SBC, while the command to allocate resource comes from the S-SBC. Due to the allocated resources, the policerMode set from S-SBC is not matching with the policerMode (BYPASS) configured on the M-SBC to allow the over flow packets.

Steps to Replicate: The steps cannot be reproduced.

Platform/Feature: SBC

On the M-SBC, when resource allocation/BwChange/Select command is
received from the S-SBC, overwrite the policerMode based onthe "spikeAction"
configuration on the M-SBc.
SBX-946073

Incorrect String with Response Error code 500.

Impact: The SBC is replying to request with 500 error response code to the client with error string as "Internal Server Error".

Root Cause: The SBC is sending string "Internal Server Error" is not correct as per RFC3261 standards.

Steps to Replicate:

Verify the SBC responds to the request with "Server Internal Error" instead of the "Internal Server Error" for 500 response code.

Set Up:

  1. Configure the SBC.
  2. Make a configuration changes so that the SBC replied with 500 Response.
    Example:
    disable the Ingress sip trunk group.
  3. Make a call.

Expected Result:
Verify the SBCs reply with the "Server Internal Error" string for the 500 response code.

Platform/Feature: SBC

The code is modified so the error string for 500 response code is a "Server Internal Error".
SBX-94397 / SBX-94250 2

Portfix SBX-94250: The S-SBC does not send any response after sending "100 Trying" for an incoming INVITE with a SDP that has no codecs in the PSP.

Impact: The SBC does not send any response after sending "100 Trying" for incoming INVITE with SDP that has no codecs in the PSP when precondition interworking is in progress.

Root Cause: The SBC waits on a precondition to complete from the ingress peer and as a result, does not send any response in this failure case.

Steps to Replicate:

  1. Configure the SBC for ingress precondition interworking.
  2. Send an INVITE with codecs not present in PSP.
  3. The SBC must terminate the call.

Platform/Feature: SBC

When there is no codecs in the PSP and precondition interworking is in progress,
the SBC now terminates the call with a 500 internal server error.
SBX-94358 / SBX-93248 1

Portfix SBX-93248: The sonusDatabaseConfigPolicyDataOutOfSync notification is raised from the S-SBC in the OAM network.

Impact: The configuration data is not stored in the policy DB for OAM and managed VM nodes. The PIPE application was used to raise the out of sync traps.

Root Cause: Existing PIPE logic was used to raise out of sync error whenever there is an out of sync condition. The logic is used between a policy DB and config DB.

Steps to Replicate:

  1. There is a PIPE thread that periodically checks for consistency between the Config DB and Policy DB. The interval is configurable.
    CLI Command [set profiles dbSyncCheckProfile DEFAULT syncCheckInterval <interval duration>.
  2. Through CLI as well the user can trigger to verify DB integrity.

    request system admin TACKS verifyDatabaseIntegrity Id all

    The command will trigger a check for the DB integrity and update the sync status and time stamp. It also raises trap if there is mismatch.

    So, a new status type "notApplicable" is added when this command is executed.

    show table system databaseIntegrity

    This command fetches the data updated by the above command and display on the console. Also, the output of this command will show the sync status as "notApplicable".

  3. SBC Application restart.

Platform/Feature: SBC

The SBC application restart used to raise the trap sync during startup of
the PIPE application is used to check for the DB integrity. There is not any
out of sync trap seen after the fix is applied.
SBX-942862

The error response of PRACK must be relayed to the endpoint when the End-End PRACK is enabled and call must not be teared down.

Impact: Call is terminated whenever the error response is received for PRACK and End to End PRACK is enabled.

Root Cause: The SBC terminates the call whenever an error response is received for PRACK.

Steps to Replicate:

  1. End to End PRACK is enabled.
  2. PRACK responded with an error response.

Platform/Feature: SBC

The code is modified so the SBC does not terminate the call when an
error response is received for the PRACK and the End to End Prack is enabled.
SBX-94285 / SBX-91820 / SBX-905402

Portfix SBX-91820: When the SRS does not respond to the SBCs request and if no redundant SRS is configured, the SBC sends BYE towards the SRS without XML. In case of load scenario when there are 'n' number of active calls towards a SRS and if scenario above occurs, the SBC releases entire 'n' recording calls in bulk.

Impact: When the SRS does not respond to the SBCs request and if no redundant SRS is configured, the SBC sends BYE towards the SRS without XML. In case of load scenario when there are 'n' number of active calls towards a SRS and if scenario above occurs, the SBC releases entire 'n' recording calls in bulk.

Root Cause: The API that is responsible for building XML body was not invoked when the release cause code was SIPSG_REC_REL_CLEANUP. This is designed to release the entire recording call when a recorder does not respond for a single call.

Steps to Replicate:

1. The Recording session is established with SRS server.
2. Trigger a Re-Invite scenario in the CS call.
3. The SBC triggers a separate Re-Invite towards the SRS.
4. Let SRS not reply to the Re-Invite.
5. Invite timeout at the SBC will case the above problem.

Platform/Feature: SBC

The code is modified to invoke the API responsible for building the XML body
when the release cause in the code is SIPSG_REC_REL_CLEANUP. The design was
modified to only terminate that particular call that had no response from the SRS.
SBX-94263 / SBX-932612

Portfix SBX-93261: The MSBCs switchover restarted two nodes.

Impact: On a node switchover on the D-SBC set up, the MSBC or SSBC can have SWe_NP coredump.

Root Cause: The issue occurred due to a code optimization in kni thread. The kni thread starts taking 100% CPU on the SWO due to large amount of ICM message flows.

Steps to Replicate: On the D-SBC set up, perform the switchovers on the MSBC

Platform/Feature: SBC

A revert the code optimization done in kni.
SBX-94244 / SBX-766052

Portfix SBX-76605: The SBC must not depend on the processSgCOnfigureWhenTGOOS setting.

Impact: The SBC must not depend on the processSgCOnfigureWhenTGOOS setting.

Root Cause: The SBC is taking the precedence of the processSgCOnfigureWhenTGOOS flag over the internalSipCauseMapProfile.

Steps to Replicate:

1. Configure "TrunkGroupOutOfService" in the existing internalSipCauseMapProfile.
[set profiles signaling sipCauseCodeMapping internalSipCauseMapProfile <profile_name> causeMap
TrunkGroupOutOfService sipCause 504].
2. Attach the configured profile to the signaling zone.
[set addressContext <addressContext_name> zone <ZONE_INGRESS> signaling causeCodeMapping
sipInternalCauseMappingProfile <profile_name>]
3. Set the mode of the "ingress" trunk group as outOfService on the SBC.
[set addressContext default zone <ZONE_INGRESS> sipTrunkGroup <TG_INGRESS> mode outOfService]
4.Enable processSGConfigWhenTGOOS
set addressContext default zone <ZONE_INGRESS> sipTrunkGroup <TG_INGRESS> processSGConfigWhenTGOOS disabled
5. Make an A-B basic call.

Platform/Feature: SBC

The code is modified to make the internalSipCauseMapProfile independent of the processSgCOnfigureWhenTGOOS flag.
SBX-94145 / SBX-937651

Portfix SBX-93765: The CS04A01 lost communication with the CM04A04 and in post-recovery, other m-sbcs cannot communicate to the CM04A04.

Impact: The IPv6 address becomes unreachable in a standby port cable pull scenarios.

Root Cause: The SWe code was not saving the multicast MAC address list and re-applying it on a hardware port during a link up/down event for standby ports.

Steps to Replicate:

  1. Bring down any standby port by cable pull on host.
  2. Configure a new IPv6 address on the pkt port.
  3. Re-insert the cable for same standby port.
  4. Perform a port switchover by plugging out active physical port's cable so that standby becomes active for same port.
  5. Ping the new configured IP from in step 2 from outside.

The ping will fail.

Platform/Feature: SBC

The code is modified to handle the programming of multicast MAC list for standby ports correctly.
SBX-94138 / SBX-940921

Portfix SBX-94092: The MGMT port is not reachable in the SLB.

Impact: The SWe_NP failed to come up in a large SLB cloud instance (i.e. 16 vcpu or more) with port redundancy enabled.

Root Cause: In the cloud, the default value of "DosSupportSecPktPorts" flag is set to "true", and requires an additional rx/worker thread to be spawned in case of port redundancy.

SLB and S-SBC uses standard_signaling_profile for the core partition. S-SBC only uses one worker for all vcpu configurations, where the SLB uses 2-workers for larger vcpus( > 16vcpu). If the DosSupportSecPktPorts=true, there will be additional worker threads required, so for this instance for the SLB, there will be secondary worker threads for each single worker. This case is not supported.

Steps to Replicate: Spawn a 16 vcpu SLB instance in the cloud using a Heat template. Check the MGMT port reachability.

Platform/Feature: SBC

The code is modified to avoid having secondary threads in case of
port redundancy when having two workers.
SBX-94113 / SBX-905812

Portfix SBX-90581: The PCAP file list (PCAP) is not displayed correctly if the file count exceeds more than 130.

Impact: When using the EMA and accessing the Call Trace/Logs/Monitors > Log Management > TShark, the screen does not list the files if there are more than 130 files in the directory.

Root Cause: Mismatch in the response header transfer-encoding.

Steps to Replicate: Create more than 130 PCAP files and try to display them under TShark screen.

Platform/Feature: SBC

The code is modified to display all files when a large volumes of
PCAP files are present.
SBX-93957 / SBX-939001

Portfix SBX-93900: The IPIGs with underscores fails on a MSRP/RCS call on a decomposed SBC.

Impact: The MSRP call on the DBSC fails when configuring an IP interface group name greater than 7 characters.

Root Cause: Incorrect type cast was used while handling the GCID allocation response in the MSBC.

Steps to Replicate: Test a basic MSRP call with an ingress and egress interface group name set to "INTERFACE_LIG1" and "IPINTERFACE_LIG2" respectively.

Platform/Feature: SBC

Use the correct typecasting for all remote resource allocation requests.
SBX-93789 / SBX-911542

Portfix SBX-91154: A call failure due to a FQDN in the request URI.

Impact: When the SBC sends a query for the SRV record to the external server and the Peer Domain in ReqURI is disabled, the SBC intermittently sends a FQDN in the reqURI of egress INVITE. The correct behavior is to the send IP and address in the reqURI of an egress INVITE. Without a fix, the SBC will send FQDN in reqURI even when Peer Domain in ReqURI is disabled.

Root Cause: The SBC does not use a formatted SIP message when the external query is made for finding a SRV record and a record is found in cache. The SBC cannot apply the setting of "Peer Domain in ReqURI" flag in an egress SIP message.

Steps to Replicate:

The following configurations on PSX Set IP PEER as FQDN abc.com instead of an IP address.

  1. Enable "noPortNumber5060" on IPSP [ This is for done for NAPTR, SRV query ]
  2. Disable "Peer Domain in ReqURI " on IPSP [ This is done to make sure we do not send FQDN in egress INVITE's reqURI ]
  3. Use External DNS server.
  4. Configure a SRV record and a record on the external DNS server with different Time To Live values. Run a high number of calls.

Platform/Feature: SBC

The code is modified to have the SBC use a saved formatted SIP message
when the external DNS query is made for a SRV record and a
record is fetched from the cache. This allows the SBC to apply the setting of
"Peer Domain in ReqURI" flag in the egress SIP message.
SBX-936792

The SIP call never connects on the ingress intermittently. (GW-GW call).

Impact: For two-node M-SBC passthrough call, the SIP call never connects on ingress. The call hangs until the call control 5-minute timer expires.

Root Cause: An improper Node GCID setting on the second M-SBC node of a two-node M-SBC passthrough call causes an internal failure, resulting in a hung call.

Steps to Replicate: The steps cannot be replicated.

Platform/Feature: SBC: SIP

The code is modified to add a proper node GCID setting on a
second M-SBC node of a two-node M-SBC passthrough call that
results in successful call set up.
SBX-936782

The DSBC IP and SIP SIG port IP was not reachable after the switchover.

Impact: LIF is activated on standby, even before the PRS process is cleaned up on standby in case the AMF process is terminated.

Root Cause: During the cleanup, the presence of a PRS process was not checked before sending a switchover event to peer.

Steps to Replicate: Kill the AMF process on active and ensure that LIF is not activated on standby before the PRS process is down on active.

Platform/Feature: SBC: Platform, Redundancy

Check for the presence of PRS process before sending
the switch-over event to the peer.
SBX-93557 / SBX-933121

Portfix SBX-93312: The SBC Memory was reading high alerts.

Impact: When the Local Ring back tone is configured on the SBC and the egress endpoint sends a 183 Session Progress with a SDP followed by a 180 Ringing, the SCMProcess does not free up memory allocated even after call is completed. Without a fix, the SCMProcess will leak memory.

Root Cause: When the Local Ring back tone is configured and the egress endpoint sends a 183 Session Progress with a SDP followed by a 180 Ringing, the SCMProcess does not free up media session descriptor structure.

Steps to Replicate:

Run a call load with Local Ring back tone configured and monitor virtual memory usage of the SCMProcess.
With a fix, the virtual memory of SCMProcess will not be high after all calls have been disconnected.

Platform/Feature: SBC

The code is modified to ensure memory is allocated for the
packet service profile structure is freed when no longer required.
SBX-93390 / SBX-922522

Portfix SBX-92252: The SBC was sending an INVITE out for the first user only.

Impact: Native Forking fail was sending out on the 2nd route.

Root Cause: If incoming call has a capital "CALL-ID", the SBC will fail to find the parent incoming call. As a result, forking will not occur.

Steps to Replicate: Treat the "CALL-ID" as case insensitive.

Platform/Feature: SBC

The code is modified to treat the "CALL-ID" as case insensitive.
SBX-933552

The P-Charge-Info header was not relayed by the SBC in an out-of-dialog MESSAGE request, even when the transparency setting is enabled.

Impact: The P-Charge-Info Header is not relayed transparently for OOD Message, even when the transparency profile is enabled for P-Charge-Info.

Root Cause: The P-Charge-Info Header is dropped in case of relay framework.

Steps to Replicate: Run the message OOD that has P-Charge-Info Header in the incoming Message and transparency is enabled for that header.

Platform/Feature: SBC

The P-Charge-Info Header is copied in case of relay framework.
SBX-93099 / SBX-92580 2

Portfix SBX-92580: The SIP domain was missing in the FROM header after an upgrade.

Impact: The DM rule for FROM Uri is not working.

Root Cause: It was introduced by a previous bug to treat the FROM Uri specifically for the RewriteIdentity only.

Steps to Replicate: Configure the PSX for the FROM Uri, and a simple SIP-SIP call. Verify the FROM header is picking up the DM rule of the FROM Uri.

Platform/Feature: SBC

The code is modified to support the old behavior for allowing
FROM Uri to take affect, even when the RewriteIdentity is disabled.
SBX-93070 / SBX-92092 1

Portfix SBX-92092: A possible memory leak in SAM process.

Impact: The SAM process will leak memory in the case where a de-REGISTER is received and then within less than 30 seconds, another REGISTER for same AOR is received.

This will only happen if Multiple contacts per AOR flag are disabled.

Root Cause: The code does not free certain memory blocks in this case.

Steps to Replicate:

1. Multiple contacts per AOR flag must be disabled.
2. Perform a Register for particular AOR and perform a de-register.
3. Within less than 30 secs, re-send the registration for same AOR so that SIPFE selects the same preferred slot that was used for registering the same AOR earlier. By registering multiple users with same time period, leak will be reproduced.

Platform/Feature: SBC

The code is modified to free the memory blocks.
SBX-930652

The SBC discards the inbound RTP stream.

Impact: The SBC discards media packets when a NAT is enabled, with Signaling and media IP listed the same, but the media port is translated by a NAT device.

Root Cause: In 7.2 the SBC has logic to disable a media NAT when the Peer IP and media IP are the same. The logic is causing issues when these IPs are set as true, but the Port is still being translated by a NAT device.

In this case, the peer IP and advertised media IP are 100.65.1.210. The media advertised port is 1132. The actual media is being sent from port 1097. Due to the disabled media NAT, there is no access to the UDP port, resulting in policed media and no audio.

Steps to Replicate:

  1. Enable the media NAT and a new flag (disableMediaNatIfSameMediaAndSigIP)
    1. Make a SIP-SIP call with the media IP and Signaling IP configured the same. Ensure the media NAT is disabled.
  2. Enable the media NAT and disable a new flag (disableMediaNatIfSameMediaAndSigIP)
    1. Make a SIP-SIP call with the media IP and Signaling IP configured the same. Ensure the media NAT is enabled.

Platform/Feature: SBC

The code is modified to enable/disable the logic introduced in a
previous release.

New CLI configuration is introduced as shown below:
addressContext->zone->sipTrunkGroup->Services->natTraversal-
>disableMediaNatIfSameMediaAndSigIP

CLI Syntax example:
set addressContext <name> zone <name> sipTrunkGroup <name>
service natTraversal disableMediaNatIfSameMediaAndSigIp enable

NOTE: The default value of the CLI commands is disabled.

SBX-930631

The SBC SWe 8.01R000 is outOfSync between the CDB and PG/policyDB after Restoring the DB from V07.02.01R002 release.

Impact: The SBC SWe 8.01R000 is outOfSync between the CDB and PG/policyDB after Restoring the DB from V07.02.01R002 release.

Root Cause: The proper code was not present to display load configuration notification at the time of Platform manager login.

Steps to Replicate: The steps cannot be replicated.

Platform/Feature: SBC

The code is modified to display load config notification at the
time of Platform manager login.
SBX-93044 / SBX-924581

The SBC DelayedRBTOnlyIf180Rxd was not working.

Impact: The SBC DelayedRBTOnlyIf180Rxd was not working.

Root Cause: When a 183 with the SDP PEM inactive is received, the SBC is going for tone play when Delayed RBT if a 180 received is enabled.

Steps to Replicate:

  1. Delayed RBT if the 180 is received in tone Profile.
  2. The EMA is enabled and THE Tone Profile is enabled.
  3. The Tone criteria must match for delayed RBT if the 180 is received.
  4. The 183 Response is received with the PEM inactive.
  5. The SBC must not be directed to tone play.

Platform/Feature: SBC

The code is modified so the SBC will not use the tone play when
Monitoring is failed due to an ENO condition.
SBX-929622

The IngressIpPrefix data was deleted when removing the SMM from the TG.

Impact: The IngressIpPrefix data was deleted when removing the SMM from the TG.

Root Cause: When deleting a SMM Profile, the code is deleting the ipPrefix data as well.

Steps to Replicate:

admin@SBC5210b> show table metadata trunkGroupIpPrefixMeta
PREFIX
TG NAME IP ADDRESS LENGTH
------------------------------------
ASTERISK_SIP 10.158.171.6 32
GG_INGRESSTG 10.6.30.137 32
GW_TG 0.0.0.0 0

Platform/Feature: SBC

The code is modified to not delete ipPrefix data when a
SMM profile is deleted.
SBX-92785 / SBX-924702

Portfix SBX-92470: The SAMP had a memory leak.

Impact: Possible slow memory leak in the SAM process when running GW-GW calls.

Root Cause: GWFE is leaking a copy of the incoming PDU, which was queued internally.

Steps to Replicate: The steps cannot be replicated.

Platform/Feature: SBC

The code is modified to free the memory that was being leaked.
SBX-92731 / SBX-91985 1

Portfix SBX-91985: The SIP calls drop with a vertical service code *65 after a minute.

Impact: The SBC is unable to send the ACK to Egress for a call to connect.

Root Cause: There is a logical error when combining multi features (e2eAck, e2eReInvite, and DLRBT)

Steps to Replicate: Configure: e2e Ack, e2e reInvite, and DLRB

Issue 1: Egress response 183(sendrecv), 183(onhold), 180(no SDP), 200OK(sendrecv).
Peer change SDP in the 18x/2xx causing internal offer/answer.
Issue 2: Ingress peer sends reInvite rigth after ACK, causing the internal state is unable to send ACK out.

Platform/Feature: SBC

The code is modified when multi features e2e ack, e2e reIvnite,
and DLRBT are enabled.
SBX-926142

The NESSUS scan reports TLS violations against the SBC 8.0 OAM VNF.

Impact: On OAM nodes for EMA/PM, the TLS 1.0 is enabled along with TLS 1.2. By default only, the TLS 1.2 must be enabled.

Root Cause: On OAM nodes for EMA/PM, the TLS 1.0 is enabled along with TLS 1.2. By default only, the TLS 1.2 must be enabled.

Steps to Replicate:

  1. Deploy an OAM node and check in /etc/apache2/sites-enabled/EMA.conf and 000-default.conf. The SSLProtocol will be set to +TLSv1.0 +TLSv1.2.
  2. With fix build, it must be set to +TLSv1.2 only.

Platform/Feature: SBC

The TLS 1.0 is removed from default SSLProtocol list of the PM/EMA.
SBX-92548 / SBX-920372

Optional fax parameters being parsed by the SBC and as a result, the 200 OK was being discarded.

Impact: There was a parser error for the unsupport t38 attributes.

Root Cause: There was a parser error for the unsupport t38 attributes.

Steps to Replicate: Perform an incoming call with unsupported t38 attributes.

Platform/Feature: SBC

Modify the parser to ignore the unsupported t38 attributes.
SBX-92518 / SBX-920912

Portfix SBX-92091: Call Graphs were showing more calls after an upgrade.

Impact: Stale calls may be found on a newly upgraded SBC, when upgrading from a version older then 6.1.0 to a newer release.

Root Cause: As a result of changes that were made to the call ID in 6.1 code, during LSWU any calls that existed prior to the upgrade and were then modified or terminated after the upgrade started will be left in a hung state.

To clean up the call, use the following commands:
unhide debug
request sbx rtm debug command “cleanup <gcid>

Steps to Replicate:

1. Create audit key greater than 31 by multiple switch over on HA system or by using instrumented code.
2. This will create GCID values using the high bits ( bit 30-31 ) of GCID value.
3. Set up SIP calls on the system.
4. Initiate LSWU on standby and after standby is upgraded to newer version , all the established calls on active will be synced.
5. Start LSWU on active.
6. At this point standby will become Active.
7. Hang up calls which established before standby became Active.
8. Issue "show table global callSummaryStatus" CLI command and for all those calls data will be Unavailable.
9. These calls will consume resources.

Platform/Feature: SBC

The code is modified to prevent calls from being hung during an
upgrade from versions older than 6.1.
SBX-92180 / SBX-908771

Portfix SBX-90877: There was a failover from Node-A to Node-B.

Impact: There was a healthcheck failure while switching from Node-A to Node-B

Root Cause: Functions that configure the DRBD subsystem are taking longer and causing a healthcheck timeout.

Steps to Replicate: The steps cannot be replicated.

Platform/Feature: SBC

The code is modified to run the DRBD set up commands in the
background and unblock the caller immediately.
SBX-92173 / SBX-906192

Portfix SBX-90619: The error status of the import CLI configuration is not reflected in the GUI.

Impact: The error status of the import CLI configuration is not reflected in the GUI.

Root Cause: The session was deleted before the failure message propagated to the UI.

Steps to Replicate: The steps cannot be reproduced.

Platform/Feature: SBC

The code is modified to handle the session timeout.
SBX-921172

After an upgrade, the SWAP partition has the wrong UUID.

Impact: File the /etc/fstab had an incorrect UUID for the swap partition, with the timeout logs were seen on the boot-up.

Root Cause: As part of multiple upgrades going through different versions, the swap partition UUID had been changed but the same is not reflected in the fstab file.

Steps to Replicate: Install/Upgrade to fix version and ensure there is no swap entry in fstab file and that there also is no timeout logs.

Platform/Feature: SBC

The code is modified to remove the swap entry from the
/etc/fstab file as swap is not enabled on the SBC. After
installing/upgrading to the fix version, timeout logs are
not seen on the boot-up.
SBX-92111 / SBX-905842

Portfix SBX-90584: The EMA SMM regular expression was inconsistent.

Impact: EMA SMM regular expression inconsistency.

Root Cause: Earlier when \n\r was used in regular expression in CLI, the corresponding characters (\n,\r) were not visible in EMA.

Steps to Replicate: The steps cannot be reproduced.

Platform/Feature: SBC

The code is modified so if \n\r is used in CLI, it will
show the same in EMA as well.
SBX-919042

The CLI stops at D2SSBC11.

Impact: The SBC web server sessions including the configuration import session were getting terminated during log rotation.

Root Cause: Process was getting killed because of the application session expiring.

Steps to Replicate: The steps cannot be replicated.

Platform/Feature: SBC

Existing sessions are preserved during log rotation.
The configuration import is done with the NOHUP command to
prevent session termination.
SBX-91326 / SBX-908752

Portfix SBX-90875: The LSASBX71 switched over and as a result, both sides cored.

Impact: A bug in GW Signaling code can cause a core when the GW Signaling Links are bouncing.

Root Cause: A bug in GW Signaling code can cause a core when the GW Signaling Links are bouncing.

Steps to Replicate: The steps cannot be replicated.

Platform/Feature: SBC

The code is modified to prevent this core.
SBX-91274 / SBX-904422

Portfix SBX-90442: Dead air on the SBC terminated calls when playing announcements.

Impact: A fix correctly calculates the amount of memory that needs to be freed from the NP (say Y, which is a multiple of certain number of fixed sized buffers) to fit in a new announcement of size WavFile_X. Due to the design, Y is not equal to WavFile_X.

Root Cause: This issue was caused because the max amount of announcements cached in the system was tampered.

Steps to Replicate: Run a customer flow with customer's announcements all dumped into the system.

Platform/Feature: SBC

The code is modified to fix the size calculation, so that the
new announcements get added properly.
SBX-909761

The trunkGroupQoeStatus shows the incorrect values.

Impact: The SBC was showing the static output as 94/93 for Qos parameters even when the trunk was running call. While checking the CDR for the call, the CDR contained invalid values (that depends in RTP packets) for QOS field.

Root Cause: For cloud platforms, the Routing state was fetched from "configContextPtr" where as the Routing state is stored under the "currentContextPtr."

Steps to Replicate:

  1. Set the global qoeCallRouting signalingQosBasedRouting to disabled.
  2. Set the global qoeCallRouting mediaQosBasedRouting to enabled.
  3. Make a call with the Media.
  4. Show the table addressContext default zone as ZONE1 trunkGroupQoeStatus. Verify the value of outbound RFactor.

Platform/Feature: SBC

The code is modified so the QOs value is fixed from the correct context.
SBX-90791 / SBX-904153

Portfix SBX-90415: A bug in the EMA table views.

Impact: All filters are not displayed for the tables like Call Detail Status, Call Media Status, and Call Resource Detail Status.

Root Cause: The code changes were done to display the filters for all columns in the tables mentioned.

Steps to Replicate:

1. Login to the EMA.
2. Navigate to Monitoring > Trunks and Subscribers > Sessions > Call Detail Status screen.
3. Filter the boxes above and the column will be displayed.

Platform/Feature: SBC

The code is modified so all the attributes are marked irrelevant for the filter.

SBX-90761 / SBX-858203

Portfix SBX-85820: The CDR records are broken into multiple syslog messages.

Impact: The CDR records are broken into multiple syslog messages.

Root Cause: There was a limit to the message size of ~1.8K and the CDR messages beyond that will be split into multiple syslog messages.

Steps to Replicate:

  1. Generate CDR's(size>1800) and transfer to remote syslog server.
  2. The SBC now transfers CDR's (size >4K) over to syslog server without breaking into multiple messages.

Platform/Feature: SBC

The code is modified to transfer a complete CDR as one syslog message.
SBX-906011

The Santa Clara SBC02B failover.

Impact: A CHM thread acquired a lock and started a long running operation. The health check timer on another thread waiting for the lock expired and the app crashed.

Root Cause: The issue was from an existing code with locks.

Steps to Replicate: Installed a fix build and ran sanity tests.

Platform/Feature: SBC

The code is modified around the locks used in the CHM and also
around health checks that are disabled for certain activities to
ensure no crashes occur due to health check timeouts.
SBX-902832

The ScmP cored while importing CLI commands from the SBC Configuration Manager.

Impact: The SIP process dumps core while importing the bulk CLI from the configuration manager.

Root Cause: Due to duplicated bug, the FXS files (CLI schema files) were copied to the directory /opt/sonus/sbx/fxs. The copied FXS files resulted in near doubling of CLI execution time, resulting and delayed responses to the health check requests. Overtime, the SIP processing module is unable to respond to the health check request and dumps core.

Steps to Replicate: Source the bulk configuration using the CLI.

Platform/Feature: SBC

The code is modified to prevent the duplicate FXS files from
being copied to /opt/sonus/sbx/fxs directory.
SBX-897411

The CPX may core during an upgrade from V05.01.05R000 to V07.02.01R001.

Impact: The LSWU CLI command returned as a failure due to failure to create a package sub-dir under external directory but the upgrade continued at the backend.

Root Cause: The upgrade script needs to be fixed here to stop the upgrade and exit if the CLI command returns with a sub-dir creation failure.

Steps to Replicate: Test the LSWU to the fix version and verify if the upgrade is successful.

Platform/Feature: SBC

The code is modified to ensure the package sub-dir creation
is successful and if the CLI command returns failure, the
upgrade will not be continued any further.
SBX-88673 / SBX-875271

Portfix SBX-87527: Conflicting IP address settings in the SBC.

Impact: The SBC allowed the user to use the same IP address for route next top that caused a loss of traffic to all off-net peers across this interface.

Root Cause: A 8.2.0 original issue.

Steps to Replicate:

  1. set addressContext default ipInterfaceGroup PKT1_53_PUBLIC ipInterface PKT1_53_PUBLIC altMediaIpAddresses 66.43.97.129
  2. set addressContext default staticRoute 47.44.160.79 32 66.43.97.129 PKT1_53_PUBLIC PKT1_53_PUBLIC preference 100

Platform/Feature: SBC

The code is modified to validate that static route's next hop
IP address is not same as the IP interface's altMediaIpAddress.
SBX-860303

Remove the alarm that shows that the licenses exceeds the system limit.

Impact: The sonusCpConfiguredExceedSystemLimit alarm was raised for the SWE and CLOUD instances. The session limit is depending on the HW(VCPU) being used and the alarm is only applicable for the Hardware platform.

Root Cause: There was no check completed for platform before raising this alarm.

Steps to Replicate:

  1. Verify the SWE or CLOUD SBC instance does not raise the sonusCpConfiguredExceedSystemLimit alarm when the license is installed more than 64000.
  2. Spawn the instance on the CLOUD or SWE
  3. Install the license bundle if on nodelocked /NWDL with any number of session license(SBC-RTU).

Expected Result:
sonusCpConfiguredExceedSystemLimit alarm will not be raised.

Platform/Feature: SBC

The code is modified so only the hardware platform has raised the
sonusCpConfiguredExceedSystemLimit alarm as a session limit.
SBX-758033

The SIP ReInvite race condition causes a call failure for relay cases.

Impact: The SIP ReInvite race condition causes a call failure for relay cases

Root Cause: When the End To End Re-Invite is enabled and the Session Refresh is received, the SBC used to only relay it to another leg skipping Offer-Answer negotiation. This is causing the Race-Conditions and causing call failures.

Steps to Replicate: Enable the End-To-End Re-Invite and run a Session Refresh call flow.

Platform/Feature: SBC

When the End To End Re-Invite is enabled and a
Session Refresh is received, the SBC will process
without skipping the Offer-Answer negotiation. 
SBX-716233

The SMM header criteria was not matching the complete header value.

Impact: The SMM header was criteria not matching the complete header value, it was only checking for the value between <>.

Root Cause: The SMM was only checking the value enclosed between <>.

Steps to Replicate: Write a criteria on header value and the issue will be reproduced.

Platform/Feature: SBC

The code is modified to consider the entire header
when comparing the criterion.
SBX-637212

The Asymmetric PRACK Interworking" was not working as described.

Impact: Whenever any CodecEntry is deleted from codec list in PSP in the PSX, it re-arranges the codec list immediately. There will not be any empty codec entry on the list.

Root Cause: When any CodecEntry is deleted, it was not re-arranging the CodecEntry, which adds a NULL value in that place.

Steps to Replicate:

1. Configure CodecEntry1, CodecEntry2 all the way to CodecEntry12
2. Delete any CodecEntry.

Result: Call will succeed.

Platform/Feature: SBC: ERE

The code is modified so in PostRoute, the
CodecEntry value is re-arranged. There is no
NULL value in between two CodecEntry's.
SBX-94117 / SBX-934562

Portfix SBX-93456: The SWe_NP worker segfault was crashing.

Impact: There is an issue in the JIO (SBX-93456), where the SWe_NP was crashing multiple times due to a skb_work->skb corruption.

Root Cause: When observing the SWe, there is a point in normal media processing ( RTP and RTCP path), where there is an update with the skb_work->skb from addr_ptr that is not necessary, and it may corrupt the skb_work->skb.

The corruption occurs in the path of processing RTCP XR packets, where the addr_ptr moves ahead by few bytes, but the UPP processing expects the MBUF address to be present back at 58 bytes from the addr_ptr.

Steps to Replicate: Run JIO scenarios.

Platform/Feature: SBC

The code is modified to avoid overwriting skb_work->skb from add_ptr.

Test SMM for SBX-96500:

set profiles signaling sipAdaptorProfile "abc" state "enabled" advancedSMM "disabled" profileType "messageManipulation"
set profiles signaling sipAdaptorProfile "abc" rule "1"
set profiles signaling sipAdaptorProfile "abc" rule "1" action "1" type "header" operation "rename"
set profiles signaling sipAdaptorProfile "abc" rule "1" action "1" from type "value" value "Matt"
set profiles signaling sipAdaptorProfile "abc" rule "1" action "1" to type "header" value "From"
set profiles signaling sipAdaptorProfile "abc" rule "1" criterion "1" type "message"
set profiles signaling sipAdaptorProfile "abc" rule "1" criterion "1" message messageTypes "all"
set profiles signaling sipAdaptorProfile "abc" rule "1" criterion "2" type "header"
set profiles signaling sipAdaptorProfile "abc" rule "1" criterion "2" header name "From" 
   condition "exist"

Input the INVITE message:

INVITE sip:4698887001@10.35.71.101:5060 SIP/2.0
Via: SIP/2.0/UDP 10.35.65.46:5060;branch=z9hG4bK0cB00009e5c72593754
From: "sipp" <sip:2144712731@10.35.71.102>;tag=gK0c00018d
To: "sut" <sip:4698887001@10.35.65.45>
Call-ID: 786432_133686613@10.35.65.46
CSeq: 242834 INVITE
Max-Forwards: 69
Allow: INVITE,ACK,CANCEL,BYE,REGISTER,REFER,INFO,SUBSCRIBE,NOTIFY,PRACK,UPDATE,OPTIONS,MESSAGE,PUBLISH
Contact: "sipp" <sip:2144712731@10.35.65.46:5060>
Supported: 100rel,precondition,replaces
Content-Length: 178
Content-Disposition: session; handling=required
Content-Type: application/sdp, msgLen = 582.
269 01282020 155839.915112:1.01.00.12168.Info .SIPCM: SipFeSocketSendMsg - msg = v=0
o=Sonus_UAC 935158 23579 IN IP4 10.35.65.46
s=SIP Media Capabilities
c=IN IP4 10.35.65.46
t=0 0
m=audio 1024 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=sendrecv
a=maxptime:60
, msgLen = 169.

Known Issues

Known Issues in 08.02.04R000 Release

There are no known issues in this release.

Known Issues in 08.02.03R000 Release

The following issues exist in this release:


Known Issues

Issue IDSev

Problem Description

Impact/Workaround                            

SBX-1028973The surrogate registration subscriberNumbers has a CLI limitation introduced in SBX-102495.Impact Statement: As part of the SBX-102495, there was a limitation introduced that any subscriberNumber related command (profiles->services->surrogateRegistrationProfile->aorUserName->subscriberNumbers) needs to be part of a separate commit. Two or more subscriberNumbers related commands cannot be part of the same commit.

Workaround: Have the subscriber number related commands as part of separate commits.

SBX-1032812The route data was lost after an offline PM upgrade from the 625R0 to 823A13.

Impact Statement: The special character data was not getting migrated to the postgres version.

Workaround: None.

SBX-1040361If the SBC is playing a tone with AMR-WB codec with mode-set=0 and if the answer received in 200 OK SDP (say AMR codec) from UAS is different from that of a tone codec, then the SBC is not sending a re-INVITE towards the ingress peer with the final negotiated codec(say AMR) after the tone is aborted.

Impact Statement: The issue may lead to a two way audio issue.

Workaround: If an extra codec of AMR-WB mode-set=0 is added to the ingress Route PSP keeping all other configurations the same, then the call flow works correctly.

Known Issues in 08.02.02R000 Release

The following issues exist in this release:


Known Issues

Issue IDSev

Problem Description

Impact/Workaround                            

SBX-1008433The GR-HA leader election could choose starting node that is not in sync.Impact Statement: The chosen leader, for the systems that are configured for the GR-HA's enhanced leader election capability, are unable to go active and restarts, causing a full outage.

Workaround: None.

SBX-1011662Deleting the SIP Adaptor profile with hundreds of rule shows "application timeout".

Impact Statement: The deletion of SIP Adaptor profile fails if there are hundreds of rules configured as part of the profile.

Workaround: Delete the rules configured in the profile before deleting the SIP Adapter profile.

Known Issues in 08.02.01R001 Release

The following issues exist in this release:


Known Issues

Issue IDSev

Problem Description

Impact/Workaround                            

SBX-98356 / SBX-983882The SCM coredumps during a surrogate de-registration.Impact Statement: After successful surrogate registration, if any configuration related to the IP Peers/TGs/Surrogate registration is deleted, the Scm Process will coredump.

Workaround: Do not delete any Trunk Group's to avoid SCM cores.

SBX-989781The VnfrProcess coredumps after upgrading the OAM from 8.2.0R002 to 8.2.1R000 if the OAM is upgraded using a stack rebuild.

Impact Statement: The VnfrProcess coredump is observed if the OAM is upgraded from 8.2.0R002 to 8.2.1R000 if the upgrade is done using a stack rebuild.

Workaround: Use stack delete and stack create to upgrade the OAM. 

Known Issues in 08.02.01R000 Release

The following issues exist in this release:


Known Issues

Issue IDSev

Problem Description

Impact/Workaround                            

SBX-98356 / SBX-983882The SCM coredumps during a surrogate de-registration.Impact Statement: After successful surrogate registration, if any configuration related to the IP Peers/TGs/Surrogate registration is deleted, the Scm Process will coredump.

Workaround: Do not delete any Trunk Group's to avoid SCM cores.

SBX-989781The VnfrProcess coredumps after upgrading the OAM from 8.2.0R002 to 8.2.1R000 if the OAM is upgraded using a stack rebuild.

Impact Statement: The VnfrProcess coredump is observed if the OAM is upgraded from 8.2.0R002 to 8.2.1R000 if the upgrade is done using a stack rebuild.

Workaround: Use stack delete and stack create to upgrade the OAM. 

Known Issues in 08.02.00R001 Release

No known issues exist in these releases.

Known Issues in 08.02.00R000 Release 

The following issues exist in this release:


Known Issues

Issue IDSev

Problem Description

Impact/Workaround                            

SBX-939922Post switchover SBC generates RTCP packets for ongoing calls which have RTCP relay between endpoints and have RTCP termination enabled.Impact Statement: The SBC generates RTCP post switchover for ongoing calls, irrespective of RTCP generate state, which are Halt or Generate RTCP.  New calls will behave as expected, acting upon RTCP Generate state.

Workaround: None

SBX-94346

1Transcoded HPC call failures observed when running high load for GETS beyond recommended call capacity for HPC.Impact Statement: HPC calls and normal calls are dropped with 503 reason code when the SBC is operating beyond recommended call capacity.

Workaround: Decrease the HPC call load to 12% of call capacity, wihich is within the recommended value.

SBX-94352

2

Packetloss and packet discards are not logged in CLI and CDR for T.140 streams with total packets less than 32.

Impact Statement: For T.140 streams with total packet less than 32 no packet loss statistics is reported. Statistics are reported correctly for T.140 steams with more than 32 packets.

Workaround: None

SBX-94491

1

Media switchover delay can be around 5 seconds for ungraceful reboots of cloud SBC.


Impact Statement: Media switchover over delay can be around 5 seconds for specific case of active SBC ungraceful reboot. This is not applicable to I-SBC, SBC 5400 or 7000.

Workaround: Issue sbxstop before reboot to ensure graceful reboot.

SBX-94532

2

Exposure to few security vulnerabilities that require kernel patch and updates.


Impact Statement: Exposure to few security vulnerabilities for SPECTER and MELTDOWN that requires kernel patch and updates.

Workaround : None

SBX-94598


2

SBC relays the RTCP for text streams from MRF towards UE even though RR/RS is set to zero.

Impact Statement : SBC relays the RTCP from MRF towards UE even though RR/RS=0 as MRF is not honoring the RR/RS=0 for text streams.

Workaround: Apply SMM to add RR/RS=0 for text stream in 2xx received from MRF if the offer sent by the SBC had RR/RS=0.

SBX-94693


2

Media information is not updated in Recording CDRs for SIPREC calls in D-SBC.

Impact Statement: Media Information is not updated in Recording CDRs on a DSBC Set up for SIPREC calls. Impacts debugging of SIPREC calls. This issue is not seen on I-SBC, SBC 5400 or SBC 7000.

Workaround: None

SBX-94838


2Securelink access does not work for SBC 5400 Standby server when all four management interfaces are configured and in use.Impact Statement: Securelink connection establishment fails on 5400 when all four management interfaces are configured and in use.

Workaround: Add static route for securelink server via mgt0 and mgt1:

ip route add securelink_ip via next_hop_ip mgt0

 

or

 

ip route add securelink_ip via next_hop_ip mgt1

 

SBX-93930


2I-SBC generates unexpected Re-Invite towards egress leg for T.140 transcode call.Impact Statement: I-SBC sends an unnecessary Re-Invite to egress leg after receiving 200 OK for T.140 transcode call. This should not impact the ongoing call.

Workaround: Enable minimizeRelayingOfMediaChangesFromOtherCallLegAll in PSPs.

SBX-94559


2

SBC spordically fails to accept calls with RTCP generation enabled under load conditions.

Impact Statement: The SBC fails to enable RTCP packet generation on one in million calls and drops the call.

Workaround: Disable the RTCP generation.

Known Limitations

The following limitations exist in this release:

  1. Due to a known EMA GUI issue, it can take up to 10 minutes to process and commit an SMM profile. This may be seen when the profile contains the max of 256 rules within it and provisioning of the SMM profile is being done using the EMA GUI. This will be fixed in a future release.

  2. 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.
  3. 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.
  4. The Antitrombone feature is not supported on the D-SBC.
  5. 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.
  6. 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 SBC Configurator and is shared among all the other SBC SWe Cloud instances in the cluster.
  7. Editing 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.
  8. 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.

The VLAN tagged SRIOV packet interfaces are unable to ping endpoint Gateway IPs in the VMware platform because of an issue with VMWare.

Performing Heat Stack Update when userdata is Updated with SSH Keys

When upgrading SBC SWe cloud instances to release 8.0, you must update your Heat template userdata section to include mandatory SSH key information. An issue in OpenStack requires that you use the stack-update process rather than re-launch after updating the template, which leads to a new UUID for the instance. As a result, you must regenerate and apply new license bundles to the upgraded instances during the upgrade.

Refer to Upgrading SBC SWe N:1 HA Nodes on OpenStack using Heat Templates for the relevant procedure. 

Restricted Functionality with SBC

The following functionalities are not supported with SBC Microservices:

  1. Direct Media and Antitrombone 

  2. Far end NAT traversal

  3. NICE

  4. Rx, Rf interfaces

  5. Fax detection

  6. ICE/STUN

  7. SIP REFER

  8. SIP REPLACE

  9. Two stage calls

  10. H323 support

  11. IMS LI support for multiple streams

  12. MS Teams

  13. Tones and Announcement using TSBC