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-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.01R001 release.

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

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

BMC: V03.21.00-R000

BIOS: V1.18.0

SBC 7000 Firmware

BMC: V03.21.00-R000

BIOS: V2.14.0

SBC Application

 


Operating System (OS) Version

V07.02.01-R001
SonusDB

V08.02.01-R001

SBC Application

V08.02.01-R001

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

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.21.00-R000.img

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

  • bmc5X00_v3.21.0-R0.rom.md5sum

  • bmc5X00_v3.21.0-R0.rom

SBC 5400 Firmware

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

SBC 7000 Series Firmware

  • firmware-7X00-V03.21.00-R000.img
  • firmware-7X00-V03.21.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.01R001-connexip-os_07.02.01-R001_9_amd64.iso
  • sbc-V08.02.01R001-connexip-os_07.02.01-R001_9_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.01R001-connexip-os_07.02.01-R001_9_amd64.qcow2
  • sbc-V08.02.01R001-connexip-os_07.02.01-R001_9_amd64.qcow2.md5
  • sbc-V08.02.01R001-connexip-os_07.02.01-R001_9_amd64.ova
  • sbc-V08.02.01R001-connexip-os_07.02.01-R001_9_amd64.ova.md5
  • sbc-V08.02.01-R001.x86_64.tar.gz
  • sbc-V08.02.01-R001.x86_64.md5
  • sbc-V08.02.01-R001.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.01R001-connexip-os_07.02.01-R001_9_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.01R001 Upgrade Information

Warning

Prior to performing an upgrade to release 08.02.01R001, 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.1R001

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 announcment "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.01R001 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.

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.02.00R000
V06.00.00F003V07.00.00F004V08.02.00R001
V06.00.00F004V07.00.00F005V08.02.00R002
V06.00.00F005V07.00.00F006V08.02.01R000
V06.00.00F006V07.01.00R000
V06.00.00F007V07.01.00R001
V06.00.00F008V07.01.00R002
V06.00.00F009V07.01.00R003 
V06.00.00F010V07.01.00R004
V06.00.00F011V07.01.00F001
V06.00.00F012V07.01.00F002
V06.00.00F013V07.01.00F003
V06.01.00F001V07.02.00R000
V06.01.00F002V07.02.00R001
V06.01.00F003V07.02.00R002
V06.01.00R000V07.02.00S809
V06.01.00R001

V07.02.00S810


V06.01.00R002V07.02.01R000
V06.01.00R003V07.02.01R001
V06.01.00R004V07.02.01R002
V06.01.00R005 V07.02.01R003
V06.01.00R006V07.02.01R004
V06.01.00R007V07.02.01F001 
V06.01.00R008 V07.02.01F002 
V06.01.00R009V07.02.01F004 
V06.02.00R000V07.02.01F005 
V06.02.01R000V07.02.01R005
V06.02.01R001V07.02.01R006
V06.02.01R002 V07.02.01R007
V06.02.01F001V07.02.01R008
V06.02.01F002V07.02.01R009
V06.02.01F003V07.02.02R000
V06.02.01F004V07.02.03R000
V06.02.01F005V07.02.03R001
V06.02.01F006

V06.02.01F007

V06.02.01F008

V06.02.01F009

V06.02.01F010

V06.02.01F011

V06.02.01F012

V06.02.02R000

V06.02.02R001

V06.02.02F001

V06.02.02F002

V06.02.02F003

V06.02.02F004

V06.02.02F005

V06.02.02F006

V06.02.02F007

V06.02.02F008

V06.02.02F009

V06.02.02F010 

V06.02.02F011

V06.02.02F012

V06.02.02F013

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

New Features

New Features in Release 08.02.01R001

There are no new features in this release.

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.01R001 Release 

The following issues are resolved in this release:


Resolved Issues


Issue IDSevProblem DescriptionResolution
1SBX-99921 / 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 the 3xx are not sent as parameters in a Request URI if they are not processed by the SBC.

Root Cause: When implementing the changes for this new flag in the 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 the PSX for the TG1 and returns the Redirector IP as part of the reply.
  3. The SBC sends the Egress Invite towards the SBC and to the Redirector.
  4. The Redirector sends 3xx with the contact containing UAS IP and DTG info as mentioned below:

Contact: <sip IP address>:5060;dtg=SBC2_INGRESS_TG>

Expected Result:

The SBC should send the redirected INVITE towards the UAS with the dtg info in the egress INVITE's request URI.

Actual Result:

The SBC does not send the redirected INVITE towards the UAS with the dtg info in the egress INVITE's request URI

Platform/Feature: SBC

The code is modified to fix the issue.

Workaround: Enable the honorEmbeddedHeadersIn3xx or includeEmbeddedPAIheaderInRedirectedInvite parameters to fix this issue.

2SBX-99888 / SBX-996101

Portfix SBX-99610: The SBC is coring on the SCMP process 3 on a switchover.

Impact: The SCM 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

3SBX-100006 / SBX-1000022

Portfix SBX-100002: The JIP parameter is not being sent in a PAI header.

Impact: The JIP parameter received in the 3xx was not sent in a PAI header

Root Cause: The root cause is due to Enhanced Local Redirection changes done in 7.2.3 R1.

Steps to Replicate: 

  1. Make a SIP-SIP call with JIP in the JIP parameter in PAI header.
  2. The Egress send 302 Moved Temporarily with different JIP value.

Expected Results:

  1. An INVITE received with JIP in the JIP parameter in PAI header.
  2. The SBC sends another INVITE with JIP as received in 302 in JIP parameter in PAI header.

Issue observed:
A JIP parameter is not present in PAI header sent by the SBC after 302 is received by the SBC.

Platform/Feature: SBC

The code is modified to fix the issue.

Workaround: N/A

4SBX-99975 / SBX-996513

Portfix SBX-99651: The SWe_NP crash to decrypt the SRTP packet.

Impact: A sporadic crash observed in the SWe_NP GCM decryption during a SRTCP packet processing.

Root Cause: In the distributed SWe NP packet and API processing model, a race condition results in processing the SRTCP packet when the crypto context is already cleared with a call disable and causing this sporadic crashes.

Steps to Replicate: Test the call media load with GCM SRTP, SRTCP and verify the SBC is not running in to any issues. 

Platform/Feature: SBC

The code is modified to correctly handle the scenario by discarding media packets with cleared GCM crypto contexts. In the latest releases, the SWe NP worker models, and spin locks also enabled in all the SBC variants to prevent race conditions.

Workaround: N/A

5SBX-99954 / SBX-999233

Portfix SBX-99923: The HW SBC GCM SRTCP encrypted packets are dropped by the SBC.

Impact: The HW SBC GCM SRTCP encrypted packets are dropped by the SBC.

Root Cause: The HW SBC is not including an E bit along with the SRTCP index in the GCM SRTCP encryption that results in dropping the SBC decryption error.

Steps to Replicate: Test calls between the HW SBC and the SBC with GCM crypto suites, and verify the SRTP/SRTCP packets are decrypted, relayed fine.

Platform/Feature: SBC

The code is modified to include E bit along with SRTCP index in GCM SRTCP encryption.

Workaround: N/A

6SBX-99650 / SBX-956792

Portfix SBX-95679: There cannot be trunk data on a live monitor.

Impact: The Zone and Trunk Group based on the live monitor charts does not show any data if the trunk group name contains a hyphen.

Root Cause: The Elastic Search interprets a 'hypen' as a delimiter as a result the string is broken down into tokens for indexing. When querying 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 trunkgroup with name containing hyphen.
2. Enable the Live Monitor.
3. Run calls and wait for sometime.
4. Verify that the data is shown in Zone and Trunk Group based charts.

Platform/Feature: SBC

The code is modified so if the data contains a hyphen, it is broken into tokens and the token is used to query for data.

Workaround: N/A

7SBX-99361 2

There is a bug in the “clearTcpConnectionsforRegistration" functionality that causes a memory leak.

Impact: There is a bug in the “clearTcpConnectionsforRegistration" functionality that causes a memory leak.

Root Cause: The code that handles the clearTcpConnectionsforRegistration flag is allocating memory to store the Hostname and Username – but it is not freeing this memory.

Steps to Replicate: Set up the configuration with the “clearTcpConnectionsforRegistration” flag set. Run load with Registrations and de-Registrations.

Platform/Feature: SBC

The code is modified to free the memory that is allocated to store the Hostname and Username.

Workaround: The workaround is to set the clearTcpConnectionsforRegistration to disabled on the TG.

8SBX-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 it was unable to create a domain controller. However, the CLI was accepting special characters to the username and 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 delivered an error.

Steps to Replicate: The steps cannot be reproduced.

Platform/Feature: SBC

The code is modified so the EMA validates the username param based on default regex that is in yang file.

Workaround: N/A

9SBX-961112

The SBC needs to add an ability to pass the newly determined Ingress IPTG to the PSX on top of SBX-88542.

Impact: The profile "sipsgSipParamBasedAction" added as part of SBX-88542 is being used to select the new ingress TG based on the SIP headers received. The new TG selected using this method used for only for the SBC profiles and still sends the original TG in policy request. Using the "sipsgSipParamBasedAction" storeIpTg functionality cannot be achieved, because in the storeIpTg operations requires the new ingress TG needs to be sent in policy request, so that cannot be achieved using sipsgSipParamBasedAction.

Root Cause: There is no direct root cause.

Steps to Replicate: Configure the operation as "storeIpTg" in sipsgSipParamBasedAction profile to achieve storeIpTg functionality.

Platform/Feature: SBC

The code is modified to support the storeIpTg operation. When the operation is set to "storeIpTg" in sipsgSipParamBasedAction, the SBC sends a new ingress TG in policy request.

Workaround: N/A

10SBX-932391

The caller ESBC cancels the call after 180: 504 to the ingress, and sends CANCEL to egress.

Impact: The late media convert call with DLRBT is not working.

Root Cause: Bad resource activation.

Steps to Replicate: Setup a late media convert call with DLRBT enabled.

Platform/Feature: SBC

The code is modified so when the DLRBT is being played, to stop activating the full resource chain when the tone is being played.

Workaround: This is a loopback call to the SBC. There is an issue in the first call where the DLRBT and late media convert to enabled. If the late media is kept as a passthru for the first call and late media as convert in the second call's TG, this is expect to work. Test in lab network before using this workaround in production.

11SBX-99560 / SBX-991893

Portfix SBX-99189: Save the dialog broken in the create custom perspective.

Impact: Save the Dialog box is enlarged  causing users to scroll to see the full dialog box.

Root Cause: Broken while implementing another JIRA.

Steps to Replicate: 

  1. Log into EMA.
  2. Go to Custom > Create/ Edit Custom Perspective.
  3. Click the New Perspective.
  4. Add a menu to new perspective and click "Save Perspective" button.
  5. Save the dialog when it appears normally.

Platform/Feature: SBC

The code is modified to make a white-space to nowrap to fix this issue in a CSS file.

Workaround: N/A

12SBX-99708 / SBX-961552

Portfix SBX-96155: Unable to view the error message in the View Config Summary page.

Impact: The custom exceptions are not passed to the UI.

Root Cause: The custom exceptions are not passed to the UI.

Steps to Replicate: 

  1. Copy a bulk configuration file [ Eg: concise-config_1_2017-08-23-05-27-20.xml ] which has size more than 5MB to sbc in /var/log/sonus/sbx/config path.
  2. Login to EMA as admin user.
  3. Navigate to Administration >System Administration >View Config Summary
  4. Click on view button of the configuration file listed in the table.
  5. Select Content as Overview Configuration.

Expected Results:

Since the file size will go beyond 5MB, the GUI throws an error stating clearly that file size is beyond the allowed limit for this feature.

Actual Results:

Since the file size will go beyond 5MB, the GUI throw an error stating clearly that file size is beyond the allowed limit for this feature.

Platform/Feature: SBC

The code is modified so the custom exceptions are sent to the UI.

Workaround: N/A

13SBX-100663 / SBX-1004421

Portfix SBX-100442: The SBC sends a 403 Forbidden when receiving a Refresh SUBSCRIBE message.

Impact: The initial registration is done for the user. A subscribe came from a registered user and the subscription is active.

When a subscription is active, the user got de-registered (or the registration lost). After the loss of registration for the refresh SUBSCRIBE for an existing subscription, the SBC is rejecting the refresh SUBSCRIBE saying the user should be registered.

Root Cause: The SBC rejecting the refresh SUBSCRIBE when it comes with in a existing SUBSCRIPTION when the registration is not available.

Steps to Replicate: 

  1. Initially register the user.
  2. Send 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 so that when the active subscription is available and registration is lost, the system accepts the refresh SUBSCRIBE instead of rejecting it.

Workaround: N/A

14SBX-99714 / SBX-572002

Portfix SBX-57200:  Implement the EMA Solution for the SBX-56878 feature: CDR Viewer and Live Monitoring cannot be enabled/disabled.

Impact: Due to the Red-Indices, the CDR Viewer and Live Monitoring cannot be enabled/disabled.

Root Cause: Due to the Red-Indices, the CDR Viewer and Live Monitoring cannot be enabled/disabled.

Steps to Replicate: 

  1. Have the Red-Indices file.
  2. Try to enable/disable(Change state) of Live Monitor and CDR Viewer.
  3. Wait for the 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 are present and to handle the class instead of throwing exception, it catches.

Workaround: N/A

15SBX-1005723

The routing label route forms zone value resets on the changing IP Peer/Trunk Group.

Impact: The zone value resets to the first value of the Zone in the RLR form on changing a Trunk Group or IP Peer

Root Cause: Selected Zone value did not get patched to the from data.

Steps to Replicate: 

  1. Go to the Routing Screen.
  2. Select any of Routing Label to edit, and click Add Routing Label Route.
  3. Select the Second Zone from the list.
  4. Then change the Trunk Group / IP Peer.

Expected Result:
The Zone value should be retained instead of Reset.

Platform/Feature: SBC: EMA

The code is modified to form data whenever a change occurs in the Trunk Group or the IP Peer to fix the issue

Workaround: N/A

16SBX-100509 / SBX-990132

Portfix SBX-99013: A different JIP parameter is being sent by the SBC in 3xx scenarios.

Impact: The JIP parameter sent by the SBC in the P-DCS-Billing-Info in the redirected INVITE is not same as the JIP parameter present in the 302 received.

Root Cause: The SBC was not saving the JIP parameter present in the redirected INVITE properly into message Info. As a result, the information was lost and the incorrect JIP parameter was sent in the redirected INVITE.

Steps to Replicate: 

  1. Enable the 'Determine JIP' in the feature control profile on the ingress trunk group.
  2. 'Send' flag for JIP in a Signaling Profile on the egress trunk group.
  3. Configure 'Include Privacy' for the P-DCS-Billing-Info header.
  4. Use JIP from 3xx in the IP Signaling Profile.
  5. Configure the globalized flag for JIP.
  6. Enable transparency for the PDCS header on 1st IP TG.
  7. Configure a standard route entry for the redirection number sent in contact in the 302, so that the call is routed to a different IP trunk group. Configure this IP trunk group same as the first IP trunk group.

Test Procedure

  1. Make a SIP-SIP call with JIP in jip parameter in P-DCS-Billing-Info header.
  2. Egress sends the 302 Moved Temporarily with different JIP value and contact points to the SBC IP.

Platform/Feature: SBC

Before framing the redirected INVITE, the SBC saves the JIP parameter in the message info so that while forming a redirected INVITE, the SBC picks the correct JIP parameter.

Workaround: N/A

17SBX-100832 / SBX-996771

Portfix SBX-99677: A SCM process core dump was observed for the challenged INVITE call.

Impact: A SCM core dump occurred when running an INVITE challenge call flow.

Root Cause: Buffer is becoming zero that is why there is a 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 in normal mode.

18SBX-945182

Disable the media lockdown does not suppress a media lockdown re-INVITE when the SRTP is enabled.

Impact: If the SBC offers crypto, and peer does not reply with crypto in the answer, a re-INVITE is sent to lockdown the crypto attribute ( no crypto ). If NAT is enabled, there is a one second media drop while re-learning for the new re-INVITE is occurring. For non-NAT cases, nothing should be observable except for the signaling change.

Root Cause: This was the SBC's original behavior.

Steps to Replicate: 

  1. Setup the SBC so that it sends crypto in an offer.
  2. In answer from the peer, do not send any crypto attribute.

Without a fix, the SBC would send yet another re-INVITE if fallback to an unencrypted is allowed. With a fix, this extra re-INVITE will be suppressed.

Platform/Feature: SBC

If a crypto line is sent in offer and none are received in answer, if minimize media and media lockdown flags are appropriately set to minimize offer/answers, a re-INVITE to lock down cryto attribute is to be not sent.

Workaround: Keep peers who do not support crypto on another TG.

19SBX-965002

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

20SBX-100786 2

The EMA /tmp has been filling the "/var/log/sonus/ema/tmp".

Impact: Performance: The EMA /tmp has been filling the "/var/log/sonus/ema/tmp"

Root Cause: Every time when the start up the SBC it is not created on a new TMP directory.

Steps to Replicate: 

  1. Restart the EMA.
  2. Connect to corresponding SBC box.
  3. Navigate to /var/log/sonus/ema.
  4. In this we can see the newly created tmp directory.

Platform/Feature: SBC

The code is modified to fix the issue.

Workaround: N/A

21SBX-99034 1

A customer reported an issue in the EMA on the SBC Core 8.2.0R0.

Impact: A customer reported an issue in the EMA on the SBC Core 8.2.0R0.

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

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 setup. 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 passthru 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 setup to do transcode only ( but same issue might be observed otherwise also if initially the early media is setup 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-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

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 has been 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: Setup 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 has been 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 has been 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. Setup 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 setup causes ping loss.

Root Cause: A cable unplug-plug causes the SWe to call an ifconfig down/up, which causes a kernel to send a VLAN del/add notification with vid 0 if the tag exists on the interface. The VMware PF does not reject this VLAN add with 0 and reconfigures the NIC's VLAN filter table resulting in ping loss.

Steps to Replicate: On the VMware sriov packet port, perform a cable unplug-plug of the packet port on a host with a VLAN tag. The ping will stop working.

Platform/Feature: SBC

Reject the request of VLAN del/add with a VLAN id 0 by the kernel.
SBX-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 setup, the MSBC or SSBC can have SWe_NP coredump.

Root Cause: The issue occurred due to a code optimization in kni thread. The kni thread starts taking 100% CPU on the SWO due to large amount of ICM message flows.

Steps to Replicate: On the D-SBC setup, perform the switchovers on the MSBC

Platform/Feature: SBC

A revert the code optimization done in kni.
SBX-94244 / SBX-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 P-SBC.

Impact: The MSRP call on the DBSC fails when configuring an IP interface group name greater than 7 characters.

Root Cause: Incorrect type cast was used while handling the GCID allocation response in the MSBC.

Steps to Replicate: Test a basic MSRP call with an ingress and egress interface group name set to "INTERFACE_LIG1" and "IPINTERFACE_LIG2" respectively.

Platform/Feature: SBC

Use the correct typecasting for all remote resource allocation requests.
SBX-93789 / SBX-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 setup.
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 ATT P-SBC DelayedRBTOnlyIf180Rxd was not working.

Impact: The ATT P-SBC DelayedRBTOnlyIf180Rxd was not working.

Root Cause: When a 183 with the SDP PEM inactive is received, the SBC is going for tone play when Delayed RBT if a 180 received is enabled.

Steps to Replicate:

  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. Setup 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 setup 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.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 Setup for SIPREC calls. Impacts debugging of SIPREC calls. This issue is not seen on I-SBC, SBC 5400 or SBC 7000.

Workaround: None

SBX-94838


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 each SMM rule when provisioning SMM on the SBC using the EMA. 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