Table of Contents

About SBC Release Notes

This document 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 07.02.xx documentation is located at the following Wiki space: SBC Core 7.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 Bulletins

The following Ribbon Bulletins are referenced in this release note:

  • Warning-14-00020748: Verify system and databases are fully in sync prior to Live Software Upgrade (LSWU)
  • Bulletin-18-00028529: The System Security Intrusion Detection AIDE Reports False Positive Alarms 

  • Warning-19-00028636: SBC SWe Gateway-to-Gateway signaling is disabled in certain SBC SWe versions 
  • Warning-19-00029555: CDR Viewer and Live Monitoring cannot be enabled/disabled

To view/download Ribbon bulletins, do the following:

  1. Log on to the 
    Support Portal link
  2. Click Announcements link from the menu bar. 
  3. Enter the bulletin number (last eight numbers) in the search field and press Return.
Note

The WBA section may not include all Warnings, Bulletins and Alerts associated with this release. Before attempting to upgrade to any release, it is recommended to check the Customer Portal in Salesforce for any newly published WBAs that may include this release in the "affected versions" section.

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
  • NetScore collection, analysis, monitoring, and reporting of selected Key Performance Indicators (KPIs) on a near-real time basis

Note

NetScore maintains a list of remote host keys for all nodes from which it collects data. If NetScore is deployed in your network, connectivity to the SBC will be lost any time the SBC software is reinstalled because the SBC’s host key is updated during the install. Refer to NetScore Release Notes for steps needed to reconnect to the SBC.

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

Refer to SBC 5000-7000-SWe Interoperability Matrices for the latest and minimum compatible product versions supporting the 07.02.04R002 release.

Compatibility with Ribbon Products

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

Note

For complete interoperability details between various Ribbon products, including backwards compatibility, refer to Ribbon Product Compatibilities.



Refer to SBC 5000-7000-SWe Interoperability Matrices for the latest and minimum compatible product versions supporting all releases. For specific interoperability information for the 07.02.04R002 release, refer to the following table:

07.02.04R002 SBC Core Compatibility Matrix

Compatible Ribbon Products by Version

EMS

PSX

GSX 9000

DSI

NetScore

SBC 1K/2K/SWe Lite

Latest11.02.03R00011.02.04R00111.00.03R00109.03.00P605.01.03R00008.00.01
Minimum11.00.00R00009.03.06R00009.02.07R00009.03.00R00005.01.01R00007.00.00

Sample Heat Templates Included in This Release

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

SBC Heat Templates

 Template NameDescription
heatRgNoDhcp.yamlM-SBC/S-SBC Heat template for No DHCP IPv4 or IPv6. This template include instructions to enable port redundancy.

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 more information on the requirements for the SBC SWe Cloud for OpenStack, refer to For OpenStack.

SBC SWe Requirements for KVM

For more information on the requirements for the SBC SWe Cloud for KVM, refer to For KVM Hypervisor.

SBC SWe Requirements for VMWare

For more information on the requirements for the SBC SWe Cloud for VMWare, refer to For VMware.

Required Software and Firmware Versions

The following SBC 5000 series (51x0/52x0), SBC 5400 and SBC 7000 software and firmware versions are required for this release. For 5xx0 the BIOS can be installed during app install, whereas for 5400 and 7000 the BIOS is included in the firmware package and is 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 BIOSV02.06.00
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

V06.02.04-R002
SonusDB

V07.02.04-R002

EMAV07.02.04-R002

SBC Application

V07.02.04-R002

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 bundles are available for download from the Customer Portal:

  • SBCSWe_7.2
  • SBC5x7x_7.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 3.2.1R0. 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-V07.02.04R002-connexip-os_06.02.04-R002_7_amd64.iso
  • sbc-V07.02.04R002-connexip-os_06.02.04-R002_7_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-V07.02.04R002-connexip-os_06.02.04-R002_7_amd64.qcow2
  • sbc-V07.02.04R002-connexip-os_06.02.04-R002_7_amd64.qcow2.md5
  • sbc-V07.02.04-R002.x86_64.tar.gz
  • sbc-V07.02.04-R002.x86_64.md5
  • sbc-V07.02.04-R002.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. The SBC has several different CSAR variants, for different personalities (S-SBC, M-SBC) and interface types (virtio, sriov). The supported CSAR packages for the SBC are:

  • ssbc_virtio_7.2.csar
  • ssbc_sriov_7.2.csar
  • msbc_virtio_7.2.csar
  • msbc_sriov_7.2.csar

Files required for CSAR creation: 

  • createVnfmCsar.py
  • vnfmSol001VnfdTemplate.yaml
  • sbc-V07.02.04R002-connexip-os_06.02.04-R002_7_amd64.qcow2

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

Upgrade Notes

Warning

Only perform a LSWU on an SBC 70000 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 7.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 07.02.04R002 Release Notes#SBC Core Installation and Upgrade Package) is automatically removed from the system.

Note

As an SBC Core password security enhancement, user passwords automatically expire after upgrading to 7.2.x. As a result, users are required to change their passwords upon initial login immediately following the upgrade.

Note

Customers using the Network licensing mode will stay on the Network licensing mode after upgrade to the SBC 7.2.4 Release.

Customers using Legacy mode will stay on the Legacy mode after upgrade to SBC 7.2.4 Release. Once upgraded to SBC 7.2.4 Release, the customer will not be able to set Network License mode.

Note

The SBC 7.2 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 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.

07.02.04R002 Upgrade Information

Warning

Prior to performing an upgrade to release 07.02.04R002, remove usernames that do not conform to the new SBC user-naming rules to prevent an upgrade failure. 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 7.2.4R002. 

Warning

Prior to performing an upgrade to the 7.2 release, the dnsGroups with type mgmt must be specified/updated with the "interface" field. The steps are included in WBA "W-17-00022847". To view the WBA, log on to the Support Portal and click the Announcement link from the menu bar. Enter the bulletin number (last eight numbers) in the search field and press Return.

Warning

Prior to performing an upgrade to 7.2 release, the duplicate trunk groups or zones must be removed. The steps are included in WBA "W-17-00022689". To view the WBA, log on to the Support Portal and click the Announcement link from the menu bar. Enter the bulletin number (last eight numbers) in the search field and press Return.

If the above MOP is not run, the LSWU process may fail because of duplicate trunk group or zone names.

If you are upgrading from any SBC version with ePSX configuration to the 07.02.04R002 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.

Support of maddr Post-Upgrade

When upgrading SBC Core to release 5.0.0 (and above) from a pre-4.2.4 release, complete the "Action to take" immediately after the upgrade if either condition that follows is applicable:

  • If you are using the SBC with a Broadsoft system and the SBC is configured for registration access (where the SBC sits between SIP phones and the Broadworks System). Otherwise no new REGISTER will be processed (phones will lose registration).
  • If you are using the SBC with other feature servers that require maddr processing.

Action to take: On the SIP trunk group facing Broadsoft (or other feature server), set the SIP Trunk Group signaling flag, honorMaddrParam, to enabled on the Trunk Group(s) requiring maddr handling. The default is ‘disabled’.

set addressContext <addressContext name> zone <zone name> sipTrunkGroup <TG name> signaling honorMaddrParam <disabled | enabled> 

See the following pages for configuration details:

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 WBA "Warning-14-00020748". To view the WBA, log on to the Support Portal and click the Announcements link from the menu bar. Enter the bulletin number (last eight numbers) in the search field and press Return.

Note

The SBC 7.2 release skips the SRV query if the flag in a DNS NAPTR response from the DNS server indicates to proceed with "A" record query as per RFC 2915/3403. This is a change in behavior from previous releases, where the SBC performed SRV queries irrespective of the "flag" setting returned by DNS Server.  If you use DNS NAPTR/SRV/A record query from SBC to determine peer transport address, ensure the DNS Server is configured to return ‘S’ flag to invoke an SRV query.

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.

Please read the following information and take necessary actions before starting your upgrade to this release.

Since the release 4.1.4, the cryptographic key pair used to sign and verify the package has been changed to enhance security. When installing/upgrading from all 4.0.x releases, all pre-4.1.4 releases (4.1.3 and earlier), and all pre-4.2.3 releases (4.2.2R00x and earlier), do one of the following, depending upon your upgrade method:

  • LSWU through CLI: Skip the integrity check during LSWU by using the CLI command below.

    During LSWU, use the integrityCheck skip option when upgrading from CLI:

    > request system serverAdmin <server> startSoftwareUpgrade integrityCheck skip package <package>
    Note

    Integrity check works as expected only when upgrades are started from 4.1.x releases (4.1.4R000 or later) or from 4.2.3R000 or later releases.

  • Upgrade through Platform Manager: If upgrading using Platform Manager, simply ignore the "Wrong Signature" warning message and continue the upgrade normally.
Note

Downgrading to any pre-5.0 release from this release requires a ConnexIP re-ISO installation. For more information, refer to:


Customer running 7.1 or 7.2 releases must check the eventLog configuration to confirm that the memusage log type has a server1 syslog configuration and if it is not present, they need to manually create before attempting to upgrade to the latest code.

The following command example output shows how to confirm with the server1 config is present for the memusage log type:

show configuration oam eventLog typeAdmin
typeAdmin packet {
 
state      enabled;   
fileCount   64;   
fileSize    10240;
filterLevel info; 
servers server1;
 }

 typeAdmin memusage {
 state enabled;
 }

Update the configuration with the following commands -
configure
 set oam eventLog typeAdmin memusage servers server1

Supported Live Software Upgrade (LSWU) Paths


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


Supported Upgrade Paths

V05.00.xxV05.01.xxV06.xxV07.xx
V05.00.00R000V05.01.00R000V06.00.00R000V07.00.00R000
V05.00.00R001V05.01.00F001V06.00.00R001V07.00.00F001
V05.00.00S102V05.01.00F002V06.00.00F001V07.00.00F002
V05.00.00S104V05.01.00F003V06.00.00F002V07.00.00F003
V05.00.00S200V05.01.00F004V06.00.00F003V07.00.00F004
V05.00.00S201V05.01.00F005V06.00.00F004V07.00.00F005
V05.00.00S202V05.01.00F006V06.00.00F005V07.00.00F006
V05.00.00S203

V05.01.00F007

V06.00.00F006V07.01.00R000
V05.00.00S204V05.01.00F008V06.00.00F007V07.01.00R001
V05.00.00F001V05.01.01F001V06.00.00F008V07.01.00R002
V05.00.00F002V05.01.01F002V06.00.00F009V07.01.00R003 
V05.00.00F003V05.01.01F003V06.00.00F010V07.01.00R004
V05.00.00F004V05.01.01F004V06.00.00F011V07.01.00F001
V05.00.01R000V05.01.01F005V06.00.00F012

V07.01.00F003

V05.00.01R001V05.01.01F006V06.00.00F013

V07.02.00R000

V05.00.01R002V05.01.00S608V06.00.00F014V07.02.00R002
V05.00.01S001V05.01.00S610V06.01.00F001V07.02.01R000
V05.00.01F001V05.01.00S611V06.01.00F002V07.02.01R001
V05.00.01F002V05.01.00S612V06.01.00F003V07.02.01R002
V05.00.01F003V05.01.00S613V06.01.00R000

V07.02.01R003

V05.00.02R000V05.01.00S614V06.01.00R001

V07.02.01R004

V05.00.02R001V05.01.00S617V06.01.00R002V07.02.01R005
V05.00.02A059V05.01.00S619V06.01.00R003V07.02.01R006
V05.00.02A061V05.01.00S620V06.01.00R004

V07.02.01R007

V05.00.02F001V05.01.00S621V06.01.00R005 

V07.02.01R008

V05.00.02F002V05.01.00S622V06.01.00R006V07.02.01F001
V05.00.02F003V05.01.01R000

V06.01.00R007

V07.02.01F002
V05.00.02F004V05.01.01R001V06.01.00R008V07.02.01F003
V05.00.02F005V05.01.02F001V06.01.00R009V07.02.01F004
V05.00.03R000V05.01.02F002V06.02.00R000V07.02.01F005
V05.00.03R001V05.01.02F003V06.02.01R000V07.02.02R000
V05.00.03R002V05.01.02F004V06.02.01R001V07.02.02R001
V05.00.03R003V05.01.02F005V06.02.01R002V07.02.02R002
V05.00.03F001V05.01.02F006V06.02.01F001V07.02.02R003
V05.00.03F002V05.01.02F007V06.02.01F002V07.02.02F001
V05.00.03F003

V05.01.02F008

V06.02.01F003V07.02.03R000
V05.00.03F004V05.01.02F009V06.02.01F004V07.02.03R001
V05.00.03F005V05.01.02S001V06.02.01F005V07.02.03R002
V05.00.03F006V05.01.02R000V06.02.01F006V07.02.03R003
V05.00.03F007V05.01.02R001

V06.02.01F007

V07.02.03R004
V05.00.03F008V05.01.02R002

V06.02.01F008

V07.02.04R000
V05.00.04F001V05.01.02R003

V06.02.01F009

V07.02.04R001
V05.00.04R000V05.01.02R004

V06.02.01F010


V05.00.04R001V05.01.03R000

V06.02.01F012


V05.00.05F001V05.01.03F001

V06.02.02R000


V05.00.05F002V05.01.03F002

V06.02.02R001


V05.00.05F003V05.01.03F003

V06.02.02F001


V05.00.05F004V05.01.03F004

V06.02.02F002


V05.00.05F005V05.01.03F005

V06.02.02F003


V05.00.05F006V05.01.03F006

V06.02.02F004


V05.00.05F007V05.01.03F007

V06.02.02F005


V05.00.05F008V05.01.03F008

V06.02.02F006


V05.00.05R000V05.01.03F009

V06.02.02F007


V05.00.06R000 V05.01.03F010

V06.02.02F008


V05.00.06F001V05.01.04R000

V06.02.02F009


V05.00.06F002V05.01.04F001

V06.02.02F010


V05.00.06F003V05.01.04F002

V06.02.02F014


V05.00.06F004V05.01.04F003

V06.02.03R000 


V05.00.06F005V05.01.04F004V06.02.03F001

V05.01.05R000V06.02.03F002

V05.01.05F001V06.02.03F003

V05.01.05F002V06.02.03F004

V05.01.05F003V06.02.03F005

V05.01.05F004V06.02.03F006

V05.01.05F005 V06.02.04R000

V05.01.05F008V06.02.04F001

V05.01.06R000V06.02.04F002

V05.01.06F001

SBC v07.02.00F001 does not have an available LSWU path.


New Features

New Features in 07.02.04R002 Release

There are no new features in this release.

 

New Features in Previous Releases

 

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


Resolved Issues

Resolved Issues in 07.02.04R002 Release 

The following Severity 1 issues are resolved in this release:


Resolved Issues


Issue IDSevProblem DescriptionResolution
1SBX-998741

The Second INVITE with a replace gets the incorrect PSX route.

Impact: The Second INVITE with a replace gets the incorrect PSX route.

Root Cause: There was a design gap in case of multilevel INVITE with REPLACES due to which SBC was sending a light weight PSX look up with incorrect source and destination trunk group. Due to this, SBC is receiving incorrect TG configuration from PSX.

Steps to Replicate: 

  1. The A and B are connected.
  2. The C sends an INV with REPL to replace A.
  3. The D sends an INV with REPL to replace C.
  4. The D sends Re-INV with a=inactive.

The code is modified so that the SBC sends a light weight PSX lookup with the correct source and destination trunks to get the corresponding TG level configuration.

Workaround: N/A

2SBX-100917 / SBX-1002491

Portfix SBX-100249: A PRS process core occurred on the Standby Server.

Impact: The PRS process cored due to the XRM accessing a NULL pointer inside of the XRES data structure.

Root Cause: The root problem was that pkt2 on standby node was stuck in DOWN state due to a possible network switch issue while the pkt2 on active node was functioning as normal. All the activated XRESs selected on LIFs of pkt2 were mirrored to standby and got inserted in the deferredXresList while waiting for the standby pkt2 to be UP.

Then when one of those XRESs is reused for a different call and mirrored to the standby node, that XRES may still be stuck in the deferredXresList because the deallocate request may have not been processed yet on the standby node. Then the PRS process hit a coredump caused by XRM accessing the NULL pointer inside of XRES data structure.

Steps to Replicate: Access an SBC HA pair, active node has pkt ports all UP, and standby node has at least one of the pkt port DOWN, for example, the pkt1 is DOWN.

Start fairly high call load and to ensure calls are picking LIFs of pkt1 on active node in the example, and to ensure the XRES on pkt1 are being re-used.

Note: The standby pkt1 should stay DOWN all the time during the test.

The code is modified to properly free the XRES in deferredXresList so that it can be re-used for the new call.

Workaround: Manually keep the pkt ports sync between active and standby nodes.

3SBX-1010571

The JFK1-CUSBC-16 both coredumped.

Impact: The iceSupport, SMM iptgStore configuration, and invalid incoming call may cause an SBC coredump.

Root Cause: After the response failure to an invalid call, the SBC still tries to initiate a setup call. As a result, it accesses invalid address.

Steps to Replicate: Configure the iceSupport, the SMM storeIPTG, an incoming call with invalid candidate (no UDP).

Platform/Feature: SBC

Add an address validation and try to not initiate a setup call if the call fails.

Workaround: SMM drops an incoming call.

The following Severity 2/3 issues are resolved in this release:


Resolved Issues


Issue IDSevProblem DescriptionResolution
1SBX-992992

The SBC was routing calls to the wrong port number when targets are defined by the SRV records and 1 or more targets get blacklisted.

Impact: When an IP peer is configured as FQDN and FQDN resolves into two IP address, port combinations, when one of the peer is blacklisted, the SBC may start sending call to invalid IP address, port combination.

Root Cause: When one of the peer is blacklisted, the SBC uses port from blacklisted peer.

Steps to Replicate: Reproduce the scenario:

  1. Configure the FQDN as IP PEER.
  2. Configure the DNS server to respond with 2 records.
  3. One of the peer is down or unresponsive
  4. After a certain number of calls, the SBC starts sending call to invalid IP and port combination

    Verify the fix:
    In the scenario above, ensure the SBC sends all calls to correct IP and port combination.

The code is modified to ensure the SBC uses correct port when IP Peer is configured as FQDN and one of the peer is blacklisted,

Workaround: N/A

2SBX-100596 3

The sipParamFilterProfile became broken.

Impact: When an extension is blocked by configuring in the sipParamFilterProfile, the SBC does not send an unsupported header when sending 420 Bad extension.

Root Cause: The SBC does not have logic to include unsupported header when an 420 Bad extension is sent while processing sipParamFilterProfile configuration.

Steps to Replicate: Below are test cases when the require action is set to passthrough.

The code is modified to ensure the SBC includes an unsupported header when sending a SIP 420 Bad extension.

Workaround: N/A

SBX-100596 Steps to Replicate

When sending an 420, all headers present in incoming request except the ones which are marked as passthrough are sent in Unsupported header.

Incoming INVITE Require Header sipParamFilterProfile
Config , rejectRequest enabled common for all test cases. Unsupported Header in 420 Bad extension sent to Ingress ( with fix )
Require: Replaces set profiles services sipParamFilterProfile PROFIL1 sipHeader require action passthrough timer

Unsupported: replaces
Require: Replaces,timer
set profiles services sipParamFilterProfile PROFIL1 sipHeader require action passthrough timer
Unsupported: replaces
Require: Replaces,timer, path,eventlist
set profiles services sipParamFilterProfile PROFIL1 sipHeader require action passthrough Replaces,timer
Unsupported: path,eventlist
Require: Replaces,timer, path,eventlist,unknownHeader1

( Includes unknown header as well )

sipParamFilterProfile PROFIL1 sipHeader require action passthrough Replaces Unsupported: timer, path,eventlist,unknownHeader1
Require: Replaces,timer, path,eventlist,unknownHeader1

( Includes unknown header as well )
sipParamFilterProfile PROFIL1 sipHeader require action passthrough Replaces, timer, unknownHeader1 Unsupported: path, eventlist
Require: Replaces,timer, path, eventlist, unknownHeader1

( Includes unknown header as well )

sipParamFilterProfile PROFIL1 sipHeader require action passthrough Replaces, timer, unknownHeader2 Unsupported: path, eventlist, unknownHeader1

( note that unkonwnheader2 was configured in passthrough list )

Require: Replaces,timer, path,eventlist,unknownHeader1, unknownHeader2
sipParamFilterProfile PROFIL1 sipHeader require action passthrough unknownHeader1, unknownHeader2 Unsupported: timer, replaces, path, eventlist


Resolved Issues in 07.02.04R001 Release 

The following issues are resolved in this release:


Resolved Issues


Issue IDSevProblem DescriptionResolution
1SBX-993093

A call hold using the a=recvonly method is not sending CPG information in SIP-I to a SIP call.

Impact: In a SIP-I to SIP call flow, after a call is answered when egress Peer sends a re-INVITE with recvOnly to the SBC, the SBC does not hold an indication in ISUP body.

Root Cause: The SBC does not treat recvOnly as hold and does not send a hold indication to the SS7 library.

Steps to Replicate: 

  1. After a call is answered, the Egress peer sends a recvOnly INVITE.
  2. The SBC sends a recvOnly SIP to the ingress and the ingress responds with sendOnly.
    Observation: There was no hold indication sent in ISUP body to peer.
  3. With a fix, the HOLD Indication is sent to ISUP and after receiving a sendRecv reINVITE from the egress, the SBC sends a Retrieve indication in ISUP body to ingress.

Platform/Feature: SBC: SIP Applications

The code is modified to ensure the SBC correctly treats the recvOnly as hold and sends the hold indication in ISUP body to the peer. After retrieving the sendRecv INVITE, the SBC sends a retrieve indication in the ISUP body.

Workaround: N/A

2SBX-982002

During a SCM memLeak (SIPSG), memory was not freeing for the pSbyRcb→pcrfInfo structure.

Impact: PCRF related structures are leaking on the standby when processing Registrations if the PCRF is configured on a Trunk Group.

Root Cause: Memory that was allocated for PCRF related structures is not being freed as part of de-registration processing.

Steps to Replicate: 

  1. Configure the pcrfCommitment to a value other than none.
  2. Set the pcrf_signallingPath to enabled.
  3. Set the pcrf_provSignalingFlow to enabled.

Platform/Feature: SBC: SIP

The code is modified to free the memory that is allocated for PCRF related structures as part of de-registration processing.

Workaround: Workaround is to set the pcrfCommitment to none.

3SBX-99931 / 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 the Request URI if they are not processed by the SBC.

Root Cause: When implementing the changes for this new flag in 723 R1, this flag check was missed.

Steps to Replicate: 

  1. The UAC sends an INVITE towards the SBC over the 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 after, towards the Redirector.
  4. The Redirector sends the 3xx with the contact containing UAS IP and DTG info.

Expected Result:

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

Actual Result:

  1. 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 to fix this issue.

4SBX-989962

There is no audio on the SRTP calls.

Impact: Certain call scenarios (SRTP with ICE) intermittently start with one-way audio on encrypted leg(s) due to SRTP authentication failures.

Root Cause: Using a race condition in the setup of encryption and decryption resource results in the uninitialized ROC value being used to encrypt outgoing media packets.

Steps to Replicate: Run a SRTP with ICE call load overnight and verified no authentication failures.

Platform/Feature: SBC

The code is modified to ensure encryption ROC begins at zero.

Workaround: N/A

5SBX-99064 / SBX-99063 / SBX-100121 / SBX-1001242

The LRBT had an unexpected UPDATE with the AMR-WB codec sent.

Impact: The SBC is not playing the tone using the same codec as negotiated, when the 183 with SDP is received and the same is indicated to ingress with UPDATE.

Root Cause:  It is a race condition exposed under the following conditions:

1. A calls B and B sends a 180 without SDP causing the tone to be played to A.
2. Subsequently B sends 183 with SDP so that the SBC needs to send UPDATE out to A for changing the codec.
3. Soon after the 183 with SDP from ingress is received, a 180 without SDP causes the tone play to start.
4. The race condition can be visualized as the UPDATE's 200 OK with SDP trying to modify the system for CUT-THRU, but instead interferes with resource management subsystem's attempt to play tone.
5. As a result, the resource management subsystem picks the incorrect PSP's to play tone.

Steps to Replicate: This steps cannot be reproduced.

Platform/Feature: SBC

The code is modified to enforce that while picking the PSP's to modify when TONE is on, pick the latest PSP and not an earlier one.

Workaround: Providing for Transcode b/w WB-NB will a correct call.

6SBX-98498 / SBX-1001242

Sending an unnecessary UPDATE with the HD codec instead of a G711A for a SIP-I to SIP call.

Impact: When a 200 OK for INVITE comes from egress side with G711A, the SBC sends an unnecessary UPDATE with an HD codec that leads to a no audio call.

Root Cause: The SBC was trying to play a tone by stopping and starting the current tones.

Steps to Replicate: Use the following call flow to reproduce the issue.

Platform/Feature: SBC

The code is modified so when it is not necessary, the SBC continues to play the tone when a 180 without SDP is received.

Workaround: N/A

 SBX-98498 Steps to Replicate

---------------------- dbgDecode CALL FLOW FILE ----------------------

timestamp gcid ingress call leg [ sonus gateway ] egress call leg

INVITE <sip:IP>@00.00.000.00:5060;dtg=<example>
Via: SIP/2.0/UDP 10.00.000.00:<branch tag>=<example>
Via: SIP/2.0/UDP 10.00.000.00:<audio tag>;branch=<example>
From: "OBS" <sip:IP@10.00.00.00:<audio tag>>;tag=<example>
To: Customer<sip:example@10.00.000.00:5060>
Call-ID: <customer call ID>
CSeq: 1 INVITE
Content-Type: application/sdp
sdp {
c=IN IP4 <IP address>
m= <media tag>
a=sendrecv
}
17:22:10.773748 [gcid 0x00080000]: [ingressPeer][ sip] ------------------->> [ sip][sonus]

SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.00.000.00:<branch tag>=<example>
Via: SIP/2.0/UDP 10.00.000.00:<audio tag>;branch=<example>
From: "OBS" <sip:IP@branch tag>;tag=<example>
To: sut <sip:IP@branch IP>;tag=<address>
Call-ID: <customer call ID>
CSeq: 1 INVITE
17:22:10.00000 [gcid 0x00080000]: [ingressPeer][ sip] <<------------------- [ sip][sonus]

INVITE sip:+<example>;phone-context=private@10.00.00.00:00000;user=phone SIP/2.0
Via: SIP/2.0/UDP <IP address>:5060; branch=<example>
From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example>
To: <sip:IP@branch IP>;tag=<address>
Call-ID: <customer call ID>
CSeq: <variable> INVITE
Content-Type: application/sdp
sdp {
c=IN IP4 <IP address>
m=<media tag> 
a=sendrecv
}
17:22:10.855252 [gcid 0x00080000]: [sonus][ sip] ------------------->> [ sip][egressPeer]

INVITE sip:<example>phone-context=private@10.00.00.00:25768;user=phone SIP/2.0
Via: SIP/2.0/UDP <IP address>:5060;branch=<example>
From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example>
To: <sip:IP@branch IP>;tag=<address>
Call-ID: <customer call ID>
CSeq: <variable> INVITE
Content-Type: application/sdp
sdp {
c=IN IP4 <IP address>
m=<media tag>
a=sendrecv
}
17:22:11.338578 [gcid 0x00080000]: [sonus][ sip] ------------------->> [ sip][egressPeer]

SIP/2.0 180 Ringing
Via: SIP/2.0/UDP <IP address>:5060;branch=<example>
From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example>
To: <sip:IP@branch IP>;tag=<address>
Call-ID: <customer call ID>
CSeq: <variable>INVITE
RSeq: 1
17:22:11.358614 [gcid 0x00080000]: [sonus][ sip] <<------------------- [ sip][egressPeer]

PRACK <sip IP address>:25768;transport=UDP SIP/2.0
Via: SIP/2.0/UDP <IP address>:5060;branch=<example>
From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example>
To: <sip:IP@branch IP>;tag=<address>
Call-ID: <customer call ID>
CSeq: <variable>PRACK
RAck: 1 <variable>INVITE
17:22:11.362756 [gcid 0x00080000]: [sonus][ sip] ------------------->> [ sip][egressPeer]

SIP/2.0 180 Ringing
Via: SIP/2.0/UDP <IP address>:5060;branch=<example>
Via: SIP/2.0/UDP <IP address>:35015;branch=<example>
From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example>
To: <sip:IP@branch IP>;tag=<address>
Call-ID: <customer call ID>
CSeq: <variable> INVITE
RSeq: <variable>
Content-Type: application/sdp
sdp {
c=IN IP4 <IP address>
m=<media tag>
a=sendrecv
}
17:22:11.391771 [gcid 0x00080000]: [ingressPeer][ sip] <<------------------- [ sip][sonus]

PRACK <sip IP address> SIP/2.0
Via: SIP/2.0/UDP <IP address>:5060;branch=<example>
From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example>
To: <sip:IP@branch IP>;tag=<address>
Call-ID: <customer call ID>
CSeq: <variable> PRACK
RAck: <variable> INVITE
17:22:11.394747 [gcid 0x00080000]: [ingressPeer][ sip] ------------------->> [ sip][sonus]

SIP/2.0 200 OK
Via: SIP/2.0/UDP <IP address>:5060;branch=<example>
From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example>
To: <sip:IP@branch IP>;tag=<address>
Call-ID: <customer call ID>
CSeq: <variable> PRACK
17:22:11.397195 [gcid 0x00080000]: [ingressPeer][ sip] <<------------------- [ sip][sonus]

SIP/2.0 200 OK
Via: SIP/2.0/UDP <IP address>:5060;branch=<example>
From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example>
To: <sip:IP@branch IP>;tag=<address>
Call-ID: <customer call ID>
CSeq: <variable> PRACK
17:22:11.467157 [gcid 0x00080000]: [sonus][ sip] <<------------------- [ sip][egressPeer]

SIP/2.0 180 Ringing
Via: SIP/2.0/UDP <IP address>:5060;branch=<example>
From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example>
To: <sip:IP@branch IP>;tag=<address>
Call-ID: <customer call ID>
CSeq: <variable>INVITE
RSeq: <variable>
17:22:15.470342 [gcid 0x00080000]: [sonus][ sip] <<------------------- [ sip][egressPeer]

PRACK sip:10.54.81.66:25768;transport=UDP SIP/2.0
Via: SIP/2.0/UDP <IP address>:5060;branch=<example>
From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example>
To: <sip:IP@branch IP>;tag=<address>
Call-ID: <customer call ID>
CSeq: <variable>PRACK
RAck: <variable> INVITE
17:22:15.475654 [gcid 0x00080000]: [sonus][ sip] ------------------->> [ sip][egressPeer]

SIP/2.0 180 Ringing
Via: SIP/2.0/UDP <IP address>:5060;branch=<example>
Via: SIP/2.0/UDP <IP address>:35015;branch=<example>
From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example>
To: <sip:IP@branch IP>;tag=<address>
Call-ID: <customer call ID>
CSeq: <variable> INVITE
RSeq: <variable>
17:22:15.478644 [gcid 0x00080000]: [ingressPeer][ sip] <<------------------- [ sip][sonus]

PRACK <sip IP address>
Via: SIP/2.0/UDP <IP address>:5060;branch=<example>
From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example>
To: <sip:IP@branch IP>;tag=<address>
Call-ID: <customer call ID>
CSeq: <variable> PRACK
RAck: <variable> INVITE
Content-Type: application/sdp
17:22:15.481542 [gcid 0x00080000]: [ingressPeer][ sip] ------------------->> [ sip][sonus]

SIP/2.0 200 OK
Via: SIP/2.0/UDP <IP address>:5060;branch=<example>
From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example>
To: <sip:IP@branch IP>;tag=<address>
Call-ID: <customer call ID>
CSeq: <variable> PRACK
17:22:15.484805 [gcid 0x00080000]: [ingressPeer][ sip] <<------------------- [ sip][sonus]

SIP/2.0 200 OK
Via: SIP/2.0/UDP <IP address>:5060;branch=<example>
From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example>
To: <sip:IP@branch IP>;tag=<address>
Call-ID: <customer call ID>
CSeq: <variable> PRACK
17:22:15.582867 [gcid 0x00080000]: [sonus][ sip] <<------------------- [ sip][egressPeer]

SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP <IP address>:5060;branch=<example>
From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example>
To: <sip:IP@branch IP>;tag=<address>
Call-ID: <customer call ID>
CSeq: <variable>INVITE
RSeq: 3
Content-Type: application/sdp
sdp {
c=IN IP4 <sip IP address>
c=IN IP4 <sip IP address>
m=<media tag>
a=sendrecv
}
17:22:15.786568 [gcid 0x00080000]: [sonus][ sip] <<------------------- [ sip][egressPeer]

PRACK <sip IP address>;transport=UDP SIP/2.0
Via: SIP/2.0/UDP <IP address>:5060;branch=<example>
From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example>
To: <sip:IP@branch IP>;tag=<address>
Call-ID: <customer call ID>
CSeq: <variable>PRACK
RAck: <variable> INVITE
17:22:15.795065 [gcid 0x00080000]: [sonus][ sip] ------------------->> [ sip][egressPeer]

SIP/2.0 200 OK
Via: SIP/2.0/UDP <IP address>:5060;branch=<example>
From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example>
To: <sip:IP@branch IP>;tag=<address>
Call-ID: <customer call ID>
CSeq: <variable> PRACK
17:22:15.797360 [gcid 0x00080000]: [sonus][ sip] <<------------------- [ sip][egressPeer]

SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP <IP address>:5060;branch=<example>
Via: SIP/2.0/UDP <IP address>:35015;branch=<example>
From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example>
To: <sip:IP@branch IP>;tag=<address>
Call-ID: <customer call ID>
CSeq: <variable> INVITE
RSeq: <variable>
17:22:15.797978 [gcid 0x00080000]: [ingressPeer][ sip] <<------------------- [ sip][sonus]

PRACK <sip IP address> SIP/2.0
Via: SIP/2.0/UDP <IP address>:5060;branch=<example>
From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example>
To: <sip:IP@branch IP>;tag=<address>
Call-ID: <customer call ID: sip IP address>
CSeq: <variable> PRACK
RAck: <variable> INVITE
Content-Type: application/sdp
17:22:15.800737 [gcid 0x00080000]: [ingressPeer][ sip] ------------------->> [ sip][sonus]

SIP/2.0 200 OK
Via: SIP/2.0/UDP <IP address>:5060;branch=<example>
From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example>
To: <sip:IP@branch IP>;tag=<address>
Call-ID: <customer call ID: sip IP address>
CSeq: <variable>PRACK
17:22:15.804002 [gcid 0x00080000]: [ingressPeer][ sip] <<------------------- [ sip][sonus]

UPDATE <sip IP address>;transport=UDP SIP/2.0
Via: SIP/2.0/UDP <IP address>:5060;branch=<example>
From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example>
To: <sip:IP@branch IP>;tag=<address>
Call-ID: <customer call ID: sip IP address>
CSeq: <variable>UPDATE
Content-Type: application/sdp
sdp {
c=IN IP4 <sip IP address>
m=<media type>
a=sendrecv
}
17:22:15.844104 [gcid 0x00080000]: [ingressPeer][ sip] <<------------------- [ sip][sonus]

SIP/2.0 200 OK
Via: SIP/2.0/UDP <IP address>:5060;branch=<example>
From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example>
To: <sip:IP@branch IP>;tag=<address>
Call-ID: <customer call ID: sip IP address>
CSeq: <variable>UPDATE
Content-Type: application/sdp
sdp {
c=IN IP4 <sip IP address>
m=<media type>
a=sendrecv
}
17:22:15.844634 [gcid 0x00080000]: [ingressPeer][ sip] ------------------->> [ sip][sonus]

SIP/2.0 180 Ringing
Via: SIP/2.0/UDP <IP address>:5060;branch=<example>
From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example>
To: <sip:IP@branch IP>;tag=<address>
Call-ID: <customer call ID: sip IP address>
CSeq: <variable>INVITE
RSeq: <variable>
17:22:20.803253 [gcid 0x00080000]: [sonus][ sip] <<------------------- [ sip][egressPeer]

PRACK <sip IP address>;transport=UDP SIP/2.0
Via: SIP/2.0/UDP <IP address>:5060;branch=<example>
From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example>
To: <sip:IP@branch IP>;tag=<address>
Call-ID: <customer call ID: sip IP address>
CSeq: <variable>PRACK
RAck: <variable> INVITE
17:22:20.807563 [gcid 0x00080000]: [sonus][ sip] ------------------->> [ sip][egressPeer]

SIP/2.0 200 OK
Via: SIP/2.0/UDP <IP address>:5060;branch=<example>
From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example>
To: <sip:IP@branch IP>;tag=<address>
Call-ID: <customer call ID: sip IP address>
CSeq: <variable>PRACK
17:22:20.808144 [gcid 0x00080000]: [sonus][ sip] <<------------------- [ sip][egressPeer]

SIP/2.0 180 Ringing
Via: SIP/2.0/UDP <IP address>:5060;branch=<example>

Via: SIP/2.0/UDP <IP address>:35015;branch=<example>
From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example>
To: <sip:IP@branch IP>;tag=<address>
Call-ID: <customer call ID: sip IP address>
CSeq: 1 INVITE
RSeq: 279809
17:22:20.809687 [gcid 0x00080000]: [ingressPeer][ sip] <<------------------- [ sip][sonus]

PRACK <sip IP address> SIP/2.0
Via: SIP/2.0/UDP <IP address>:5060;branch=<example>
From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example>
To: <sip:IP@branch IP>;tag=<address>
Call-ID: <customer call ID: sip IP address>
CSeq: <variable>PRACK
RAck: <variable> INVITE
Content-Type: application/sdp
17:22:20.812694 [gcid 0x00080000]: [ingressPeer][ sip] ------------------->> [ sip][sonus]

SIP/2.0 200 OK
Via: SIP/2.0/UDP <IP address>:5060;branch=<example>
From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example>
To: <sip:IP@branch IP>;tag=<address>
Call-ID: <customer call ID: sip IP address>
CSeq: <variable>PRACK
17:22:20.816141 [gcid 0x00080000]: [ingressPeer][ sip] <<------------------- [ sip][sonus]

SIP/2.0 180 Ringing
Via: SIP/2.0/UDP <IP address>:5060;branch=<example>
From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example>
To: <sip:IP@branch IP>;tag=<address>
Call-ID: <customer call ID: sip IP address>
CSeq: <variable>INVITE
RSeq: <variable>
17:22:21.314820 [gcid 0x00080000]: [sonus][ sip] <<------------------- [ sip][egressPeer]

PRACK <sip IP address>;transport=UDP SIP/2.0
Via: SIP/2.0/UDP <IP address>:5060;branch=<example>
From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example>
To: <sip:IP@branch IP>;tag=<address>
Call-ID: <customer call ID: sip IP address>
CSeq: <variable>PRACK
RAck: <variable> INVITE
17:22:21.318799 [gcid 0x00080000]: [sonus][ sip] ------------------->> [ sip][egressPeer]

SIP/2.0 200 OK
Via: SIP/2.0/UDP <IP address>:5060;branch=<example>
From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example>
To: <sip:IP@branch IP>;tag=<address>
Call-ID: <customer call ID: sip IP address>
CSeq: <variable>PRACK
17:22:21.319450 [gcid 0x00080000]: [sonus][ sip] <<------------------- [ sip][egressPeer]

SIP/2.0 180 Ringing
Via: SIP/2.0/UDP <IP address>:5060;branch=<example>                                                  Via: SIP/2.0/UDP <IP address>:5060;branch=<example>
From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example>
To: <sip:IP@branch IP>;tag=<address>
Call-ID: <customer call ID: sip IP address>
CSeq: <variable>INVITE
RSeq: <variable>
17:22:21.321235 [gcid 0x00080000]: [ingressPeer][ sip] <<------------------- [ sip][sonus]

PRACK <sip IP address>:5060 SIP/2.0
Via: SIP/2.0/UDP <IP address>:5060;branch=<example>
From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example>
To: <sip:IP@branch IP>;tag=<address>
Call-ID: <customer call ID: sip IP address>
CSeq: <variable>PRACK
RAck: <variable> INVITE
Content-Type: application/sdp
17:22:21.324074 [gcid 0x00080000]: [ingressPeer][ sip] ------------------->> [ sip][sonus]

SIP/2.0 200 OK
Via: SIP/2.0/UDP <IP address>:5060;branch=<example>
From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example>
To: <sip:IP@branch IP>;tag=<address>
Call-ID: <customer call ID: sip IP address>
CSeq: <variable>PRACK
17:22:21.326579 [gcid 0x00080000]: [ingressPeer][ sip] <<------------------- [ sip][sonus]

SIP/2.0 200 OK
Via: SIP/2.0/UDP <IP address>:5060;branch=<example>
From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example>
To: <sip:IP@branch IP>;tag=<address>
Call-ID: <customer call ID: sip IP address>
CSeq: <variable>INVITE
Content-Type: application/sdp
sdp {
c=IN IP4 <sip IP address>
m=<media type>
a=sendrecv
}
17:22:25.823182 [gcid 0x00080000]: [sonus][ sip] <<------------------- [ sip][egressPeer]

UPDATE <sip IP address>35015;transport=UDP SIP/2.0
Via: SIP/2.0/UDP <IP address>:5060;branch=<example>
From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example>
To: <sip:IP@branch IP>;tag=<address>
Call-ID: <customer call ID: sip IP address>
CSeq: <variable>UPDATE
Content-Type: application/sdp
sdp {
c=IN IP4 <sip IP address>
m=<media type>
a=sendrecv
}

Resolved Issues in 07.02.04R000 Release 

The following severity 1 issues are resolved in this release:


Resolved Issues


Issue IDSevProblem DescriptionResolution
1SBX-947361

The SBC is converting two of the same rtpmaps into one line.

Impact: A duplicated media payload may cause a syntax error when the sdpSelectedAttribueRelay and transcodefree is sent to the other side.

Root Cause: A duplicated attribute line was merged into one line.

Steps to Replicate: Configure the sdpSelectedAttribeRelay and transcodefree. 

Platform/Feature: SBC

Ignore the duplicated media payload and the attributes lines.
2SBX-952411

The SCMP coredumps occurred on the Server.

Impact: The SBC was reading off the end of a memory block while trying to copy the called and 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 resulted in the SBC reading more memory than was allocated for the hostname.

If the memory block passed was right at the edge of process memory, then it is possible this might cause a memory exception and a coredump.

Steps to Replicate: A coredump analysis and code review.

Platform/Feature: SBC

The code is modified to not read more characters that are present in the hostname to avoid reading off the end of the memory block.
3SBX-946101

The Bye URI Messages do not include the domain.

Impact: When the incoming INVITE contains a Contact header with a GR tag.

And the call flow is: SIP-SBC1 -- GW - GW - GSX- ISUP. The SBC includes an IP address in the reqURI of a BYE message and do not have FQDN present in the Contact of Ingress INVITE.

Root Cause: In a GW-GW scenario where the egress GW is GSX, the SBC sends IP address in ReqURI field of BYE message.

Steps to Replicate:

1. Reproduce the issue.
When the incoming INVITE contains a Contact header with a GR tag:

And call flow is: SIP-SBC1 -- GW - GW - GSX- ISUP, SBC includes an IP address in the reqURI of a BYE message and do not have FQDN ( present in Contact of Ingress INVITE )

2. Verify the issue.
After a fix, the SBC sends FQDN in BYE sent towards the Ingress endpoint.

Platform/Feature: SBC

The code is modified to ensure the SBC sends FQDN ( present in Contact header of Incoming INVITE ) in the reqURI of a BYE message.
4SBX-945391

Calls release cause 132 after a switchover.

Impact: The XRES uses the freed altMediaIpAddress unexpectedly in the standby XRM when the LIF is created.

Root Cause: When the standby XRM is notified with the LIF allocate request from NRS, it only receives the LIF's IP address. Any altMediaIpAddress will not be populated until the 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: The SBC HA and SIPP call test setup:

1. Disable the keepAlive timer in the sipTrunkGroup.
2. Enable the debug INFO level logging.
3. Configure the altMediaIpAddress on LIF or LIFs if both ingress and egress legs have XRESs.
4. Configure the link detection on pkt port, threshold = 1 and enable it.
5. Make 5 basic SIP calls, call's mediaIpAddress = altMediaIpAddress, and call duration >= 20 mins.
6. Pull the cable from the pkt port, or ports if 2 pkt are interfaces involved, with link detection enabled.
7. Check the callCountStatus, wait for 5 min and plug in the cable on pkt port(s).
8. Check the callCountStatus again and wait for HA pair to finish syncing.
9. Perform a switchover again.

At step 6, the switchover triggered by link detection at step 7, 5 calls should be ACTIVE, check DBG log for following messages from XRM:

1. "XrmRedResAlloc: DEBUG! Context ID 0 XRES resId x on NIF y not allocated (on deferred list), LIF z not created"
2. "XrmNifMacAddrGet: Could not find LIF ifIndex z"
3. "XrmRedUdpAlloc: Context ID 0 Could not find UDP structure for LIF..."

At step 8, the calls should still be ACTIVE.
At step 9, the calls could be released during extensive audit, but not always.

Platform/Feature: SBC: CDR, Redundancy

The code is modified to skip the XRESs using altMediaIpAddress when the LIF is created in the standby XRM. Walk through the deferred activate list one more time when the altMediaIpAddress is added in the standby XRM.
5SBX-950961

The SBC7K core dumps again after the 6.2.1F010 update.

Impact: A rare race condition can cause the SamProcess to core with a Healthcheck failure when using the TLS.

Root Cause: The root cause of this issue is a rare race condition that allows one of the threads in the SamProcess to free memory, that is still being used by another thread in the same process.

Steps to Replicate: The steps cannot be reproduced.

Platform/Feature: SBC

The code is modified to prevent the race condition that causes the Healthcheck failure.
6SBX-945771

The SBC services will not come up.

Impact: The standby fails to start and connect to the active, shutting 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 it being shut back down.

Steps to Replicate: This is a one-off situation and can be easily reproduced.

Platform/Feature: SBC

The code is modified to recover the checkpoint address if it is unknown.
7SBX-951141

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 into the EMA.
  2. Navigate to
    All->profile->services->Transparency profile->SIP Header
  3. Select the transparency profile.
  4. Click on New Sip Header.
  5. After that, the "Ignore Transparency " field will be visible.

Platform/Feature: SBC

The code is modified to create a method for checking "not" is applied to a whole expression or not to a whole expression.
8SBX-95784 / SBX-951561

Portfix SBX-95156: The SBC disconnects the call when it receives a 491.

Impact: A 491 received for a Re-Invite without an SDP was not being relayed to another Leg, even when the E2E Re-Invite and statusCode4xx6xx are enabled.

Root Cause: A 491 Relay logic is missing for the Re-Invite without SDP case.

Steps to Replicate:

  1. Enable the E2E Re-Invite and the statusCode4xx6xx.
  2. A 491 will be received for Re-Invite without a SDP sent.

Platform/Feature: SBC

The code is modified to Re-Invite without a SDP case when the E2E Re-Invite and statusCode4xx6xx are enabled.
9SBX-95921 / SBX-952641

Portfix SBX-95264: Calls stopped working after an upgrade to SBC5110 from V05.00.05F008 to V06.02.03F005.

Impact: In the X-dmi parameter, the "p=0.0.0.0" was changed to "p=" in 6.2.3F5 that was failing the parser.

Root Cause: The root trigger was the change in the IPUtilGetStr() since early 6.2 release checks the given ipAddr is a V4 or V6 address. In this case, the ipAddress was unspecified, so IPUtilGetStr() returns '\0'.

Steps to Replicate: The steps cannot be reproduced.

Platform/Feature: SBC

The code is modified to check the source IP address and initialize it to IPv4 if it is unspecified.
10SBX-933111

The 488 Response to the T38 Reinvite.

Impact: For a G.711-T.38 Fax call, if the SBC receives a G.711 reInvite with some change in SDP from ingress peer, then the SBC sends a G.711 reInvite to egress peer.

The customer expected 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 a G.711 reInvite or any other reInvite that has some change in the SDP from ingress peer, then the SBC initiates 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: The steps cannot be replicated.

Platform/Feature: SBC

The code is modified so when the SBC detects a change in the SDP for a Fax call LEG, and if the codec active for that fax call LEG is G711 and there is no change in G711 LAW, then SBC stays in a Fax call and sends the 200OK with answer-SDP as per last offer-answer negotiation. Any change in DTMF, silence Suppress mode and any other SDP parameter is ignored.

11SBX-96629 / SBX-965241

Portfix SBX-96524: Getting the Pes Process coredump while running registrations.

Impact: Getting the Pes Process coredump while running registrations.

Root Cause: CallParamMatchName function is called with matchName which is of 15 byte array and strncpy is used to copy the string to the 50 byte array but with a wrong size of MATCH_NAME_SIZE which is defined as 30 byte*.*.

Passing bigger size than the actual destination string to strncpy is resulting in padding 0’s beyond the actual 15 bytes of the matchName. This was corrupting the stack and the stack pointer and causing a segmentation fault.

Steps to Replicate: The steps cannot be reproduced.

Platform/Feature: SBC

Change the size of matchName[] to correct size.
12SBX-960871

The SBC is not sending the RTCP to egress Peer for transcode only.

Impact: In the customer call flow:

With the Ingress Peer -(ISDN)> GSX ---(GW2GW)-> SBC --(SIP)-> Egress Peer, with the PSP setting as "transcode only" and RTCP enabled, the SBC does not send RTCP packets towards the egress.

Root Cause: Due to changes made for a previous feature SBX-6366, the SBC does not mark the XRES resource as duplex and marks it as receive only. As a result, the SBC does not send RTCP towards egress.

Steps to Replicate:

  1. Reproduce the problem in following call flow:
    Ingress Peer -- SIP -- GSX -- GW2GW -- SBC -- SIP -- Egress Peer
    This transcode only call and RTCP is enabled.
    Result: No RTCP sent by the SBC to egress.
  2. Verify the issue by applying SamP with GWFE change but not change in ScmP.
  3. Use the same setup. RTCP traffic was sent from the SBC to egress.

Platform/Feature: SBC

The code is modified to set RTCP send and receive bandwidth as the 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.
13SBX-96800 / SBX-897411

Portfix SBX-89741: There was a CPX core during an upgrade from V05.01.05R000 to V07.02.01R001.

Impact: The LSWU CLI command returned in a failure due to a failure to create package sub-dir under the external directory, but the upgrade continued on 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 CLI command returns failure, the upgrade is not continued further.
14SBX-967061

Multiple switchovers causes non 5060 sipSigPorts to become inactive.

Impact: When a user configured >= 2 SIP Sig ports with same IP address but different port numbers, and they are using the same LIF group that contained 1 LIF, the pkt down triggered a switchover and it stayed down for extended time. After the pkt UP, a second switchover occurred, then only one Sig port went in service. The other Sig ports were stuck in OOS.

Root Cause: Since the pkt port was DOWN when the new standby node came back online, the SIP sig ports were restored while LIF was OOS. So address registrations were failed. After the SIPCM has reached a max number of retries, the LADDRs of the Sig ports, except the first one, were deleted in the NRS context.

When the pkt port came UP, the NRS brought LIF into service and registered the only one signaling address saved in the NRS context.

Steps to Replicate:

Test steps:
1. Configure 2 VLANs on the YF or BF pkt2.
2. Configure 4 SSPs on the first VLAN interface; 4 SSPs on the second VLAN interface. 4 SSPs use the udp/tcp port numbers 5060, 5160, 5260, and 5360 with the same IP address
3. Run the Sbxstop command.
4. Unplug the packet ports - YF pkt2
5. Run the Sbxstart command.
6. Display the SSPs on VLAN interfaces.

Platform/Feature: SBC

1. The code is modified to only delete LADDR before reaching the max number of retries.
2. Restore the pendingNrsReq flag properly when the address registration failed.

15SBX-970791

After the LDG triggered a switch over, the SBC is rejecting all the register message with a 500 internal error.

Impact: The SCM process may coredump when the SIP signaling port was being used during a 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.
16SBX-954511

The SCM fast memory increase causes a delayed switchover with an outage.

Impact: If a multilevel INVITE with Replaces is run, the memory and CPU utilization by the Scm Process increases drastically and leads to a core dump.

Root Cause: Each INVITE with Replaces is a new Callgroup. Each call group has its own segments. For each segment, there are associated segments.

When a Release call is invoked, it releases all segments and each call segment frees the associated call segments.
During the release flow for such a call CC_EV_ASG_DISC_CMD event is posted multiple times for various orig and term GCID’s.

Please note that this ultimately frees up everything although the memory and CPU utilization shoots up.

Steps to Replicate:

  1. Test multilevel INVITE replaces (more than 15).
  2. Crash will not occur.

Platform/Feature: SBC

Now in the CC state machine, the CC_EV_ASG_DISC_CMD event is not posted multiple times for the same original and term labels. This leads to drastically reducing the looping, while also ensuring that all call segments (and associated segments) are freed.

 
17SBX-977431

The SBC fails to relay the 18x/2xx towards the ingress when the SBC is configured to play tone.

Impact: The SBC Fails to relay the 18x/2xx in case of the MSRP call when tone is configured. The SBC tries to allocate tone Resources even though the Audio stream is not present.

Root Cause: The SBC is going for Tone allocation, even though audio stream is not present.

Steps to Replicate: Run a MSRP call with the tone configured.

Platform/Feature: SBC: Application

The code is modified to not trigger tone for the MSRP only call.
18SBX-96872 / SBX-918711

Portfix SBX-91871: The metavar was assigned to none.

Impact: When only one of the nodes detects a network glitch in the N:1 setup, usingMetavarsOf field of the other node is set to none.

Root Cause: A metavar response message is not sent from the node that did not detect the network glitch.

Steps to Replicate: Bring down the HA link for less than 5 seconds such that only one node detects the network glitch.

Platform/Feature: SBC

The code is modified so the ChmSendMetavarDetails indicates a reply is expected in case of NODE_SERVICE_ID_UP event.
19SBX-944031

Unable to establish the same number of sessions after the switchover.

Impact: Calls were getting cleared under load conditions after a switchover in the first gateway in a GW-GW setup.

Root Cause: When sessionKeepAlive is set and the SBC switched over, the SBC starts sending refresh INVITEs to the endpoints. Since this is a GW-GW setup, in such scenario's, the newly active GW-1 will send call processing messages to the GW-2. There was an issue in call processing at the GW-2 that resulted in call failures.

Steps to Replicate:

  1. Create a SBC GW-GW setup and enable the sessionKeepAlive.
  2. Establish a call load of more than 25K and once the call is stable, perform a switchover at the GW-1.
  3. Calls will start failing

Platform/Feature: SBC

The code is modified to take care of processing multiple segments and successfully establishing a GW-GW connection.
20SBX-942451

The SBC picks up an incorrect TG for incoming non-INVITE requests and responses to non-INVITE requests.

Impact: The SBC is picking up the wrong trunk group for incoming messages.
This is specific for a rare configuration when there is only 1 sigport sharing multiple trunkgroups, and the same peer source address routing traffic to different trunkgroups.

Root Cause: When the SBC processes inbound/outbound messages, it puts the TG into the cache table for processing after the response. In this case, there are two 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 registered end point.

Steps to Replicate: 

  1. Run a configuration where there is only 1 sigport sharing multiple trunkgroups, and the same peer source address routing traffic to different trunkgroups.
  2. Call B was sharing the same signaling port and the same peer IP.
  3. An OOD to the SBC and route back to A.
  4. Both outbound cases are using different TGs.

Platform/Feature: SBC

The code is modified to avoid swapping the TG. The SBC puts in a different new hash table, and later, the response from the request looks at the new hash table for the TG.
21SBX-979601

An incorrect transparency functionality causes calls to fail.

Impact: The To header transparency becomes active and launches a successful ENUM query may cause an incorrect RURI format. 

Root Cause: The RURI build was based on the To header.

Steps to Replicate: Enable the To header transparency and PSX ENUM LNP response may contain an empty “Called URI”.

Platform/Feature: SBC

The code is modified so the RURI is independent of To header.
22SBX-98993 / SBX-989921

Portfix SBX-98992: The EMA logs are not being copied in SysDump, however, the folder is there.

Impact: The EMA logs are not captured by the sysdump. 

Root Cause: The EMA log location was changed in the 6.0.0 and the sysdump was never updated with the change.

Steps to Replicate: Run sysdump and verify the EMA logs are captured.

Platform/Feature: SBC

The code is modified to use the correct location for the EMA logs.
23SBX-971121

The EMA response time on the SBC 7.2.3 release is very high.

Impact: The EMA response time on the SBC 7.2.3 release is very high.

Root Cause: Making more than six TCP calls at a time from the browser.

Steps to Replicate: 

  1. Log in to EMA.
  2. Route from Configuration->System Provisioning-> Routing

A user can see the efficiency of screen loading.

Platform/Feature: SBC

The code is modified to fix the issue.
24SBX-969961

The Scm Process cored.

Impact: When the pathcheck timeout, and the SBC is unable to find a zone, the SBC may core.

Root Cause: Access the null pointer.

Steps to Replicate: The steps cannot be reproduced.

Platform/Feature: SBC

Check for the valid zone pointer before the access.
25SBX-971991

The Wall Comcast PM-SBC memory increasing.

Impact: There is a memory leak in the PRS. The structures associated with certain interprocess messages are leaking.

Root Cause: The structures associated with certain interprocess messages are leaking because these structures were not being freed.

Steps to Replicate: The steps cannot be reproduced.

Platform/Feature: SBC

The code is modified to free the memory for certain interprocess messages.
26SBX-953551

The SIP to SIP call no ring back tone passed to the ingress when PEM header is enabled on egress endpoint.

Impact: There was no RBT when the PEM header is enabled, the Split 18x moves into alerting and progress flag is enabled.

Root Cause: This flow was never tested with flag, and with Split 18x into alerting and progress.

Steps to Replicate: Setup call with PEM enabled on the egress and with Split 18x flag enabled.

Platform/Feature: SBC

Before 18x is split, the PEM header handling is updated and corrected.
27SBX-932391

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

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

Root Cause: A bad resource activation.

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

Platform/Feature: SBC

The code is modified to stop activating the full resource chain when the tone is being played.
28SBX-96954 / SBX-958741

Portfix SBX-95874: The SBC's dump SCM process when running a MSRP call with the LI enabled.

Impact: The SCM process dumps when running a MSRP call with the PCSILI enabled.

Root Cause: The SBC sends an invalid Stream ID for non audio calls in NrmaDsbcSendDummySplitterCmd() and NrmaDsbcSendSplitterCmd() when invoking NrmaDsbcIssueXresCmd(). In the M-SBC, when processing the same correct stream, the EP res is not fetched because of an invalid stream ID and is why the SYS_ERR is triggered.

Steps to Replicate: Running a MSRP call with the PCSILI enabled.

Platform/Feature: SBC

Since this command is sent per leg and not per stream, the S-SBC cannot send streamIds. In M-SBC do not use the localEp res fetched based on streamId for processing of SPLITTER_CMD. To fix the issue, avoiding fetching localEpRes and comparing the same in the M-SBC.
29SBX-97855 / SBX-990571

The wrong codec selection for the LRBT when one 183 with the SDP followed by two 180 Ringing.

Impact: The Ingress Trunk had theSIP-I and LRBT enabled and the Egress side Trunk is configured with the SIP.

The transcode conditional is enabled and the AMR-WB , AMR ,G711 and G729 are present in the Ingress and Egress Route PSP. Transcoding for AMR and AMR-WB is disabled but enabled for the G711 and G729.

After the INVITE OFFER is relayed by the SBC to Egress, the SBC receives the 183 with pcma followed by two 180 ringing alerts from the Egress.

The SBC should send 183 with PCMA in the SDP but instead it sends amr-wb, the first codec from the Offer, to the Ingress and as a result the tone is played in AMR-WB, which is incorrect.

Root Cause: For every 180 ringing alert received from the Egress, the tone is stopped and restarted. During the second tone restart, the SBC makes a new Offer with a Route PSP and discards the current answer received from the Egress Peer.

Steps to Replicate: The steps cannot be reproduced.

Platform/Feature: SBC: SIP Applications

If the tone context is present and SDP ANSWER is received, the SBC uses that to play the tone.
30SBX-99017 / SBX-978561

Portfix SBX-97856: A bad Update sent by the SBC to Ingress during the LRBT.

Impact: The SIP-I on the Ingress TG and the SIP on the Egress TG.

With the transcode conditional enabled, the AMR-WB transcoding disabled in PSP and LRBT enabled, when making a call, during the LRBT, the Egress peer sends an update with change of media port but the SBC sends unwanted UPDATE towards ingress side with the AMR-WB / 16k DTMF

Root Cause: After an update followed by 180 ringing alert is received from the Egress Peer with change in the port only, the SBC generated a new Offer to the Ingress with a Route PSP codec preference of AMR-WB discarding the active codec PCMA already negotiated.

Steps to Replicate: The steps cannot be reproduced.

Platform/Feature: SBC

The existing active TONE Packet Service Profile that is already negotiated is used in the update.
31SBX-94233 / SBX-943951

Portfix SBX-94395

Impact: RTCP Packets discarded.

IPv6 to IPv4, NAT enabled on V6 side – RTCP Packets discarded for Audio+T140 call after call modify.

Root Cause: For non-audio streams call-modify scenarios, the optional spec flag to mark the IP version was not set in the NP Interface.

Steps to Replicate: None.

Platform/Feature: SBC

Ribbon added code to set the flag for IPv6 in the NP Interface during a Modify flow.

The following Severity 2 and 3 issues are resolved in this release:


Resolved Issues


Issue IDSevProblem DescriptionResolution
1SBX-932472

A SCM leak on the Standby.

Impact: The SCM may leak memory in calls with a SIP Relay and FQDN. The memory used to store the Domain information may be leaked.

Root Cause: There is an edge case where the memory used to store the Domain information for a SIP Relay call is not being freed.

Steps to Replicate: This issue has been found by a code inspection and the steps to reproduce this case have not been identified.

Platform/Feature: SBC

The code is modified so that the memory used to store the Domain information is freed whenever the standby Relay Call Block is freed.
2SBX-94865 / SBX-945122

Portfix SBX-94512: The RTCP packets count is not getting populated consistently in the callMediaStatus.

Impact: With the RTCP relay monitoring feature, sometimes the RTCP packets are not relayed or discarded.

Root Cause: In the SWe NP, due to endian alignment code issue, the RTCP mode configuration flags were not set as per the call flows enable/modifications.

Steps to Replicate: This is sporadic, when multiple times RTCP REL MON call flows, modifications tried it might occur.

Platform/Feature: SBC

The code is modified to be applied correctly in the SWe now.
3SBX-949983

The SipSgProcessRelayRequestPrimitive: relay an INVITE without the cpcOrigMsgInfoPtr.

Impact: A increase in the DBG logs filling up with SipSgProcessRelayRequestPrimitive messages.

Root Cause: In case of an End2End Re-INVITE, the log message does not have any impact.

Steps to Replicate: The log level changed on the basis of code analysis and description.

Platform/Feature: SBC

Change the log level to info since it happens when the E2E Re-INVITE flag is enabled and does not have any negative impact.
4SBX-925822

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 an error: No Routes in Cache to the SBC. The SBC logs a trap after receiving No routes in the cache error.

Root Cause: The SBC makes an additional query to the PSX even after the PSX sent all the routes.

Steps to Replicate:

  1. Configure more than 10 routes on the PSX Routing Label (11 routes for example).
  2. All 10 routes fail.
  3. The SBC sends another query to get more route and those fail as well.
  4. The SBC still send additional query to the PSX which fails because the PSX have returned all the

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.
5SBX-95323 / SBX-939672

Portfix SBX-93967: Direct dial to a call queue, and then transfer to agent fails.

Impact: For the PSTN to Teams calls, when Teams was triggering an INVITE with replaces, perform a subsequent REFER. The SBC was not relaying the REFER-TO information from the REFER message to the subsequent INVITE. This was resulting in the wrong information being sent back to MS Teams and the call failed.

Root Cause: The SBC was not relaying the REFER-TO information from the REFER message to the subsequent INVITE.

Steps to Replicate: In a MS Teams setup run a call Q and transfer scenario where the call originates from the PSTN side.

Platform/Feature: SBC

The code is modified to pass the REFER-TO information from the REFER to the INVITE in this scenario for the MS Teams setup.
6SBX-917372

External PSX became active after a switch over, though it was the OOS prior to the switch over.

Impact: When changing the multiple remote policy servers' 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 will not try to register with this server, and the iteration of all mode change servers will be stopped. This causes the rest of the servers, whose operStats have not been changed and remain unchanged. Therefore, 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 at enabled, only keep 1 of the servers mode as active, and rest are out of service.
  3. Change those servers' mode, commit only after all the set commands finished.
  4. Display the status using the 2 commands below:
    "show table system policyServer remoteServer"
    "show table system policyServer policyServerStatus"
  5. Perform a switchover.
  6. Repeat step 4. The operStat will be different from step 4.
  7. Making call load, may be a load call rate, when the Node A is active, and then when the Node B is active. When the Node B is active, the policy request may still be sent to the remote server that you have already made the OOS when the Node A was active.

Platform/Feature: SBC

The code is modified for all remote servers requested by the CLI users, although remote servers are not registered even if the mode is being changed from the OOS to active. As a result, the operStates at standby node stays synced with the active node.
7SBX-921143

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

Impact: Removes this incorrect log message:

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

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

Steps to Replicate: The steps cannot be replicated.

Platform/Feature: SBC

The code is modified to remove this incorrect log message:

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

 
8SBX-94814 / SBX-934562

Portfix SBX-93456: The SWe NP worker has a segfault.

Impact: There is an issue in the SBX-93456, where the SWe_NP was crashing multiple times due to the skb_work->skb corruption.

Root Cause: There is a point in normal media processing ( RTP and RTCP path), where an update to skb_work->skb from addr_ptr that is not necessary, may corrupt the skb_work->skb.

The corruption occurs in the path of processing RTCP XR packets, where the addr_ptr moves ahead by a few bytes, but the UPP processing expects the mbuf address to be present back at the 58 bytes from addr_ptr.

Steps to Replicate: Run JIO scenarios.

Platform/Feature: SBC

Avoid overwriting the skb_work->skb from add_ptr.
9SBX-937122

The RTP Inactivity Timer fires early upon performing a port switch-over on the M-SBC.

Impact: If a call starts out with no RTP packet at all, the RTP Inactivity Notification is triggered earlier than the configured threshold. This is only observed on the SWe SBC.

Root Cause: The timestamp used for inactivity detection is not set when the media resource is enabled in the network processor code.

Steps to Replicate: Run a test that establishes a call where the ingress peer does not send RTP. There are no switchovers or other events and the calls are disconnected before the timer expires. The timer is set to 30 seconds.

Call service Duration with a disconnect 145.

Platform/Feature: SBC

Set the timestamp to the current time when the media resource is enabled.
10SBX-948112

The SBC fails to route in advance to the 13th route.

Impact: When the PSX has more than 10 routes configured and all routes in the first policy response fail due to an internal cause, the call fails because the SBC cannot handle more routes correctly.

Root Cause: When the PSX has more than 10 routes configured and all routes in the first policy response fail due to an internal cause, the SBC's NRMA subsytem returns with an allocation failure.

Steps to Replicate:

1. Configure more than 10 routes on the PSX.
2. Force a failure on the first 10 routes due to an internal error.
3. Verify the call gets established on the routes in second policy response.

Platform/Feature: SBC

The code is modified to ensure the SBC handles more than 10 routes from the PSX correctly.
11SBX-91463 / SBX-913982

Portfix SBX-91398: The ASAN heap-use-after-free on the address DnsClientQueryServerCmd.

Impact: The DNS client running in the SBC while trying to query the DNS server, tries to identify the transport protocol used. If the query fails on the first server, it accesses the first DNS server's data structure to get the type of transport protocol.

Root Cause: This issue was reported as part of the ASAN Testing on the DNS regression suite in the SBC lab.

Steps to Replicate: This issue was found while running the DNS regression test suites.

Platform/Feature: SBC

The code is modified to fetch the transport protocol from the next available DNS server in the list and trigger the DNS query.
12SBX-910572

The SBC fails to relay the 4xx-6xx responses when the IPTG authentication is enabled - all SIP causes are 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 the CPC 176. The SBC is unable to relay the cause code from the egress to ingress endpoint.

Root Cause: When the IPTG authentication is enabled, the SBC maps all the 4xx-6xx SIP codes to the 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 the 599 that is mapping of 176 ( CPC_DISC_TG_AUTH_FAIL, which is CPC code) to Ingress.

With a fix, the SBC sends the 486 buys to the ingress correctly.

Platform/Feature: SBC

The code is modified to ensure the SBC, upon receipt of provision response, clears the authentication flag and relays the cause code from the egress to the ingress.
13SBX-950332

The SAM Process cores when the SNMP walk commands are executed during the TLS load.

Impact: When the getTlsSessionStatus command is executed when the TLS load is running, it will result in a SAM Process core.

Root Cause: The issue is because the SIPCM expects the SSL_get1_session() to increment the reference count of the SSL socketPtr. After the SIPCM returns from the SSL_get1_session() tries to decrement, the reference count during the time the socketPtr was deleted by another thread, which results in a double free.

Steps to Replicate: The steps cannot be reproduced.

Platform/Feature: SBC

The code is modified to ensure to lock the SSL socketPtr before performing any operation so that no thread tries to access it.
14SBX-931053

The SIP OPTIONS was not responding after a failover.

Impact: A syntax error message during a switch over is unable to respond.

Root Cause: Internal messages drop due to other subsystems not being ready to process the message. Subsequent messages are stuck in the queue.

Steps to Replicate: Simple ping Options messages during a switchover.

Platform/Feature: SBC

During a switchover, the message drops.
15SBX-950072

The IPv4 Path MTU Discovery (RFC1191) was not working.

Impact: The IPv4 Path MTU Discovery (RFC1191) does not work.

The SBC uses the MTU of the outgoing network interface as the Path MTU.
Without the fix, the SBC does not update the Path MTU properly even if a router in the path sends "ICMP Destination Unreachable Fragmentation Needed" message with a smaller Path MTU value. The large packets requiring fragmentation to fit the Path MTU from the SBC will not reach the SIP peer.

Root Cause: In performing a route/fib, lookup in the updating Path MTU from "ICMP Destination Unreachable Fragmentation Needed" message did not consider the ipInterfaceGroup and addressContext. This resulted in not updating Path MTU of the proper route entry to the peer.

Steps to Replicate: The SBC sends IP packets of a length 1500 bytes toward the SIP peer when a path to the peer has a smaller MTU (e.g. 1400 bytes). A router with the smaller MTU sends "ICMP Destination Unreachable Fragmentation Needed" to the SBC. The SBC, with the fix, adjusts the Path MTU, performs the fragmentation and sends fragments to the SIP peer.

Platform/Feature: SBC

The code is modified to add ipInterfaceGroup and addressContext information in handling the "ICMP Destination Unreachable Fragmentation Needed" message in the Linux kernel. 
16SBX-949942

The lwresd process on the active node is killed when a reboot is issued.

Impact: When a reboot is issued at the command prompt on the active node, the slwresd process is killed prior to it being properly shutdown. This causes a delay in reboot processing as the system goes through a fault recovery processes rather than an expedited shutdown.

Root Cause: The reboot wrapper that kills a non-SBC processes and using the drbd mount point was inadvertently killing the swlresd process.

Steps to Replicate: On the active CE, issue a reboot at a command prompt.

Platform/Feature: SBC

The code is modified to properly detect all the SBC processes so that the slwresd is not killed by the wrapper and therefore is not detected as having failed.
17SBX-943772

A large number of TLS error messages were in DBG log.

Impact: The following log message was filling logs due to being incorrectly logged at the MINOR level (when it should have been at INFO level):

Minor .SIPSG: sipsgUtils.c (-27373) 27050. SipSgLogLevel4: missing callId need to parse

Root Cause: The following log message was incorrectly being logged at the MINOR level (when it should have been at INFO level):

Minor .SIPSG: sipsgUtils.c (-27373) 27050. SipSgLogLevel4: missing callId need to parse

Steps to Replicate: The only change was to change a log message from MINOR to INFO - there was no testing necessary.

Platform/Feature: SBC

The code is modified to change the following log message from MINOR to INFO:
Minor .SIPSG: sipsgUtils.c (-27373) 27050. SipSgLogLevel4: missing callId need to parse

18SBX-89209 / SBX-890182

Portfix SBX-89018: The ASAN heap-buffer-overflow in the CpcOptionalParameterSave from the SipSgCopySipUrlToCpc

Impact: When an INVITE arrived to start a new call, the SIP service group control "callRouting useRouteSet" is set to the value of "received" to try and route the call based on the routeset in the INVITE. While processing the URI information in the header and trying to map it into internal structures, the code was reading off the end of a memory block. This setup can cause a crash if the memory block is at the end of the heap.

Root Cause: The code was trying to apply a 4 byte alignment to the internal parameter length after the memory had already been allocated. This meant that sometimes, the parameter length got set to a larger value than the memory block size.

Steps to Replicate: This problem was identified while running ASAN testing in the Ribbon lab and cannot be reproduced using normal images.

Platform/Feature: SBC

The code is modified to correctly handle the memory management so that it does not read off the end of the memory block.
19SBX-947903

A backup/restore file cannot be downloaded from the EMA if the file name contains a dot (.).

Impact: A backup/restore file cannot be downloaded from the EMA if the file name contains a dot (.).

Root Cause: In the downloadSavedConfig block, making an API call both the time (Running on the SBC or running on the EMS).

Steps to Replicate:

  1. Login into EMA.
  2. Navigate to
    Administration -> System Administration -> Backup/Restore
  3. Download the Backup file.

Platform/Feature: SBC: EMA

Make an API call if it is running the EMS on a normal method while on the SBC.
20SBX-91113 / SBX-724992

Portfix SBX-72499: The PesP cored on the active node.

Impact: The PesP cored on the active node.

Root Cause: The Ref count is getting incremented and once it reached the max value, it is becoming zero and destroying the object in one thread. At the same time, the other thread is accessing the object and crashing.

Steps to Replicate: Keep running calls for a longer time by using only one IpSignalingProfile.

Platform/Feature: SBC: Application, ERE

The code is modified to stop the Ref count from getting incremented when it reaches the max value.
21SBX-95244 / SBX-950972

Portfix SBX-95097: The SBC is sending incorrect RACK in the PRACK for a Late Media Call.

Impact: The SBC is sending incorrect RACK in the PRACK for a Late Media Call.

Root Cause: Whenever the PRACK with SDP comes as an answer, the PRACK entry holding RSEQ details is not getting removed from the list while being sent out, because of any subsequent 18x/PRACK without SDP coming out at the same time; the SBC is adding old RSEQ in RACK.

Steps to Replicate: Late Media call with first 18x and PRACK with SDP followed by an 18x and PRACK without SDP.

Platform/Feature: SBC

To fix the issue, remove the RSEQ details from the PRACK entry List while sending PRACK with SDP out.
22SBX-945712

Missing the Egress Response Code in the Field 59.19.

Impact: Egress error response code is not updated for the SIP response “487 Request Cancelled” in the field number 59.19 in ATTEMPT CDR record.

Root Cause: In the “487 Request Cancelled” case, because there is no CANCEL sent for the INVITE, the correct function is not called that is responsible for adding field number 59.19 in the ATTEMPT CDR record.

Steps to Replicate: Set up the SBC to make a simple call flow as below, and check the CDR for field 45.19/20 and 59.19/20:

UAC.xml SBX UAS.xml
| | |
| INVITE | |
|=======>| |
| 100 | |
|<=======| |
| | INVITE |
| |=====>|
| | 487 |
| |<=====|
| | ACK |
| |=====>|
| | |
|480 | |
|<=======| |
| ACK | |
|=======>| |

Platform/Feature: SBC

The code is modified to add the field number 59.19 in the ATTEMPT CDR record, in “487 Request Cancelled” case.
23SBX-95833 / SBX-957492

Portfix SBX-95749: The SBC is not adding the Contact header in the 200 OK of UPDATE for a session refresh UPDATE.

Impact: The contact header is missing in the 200OK sent by the SBC for a session refresh UPDATE (an UPDATE without SDP or an UPDATE with the same SDP as last SDP).

Root Cause: The contact header is missing in the 200OK sent by the SBC for a session refresh UPDATE (an UPDATE without SDP or an UPDATE with the same SDP as last SDP).

Steps to Replicate:

  1. Enable the E2E Update.
  2. Trigger an UPDATE without SDP or an UPDATE with same SDP as last SDP.

Platform/Feature: SBC

The code is modified to add the contact header by the SBC when not provided by an application in the 200OK for a Session Refresh Update(an UPDATE without SDP or an UPDATE with the same SDP as last SDP).
24SBX-954702

The SBC was using the incorrect SIP signaling port for the 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 the REGISTER - SUBSCRIBE scenarios when the initial SUBSCRIBE request is challenged.

Root Cause: When the usePortRangeFlag is enabled, the SBC may use an incorrect SIP Signaling Port when handling a SUBSCRIBE request with an Authorization header to the egress peer.

Steps to Replicate:

Provision the SBC to support CUCM (Cisco Unified Connection Manager) .
Ingress zone / sipTrunkGroup:
set addressContext default zone ZONE2 sipTrunkGroup SBXSUS4_LABSIP1 signaling registration requireRegistration required
set addressContext default zone ZONE2 sipTrunkGroup SBXSUS4_LABSIP1 signaling usePortRangeFlag disabled
set addressContext default zone ZONE2 sipTrunkGroup SBXSUS4_LABSIP1 signaling psxRouteForSubscribe enabled
commit

Egress zone / sipTrunkGroup:
set addressContext default zone ZONE4 sipTrunkGroup SBXSUS4_LABSIP2 signaling registration requireRegistration none
set addressContext default zone ZONE4 sipTrunkGroup SBXSUS4_LABSIP2 signaling usePortRangeFlag enabled
set addressContext default zone ZONE4 sipTrunkGroup SBXSUS4_LABSIP2 signaling psxRouteForSubscribe disabled
commit

set profiles signaling ipSignalingProfile DEFAULT_SIP commonIpAttributes relayFlags dialogEventPackage enable
commit

Perform REGISTRATION.

Perform a challenged SUBSCRIBE.

Platform/Feature: SBC

The code is modified to use the proper connection Id, when the usePortRangeFlag is enabled, and when the SUBSCRIBE request with Authorization header is sent to the egress peer.
25SBX-952612

Co-existence of 4xx-6xx IPSP flag and Subscribe crankback is not working.

Impact: Out of dialog message fails to crankback when the relay 4xx-6xx is enabled.

Root Cause: The relay flag must not take precedent.

Steps to Replicate: Configure the crankback and enable relay 4xx-6xx flag. The subscribe response with failure must be able to crankback.

Platform/Feature: SBC: SIP

For failure response, the crankback feature must take precedent.
26SBX-95941 / SBX-959303

Portfix SBX-95941: An unknown header transparency flag interaction with Tagging.

Impact: STIR-SHAKEN related headers are duplicated when the STI service type is tagging and transparency is enabled.

Root Cause: This scenario was not handled when STIR-SHAKEN was supported in 7.2.0.

Steps to Replicate: STI Profile is assigned on Ingress and Egress TG, on Ingress STI Profile “Override P-Headers with configured values”  flag is enabled.

In egress IPSP (IPTG section) “Unknown header” transparency flag is enabled.

Platform/Feature: SBC

STIR-SHAKEN related headers are given higher precedence and ignored transparency for the P-ORIGINATION-ID and P-ATTESTATION-INDICATOR headers when the STI service type is "tagging".
27SBX-92128 / SBX-919962

Portfix SBX-91996: The SBC fails to send a=fmtp parameter towards the UAC, when the SBC received a=fmtp parameter above a=rtpmap in the answer from UAS.

Impact: The SBC fails to send a=fmtp parameter towards the UAC, when the SBC received a=fmtp parameter above a=rtpmap for the Dynamic Payload in answer from the UAS.

Root Cause: When the FMTP line is received prior to the RTP line for a dynamic payload, Internal Logical issue is causing the issue. When the string holding FMTP line is terminated with \0, the SBC unable to parse manually.

Steps to Replicate:

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

  1. The SBC must be configured to handle the AMR passthru call.
  2. The transcoding must be set as conditional.

Test Procedure:
=============

  1. The UAC sends Invite with AMR WB codec.
  2. The UAS sends 180 Ringing with AMR with following SDP:

m=audio 6084 RTP/AVP 106 100
a=fmtp:106 mode-set=0,2,5,7;max-red=0
a=rtpmap:106 AMR/8000
a=rtpmap:100 telephone-event/8000

Platform/Feature: SBC

The code is modified to handle internal logic when FMTP line string is terminated with \0.
28SBX-95831 / SBX-933602

Portfix SBX-93360: The SBC was sending an INVITE with the SRTP instead of RTP.

Impact: The SBC is sending the SRTP instead of RTP.

Root Cause: The intersection of working PSP and peer PSP does not take place in the stream absent case. The SRTP values are never updated.

Steps to Replicate:

  1. Create a UAC with RTP.
  2. Create two UAS with SRTP param.
  3. Send a port =0 for hold response.
  4. Check if the SBC is misbehaving while sending an INVITE to release hold from the far end.

Platform/Feature: SBC

The code is modified for the SRTP values for stream absent case.
29SBX-95520 / SBX-716233

Portfix SBX-71623: The SMM header criteria not matching complete header value.

Impact: The SMM header criteria was not matching complete header value, it is only checking for the value between <>.

Root Cause: The SMM value being checked is enclosed between <>.

Steps to Replicate: Write a criteria on the header value and the issue will be displayed.

Platform/Feature: SBC: Application

The code is modified to consider the entire header of comparing the criterion.
30SBX-95995 / SBX-858522

Portfix SBX-85852: The "Timeout detected -- Forcing read/write access" occurred during switchovers.

Impact: The message "Timeout detected -- Forcing read/write access" is observed during switchovers.

Root Cause: This message is logged on the NBI timer expiry (after 2mins) and configuration changes were allowed before the DBs are in sync. This occurs when standby initialization takes longer.

Steps to Replicate: Install the SBC with the fix build and perform a switchover. Ensure there is no timeout message and that configuration changes are allowed only after the DBs are in sync.

Platform/Feature: SBC

The code is modified to allow configuration changes only when both the CDB and ORACLE DB are available for READ_WRITE and when the sync is completed.
31SBX-945182

Disable media lockdown does not suppress the 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 one second media drop while re-learning for the new re-INVITE is happening. For non-NAT cases, nothing will be observable except for signaling change.

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

Steps to Replicate:

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

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

Platform/Feature: SBC

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

The R-URI in NOTIFY messages was not using the correct port number in case of TLS.

Impact: The SIP NOTIFY messages relayed through the TLS, may contain a R-URI that uses the SIP signaling port number verses the TLS port number.

Root Cause: The relay software used the SIP signaling port number instead of using the TLS port number.

Steps to Replicate: The steps cannot be reproduced.

Platform/Feature: SBC: Call Control

The code is modified to use the TLS port number when relaying the SIP NOTIFY messages.
33SBX-599082

When the SBC receives route header with a port and TLS, it increments the port number.

Impact: When the SBC receives route header with a port and TLS, it increments the port number.

Root Cause: The SipSgPopulateAndSendToEgress() incorrectly increments the TLS signaling port number, when an out-of-dialog SIP OPTIONS message being relayed contains a "transport=TLS" parameter in the top most ROUTE header, and TLS transport is used.

Steps to Replicate: When the SBC receives OPTIONS with the Route header, the SBC relays that OPTIONS to a Port+1.

Platform/Feature: SBC: SIP

The code is modified to prevent incorrectly incrementing the TLS signaling port number, when an out-of-dialog SIP OPTIONS message being relayed contains a "transport=TLS" parameter in the top most ROUTE header, and TLS transport is used.
34SBX-958102

The PrsP cored on the standby SBC node.

Impact: The standby PRS process core was triggered from the XRM, when processing the XRM_DEALLOCATE_CMD_MSG from the standby SIPFE before the XRM has received the RTM_SYNC_TO_ACT_START_NFY_MSG.

Root Cause: There were many registration bind timeouts reported on the active SIPFE that triggered deallocation of the registration blocks and closing of port range connections. An active SIPFE mirrored the port range connection close requests to the standby SIPFE that triggered XRM_DEALLOCATE_CMD_MSG being sent to the standby XRM. The bug was that active SIPFE used regular ICM alloc/send mechanism to send the redundancy requests while standby node was in the middle of sync to active node.

Steps to Replicate:

  1. HA pair, SIP registration load test, with high number of registrations.
  2. Cause registration binding timeouts.
  3. Restart the standby node.

Platform/Feature: SBC

Replace the regular ICM alloc/send with an RTM alloc/send in SIPFE when mirroring the port range connection close request to the standby node. The RTM then delivers the request to standby SIPFE properly based on the RTM sync state.
35SBX-958953

The 4 SCMs cored after switchover.

Impact: The SCMs have cored after a switchover.

Root Cause: There is a bug that allows the RTM to attempt to process the Call Audit fault while still in the STANDBY mode. Since the Call Audit fault must only be processed while in the Active Mode - this causes a core.

Steps to Replicate: The steps cannot be reproduced.

Platform/Feature: SBC

The code is modified to prevent the RTM from processing the Call Audit fault while in the STANDBY mode.
36SBX-93067 / SBX-749222

Portfix SBX-74922: Modem calls failing when the DSP engaged in the ingress SBC.

Impact: The Bell 103 Modems in a G711-G711 transcoded call does not succeed.

Root Cause: The SBC G711-G711 transcoded calls perform a DTMF detection and the removal operation that can falsely remove some short signals, which is fine for speech perception but can affect modem signals that have similar characteristics of some modem signals. The SBC has signal detector for more modern modem that send a 2100 Hz tone to precede actual modem transmission. Once that is detected, the DSP media handling disables the DTMF removal. The SBC, however, does not detect older modems that sends a 2225 Hz signal in the beginning.

Steps to Replicate: 

  1. Make a G711-G711 forced transcoded call. Ensure that both legs have the DTMF remove enabled (dspchanstat).
  2. Use modem2225g711.pcap that has the modem signal captured from the customer in the ingress.
  3. Collect the media capture for the call and inspect the dspchanstat, as well as the output signal from egress.
  4. The dspchanstat and faxconfirmed field show 0x0. Signal output shows drops in the FSK modem signal between 18.72 and 19.65.

Platform/Feature: SBC

The code is modified to look for the 2225 Hz tone of at least 750 ms at which point, the DTMF remove feature is disabled. It is important to understand that this fix only applies to G711-G711 transcoded calls and not any compressed calls.
37SBX-960942

Port the fix for SBX-86420 to 6.2 and 7.2 code branch.

Impact: Whenever the TLS transport is selected, the SBC is trying to increment FQDN port by 1. In this case, even when FQDNPort is Zero in SIPSG/SIPS, the port is incremented by 1. So the FQDN port is set 1 because of this SRV query is not sent to the DNS server.

Root Cause: Whenever the TLS transport is selected, the SBC is trying to increment FQDN port by 1. In this case, even when FQDNPort is Zero in SIPSG/SIPS, the port is incremented by 1. So the FQDN port is set 1 because of this SRV query is not sent to the DNS server.

Steps to Replicate:

  1. Send an INVITE with the TGRP parameters in R-URI.
  2. The SBC sends the TGRP information to the PSX.
  3. The PSX does TGRP based routing and sends route.
  4. The SBC must send the SRV query to the DNS to resolve port and IP details when egress peer is FQDN.

Platform/Feature: SBC

In case of the TLS transport at egress, remote the fqdnPort is incremented by 1 only when the port received from the PSX other then zero. A check is added in sipsgSendFsmRmAlloc() function.
38SBX-96305 / SBX-961702

Portfix SBX-96170: When the SBC executes a "Teardown" to UPDATE request by the SMM, the To header and From header of response are malformed.

Impact: Write an SMM Rule to do a teardown on an UPDATE Request and Error Response has Malformed headers.

Root Cause: When a server request of UPDATE request is saved, optional headers are not being saved.

Steps to Replicate: Write a SMM rule to tear down update request with the 415 and the issue will be reproduced.

Platform/Feature: SBC

The code is modified to save the headers when saving an Update message as a server request.
39SBX-957062

The direct media (release) not working, no x-dmi to BSFT in the 200 OK while the 18x has it.

Impact: The 200OK behindNapt and direct Media support is unable to treat as direct media.

Root Cause: The issue is due to an internal offer/answer update after the first 18x, the previous flags for behind NAPT was lost.

Steps to Replicate:

  1. Ingress configuration behind Napt and direct Media support.
  2. Egress sends the SRTP Invite and peer response 18x with non-secure RTP. Subsequent 18x/2xx sent to ingress is missing x-dmi line.

Platform/Feature: SBC: Media, Platform, SIP

The code is modified to update the flags again when received in subsequent 18x/2xx.
40SBX-945462

To TAG broken when dialogTransp enabled and downStreamForking enabled.

Impact: When the dialog transparency, downstream forking and end to end PRACK is enabled, the SBC intermittently sends incorrect tagging in outgoing PRACK towards the egress.

Root Cause: A previous fix (SBX-63508) tries to address the scenario where downstream forking is enabled, dialog transparency is enabled and the 183 for the second dialog comes before PRACK when the first dialog is sent. But the pstCall structure was pointing to memory that may have been freed and re-used for storing some other SIP Message. So the To Tag sent from the SBC in an ACK message was incorrect.

Steps to Replicate:

  1. Enable Downstream forking, dialog transparency and E2E PRACK.
  2. Outgoing ACK from the SBC to egress has incorrect to Tag.

Platform/Feature: SBC: SIP

The code is modified to ensure to tag in the ACK message sent from the SBC is correct.
41SBX-96802 / SBX-964482

Portfix SBX-96448: ICE not getting completed when the simultaneous ringing is enabled.

Impact: When simultaneous ringing is enabled to multiple MS teams endpoints, in certain cases where the ICE STUN requests are received by the 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 through the SBC.

Root Cause: The SBC answers the first STUN message with a 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 the SBC to MS teams and verify that irrespective of when the endpoint answers the call voice media can flow through the SBC. Test must be repeated around 10 times and call answered from a different end point each time.

Platform/Feature: SBC

The code is modified so that after receiving a SDP with the ICE ufrag in signaling message. The SBC only completes ICE learning against the stun requests that have the same remote ufrag as that received in the SDP.
42SBX-96817 / SBX-951702

Portfix SBX-95170: To allow early RTP ICE learning for the MS teams DLRBT media bypass scenarios.

Impact: In a media bypass call flow with the 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 a useCandidate = 1 because it did not get 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 not responding to STUNs until an answer SDP is 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, enable the ICE learning and respond to STUNs on the RTP port.
43SBX-945792

Upgrade set all the CNAM Trunks to a Subscribe Rate of 1.

Impact: When the LSWU upgrade is completed, 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 the values were not set).

Steps to Replicate:

Configure SIP Trunk Group CAC ingress/egress subscribeRateMax and subscribeBurstMax, for example:
% set addressContext default zone ZONE sipTrunkGroup SIPTRUNK cac ingress callRateMax 1 callBurstMax 1 registerRateMax 1 registerBurstMax 1 callLimit 0 emergencyOversubscription 0 extendedEmergencyIpLimit 0 subscribeRateMax 10 subscribeBurstMax 20 otherReqRateMax unlimited otherReqBurstMax unlimited hpcOversubscription 0
% commit
% set addressContext default zone ZONE sipTrunkGroup SIPTRUNK cac egress callRateMax 1 callBurstMax 1 registerRateMax 1 registerBurstMax 1 callLimit 0 emergencyOversubscription 0 extendedEmergencyIpLimit 0 subscribeRateMax 10 subscribeBurstMax 20 otherReqRateMax unlimited otherReqBurstMax unlimited hpcOversubscription 0

Perform an LSWU upgrade.

See 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.
44SBX-96856 / SBX-921172

After an upgrade, the SWAP partition has a wrong UUID.

Impact: The file /etc/fstab had an incorrect UUID for SWAP partition due to the timeout logs were seen on the boot-up.

Root Cause: As part of multiple upgrades going through different versions, the SWAP partition UUID has somehow been changed but the same is not reflected in fstab file.

Steps to Replicate: Install/upgrade to fix version and ensure there is no swap entry in fstab file and also there is no timeout logs.

Platform/Feature: SBC

The code is modified to remove the SWAP entry from the /etc/fstab file as there is not SWAP enabled on the SBC. So, after installing/upgrading to the fix version, there is no timeout logs.
45SBX-737193

The SMM writeCdr was failing to write to ATTEMPT CDR when acting upon 300 Multiple Choice.

Impact: The SBC is failing to write the SMM fields in the ATTEMPT CDR when acting upon the 300 Multiple Choice.

Root Cause: The code was missing to handle the SMM information for a Redirect Scenario in the CDR.

Steps to Replicate: Test Redirect cases, and ensure SMM CDR write operation is successful in ATTEMPT record.

Platform/Feature: SBC

The code is modified to write the SMM information in the CDR for a Redirect Scenario.
46SBX-96691 / SBX-946622

Portfix SBX-94662: The SBC is unable to handle emergency calls (E911) when ICE is enabled.

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: An issue in 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 via 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 via the trunk group and verify the call succeeds.

Platform/Feature: SBC: Media, SIP

The code is modified to process the ICE data correctly when a call is transitioning to using emergency bandwidth.
47SBX-96770 / SBX-967232

Portfix SBX-96723: The Zone SMM Profile was not working when performing a sbxrestart/reboot.

Impact: The Zone SMM is not getting applied when performing a SBC restart.

Root Cause: The Zone SMM profile is not being restored during an SBC restart.

Steps to Replicate: Attach a Zone Profile with the fixed order, and run a call. The Zone SMM profile will be applied, and when performing a  SBC restart and running the call, the Zone SMM is not getting applied.

Platform/Feature: SBC

The code is modified to restore the Zone SMM Profile during an SBC restart.
48SBX-97194 / SBX-969372

Portfix SBX-96937: Running the sysDump.pl on Openstack restarts the SBC.

Impact: Running the sysDump.pl on the 8.2.0R0 release on the SBC Openstack cloud platforms causes the SBC application to restart.

Root Cause: The openclovis is monitoring some files as markers, using notify and taking it down when the file open operations are done.

Steps to Replicate: Once the SBC application is up and running:

  1. Run sysDump.pl and enter the default inputs.
  2. The SBC application will not go down.

Platform/Feature: SBC

As part of sysdump, backing up of /opt/sonus/sbx/openclovis/var/run/notify directory is excluded.
49SBX-96945 / SBX-96939 2

Portfix SBX-96939: The ImPr cored when the SBC was running a call load.

Impact: The SBC ImProcess cored when the LI server became unavailable.

Root Cause: When the LI server becomes unavailable and a large number of packets are queued up for that server, the ImProcess takes more than 10 seconds to clean up all those packets, and the process coredumps.

Steps to Replicate:

  1. Establish a large number of LI calls.
  2. Bring the LI server down.
  3. Ensure that the ImProcess does not coredump.

Platform/Feature: SBC

The code is modified to disable the healthcheck while cleaning up the packets.
50SBX-951762

7k DSP falsely detecting fax tone on music.

Impact: SBC falsely detects a modem tone (2100 Hz with phase reversals) for certain type of music.

Root Cause: Algorithm for modem tone detection first looks for 2100 Hz tone for 630 ms and a non-zero number of phase reversals. In certain type of rich harmonic tones, this results in large number of phase reversals. Typically for modem tones we expect no more than 2 phase reversals in 630 ms.

Steps to Replicate: Make g729 to g711 calls and stream the pcmu_stream1_withsilence3.pcap from the g711 leg.
Before a fix, a modem is detected on this signal as indicated in the dspchanstat.
tone2100PhaseRevCnt: 1.

Platform/Feature: SBC: DSP

Modem tone detection algorithm is modified so that in case it finds a modem tone for 630 ms, in case number of phase reversals is larger than 3, its rejected as a spurious detection.
51SBX-946982

The SBC does not send invite to subsequent routes in native forking when the SBC receives Invite with call-ID as "i".

Impact: An incoming short callId header "i" fails to send subsequent Invite for multi routes.

Root Cause: There was missing logic to look for callId header with a short name.

Steps to Replicate: Configure the native forking call and have incoming call with short name "i' for callId header.

Platform/Feature: SBC

The code is modified to support short header name callId.
52SBX-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 sending 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.

53SBX-968342

Asymmetric PRACK Interworking was not working as described.

Impact: Whenever any codec entry is deleted from codec list in the PSP and in the PSX, it rearranges the codec list immediately. There will not be any empty codec entry in the list.

The same issue is in the ERE, so it can be treated as a bug in the ERE.

Root Cause: When any CodecEntry is deleted, it is not rearranging the CodecEntry, which causes a NULL value in that place.

Steps to Replicate:

1. Configure the CodecEntry1 ,CodecEntry2 to CodecEntry12
2. Delete any CodecEntry.

Result: The call will be successful.

Platform/Feature: SBC: ERE

The code is modified so that there is no NULL value in between the two CodecEntry's.
54SBX-933293

Update scripts in the common/debian/install/sbx-install and orca/install.

Impact: Monit paths needed to be updated with the new definitions.

Root Cause: New definitions were introduced for monit paths.

Steps to Replicate: The steps cannot be replicated.

Platform/Feature: SBC

Updated the monit paths to resolve this issue.
55SBX-954742

The LCA errors seen when the SBC is spawned.

Impact: A sbcDiagnostic.sh flags error in the LCA, because it greps for ERROR.

Root Cause: The keyKeeper.py prints in the lca.log ERROR whenever it is unable to delete a file that contains a pswd. The file may already be deleted or not even created, this may also throw error.

Steps to Replicate: Run the sbcDiagonostic.sh and check no errors are present from keyKeeper.py.

Platform/Feature: SBC

The code is modified so the parameters sonusUtils.logger.error changes to sonusUtils.logger.info and some other logs so there is no grep ERROR.
56SBX-96952 / SBX-964712

Portfix SBX-96471: While trying to become active on a switchover, the systrem rebooted since the DRBD could not be switched to the primary.

Impact: While trying to become active on a switchover, the systrem rebooted since the DRBD could not be switched to the primary.

Root Cause: The DRBD is configured so that whenever a low level error occurs, the DRBD will be detached and the dstate will become "diskless". This scenario was leading the standby for reboot.

Steps to Replicate:

  1. Run "drbdadm detach mirror" on standby.
  2. Perform a switchover.
  3. The switchover will be successful.

Platform/Feature: SBC

While coming up as active after a switchover, the dstate of DRBD is checked, and if it is "diskless" the DRBD is attached before proceeding further.
57SBX-97545 / SBX-700593

Portfix SBX-70059: Support the HOLD/RESUME INVITE from the SIPREC SRS to pause and start pumping media towards the SRS.

Impact: With a second SIPREC server call hold, the RTP recording is not paused/stopped towards recording server.

Root Cause: With the RTCP snoop enabled, the NP API handler has an issue in handling the media snoop configuration update with a SIPREC hold.

Steps to Replicate: Test the SIPREC hold features with the RTCP snoop enabled.

Platform/Feature: SBC

The code is modified for the NP API handler to resolve this issue.
58SBX-94935 / SBX-908553

Portfix SBX-90855: The ASAN has a new-delete-type-mismatch on the SrchCriteriaIb.

Impact: The ASAN has a new-delete-type-mismatch on the SrchCriteriaIb.

Root Cause: The srchCriteriaIbArray is a dynamically allocated array in the GUISERVER, but it was not released using delete, so it is reported by ASAN.

Steps to Replicate: Re-run the testcase in the ASAN build and verify that the issue is not reported again.

Platform/Feature: SBC

The code is modified to fix the issue.
59SBX-873993

The IPACL causes a PRS deadlock.

Impact: The PRS process may coredump after the state disabling and enabling ACL rule(s), performing a switchover by powering the CE off immediately, and state disabling and enabling ACL rule(s).

Root Cause: The PRS used stale socket connections after the power off immediate switchover.

Steps to Replicate: Reproduce the PRS coredump issue by performing the following:

  1. Create the ACL rule using the installed role active CE when the HA system is synchronized (full redundancy protection).
  2. Perform a switchover to the installed roll standby CE.
  3. Wait until the HA becomes synchronized (full redundancy protection).
  4. Using EMA to installed roll standby CE:
    Disable the ACL rule
    Enable the ACL rule
    Disable the ACL rule
    Enable the ACL rule
  5. Verify that the system is synchronized.
  6. Power off the installed roll standby CE "Power Off Server - Immediate" using the BMC.
  7. Using EMA to installed roll active CE:
    Disable the ACL rule
    Enable the ACL rule <--- PRS CORED

Platform/Feature: SBC

The code is modified to re-open the connection to ConfD (on the immediate power off of the Active system), to prevent a PRS health check timeout coredump.
60SBX-944862

The SBC was not releasing the other leg when a call is disconnected during hold( MOH enabled).

Impact: The SBC was not releasing the other leg when a call is disconnected during hold( MOH enabled).

Root Cause: This is a race condition in the CC where the handler for the event ASG_DISC_CMD is not present, and for the CC state CC_VIRT_ESCR_VDREQ due the call being hung.

Steps to Replicate:

  1. Make a TEAMS to PSTN call.
  2. TEAMS holds the call (MOH).
  3. TEAMS disconnects the call during MOH.

Platform/Feature: SBC

Added a handler for the event ASG_DISC_CMD for the CC state CC_VIRT_ESCR_VDREQ, so that the DISC cmd gets propagated to the other active peer call side and the call gets terminated correctly.
61SBX-96178 / SBX-945622

Portfix SBX-94562: The ASAN has a heap-buffer-overflow in the SipSgACDMNaptQualTblAddEntry.

Impact: There was a Heap Buffer Overflow in the function SipSgACDMNaptQualTblAddEntry().

Root Cause: The Memcpy is being used instead of StrnCpyZ().

Steps to Replicate: Run the PCR 5637 regression on an ASAN Build.

Platform/Feature: SBC

The MemCpy is replaced by the StrnCpyZ().
62SBX-96180 / SBX-944022

Portfix SBX-94402: The SBC was not throwing a parse error in TLS if the content-length is not sent in a PRACK message.

Impact: The SBC is not throwing a parse error when the content-length Header is not sent in PRACK request using the TLS transport.

Root Cause: Similar code is present in the TCP Transport but not in the TLS-TCP transport.

Steps to Replicate: 

  1. Make a TLS call with the 100rel enabled.
  2. Send PRACK without content-length header for 18x.

Platform/Feature: SBC

The code is modified for the TLS-TCP Transport to resolve the issue.
63SBX-95118 / SBX-944032

Portfix SBX-94403: Unable to establish the same number of sessions after the switchover.

Impact: Calls were getting cleared under load conditions after a switchover in the first gateway in a GW-GW setup.

Root Cause: When the sessionKeepAlive is set and when the SBC switched over, the SBC starts sending refresh INVITEs to the endpoints. Since this is a GW-GW setup, a newly active GW-1 will send call processing messages to the GW-2. There was an issue in call processing at GW-2 that resulted in call failures.

Steps to Replicate:

  1. Create a SBC GW-GW setup and enable the sessionKeepAlive,
  2. Establish a call load of more than 25K and once call is stable, perform a switchover at the GW-1.
  3. Calls now start failing.

Platform/Feature: SBC

The code is modified to now take care of processing multiple segments and to successfully establish a GW-GW connection.
64SBX-94782 / SBX-943892

Portfix SBX-94389: When call transferring to the PSTN, the SBC was sending RTP/AVP instead of RTP/SAVP towards Teams in the ReINVITE.

Impact: The SBC was sending a Re-INVITE towards Teams with m= line protocol as RTP/AVP instead of RTP/SAVP. Because of this, Teams is sending a 488 call was failed.

Root Cause: After an abort_ann_tone event, the CC was not moving to cutthru mode.

Steps to Replicate:

  1. The 'Announcement based tones' flag is enabled.
  2. Make a call from the PSTN - Teams n/w.
  3. After a call connect, a Teams user transfers the call to another Teams user, and the call will succeed.

Platform/Feature: SBC

During an inbandtones event triggered in the CC, when an abort_ann_tone event returns and if the cutthru is already received, set the cutthru to cutthru_pending.
65SBX-973162

The Scm Process coredumps when there is NO ROUTE from the PSX = 0.

Impact: The Scm process coredumps when there is a call clearing with "no route found" from the PSX/ERE.

Root Cause: There was a bug in the call disconnect handler that resulted in the Scm crash for a non-configured number.

Steps to Replicate: Run a basic SIP call with a non-configured number and the Scm Process must not crash while handling the disconnect.

Platform/Feature: SBC: Application

The code is modified to handle call disconnects with 'no routes found' in the PSX/ERE without a Scm Process crash.
66SBX-863742

The early media PEM has a behavior issue if there is no PEM in 18x.

Impact: When the egress TG early media method is P Early Media and the P Early Media header is not received, the SBC does not send media to the ingress caller.

Root Cause: The audio data path mode is set to inactive for the PEM structure.

Steps to Replicate: 

1. PEM Header transparency is enabled and the egress TG configuration is listed below:

set addressContext default zone IPX_SIGNALING_VOLTE sipTrunkGroup 1009074301 media earlyMedia method pEarlyMedia
set addressContext default zone IPX_SIGNALING_VOLTE sipTrunkGroup 1009074301 media earlyMedia egressSupport enabled
set addressContext default zone IPX_SIGNALING_VOLTE sipTrunkGroup 1009074301 media earlyMedia defaultGatingMethod sendrecv
set addressContext default zone IPX_SIGNALING_VOLTE sipTrunkGroup 1009074301 media earlyMedia forkingBehaviour firstProvResponse

Call Flow: The 183 Session Progress from the egress contains SDP and no PEM header.
Issue: The SBC does not send media from egress to ingress and the caller receives dead air.

Platform/Feature: SBC

The code is modified to ensure the audio data path mode is set to default gating mode.
67SBX-99097 / SBX-943242

Portfix SBX-94324: In the SBC to GW to SBC scenario, the first SBC coredumps when the ingress invite contains four identity headers.

Impact: Making a GW-GW call that contains multiple identity headers will cause a crash.

Root Cause: There was a validation code to check that the internal CPC structures that carries the identity header information was correctly padded to a 4 byte alignment. This validation code was correct for one identity header but failed when more than one was present and as a result, triggered the system to crash.

Steps to Replicate: Send in an INVITE that contains two identity headers of type SHAKEN and route the call over a GW-GW connection to a second SBC.

Platform/Feature: SBC

The code is modified to ignore any padding rules for the particular internal CPC structures that carry the identity header information.
68SBX-98387 / SBX-983562

Portfix SBX-98356: There was a SEGV on an unknown address 0x0000000000e5 (pc 0x5653a715fdde bp 0x7f84a52bfea0 sp 0x7f84a52bfe70 T9).

Impact: After a successful surrogate registration, if any configuration related to the IP Peers/TGs/Surrogate registration is deleted, the Scm Process will coredump.

Root Cause: The code was dereferencing a null pointer when the trunk group configuration data was no longer present and the surrogate registration response came back.

Steps to Replicate: Trigger the SBC to send out surrogate registration request and delete all the associated trunk group configurations before sending back a response from the remote server.

Platform/Feature: SBC

The code is modified to check that the trunk group configuration exists before trying to read the configuration.
69SBX-956792

The trunks data cannot be displayed on the live monitor.

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

Root Cause: The Elastic Search interprets 'hypen' as a delimiter and as a result, the string is broken down into tokens for indexing. When a query is put in the ElasticSearch for data with trunkgroup name containing 'hyphen', no data is retrieved as the Elastic Search has stored the data not with the actual trunkgroup name but with tokens

Steps to Replicate: 

1. Create a trunkgroup with name containing hyphen.
2. Enable the Live Monitor.
3. Run Calls and wait for sometime.
4. Verify data is shown in Zone and Trunk Group based charts.

Platform/Feature: SBC

Before querying the ElasticSearch for data, check if trunkgroup name contains hyphen, if it does then it is broken into tokens and the token is used to query for data.
70SBX-978302

The ipRecMetadataProfile does not work for the request-uri in the V07.02.02.

Impact: INVITE SIPREC or SIPREC INVITE may not have a request-uri beta or core.

Root Cause: The logical error that 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.
71SBX-960282

The MAINTAIN ONLY CDR .ACT file extension during atomic write process was not utilizing the .TMP.

Impact: When the CDR files are copied to the remote server, the file is copied with a temporary extension .TMP. For some installations, the software running on the remote server moves those files with the .TMP extension before the SBC software renames them with an .ACT extension.

Root Cause: A temporary extension is used during the time files are copied to the remote server.

Steps to Replicate: Perform the following step:

  1. Unhide debug
  2. Set OAM accounting cdrServer admin primary useFilePostfix disable
  3. Transfer a large file.

Note that the file that is being uploaded to the remote server has an ACT extension while it is being transferred.

Platform/Feature: SBC

A new option is added to fix the issue:

  1. Unhide debug
  2. Set oam accounting cdrServer admin primary useFilePostfix disable

By default, the useFilePostfix is set to enabled.

When set to disable, a temporary extension is not used when copying the file to the remote server.

72SBX-976173

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 dereference 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 dereferencing it.
73SBX-978002

The PrsP cored on both the active and standby nodes at the same time.

Impact: The PRS process cored due to accessing a non accessible memory location while processing the MONSEC response from NP.

Root Cause: Based on the core analysis, the core dump was caused by an invalid MONSEC response from NP. There were many read media stats commands sent to NP at the same time with the MONSEC request. The response that was processing appeared like a valid PNPS_NP_RSP_RD_MEDIA_FLOW_STR response.Due to this observation, there may be some timing issue that sent media flow stat response to MONSEC.

Steps to Replicate: The steps cannot be reproduced.

Platform/Feature: SBC

The code is modified to check that npPoolId and numSecIds are in the defined range.
74SBX-978512

The SBC adds a media IP address in the outgoing SDP although the call is a direct media call.

Impact: When a direct media is enabled when handling the re-INVITE from ingress endpoint without a 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 the direct media is enabled, while handling a re-INVITE relay transaction, the SBC does not update the SIPStack SDP correctly.

Steps to Replicate: 

Configure for Direct media and enable the e2e Re-Invite.

  1. Send an Invite from A to B.


  2. B sends a re-Invite to A.


  3. A sends a re-Invite to B with SDP of 200 OK that is sent for previous re-Invite

Platform/Feature: SBC

The code is modified to ensure the SBC updates the SIPstack SDP for direct media scenarios.
75SBX-980983

All call registrations were failing on the SJ SBC7K.

Impact: RFC-5626 PING/PONG traffic may cause severe CPU utilization issues in the SBC.

Root Cause: RFC-5626 PING/PONG traffic was sent from the SAM process to the SCM process and back.

Steps to Replicate: Send a lot of RFC-5626 PING/PONG traffic.

Platform/Feature: SBC: Call Control

The code is modified to fast-path RFC-5626 PING/PONG traffic.
76SBX-969532

Investigate a PATHCHECK Process coredump.

Impact: The Pathcheck process may coredump (due to healthcheck timeout) when the zone tracerouteSigPort is enabled, and when the traceroute takes longer than 45 seconds to complete (after the endpoint becomes BLACKLISTED).

Root Cause: The Pathcheck process coredumps due to a healthcheck timeout when the traceroute to the BLACkLISTED endpoint takes longer that 45 seconds to complete.

Steps to Replicate: Enable the zone tracerouteSigPort, and configure an ipPeer in that zone that will become BLACKLISTED, and the traceroute to that ipPeer takes minutes to complete.

Platform/Feature: SBC

The code is modified to handle slower/longer traceroute completions.
77SBX-954753

A double SCM core resulted in an outage.

Impact: A double SCM core resulted in an outage.

Root Cause: While building the outgoing IAD message, there might be a case where the null values for a request message result in incomplete From and To headers, and cause a crash as a result.

Steps to Replicate: The steps cannot be reproduced.

Platform/Feature: SBC

The code is modified to avoid a coredump in cases where there are NULL values for a Request Message.
78SBX-98198 / SBX-979162

The STI and Privacy interactions are incorrect.

Impact: When the STIR/SHAKEN is enabled, a default privacy behavior was not given preference when the Privacy header is present in the ingress INVITE as follows:

  1. The STIR/SHAKEN is generating PAI/Privacy:id headers for all services when the PSX IPSP, SIP HTP, or PrivacyProfile->passThruPrivacyInfo is not configured to send the PAI header out. “Add verstat to PAI” flag is set, the SBC was generating the PAI/Privacy: id to add the verstat to PAI when no PSX IPSP, SIP HTP, or PrivacyProfile->passThruPrivacyInfo is configured to send the PAI header out.
  2. The PrivacyParamRestricted configuration must have preference over STI service. The PrivacyParamRestricted->default must anonymize the From and Contact headers when Privacy: user,id,header,or uri is present in the ingress INVITE even when STI is enabled.
  3. The PrivacyProfile configuration should be given preference over STI, when a privacy profile is configured to “applyPrivacyId/supportPrivacyId” and STI should not generate PAI/Privacy: id for any service.
  4. The STIR/SHAKEN is removing the “Privacy: User” header from the egress signal after anonymizing From and Contact header, when the IPSP Privacy->Transparency is enabled and Privacy: User header is present in the ingress INVITE.
  5. Anonymization format should be based on Privacy->Privacy Information and variantType.

Root Cause: 

  1. After the verification service, the verstat should either be added to the PAI or the From header. The “Add verstat to PAI” needs enhancement to enable adding the verstat to From if the PAI is not present in the egress signal.
  2. The PrivacyParamRestricted->default behavior anonymizes the From and Contact headers when Privacy: user, id, header, or uri is present in the ingress INVITE. The STI was not giving preference to PrivacyParamRestricted->default anonymization behavior for the privacy: id.
  3. The PrivacyProfile configuration was not given preference when the “applyPrivacyId/supportPrivacyId” is enabled, and the STI was generating PAI/Privacy: id headers.
  4. The SBC will not remove privacy: user after just anonymizing the From and Contact header and let the downstream switch(es) perform further anonymization.
  5. A preference was not given to Privacy information and variantType while determining the anonymization format.

Steps to Replicate: Configuration:

  1. Configure the STI profile on the SBC and attach the profile on to both the ingress and egress TG.
  2. Configure the STI profile for Signing/Tagging/Verification service on the PSX.

Observations:

  1. When no PSX IPSP->Privacy, SIP HTP, or PrivacyProfile->passThruPrivacyInfo configuration is enabled and the From is anonymized in the egress INVITE, PAI/Privacy header is generated.
  2. The Ingress TG->Signalling->PrivacyParamRestricted->default is configured. Observed that “From” and contact headers are not anonymized, if the privacy: id is present in the ingress INVITE.
  3. When no PSX IPSP->Privacy, SIP HTP, or PrivacyProfile->passThruPrivacyInfo configuration is enabled and privacyProfile configuration is:
    • The PrivacyProfile is configured with the “applyPrivacyId” flag enabled. The PAI/Privacy header is generated when the Privacy: id is present in the ingress INVITE.
    • The PrivacyProfile is configured with the “supportPrivacyId” flag enabled. The PAI/Privacy header is generated.
    (Note: The PrivacyProfile behaviour without any STIR/SHAKEN interactions. When PrivacyProfile is configured to “applyPrivacyId” and attached to the ingress TG or when the “supportPrivacyId” is configured in egress TG, the SBC will remove PAI headers from egress INVITE when the Privacy:id header is received in the invite. When the privacyProfile with the “supportPrivacyId” is configured in the egress TG, the SBC will remove PAI headers from egress INVITE, irrespective of the Privacy header.)
  4. The “Privacy: User” header is not present in the egress signal, when the IPSP Privacy->Transparency, SIP HTP or PrivacyProfile->passThruPrivacyInfo is enabled and the Privacy: User header is present in the ingress INVITE.
  5. The From and contact headers has “Anonymous@Anonymous.invalid” as opposed to "Anonymous” <sip:Restricted>. If the privacy: user header is present in the INVITE and when IPSP->Privacy->Privacy Information is P-Preferred-Id or Remote-Info Party.

Platform/Feature: SBC

When the STI is enabled, the Privacy behavior is given preference over STI, which effectively means no changes in privacy behavior.
  1. The STIR/SHAKEN does not generate the PAI/Privacy: id headers for any services when no control is set to send the PAI headers out(no PSX IPSP, SIP HTP or PrivacyProfile->passThruPrivacyInfo configured), one of the mentioned control must be set for the PAI header to go out. The “Add verstat to PAI” Flag is changed to the “Prefer PAI”, to enable sending verstat in From if PAI is not present in the egress INVITE.
  2. The PrivacyParamRestricted->default anonymizes the From and Contact headers when the Privacy: user,id,header,or uri is present in the ingress INVITE. The PrivacyParamRestricted->default anonymization behaviour for privacy: id is retained even when the STI is enabled.
  3. The PrivacyProfile is given preference over the STI service.
  4. The SBC is not removing the “Privacy: User” header after anonymizing the From and Contact header as part of STIR/SHAKEN service, when the IPSP Privacy->Transparency is enabled and Privacy: User header is present in the ingress INVITE. This enables the downstream switch(es) to perform further anonymization.
  5. The format of anonymized From and Contact headers when IPSP->Privacy->Privacy Information is P-Preferred-Id or Remote-Party-ID is retained even when the STI profile is enabled. The example below is for variantType,
From: "Anonymous" <sip:Restricted@example.com>;tag=gK08000282
Contact: "Anonymous" sip:Restricted@example.com:5060
Format of anonymized From and Contact headers when STI profile is enabled, when IPSP->Privacy set to P-Asserted-ID is as follows,
From: "Anonymous" <sip:Anonymous@Anonymous.invalid>;tag=gK080004bb
Contact: "Anonymous" sip:Anonymous@10.54.46.45:5060
79SBX-98566 / SBX-945132

Portfix SBX-94513: The Antitrombone will not have a kickstart but undesired pattern "PCR7400 Direct Media Antitrombone Call" is found in the dbg.

Impact: For a direct media call using X-dmi, the SBC is not preferring X-dmi over anti trombone direct media. This could cause one way or two way audio issue.

Root Cause: The SBC selects the Antitrombone direct media instead of X-dmi.

Steps to Replicate: 

  1. Run a basic XDMI DM call
  2. Run a basic DM with NAT call with XDMI
  3. Run a basic Antitrombone call with XDMI enabled

Platform/Feature: SBC

The code is modified to ensure the X-dmi is preferred over anti trombone
80SBX-98598 / SBX-969512

Portfix SBX-96951: Unable to write to the CDR in the ATTEMPT record due to 3xx.

Impact: Run a redirect scenario and write a SMM CDR operation on the 302 message. The CDR information is not populated in the attempt record.

Root Cause: The CDR information is not being updated to CC in this scenario.

Steps to Replicate: 

  1. Run a Redirect Scenario.
  2. Write a SMM CDR operation on the 302 message.

Platform/Feature: SBC

The code is modified to update the CC about the SMM CDR Information.
81SBX-95970 / SBX-937643

Portfix SBX-93764: The CAC handling is not working with the REFER and INVITE with replaces to 7.2.x.

Impact: In MS Teams call flows, they support music on hold service by default. The “on hold” feature was implemented by sending a REFER to the SBC so that the SBC then generates an INVITE out to the MS Teams music server and the B-leg is then released. The "off hold" feature was added to have the MS Teams phone replace the music on hold server call leg. Customer's are running with the CAC enabled in the lab and have call limit set to 10. Every time the SBC gets an INVITE with replaces, it reduces the CAC count on the ingress trunk group and then eventually fails.

Root Cause: The issue is that the Trunk Group and the Zone CAC are being performed for call pickup. Since CAC has already been performed for a call that is being picked up, a double count occurs that causes incorrect CAC failures.

Steps to Replicate: The steps cannot be reproduced.

Platform/Feature: SBC

The code is modified so the CAC is not performed for call pickup scenarios and for double counting all call licenses for call pickup.
82SBX-968583

A security patch drift for 7.2.4.

Impact: There are Nessus scan vulnerabilities.

Root Cause: There are Nessus scan vulnerabilities.

Steps to Replicate: Run a Nessus scan.

Platform/Feature: SBC

Update vulnerable packages to latest.
83SBX-93229 / SBX-871802

Portfix SBX-87180: Enable to trace with the TRC file SIP message outside the call, such as REGISTER and SUBSCRIBE.

Impact: Trace logs were not coming in the case of OOD when the trace level is set to 1 and the key is ipPeer

Root Cause: The current code does not send the TRC logs for OOD when the level is set to 1, and this option enabled now for OOD.

Steps to Replicate: Pre-Configuration:

-------------------------
admin@ELEANORSBX% show global callTrace | details
errorFilter {
errorType any;
}
maxTriggerCount 10;
callTraceTimer 111;
callFilter Naga {
state enabled;
level level1;
key peerIpAddress;
stopMatch unsupported;
match {
called "";
calling "";
contractor "";
redirecting "";
transferCapability unrestricted;
trunkGroup "";
peerIpAddress 10.54.81.11;
cddn "";
}
mediaPacketCapture disable;
}
signalingPacketCapture {
signalingPacketCaptureTimer 180;
state disable;
}
[ok][2019-04-19 14:44:24]

[edit]

In the configuration above, traces for all methods will be captured,

Platform/Feature: SBC

The code is modified to send the TRC logs when the level is set 1 and the key is ipPeer.
84SBX-986603

The heap-use-after-free in the DnsClientTcpMonitorDnsServerTimeout.

Impact: When using the DNS over the TCP, if there was a failure in reading from the TCP socket, the timeout processing was invoked for the outstanding DNS query and it was reading memory that has already been freed up.

Root Cause: This is an edge case error processing scenario where the pointers were being passed around internally and did not get updated to be null when the memory was freed.

Steps to Replicate: Issue was analysed based on a coredump and code review. The exact call scenario that caused the issue is unknown.

Platform/Feature: SBC

The code is modified to pass around the index values rather than the pointers and memory blocks being retrieved based on the index value that allows the code to verify if the associated memory block is free before accessing it.
85SBX-96686 / SBX-944862

Portfix SBX-94486: The SBC was not releasing the other leg when call was disconnected during hold( MOH enabled).

Impact: The SBC is not releasing the other leg when call is disconnected during hold( MOH enabled).

Root Cause: This is a race condition in CC where the handler for the event ASG_DISC_CMD is not present for the CC state CC_VIRT_ESCR_VDREQ and as a result, the call is hung.

Steps to Replicate: 

  1. Make a TEAMS to PSTN call.
  2. The TEAMS holds the call (MOH).
  3. The TEAMS disconnect the call during MOH.

Platform/Feature: SBC

The code is modified so that, the DISC cmd gets propagated to the other active peer call side and the call gets terminated correctly.
86SBX-945912

The CE_Node2 log fill up disk space causing a switch over.

Impact: The SYS ERRs from the CpcGenericCodecIsRfc3389Applicable() were filling up the SYS log and CE_logs quickly.

Root Cause: Based on the analysis of genCodecData in SCM core file and source code inspection, a bug was found in CpcGenCodecCriterionMatch() that could return an unpredictable value when all attributes are invalid in a specified criterion. In the SCM core, call control blocks were found in the SIPSG with the GSM audio encoding that has all attributes set to invalid in the criterion.

Steps to Replicate: The steps cannot be reproduced.

Platform/Feature: SBC

1. Fix the bug in the CpcGenCodecCriterionMatch().
2. Downgrade the debug message from the SipSgConvNsdMediaRawTransparencyToSdp() to the INFO level.
87SBX-979482

The SBC drops a request from egress to a registered user.

Impact: Non-Invite messages may drop if received immediately after a registration/Subscribe from the AS.

Root Cause: When a request was sent out to the server, internally, it creates a control block for handling the response. When a Peer sends a request back with the same callId, the SBC found the control block that is wrong and causing the SBC to drop.

Steps to Replicate: A register an to B, and the B send message back the SBC.

Platform/Feature: SBC

The code is modified to ensure the internal callId is unique so the incoming request can create a separate one.
88SBX-984012

A SIP-I Issue with HOLD for the SIP-I to SIP call.

Impact: The SIP-I body is not being sent out in a re-INVITE for HOLD.

Root Cause: The SIP subsystem is making a dip into the ISUP stack with wrong even type, that's why ISUP stack is not returning SIP-I body to be sent with.

Steps to Replicate: It is a complex scenario that is run into this situation when the re-INVITE for HOLD is to be sent out. It requires multiple offer/answers before the call is setup to end up in this situation. 

Platform/Feature: SBC: SIP Applications

If flag is set for PROGRESS and MID_CALL_INFO, the precedence is set to send the event as PROGRESS for dipping into the ISUP stack for ISUP body.


89SBX-96816 / SBX-958512

Portfix SBX-95851: The LeakSanitizer detected memory leaks in the DiamCsvAddPeer.

Impact: Unable to resolve the SRV fqdn for a diameter peer. Without this fix, the diameter connection cannot be established towards the diameter peer.

Root Cause: The wrong domain name is attached to diameter peer when a peer is created with the SRV domain fqdn internally in code.

Steps to Replicate: Create a  diameter peer with SRV fqdn.

Platform/Feature: SBC

Removed attaching the wrong domain name to the diameter peer when the SRV based FQDN is configured for a diameter peer.
90SBX-96754 / SBX-946193

Portfix SBX-94619: The intel microcode bundle is not the latest version.

Impact: There are vulnerabilities in hardware.

Root Cause: The CPU microcode is outdated.

Steps to Replicate: Run the Spectra-melt-down script on a host and check vulnerabilities.

Platform/Feature: SBC

The code is modified to reflect the latest version.

Resolved Issues in 07.02.03R000 Release 

The following Severity 1 issues are resolved in this release:


Resolved Issues


Issue IDSevProblem DescriptionResolution
1SBX-917231

Observing the CLI port SWO in the M-SBC is causing the MGMT link to go down.

Impact: On the CLI port, a switchover on packet interface has random connectivity loss for few seconds on other interfaces.

Root Cause: A bug in SWe_NP code was picking the incorrect NIF control blocks for standby ports causing intermittent signalling packet loss and a loss of ICMP packets resulting in connectivity failures. This happens specifically on high call loads, when workers are at 80% capacity.

Steps to Replicate:

  1. Bring up setup with port redundancy and perform multiple CLI switch over.
  2. Observe the link status of various ports.

Platform/Feature: SBC

The code is modified to correct NIF control blocks are chosen for standby ports.
2SBX-912731

The EMA receives a Proxy error whenever an operation takes a long time to complete.

Impact: When the user navigates to a SIP trunk group or DM PM rule creation screen, there is no response from the UI and after approximately a 2 minute interval, "Proxy error" is shown to the user.

Root Cause: The EMA reads the DM PM Rule, DM PM Sub Rule and DM PM Criteria data from the CDB through the Netconf interface. With a large amount of data, there is a significant delay in rendering the UI. The request from the browser times out, resulting in a Proxy Error to the user.

Steps to Replicate:

1. Configure more than 25,000 DM PM Criterias and more than 25,000 DM PM Rules.
2. Navigate to a SiP Trunk Group Creation Screen or DM PM Rule creation screen.
3. The create screen does not load and after some time results in Proxy error.

Platform/Feature: SBC

Instead of a CDB, the EMA reads the data for DM PM Rule, DM PM Sub Rule and DM PM Criteria directly from the Oracle Database, reducing the delay to a larger extent in rendering the UI.

When the Copy Trunk Group operation is performed, it can take up to 3 minutes to complete the copy operations. The 3 minute delay is due to the EMA performing some additional operation compared to new TG creation.

3SBX-91744 / SBX-914811

Portfix SBX-91481: The SamP cored. (Originated in release 6.2.4)

Impact: Under certain conditions, the SBC sends out a duplicate OPEN_ACK, causing the receiving GW to crash.

Root Cause: A bug in the GW Signaling code can cause a duplicate OPEN_ACKS to send when GW Signaling Links are bouncing.

Steps to Replicate: This problem is not reproducible.

Platform/Feature: SBC

The code is modified to only send out one OPEN_ACK per tcp/ip connection.
4SBX-91726 / SBX-878611

Portfix SBX-87861: While performing a port switchover, the SBC active performed a reboot and the Standby did not takeover the calls. (Originated in release 8.1.0)

Impact: An SWe_NP thread hang was observed on a packet port pull out.

Root Cause: A cable pull was calling a reset on an interface that may take more than 5s on a thread health check threshold, causing the thread to lock on reset.

Steps to Replicate:

  1. Bring up setup in port redundancy setup.
  2. Cable pull packet interface to trigger port switchover.

Platform/Feature: SBC

The code is modified to adjust the thread health check mechanism on a port reset.
5SBX-908771

Failover from Node-A to Node-B.

Impact: Healthcheck failure while switching from nodeA to nodeB.

Root Cause: Functions that configure the DRBD subsystem are taking longer and causing a health check timeout.

Steps to Replicate: Switchover from Active to standby.

Platform/Feature: SBC

The code is modified to run DRBD setup commands in the background and unblock the caller immediately.
6SBX-92274 / SBX-913321

The ipPeerCurrentStatistics and ipPeerIntervalStatistics are not working.

Impact: Getting the IP peer current statistics for individual IP peers was not working. The issue is reproduced when multiple IP peers are configured under the same zone.

Root Cause: Multiple IP Peers must be configured under same zone to reproduce this issue. When obtaining specific peer statistics, the peer name comparison within the same zone was missing.

Steps to Replicate: Configure multiple IP Peers under the same zone and then execute the command to obtain IP Peer Current/Interval statistics for a specific peer.

Platform/Feature: SBC

The code is modified by adding the comparison for IP peer specified in the CLI against the IP peer statistics list with other existing validations.
7SBX-91725 / SBX-909471

Portfix SBX-90947: The NP process core dumped while running a load on the HA setup.

Impact: A random SWe_NP crash occurs on a standby node while running a transcoded load.

Root Cause: RTCP resources are not managed properly by application layer on standby node. This causes a restart of already running timers on the SWe that causes a race and random crash.

Steps to Replicate:

  1. Run a large number of transcoded calls, on HA pair.
  2. Perform multiple swtichovers of SWE_NP coredump will be observed on standby node.

Platform/Feature: SBC

Maintain the state in the SWe_NP of running RTCP timers in the context block and guard the double start of timers.
8SBX-919851

The SIP calls drop with vertical service code *65 after a minute.

Impact: The SBC is not able to send ACK to the Egress for call to connect.

Root Cause: A logical error when combined with multi features (e2eAck, e2eReInvite, and DLRBT).

Steps to Replicate:

  1. Configure the e2e Ack, e2e reInvite, and DLRBT.
  2. Egress response 183(sendrecv), 183(onhold), 180(no SDP), 200OK(sendrecv).
  3. Peer change the SDP in 18x/2xx response causing internal offer/answer.
  4. Ingress peer sends the reInvite right after ACK, causing internal state not able to send ACK out.

Platform/Feature: SBC

Correct logical errors when multi features e2e ack, e2e reIvnite, and DLRBT are enabled.
9SBX-926601

The SBC failed over DEADLOCK detected and a ScmP core was generated as a result.

Impact: Access the NULL pointer in NRMA when deleting a tone profile.

Root Cause: The given targets name does not exist.

Steps to Replicate: Use CLI command to delete the non-existing announcement tone profile.

Platform/Feature: SBC

The code is modified to validate the return value from lookup function before accessing the value.
10SBX-921151

The SCMP coredump was related to ARS.

Impact: The SCM process may core dump when the SIP signaling port is out of service, and if calls are in progress and a SIP transaction timeout occurs.

Root Cause: If the SIP signaling port is out of service, and if calls are in progress and a SIP transaction timeout occurs.

Steps to Replicate: The steps cannot be replicated.

Platform/Feature: SBC

The code is modified to check that the SIP signaling port is in service when handling SIP transaction timeout events.
11SBX-917501

Observed "SamProcess" core dump on an active box while running SIP-GW (cyclic) calls.

Impact: The SBC may core if the GW Signaling Port configuration is disabled while GW Signaling Link is up.

Root Cause: The core is caused by an attempted NULL pointer access.

Steps to Replicate: Disable the GW Sig Port while GW Sig Link is up.

Platform/Feature: SBC

The code is modified to check for NULL pointer to GW Signaling Port before attempting to access this pointer.
12SBX-923861

When running the 7.2.1R2 release, the SBC is responding with 'a=inactive' instead of 'a=sendrecv' in a 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 the SBC on hold.

Root Cause: A missing requirement.

Steps to Replicate:

Step 1: Generate SIP scripts for a call flow.
Step 2: Setup 7.2.1 system without a fix.
Step 3: Run the call flow to see that the problem is observed.

Platform/Feature: SBC

The code is modified to send a=sendrecv to make it RFC compliant.
13SBX-920921

A possible memory leak in the 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 in the same AOR is received. This will only happen if multiple contacts in the AOR flag is disabled.

Root Cause: The code does not free certain memory blocks.

Steps to Replicate:

  1. Multiple contacts per AOR flag will be disabled
  2. Do a Register for particular AOR and do a de-register.
  3. Within less than 30 secs, re-send the registration for same AOR so that SIPFE selects the same preferred slot which 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.
14SBX-932851

Observing a box reboot while the application is coming up as standby after a port-failure.

Impact: After a node switchover, the standby node may reboot while the application is coming up.

Root Cause: During a node switchover, when application comes up on standby node, the health monitoring for worker thread fails because of an incorrect evaluation of CPU cycles spent by the thread. A failure to health monitoring causes the standby node to reboot.

Steps to Replicate:

Execute node switchover with the following steps:
1) Bringing down all active ports.
2) Applying the appropriate CLI command.
3) Fail the application on the active node.

Platform/Feature: SBC

The code is modified so the health check monitoring for the worker thread is correct.
15SBX-93553 / SBX-934691

Portfix SBX-93469: The DFW1-CASBC-02 Box A had a SCMP coredump. (Originated in release 7.2.3)

Impact: The SBC cored when accessing Box A, switching over to Box B instead.

Root Cause: Enabling the SDP transparency and the directMediaAllow to show a simple 18x response from the peer may cause a core dump due to access from an invalid address.

Steps to Replicate: Disable either the SDP transparency or the directMediaAllow.

Platform/Feature: SBC

The code is modified to ensure it does not have access with an invalid address.
16SBX-921551

The SBC is releasing the call with 504 when the DLRB and Downstream Forking are enabled.

Impact: The SBC releasing the call with 504 when the DLRB and Downstream Forking are enabled.

Root Cause: The race condition is not handled properly. When first 180 message without SDP is received, the forking list and stored the message were updated. The second time the 180 message with SDP was received, the forking list and stored the 180 message were updated, but since RTP learning was applied earlier, it was not replicated again.

Steps to Replicate: Send the RTP before sending the 180 Ringing (CSeq: 961529 INVITE RSeq: 629928).

Platform/Feature: SBC

If RTP learning happens before the corresponding 18x message with SDP is received, save the SDP into a queue of possible SDPs to cut-thru for use while 200 OK is received.
17SBX-935661

The WALL Signaling PSBC10A01 cored.

Impact: When the MRF Modify is received, the MRFRM fsm state must be OA_ACTIVE. But in this issue, the state is leading to incorrect typecasting.

Root Cause: The defensive was checked.

Steps to Replicate: Run the MRF load.

Platform/Feature: SBC

When the MRFRM is in OA-NULL state, the call must not be in connected state.
18SBX-933121

The SBC Memory has High alerts.

Impact: When the Local Ring back tone is configured on the SBC and egress endpoint sends a 183 Session Progress with 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 on the SBC and egress endpoint sends a 183 Session Progress with SDP followed by a 180 Ringing, the ScmProcess does not free up memory allocated even after call is completed.

Steps to Replicate: Run a call load with the Local Ring back tone configured and monitor the virtual memory usage of the ScmProcess.

With a fix, the virtual memory of ScmProcess must not be high after all calls have been disconnected.

Platform/Feature: SBC

The code is modified to ensure the memory allocated for packet service profile structure is freed when no longer required.
19SBX-918991

SBCv6 Unexpected 183 (CPG) sending - out of PER6608 spec.

Impact: Early cut through may not work for trusted configured RTP Servers on system restart.

Root Cause: The system restores the SIP service group data before the RTP Server data which is incorrect.

Steps to Replicate:

Provisioned the rtpServerTable (OLIVER_RTP_SRV_TBL), and associated it which the egress sipTrunkGroup SBXSUS9_LABSIP2
(as shown below):

admin@sbxsus9> show configuration details addressContext default rtpServerTable OLIVER_RTP_SRV_TBL
rtpServer 10.8.20.75 32;

admin@sbxsus9> show configuration details addressContext default zone ZONE4 sipTrunkGroup SBXSUS9_LABSIP2 media earlyMedia
method rtpServerTable;
rtpServerTableName OLIVER_RTP_SRV_TBL;
forkingBehaviour lastReceivedSdp;

Platform/Feature: SBC

Fixed the ordering of the initialization procedure to restore the RTP server profile configuration data before restoring the SIP service group data.
20SBX-926111

Outbound call Failing with 488.

Impact: Transcode call, after 40 onhold/offhold, call fail.

Root Cause: Internal process Nrma TransactionId did not reset properly after wraparound (12 bits limit). As resulted, it is sending the same transactionId for allocating DRM resources for both Ingress and Egress legs.

DRM reject due to duplicated transactionId.

Steps to Replicate: sip-sip call with transcoding. Call fail after 40 onhold/offhold.

Platform/Feature: SBC

 Properly reset the TransactionId when it reach 12 bit limit.
21SBX-940531

The P-SBC Openstack installation fails with an OAM node and core dumps.

Impact: Upgrade fails if any of the SNMP trap targets are 32 characters in length.

Root Cause: Right sized buffer was allocated to fetch data from the database but passed incorrect length field to database API. In the case where the field being fetched has max allowed length, the API fails because the API verifies that there is not enough room to terminate the field with NULL.

Steps to Replicate:

  1. Create SNMP trap target of 32 character long.
  2. Attempt to upgrade.
  3. The upgrade will fail.
  4. Perform upgrade with the fix, and the upgrade will succeed.

Platform/Feature: SBC

The code is modified to add the correct buffer length to configuration database APIs.
22SBX-937651

CS04A01 lost communication with the CM04A04. Post-recovery, other M-SBCs cannot talk to the CM04A04.

Impact: The IPv6 address becomes unreachable in standby port cable pull scenarios.

Root Cause: The SWe code was not handling saving the multicast mac address list and re-applying it on the 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 that PKT port.
  3. Re-insert the cable for same standby port.
  4. Do a port switchover by plugging out active physical port's cable so that the standby becomes active for same port.
  5. Ping the new configured IP from in step 2 from outside. The ping will result in a failure.

Platform/Feature: SBC

The code is modified to handle the programming of multicast MAC list for standby ports properly.
23SBX-94171 / SBX-941151

Portfix SBX-94115: The I/O scheduler was incorrectly configured after upgrade.

Impact: Kernel scheduling issues are causing intermittent issues, including lost pings across the HA interface. The lost pings induce a split brain and subsequent split brain recovery. Transient calls are lost during the split brain and recovery, and depending on call flow, stable calls may be lost as well.

Root Cause: The I/O scheduler is being reverted from 'deadline' to 'noop' due the upgrade due to a bug in the upgrade script.

Steps to Replicate: After upgrade to 6.2.x or 7.x, verify the scheduler with the following command:

cat /sys/block/sda/queue/scheduler

The output must show brackets around deadline to indicate it is in use, for example:

[root@SBX24-154a log]# cat /sys/block/sda/queue/scheduler
noop [deadline] cfq

Platform/Feature: SBC

The code is modified to properly specify the I/O scheduler.
24SBX-943131

There is a core dump during an A to B tandem call in (GSX)SIP-gw-gw-SIP(SBX) when the egress IP Signaling Profile is not configured.

Impact: The GSX-SIP-Gw-Gw-SIP-SBX has a core dump in the SBC if the egress Signaling Profile is not attached.

Root Cause: The issue was found by providing a fix to another issue, not through attempting a call with no egress signaling profile attached.

Steps to Replicate: Make an A to B call using the GSX-SIP-Gw-Gw-SIP-SBX and on the egress TG in the PSX. Do not attach the egress Signaling Profile. These steps will result in a core dump.

Platform/Feature: SBC

The code is modified to create a zeroed out IPSP and pass it for the system to act on instead of NULL the PTR. When the code looks for specific IPSP flags, none of the flags are enabled, but there is active memory.
25SBX-93931 / SBX-937991

Portfix SBX-93799: A SCM process coredump was observed when the sipParamFilterProfile is configured.

Impact: This issue is a result of a bug in a previous release (Configuring multiple JJ9030 profiles in a single commit does not work) fix.

Root Cause: Reading the Profile XML tag from the confd when the confd iterator is not pointed to a profile.

Steps to Replicate:

Configure the sipParamFilterProfile as shown below:
1. Set the profiles services sipParamFilterProfile as a Test sipHeader to require action passthru all.
2. The SBC will generate SYS_ERROR when the confd iterator is not pointed to the profile.

Platform/Feature: SBC

The code is modified to read XML tag from the confd when the confd iterator is pointed to the profile.

The following Severity 2/3 issues are resolved in this release:


Resolved Issues


Issue IDSevProblem DescriptionResolution
1SBX-924792

In the I-SBC, PKT Port redundancy support is not present in 7.2.2 release.

Impact: The SBC Release 7.2.2 is missing the PKT Port redundancy support, when it is listed as available.

Root Cause: In the I-SBC, the PKT Port redundancy support is added in the 8.x releases, but not present in the 7.2.2 release.

Steps to Replicate: Configure the pkt port redundancy, port the switchover to see the service continuity on PKT ports with redundancy enabled.

Platform/Feature: SBC

Back ported support is added in the 8.x to 7.2.2. releases.
2SBX-88061 / SBX-874043

Portfix SBX-87404: A reInvite is triggered before an ACK is verified. (Originated in release 6.2.4)

Impact: When the online validation (sessId and verId) is set to zero in 200OK, the SIPS fails to save the peer SDP.

Root Cause: When the o-line validation (sessId and verId) is set to zero in 200OK, the SIPS fails to save the peer SDP. This could trigger an unnecessary reInvite.

Steps to Replicate: Configure the SDP o-line version only. The SDP received in 200 Ok (multi codecs) for egress has a sessId and verId of zero. The SBC could send an unnecessary reInvite to the peer.

Platform/Feature: SBC

The code is modified so the peer SDP is saved properly.
3SBX-920372

Optional fax parameters are being parsed by the SBC and, as a result, the 200 Ok is being discarded.

Impact: The SBC returns a parser error (4xx) for unsupported t38 attributes.

Root Cause: When the unsupported t38 attributes are received, the SBC shows it as an error.

Steps to Replicate: When the Incoming call has unsupported t38 attributes, the SBC shows a reply 4xx (parsed error).

Platform/Feature: SBC

The code is modified so the SBC ignores the attributes and does not display an error message.
4SBX-916823

The MS Teams scenario with ICE causes the RTCP port value discrepancy with X when the RTP is Y and when MUX is supported.

Impact: When the SBC sends out re-INVITE messages on a call leg supporting ICE, it can still include a=rtcp:<rtp port + 1> value in the SDP that is different to the previously agreed RTP/RTCP MUX setup with the remote end.

Root Cause: The SBC was not considering the SDP answer from the peer when setting the RTCP port value.

Steps to Replicate:

1. Send INVITE to SBX ingress with valid audio stream in SDP.

2. From the egress endpoint, respond to the INVITE with a 180 ringing and a 200 OK, and in both cases include valid SDP that has an RTP ICE candidate (no RTCP).

a=rtcp-mux

3. At the ingress endpoint, respond to a 200 OK with valid ACK.

4. From ingress endpoint, send a re-Invite that includes an existing audio stream and add a new video stream in SDP.

5. Complete the call signaling and then clear the call.

Platform/Feature: SBC: MS Teams

The code is modified to send a=rtcp:<rtp port> when sending re-INVITE messages for streams previously agreed to support muxed behaviour.
5SBX-89807 / SBX-864953

Portfix SBX-86495: Add a lightweight MPSTAT analysis as a warning to the user. (Originated in release 8.1.0)

Impact: The SBC had random timeouts/healthchecks due to the high %steal (in mpstat output).

Root Cause: There is no warning given when the %steal value is high.

Steps to Replicate: On a VM or cloud machine, manually add a value in the mpstat.log and then run the script.

Plaform/Feature: SBC

The code is modified to check if the system is running with high steal% value and showing a warning to the user.
6SBX-907583

The SIP level4 call trace filter must not be restricted by the maxTriggerCount.

Impact: Level 4 call traces are incorrectly restricted by the maxTriggerCount value.

Root Cause: The intention is that the level 4 traces runs all messages and not be restricted by the system wide trigger count. The count must only apply to per call level 1-3 traces.

Steps to Replicate:

  1. Configure a level 4 call trace.
  2. Configure the maxTriggerCount to a non-zero value.
  3. Change calls that are traced as well as subsequent calls – once maxTriggerCount calls have been made, not be traced.

Platform/Feature: SBC

The code is modified to ensure level 4 traces are unrestricted.
7SBX-92266 / SBX-881222

Portfix SBX-88122: The SBC failed to re-establish media session between the SBC and MS Teams Client after a call transfer initiated by Teams client has failed. (Originated in release 7.2.1)

Impact: In scenarios where MS Teams referred the call to another, the SBC started to play a RBT (ring back tone) and if the REFER failed due to the C-party not answering, the media is not established again between the A and B party.

Root Cause: The media resource used to play the RBT did not get freed up correctly when the REFER failed and this blocked the media flow from A to B being re-established.

Steps to Replicate: Make a call from PSTN to MS Teams, have MS Teams REFER the call to another user. Let the phone ring as C-party but do not answer it.

Platform/Feature: SBC

The code is modified to correctly free up the RBT resources so the A- to-B call can re-establish.
8SBX-908672

The Ssreq coredumped on the SYD SBC.

Impact: The ssreq server has a memory leak that may eat up virtual memory, when there is call load through the ssreq client.

Root Cause: The memory allocated for call data and call trace is not being deleted properly, leaving those memory blocks idle forever.

Steps to Replicate:

  1. Set up the SBC system with a light or heavy call load.
  2. Add a call load through ssreq client to the system, light traffic is enough.
  3. Use the top command to watch the memory growth.

Platform/Feature: SBC

The code is modified to remove the memory blocks promptly.
9SBX-91585 / SBX-915102

Portfix SBX-91510: An ASAN global-buffer-overflow for the IPUtilGetIpAddressForPrefix. (Originated in release 8.1.0)

Impact: In the SBC, while validating whether the peer RTP address is trusted or not, the IP address is validated. While validating the IP Address, the prefix is passed along with the IP Address. The prefix length is passed as 128, irrespective of the IP Address version.

Root Cause: This issue was reported as part of the ASAN Testing on a PCR 8709 regression suite in the SBC lab.

Steps to Replicate: This issue was found while running a PCR 8709 regression test suite.

Platform/Feature: SBC

The code is modified by passing the correct prefix length and by checking the IP Address version (i.e. If IPV4, pass prefix length as 32. If IPV6, pass prefix length as 128).
10SBX-921372

The RTP is sent to RTCP after a monitor success indication.

Impact: The SBC learns the RTCP port number and uses that to send RTP packets to the end point when RTP monitoring is enabled.

Root Cause: When the RTP montoring is enabled for a call and the media stream sends RTCP packet within the number of packets for authorization, an Network Processor (NP) learns the RTCP packet and notifies the application about the sourceIP and sourcePort.

Steps to Replicate:

  1. Enable the RTP monitoring for a call.
  2. Send RTCP packet first and then RTP packets.
  3. The SBC may send to the learned RTP source port.

Platform/Feature: SBC

The SBC does not learn the RTCP packet when the RTP monitoring/x_cnt feature is enabled.
11SBX-91724 / SBX-910902

Portfix SBX-91090: PrsNP process core dump on standby of KVM-ISBC HA while doing an sbxrestart. (Originated in release 8.1.0)

Impact: There is rare potential of race in healthcheck implementation of SWe_NP. It can cause a false healthcheck failure of the SWe thread and a result in SWe_NP thread crash.

Root Cause: Read and write a healthcheck global variable occurred in non-atomic manner from two different cores.

Steps to Replicate: This is a rare occurrence that happens randomly on idle systems. The steps cannot be consistently reproduced.

Platform/Feature: SBC

The code is modified to make the healthcheck variable update as atomic.
12SBX-909463

Replace the cdb_get when processing status commands.

Impact: Multiple issues were reported where the process cored from healthcheck timeout. The application must not call out to the CONFD when processing the CLI status requests.

Root Cause: Application must not call out to CONFD when processing the CLI status request.

Steps to Replicate:

1. Configure IPSEC testbed.

2. Start to run some calls.

3. From CLI, issue the following commands: "show table addressContext <address context> ipsec ikeSaStatus" "show table addressContext <address context> ipsec ikeSaStatistics" "show table addressContext <address context> ipsec ipsecSaStatus" "show table addressContext <address context> ipsec ipsecSaStatistics" "show table addressContext <address context> ipsec systemStatistics"

Platform/Feature: SBC

The code IKE process code is modified to avoid calling out to CONFD when processing CLI status requests.
13SBX-920022

The DALSBX71A core dumped.

Impact: The SBC core dumped while processing a call with the call stack in 5.0.5R000 software.

Root Cause: NRMA has resources getting cleaned up in response to the ingress hanging up. At the same time, in response to egress received 183 Session Progress and 180 Ringing, the activate starts. In this race condition, the ipCktInfo is NULL and code illegally tries to access it and causes a core dump.

Steps to Replicate: No steps to replicate, only a code inspection was done to test the issue.

Platform/Feature: SBC

A null pointer check is put in place.
14SBX-92402 / SBX-912572

Portfix SBX-91257: No Ring back is heard during a blind transfer. (Originated in release 7.2.1)

Impact: The SBC was playing a ring back tone while processing REFER and transferring the call. However, the tone was not heard on the original call leg because MS Teams had put the original call on hold.

Root Cause: The code was intentionally not sending re-INVITE messages in this scenario.

Steps to Replicate: Run any MS Teams transfer call scenario.

Platform/Feature: SBC

The code is modified to send out a re-INVITE message to take the original call off hold so that it can hear the ring back tone being played.
15SBX-920912

Call Graphs are showing more calls after upgrade.

Impact: Stale calls may be found on a newly upgraded SBC if upgrading from a version older then 6.1.0 to a version higher.

Root Cause: As a result of changes that were made to the call ID in 6.1 code, any calls during the LSWU that existed prior to the upgrade and then were modified or terminated after the upgrade started will be left in a hung state.

The only way to clean up these calls is to use the following commands:

unhide debug
request sbx rtm debug command “cleanup <gcid>

Steps to Replicate:

1. Create an audit key greater than 31 by multiple switch over on a HA system or by using instrumented code.

2. The audit key will create GCID values using the high bits ( bit 30-31) of GCID value.

3. Setup SIP calls on the system.

4. Initiate the LSWU on standby and after standby is upgraded to newer version, all the established calls on active will be synced.

5. Start the LSWU on active.

6. At this point, standby will become Active.

7. Hang up calls that were 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. To verify the issue, perform the same steps mentioned above. After upgrading to version with fix, after calls are hung, resources must be released and show table global callSummaryStatus command will not show any orphaned calls.

Platform/Feature: SBC

The code is modified to prevent calls from being hung during an upgrade from versions older than 6.1.
16SBX-917383

When using the metaVariableDynamic, LinkDetection is not activated in the SBC.

Impact: If the LinkDetection interfaces are configured to use addresses specified in the systemMetaVariable dynamic table, those addresses are not properly read and the LinkDetection is not activated.

Root Cause: The addresses were not properly read from the metaVariableDynamic table.

Steps to Replicate:

1. Add new entries to the metavariableDynamic table.
2. Create an ipInterface with meta keys added to metaVariableDynamic table.
3. Configure the Link Detection on the ipInterface.
4. Check the Link Detection status.

Platform/Feature: SBC

The code is modified to properly read the addresses from the metaVariableDynamic table.
17SBX-920013

Memory leaks in the SIPSG.

Impact: While debugging a bug in a previous release (SCM crashed from segmentation fault fired from malloc()), memory leaks were found in the SIPSG related to subscription.

Root Cause: Observed through a source code inspection.

Steps to Replicate: Perform SIP regression tests.

Platform/Feature: SBC

The code is modified to free memory blocks properly.
18SBX-92430 / SBX-906542

Portfix SBX-90654: Unable to retrieve the parked call on MS Teams. (Originated in release 7.2.1)

Impact: The SBC was unable to retrieve a parked call. The call was not working correctly because the NRMA process had incorrectly swapped PSP information on the call legs.

Root Cause: This is a new call scenario being implemented for the MS Teams interop.

Steps to Replicate: Run a test call in the MS teams for call park and retrieve.

Platform/Feature: SBC: MS Teams

The code is modified to correctly process PSP information on the different call legs during parking and retrieving a call.
19SBX-92160 / SBX-919072

Portfix SBX-91907: The SBC fails to mount a cinder volume on first boot. (Originated in release 8.1.0)

Impact: The SBC fails to mount a cinder volume on first boot.

Root Cause: The bootcmd instruction to mount the volume was executed before the cinder volume was attached as part of instance creation. The cinder volume was not mounted on first boot and as a result, the SBC results in a failure.

Steps to Replicate: Launch the SBC instance with a cinder volume attached and ensure volume is mounted properly.

Platform/Feature: SBC

The code is modified to wait until the cinder volume is detected and then proceed with the mount.
20SBX-92414 / SBX-918202

Portfix SBX-91820: In crank back scenarios, the SBC is taring down the SRS call even before the CS call is torn down.(Originated in release 7.2.1)

Impact: The SBC was immediately disconnecting the SRS call after establishing the SIP Rec session with the next available SRS. The initial SRS responds with a failure 4xx response.

Root Cause: The SBC, after finding the next reachable SRS when the initial one has failed with 4xx response, creates a new SIP Rec Call Block data matching to new SRS. In the older version of the SIP Rec Call Block, the state machine was invoked with a incorrect event. The incorrect event in the state machine was causing the deletion of old SIP Rec Call Block along with deleting the new SIP Rec Call Block.

Steps to Replicate:

1. Create a SRS Group with three SRS Servers.
2. Configure the num streams to 2.
3. The SBC tries to send SRS Invite to first 2 SRS.
4. Send the 4xx response from the first SRS and 2xx response from the 2nd SRS.
6. After receiving the 4xx response, the SBC tries to send new INVITE to 3rd SRS.
7. Send a 2xx response from 3rd SRS.
8. At this step, after ACK towards 3rd SRS, SBC immediately sends BYE to 3rd SRS.

Platform/Feature: SBC

The code is modified to invoke the State machine with a proper event so that only the old SIP Rec Call Block data is removed and the new SIP Rec Call Block data is retained. This avoids immediate disconnection of new SIPREC Call that is established with the second SRS.
21SBX-910362

A DTMF transcoding caused the call to disconnect.

Impact: A certain percentage of the traffic (5%of the calls) are failing due to an incorrect DTMF payload being sent by BROADSOFT.

Root Cause: The SBC was expecting that for a single HD CODEC entry in the 200 OK ANSWER, the Peer/Endpoint must send a matching 16K DTMF payload as per the RFC standard. But the BROADSOFT server at the Egress side is non compliant and sending a 8K DTMF, which is causing the call disconnection.

Steps to Replicate:

1. Enable the DTMF either on both the legs and Different Transcode Flag.

2. Send the PCMU with DTMF 8K from Ingress leg.

3. From Egress side, send the PCMU without any DTMF.

4. Ensure that the call is transcoded.

Platform/Feature: SBC

The code is modified so the strict check is now relaxed and for single codec entry, the SBC does not match the DTMF clock with the codec clock frequency.
22SBX-915522

Q.850 reason header has a grammar issue.

Impact: Invalid format in the reason header in a SIP 500 message.

Root Cause: When the reason header transparency is enabled, a bug appears in the code.

Steps to Replicate: Enable the Reason header transparency along with ANM to CPG feature.

Platform/Feature: SBC

The code is modified so that even when transparency is enabled, the Reason header is sent out in the correct format.
23SBX-92658 / SBX-915993

Portfix SBX-91599: There was a ASAN stack-buffer-overflow on the address in the StrNCpyZ.

Impact: There is an array, which is being used with string specifier and is not null terminated, which causes the overflow problem.

Root Cause: A buffer overflow.

Steps to Replicate: The steps are not reproducible.

Platform/Feature: SBC

The log is removed to stop the buffer overflow.
24SBX-926212

*BrmRedBresAlloc messages are overloading DBG logs.

Impact: BRM redundancy messages were filling up DBG logs.

Root Cause: Those were debug messages to help debug resource leaking issue.

Steps to Replicate: Use regression test only.

Platform/Feature: SBC

Downgraded the related BRM redundancy messages to INFO/Minor level to avoid overloading the DBG logs.
25SBX-919522

Oracle Java JDK vulnerabilities were observed for Nessus scans.

Impact: The Nessus Scan was reporting that embedded java in Oracle database has security vulnerabilities.

Root Cause: Oracle 12c has Java 1.6.0_75 embedded.

Steps to Replicate: Run a Nessus scan and the earlier vulnerability will go away.

Platform/Feature: SBC

Upgraded the Oracle 12c 12.1.0.2 embedded java to 1.7.0_221 using the patch provided by Oracle.
26SBX-915702

Calls from MS Teams may have an audio loss for 30 seconds and then switch-over.

Impact: If there is an SBC switch-over after the call is established, there can be a delay (for example, 30 seconds) when re-establishing the media from the PSTN to MS Teams.

Root Cause: The stored SSN value does not get updated before the SBC switch-over occurs, and it causes the SSN to jump backwards after a switch-over, which causes the one way audio issue until the SSN value increments past the previously set value.

Steps to Replicate: Perform a switch-over after the LRBT is played and check that there is no one way audio issue.

Platform/Feature: SBC: MS Teams

After the LRBT is played, the latest SSN value is sent to the standby SBC so it can correctly jump the SSN forward on a switch-over and the media flow continues without delay post switch-over.
27SBX-908752

The LSASBX71 switched over and causes both sides to core.

Impact: A bug in GW Signaling code can cause a core when GW Signaling Links are bouncing.

Root Cause: A bug in GW Signaling code can cause a core when GW Signaling Links are bouncing.

Steps to Replicate: The steps are not reproducible.

Platform/Feature: SBC

The GW Signaling code is modified to prevent a core.

28SBX-917722

The application is generating "User Error: monitoring/0/101 PAM authentication succeeded" in .SEC file.

Impact: The SEC log records all successful PAM authentication, which is causing the disc to fill.

Root Cause: Due to constant value re-organization, successful PAM authentication has been mistakenly logged in to SEC log.

Steps to Replicate:

  1. Ensure that logs are configured at MAJOR level.
  2. Put a TLS load on the SBC.
  3. Many of the similar lines in the SEC log, as shown in the example below:

    154 07092019 155039.345656:1.01.00.56147.MAJOR .CHM: *User Error: monitoring/0/101 pam authentication succeeded via rest

  4. Apply the same procedure in a fix version SBC and those lines will not be seen.

Platform/Feature: SBC

The code is modified to exclude a successful case when logging in PAM authentication failures.
29SBX-933892

The MS Teams call flow when using hold/resume then transfer causes SCM crash.

Impact: When music on hold is used in the deployment and a call is put on hold/resumed and then transferred, the call is causing the SBC to coredump in the SCM process.

Root Cause: The SCM process was de-referencing a null pointer.

Steps to Replicate: Music on hold is used in the deployment and a call is put on hold/resume and then transferred.

Platform/Feature: SBC: MS Teams

The code is modified to validate the pointer as not null before trying to use it.
30SBX-92980 / SBX-924842

Portfix SBX-92484: The SBC is dropping the 2nd codec for a text stream when the sendOnlyPreferredCodec flag is enabled. (Originated in release 8.1.0).

Impact: The SBC was dropping the second payload for a text stream if the "Send Only Preferred Codec flag" was enabled and the offer answer contains both t140 and red as payloads for this stream.

Root Cause: The "Send Only Preferred Codec" flag's logic was applied even to a text stream that resulted in the SBC picking the first codec and dropping the other.

Steps to Replicate:

1. Bring up the setup for an A-B call.

2. Enable the flag t140 on both PSPs.

3. Enable the flag sendOnlyPreferredCodec on both IPSPs.

4. Send INVITE from A with both Audio and text media stream with 2 codecs for text(t140 & red).

5. Send 200 OK from B with both Audio and text media stream with 2 codecs for text(t140 & red). Both of the payload is received through the t140 and red is received and no payload is dropping.

Platform/Feature: SBC

The code is modified to exclude text stream from "Send Only Preferred Codec" logic.
31SBX-925802

The SIP Domain is missing in the FROM header after an upgrade.

Impact: The DM rule for the FROM Uri is not working.

Root Cause: Introduced in a previous release to treat the FROM Uri for theRewriteIdentity only.

Steps to Replicate: Configure the PSX for FROM Uri, and a SIP-SIP call. Verify the FROM header is picking up the DM rule of FROM Uri.

Platform/Feature: SBC

The code is modified to support the old behavior for allowing the FROM URI taking effect, even when RewriteIdentity is disabled
32SBX-929183

Inconsistent handling of the SDP in 200 OK on an egress SIP leg.

Impact: "Send Updated SDP in 200OK" was enabled and GW-GW call will fail when the 2xx response SDP is different from the previous 18x response.

Root Cause: The feature flag "Send Updated SDP in 200OK" is applicable for SIP-SIP call only.

Steps to Replicate: Turn on the flag, make a GW-GW call where the 200OK SDP is different from the previous 18x response.

Platform/Feature: SBC

Added logic to disable the feature even if configuration is enabled
33SBX-924702

The SamP has a memory leak.

Impact: There is possible slow memory leak in the SAM process when running GW-GW calls.

Root Cause: GWFE is leaking a copy of the incoming PDU that was queued internally.

Steps to Replicate: The steps are not reproducible.

Platform/Feature: SBC

The code is modified to free the memory that was being leaked.
34SBX-922522

The SBC was sending an INVITE out for the first user only.

Impact: The Native Forking fails to send out on 2nd route.

Root Cause: If an incoming call that has capital "CALL-ID", the SBC fails to find the parent incoming call.

Steps to Replicate: Configure the native forking feature, and incoming call has capital "CALL-ID".

Platform/Feature: SBC

The code is modified so the "CALL-ID" is case insensitive.
35SBX-925852

The SBC SWe is dropping packets on the pkt0.

Impact: The pkt0 interface stops pinging after a long time.

Root Cause: The SWe_NP code has a slow leak when it is in standby mode, causing the pkt0 to get exhausted after sufficiently long time.

Steps to Replicate: On a standby node, run a program/utility to send packet out of the interface.

Platform/Feature: SBC

Ensure all packets are freed that are read from the KNI devices in SWE_NP code.
36SBX-930562

The SBC failed to generate Enum lookup after updating the dynamic metaVariable.

Impact: The SBC failed to generate Enum lookup after updating the dynamic metaVariable

Root Cause: When the dynamic metaVariable updated for the sipSigPort, the trigger was missing for lwresdProfile and update of sipSigPort IP was not happening that causes the issue.

Steps to Replicate:

1.Configure the SBC for A-B call.
2.Create a dynamic metaVariable to add to sipSig port.
Example:

admin@vsbc1% show addressContext default zone ZONE_ING_V6 sipSigPort sipSigPort 3

{ ipInterfaceGroupName LIG_ING_V6; portNumber 5060; mode inService;

state enabled; transportProtocolsAllowed sip-udp,sip-tcp; ipVarV6 lpl_ing; }

[ok][2018-10-16 15:40:32] [edit] admin@vsbc1% q [ok][2018-10-16 15:40:34]

admin@vsbc1> show table system metaVariableDynamic

CE NAME NAME VALUE -----------------------------------------------------

vsbc1-10.34.195.109 lpl_egg fd00:10:6b50:5d20::c9 vsbc1-10.34.195.109 lpl_ing fd00:10:6b50:5d20::c7


3. Configure for an Enum call and run an Enum call make sure Enum over sipSigPort and observe an Enum call is successful over sipSigPort.
4. Update the dynanamic metaVaribale lpl_ing to fd00:10:6b50:5d20::ec and restart the SBC and try the call.
5. After updating the metaVaribale lpl_ing to fd00:10:6b50:5d20::ec, the Enum call must be successful.

Platform/Feature: SBC

The dynamic metaVariable trigger is added for lwresdProfile to update sipSigPort IP to fix the issue.
37SBX-933072

Configuring the multiple NNI profiles in a single commit does not work.

Impact:

The following tables are not read correctly by the SIP application, if multiple rows are changed in the same commit in the CLI:
E164 Profile
SIP Filter Profile
NNI Profile
Privacy Profile
PSX Script Profile
SIP Security Profile
SIP Param Filter Profile
SRVCC
STI Profile

Root Cause: There was a coding error.

Steps to Replicate:

  1. Configure two or more NNI profiles.
  2. Configure SIP trunk groups using each of the NNI profiles.
  3. When making SIP calls, the controls on only one of the NNI profiles (the one which is displayed first when running show command) are effective.

Platform/Feature: SBC

The code is modified to process multiple rows in a commit.
38SBX-923873

The service instance messages for "Call_Hold" and "Call_Retrieve" are not generated in some GW-GW scenarios.

Impact: When a SIP-SBX-GW-GW-GSX-ISUP call is intercepted, if hold/retrieve is received from either side, the SBC does not send service instance messages to the LI server.

Root Cause: The SBC is not sending the service instance messages to the LI server.

Steps to Replicate:

1. Start the LI server.
2. Initiate the SIP-ISUP call with HOLD from egress.
3. Check LI server logs for service instance msg for hold and retrieve.

Platform/Feature: SBC

The code is modified to pass the Hold/Retrieve indications from one GW to other GW.
39SBX-930892

Admin credentials are visible to non-root users during PM login.

Impact: The credentials for admin were visible to linuxadmin.

Root Cause: Previously a shell was invoked by PHP and inside it pamValidator was called with credentials as arguments.

Steps to Replicate: Run the following in a session as linuxadmin while

  1. Apply pgrep -a pam; done.
  2. Log into PM now credentials should not be present in the output of the command.
30131 /usr/local/bin/pamValidator 30131 /usr/local/bin/pamValidator 30131
 /usr/local/bin/pamValidator 30131 /usr/local/bin/pamValidator 30131
 /usr/local/bin/pamValidator 30131 /usr/local/bin/pamValidator

Platform/Feature: SBC

The code is modified so pamValidator takes input from the ENV instead of cmdline arguments.
40SBX-912113

"X509_STORE_add_cert failed 0" when multiple certificates are created using the same certificate file.

Impact: "X509_STORE_add_cert failed 0" error log is continually logged onto .DBG from the standby (HW only) when a remote certificate is added that does not have a 'success' status.

Root Cause: The certificate does not properly exist in CLI, therefore the certificate cannot be properly read from CDB.

Steps to Replicate: Create multiple certificates using the same remote.

Platform/Feature: SBC

The timer used to import the certificate on the standby now checks the certificate status and successfully exits in cases where the certificate status is not a 'success'.
41SBX-933262

Receiving text populated as null in mediaStream2Codec and in callMediaStatus.

Impact: When audio and text media call is made, the mediaStream2Codec of text is being populated as null.

Root Cause: Text has been removed from a fix in a previous release, which has made "mediaStream2Codec" field not to populate for text media.

Steps to Replicate:

  1. Bring up the box with the latest SBC build that supports T.140 session.
  2. Enable the following CLI and attach to Ingress and Egress TG's.

    -set profiles media packetServiceProfile DEFAULT flags t140Call enable


  3. Send INVITE with Audio+T.140 sessions from UAC.
  4. Send 200 OK with Audio+T.140 sessions from UAS.
  5. Send BYE.

Platform/Feature: SBC

The code is modified to include the text stream to populate "mediaStream2Codec".
42SBX-931243

The SBC changes the format of P-Access-Network-Info header on the 18x and 200OK.

Impact: When transparency is enabled in the P-Access-Network-Info Egress and received by P-Access-Network-Info in the 18x, the message forwarded to the ingress has an incorrect syntax.

Root Cause: A logical error related to double quote string parameter was causing a syntax error to be sent out.

Steps to Replicate:

  1. On SIP-SIP call, enable the header P-Access-Network-Info transparency.
  2. Egress receives P-Access-Network-Info in 18x and forwards to the ingress with an incorrect syntax.

Platform/Feature: SBC

The code is modified to correct the logical error.
43SBX-934762

Fix the double free scenario in NAT and in a multicast scenario.

Impact: There will be a random SWe_NP core dump when either NAT is enabled or the LI is enabled at peak loads.

Root Cause: There was double free of mbuf pointer, which can cause corruption.

Steps to Replicate: Run calls with the LI or NAT enabled at a peak load.

Platform/Feature: SBC

The code is modified to fix the double free of mbuf pointer.
44SBX-93325 / SBX-931752

Portfix SBX-93175: Receiving a null in the mediaStream2Codec and in the callMediaStatus. (Originated in release 8.1.0)

Impact: When a audio+ text media call is made, the mediaStream2Codec is being populated as null.

Root Cause: Text has been removed through a fix in a previous release, which has made "mediaStream2Codec" field to not populate for text media.

Steps to Replicate:

  1. Bring up the box with the latest SBC build that supports T.140 session.
  2. Enable the following CLI and attach to the Ingress and Egress TGs.

    -set profiles media packetServiceProfile DEFAULT flags t140Call enable


  3. Send INVITE with Audio+T.140 sessions from UAC.

  4. Send 200 OK with Audio+T.140 sessions from UAS.

  5. Send BYE.

Platform/Feature: SBC

The code is modified to include the text stream to populate "mediaStream2Codec".
45SBX-93551 / SBX-694123

Portfix SBX-69412: o= version was not incrementing. (Originated in release 6.0.0)

Impact: The SBC responds to an Update without an incremental SDP session version.

Root Cause: Enable the "Only Selected Codec in Session Refresh", peer answer the SDP in 18x, and send an Update with a different SDP. However, the SDP version did not increment.

Steps to Replicate: Enable the "Only Selected Codec in Session Refresh", peer answer the SDP in 18x, and send an Update with a different SDP.

Platform/Feature: SBC

The SBC responds to an UPDATE with a different SDP in a previous Invite. The SBC correctly increments the SDP version.
46SBX-93492 / SBX-907112

Portfix SBX-90711: ELT: Observed Negative accepted packets at the "request sbx xrm debug command acl\ -stat".

Impact: Observed a negative packet count for the ACL and aggregate ACL while running CLI commands.

Root Cause: We were using an incorrect format specifier. We were using %d to print an unsigned long instead of %u.

Steps to Replicate: Tested with pumping packets to specific ACL. The counters are working as expected.

Platform/Feature: SBC

Corrected the format specified usage.
47SBX-937142

Unable to configure more than 2 IPIFs into 1 IPIG.

Impact: Cannot create 4 IP Interfaces under a single IPIG in Yellowfin. As Yellowfin has a single NP, a port map needs to be created for all ports on the NP0.

Root Cause: During the Yellowfin development, creating 4 IP Interfaces in the same Interface groups was not evaluated correctly.

Steps to Replicate:

1. Attempt to create 4 interface groups under the same Interface group.
2. Associate it to other signalling elements such as sipSigPort to validate NP friendly checks.

Platform/Feature: SBC

Create a port map for packet ports pkt2 and pkt3 using the NP0.
48SBX-927803

'request SBC arm debug command' commands stop working after a switchover.

Impact: Request the SBC arm debug command help is not working when a switchover was made from active box to standby one.

Root Cause: Inside the ArmCsv.c, the CsvMgObjRegisterObject() was not enabled when "request sbx arm debug command help" is configured in Debug Mode.

Steps to Replicate:

1. Setup HA.
2. Start both the boxes.
3. Run "request system admin <SBC_NAME> switchover" to do a switchover.
4. Wait for full sync let standby box come as active.
5. Run "request SBX arm debug command help" on the new active SBC (former standby SBC).

Platform/Feature: SBC: CLI, confd

Enable the CsvMgObjRegisterObject(&armCsv->csvCb, "/sbx/arm/debug") function.
49SBX-932552

Unable to change the Source Port to any port on the EMA.

Impact: Unable to change the Source Port to any port on the EMA.

Root Cause: The source port attribute is validated as an integer instead of a Alpha Numeric.

Steps to Replicate:

  1. Successfully verified the loading of the EMA Application.
  2. Successfully changed the SourcePort number from 'any' to 'int' and 'int' to 'any'

Platform/Feature: SBC

The code is modified to validate source port as type Alpha Numeric instead of an integer.
50SBX-932872

The SBC was not responding to 483 for PRACK with the Max-Forwards=0 and rfc7332ValidateMaxForwards enabled.

Impact: If the SBC received a PRACK request with the Max-Forwards header value as zero, the SBC was not rejecting the request with 483 error response.

Root Cause: The part of code was missed from the code merge from 7.2 to main branch.

Steps to Replicate:

Test steps:
1. Send PRACK with Max-Forwards 0.
2. Verify the SBC is rejecting it with 483 Error response.

Platform/Feature: SBC

The code is modified to handle Max-Forward with 0.
51SBX-911542

There is a call failure due to a FQDN in the request URI.

Impact: When the SBC sends a query for SRV record to the external server and the Peer Domain in the reqURI is disabled, the SBC intermittently sends a FQDN in the request URI of egress INVITE. The correct behavior is to send an IP and address in reqURI of egress INVITE.

Without a fix, the SBC will send a 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 the SRV record and a record is found in the cache. As a result, the SBC cannot apply the "Peer Domain in ReqURI" flag in the egress SIP message.

Steps to Replicate:

  1. Use the following configurations on the PSX:
    1. Set the IP PEER as FQDN abc.com instead of IP address.
    2. Enable "noPortNumber5060" on the IPSP (This is for done for NAPTR, SRV query)
    3. Disable "Peer Domain in the reqURI " on IPSP (This is done to ensure FQDN is not sent in egress INVITE's reqURI)
  2. Use External DNS server.
    1. Configure SRV record and A record on the external DNS server with different Time To Live values.
  3. Run high number of calls.
  4. With fix, the SBC is sending IP and Port for all the calls since Peer Domain in ReqURI is disabled.

Platform/Feature: SBC

The code is modified to have the SBC use the saved formatted SIP message when the external DNS query is made for SRV record and a record is fetched from the cache. This allows the SBC to apply the "Peer Domain in ReqURI" flag in the egress SIP message.
52SBX-93562 / SBX-933552

Portfix SBX-93355: P-Charge-Info header not relayed by the SBC in out-of-dialog MESSAGE request even though the transparency setting is enabled.

Impact: P-Charge-Info Header is not relayed transparently for OOD Message even though Transparency profile is enabled for P-Charge-Info.

Root Cause: P-Charge-Info Header is dropped in case of relay framework.

Steps to Replicate: Run the message OOD which has P-Charge-Info Header in the incoming Message and Transparency is enabled for that header.

Platform/Feature: SBC

P-Charge-Info Header is copied in case of relay framework.
53SBX-941412

Call Transfer call to PSTN gets failed second time ,when MOH is played in the initial call.

Impact: After multiple holds and resumes, if the first call transfer fails due to reject by transfer target then the transferee and transferer are reconnected successfully. For any subsequent call transfer, the SBC is rejecting the call transfer request.

Root Cause: Since, the first call transfer failed, the SBC tries to reconnect the original call. As part of this, the original call is not moving to the stable state. So, any call transfer request in such state is getting 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

Added missing code to move the original call state to the stable state during re-connection.
54SBX-934752

IngressIpPrefix data deleted when removing SMM from TG.

Impact: IngressIpPrefix data deleted when removing SMM from TG

Root Cause: When deleting SMM Profile, code is there to delete ipPrefix data as well

Steps to Replicate: Remove a SMM rule from the TG in the EMA it also deletes the ingressIpPrefix metadata causing ingress calls to fail.

Platform/Feature: SBC

Added checks not to delete ipPrefix data when we delete the SMM Profile.
55SBX-93394 / SBX-925543

Portfix SBX-92554: TTY is not enabled for EVRC and EVRCB in the H/W SBC.

Impact: TTY was not enabled for transcoded calls of EVRC and EVRCB codec in the SBC 52x0 and SBC7000 and SBC54xx.

Root Cause: TTY was disabled for unknown reasons.

Steps to Replicate:

  1. Setup EVRC/EVRCB<=>g711 call.
  2. Send media with TTY characters from G711 side.
  3. Observe the PCAP of EVRC/B. TTY has special code points in the EVRC/B. Before the fix, TTY signals were encoded as EVRC codec media. With the fix, you will observe TTY special code points in PCAP.

Platform/Feature: SBC

Enable the TTY. There is no API/CLI to enable TTY.
56SBX-936013

MS Teams Call Park has an intermittent failure.

Impact: In a Microsoft Teams environment, Microsoft has a bug in the client code that can randomly cause messages to be sent out of sequence. For example, when trying to transfer calls, Microsoft can send REFER and then INVITE with a=inactive afterwards. The out of sequence message processing was causing processing issues on the SBC and the call did not complete.

Root Cause: Microsoft agrees that their message sending is broken and are working on a fix.

Steps to Replicate: Repeatedly run Microsoft Teams Call Park scenarios. The problem is not always reproducible and is possibly dependent on the Microsoft server and location of the associated client.

Platform/Feature: SBC: MS Teams

The code is modified to be more defensive against the out of sequence messaging, such as:
1) Reject the INVITE with 491 if REFER is being processed on a call leg.
2) Reject the REFER if the SBC has an outstanding INVITE waiting to be sent.

57SBX-93532 / SBX-934732

Portfix SBX-93473: The SBC is core dumping when the diversionHistoryInfoInterworking flag is enabled in the egress IPSP.

Impact: When the interworking diverts Diversion Headers to History Info for Japan NNI, on a call where ingress SIP performs an INVITE/UPDATE due to preconditions, the SBC core dumps.

Root Cause: The cause is from a code bug.

Steps to Replicate: Make an SIP-SIP call where ingress side has preconditions, such that INVITE/UPDATE sequence is needed. The received INVITE will contain Diversion headers. Egress side is configured with an NNI profile attached to the trunk group with historyInfoInterworking enabled.

Platform/Feature: SBC

The code is modified to no longer core dump.
58SBX-93608 / SBX-917872

Portfix SBX-91787: Debian vulnerabilities are observed for Nessus scans. (Originated in release 7.2.2)

Impact: Nessus scan display vulnerabilities.

Root Cause: Many packages are out of date, which can cause vulnerability.

Steps to Replicate: Run Nessus scan.

Platform/Feature: SBC

Packages and kernels are updated to fix this issue.
59SBX-940622

Unexpected INFO was received.

Impact: DTMF inter-working from RFC 2833 to SIP INFO was not generating signal event packets and only signal-update are coming on the SWe.

Root Cause: On the SWe, due to endian mismatch from low level platforms to SIP applications, the signal event was not raised.

Steps to Replicate: Enable the DTMF inter-working and send the 2833 media from one-leg, observe the SIP signal, signal-update events on the other leg.

Platform/Feature: SBC

The code is modified so that the signal event is generated correctly.
60SBX-90831 / SBX-898602

Portfix SBX-89860: There is no bit-exactness across warp for Mode 8. (Originated in release 8.1.0).

Impact: In the case of GPU AMRWB 23.85kbps, there is no bit-exactness in the output across warps even though the same input is fed to all the warps.

Root Cause: The size of one of the scratch buffers was incorrectly used in a macro. The macro eventually led to memory corruption.

Steps to Replicate: The issue was found in the standalone test and cannot be executed outside development.

Platform/Feature: SBC

The code is modified by rectifying the size in the macro.
61SBX-90816 / SBX-903122

Portfix SBX-90312: ASAN: Heap-buffer-overflow on the address in SipFeGetCseqType. (Originated in release 8.1.0).

Impact: This issue was found during ASAN regression testing. While processing the CSEQ header, the code was reading off the end of allocated memory block.

Root Cause: The code was expecting the CSEQ string to be null terminated and it was not.

Steps to Replicate: This issue is only seen with the engineering ASAN build.

Platform/Feature: SBC

The code is updated to correctly handle the case where the CSEQ is not null terminated.
62SBX-939033

Large SIP messages in TRC are divided into several syslog messages to the rsyslog server.

Impact: TRC PDU's are broken into multiple syslog messages.

Root Cause: There was a limit to the message size of ~1.8K and TRC messages beyond that would be split into multiple syslog messages.

Steps to Replicate:

  1. Reproduce the issue.
  2. Generate TRC files (size>1800) and transfer to remote syslog server.
  3. Single TRC is broken into multiple syslog messages.

Platform/Feature: SBC

The code is modified to transfer a complete TRC PDU as one syslog message.
63SBX-935482

When the transfer call is not answered from PSTN, MS TEAMS client is unable to resume the existing call.

Impact: In a Microsoft Teams call flow where the call gets transferred and the C-party has sent back a 180 without the SDP, which triggers the SBC to play RBT and then C-party sends 183 with SDP and finally rejects with a 6xx, it can result in the SBC internally getting into a bad state. This results in the SBC not being able to resume the call and the call getting released.

Root Cause: The resource management in the SBC was getting confused on the packet service profile for the various call legs that lead to the call being released.

Steps to Replicate:

1.TEAMS to PSTN1 call.
2.TEAMS transfer call to PSTN2.
3.PSTN2 does not answer the call.
4.TEAMS resume the call and transfer again to PSTN2.

Platform/Feature: SBC

The code is modified to correctly manage the packet service profile and other call leg information so it can correctly handle the transfer rejection from C-party.
64SBX-939932

The Quality of Announcement tone played by the SBC is bad.

Impact: Bad Announcement quality.

Root Cause: A software bug in DSP was resetting the first sample of every announcement frame to zero.

Steps to Replicate:

1. The set-up requires the SBC and the PSX. A PSX script is implemented, which has information about what announcement to play and DTMF digits that need to be entered to switch to the second stage of the call.
2. Client makes a call to the SBC. In the first dip, the SBC plays the announcement configured in the script and waits for DTMF digits to be entered.
3. A route is present in the PSX for DTMF digits entered.
4. After entering digits, the PSX now goes for second dip for the new digits entered and returns a route to the SBC.
5. With this route, the SBC calls Egress end point
6. Monitor the announcement quality played at step #2.

Platform/Feature: SBC

The code is modified to not remove the first sample.
65SBX-907522

The ASAN creates a global-buffer-overflow on the address in s_finish.

Impact: This issue was found during ASAN regression testing.

The coding was reading from invalid memory block during the process of a CDB transaction completion event.

Root Cause: The code was looking for CDB worker socket that matched with the CDB transaction completion event and in a case where the worker socket did not exist,the code was reading off the end of an array.

Steps to Replicate: Run the SVT test suite using a ASAN specific build.

Platform/Feature: SBC

The code is modified to ensure it does not read off the end of the worker socket array to prevent the problem.
66SBX-922832

Transport the attribute populated twice in the RURI of INVITE request towards the peer, when the To header transparency is enabled.

Impact: A call directed to the registered endpoint has duplicated the URI parameters in the RURI.

Root Cause: Introduced in a previous release.

Steps to Replicate: Configure the TO header transparency. Endpoint registered with contact has multiple RUI parameters. Server makes a call to the endpoint. The SBC sends out an Invite with a duplicated URI parameters.

Platform/Feature: SBC

The code is modified to avoid duplicated RUL parameters in the RURI.
67SBX-932622

The SBC generates a RTCP goodbye to ingress after the 200 OK.

Impact: When 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: Root cause lies in feature completed in a previous release. The feature required that if the ingress peer does not have 100 rel support, and egress gets multiple 18xs, then the transcode is forced even though pass through is possible to support codec change.

Steps to Replicate: Enable Downstream Forking and forking response as anything except the first prov response.

PSPs are setup to perform a transcode only.

Platform/Feature: SBC

The code is modified according to the following:
1. Downstream forking is enabled.
2. Early media behavior - non FIRST PROV RESP.
3. One forking dialogue.
4. No SDP is sent in 2xx if the 18x reliable.

68SBX-931032

There is no relay of an UPDATE with the SDP when the media mode has changed and when the DRBT is configured.

Impact: When the Downstream Forking and DLRBT is enabled, an UPDATE received from the ingress are not going out to egress (UPDATE received after the media cut-thru has happened because of receipt of RTP from egress).

Root Cause: 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 legs not being marked as OA_COMPLETE due to an incomplete implementation.

Steps to Replicate: Set Downstream Forking and DLRBT as enabled.

Platform/Feature: SBC

The code is modified to mark OA_COMPLETE in all instances where the parallelRingPsp is being appended with the new SDP's received in 18x's.
69SBX-923422

Call diagnostics were not working through EMA.

Impact: Call diagnostics fails due to errors in EMA.

Root Cause: Call diagnostics fails due to the STDERR for CP commands in dumpCommonFunction.

Steps to Replicate:

  1. Open EMA-> Troubleshooting and run call diagnostics.
  2. Save the call diagnostics.
  3. Call diagnostics are saved successfully.

Platform/Feature: SBC

The code is modified by redirecting stderr to /dev/null.
70SBX-91196 / SBX-859382

Portfix SBX-85938: The SMM tears down the Operation on Early dialog, and the SBC sends CANCEL before completing the 18x transaction. (Originated in release 8.1.0)

Impact: The SMM tears down the Operation on Early dialog, and the SBC sends CANCEL before completing the 18x transaction.

Root Cause: In case of End2End, PRACK is enabled and SMMTearDownFunctionality was not working as expected.

Steps to Replicate:

1.Tested the call by triggering an SMM teardown functionality in Invite, the SBC tear downs the call as per the call flow.
2. Tested the call by triggering an SMM teardown in 180 response where PRACK is mandatory, the SBC tear downs the call by initiating a SMM Teardown as per the call flow (after PRACK-200ok is complete).
3.Tested the call by triggering a SMM Teardown in 200 OK of PRACK.
4.Tested the call by triggering a SMM Teardown in 200 OK of Invite.

Platform/Feature: SBC

The code is modified to make the SMM Teardown functionality to initiate and not to take any action if the 18x/PRACK transaction is pending and enedtoendprack is enabled. Once the response of PRACK is received/sent based on the call flow, the teardown is initiated based on the SMMTearDown action state.
71SBX-927782

The Edit route action taking a long time to complete.

Impact: The Edit Route action was taking long time and failing.

Root Cause: Use of special characters, such as # in destination National field, can cause the failure of the Edit route action.

Steps to Replicate:

  1. Create Route with special character in Destination National.
  2. Select the Route that is created in Special Character.
  3. Edit Form must be load.

Platform/Feature: SBC

A few more special characters to support Destination National field in the Edit route are allowed.
72SBX-93959 / SBX-933662

Portfix SBX-93366: The SBC is not able to update a transcode from a pass thru call.

Impact: The SBC is not able to update a transcodec call after a pass thru call.

Root Cause: In this issue, it is changing from the pass thru to transcode because the sendOnlyPreferredCodec was enabled in the IPSP and in ModifyReq(Ans Side new PSP), it is taking RxPT of old PSP.

Steps to Replicate: Tested the call by sending PCMU/G729/PCMA in the 183 call is working as expected.

Platform/Feature: SBC

In the NrmaSelectCodecEntryFromPspForXcode() function, adding a condition to overwrite the PT only if it is a valid RxPT(old psp).
73SBX-941183

EMA CLI script import stays "In Progress" if the script contains a special character.

Impact: EMA CLI script import stays "In Progress" if the script contains a special character.

Root Cause: Non printable characters are present in the error message.

Steps to Replicate:

  1. Log into EMA Application.
  2. Click on Administration->System Administration->File upload->Add the files to queue.
  3. Select the CLI file that you want import.
  4. Click on "Upload All files".

Platform/Feature: SBC

Remove Non printable characters from the error message.
74SBX-940892

SAM crash on standby SBC (SIPFE stby).

Impact: The standby SBC may core when IpPeer deletes or creates the same structure in a different zone.

Root Cause: When using the IpPeer delete, the function will fail to remove the internal data structure from the hashtable. Later on, the IpPeer will create a new structure again in a different zone, it fails to insert a new data structure into the hashtable and deletes the new data structure.

There was a logical error that still has access to the new data structure after free.

Steps to Replicate: Create an IpPeer from one zone. Delete it and create the same IpPeer in a different zone.

Platform/Feature: SBC

The code is modified to fix the initial IpPeer delete issue and ensure not the new data structure is not accessed if it is already freed.
75SBX-94667 / SBX-945802

Portfix SBX-94580: The GWSG is missing a svcGrp entry for the TG while a few duplicate entries in the srvcGrpTbl. (Originated in release 6.2.2).

Impact: Duplicate entries shown in the GWSG service group table.

Root Cause: The root problem is that the create GWSG does not validate the TG name. Currently, the GWSG only goes through the srvcGrpTbl[] and finds the first empty slot’s index. If the new index != original entry’s index, the NamedInsert() will insert SUCCESS and set duplicate entry at the new location in the table, otherwise the NamedInsert() will return FAILURE and the duplicated entry will be freed.

On the standby node, when it is coming up, the GWSG restores all GWSG_SRVC_GRP_STR from the CDB. Once configuration restore is done, the active node will start to sync over all the GWSG_SRVC_GRP_STR, which caused the standby node to have duplicate entries.

Steps to Replicate: Refer to /sonus/sw/Specs/TSBX-94580.txt.

Platform/Feature: SBC: GW-GW

The code is modified to validate if the specified name is already in the table before creating a new one.
76SBX-93562 / SBX-933552

Portfix SBX-93355: P-Charge-Info header was not relayed by the SBC in a out-of-dialog MESSAGE request, even though the transparency setting is enabled.

Impact: The P-Charge-Info Header is not relayed transparently for the OOD Message, even though the Transparency profile is enabled for P-Charge-Info.

Root Cause: The P-Charge-Info Header is dropped, in case of the relay framework.

Steps to Replicate: Run the message OOD that has the 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 a relay framework.
77SBX-943203

The SBC application is resulting in a failure after switchover.

Impact: The SBC results in a failure due to being unable to mount the DRBD post switchover.

Root Cause: Post switchover, the DRBD mount failed as one of the DRBD setup command was being run in the background, but this command needs to complete execution before mounting the DRBD.

Steps to Replicate: Bring up the SBC and perform a switchover. Verify that the switchover is successful and the SBC application comes up fine on both nodes.

Platform/Feature: SBC

The code is modified to run the DRBD command in foreground and then mount the DRBD.

78SBX-94552 / SBX-766693

Portfix SBX-76669: With the sipOod set to unlimited, MAJOR errors are displayed in DBG log.

Impact: With the sipOod set to unlimited, MAJOR errors are displayed in DBG log.

Root Cause: If the sipOod licensedMaxRateLimit is set to UNLIMITED, it was generating a TRAP and MAJOR level logging that is incorrect. 

Steps to Replicate:

Make a OOD call and no MAJOR logs be visible, as presented in the example below:

152 12242018 083916.769675:1.01.00.00493.MAJOR .SIPFE: threshold reached notification for OOD message Rate. Active OOD rate 1 and OOD Rate Limit is 0
152 12242018 083916.769675:1.01.00.00493.MAJOR .SIPFE: threshold reached notification for OOD message Rate. Active OOD rate 1 and OOD Rate Limit is 0

Platform/Feature: SBC: Application, FM/Traps and Alarms

Instead of assigning a value 0 to the variable, the value is assigned to a INTMAX.
79SBX-871192

The SAM Process may core.

Impact: The SAM Process cored due to a deadlock occurring in the SIPCM.

Root Cause: In one thread, the SSL_CTX_add_session() was trying to do cache cleanup and in another thread the SipCmOpenSSLSSessinCacheCleanup() was trying to do cache cleanup at the same time. If the cache entries exceed 20480, then the SSL_CTX_add_session() will start clearing old cache entries. At the same time, the SipCmOpenSSLSSessinCacheCleanup() is also removing entries from entries from cache. This resulted in deadlock.

Steps to Replicate: The steps cannot be replicated.

Platform/Feature: SBC

The code is modified to invoke SipCmOpenSSLSSessinCacheCleanup() only in standby mode.
80SBX-94146 / SBX-930923

Portfix SBX-93092: The npLogRotate (np log rotation) must occur on the basis of a log file size.

Impact: A New SWe_NP log used to be created everyday and used to get rotated after 10 log files. The rotation allowed very limited timeframe for SWe_NP debug log capturing.

Root Cause: The setting in npLogRotate was causing the issue.

Steps to Replicate: Analyse the SWe_NP debug logs.

Platform/Feature: SBC

Create a new SWe_NP log file when a previous file has exceeded certain size (i.e 50M) and not on a daily basis.
81SBX-91727 / SBX-914252

Portfix SBX-91425: Low MOS score on the ingress leg when both legs are recorded with LI.

Impact: Random packets losses are observed, when the called and calling number are set as LI during transcoded calls.

Root Cause: An uninitialized field of structure that is used to hold the incoming packet from DSP in SWe_NP was causing this behavior of a random packet drop.

Steps to Replicate:

  1. Setup was called and calling number as LI.
  2. Run the transcoded call.

Platform/Feature: SBC

Initialize the field correctly.
82SBX-942552

Updated the kernel configuration file that was not installed after the LSWU.

Impact: After the LSWU, the kernel configuration and grub menu is not updated properly as mentioned in the description.

Root Cause: Missing the kernel configuration and an invalid grub menu.

Steps to Replicate: Perform the LSWU and verify the grub menu and kernel configuration file in /boot.

Platform/Feature: SBC

Updated the grub menu and copied the kernel configuration after the LSWU.
83SBX-92346 / SBX-907222

Portfix SBX-90722: There was an inconsistency in generating the sonusSbxTrunkGroupOutOfResourcesNotification2 trap.

Impact: There was an inconsistency in the sonusSbxTrunkGroupOutOfResourcesNotification2 trap generation using the MTRG CAC.

Root Cause: Once the CAC resource usage reaches 100%, the SBC internally marks the congested flag and generates sonusSbxTrunkGroupOutOfResourcesNotification2 trap. During a call release, if the available/free CAC resource reaches above 15%, the SBC must disable the congestion flag. However, the SBC failed to disable/reset internal the congestion flag once the free resource reaches above 15% due to the failed generated trap. (This issue occurs only when the TG's cac callLimit is set to unlimited).

Steps to Replicate:

Procedure:
1. Run 10 calls.
2. Disconnect 2 calls.
3. Run another 2 calls.
4. Disconnect 2 calls.
5. Run another 2 calls.

Expected Result:
1. Trap must be generated when receiving the 10th call.
2. A disconnected call must be successful.
3. When receiving the 2nd call, trap must be generated.
4. Call disconnect must be successful.
5. When receiving the 2nd call, trap must be generated.

Platform/Feature: SBC

The code is modified to reset internal congestion flag when the CAC free resource reaches above 15%.
84SBX-922433

Upgrade failed from 7.1R0 to 8.1R0.

Impact: An upgrade failed between 7.1R0 to 8.1R0.

Root Cause: A mandatory node /eventLog{memusage}/servers{server1} is not created with an upgrade code.

Steps to Replicate: The steps cannot be replicated.

Platform/Feature: SBC

The code is modified to create a /eventLog{memusage}/servers{server1}.
85SBX-91729 / SBX-914672

Portfix SBX-91467: The SBC fails to populate statistics in the callCurrentStatistics under zone for the trunkgroup towards MRF. (Originated in release 8.1.0)

Impact: The SBC fails to populate statistics in the callCurrentStatistics under zone for the trunkgroup towards MRF.

Root Cause: There was code missing to populate statistics in the callCurrentStatistics under zone for the trunkgroup towards MRF

Steps to Replicate:

1) UAC sends an Invite with the PCMU.
2) UAS sends 180 Ringing without the SDP.
3) UAS sends 200 OK with the PCMA.
4) SBC sends an Invite with the m1=PCMU m2=PCMA towards the MRF.
5) MRF responds with 200 OK with m1=PCMU and m2=PCMA.
6) A PCMU-PCMA transcoded call is established.
7) Check the trunkgroupStatus for the TG towards MRF.
8) Check the callCurrentStatistics for the TG towards MRF.

Platform/Feature: SBC

The code is modified to increment the callCurrentStatistics on the MRF legs.
86SBX-92473 / SBX-915082

Portfix SBX-91508: The ASAN frees SipSgClearOtherForkedCalls. (Originated in release 8.1.0)

Impact: As part of the Call Forking testing, the SBC sends multiple requests as part of forking. When one of the forked leg answers the call, the SBC tries to clear the other forked calls. While clearing/releasing the call, some of the elements in the CCB forked structure are accessed/set even after the structure is freed.

Root Cause: This issue was reported as a part of the ASAN Testing on Call Forking regression suite in the SBC lab.

Steps to Replicate: This issue was reported as part of Call Forking feature with regression testing.

Platform/Feature: SBC

The code is modified to release the CCB forked structure at the end (after all the elements in the structure are accessed/set with the correct values).
87SBX-918932

The NOA fields for the redirecting number and the original called number are not supported in the SBC.

Impact: The NOA fields for redirecting number and original called number are not supported in X2 interception in the Service Instance messages and the Signaling Start messages.

Root Cause:

The following message types were never supported for NOA on the SBC:

Service Instance messages:
Calling Party Number
Called Party Number
Redirected From Party Number
Redirected To Party Number

Signaling Start messages:
Calling Party Number
Called Party Number
Last Redirecting Party
Original Called Party

Steps to Replicate: The steps cannot be reproduced.

Platform/Feature: SBC

A new CLI is added to support this feature.

set addressContext default intercept callDataChannel <cdc_name> 
noaParamSupport enabled/disabled


88SBX-93767 / SBX-934903

Portfix SBX-93490: The SBC duplicates the supported header in the outgoing OPTIONS.

Impact: The SBC duplicates the supported header in the outgoing OPTIONS.

Example:
Supported: timer,100rel,199,precondition,replaces,gruu
Supported: timer,100rel,199,precondition,replaces,gruu

Root Cause: When the gruu parameter was present, there was a logical issue in software that adds one additional Supported Header.

Steps to Replicate: For the Registered Endpoint, an OPTIONS message coming with supported Header having gruu parameter will cause this issue.

Platform/Feature: SBC

The code is modified so a duplicate entry is created for the supported Header.
89SBX-93687 / SBX-935722

Portfix SBX-93572: There was a LeakSanitizer in the NrmaSessDescClone.

Impact: There was a memory Leak while running the NrmaSessDescClone. Fax transmissions cannot be performed with T.38 relay mode, when the trunk group is configured as T.38FallbackToG711 and uses voice codec in the G.711-REGR.

Root Cause: As part of Additional offer creation, memory is getting added for session attributes and is not getting freed.

Steps to Replicate: Fax transmissions cannot be performed with T.38 relay mode, when the trunk group is configured as T.38FallbackToG711 and use a voice codec in the G.711-REGR.

Platform/Feature: SBC

Allocated memory is freed.
90SBX-93536 / SBX-934112

Portfix SBX-93411: The ASAN global-buffer-overflow on the address in __interceptor_vsnprintf.

Impact: This is an ASAN issue regarding the buffer overflow.

Root Cause: Boundary conditions are missing, leading to a buffer overflow.

Steps to Replicate: The steps cannot be reproduced.

Platform/Feature: SBC

The code is modified to add additional boundary conditions.
91SBX-92794 / SBX-922682

Portfix SBX-92268: The SBC fails to tear down a call towards the UAS until the 200 OK Invite timeout occurs when the MRF responds with a 3xx message.

Impact: The SBC fails to tear down a call towards the UAS until the 200 OK Invite timeout occurs when the MRF responds with a 3xx message.

Root Cause: The handling missing when the SBC receives a 3xx from the MRF server.

Steps to Replicate:

1) SBC must tear down a call towards the UAS upon receiving a 3xx from the MRF.

2) SBC must not wait for a 200 OK Invite timeout.

Platform/Feature: SBC

Disconnect the call immediately when the SBC receives a 3xx message from the MRF server.
92SBX-92336 / SBX-914462

Portfix SBX-91446: Observing a MAJOR logs flood related to SipSgRedundDeleteMrfCbData during the SSBC SWO. (Originated in release 8.1.0)

Impact: Changing to INFO from MAJOR.

Root Cause: Logs listed as INFO were kept as MAJOR.

Steps to Replicate:

  1. Initiate 1000 cps of load with 60 CHT.
  2. Once the calls are stable, initiate the SSBC SWO.

Platform/Feature: SBC

The code is modified to change unwanted MAJOR logs as INFO.
93SBX-91172 / SBX-908442

Portfix SBX-90844: The SBC must not add the 100 rel for the 180 Ringing without the SDP. (Originated in release 8.1.0)

Impact: The SBC must not add Require:100 rel for 180 Ringing when the other leg does not receive the provided E2E PRACK and the Dialog-Transparency are enabled.

Root Cause: The design was changed in between to handle 18x and PRACK leg specific.

Steps to Replicate:

  1. Enable the dialogTransparency on both egress and ingress leg.
  2. Enable the transcoderFreeTransparency flag on PSP.
  3. Enable the 'downstreamForkingSupport' flag on the egress leg.
  4. Keep the value of 'forkingBehavior' as 'lastProvResponse' in early media on Egress leg.
  5. Enable the preconditions flag on both TG. 6) Enable sdpAttributesSelectiveRelay on both TG.

Replication procedure -

  1. From the UAC, send an initial INVITE with Require header Require: 100rel
  2. From the UAS, send forked 18x with dialog d1.
  3. From the UAS, send 2nd forked 18x with dialog d2 and UPDATE from UAC for dialog d1 at the same time.
  4. Send the 3rd dialog 18x from UAS and 2nd dialog update from UAC at the same time.
  5. Send a 180 Ringing from UAS without sdp for dialog D1.

Platform/Feature: SBC

The code is modified so that the SBTM needs to relay behaviour for non-reliable 18x when the E2E PRACK and Dialog-Transparency are enabled.
94SBX-92881 / SBX-876072

Portfix SBX-87607: The SBC is unable to tear down the leg towards the MRF when the Malformed packet in a 200 OK is received with a 1 m line in the SDP from the MRF.

Impact: The SBC is unable to tear down the leg towards the MRF when the Malformed packet in a 200 OK is received with a 1 m line in the SDP from the MRF.

Root Cause: The handling is missing when the Malformed packet in a 200 OK is received with a 1 m line in the SDP from the MRF.

Steps to Replicate:

  1. USER A sends an INVITE with AMR.
  2. The SBC sends an INVITE to USER B.
  3. USER B responds with a 200 OK with EVRC codec in the SDP.
  4. The SBC sends an INVITE towards an MRF.
  5. MRF responds with a 200 OK with a 1 m line in the SDP.
  6. The SBC sends a BYE towards USER B and a 488 towards USER A.
  7. The SBC tear down the legs towards USER A and USER B, but unable to tear down the leg towards MRF.

Platform/Feature: SBC

Tear down the call when the Malformed packet in a 200 OK is received with the 1 m line in a SDP from the MRF.
95SBX-919873

Multiple 'CONFD_NOTIF_USER_SESSION' logs were in the app.latest.

Impact: Notification messages are printed in the logs.

Root Cause: Session logs are logged as MAJOR.

Steps to Replicate:

  1. Set the logs to Major.
  2. Log into the CLI.
  3. Check the logs and ensure session logs are not printed.

Platform/Feature: SBC

The code is modified to change session logs to DEBUG logs.

Known Issues

Known Issues in 07.02.04R002

There are no known issues in this release.

Known Issues in 07.02.04R001

There are no known issues in this release.

Known Issues in 07.02.04R000 

The following issues exist in this release:


Known Issues

Issue IDSevProblem DescriptionImpact/Workaround
SBX-993102

Support of Identity headers with multiple values.

Platform/Feature: SBC

Impact: The SBC supports standalone multiple Identity headers but does not support single Identity headers with multiple values, each comma separated. 

Workaround: Use the SMM to separate out the comma separated list into individual standalone Identity headers.

SBX-94948

2

On attaching dnsGroup to zone, the SBC failed to link dnsGroup Id with all the TGs of the corresponding zone.

Platform/Feature: SBC

Impact: The SBC uses an incorrect DNS group to resolve the FQDN associated with diameter peer.

Workaround:

  1. After setting the dnsGroup configuration, perform a manual switchover (so during an application restart and all configuration restored properly).
  2. The dnsGroup has to be attached to zone before creating TGs under this zone. When a new TG is created under the zone, it will read as a configured dnsGroup id.

Known Issues in 07.02.02R000 and 07.02.03R000

There are no known issues in this release. 

Known Issues in 07.02.01R002 

The following issue exists in this release:


Known Issues

Issue IDSevProblem DescriptionImpact/Workaround
SBX-877402

LI call not working when standby MSBC is upgraded.

Platform/Feature: SBC

Impact: Interception of LI calls fail during upgrade (for instance, when the setup has S-SBC and the M-SBC running on different versions). The impact is only for in-service upgrade. No impact with respect to LI calls, when the VNF is brought down and re-created for upgrade..

Workaround: No workaround available.

Known Issues in 07.02.01R001 Release 

The following issue exists in this release:


Known Issues

Issue IDSevProblem DescriptionImpact/Workaround
SBX-880031

 If there are any PRACK drops and call fails, a memory leak occurs.

Platform/Feature: SBC

Impact: In the rare case where a PRACK for 18x is dropped and the call eventually fails, a small leak of SCM memory can occur.

Workaround: No workaround available.

Known Issues in 07.02.01R000 Release 

The following issues exist in this release:


Known Issues

Issue IDSevProblem DescriptionImpact/Workaround
SBX-85825 2

When a headend cluster configuration is pushed, the Standby SBC reboots and hangs without getting the Configuration.

When a Standby SBC is rebooted, it transitions to registered online then later unregistered offline. This also happens in #1, Standby reboot after Configuration is pushed.

Platform/Feature: SBC Core: EMA

Impact: When a headend cluster configuration is pushed, Standby SBC fails to download the configuration and so fails to come up properly.

Workaround: To resolve the above issue, the fill rate and bucket size needs to be increased in lca.py script and the Standby SBC system needs to be rebooted so that it can download the configuration again.

SBX-863542

CallMedia and CallDetailstatus do not show in the EMA during the load run.

Platform/Feature: SBC Core: EMA

Impact: Call details Status and Call Media Status are intermittently not visible in the EMA.

Workaround: Call details status and Call Media status can be viewed from CLI.

SBX-852282

Observed M-SBC reboot and PrsProcess crash during 30000 NP based tones playing.

Platform/Feature: SBC Cloud

Impact: Under load with 30,000 simultaneous NP tones playing M-SBC switches over. M-SBC system confirmed to perform fine up to 28,000 simultaneous NP tones.

Workaround: No workaround available.

Known Issues in 07.02.00R002 Release 

The following Severity 1 issues exist in this release:


Known Issues

Issue IDSevProblem DescriptionImpact/Workaround

SBX-86003

1

While UPDATE is pending and a subsequent 18x is received on Egress, the SBC includes SDP in the subsequent 18x on Ingress.

Platform/Feature: SBC Core: SIP Application

Impact: The peer may reject the call.

Workaround: No workaround available.

The following Severity 2/3 issues exist in this release:


Known Issues

Issue IDSevProblem DescriptionImpact/Workaround
SBX-850713

The SBC did not like the <4K size INVITE PDU since the maxPduSizeValue = 6K.

Platform/Feature: SBC

Impact: A PDU of a size less than 6K is rejected with 400 Bad Request, when maxPduSizeValue is set to 6K.

Workaround: Increase the maxPduSizeValue to 15k.

SBX-770542

An LSWU Upgrade from 7.0 to 7.1 failed.

Platform/Feature: SBC 5000/7000 Series: Application

Impact: While upgrading from pre-7.1 releases to 7.1 and 7.2 releases, if the SNMP trap targets are setup with <space> in the name field then the upgrade fails. This affects all the platforms (SBC 5xxx/7xxx/SWe).

Workaround: Prior to the upgrade, the user must check and delete/replace any trap targets that are setup with <space> in the name.

SBX-860942

Call fail after onhold and offhold.

Platform/Feature: SBC Core: SIP Application


Impact: A call onhold/offhold before being connected by Update may fail.

Workaround: Enable E2E Update.


SBX-858592

A race condition occurs under a 3x load scenario where MRF is configured as FQDN and none of the MRF server responds.

Platform/Feature: SBC: DSBC

Impact: The SCM process may core dump.

Workaround: No workaround available.



Known Issues in 07.02.00R001 Release 

The following issues exist in this release:


Known Issues

Issue IDSevProblem DescriptionImpact/Workaround
SBX-760662

The SBC is discarding media packets when the SBC is monitoring and media packets are received from IPV6 terminated peer.

Platform/Feature: SBC CE: Application

Impact:

The RTP monitoring feature will not work for IPv6 terminated peers, and therefore the following behavior will be observed.

  1. If The SBC is in tone playing state and expecting media cut through after successful monitoring, the SBC will continue the tone play even though the expected RTP packet count is received, which is discarded by the SBC because of this issue.
  2. If the SBC does not have conditions for delayed tone play, is not in tone playing state and is expecting media cut through after successful monitoring, the SBC will discard media packets because of this issue.
  3. If the SBC has conditions for delayed tone play, is not in tone playing state, and is expecting media cut through after successful monitoring, the SBC will discard media packets because of this issue and therefore the delayed tone play starts because of the monitoring failure.

Workaround: no workaround for IPv6, but the same feature works for IPv4.

SBX-850713

The SBC did not like the <4K size INVITE PDU since the maxPduSizeValue = 6K.

Platform/Feature: SBC

Impact: A PDU of a size less than 6K is rejected with 400 Bad Request, when maxPduSizeValue is set to 6K.

Workaround: Increase the maxPduSizeValue to 15k.

SBX-770542

An LSWU Upgrade from 7.0 to 7.1 failed.

Platform/Feature: SBC 5000/7000 Series: Application

Impact: While upgrading from pre-7.1 releases to 7.1 and 7.2 releases, if the SNMP trap targets are setup with <space> in the name field then the upgrade fails. This affects all the platforms (SBC 5xxx/7xxx/SWe).

Workaround: Prior to the upgrade, the user must check and delete/replace any trap targets that are setup with <space> in the name.


Known Issues in 07.02.00R000 Release

The following Severity 1 issues exist in this release:


Known Issues

Issue ID

Sev

Problem Description

Impact/Workaround

SBX-74179


1

Cannot ping the G/W from the V6 interface alternatively when Alt_IP's are configured in X710 NIC card server.

Platform/Feature: SBC CE: Application, Platform

Impact: IPv6 with X710 NIC cards in SRIOV mode will not work as multicast packets will be dropped by the PF.

Workaround:

Set the trust mode to "on" for all the VFs on the computes.

ip link set dev <PF name> VF <vf id> trust on

This needs to be done for all computes and all created VFs (this change is not persistent across reboots). This will allow Multicast promiscous mode to work.

Otherwise, add a static neighbor table entry on the remote servers connecting to the SBC using the following command:

ip -6 neigh add <IPv6 address> lladdr <link-layer address> dev <device>

SBX-73218


 1

The S-SBC is unable to register 1M endpoints with 1000 RPS and is having a 180 second refresh Register with RHEL 7.5, RHOSP 13 (Queens) setup.

Platform/Feature: SBC CE: Application

Impact: Virtual ports intermittently stop responding on compute node running on RHOSP 13 (Queens) under certain conditions. Specifically, at 1000 RPS with refresh registration interval at 180 seconds, virtual ports stop responding after reaching 500K registrations. This issue is not seen when the refresh registration interval is configured as 200 seconds and above

Workaround: Use SR-IOV ports only when using RHOSP 13 (Queens) release.

The following Severity 2, 3, and 4 issues exist in this release:


Known Issues

Issue ID

Sev

Problem Description

Impact/Workaround

SBX-73943


2

The SBC does not add all codecs when Update is received with updated SDP from egress and sends 200 OK for Update with all supported codecs towards egress, the SBC is playing tone.

Platform/Feature: SBC Core: Application

Impact: The call signaling and media work properly, but media clipping can occur if the final cut-thru codec received from UAS is different from the codec that is being used for playing tone. 

Workaround: No workaround available.

SBX-74945

 4

Unable to commit pkt and sip-sig config with single commit command. An error message is thrown when the commit command is given.

Platform/Feature: SBC Core: CLI

Impact: Commit cannot be issued in for all set commands until the ipInterfacegroup is committed.

Workaround: Commit should be issued for ipInterfacegroup first and then commit for the remaining set commands can be executed.

SBX-73660


 2

Unable to view TRAPS under Fault Management in Cloud-ISBC (Openstack Nova Platform) in EMS.

Platform/Feature: SBC CE: Application, EMA/EMS

Impact: EMS will not be able to identify the trap since the source IP address is packet interface.

Workaround: Add a static route to EMS from the SBC through management interface.

SBX-725132

Memory congestion was observed when executing around 64K calls in the 32GB SWe system.

Platform/Feature: SBC SWe: SIP-Peering

ImpactOn a SWe system with 32GB 32vCPU, the SBC is only able to scale up to 60K calls instead of 64K, due to per call memory increase.

Workaround: No workaround available.

SBX-713032

Observing 503 response for more time post port SWO in S-SBC.

Platform/Feature: SBC CE: Application

Impact: The load is 1000cps/120K calls. After doing port SWO on S-SBC, SBX rejects calls with a 503 response for 86 seconds. Later SBX again responds with 503 responses for approx 36 seconds. After that, it stabilizes.

Workaround: No workaround available.

SBX-727362

The SBC is not able to handle 150 Sa/Sec IPsec load on the Yellowfin Platform.

Platform/Feature: SBC 5000/7000 Series: SIP

Impact: If the rate for IPsec SA setup using IKE is increased beyond 60 SA/s, errors are seen.

Workaround: No workaround available.

SBX-72652


2

The PSBC observing system is in continuous iRTT congestion during the overload test.

Platform/Feature: SBC CE: Application

Impact: IRTT congestion is observed continuously for the 15 mins duration of 3x overload. There is no congestion during normal 1x load. This is 1000cps/120K in DSBC (PSBC).

Workaround: No workaround available.

SBX-745462

The SBC failed to generate Enum lookup after updating the dynamic metaVariable.

Platform/Feature: SBC CE: Application

Impact: Enum lookup fails to generate if the meta variable related to sipSigPort (used for the Enum lookup) is dynamically updated.

Example:

Before updating sipSigPort with new dynamic metaVariable:

admin@vsbc1% show global servers lwresdProfile

lwresdProfile DEFAULT {

    description          DEFAULT;

    enumDomainNameLabel  DEFAULT_ZONE_LABEL;

    enableLwresdLog      disable;

    type                 signalingIp;

    addressContext       default;

    eDnsGlobalBufferSize 4096;

    eDnsMonitorInterval  120;

    zone                 ZONE_ING_V6;

    sipSigPort           3;

    ipInterfaceGroupName LIG_ING_V6;

}

admin@vsbc1% show addressContext default zone ZONE_ING_V6 sipSigPort

sipSigPort 3 {

    ipInterfaceGroupName      LIG_ING_V6;

    portNumber                5060;

    mode                      inService;

    state                     enabled;

    transportProtocolsAllowed sip-udp,sip-tcp;

    ipVarV6                   IF2.IPV6;

}

[root@VSBCSYSTEM-vsbc1 linuxadmin]# lsof -ni:5060

COMMAND     PID       USER   FD   TYPE  DEVICE SIZE/OFF NODE NAME

CE_2N_Com 32059 sonusadmin  110u  IPv6 3716854      0t0  UDP [fd00:10:6b50:5d20::c9]:sip

CE_2N_Com 32059 sonusadmin  111u  IPv6 3716855      0t0  TCP [fd00:10:6b50:5d20::c9]:sip (LISTEN)

CE_2N_Com 32059 sonusadmin  112u  IPv6 3716856      0t0  UDP [fd00:10:6b50:5d20::a9]:sip

CE_2N_Com 32059 sonusadmin  113u  IPv6 3716857      0t0  TCP [fd00:10:6b50:5d20::a9]:sip (LISTEN) 

ENUM query is successful from sipSigport (fd00:10:6b50:5d20::a9)

After updating sipSigport to new dynamic metaVariable:

admin@vsbc1> show table system metaVariableDynamic

CE NAME              NAME     VALUE                 

-----------------------------------------------------

vsbc1-10.34.195.109  lpl_egg  fd00:10:6b50:5d20::c9 

vsbc1-10.34.195.109  lpl_ing  fd00:10:6b50:5d20::c7 

admin@vsbc1% show addressContext default zone ZONE_ING_V6 sipSigPort

sipSigPort 3 {

    ipInterfaceGroupName      LIG_ING_V6;

    portNumber                5060;

    mode                      inService;

    state                     enabled;

    transportProtocolsAllowed sip-udp,sip-tcp;

    ipVarV6                   lpl_ing;

}

[root@VSBCSYSTEM-vsbc1 linuxadmin]# lsof -ni:5060

COMMAND     PID       USER   FD   TYPE  DEVICE SIZE/OFF NODE NAME

CE_2N_Com 32059 sonusadmin  110u  IPv6 3716854      0t0  UDP [fd00:10:6b50:5d20::c9]:sip

CE_2N_Com 32059 sonusadmin  111u  IPv6 3716855      0t0  TCP [fd00:10:6b50:5d20::c9]:sip (LISTEN)

CE_2N_Com 32059 sonusadmin  112u  IPv6 3716856      0t0  UDP [fd00:10:6b50:5d20::c7]:sip

CE_2N_Com 32059 sonusadmin  113u  IPv6 3716857      0t0  TCP [fd00:10:6b50:5d20::c7]:sip (LISTEN)

ENUM query is not picking new sipSigport (fd00:10:6b50:5d20::c7) updated with dynamic metaVariable


Workaround: Do not update the metavvariable associated with a sipSigPort if Enum is being used.

Example:

Don't update the sipSigport to new metaVariable

admin@vsbc1% show addressContext default zone ZONE_ING_V6 sipSigPort

sipsigPort 3 {

    ipInterfaceGroupName      LIG_ING_V6;

    portNumber                5060;

    mode                      inService;

    state                     enabled;

    transportProtocolsAllowed sip-udp,sip-tcp

    ipVarV6                   IF2.IPV6;

}

SBX-756092

The SBC VM is failing to join back the cluster post switchover after healing (Recreate_destroy) N:1 MSBC VM.

Platform/Feature: SBC CE: Install/Upgrade(Platform)

 Impact: The Ribbon VNF Manager provides functionality to manually heal a VM within an  orchestrated VNF.  There are a number of options for healing provided, including a Recreate_destroy option.  There is an issue if the Recreate_destroy is executed on a VM that has DHCP enabled on its interfaces.  In this case, the VM is provided new IP addresses, causing that VM to be unable to re-join in the cluster.

Workaround: There is no workaround that is not service impacting.  Do not execute the Recreate_destroy option on a VM that has DHCP enabled.

SBX-742692

The IPv6/v4 Interface update with a new dynamic meta Variable is not deleting the old IP address.

Platform/Feature: SBC CE: Application

Impact: The old IP address is not getting deleted when the ipInterfaceGroup is updated with new dynamic meta variable.

Example:

Before updating ipInterfaceGroup with dynamic metaVariable:

admin@vsbc1> show table system metaVariable | match IF2.IPV6

vsbc1-10.34.195.109  IF2.IPV6      fd00:10:6b50:5d20::a9 

admin@vsbc1% show addressContext default ipInterfaceGroup LIG_ING_V6

ipInterface PKT_ING_V6 {

    ceName      SSBCACTIVE;

    portName    pkt0;

    mode        inService;

    state       enabled;

    ipVarV6     IF2.IPV6;

    prefixVarV6 IF2.PrefixV6;

    vlanTagVar  IF2.VlanId;

}

pkt0.609  Link encap:Ethernet  HWaddr fa:16:3e:ee:70:92 

          inet6 addr: fd00:10:6b50:5d20::a9/60 Scope:Global

          inet6 addr: fe80::f816:3eff:feee:7092/64 Scope:Link

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:8954 errors:0 dropped:0 overruns:0 frame:0

          TX packets:9060 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:0

          RX bytes:780288 (762.0 KiB)  TX bytes:902476 (881.3 KiB)                                                          

Creating dynamic metaVariable:

admin@vsbc1> show table system metaVariableDynamic

CE NAME              NAME  VALUE                 

--------------------------------------------------

vsbc1-10.34.195.109  lpl   fd00:10:6b50:5d20::cf 

vsbc1-10.34.195.110  lpl   fd00:10:6b50:5d20::ff 

[ok][2018-11-13 07:11:41]

After updating ipInterfaceGroup with dynamic metaVariable (lpl) old IP (IF2.IPV6) is not deleted from interface

admin@vsbc1% show addressContext default ipInterfaceGroup LIG_ING_V6

ipInterface PKT_ING_V6 {

    ceName      SSBCACTIVE;

    portName    pkt0;

    mode        inService;

    state       enabled;

    ipVarV6     lpl;

    prefixVarV6 IF2.PrefixV6;

    vlanTagVar  IF2.VlanId;

}

pkt0.609  Link encap:Ethernet  HWaddr fa:16:3e:ee:70:92 

          inet6 addr: fd00:10:6b50:5d20::a9/60 Scope:Global

          inet6 addr: fe80::f816:3eff:feee:7092/64 Scope:Link

          inet6 addr: fd00:10:6b50:5d20::cf/128 Scope:Global

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:9093 errors:0 dropped:0 overruns:0 frame:0

          TX packets:9209 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:0

          RX bytes:792396 (773.8 KiB)  TX bytes:917382 (895.8 KiB)


Workaround: To change an addressContext ipInterfaceGroup to use a different ipVarV6 you must delete the ipInterfaceGroup and recreate it.

Example:

Delete the interface group:

 delete addressContext default ipInterfaceGroup LIG_ING_V6

Create interface group with new dynamic metaVariable:

admin@vsbc1% show addressContext default ipInterfaceGroup LIG_ING_V6

ipInterface PKT_ING_V6 {

    ceName      SSBCACTIVE;

    portName    pkt0;

    mode        inService;

    state       enabled;

    ipVarV6     lpl;

    prefixVarV6 IF2.PrefixV6;

    vlanTagVar  IF2.VlanId;

}

pkt0.609  Link encap:Ethernet  HWaddr fa:16:3e:ee:70:92 

          inet6 addr: fd00:10:6b50:5d20::cf/60 Scope:Global

          inet6 addr: fe80::f816:3eff:feee:7092/64 Scope:Link

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:9093 errors:0 dropped:0 overruns:0 frame:0

          TX packets:9209 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:0

          RX bytes:792396 (773.8 KiB)  TX bytes:917382 (895.8 KiB)

 Note: Similar procedure for IPV4.

SBX-758473

The RTCP port is not transparently passed in Direct Media.

Platform/Feature: SBC Core: Application

Impact: In case of a Direct Media call, the SBC will add an RTCP port in the outgoing INVITE SDP, when RTCP is enabled on Egress PSP and the RTCP port was not received in the incoming INVITE SDP.

Workaround: Disable RTCP flag on Egress PSP.

set profiles media packetServiceProfile PSP_DM_DTLS rtcpOptions rtcp disabled


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 7.2, 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 M-SBCs in an N:1 Redundancy Group for the relevant procedure. 

Restricted Functionality with SBC

The following functionalities are not supported with SBC Microservices:

  1. SRTP
  2. Far end NAT traversal
  3. DTMF inter-working
  4. RTCP termination for pass-through calls
  5. Direct Media and Antitrombone
  6. NICE, SIP-REC
  7. Rx, Rf interfaces
  8. Multimedia - MSRP, BFCP  
  9. Fax detection
  10. ICE/STUN
  11. SIP REFER
  12. SIP REPLACE
  13. Two stage calls

  14. H323 support
  15. GW signaling support
  16. Network Licensing Limitations

After switchover during grace period, when the new standby SBC comes up and establishes itself as standby, there is a short period (a few minutes) when the standby is synchronized for normal operation, but the new standby has not yet completed establishing its licensing state using the grace license information. If there is a second SBC switchover during that window, the new active SBC (which became active before completing license state synchronization) will lose calls until it re-acquires the grace licenses.

For configuring Network Wide Licensing, refer to Configuring Network Wide Licensing on D-SBC. This procedure is common for D-SBC and SBC.

Table of Contents

About SBC Release Notes

This document 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 07.02.xx documentation is located at the following Wiki space: SBC Core 7.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 Bulletins

The following Ribbon Bulletins are referenced in this release note:

  • Warning-14-00020748: Verify system and databases are fully in sync prior to Live Software Upgrade (LSWU)
  • Bulletin-18-00028529: The System Security Intrusion Detection AIDE Reports False Positive Alarms 

  • Warning-19-00028636: SBC SWe Gateway-to-Gateway signaling is disabled in certain SBC SWe versions 
  • Warning-19-00029555: CDR Viewer and Live Monitoring cannot be enabled/disabled

To view/download Ribbon bulletins, do the following:

  1. Log on to the 
    Support Portal link
  2. Click Announcements link from the menu bar. 
  3. Enter the bulletin number (last eight numbers) in the search field and press Return.
Note

The WBA section may not include all Warnings, Bulletins and Alerts associated with this release. Before attempting to upgrade to any release, it is recommended to check the Customer Portal in Salesforce for any newly published WBAs that may include this release in the "affected versions" section.

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
  • NetScore collection, analysis, monitoring, and reporting of selected Key Performance Indicators (KPIs) on a near-real time basis

Note

NetScore maintains a list of remote host keys for all nodes from which it collects data. If NetScore is deployed in your network, connectivity to the SBC will be lost any time the SBC software is reinstalled because the SBC’s host key is updated during the install. Refer to NetScore Release Notes for steps needed to reconnect to the SBC.

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

Refer to SBC 5000-7000-SWe Interoperability Matrices for the latest and minimum compatible product versions supporting the 07.02.04R002 release.

Compatibility with Ribbon Products

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

Note

For complete interoperability details between various Ribbon products, including backwards compatibility, refer to Ribbon Product Compatibilities.



Refer to SBC 5000-7000-SWe Interoperability Matrices for the latest and minimum compatible product versions supporting all releases. For specific interoperability information for the 07.02.04R002 release, refer to the following table:

07.02.04R002 SBC Core Compatibility Matrix

Compatible Ribbon Products by Version

EMS

PSX

GSX 9000

DSI

NetScore

SBC 1K/2K/SWe Lite

Latest11.02.03R00011.02.04R00111.00.03R00109.03.00P605.01.03R00008.00.01
Minimum11.00.00R00009.03.06R00009.02.07R00009.03.00R00005.01.01R00007.00.00

Sample Heat Templates Included in This Release

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

SBC Heat Templates

 Template NameDescription
heatRgNoDhcp.yamlM-SBC/S-SBC Heat template for No DHCP IPv4 or IPv6. This template include instructions to enable port redundancy.

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 more information on the requirements for the SBC SWe Cloud for OpenStack, refer to For OpenStack.

SBC SWe Requirements for KVM

For more information on the requirements for the SBC SWe Cloud for KVM, refer to For KVM Hypervisor.

SBC SWe Requirements for VMWare

For more information on the requirements for the SBC SWe Cloud for VMWare, refer to For VMware.

Required Software and Firmware Versions

The following SBC 5000 series (51x0/52x0), SBC 5400 and SBC 7000 software and firmware versions are required for this release. For 5xx0 the BIOS can be installed during app install, whereas for 5400 and 7000 the BIOS is included in the firmware package and is 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 BIOSV02.06.00
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

V06.02.04-R002
SonusDB

V07.02.04-R002

EMAV07.02.04-R002

SBC Application

V07.02.04-R002

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 bundles are available for download from the Customer Portal:

  • SBCSWe_7.2
  • SBC5x7x_7.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 3.2.1R0. 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-V07.02.04R002-connexip-os_06.02.04-R002_7_amd64.iso
  • sbc-V07.02.04R002-connexip-os_06.02.04-R002_7_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-V07.02.04R002-connexip-os_06.02.04-R002_7_amd64.qcow2
  • sbc-V07.02.04R002-connexip-os_06.02.04-R002_7_amd64.qcow2.md5
  • sbc-V07.02.04-R002.x86_64.tar.gz
  • sbc-V07.02.04-R002.x86_64.md5
  • sbc-V07.02.04-R002.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. The SBC has several different CSAR variants, for different personalities (S-SBC, M-SBC) and interface types (virtio, sriov). The supported CSAR packages for the SBC are:

  • ssbc_virtio_7.2.csar
  • ssbc_sriov_7.2.csar
  • msbc_virtio_7.2.csar
  • msbc_sriov_7.2.csar

Files required for CSAR creation: 

  • createVnfmCsar.py
  • vnfmSol001VnfdTemplate.yaml
  • sbc-V07.02.04R002-connexip-os_06.02.04-R002_7_amd64.qcow2

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

Upgrade Notes

Warning

Only perform a LSWU on an SBC 70000 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 7.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 (307782653) is automatically removed from the system.

Note

As an SBC Core password security enhancement, user passwords automatically expire after upgrading to 7.2.x. As a result, users are required to change their passwords upon initial login immediately following the upgrade.

Note

Customers using the Network licensing mode will stay on the Network licensing mode after upgrade to the SBC 7.2.4 Release.

Customers using Legacy mode will stay on the Legacy mode after upgrade to SBC 7.2.4 Release. Once upgraded to SBC 7.2.4 Release, the customer will not be able to set Network License mode.

Note

The SBC 7.2 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 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.

07.02.04R002 Upgrade Information

Warning

Prior to performing an upgrade to release 07.02.04R002, remove usernames that do not conform to the new SBC user-naming rules to prevent an upgrade failure. 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 7.2.4R002. 

Warning

Prior to performing an upgrade to the 7.2 release, the dnsGroups with type mgmt must be specified/updated with the "interface" field. The steps are included in WBA "W-17-00022847". To view the WBA, log on to the Support Portal and click the Announcement link from the menu bar. Enter the bulletin number (last eight numbers) in the search field and press Return.

Warning

Prior to performing an upgrade to 7.2 release, the duplicate trunk groups or zones must be removed. The steps are included in WBA "W-17-00022689". To view the WBA, log on to the Support Portal and click the Announcement link from the menu bar. Enter the bulletin number (last eight numbers) in the search field and press Return.

If the above MOP is not run, the LSWU process may fail because of duplicate trunk group or zone names.

If you are upgrading from any SBC version with ePSX configuration to the 07.02.04R002 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.

Support of maddr Post-Upgrade

When upgrading SBC Core to release 5.0.0 (and above) from a pre-4.2.4 release, complete the "Action to take" immediately after the upgrade if either condition that follows is applicable:

  • If you are using the SBC with a Broadsoft system and the SBC is configured for registration access (where the SBC sits between SIP phones and the Broadworks System). Otherwise no new REGISTER will be processed (phones will lose registration).
  • If you are using the SBC with other feature servers that require maddr processing.

Action to take: On the SIP trunk group facing Broadsoft (or other feature server), set the SIP Trunk Group signaling flag, honorMaddrParam, to enabled on the Trunk Group(s) requiring maddr handling. The default is ‘disabled’.

set addressContext <addressContext name> zone <zone name> sipTrunkGroup <TG name> signaling honorMaddrParam <disabled | enabled> 

See the following pages for configuration details:

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 WBA "Warning-14-00020748". To view the WBA, log on to the Support Portal and click the Announcements link from the menu bar. Enter the bulletin number (last eight numbers) in the search field and press Return.

Note

The SBC 7.2 release skips the SRV query if the flag in a DNS NAPTR response from the DNS server indicates to proceed with "A" record query as per RFC 2915/3403. This is a change in behavior from previous releases, where the SBC performed SRV queries irrespective of the "flag" setting returned by DNS Server.  If you use DNS NAPTR/SRV/A record query from SBC to determine peer transport address, ensure the DNS Server is configured to return ‘S’ flag to invoke an SRV query.

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.

Please read the following information and take necessary actions before starting your upgrade to this release.

Since the release 4.1.4, the cryptographic key pair used to sign and verify the package has been changed to enhance security. When installing/upgrading from all 4.0.x releases, all pre-4.1.4 releases (4.1.3 and earlier), and all pre-4.2.3 releases (4.2.2R00x and earlier), do one of the following, depending upon your upgrade method:

  • LSWU through CLI: Skip the integrity check during LSWU by using the CLI command below.

    During LSWU, use the integrityCheck skip option when upgrading from CLI:

    > request system serverAdmin <server> startSoftwareUpgrade integrityCheck skip package <package>
    Note

    Integrity check works as expected only when upgrades are started from 4.1.x releases (4.1.4R000 or later) or from 4.2.3R000 or later releases.

  • Upgrade through Platform Manager: If upgrading using Platform Manager, simply ignore the "Wrong Signature" warning message and continue the upgrade normally.
Note

Downgrading to any pre-5.0 release from this release requires a ConnexIP re-ISO installation. For more information, refer to:


Customer running 7.1 or 7.2 releases must check the eventLog configuration to confirm that the memusage log type has a server1 syslog configuration and if it is not present, they need to manually create before attempting to upgrade to the latest code.

The following command example output shows how to confirm with the server1 config is present for the memusage log type:

show configuration oam eventLog typeAdmin
typeAdmin packet {
 
state      enabled;   
fileCount   64;   
fileSize    10240;
filterLevel info; 
servers server1;
 }

 typeAdmin memusage {
 state enabled;
 }

Update the configuration with the following commands -
configure
 set oam eventLog typeAdmin memusage servers server1

Supported Live Software Upgrade (LSWU) Paths


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


Supported Upgrade Paths

V05.00.xxV05.01.xxV06.xxV07.xx
V05.00.00R000V05.01.00R000V06.00.00R000V07.00.00R000
V05.00.00R001V05.01.00F001V06.00.00R001V07.00.00F001
V05.00.00S102V05.01.00F002V06.00.00F001V07.00.00F002
V05.00.00S104V05.01.00F003V06.00.00F002V07.00.00F003
V05.00.00S200V05.01.00F004V06.00.00F003V07.00.00F004
V05.00.00S201V05.01.00F005V06.00.00F004V07.00.00F005
V05.00.00S202V05.01.00F006V06.00.00F005V07.00.00F006
V05.00.00S203

V05.01.00F007

V06.00.00F006V07.01.00R000
V05.00.00S204V05.01.00F008V06.00.00F007V07.01.00R001
V05.00.00F001V05.01.01F001V06.00.00F008V07.01.00R002
V05.00.00F002V05.01.01F002V06.00.00F009V07.01.00R003 
V05.00.00F003V05.01.01F003V06.00.00F010V07.01.00R004
V05.00.00F004V05.01.01F004V06.00.00F011V07.01.00F001
V05.00.01R000V05.01.01F005V06.00.00F012

V07.01.00F003

V05.00.01R001V05.01.01F006V06.00.00F013

V07.02.00R000

V05.00.01R002V05.01.00S608V06.00.00F014V07.02.00R002
V05.00.01S001V05.01.00S610V06.01.00F001V07.02.01R000
V05.00.01F001V05.01.00S611V06.01.00F002V07.02.01R001
V05.00.01F002V05.01.00S612V06.01.00F003V07.02.01R002
V05.00.01F003V05.01.00S613V06.01.00R000

V07.02.01R003

V05.00.02R000V05.01.00S614V06.01.00R001

V07.02.01R004

V05.00.02R001V05.01.00S617V06.01.00R002V07.02.01R005
V05.00.02A059V05.01.00S619V06.01.00R003V07.02.01R006
V05.00.02A061V05.01.00S620V06.01.00R004

V07.02.01R007

V05.00.02F001V05.01.00S621V06.01.00R005 

V07.02.01R008

V05.00.02F002V05.01.00S622V06.01.00R006V07.02.01F001
V05.00.02F003V05.01.01R000

V06.01.00R007

V07.02.01F002
V05.00.02F004V05.01.01R001V06.01.00R008V07.02.01F003
V05.00.02F005V05.01.02F001V06.01.00R009V07.02.01F004
V05.00.03R000V05.01.02F002V06.02.00R000V07.02.01F005
V05.00.03R001V05.01.02F003V06.02.01R000V07.02.02R000
V05.00.03R002V05.01.02F004V06.02.01R001V07.02.02R001
V05.00.03R003V05.01.02F005V06.02.01R002V07.02.02R002
V05.00.03F001V05.01.02F006V06.02.01F001V07.02.02R003
V05.00.03F002V05.01.02F007V06.02.01F002V07.02.02F001
V05.00.03F003

V05.01.02F008

V06.02.01F003V07.02.03R000
V05.00.03F004V05.01.02F009V06.02.01F004V07.02.03R001
V05.00.03F005V05.01.02S001V06.02.01F005V07.02.03R002
V05.00.03F006V05.01.02R000V06.02.01F006V07.02.03R003
V05.00.03F007V05.01.02R001

V06.02.01F007

V07.02.03R004
V05.00.03F008V05.01.02R002

V06.02.01F008

V07.02.04R000
V05.00.04F001V05.01.02R003

V06.02.01F009

V07.02.04R001
V05.00.04R000V05.01.02R004

V06.02.01F010


V05.00.04R001V05.01.03R000

V06.02.01F012


V05.00.05F001V05.01.03F001

V06.02.02R000


V05.00.05F002V05.01.03F002

V06.02.02R001


V05.00.05F003V05.01.03F003

V06.02.02F001


V05.00.05F004V05.01.03F004

V06.02.02F002


V05.00.05F005V05.01.03F005

V06.02.02F003


V05.00.05F006V05.01.03F006

V06.02.02F004


V05.00.05F007V05.01.03F007

V06.02.02F005


V05.00.05F008V05.01.03F008

V06.02.02F006


V05.00.05R000V05.01.03F009

V06.02.02F007


V05.00.06R000 V05.01.03F010

V06.02.02F008


V05.00.06F001V05.01.04R000

V06.02.02F009


V05.00.06F002V05.01.04F001

V06.02.02F010


V05.00.06F003V05.01.04F002

V06.02.02F014


V05.00.06F004V05.01.04F003

V06.02.03R000 


V05.00.06F005V05.01.04F004V06.02.03F001

V05.01.05R000V06.02.03F002

V05.01.05F001V06.02.03F003

V05.01.05F002V06.02.03F004

V05.01.05F003V06.02.03F005

V05.01.05F004V06.02.03F006

V05.01.05F005 V06.02.04R000

V05.01.05F008V06.02.04F001

V05.01.06R000V06.02.04F002

V05.01.06F001

SBC v07.02.00F001 does not have an available LSWU path.


Note

Prior to upgrading to 7.x, run the following command to verify availability of at least 40 MB free disk space in the /boot partition.

df -kh

New Features

New Features in 07.02.04R002 Release

There are no new features in this release.

 

New Features in Previous Releases

 

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


Resolved Issues

Resolved Issues in 07.02.04R002 Release 

The following Severity 1 issues are resolved in this release:


Resolved Issues


Issue IDSevProblem DescriptionResolution
1SBX-998741

The Second INVITE with a replace gets the incorrect PSX route.

Impact: The Second INVITE with a replace gets the incorrect PSX route.

Root Cause: There was a design gap in case of multilevel INVITE with REPLACES due to which SBC was sending a light weight PSX look up with incorrect source and destination trunk group. Due to this, SBC is receiving incorrect TG configuration from PSX.

Steps to Replicate: 

  1. The A and B are connected.
  2. The C sends an INV with REPL to replace A.
  3. The D sends an INV with REPL to replace C.
  4. The D sends Re-INV with a=inactive.

The code is modified so that the SBC sends a light weight PSX lookup with the correct source and destination trunks to get the corresponding TG level configuration.

Workaround: N/A

2SBX-100917 / SBX-1002491

Portfix SBX-100249: A PRS process core occurred on the Standby Server.

Impact: The PRS process cored due to the XRM accessing a NULL pointer inside of the XRES data structure.

Root Cause: The root problem was that pkt2 on standby node was stuck in DOWN state due to a possible network switch issue while the pkt2 on active node was functioning as normal. All the activated XRESs selected on LIFs of pkt2 were mirrored to standby and got inserted in the deferredXresList while waiting for the standby pkt2 to be UP.

Then when one of those XRESs is reused for a different call and mirrored to the standby node, that XRES may still be stuck in the deferredXresList because the deallocate request may have not been processed yet on the standby node. Then the PRS process hit a coredump caused by XRM accessing the NULL pointer inside of XRES data structure.

Steps to Replicate: Access an SBC HA pair, active node has pkt ports all UP, and standby node has at least one of the pkt port DOWN, for example, the pkt1 is DOWN.

Start fairly high call load and to ensure calls are picking LIFs of pkt1 on active node in the example, and to ensure the XRES on pkt1 are being re-used.

Note: The standby pkt1 should stay DOWN all the time during the test.

The code is modified to properly free the XRES in deferredXresList so that it can be re-used for the new call.

Workaround: Manually keep the pkt ports sync between active and standby nodes.

3SBX-1010571

The JFK1-CUSBC-16 both coredumped.

Impact: The iceSupport, SMM iptgStore configuration, and invalid incoming call may cause an SBC coredump.

Root Cause: After the response failure to an invalid call, the SBC still tries to initiate a setup call. As a result, it accesses invalid address.

Steps to Replicate: Configure the iceSupport, the SMM storeIPTG, an incoming call with invalid candidate (no UDP).

Platform/Feature: SBC

Add an address validation and try to not initiate a setup call if the call fails.

Workaround: SMM drops an incoming call.

The following Severity 2/3 issues are resolved in this release:


Resolved Issues


Issue IDSevProblem DescriptionResolution
1SBX-992992

The SBC was routing calls to the wrong port number when targets are defined by the SRV records and 1 or more targets get blacklisted.

Impact: When an IP peer is configured as FQDN and FQDN resolves into two IP address, port combinations, when one of the peer is blacklisted, the SBC may start sending call to invalid IP address, port combination.

Root Cause: When one of the peer is blacklisted, the SBC uses port from blacklisted peer.

Steps to Replicate: Reproduce the scenario:

  1. Configure the FQDN as IP PEER.
  2. Configure the DNS server to respond with 2 records.
  3. One of the peer is down or unresponsive
  4. After a certain number of calls, the SBC starts sending call to invalid IP and port combination

    Verify the fix:
    In the scenario above, ensure the SBC sends all calls to correct IP and port combination.

The code is modified to ensure the SBC uses correct port when IP Peer is configured as FQDN and one of the peer is blacklisted,

Workaround: N/A

2SBX-100596 3

The sipParamFilterProfile became broken.

Impact: When an extension is blocked by configuring in the sipParamFilterProfile, the SBC does not send an unsupported header when sending 420 Bad extension.

Root Cause: The SBC does not have logic to include unsupported header when an 420 Bad extension is sent while processing sipParamFilterProfile configuration.

Steps to Replicate: Below are test cases when the require action is set to passthrough.

The code is modified to ensure the SBC includes an unsupported header when sending a SIP 420 Bad extension.

Workaround: N/A

SBX-100596 Steps to Replicate

When sending an 420, all headers present in incoming request except the ones which are marked as passthrough are sent in Unsupported header.

Incoming INVITE Require Header sipParamFilterProfile
Config , rejectRequest enabled common for all test cases. Unsupported Header in 420 Bad extension sent to Ingress ( with fix )
Require: Replaces set profiles services sipParamFilterProfile PROFIL1 sipHeader require action passthrough timer

Unsupported: replaces
Require: Replaces,timer
set profiles services sipParamFilterProfile PROFIL1 sipHeader require action passthrough timer
Unsupported: replaces
Require: Replaces,timer, path,eventlist
set profiles services sipParamFilterProfile PROFIL1 sipHeader require action passthrough Replaces,timer
Unsupported: path,eventlist
Require: Replaces,timer, path,eventlist,unknownHeader1

( Includes unknown header as well )

sipParamFilterProfile PROFIL1 sipHeader require action passthrough Replaces Unsupported: timer, path,eventlist,unknownHeader1
Require: Replaces,timer, path,eventlist,unknownHeader1

( Includes unknown header as well )
sipParamFilterProfile PROFIL1 sipHeader require action passthrough Replaces, timer, unknownHeader1 Unsupported: path, eventlist
Require: Replaces,timer, path, eventlist, unknownHeader1

( Includes unknown header as well )

sipParamFilterProfile PROFIL1 sipHeader require action passthrough Replaces, timer, unknownHeader2 Unsupported: path, eventlist, unknownHeader1

( note that unkonwnheader2 was configured in passthrough list )

Require: Replaces,timer, path,eventlist,unknownHeader1, unknownHeader2
sipParamFilterProfile PROFIL1 sipHeader require action passthrough unknownHeader1, unknownHeader2 Unsupported: timer, replaces, path, eventlist


Resolved Issues in 07.02.04R001 Release 

The following issues are resolved in this release:


Resolved Issues


Issue IDSevProblem DescriptionResolution
1SBX-993093

A call hold using the a=recvonly method is not sending CPG information in SIP-I to a SIP call.

Impact: In a SIP-I to SIP call flow, after a call is answered when egress Peer sends a re-INVITE with recvOnly to the SBC, the SBC does not hold an indication in ISUP body.

Root Cause: The SBC does not treat recvOnly as hold and does not send a hold indication to the SS7 library.

Steps to Replicate: 

  1. After a call is answered, the Egress peer sends a recvOnly INVITE.
  2. The SBC sends a recvOnly SIP to the ingress and the ingress responds with sendOnly.
    Observation: There was no hold indication sent in ISUP body to peer.
  3. With a fix, the HOLD Indication is sent to ISUP and after receiving a sendRecv reINVITE from the egress, the SBC sends a Retrieve indication in ISUP body to ingress.

Platform/Feature: SBC: SIP Applications

The code is modified to ensure the SBC correctly treats the recvOnly as hold and sends the hold indication in ISUP body to the peer. After retrieving the sendRecv INVITE, the SBC sends a retrieve indication in the ISUP body.

Workaround: N/A

2SBX-982002

During a SCM memLeak (SIPSG), memory was not freeing for the pSbyRcb→pcrfInfo structure.

Impact: PCRF related structures are leaking on the standby when processing Registrations if the PCRF is configured on a Trunk Group.

Root Cause: Memory that was allocated for PCRF related structures is not being freed as part of de-registration processing.

Steps to Replicate: 

  1. Configure the pcrfCommitment to a value other than none.
  2. Set the pcrf_signallingPath to enabled.
  3. Set the pcrf_provSignalingFlow to enabled.

Platform/Feature: SBC: SIP

The code is modified to free the memory that is allocated for PCRF related structures as part of de-registration processing.

Workaround: Workaround is to set the pcrfCommitment to none.

3SBX-99931 / 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 the Request URI if they are not processed by the SBC.

Root Cause: When implementing the changes for this new flag in 723 R1, this flag check was missed.

Steps to Replicate: 

  1. The UAC sends an INVITE towards the SBC over the 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 after, towards the Redirector.
  4. The Redirector sends the 3xx with the contact containing UAS IP and DTG info.

Expected Result:

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

Actual Result:

  1. 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 to fix this issue.

4SBX-989962

There is no audio on the SRTP calls.

Impact: Certain call scenarios (SRTP with ICE) intermittently start with one-way audio on encrypted leg(s) due to SRTP authentication failures.

Root Cause: Using a race condition in the setup of encryption and decryption resource results in the uninitialized ROC value being used to encrypt outgoing media packets.

Steps to Replicate: Run a SRTP with ICE call load overnight and verified no authentication failures.

Platform/Feature: SBC

The code is modified to ensure encryption ROC begins at zero.

Workaround: N/A

5SBX-99064 / SBX-99063 / SBX-100121 / SBX-1001242

The LRBT had an unexpected UPDATE with the AMR-WB codec sent.

Impact: The SBC is not playing the tone using the same codec as negotiated, when the 183 with SDP is received and the same is indicated to ingress with UPDATE.

Root Cause:  It is a race condition exposed under the following conditions:

1. A calls B and B sends a 180 without SDP causing the tone to be played to A.
2. Subsequently B sends 183 with SDP so that the SBC needs to send UPDATE out to A for changing the codec.
3. Soon after the 183 with SDP from ingress is received, a 180 without SDP causes the tone play to start.
4. The race condition can be visualized as the UPDATE's 200 OK with SDP trying to modify the system for CUT-THRU, but instead interferes with resource management subsystem's attempt to play tone.
5. As a result, the resource management subsystem picks the incorrect PSP's to play tone.

Steps to Replicate: This steps cannot be reproduced.

Platform/Feature: SBC

The code is modified to enforce that while picking the PSP's to modify when TONE is on, pick the latest PSP and not an earlier one.

Workaround: Providing for Transcode b/w WB-NB will a correct call.

6SBX-98498 / SBX-1001242

Sending an unnecessary UPDATE with the HD codec instead of a G711A for a SIP-I to SIP call.

Impact: When a 200 OK for INVITE comes from egress side with G711A, the SBC sends an unnecessary UPDATE with an HD codec that leads to a no audio call.

Root Cause: The SBC was trying to play a tone by stopping and starting the current tones.

Steps to Replicate: Use the following call flow to reproduce the issue.

Platform/Feature: SBC

The code is modified so when it is not necessary, the SBC continues to play the tone when a 180 without SDP is received.

Workaround: N/A

 SBX-98498 Steps to Replicate

---------------------- dbgDecode CALL FLOW FILE ----------------------

timestamp gcid ingress call leg [ sonus gateway ] egress call leg

INVITE <sip:IP>@00.00.000.00:5060;dtg=<example>
Via: SIP/2.0/UDP 10.00.000.00:<branch tag>=<example>
Via: SIP/2.0/UDP 10.00.000.00:<audio tag>;branch=<example>
From: "OBS" <sip:IP@10.00.00.00:<audio tag>>;tag=<example>
To: Customer<sip:example@10.00.000.00:5060>
Call-ID: <customer call ID>
CSeq: 1 INVITE
Content-Type: application/sdp
sdp {
c=IN IP4 <IP address>
m= <media tag>
a=sendrecv
}
17:22:10.773748 [gcid 0x00080000]: [ingressPeer][ sip] ------------------->> [ sip][sonus]

SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.00.000.00:<branch tag>=<example>
Via: SIP/2.0/UDP 10.00.000.00:<audio tag>;branch=<example>
From: "OBS" <sip:IP@branch tag>;tag=<example>
To: sut <sip:IP@branch IP>;tag=<address>
Call-ID: <customer call ID>
CSeq: 1 INVITE
17:22:10.00000 [gcid 0x00080000]: [ingressPeer][ sip] <<------------------- [ sip][sonus]

INVITE sip:+<example>;phone-context=private@10.00.00.00:00000;user=phone SIP/2.0
Via: SIP/2.0/UDP <IP address>:5060; branch=<example>
From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example>
To: <sip:IP@branch IP>;tag=<address>
Call-ID: <customer call ID>
CSeq: <variable> INVITE
Content-Type: application/sdp
sdp {
c=IN IP4 <IP address>
m=<media tag> 
a=sendrecv
}
17:22:10.855252 [gcid 0x00080000]: [sonus][ sip] ------------------->> [ sip][egressPeer]

INVITE sip:<example>phone-context=private@10.00.00.00:25768;user=phone SIP/2.0
Via: SIP/2.0/UDP <IP address>:5060;branch=<example>
From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example>
To: <sip:IP@branch IP>;tag=<address>
Call-ID: <customer call ID>
CSeq: <variable> INVITE
Content-Type: application/sdp
sdp {
c=IN IP4 <IP address>
m=<media tag>
a=sendrecv
}
17:22:11.338578 [gcid 0x00080000]: [sonus][ sip] ------------------->> [ sip][egressPeer]

SIP/2.0 180 Ringing
Via: SIP/2.0/UDP <IP address>:5060;branch=<example>
From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example>
To: <sip:IP@branch IP>;tag=<address>
Call-ID: <customer call ID>
CSeq: <variable>INVITE
RSeq: 1
17:22:11.358614 [gcid 0x00080000]: [sonus][ sip] <<------------------- [ sip][egressPeer]

PRACK <sip IP address>:25768;transport=UDP SIP/2.0
Via: SIP/2.0/UDP <IP address>:5060;branch=<example>
From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example>
To: <sip:IP@branch IP>;tag=<address>
Call-ID: <customer call ID>
CSeq: <variable>PRACK
RAck: 1 <variable>INVITE
17:22:11.362756 [gcid 0x00080000]: [sonus][ sip] ------------------->> [ sip][egressPeer]

SIP/2.0 180 Ringing
Via: SIP/2.0/UDP <IP address>:5060;branch=<example>
Via: SIP/2.0/UDP <IP address>:35015;branch=<example>
From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example>
To: <sip:IP@branch IP>;tag=<address>
Call-ID: <customer call ID>
CSeq: <variable> INVITE
RSeq: <variable>
Content-Type: application/sdp
sdp {
c=IN IP4 <IP address>
m=<media tag>
a=sendrecv
}
17:22:11.391771 [gcid 0x00080000]: [ingressPeer][ sip] <<------------------- [ sip][sonus]

PRACK <sip IP address> SIP/2.0
Via: SIP/2.0/UDP <IP address>:5060;branch=<example>
From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example>
To: <sip:IP@branch IP>;tag=<address>
Call-ID: <customer call ID>
CSeq: <variable> PRACK
RAck: <variable> INVITE
17:22:11.394747 [gcid 0x00080000]: [ingressPeer][ sip] ------------------->> [ sip][sonus]

SIP/2.0 200 OK
Via: SIP/2.0/UDP <IP address>:5060;branch=<example>
From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example>
To: <sip:IP@branch IP>;tag=<address>
Call-ID: <customer call ID>
CSeq: <variable> PRACK
17:22:11.397195 [gcid 0x00080000]: [ingressPeer][ sip] <<------------------- [ sip][sonus]

SIP/2.0 200 OK
Via: SIP/2.0/UDP <IP address>:5060;branch=<example>
From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example>
To: <sip:IP@branch IP>;tag=<address>
Call-ID: <customer call ID>
CSeq: <variable> PRACK
17:22:11.467157 [gcid 0x00080000]: [sonus][ sip] <<------------------- [ sip][egressPeer]

SIP/2.0 180 Ringing
Via: SIP/2.0/UDP <IP address>:5060;branch=<example>
From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example>
To: <sip:IP@branch IP>;tag=<address>
Call-ID: <customer call ID>
CSeq: <variable>INVITE
RSeq: <variable>
17:22:15.470342 [gcid 0x00080000]: [sonus][ sip] <<------------------- [ sip][egressPeer]

PRACK sip:10.54.81.66:25768;transport=UDP SIP/2.0
Via: SIP/2.0/UDP <IP address>:5060;branch=<example>
From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example>
To: <sip:IP@branch IP>;tag=<address>
Call-ID: <customer call ID>
CSeq: <variable>PRACK
RAck: <variable> INVITE
17:22:15.475654 [gcid 0x00080000]: [sonus][ sip] ------------------->> [ sip][egressPeer]

SIP/2.0 180 Ringing
Via: SIP/2.0/UDP <IP address>:5060;branch=<example>
Via: SIP/2.0/UDP <IP address>:35015;branch=<example>
From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example>
To: <sip:IP@branch IP>;tag=<address>
Call-ID: <customer call ID>
CSeq: <variable> INVITE
RSeq: <variable>
17:22:15.478644 [gcid 0x00080000]: [ingressPeer][ sip] <<------------------- [ sip][sonus]

PRACK <sip IP address>
Via: SIP/2.0/UDP <IP address>:5060;branch=<example>
From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example>
To: <sip:IP@branch IP>;tag=<address>
Call-ID: <customer call ID>
CSeq: <variable> PRACK
RAck: <variable> INVITE
Content-Type: application/sdp
17:22:15.481542 [gcid 0x00080000]: [ingressPeer][ sip] ------------------->> [ sip][sonus]

SIP/2.0 200 OK
Via: SIP/2.0/UDP <IP address>:5060;branch=<example>
From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example>
To: <sip:IP@branch IP>;tag=<address>
Call-ID: <customer call ID>
CSeq: <variable> PRACK
17:22:15.484805 [gcid 0x00080000]: [ingressPeer][ sip] <<------------------- [ sip][sonus]

SIP/2.0 200 OK
Via: SIP/2.0/UDP <IP address>:5060;branch=<example>
From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example>
To: <sip:IP@branch IP>;tag=<address>
Call-ID: <customer call ID>
CSeq: <variable> PRACK
17:22:15.582867 [gcid 0x00080000]: [sonus][ sip] <<------------------- [ sip][egressPeer]

SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP <IP address>:5060;branch=<example>
From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example>
To: <sip:IP@branch IP>;tag=<address>
Call-ID: <customer call ID>
CSeq: <variable>INVITE
RSeq: 3
Content-Type: application/sdp
sdp {
c=IN IP4 <sip IP address>
c=IN IP4 <sip IP address>
m=<media tag>
a=sendrecv
}
17:22:15.786568 [gcid 0x00080000]: [sonus][ sip] <<------------------- [ sip][egressPeer]

PRACK <sip IP address>;transport=UDP SIP/2.0
Via: SIP/2.0/UDP <IP address>:5060;branch=<example>
From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example>
To: <sip:IP@branch IP>;tag=<address>
Call-ID: <customer call ID>
CSeq: <variable>PRACK
RAck: <variable> INVITE
17:22:15.795065 [gcid 0x00080000]: [sonus][ sip] ------------------->> [ sip][egressPeer]

SIP/2.0 200 OK
Via: SIP/2.0/UDP <IP address>:5060;branch=<example>
From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example>
To: <sip:IP@branch IP>;tag=<address>
Call-ID: <customer call ID>
CSeq: <variable> PRACK
17:22:15.797360 [gcid 0x00080000]: [sonus][ sip] <<------------------- [ sip][egressPeer]

SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP <IP address>:5060;branch=<example>
Via: SIP/2.0/UDP <IP address>:35015;branch=<example>
From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example>
To: <sip:IP@branch IP>;tag=<address>
Call-ID: <customer call ID>
CSeq: <variable> INVITE
RSeq: <variable>
17:22:15.797978 [gcid 0x00080000]: [ingressPeer][ sip] <<------------------- [ sip][sonus]

PRACK <sip IP address> SIP/2.0
Via: SIP/2.0/UDP <IP address>:5060;branch=<example>
From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example>
To: <sip:IP@branch IP>;tag=<address>
Call-ID: <customer call ID: sip IP address>
CSeq: <variable> PRACK
RAck: <variable> INVITE
Content-Type: application/sdp
17:22:15.800737 [gcid 0x00080000]: [ingressPeer][ sip] ------------------->> [ sip][sonus]

SIP/2.0 200 OK
Via: SIP/2.0/UDP <IP address>:5060;branch=<example>
From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example>
To: <sip:IP@branch IP>;tag=<address>
Call-ID: <customer call ID: sip IP address>
CSeq: <variable>PRACK
17:22:15.804002 [gcid 0x00080000]: [ingressPeer][ sip] <<------------------- [ sip][sonus]

UPDATE <sip IP address>;transport=UDP SIP/2.0
Via: SIP/2.0/UDP <IP address>:5060;branch=<example>
From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example>
To: <sip:IP@branch IP>;tag=<address>
Call-ID: <customer call ID: sip IP address>
CSeq: <variable>UPDATE
Content-Type: application/sdp
sdp {
c=IN IP4 <sip IP address>
m=<media type>
a=sendrecv
}
17:22:15.844104 [gcid 0x00080000]: [ingressPeer][ sip] <<------------------- [ sip][sonus]

SIP/2.0 200 OK
Via: SIP/2.0/UDP <IP address>:5060;branch=<example>
From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example>
To: <sip:IP@branch IP>;tag=<address>
Call-ID: <customer call ID: sip IP address>
CSeq: <variable>UPDATE
Content-Type: application/sdp
sdp {
c=IN IP4 <sip IP address>
m=<media type>
a=sendrecv
}
17:22:15.844634 [gcid 0x00080000]: [ingressPeer][ sip] ------------------->> [ sip][sonus]

SIP/2.0 180 Ringing
Via: SIP/2.0/UDP <IP address>:5060;branch=<example>
From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example>
To: <sip:IP@branch IP>;tag=<address>
Call-ID: <customer call ID: sip IP address>
CSeq: <variable>INVITE
RSeq: <variable>
17:22:20.803253 [gcid 0x00080000]: [sonus][ sip] <<------------------- [ sip][egressPeer]

PRACK <sip IP address>;transport=UDP SIP/2.0
Via: SIP/2.0/UDP <IP address>:5060;branch=<example>
From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example>
To: <sip:IP@branch IP>;tag=<address>
Call-ID: <customer call ID: sip IP address>
CSeq: <variable>PRACK
RAck: <variable> INVITE
17:22:20.807563 [gcid 0x00080000]: [sonus][ sip] ------------------->> [ sip][egressPeer]

SIP/2.0 200 OK
Via: SIP/2.0/UDP <IP address>:5060;branch=<example>
From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example>
To: <sip:IP@branch IP>;tag=<address>
Call-ID: <customer call ID: sip IP address>
CSeq: <variable>PRACK
17:22:20.808144 [gcid 0x00080000]: [sonus][ sip] <<------------------- [ sip][egressPeer]

SIP/2.0 180 Ringing
Via: SIP/2.0/UDP <IP address>:5060;branch=<example>

Via: SIP/2.0/UDP <IP address>:35015;branch=<example>
From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example>
To: <sip:IP@branch IP>;tag=<address>
Call-ID: <customer call ID: sip IP address>
CSeq: 1 INVITE
RSeq: 279809
17:22:20.809687 [gcid 0x00080000]: [ingressPeer][ sip] <<------------------- [ sip][sonus]

PRACK <sip IP address> SIP/2.0
Via: SIP/2.0/UDP <IP address>:5060;branch=<example>
From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example>
To: <sip:IP@branch IP>;tag=<address>
Call-ID: <customer call ID: sip IP address>
CSeq: <variable>PRACK
RAck: <variable> INVITE
Content-Type: application/sdp
17:22:20.812694 [gcid 0x00080000]: [ingressPeer][ sip] ------------------->> [ sip][sonus]

SIP/2.0 200 OK
Via: SIP/2.0/UDP <IP address>:5060;branch=<example>
From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example>
To: <sip:IP@branch IP>;tag=<address>
Call-ID: <customer call ID: sip IP address>
CSeq: <variable>PRACK
17:22:20.816141 [gcid 0x00080000]: [ingressPeer][ sip] <<------------------- [ sip][sonus]

SIP/2.0 180 Ringing
Via: SIP/2.0/UDP <IP address>:5060;branch=<example>
From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example>
To: <sip:IP@branch IP>;tag=<address>
Call-ID: <customer call ID: sip IP address>
CSeq: <variable>INVITE
RSeq: <variable>
17:22:21.314820 [gcid 0x00080000]: [sonus][ sip] <<------------------- [ sip][egressPeer]

PRACK <sip IP address>;transport=UDP SIP/2.0
Via: SIP/2.0/UDP <IP address>:5060;branch=<example>
From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example>
To: <sip:IP@branch IP>;tag=<address>
Call-ID: <customer call ID: sip IP address>
CSeq: <variable>PRACK
RAck: <variable> INVITE
17:22:21.318799 [gcid 0x00080000]: [sonus][ sip] ------------------->> [ sip][egressPeer]

SIP/2.0 200 OK
Via: SIP/2.0/UDP <IP address>:5060;branch=<example>
From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example>
To: <sip:IP@branch IP>;tag=<address>
Call-ID: <customer call ID: sip IP address>
CSeq: <variable>PRACK
17:22:21.319450 [gcid 0x00080000]: [sonus][ sip] <<------------------- [ sip][egressPeer]

SIP/2.0 180 Ringing
Via: SIP/2.0/UDP <IP address>:5060;branch=<example>                                                  Via: SIP/2.0/UDP <IP address>:5060;branch=<example>
From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example>
To: <sip:IP@branch IP>;tag=<address>
Call-ID: <customer call ID: sip IP address>
CSeq: <variable>INVITE
RSeq: <variable>
17:22:21.321235 [gcid 0x00080000]: [ingressPeer][ sip] <<------------------- [ sip][sonus]

PRACK <sip IP address>:5060 SIP/2.0
Via: SIP/2.0/UDP <IP address>:5060;branch=<example>
From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example>
To: <sip:IP@branch IP>;tag=<address>
Call-ID: <customer call ID: sip IP address>
CSeq: <variable>PRACK
RAck: <variable> INVITE
Content-Type: application/sdp
17:22:21.324074 [gcid 0x00080000]: [ingressPeer][ sip] ------------------->> [ sip][sonus]

SIP/2.0 200 OK
Via: SIP/2.0/UDP <IP address>:5060;branch=<example>
From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example>
To: <sip:IP@branch IP>;tag=<address>
Call-ID: <customer call ID: sip IP address>
CSeq: <variable>PRACK
17:22:21.326579 [gcid 0x00080000]: [ingressPeer][ sip] <<------------------- [ sip][sonus]

SIP/2.0 200 OK
Via: SIP/2.0/UDP <IP address>:5060;branch=<example>
From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example>
To: <sip:IP@branch IP>;tag=<address>
Call-ID: <customer call ID: sip IP address>
CSeq: <variable>INVITE
Content-Type: application/sdp
sdp {
c=IN IP4 <sip IP address>
m=<media type>
a=sendrecv
}
17:22:25.823182 [gcid 0x00080000]: [sonus][ sip] <<------------------- [ sip][egressPeer]

UPDATE <sip IP address>35015;transport=UDP SIP/2.0
Via: SIP/2.0/UDP <IP address>:5060;branch=<example>
From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example>
To: <sip:IP@branch IP>;tag=<address>
Call-ID: <customer call ID: sip IP address>
CSeq: <variable>UPDATE
Content-Type: application/sdp
sdp {
c=IN IP4 <sip IP address>
m=<media type>
a=sendrecv
}

Resolved Issues in 07.02.04R000 Release 

The following severity 1 issues are resolved in this release:


Resolved Issues


Issue IDSevProblem DescriptionResolution
1SBX-947361

The SBC is converting two of the same rtpmaps into one line.

Impact: A duplicated media payload may cause a syntax error when the sdpSelectedAttribueRelay and transcodefree is sent to the other side.

Root Cause: A duplicated attribute line was merged into one line.

Steps to Replicate: Configure the sdpSelectedAttribeRelay and transcodefree. 

Platform/Feature: SBC

Ignore the duplicated media payload and the attributes lines.
2SBX-952411

The SCMP coredumps occurred on the Server.

Impact: The SBC was reading off the end of a memory block while trying to copy the called and 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 resulted in the SBC reading more memory than was allocated for the hostname.

If the memory block passed was right at the edge of process memory, then it is possible this might cause a memory exception and a coredump.

Steps to Replicate: A coredump analysis and code review.

Platform/Feature: SBC

The code is modified to not read more characters that are present in the hostname to avoid reading off the end of the memory block.
3SBX-946101

The Bye URI Messages do not include the domain.

Impact: When the incoming INVITE contains a Contact header with a GR tag.

And the call flow is: SIP-SBC1 -- GW - GW - GSX- ISUP. The SBC includes an IP address in the reqURI of a BYE message and do not have FQDN present in the Contact of Ingress INVITE.

Root Cause: In a GW-GW scenario where the egress GW is GSX, the SBC sends IP address in ReqURI field of BYE message.

Steps to Replicate:

1. Reproduce the issue.
When the incoming INVITE contains a Contact header with a GR tag:

And call flow is: SIP-SBC1 -- GW - GW - GSX- ISUP, SBC includes an IP address in the reqURI of a BYE message and do not have FQDN ( present in Contact of Ingress INVITE )

2. Verify the issue.
After a fix, the SBC sends FQDN in BYE sent towards the Ingress endpoint.

Platform/Feature: SBC

The code is modified to ensure the SBC sends FQDN ( present in Contact header of Incoming INVITE ) in the reqURI of a BYE message.
4SBX-945391

Calls release cause 132 after a switchover.

Impact: The XRES uses the freed altMediaIpAddress unexpectedly in the standby XRM when the LIF is created.

Root Cause: When the standby XRM is notified with the LIF allocate request from NRS, it only receives the LIF's IP address. Any altMediaIpAddress will not be populated until the 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: The SBC HA and SIPP call test setup:

1. Disable the keepAlive timer in the sipTrunkGroup.
2. Enable the debug INFO level logging.
3. Configure the altMediaIpAddress on LIF or LIFs if both ingress and egress legs have XRESs.
4. Configure the link detection on pkt port, threshold = 1 and enable it.
5. Make 5 basic SIP calls, call's mediaIpAddress = altMediaIpAddress, and call duration >= 20 mins.
6. Pull the cable from the pkt port, or ports if 2 pkt are interfaces involved, with link detection enabled.
7. Check the callCountStatus, wait for 5 min and plug in the cable on pkt port(s).
8. Check the callCountStatus again and wait for HA pair to finish syncing.
9. Perform a switchover again.

At step 6, the switchover triggered by link detection at step 7, 5 calls should be ACTIVE, check DBG log for following messages from XRM:

1. "XrmRedResAlloc: DEBUG! Context ID 0 XRES resId x on NIF y not allocated (on deferred list), LIF z not created"
2. "XrmNifMacAddrGet: Could not find LIF ifIndex z"
3. "XrmRedUdpAlloc: Context ID 0 Could not find UDP structure for LIF..."

At step 8, the calls should still be ACTIVE.
At step 9, the calls could be released during extensive audit, but not always.

Platform/Feature: SBC: CDR, Redundancy

The code is modified to skip the XRESs using altMediaIpAddress when the LIF is created in the standby XRM. Walk through the deferred activate list one more time when the altMediaIpAddress is added in the standby XRM.
5SBX-950961

The SBC7K core dumps again after the 6.2.1F010 update.

Impact: A rare race condition can cause the SamProcess to core with a Healthcheck failure when using the TLS.

Root Cause: The root cause of this issue is a rare race condition that allows one of the threads in the SamProcess to free memory, that is still being used by another thread in the same process.

Steps to Replicate: The steps cannot be reproduced.

Platform/Feature: SBC

The code is modified to prevent the race condition that causes the Healthcheck failure.
6SBX-945771

The SBC services will not come up.

Impact: The standby fails to start and connect to the active, shutting 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 it being shut back down.

Steps to Replicate: This is a one-off situation and can be easily reproduced.

Platform/Feature: SBC

The code is modified to recover the checkpoint address if it is unknown.
7SBX-951141

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 into the EMA.
  2. Navigate to
    All->profile->services->Transparency profile->SIP Header
  3. Select the transparency profile.
  4. Click on New Sip Header.
  5. After that, the "Ignore Transparency " field will be visible.

Platform/Feature: SBC

The code is modified to create a method for checking "not" is applied to a whole expression or not to a whole expression.
8SBX-95784 / SBX-951561

Portfix SBX-95156: The SBC disconnects the call when it receives a 491.

Impact: A 491 received for a Re-Invite without an SDP was not being relayed to another Leg, even when the E2E Re-Invite and statusCode4xx6xx are enabled.

Root Cause: A 491 Relay logic is missing for the Re-Invite without SDP case.

Steps to Replicate:

  1. Enable the E2E Re-Invite and the statusCode4xx6xx.
  2. A 491 will be received for Re-Invite without a SDP sent.

Platform/Feature: SBC

The code is modified to Re-Invite without a SDP case when the E2E Re-Invite and statusCode4xx6xx are enabled.
9SBX-95921 / SBX-952641

Portfix SBX-95264: Calls stopped working after an upgrade to SBC5110 from V05.00.05F008 to V06.02.03F005.

Impact: In the X-dmi parameter, the "p=0.0.0.0" was changed to "p=" in 6.2.3F5 that was failing the parser.

Root Cause: The root trigger was the change in the IPUtilGetStr() since early 6.2 release checks the given ipAddr is a V4 or V6 address. In this case, the ipAddress was unspecified, so IPUtilGetStr() returns '\0'.

Steps to Replicate: The steps cannot be reproduced.

Platform/Feature: SBC

The code is modified to check the source IP address and initialize it to IPv4 if it is unspecified.
10SBX-933111

The 488 Response to the T38 Reinvite.

Impact: For a G.711-T.38 Fax call, if the SBC receives a G.711 reInvite with some change in SDP from ingress peer, then the SBC sends a G.711 reInvite to egress peer.

The customer expected 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 a G.711 reInvite or any other reInvite that has some change in the SDP from ingress peer, then the SBC initiates 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: The steps cannot be replicated.

Platform/Feature: SBC

The code is modified so when the SBC detects a change in the SDP for a Fax call LEG, and if the codec active for that fax call LEG is G711 and there is no change in G711 LAW, then SBC stays in a Fax call and sends the 200OK with answer-SDP as per last offer-answer negotiation. Any change in DTMF, silence Suppress mode and any other SDP parameter is ignored.

11SBX-96629 / SBX-965241

Portfix SBX-96524: Getting the Pes Process coredump while running registrations.

Impact: Getting the Pes Process coredump while running registrations.

Root Cause: CallParamMatchName function is called with matchName which is of 15 byte array and strncpy is used to copy the string to the 50 byte array but with a wrong size of MATCH_NAME_SIZE which is defined as 30 byte*.*.

Passing bigger size than the actual destination string to strncpy is resulting in padding 0’s beyond the actual 15 bytes of the matchName. This was corrupting the stack and the stack pointer and causing a segmentation fault.

Steps to Replicate: The steps cannot be reproduced.

Platform/Feature: SBC

Change the size of matchName[] to correct size.
12SBX-960871

The SBC is not sending the RTCP to egress Peer for transcode only.

Impact: In the customer call flow:

With the Ingress Peer -(ISDN)> GSX ---(GW2GW)-> SBC --(SIP)-> Egress Peer, with the PSP setting as "transcode only" and RTCP enabled, the SBC does not send RTCP packets towards the egress.

Root Cause: Due to changes made for a previous feature SBX-6366, the SBC does not mark the XRES resource as duplex and marks it as receive only. As a result, the SBC does not send RTCP towards egress.

Steps to Replicate:

  1. Reproduce the problem in following call flow:
    Ingress Peer -- SIP -- GSX -- GW2GW -- SBC -- SIP -- Egress Peer
    This transcode only call and RTCP is enabled.
    Result: No RTCP sent by the SBC to egress.
  2. Verify the issue by applying SamP with GWFE change but not change in ScmP.
  3. Use the same setup. RTCP traffic was sent from the SBC to egress.

Platform/Feature: SBC

The code is modified to set RTCP send and receive bandwidth as the 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.
13SBX-96800 / SBX-897411

Portfix SBX-89741: There was a CPX core during an upgrade from V05.01.05R000 to V07.02.01R001.

Impact: The LSWU CLI command returned in a failure due to a failure to create package sub-dir under the external directory, but the upgrade continued on 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 CLI command returns failure, the upgrade is not continued further.
14SBX-967061

Multiple switchovers causes non 5060 sipSigPorts to become inactive.

Impact: When a user configured >= 2 SIP Sig ports with same IP address but different port numbers, and they are using the same LIF group that contained 1 LIF, the pkt down triggered a switchover and it stayed down for extended time. After the pkt UP, a second switchover occurred, then only one Sig port went in service. The other Sig ports were stuck in OOS.

Root Cause: Since the pkt port was DOWN when the new standby node came back online, the SIP sig ports were restored while LIF was OOS. So address registrations were failed. After the SIPCM has reached a max number of retries, the LADDRs of the Sig ports, except the first one, were deleted in the NRS context.

When the pkt port came UP, the NRS brought LIF into service and registered the only one signaling address saved in the NRS context.

Steps to Replicate:

Test steps:
1. Configure 2 VLANs on the YF or BF pkt2.
2. Configure 4 SSPs on the first VLAN interface; 4 SSPs on the second VLAN interface. 4 SSPs use the udp/tcp port numbers 5060, 5160, 5260, and 5360 with the same IP address
3. Run the Sbxstop command.
4. Unplug the packet ports - YF pkt2
5. Run the Sbxstart command.
6. Display the SSPs on VLAN interfaces.

Platform/Feature: SBC

1. The code is modified to only delete LADDR before reaching the max number of retries.
2. Restore the pendingNrsReq flag properly when the address registration failed.

15SBX-970791

After the LDG triggered a switch over, the SBC is rejecting all the register message with a 500 internal error.

Impact: The SCM process may coredump when the SIP signaling port was being used during a 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.
16SBX-954511

The SCM fast memory increase causes a delayed switchover with an outage.

Impact: If a multilevel INVITE with Replaces is run, the memory and CPU utilization by the Scm Process increases drastically and leads to a core dump.

Root Cause: Each INVITE with Replaces is a new Callgroup. Each call group has its own segments. For each segment, there are associated segments.

When a Release call is invoked, it releases all segments and each call segment frees the associated call segments.
During the release flow for such a call CC_EV_ASG_DISC_CMD event is posted multiple times for various orig and term GCID’s.

Please note that this ultimately frees up everything although the memory and CPU utilization shoots up.

Steps to Replicate:

  1. Test multilevel INVITE replaces (more than 15).
  2. Crash will not occur.

Platform/Feature: SBC

Now in the CC state machine, the CC_EV_ASG_DISC_CMD event is not posted multiple times for the same original and term labels. This leads to drastically reducing the looping, while also ensuring that all call segments (and associated segments) are freed.

 
17SBX-977431

The SBC fails to relay the 18x/2xx towards the ingress when the SBC is configured to play tone.

Impact: The SBC Fails to relay the 18x/2xx in case of the MSRP call when tone is configured. The SBC tries to allocate tone Resources even though the Audio stream is not present.

Root Cause: The SBC is going for Tone allocation, even though audio stream is not present.

Steps to Replicate: Run a MSRP call with the tone configured.

Platform/Feature: SBC: Application

The code is modified to not trigger tone for the MSRP only call.
18SBX-96872 / SBX-918711

Portfix SBX-91871: The metavar was assigned to none.

Impact: When only one of the nodes detects a network glitch in the N:1 setup, usingMetavarsOf field of the other node is set to none.

Root Cause: A metavar response message is not sent from the node that did not detect the network glitch.

Steps to Replicate: Bring down the HA link for less than 5 seconds such that only one node detects the network glitch.

Platform/Feature: SBC

The code is modified so the ChmSendMetavarDetails indicates a reply is expected in case of NODE_SERVICE_ID_UP event.
19SBX-944031

Unable to establish the same number of sessions after the switchover.

Impact: Calls were getting cleared under load conditions after a switchover in the first gateway in a GW-GW setup.

Root Cause: When sessionKeepAlive is set and the SBC switched over, the SBC starts sending refresh INVITEs to the endpoints. Since this is a GW-GW setup, in such scenario's, the newly active GW-1 will send call processing messages to the GW-2. There was an issue in call processing at the GW-2 that resulted in call failures.

Steps to Replicate:

  1. Create a SBC GW-GW setup and enable the sessionKeepAlive.
  2. Establish a call load of more than 25K and once the call is stable, perform a switchover at the GW-1.
  3. Calls will start failing

Platform/Feature: SBC

The code is modified to take care of processing multiple segments and successfully establishing a GW-GW connection.
20SBX-942451

The SBC picks up an incorrect TG for incoming non-INVITE requests and responses to non-INVITE requests.

Impact: The SBC is picking up the wrong trunk group for incoming messages.
This is specific for a rare configuration when there is only 1 sigport sharing multiple trunkgroups, and the same peer source address routing traffic to different trunkgroups.

Root Cause: When the SBC processes inbound/outbound messages, it puts the TG into the cache table for processing after the response. In this case, there are two 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 registered end point.

Steps to Replicate: 

  1. Run a configuration where there is only 1 sigport sharing multiple trunkgroups, and the same peer source address routing traffic to different trunkgroups.
  2. Call B was sharing the same signaling port and the same peer IP.
  3. An OOD to the SBC and route back to A.
  4. Both outbound cases are using different TGs.

Platform/Feature: SBC

The code is modified to avoid swapping the TG. The SBC puts in a different new hash table, and later, the response from the request looks at the new hash table for the TG.
21SBX-979601

An incorrect transparency functionality causes calls to fail.

Impact: The To header transparency becomes active and launches a successful ENUM query may cause an incorrect RURI format. 

Root Cause: The RURI build was based on the To header.

Steps to Replicate: Enable the To header transparency and PSX ENUM LNP response may contain an empty “Called URI”.

Platform/Feature: SBC

The code is modified so the RURI is independent of To header.
22SBX-98993 / SBX-989921

Portfix SBX-98992: The EMA logs are not being copied in SysDump, however, the folder is there.

Impact: The EMA logs are not captured by the sysdump. 

Root Cause: The EMA log location was changed in the 6.0.0 and the sysdump was never updated with the change.

Steps to Replicate: Run sysdump and verify the EMA logs are captured.

Platform/Feature: SBC

The code is modified to use the correct location for the EMA logs.
23SBX-971121

The EMA response time on the SBC 7.2.3 release is very high.

Impact: The EMA response time on the SBC 7.2.3 release is very high.

Root Cause: Making more than six TCP calls at a time from the browser.

Steps to Replicate: 

  1. Log in to EMA.
  2. Route from Configuration->System Provisioning-> Routing

A user can see the efficiency of screen loading.

Platform/Feature: SBC

The code is modified to fix the issue.
24SBX-969961

The Scm Process cored.

Impact: When the pathcheck timeout, and the SBC is unable to find a zone, the SBC may core.

Root Cause: Access the null pointer.

Steps to Replicate: The steps cannot be reproduced.

Platform/Feature: SBC

Check for the valid zone pointer before the access.
25SBX-971991

The Wall Comcast PM-SBC memory increasing.

Impact: There is a memory leak in the PRS. The structures associated with certain interprocess messages are leaking.

Root Cause: The structures associated with certain interprocess messages are leaking because these structures were not being freed.

Steps to Replicate: The steps cannot be reproduced.

Platform/Feature: SBC

The code is modified to free the memory for certain interprocess messages.
26SBX-953551

The SIP to SIP call no ring back tone passed to the ingress when PEM header is enabled on egress endpoint.

Impact: There was no RBT when the PEM header is enabled, the Split 18x moves into alerting and progress flag is enabled.

Root Cause: This flow was never tested with flag, and with Split 18x into alerting and progress.

Steps to Replicate: Setup call with PEM enabled on the egress and with Split 18x flag enabled.

Platform/Feature: SBC

Before 18x is split, the PEM header handling is updated and corrected.
27SBX-932391

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

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

Root Cause: A bad resource activation.

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

Platform/Feature: SBC

The code is modified to stop activating the full resource chain when the tone is being played.
28SBX-96954 / SBX-958741

Portfix SBX-95874: The SBC's dump SCM process when running a MSRP call with the LI enabled.

Impact: The SCM process dumps when running a MSRP call with the PCSILI enabled.

Root Cause: The SBC sends an invalid Stream ID for non audio calls in NrmaDsbcSendDummySplitterCmd() and NrmaDsbcSendSplitterCmd() when invoking NrmaDsbcIssueXresCmd(). In the M-SBC, when processing the same correct stream, the EP res is not fetched because of an invalid stream ID and is why the SYS_ERR is triggered.

Steps to Replicate: Running a MSRP call with the PCSILI enabled.

Platform/Feature: SBC

Since this command is sent per leg and not per stream, the S-SBC cannot send streamIds. In M-SBC do not use the localEp res fetched based on streamId for processing of SPLITTER_CMD. To fix the issue, avoiding fetching localEpRes and comparing the same in the M-SBC.
29SBX-97855 / SBX-990571

The wrong codec selection for the LRBT when one 183 with the SDP followed by two 180 Ringing.

Impact: The Ingress Trunk had theSIP-I and LRBT enabled and the Egress side Trunk is configured with the SIP.

The transcode conditional is enabled and the AMR-WB , AMR ,G711 and G729 are present in the Ingress and Egress Route PSP. Transcoding for AMR and AMR-WB is disabled but enabled for the G711 and G729.

After the INVITE OFFER is relayed by the SBC to Egress, the SBC receives the 183 with pcma followed by two 180 ringing alerts from the Egress.

The SBC should send 183 with PCMA in the SDP but instead it sends amr-wb, the first codec from the Offer, to the Ingress and as a result the tone is played in AMR-WB, which is incorrect.

Root Cause: For every 180 ringing alert received from the Egress, the tone is stopped and restarted. During the second tone restart, the SBC makes a new Offer with a Route PSP and discards the current answer received from the Egress Peer.

Steps to Replicate: The steps cannot be reproduced.

Platform/Feature: SBC: SIP Applications

If the tone context is present and SDP ANSWER is received, the SBC uses that to play the tone.
30SBX-99017 / SBX-978561

Portfix SBX-97856: A bad Update sent by the SBC to Ingress during the LRBT.

Impact: The SIP-I on the Ingress TG and the SIP on the Egress TG.

With the transcode conditional enabled, the AMR-WB transcoding disabled in PSP and LRBT enabled, when making a call, during the LRBT, the Egress peer sends an update with change of media port but the SBC sends unwanted UPDATE towards ingress side with the AMR-WB / 16k DTMF

Root Cause: After an update followed by 180 ringing alert is received from the Egress Peer with change in the port only, the SBC generated a new Offer to the Ingress with a Route PSP codec preference of AMR-WB discarding the active codec PCMA already negotiated.

Steps to Replicate: The steps cannot be reproduced.

Platform/Feature: SBC

The existing active TONE Packet Service Profile that is already negotiated is used in the update.
31SBX-94233 / SBX-943951

Portfix SBX-94395

Impact: RTCP Packets discarded.

IPv6 to IPv4, NAT enabled on V6 side – RTCP Packets discarded for Audio+T140 call after call modify.

Root Cause: For non-audio streams call-modify scenarios, the optional spec flag to mark the IP version was not set in the NP Interface.

Steps to Replicate: None.

Platform/Feature: SBC

Ribbon added code to set the flag for IPv6 in the NP Interface during a Modify flow.

The following Severity 2 and 3 issues are resolved in this release:


Resolved Issues


Issue IDSevProblem DescriptionResolution
1SBX-932472

A SCM leak on the Standby.

Impact: The SCM may leak memory in calls with a SIP Relay and FQDN. The memory used to store the Domain information may be leaked.

Root Cause: There is an edge case where the memory used to store the Domain information for a SIP Relay call is not being freed.

Steps to Replicate: This issue has been found by a code inspection and the steps to reproduce this case have not been identified.

Platform/Feature: SBC

The code is modified so that the memory used to store the Domain information is freed whenever the standby Relay Call Block is freed.
2SBX-94865 / SBX-945122

Portfix SBX-94512: The RTCP packets count is not getting populated consistently in the callMediaStatus.

Impact: With the RTCP relay monitoring feature, sometimes the RTCP packets are not relayed or discarded.

Root Cause: In the SWe NP, due to endian alignment code issue, the RTCP mode configuration flags were not set as per the call flows enable/modifications.

Steps to Replicate: This is sporadic, when multiple times RTCP REL MON call flows, modifications tried it might occur.

Platform/Feature: SBC

The code is modified to be applied correctly in the SWe now.
3SBX-949983

The SipSgProcessRelayRequestPrimitive: relay an INVITE without the cpcOrigMsgInfoPtr.

Impact: A increase in the DBG logs filling up with SipSgProcessRelayRequestPrimitive messages.

Root Cause: In case of an End2End Re-INVITE, the log message does not have any impact.

Steps to Replicate: The log level changed on the basis of code analysis and description.

Platform/Feature: SBC

Change the log level to info since it happens when the E2E Re-INVITE flag is enabled and does not have any negative impact.
4SBX-925822

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 an error: No Routes in Cache to the SBC. The SBC logs a trap after receiving No routes in the cache error.

Root Cause: The SBC makes an additional query to the PSX even after the PSX sent all the routes.

Steps to Replicate:

  1. Configure more than 10 routes on the PSX Routing Label (11 routes for example).
  2. All 10 routes fail.
  3. The SBC sends another query to get more route and those fail as well.
  4. The SBC still send additional query to the PSX which fails because the PSX have returned all the

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.
5SBX-95323 / SBX-939672

Portfix SBX-93967: Direct dial to a call queue, and then transfer to agent fails.

Impact: For the PSTN to Teams calls, when Teams was triggering an INVITE with replaces, perform a subsequent REFER. The SBC was not relaying the REFER-TO information from the REFER message to the subsequent INVITE. This was resulting in the wrong information being sent back to MS Teams and the call failed.

Root Cause: The SBC was not relaying the REFER-TO information from the REFER message to the subsequent INVITE.

Steps to Replicate: In a MS Teams setup run a call Q and transfer scenario where the call originates from the PSTN side.

Platform/Feature: SBC

The code is modified to pass the REFER-TO information from the REFER to the INVITE in this scenario for the MS Teams setup.
6SBX-917372

External PSX became active after a switch over, though it was the OOS prior to the switch over.

Impact: When changing the multiple remote policy servers' 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 will not try to register with this server, and the iteration of all mode change servers will be stopped. This causes the rest of the servers, whose operStats have not been changed and remain unchanged. Therefore, 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 at enabled, only keep 1 of the servers mode as active, and rest are out of service.
  3. Change those servers' mode, commit only after all the set commands finished.
  4. Display the status using the 2 commands below:
    "show table system policyServer remoteServer"
    "show table system policyServer policyServerStatus"
  5. Perform a switchover.
  6. Repeat step 4. The operStat will be different from step 4.
  7. Making call load, may be a load call rate, when the Node A is active, and then when the Node B is active. When the Node B is active, the policy request may still be sent to the remote server that you have already made the OOS when the Node A was active.

Platform/Feature: SBC

The code is modified for all remote servers requested by the CLI users, although remote servers are not registered even if the mode is being changed from the OOS to active. As a result, the operStates at standby node stays synced with the active node.
7SBX-921143

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

Impact: Removes this incorrect log message:

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

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

Steps to Replicate: The steps cannot be replicated.

Platform/Feature: SBC

The code is modified to remove this incorrect log message:

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

 
8SBX-94814 / SBX-934562

Portfix SBX-93456: The SWe NP worker has a segfault.

Impact: There is an issue in the SBX-93456, where the SWe_NP was crashing multiple times due to the skb_work->skb corruption.

Root Cause: There is a point in normal media processing ( RTP and RTCP path), where an update to skb_work->skb from addr_ptr that is not necessary, may corrupt the skb_work->skb.

The corruption occurs in the path of processing RTCP XR packets, where the addr_ptr moves ahead by a few bytes, but the UPP processing expects the mbuf address to be present back at the 58 bytes from addr_ptr.

Steps to Replicate: Run JIO scenarios.

Platform/Feature: SBC

Avoid overwriting the skb_work->skb from add_ptr.
9SBX-937122

The RTP Inactivity Timer fires early upon performing a port switch-over on the M-SBC.

Impact: If a call starts out with no RTP packet at all, the RTP Inactivity Notification is triggered earlier than the configured threshold. This is only observed on the SWe SBC.

Root Cause: The timestamp used for inactivity detection is not set when the media resource is enabled in the network processor code.

Steps to Replicate: Run a test that establishes a call where the ingress peer does not send RTP. There are no switchovers or other events and the calls are disconnected before the timer expires. The timer is set to 30 seconds.

Call service Duration with a disconnect 145.

Platform/Feature: SBC

Set the timestamp to the current time when the media resource is enabled.
10SBX-948112

The SBC fails to route in advance to the 13th route.

Impact: When the PSX has more than 10 routes configured and all routes in the first policy response fail due to an internal cause, the call fails because the SBC cannot handle more routes correctly.

Root Cause: When the PSX has more than 10 routes configured and all routes in the first policy response fail due to an internal cause, the SBC's NRMA subsytem returns with an allocation failure.

Steps to Replicate:

1. Configure more than 10 routes on the PSX.
2. Force a failure on the first 10 routes due to an internal error.
3. Verify the call gets established on the routes in second policy response.

Platform/Feature: SBC

The code is modified to ensure the SBC handles more than 10 routes from the PSX correctly.
11SBX-91463 / SBX-913982

Portfix SBX-91398: The ASAN heap-use-after-free on the address DnsClientQueryServerCmd.

Impact: The DNS client running in the SBC while trying to query the DNS server, tries to identify the transport protocol used. If the query fails on the first server, it accesses the first DNS server's data structure to get the type of transport protocol.

Root Cause: This issue was reported as part of the ASAN Testing on the DNS regression suite in the SBC lab.

Steps to Replicate: This issue was found while running the DNS regression test suites.

Platform/Feature: SBC

The code is modified to fetch the transport protocol from the next available DNS server in the list and trigger the DNS query.
12SBX-910572

The SBC fails to relay the 4xx-6xx responses when the IPTG authentication is enabled - all SIP causes are 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 the CPC 176. The SBC is unable to relay the cause code from the egress to ingress endpoint.

Root Cause: When the IPTG authentication is enabled, the SBC maps all the 4xx-6xx SIP codes to the 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 the 599 that is mapping of 176 ( CPC_DISC_TG_AUTH_FAIL, which is CPC code) to Ingress.

With a fix, the SBC sends the 486 buys to the ingress correctly.

Platform/Feature: SBC

The code is modified to ensure the SBC, upon receipt of provision response, clears the authentication flag and relays the cause code from the egress to the ingress.
13SBX-950332

The SAM Process cores when the SNMP walk commands are executed during the TLS load.

Impact: When the getTlsSessionStatus command is executed when the TLS load is running, it will result in a SAM Process core.

Root Cause: The issue is because the SIPCM expects the SSL_get1_session() to increment the reference count of the SSL socketPtr. After the SIPCM returns from the SSL_get1_session() tries to decrement, the reference count during the time the socketPtr was deleted by another thread, which results in a double free.

Steps to Replicate: The steps cannot be reproduced.

Platform/Feature: SBC

The code is modified to ensure to lock the SSL socketPtr before performing any operation so that no thread tries to access it.
14SBX-931053

The SIP OPTIONS was not responding after a failover.

Impact: A syntax error message during a switch over is unable to respond.

Root Cause: Internal messages drop due to other subsystems not being ready to process the message. Subsequent messages are stuck in the queue.

Steps to Replicate: Simple ping Options messages during a switchover.

Platform/Feature: SBC

During a switchover, the message drops.
15SBX-950072

The IPv4 Path MTU Discovery (RFC1191) was not working.

Impact: The IPv4 Path MTU Discovery (RFC1191) does not work.

The SBC uses the MTU of the outgoing network interface as the Path MTU.
Without the fix, the SBC does not update the Path MTU properly even if a router in the path sends "ICMP Destination Unreachable Fragmentation Needed" message with a smaller Path MTU value. The large packets requiring fragmentation to fit the Path MTU from the SBC will not reach the SIP peer.

Root Cause: In performing a route/fib, lookup in the updating Path MTU from "ICMP Destination Unreachable Fragmentation Needed" message did not consider the ipInterfaceGroup and addressContext. This resulted in not updating Path MTU of the proper route entry to the peer.

Steps to Replicate: The SBC sends IP packets of a length 1500 bytes toward the SIP peer when a path to the peer has a smaller MTU (e.g. 1400 bytes). A router with the smaller MTU sends "ICMP Destination Unreachable Fragmentation Needed" to the SBC. The SBC, with the fix, adjusts the Path MTU, performs the fragmentation and sends fragments to the SIP peer.

Platform/Feature: SBC

The code is modified to add ipInterfaceGroup and addressContext information in handling the "ICMP Destination Unreachable Fragmentation Needed" message in the Linux kernel. 
16SBX-949942

The lwresd process on the active node is killed when a reboot is issued.

Impact: When a reboot is issued at the command prompt on the active node, the slwresd process is killed prior to it being properly shutdown. This causes a delay in reboot processing as the system goes through a fault recovery processes rather than an expedited shutdown.

Root Cause: The reboot wrapper that kills a non-SBC processes and using the drbd mount point was inadvertently killing the swlresd process.

Steps to Replicate: On the active CE, issue a reboot at a command prompt.

Platform/Feature: SBC

The code is modified to properly detect all the SBC processes so that the slwresd is not killed by the wrapper and therefore is not detected as having failed.
17SBX-943772

A large number of TLS error messages were in DBG log.

Impact: The following log message was filling logs due to being incorrectly logged at the MINOR level (when it should have been at INFO level):

Minor .SIPSG: sipsgUtils.c (-27373) 27050. SipSgLogLevel4: missing callId need to parse

Root Cause: The following log message was incorrectly being logged at the MINOR level (when it should have been at INFO level):

Minor .SIPSG: sipsgUtils.c (-27373) 27050. SipSgLogLevel4: missing callId need to parse

Steps to Replicate: The only change was to change a log message from MINOR to INFO - there was no testing necessary.

Platform/Feature: SBC

The code is modified to change the following log message from MINOR to INFO:
Minor .SIPSG: sipsgUtils.c (-27373) 27050. SipSgLogLevel4: missing callId need to parse

18SBX-89209 / SBX-890182

Portfix SBX-89018: The ASAN heap-buffer-overflow in the CpcOptionalParameterSave from the SipSgCopySipUrlToCpc

Impact: When an INVITE arrived to start a new call, the SIP service group control "callRouting useRouteSet" is set to the value of "received" to try and route the call based on the routeset in the INVITE. While processing the URI information in the header and trying to map it into internal structures, the code was reading off the end of a memory block. This setup can cause a crash if the memory block is at the end of the heap.

Root Cause: The code was trying to apply a 4 byte alignment to the internal parameter length after the memory had already been allocated. This meant that sometimes, the parameter length got set to a larger value than the memory block size.

Steps to Replicate: This problem was identified while running ASAN testing in the Ribbon lab and cannot be reproduced using normal images.

Platform/Feature: SBC

The code is modified to correctly handle the memory management so that it does not read off the end of the memory block.
19SBX-947903

A backup/restore file cannot be downloaded from the EMA if the file name contains a dot (.).

Impact: A backup/restore file cannot be downloaded from the EMA if the file name contains a dot (.).

Root Cause: In the downloadSavedConfig block, making an API call both the time (Running on the SBC or running on the EMS).

Steps to Replicate:

  1. Login into EMA.
  2. Navigate to
    Administration -> System Administration -> Backup/Restore
  3. Download the Backup file.

Platform/Feature: SBC: EMA

Make an API call if it is running the EMS on a normal method while on the SBC.
20SBX-91113 / SBX-724992

Portfix SBX-72499: The PesP cored on the active node.

Impact: The PesP cored on the active node.

Root Cause: The Ref count is getting incremented and once it reached the max value, it is becoming zero and destroying the object in one thread. At the same time, the other thread is accessing the object and crashing.

Steps to Replicate: Keep running calls for a longer time by using only one IpSignalingProfile.

Platform/Feature: SBC: Application, ERE

The code is modified to stop the Ref count from getting incremented when it reaches the max value.
21SBX-95244 / SBX-950972

Portfix SBX-95097: The SBC is sending incorrect RACK in the PRACK for a Late Media Call.

Impact: The SBC is sending incorrect RACK in the PRACK for a Late Media Call.

Root Cause: Whenever the PRACK with SDP comes as an answer, the PRACK entry holding RSEQ details is not getting removed from the list while being sent out, because of any subsequent 18x/PRACK without SDP coming out at the same time; the SBC is adding old RSEQ in RACK.

Steps to Replicate: Late Media call with first 18x and PRACK with SDP followed by an 18x and PRACK without SDP.

Platform/Feature: SBC

To fix the issue, remove the RSEQ details from the PRACK entry List while sending PRACK with SDP out.
22SBX-945712

Missing the Egress Response Code in the Field 59.19.

Impact: Egress error response code is not updated for the SIP response “487 Request Cancelled” in the field number 59.19 in ATTEMPT CDR record.

Root Cause: In the “487 Request Cancelled” case, because there is no CANCEL sent for the INVITE, the correct function is not called that is responsible for adding field number 59.19 in the ATTEMPT CDR record.

Steps to Replicate: Set up the SBC to make a simple call flow as below, and check the CDR for field 45.19/20 and 59.19/20:

UAC.xml SBX UAS.xml
| | |
| INVITE | |
|=======>| |
| 100 | |
|<=======| |
| | INVITE |
| |=====>|
| | 487 |
| |<=====|
| | ACK |
| |=====>|
| | |
|480 | |
|<=======| |
| ACK | |
|=======>| |

Platform/Feature: SBC

The code is modified to add the field number 59.19 in the ATTEMPT CDR record, in “487 Request Cancelled” case.
23SBX-95833 / SBX-957492

Portfix SBX-95749: The SBC is not adding the Contact header in the 200 OK of UPDATE for a session refresh UPDATE.

Impact: The contact header is missing in the 200OK sent by the SBC for a session refresh UPDATE (an UPDATE without SDP or an UPDATE with the same SDP as last SDP).

Root Cause: The contact header is missing in the 200OK sent by the SBC for a session refresh UPDATE (an UPDATE without SDP or an UPDATE with the same SDP as last SDP).

Steps to Replicate:

  1. Enable the E2E Update.
  2. Trigger an UPDATE without SDP or an UPDATE with same SDP as last SDP.

Platform/Feature: SBC

The code is modified to add the contact header by the SBC when not provided by an application in the 200OK for a Session Refresh Update(an UPDATE without SDP or an UPDATE with the same SDP as last SDP).
24SBX-954702

The SBC was using the incorrect SIP signaling port for the 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 the REGISTER - SUBSCRIBE scenarios when the initial SUBSCRIBE request is challenged.

Root Cause: When the usePortRangeFlag is enabled, the SBC may use an incorrect SIP Signaling Port when handling a SUBSCRIBE request with an Authorization header to the egress peer.

Steps to Replicate:

Provision the SBC to support CUCM (Cisco Unified Connection Manager) .
Ingress zone / sipTrunkGroup:
set addressContext default zone ZONE2 sipTrunkGroup SBXSUS4_LABSIP1 signaling registration requireRegistration required
set addressContext default zone ZONE2 sipTrunkGroup SBXSUS4_LABSIP1 signaling usePortRangeFlag disabled
set addressContext default zone ZONE2 sipTrunkGroup SBXSUS4_LABSIP1 signaling psxRouteForSubscribe enabled
commit

Egress zone / sipTrunkGroup:
set addressContext default zone ZONE4 sipTrunkGroup SBXSUS4_LABSIP2 signaling registration requireRegistration none
set addressContext default zone ZONE4 sipTrunkGroup SBXSUS4_LABSIP2 signaling usePortRangeFlag enabled
set addressContext default zone ZONE4 sipTrunkGroup SBXSUS4_LABSIP2 signaling psxRouteForSubscribe disabled
commit

set profiles signaling ipSignalingProfile DEFAULT_SIP commonIpAttributes relayFlags dialogEventPackage enable
commit

Perform REGISTRATION.

Perform a challenged SUBSCRIBE.

Platform/Feature: SBC

The code is modified to use the proper connection Id, when the usePortRangeFlag is enabled, and when the SUBSCRIBE request with Authorization header is sent to the egress peer.
25SBX-952612

Co-existence of 4xx-6xx IPSP flag and Subscribe crankback is not working.

Impact: Out of dialog message fails to crankback when the relay 4xx-6xx is enabled.

Root Cause: The relay flag must not take precedent.

Steps to Replicate: Configure the crankback and enable relay 4xx-6xx flag. The subscribe response with failure must be able to crankback.

Platform/Feature: SBC: SIP

For failure response, the crankback feature must take precedent.
26SBX-95941 / SBX-959303

Portfix SBX-95941: An unknown header transparency flag interaction with Tagging.

Impact: STIR-SHAKEN related headers are duplicated when the STI service type is tagging and transparency is enabled.

Root Cause: This scenario was not handled when STIR-SHAKEN was supported in 7.2.0.

Steps to Replicate: STI Profile is assigned on Ingress and Egress TG, on Ingress STI Profile “Override P-Headers with configured values”  flag is enabled.

In egress IPSP (IPTG section) “Unknown header” transparency flag is enabled.

Platform/Feature: SBC

STIR-SHAKEN related headers are given higher precedence and ignored transparency for the P-ORIGINATION-ID and P-ATTESTATION-INDICATOR headers when the STI service type is "tagging".
27SBX-92128 / SBX-919962

Portfix SBX-91996: The SBC fails to send a=fmtp parameter towards the UAC, when the SBC received a=fmtp parameter above a=rtpmap in the answer from UAS.

Impact: The SBC fails to send a=fmtp parameter towards the UAC, when the SBC received a=fmtp parameter above a=rtpmap for the Dynamic Payload in answer from the UAS.

Root Cause: When the FMTP line is received prior to the RTP line for a dynamic payload, Internal Logical issue is causing the issue. When the string holding FMTP line is terminated with \0, the SBC unable to parse manually.

Steps to Replicate:

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

  1. The SBC must be configured to handle the AMR passthru call.
  2. The transcoding must be set as conditional.

Test Procedure:
=============

  1. The UAC sends Invite with AMR WB codec.
  2. The UAS sends 180 Ringing with AMR with following SDP:

m=audio 6084 RTP/AVP 106 100
a=fmtp:106 mode-set=0,2,5,7;max-red=0
a=rtpmap:106 AMR/8000
a=rtpmap:100 telephone-event/8000

Platform/Feature: SBC

The code is modified to handle internal logic when FMTP line string is terminated with \0.
28SBX-95831 / SBX-933602

Portfix SBX-93360: The SBC was sending an INVITE with the SRTP instead of RTP.

Impact: The SBC is sending the SRTP instead of RTP.

Root Cause: The intersection of working PSP and peer PSP does not take place in the stream absent case. The SRTP values are never updated.

Steps to Replicate:

  1. Create a UAC with RTP.
  2. Create two UAS with SRTP param.
  3. Send a port =0 for hold response.
  4. Check if the SBC is misbehaving while sending an INVITE to release hold from the far end.

Platform/Feature: SBC

The code is modified for the SRTP values for stream absent case.
29SBX-95520 / SBX-716233

Portfix SBX-71623: The SMM header criteria not matching complete header value.

Impact: The SMM header criteria was not matching complete header value, it is only checking for the value between <>.

Root Cause: The SMM value being checked is enclosed between <>.

Steps to Replicate: Write a criteria on the header value and the issue will be displayed.

Platform/Feature: SBC: Application

The code is modified to consider the entire header of comparing the criterion.
30SBX-95995 / SBX-858522

Portfix SBX-85852: The "Timeout detected -- Forcing read/write access" occurred during switchovers.

Impact: The message "Timeout detected -- Forcing read/write access" is observed during switchovers.

Root Cause: This message is logged on the NBI timer expiry (after 2mins) and configuration changes were allowed before the DBs are in sync. This occurs when standby initialization takes longer.

Steps to Replicate: Install the SBC with the fix build and perform a switchover. Ensure there is no timeout message and that configuration changes are allowed only after the DBs are in sync.

Platform/Feature: SBC

The code is modified to allow configuration changes only when both the CDB and ORACLE DB are available for READ_WRITE and when the sync is completed.
31SBX-945182

Disable media lockdown does not suppress the 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 one second media drop while re-learning for the new re-INVITE is happening. For non-NAT cases, nothing will be observable except for signaling change.

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

Steps to Replicate:

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

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

Platform/Feature: SBC

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

The R-URI in NOTIFY messages was not using the correct port number in case of TLS.

Impact: The SIP NOTIFY messages relayed through the TLS, may contain a R-URI that uses the SIP signaling port number verses the TLS port number.

Root Cause: The relay software used the SIP signaling port number instead of using the TLS port number.

Steps to Replicate: The steps cannot be reproduced.

Platform/Feature: SBC: Call Control

The code is modified to use the TLS port number when relaying the SIP NOTIFY messages.
33SBX-599082

When the SBC receives route header with a port and TLS, it increments the port number.

Impact: When the SBC receives route header with a port and TLS, it increments the port number.

Root Cause: The SipSgPopulateAndSendToEgress() incorrectly increments the TLS signaling port number, when an out-of-dialog SIP OPTIONS message being relayed contains a "transport=TLS" parameter in the top most ROUTE header, and TLS transport is used.

Steps to Replicate: When the SBC receives OPTIONS with the Route header, the SBC relays that OPTIONS to a Port+1.

Platform/Feature: SBC: SIP

The code is modified to prevent incorrectly incrementing the TLS signaling port number, when an out-of-dialog SIP OPTIONS message being relayed contains a "transport=TLS" parameter in the top most ROUTE header, and TLS transport is used.
34SBX-958102

The PrsP cored on the standby SBC node.

Impact: The standby PRS process core was triggered from the XRM, when processing the XRM_DEALLOCATE_CMD_MSG from the standby SIPFE before the XRM has received the RTM_SYNC_TO_ACT_START_NFY_MSG.

Root Cause: There were many registration bind timeouts reported on the active SIPFE that triggered deallocation of the registration blocks and closing of port range connections. An active SIPFE mirrored the port range connection close requests to the standby SIPFE that triggered XRM_DEALLOCATE_CMD_MSG being sent to the standby XRM. The bug was that active SIPFE used regular ICM alloc/send mechanism to send the redundancy requests while standby node was in the middle of sync to active node.

Steps to Replicate:

  1. HA pair, SIP registration load test, with high number of registrations.
  2. Cause registration binding timeouts.
  3. Restart the standby node.

Platform/Feature: SBC

Replace the regular ICM alloc/send with an RTM alloc/send in SIPFE when mirroring the port range connection close request to the standby node. The RTM then delivers the request to standby SIPFE properly based on the RTM sync state.
35SBX-958953

The 4 SCMs cored after switchover.

Impact: The SCMs have cored after a switchover.

Root Cause: There is a bug that allows the RTM to attempt to process the Call Audit fault while still in the STANDBY mode. Since the Call Audit fault must only be processed while in the Active Mode - this causes a core.

Steps to Replicate: The steps cannot be reproduced.

Platform/Feature: SBC

The code is modified to prevent the RTM from processing the Call Audit fault while in the STANDBY mode.
36SBX-93067 / SBX-749222

Portfix SBX-74922: Modem calls failing when the DSP engaged in the ingress SBC.

Impact: The Bell 103 Modems in a G711-G711 transcoded call does not succeed.

Root Cause: The SBC G711-G711 transcoded calls perform a DTMF detection and the removal operation that can falsely remove some short signals, which is fine for speech perception but can affect modem signals that have similar characteristics of some modem signals. The SBC has signal detector for more modern modem that send a 2100 Hz tone to precede actual modem transmission. Once that is detected, the DSP media handling disables the DTMF removal. The SBC, however, does not detect older modems that sends a 2225 Hz signal in the beginning.

Steps to Replicate: 

  1. Make a G711-G711 forced transcoded call. Ensure that both legs have the DTMF remove enabled (dspchanstat).
  2. Use modem2225g711.pcap that has the modem signal captured from the customer in the ingress.
  3. Collect the media capture for the call and inspect the dspchanstat, as well as the output signal from egress.
  4. The dspchanstat and faxconfirmed field show 0x0. Signal output shows drops in the FSK modem signal between 18.72 and 19.65.

Platform/Feature: SBC

The code is modified to look for the 2225 Hz tone of at least 750 ms at which point, the DTMF remove feature is disabled. It is important to understand that this fix only applies to G711-G711 transcoded calls and not any compressed calls.
37SBX-960942

Port the fix for SBX-86420 to 6.2 and 7.2 code branch.

Impact: Whenever the TLS transport is selected, the SBC is trying to increment FQDN port by 1. In this case, even when FQDNPort is Zero in SIPSG/SIPS, the port is incremented by 1. So the FQDN port is set 1 because of this SRV query is not sent to the DNS server.

Root Cause: Whenever the TLS transport is selected, the SBC is trying to increment FQDN port by 1. In this case, even when FQDNPort is Zero in SIPSG/SIPS, the port is incremented by 1. So the FQDN port is set 1 because of this SRV query is not sent to the DNS server.

Steps to Replicate:

  1. Send an INVITE with the TGRP parameters in R-URI.
  2. The SBC sends the TGRP information to the PSX.
  3. The PSX does TGRP based routing and sends route.
  4. The SBC must send the SRV query to the DNS to resolve port and IP details when egress peer is FQDN.

Platform/Feature: SBC

In case of the TLS transport at egress, remote the fqdnPort is incremented by 1 only when the port received from the PSX other then zero. A check is added in sipsgSendFsmRmAlloc() function.
38SBX-96305 / SBX-961702

Portfix SBX-96170: When the SBC executes a "Teardown" to UPDATE request by the SMM, the To header and From header of response are malformed.

Impact: Write an SMM Rule to do a teardown on an UPDATE Request and Error Response has Malformed headers.

Root Cause: When a server request of UPDATE request is saved, optional headers are not being saved.

Steps to Replicate: Write a SMM rule to tear down update request with the 415 and the issue will be reproduced.

Platform/Feature: SBC

The code is modified to save the headers when saving an Update message as a server request.
39SBX-957062

The direct media (release) not working, no x-dmi to BSFT in the 200 OK while the 18x has it.

Impact: The 200OK behindNapt and direct Media support is unable to treat as direct media.

Root Cause: The issue is due to an internal offer/answer update after the first 18x, the previous flags for behind NAPT was lost.

Steps to Replicate:

  1. Ingress configuration behind Napt and direct Media support.
  2. Egress sends the SRTP Invite and peer response 18x with non-secure RTP. Subsequent 18x/2xx sent to ingress is missing x-dmi line.

Platform/Feature: SBC: Media, Platform, SIP

The code is modified to update the flags again when received in subsequent 18x/2xx.
40SBX-945462

To TAG broken when dialogTransp enabled and downStreamForking enabled.

Impact: When the dialog transparency, downstream forking and end to end PRACK is enabled, the SBC intermittently sends incorrect tagging in outgoing PRACK towards the egress.

Root Cause: A previous fix (SBX-63508) tries to address the scenario where downstream forking is enabled, dialog transparency is enabled and the 183 for the second dialog comes before PRACK when the first dialog is sent. But the pstCall structure was pointing to memory that may have been freed and re-used for storing some other SIP Message. So the To Tag sent from the SBC in an ACK message was incorrect.

Steps to Replicate:

  1. Enable Downstream forking, dialog transparency and E2E PRACK.
  2. Outgoing ACK from the SBC to egress has incorrect to Tag.

Platform/Feature: SBC: SIP

The code is modified to ensure to tag in the ACK message sent from the SBC is correct.
41SBX-96802 / SBX-964482

Portfix SBX-96448: ICE not getting completed when the simultaneous ringing is enabled.

Impact: When simultaneous ringing is enabled to multiple MS teams endpoints, in certain cases where the ICE STUN requests are received by the 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 through the SBC.

Root Cause: The SBC answers the first STUN message with a 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 the SBC to MS teams and verify that irrespective of when the endpoint answers the call voice media can flow through the SBC. Test must be repeated around 10 times and call answered from a different end point each time.

Platform/Feature: SBC

The code is modified so that after receiving a SDP with the ICE ufrag in signaling message. The SBC only completes ICE learning against the stun requests that have the same remote ufrag as that received in the SDP.
42SBX-96817 / SBX-951702

Portfix SBX-95170: To allow early RTP ICE learning for the MS teams DLRBT media bypass scenarios.

Impact: In a media bypass call flow with the 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 a useCandidate = 1 because it did not get 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 not responding to STUNs until an answer SDP is 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, enable the ICE learning and respond to STUNs on the RTP port.
43SBX-945792

Upgrade set all the CNAM Trunks to a Subscribe Rate of 1.

Impact: When the LSWU upgrade is completed, 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 the values were not set).

Steps to Replicate:

Configure SIP Trunk Group CAC ingress/egress subscribeRateMax and subscribeBurstMax, for example:
% set addressContext default zone ZONE sipTrunkGroup SIPTRUNK cac ingress callRateMax 1 callBurstMax 1 registerRateMax 1 registerBurstMax 1 callLimit 0 emergencyOversubscription 0 extendedEmergencyIpLimit 0 subscribeRateMax 10 subscribeBurstMax 20 otherReqRateMax unlimited otherReqBurstMax unlimited hpcOversubscription 0
% commit
% set addressContext default zone ZONE sipTrunkGroup SIPTRUNK cac egress callRateMax 1 callBurstMax 1 registerRateMax 1 registerBurstMax 1 callLimit 0 emergencyOversubscription 0 extendedEmergencyIpLimit 0 subscribeRateMax 10 subscribeBurstMax 20 otherReqRateMax unlimited otherReqBurstMax unlimited hpcOversubscription 0

Perform an LSWU upgrade.

See 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.
44SBX-96856 / SBX-921172

After an upgrade, the SWAP partition has a wrong UUID.

Impact: The file /etc/fstab had an incorrect UUID for SWAP partition due to the timeout logs were seen on the boot-up.

Root Cause: As part of multiple upgrades going through different versions, the SWAP partition UUID has somehow been changed but the same is not reflected in fstab file.

Steps to Replicate: Install/upgrade to fix version and ensure there is no swap entry in fstab file and also there is no timeout logs.

Platform/Feature: SBC

The code is modified to remove the SWAP entry from the /etc/fstab file as there is not SWAP enabled on the SBC. So, after installing/upgrading to the fix version, there is no timeout logs.
45SBX-737193

The SMM writeCdr was failing to write to ATTEMPT CDR when acting upon 300 Multiple Choice.

Impact: The SBC is failing to write the SMM fields in the ATTEMPT CDR when acting upon the 300 Multiple Choice.

Root Cause: The code was missing to handle the SMM information for a Redirect Scenario in the CDR.

Steps to Replicate: Test Redirect cases, and ensure SMM CDR write operation is successful in ATTEMPT record.

Platform/Feature: SBC

The code is modified to write the SMM information in the CDR for a Redirect Scenario.
46SBX-96691 / SBX-946622

Portfix SBX-94662: The SBC is unable to handle emergency calls (E911) when ICE is enabled.

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: An issue in 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 via 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 via the trunk group and verify the call succeeds.

Platform/Feature: SBC: Media, SIP

The code is modified to process the ICE data correctly when a call is transitioning to using emergency bandwidth.
47SBX-96770 / SBX-967232

Portfix SBX-96723: The Zone SMM Profile was not working when performing a sbxrestart/reboot.

Impact: The Zone SMM is not getting applied when performing a SBC restart.

Root Cause: The Zone SMM profile is not being restored during an SBC restart.

Steps to Replicate: Attach a Zone Profile with the fixed order, and run a call. The Zone SMM profile will be applied, and when performing a  SBC restart and running the call, the Zone SMM is not getting applied.

Platform/Feature: SBC

The code is modified to restore the Zone SMM Profile during an SBC restart.
48SBX-97194 / SBX-969372

Portfix SBX-96937: Running the sysDump.pl on Openstack restarts the SBC.

Impact: Running the sysDump.pl on the 8.2.0R0 release on the SBC Openstack cloud platforms causes the SBC application to restart.

Root Cause: The openclovis is monitoring some files as markers, using notify and taking it down when the file open operations are done.

Steps to Replicate: Once the SBC application is up and running:

  1. Run sysDump.pl and enter the default inputs.
  2. The SBC application will not go down.

Platform/Feature: SBC

As part of sysdump, backing up of /opt/sonus/sbx/openclovis/var/run/notify directory is excluded.
49SBX-96945 / SBX-96939 2

Portfix SBX-96939: The ImPr cored when the SBC was running a call load.

Impact: The SBC ImProcess cored when the LI server became unavailable.

Root Cause: When the LI server becomes unavailable and a large number of packets are queued up for that server, the ImProcess takes more than 10 seconds to clean up all those packets, and the process coredumps.

Steps to Replicate:

  1. Establish a large number of LI calls.
  2. Bring the LI server down.
  3. Ensure that the ImProcess does not coredump.

Platform/Feature: SBC

The code is modified to disable the healthcheck while cleaning up the packets.
50SBX-951762

7k DSP falsely detecting fax tone on music.

Impact: SBC falsely detects a modem tone (2100 Hz with phase reversals) for certain type of music.

Root Cause: Algorithm for modem tone detection first looks for 2100 Hz tone for 630 ms and a non-zero number of phase reversals. In certain type of rich harmonic tones, this results in large number of phase reversals. Typically for modem tones we expect no more than 2 phase reversals in 630 ms.

Steps to Replicate: Make g729 to g711 calls and stream the pcmu_stream1_withsilence3.pcap from the g711 leg.
Before a fix, a modem is detected on this signal as indicated in the dspchanstat.
tone2100PhaseRevCnt: 1.

Platform/Feature: SBC: DSP

Modem tone detection algorithm is modified so that in case it finds a modem tone for 630 ms, in case number of phase reversals is larger than 3, its rejected as a spurious detection.
51SBX-946982

The SBC does not send invite to subsequent routes in native forking when the SBC receives Invite with call-ID as "i".

Impact: An incoming short callId header "i" fails to send subsequent Invite for multi routes.

Root Cause: There was missing logic to look for callId header with a short name.

Steps to Replicate: Configure the native forking call and have incoming call with short name "i' for callId header.

Platform/Feature: SBC

The code is modified to support short header name callId.
52SBX-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 sending 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.

53SBX-968342

Asymmetric PRACK Interworking was not working as described.

Impact: Whenever any codec entry is deleted from codec list in the PSP and in the PSX, it rearranges the codec list immediately. There will not be any empty codec entry in the list.

The same issue is in the ERE, so it can be treated as a bug in the ERE.

Root Cause: When any CodecEntry is deleted, it is not rearranging the CodecEntry, which causes a NULL value in that place.

Steps to Replicate:

1. Configure the CodecEntry1 ,CodecEntry2 to CodecEntry12
2. Delete any CodecEntry.

Result: The call will be successful.

Platform/Feature: SBC: ERE

The code is modified so that there is no NULL value in between the two CodecEntry's.
54SBX-933293

Update scripts in the common/debian/install/sbx-install and orca/install.

Impact: Monit paths needed to be updated with the new definitions.

Root Cause: New definitions were introduced for monit paths.

Steps to Replicate: The steps cannot be replicated.

Platform/Feature: SBC

Updated the monit paths to resolve this issue.
55SBX-954742

The LCA errors seen when the SBC is spawned.

Impact: A sbcDiagnostic.sh flags error in the LCA, because it greps for ERROR.

Root Cause: The keyKeeper.py prints in the lca.log ERROR whenever it is unable to delete a file that contains a pswd. The file may already be deleted or not even created, this may also throw error.

Steps to Replicate: Run the sbcDiagonostic.sh and check no errors are present from keyKeeper.py.

Platform/Feature: SBC

The code is modified so the parameters sonusUtils.logger.error changes to sonusUtils.logger.info and some other logs so there is no grep ERROR.
56SBX-96952 / SBX-964712

Portfix SBX-96471: While trying to become active on a switchover, the systrem rebooted since the DRBD could not be switched to the primary.

Impact: While trying to become active on a switchover, the systrem rebooted since the DRBD could not be switched to the primary.

Root Cause: The DRBD is configured so that whenever a low level error occurs, the DRBD will be detached and the dstate will become "diskless". This scenario was leading the standby for reboot.

Steps to Replicate:

  1. Run "drbdadm detach mirror" on standby.
  2. Perform a switchover.
  3. The switchover will be successful.

Platform/Feature: SBC

While coming up as active after a switchover, the dstate of DRBD is checked, and if it is "diskless" the DRBD is attached before proceeding further.
57SBX-97545 / SBX-700593

Portfix SBX-70059: Support the HOLD/RESUME INVITE from the SIPREC SRS to pause and start pumping media towards the SRS.

Impact: With a second SIPREC server call hold, the RTP recording is not paused/stopped towards recording server.

Root Cause: With the RTCP snoop enabled, the NP API handler has an issue in handling the media snoop configuration update with a SIPREC hold.

Steps to Replicate: Test the SIPREC hold features with the RTCP snoop enabled.

Platform/Feature: SBC

The code is modified for the NP API handler to resolve this issue.
58SBX-94935 / SBX-908553

Portfix SBX-90855: The ASAN has a new-delete-type-mismatch on the SrchCriteriaIb.

Impact: The ASAN has a new-delete-type-mismatch on the SrchCriteriaIb.

Root Cause: The srchCriteriaIbArray is a dynamically allocated array in the GUISERVER, but it was not released using delete, so it is reported by ASAN.

Steps to Replicate: Re-run the testcase in the ASAN build and verify that the issue is not reported again.

Platform/Feature: SBC

The code is modified to fix the issue.
59SBX-873993

The IPACL causes a PRS deadlock.

Impact: The PRS process may coredump after the state disabling and enabling ACL rule(s), performing a switchover by powering the CE off immediately, and state disabling and enabling ACL rule(s).

Root Cause: The PRS used stale socket connections after the power off immediate switchover.

Steps to Replicate: Reproduce the PRS coredump issue by performing the following:

  1. Create the ACL rule using the installed role active CE when the HA system is synchronized (full redundancy protection).
  2. Perform a switchover to the installed roll standby CE.
  3. Wait until the HA becomes synchronized (full redundancy protection).
  4. Using EMA to installed roll standby CE:
    Disable the ACL rule
    Enable the ACL rule
    Disable the ACL rule
    Enable the ACL rule
  5. Verify that the system is synchronized.
  6. Power off the installed roll standby CE "Power Off Server - Immediate" using the BMC.
  7. Using EMA to installed roll active CE:
    Disable the ACL rule
    Enable the ACL rule <--- PRS CORED

Platform/Feature: SBC

The code is modified to re-open the connection to ConfD (on the immediate power off of the Active system), to prevent a PRS health check timeout coredump.
60SBX-944862

The SBC was not releasing the other leg when a call is disconnected during hold( MOH enabled).

Impact: The SBC was not releasing the other leg when a call is disconnected during hold( MOH enabled).

Root Cause: This is a race condition in the CC where the handler for the event ASG_DISC_CMD is not present, and for the CC state CC_VIRT_ESCR_VDREQ due the call being hung.

Steps to Replicate:

  1. Make a TEAMS to PSTN call.
  2. TEAMS holds the call (MOH).
  3. TEAMS disconnects the call during MOH.

Platform/Feature: SBC

Added a handler for the event ASG_DISC_CMD for the CC state CC_VIRT_ESCR_VDREQ, so that the DISC cmd gets propagated to the other active peer call side and the call gets terminated correctly.
61SBX-96178 / SBX-945622

Portfix SBX-94562: The ASAN has a heap-buffer-overflow in the SipSgACDMNaptQualTblAddEntry.

Impact: There was a Heap Buffer Overflow in the function SipSgACDMNaptQualTblAddEntry().

Root Cause: The Memcpy is being used instead of StrnCpyZ().

Steps to Replicate: Run the PCR 5637 regression on an ASAN Build.

Platform/Feature: SBC

The MemCpy is replaced by the StrnCpyZ().
62SBX-96180 / SBX-944022

Portfix SBX-94402: The SBC was not throwing a parse error in TLS if the content-length is not sent in a PRACK message.

Impact: The SBC is not throwing a parse error when the content-length Header is not sent in PRACK request using the TLS transport.

Root Cause: Similar code is present in the TCP Transport but not in the TLS-TCP transport.

Steps to Replicate: 

  1. Make a TLS call with the 100rel enabled.
  2. Send PRACK without content-length header for 18x.

Platform/Feature: SBC

The code is modified for the TLS-TCP Transport to resolve the issue.
63SBX-95118 / SBX-944032

Portfix SBX-94403: Unable to establish the same number of sessions after the switchover.

Impact: Calls were getting cleared under load conditions after a switchover in the first gateway in a GW-GW setup.

Root Cause: When the sessionKeepAlive is set and when the SBC switched over, the SBC starts sending refresh INVITEs to the endpoints. Since this is a GW-GW setup, a newly active GW-1 will send call processing messages to the GW-2. There was an issue in call processing at GW-2 that resulted in call failures.

Steps to Replicate:

  1. Create a SBC GW-GW setup and enable the sessionKeepAlive,
  2. Establish a call load of more than 25K and once call is stable, perform a switchover at the GW-1.
  3. Calls now start failing.

Platform/Feature: SBC

The code is modified to now take care of processing multiple segments and to successfully establish a GW-GW connection.
64SBX-94782 / SBX-943892

Portfix SBX-94389: When call transferring to the PSTN, the SBC was sending RTP/AVP instead of RTP/SAVP towards Teams in the ReINVITE.

Impact: The SBC was sending a Re-INVITE towards Teams with m= line protocol as RTP/AVP instead of RTP/SAVP. Because of this, Teams is sending a 488 call was failed.

Root Cause: After an abort_ann_tone event, the CC was not moving to cutthru mode.

Steps to Replicate:

  1. The 'Announcement based tones' flag is enabled.
  2. Make a call from the PSTN - Teams n/w.
  3. After a call connect, a Teams user transfers the call to another Teams user, and the call will succeed.

Platform/Feature: SBC

During an inbandtones event triggered in the CC, when an abort_ann_tone event returns and if the cutthru is already received, set the cutthru to cutthru_pending.
65SBX-973162

The Scm Process coredumps when there is NO ROUTE from the PSX = 0.

Impact: The Scm process coredumps when there is a call clearing with "no route found" from the PSX/ERE.

Root Cause: There was a bug in the call disconnect handler that resulted in the Scm crash for a non-configured number.

Steps to Replicate: Run a basic SIP call with a non-configured number and the Scm Process must not crash while handling the disconnect.

Platform/Feature: SBC: Application

The code is modified to handle call disconnects with 'no routes found' in the PSX/ERE without a Scm Process crash.
66SBX-863742

The early media PEM has a behavior issue if there is no PEM in 18x.

Impact: When the egress TG early media method is P Early Media and the P Early Media header is not received, the SBC does not send media to the ingress caller.

Root Cause: The audio data path mode is set to inactive for the PEM structure.

Steps to Replicate: 

1. PEM Header transparency is enabled and the egress TG configuration is listed below:

set addressContext default zone IPX_SIGNALING_VOLTE sipTrunkGroup 1009074301 media earlyMedia method pEarlyMedia
set addressContext default zone IPX_SIGNALING_VOLTE sipTrunkGroup 1009074301 media earlyMedia egressSupport enabled
set addressContext default zone IPX_SIGNALING_VOLTE sipTrunkGroup 1009074301 media earlyMedia defaultGatingMethod sendrecv
set addressContext default zone IPX_SIGNALING_VOLTE sipTrunkGroup 1009074301 media earlyMedia forkingBehaviour firstProvResponse

Call Flow: The 183 Session Progress from the egress contains SDP and no PEM header.
Issue: The SBC does not send media from egress to ingress and the caller receives dead air.

Platform/Feature: SBC

The code is modified to ensure the audio data path mode is set to default gating mode.
67SBX-99097 / SBX-943242

Portfix SBX-94324: In the SBC to GW to SBC scenario, the first SBC coredumps when the ingress invite contains four identity headers.

Impact: Making a GW-GW call that contains multiple identity headers will cause a crash.

Root Cause: There was a validation code to check that the internal CPC structures that carries the identity header information was correctly padded to a 4 byte alignment. This validation code was correct for one identity header but failed when more than one was present and as a result, triggered the system to crash.

Steps to Replicate: Send in an INVITE that contains two identity headers of type SHAKEN and route the call over a GW-GW connection to a second SBC.

Platform/Feature: SBC

The code is modified to ignore any padding rules for the particular internal CPC structures that carry the identity header information.
68SBX-98387 / SBX-983562

Portfix SBX-98356: There was a SEGV on an unknown address 0x0000000000e5 (pc 0x5653a715fdde bp 0x7f84a52bfea0 sp 0x7f84a52bfe70 T9).

Impact: After a successful surrogate registration, if any configuration related to the IP Peers/TGs/Surrogate registration is deleted, the Scm Process will coredump.

Root Cause: The code was dereferencing a null pointer when the trunk group configuration data was no longer present and the surrogate registration response came back.

Steps to Replicate: Trigger the SBC to send out surrogate registration request and delete all the associated trunk group configurations before sending back a response from the remote server.

Platform/Feature: SBC

The code is modified to check that the trunk group configuration exists before trying to read the configuration.
69SBX-956792

The trunks data cannot be displayed on the live monitor.

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

Root Cause: The Elastic Search interprets 'hypen' as a delimiter and as a result, the string is broken down into tokens for indexing. When a query is put in the ElasticSearch for data with trunkgroup name containing 'hyphen', no data is retrieved as the Elastic Search has stored the data not with the actual trunkgroup name but with tokens

Steps to Replicate: 

1. Create a trunkgroup with name containing hyphen.
2. Enable the Live Monitor.
3. Run Calls and wait for sometime.
4. Verify data is shown in Zone and Trunk Group based charts.

Platform/Feature: SBC

Before querying the ElasticSearch for data, check if trunkgroup name contains hyphen, if it does then it is broken into tokens and the token is used to query for data.
70SBX-978302

The ipRecMetadataProfile does not work for the request-uri in the V07.02.02.

Impact: INVITE SIPREC or SIPREC INVITE may not have a request-uri beta or core.

Root Cause: The logical error that 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.
71SBX-960282

The MAINTAIN ONLY CDR .ACT file extension during atomic write process was not utilizing the .TMP.

Impact: When the CDR files are copied to the remote server, the file is copied with a temporary extension .TMP. For some installations, the software running on the remote server moves those files with the .TMP extension before the SBC software renames them with an .ACT extension.

Root Cause: A temporary extension is used during the time files are copied to the remote server.

Steps to Replicate: Perform the following step:

  1. Unhide debug
  2. Set OAM accounting cdrServer admin primary useFilePostfix disable
  3. Transfer a large file.

Note that the file that is being uploaded to the remote server has an ACT extension while it is being transferred.

Platform/Feature: SBC

A new option is added to fix the issue:

  1. Unhide debug
  2. Set oam accounting cdrServer admin primary useFilePostfix disable

By default, the useFilePostfix is set to enabled.

When set to disable, a temporary extension is not used when copying the file to the remote server.

72SBX-976173

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 dereference 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 dereferencing it.
73SBX-978002

The PrsP cored on both the active and standby nodes at the same time.

Impact: The PRS process cored due to accessing a non accessible memory location while processing the MONSEC response from NP.

Root Cause: Based on the core analysis, the core dump was caused by an invalid MONSEC response from NP. There were many read media stats commands sent to NP at the same time with the MONSEC request. The response that was processing appeared like a valid PNPS_NP_RSP_RD_MEDIA_FLOW_STR response.Due to this observation, there may be some timing issue that sent media flow stat response to MONSEC.

Steps to Replicate: The steps cannot be reproduced.

Platform/Feature: SBC

The code is modified to check that npPoolId and numSecIds are in the defined range.
74SBX-978512

The SBC adds a media IP address in the outgoing SDP although the call is a direct media call.

Impact: When a direct media is enabled when handling the re-INVITE from ingress endpoint without a 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 the direct media is enabled, while handling a re-INVITE relay transaction, the SBC does not update the SIPStack SDP correctly.

Steps to Replicate: 

Configure for Direct media and enable the e2e Re-Invite.

  1. Send an Invite from A to B.


  2. B sends a re-Invite to A.


  3. A sends a re-Invite to B with SDP of 200 OK that is sent for previous re-Invite

Platform/Feature: SBC

The code is modified to ensure the SBC updates the SIPstack SDP for direct media scenarios.
75SBX-980983

All call registrations were failing on the SJ SBC7K.

Impact: RFC-5626 PING/PONG traffic may cause severe CPU utilization issues in the SBC.

Root Cause: RFC-5626 PING/PONG traffic was sent from the SAM process to the SCM process and back.

Steps to Replicate: Send a lot of RFC-5626 PING/PONG traffic.

Platform/Feature: SBC: Call Control

The code is modified to fast-path RFC-5626 PING/PONG traffic.
76SBX-969532

Investigate a PATHCHECK Process coredump.

Impact: The Pathcheck process may coredump (due to healthcheck timeout) when the zone tracerouteSigPort is enabled, and when the traceroute takes longer than 45 seconds to complete (after the endpoint becomes BLACKLISTED).

Root Cause: The Pathcheck process coredumps due to a healthcheck timeout when the traceroute to the BLACkLISTED endpoint takes longer that 45 seconds to complete.

Steps to Replicate: Enable the zone tracerouteSigPort, and configure an ipPeer in that zone that will become BLACKLISTED, and the traceroute to that ipPeer takes minutes to complete.

Platform/Feature: SBC

The code is modified to handle slower/longer traceroute completions.
77SBX-954753

A double SCM core resulted in an outage.

Impact: A double SCM core resulted in an outage.

Root Cause: While building the outgoing IAD message, there might be a case where the null values for a request message result in incomplete From and To headers, and cause a crash as a result.

Steps to Replicate: The steps cannot be reproduced.

Platform/Feature: SBC

The code is modified to avoid a coredump in cases where there are NULL values for a Request Message.
78SBX-98198 / SBX-979162

The STI and Privacy interactions are incorrect.

Impact: When the STIR/SHAKEN is enabled, a default privacy behavior was not given preference when the Privacy header is present in the ingress INVITE as follows:

  1. The STIR/SHAKEN is generating PAI/Privacy:id headers for all services when the PSX IPSP, SIP HTP, or PrivacyProfile->passThruPrivacyInfo is not configured to send the PAI header out. “Add verstat to PAI” flag is set, the SBC was generating the PAI/Privacy: id to add the verstat to PAI when no PSX IPSP, SIP HTP, or PrivacyProfile->passThruPrivacyInfo is configured to send the PAI header out.
  2. The PrivacyParamRestricted configuration must have preference over STI service. The PrivacyParamRestricted->default must anonymize the From and Contact headers when Privacy: user,id,header,or uri is present in the ingress INVITE even when STI is enabled.
  3. The PrivacyProfile configuration should be given preference over STI, when a privacy profile is configured to “applyPrivacyId/supportPrivacyId” and STI should not generate PAI/Privacy: id for any service.
  4. The STIR/SHAKEN is removing the “Privacy: User” header from the egress signal after anonymizing From and Contact header, when the IPSP Privacy->Transparency is enabled and Privacy: User header is present in the ingress INVITE.
  5. Anonymization format should be based on Privacy->Privacy Information and variantType.

Root Cause: 

  1. After the verification service, the verstat should either be added to the PAI or the From header. The “Add verstat to PAI” needs enhancement to enable adding the verstat to From if the PAI is not present in the egress signal.
  2. The PrivacyParamRestricted->default behavior anonymizes the From and Contact headers when Privacy: user, id, header, or uri is present in the ingress INVITE. The STI was not giving preference to PrivacyParamRestricted->default anonymization behavior for the privacy: id.
  3. The PrivacyProfile configuration was not given preference when the “applyPrivacyId/supportPrivacyId” is enabled, and the STI was generating PAI/Privacy: id headers.
  4. The SBC will not remove privacy: user after just anonymizing the From and Contact header and let the downstream switch(es) perform further anonymization.
  5. A preference was not given to Privacy information and variantType while determining the anonymization format.

Steps to Replicate: Configuration:

  1. Configure the STI profile on the SBC and attach the profile on to both the ingress and egress TG.
  2. Configure the STI profile for Signing/Tagging/Verification service on the PSX.

Observations:

  1. When no PSX IPSP->Privacy, SIP HTP, or PrivacyProfile->passThruPrivacyInfo configuration is enabled and the From is anonymized in the egress INVITE, PAI/Privacy header is generated.
  2. The Ingress TG->Signalling->PrivacyParamRestricted->default is configured. Observed that “From” and contact headers are not anonymized, if the privacy: id is present in the ingress INVITE.
  3. When no PSX IPSP->Privacy, SIP HTP, or PrivacyProfile->passThruPrivacyInfo configuration is enabled and privacyProfile configuration is:
    • The PrivacyProfile is configured with the “applyPrivacyId” flag enabled. The PAI/Privacy header is generated when the Privacy: id is present in the ingress INVITE.
    • The PrivacyProfile is configured with the “supportPrivacyId” flag enabled. The PAI/Privacy header is generated.
    (Note: The PrivacyProfile behaviour without any STIR/SHAKEN interactions. When PrivacyProfile is configured to “applyPrivacyId” and attached to the ingress TG or when the “supportPrivacyId” is configured in egress TG, the SBC will remove PAI headers from egress INVITE when the Privacy:id header is received in the invite. When the privacyProfile with the “supportPrivacyId” is configured in the egress TG, the SBC will remove PAI headers from egress INVITE, irrespective of the Privacy header.)
  4. The “Privacy: User” header is not present in the egress signal, when the IPSP Privacy->Transparency, SIP HTP or PrivacyProfile->passThruPrivacyInfo is enabled and the Privacy: User header is present in the ingress INVITE.
  5. The From and contact headers has “Anonymous@Anonymous.invalid” as opposed to "Anonymous” <sip:Restricted>. If the privacy: user header is present in the INVITE and when IPSP->Privacy->Privacy Information is P-Preferred-Id or Remote-Info Party.

Platform/Feature: SBC

When the STI is enabled, the Privacy behavior is given preference over STI, which effectively means no changes in privacy behavior.
  1. The STIR/SHAKEN does not generate the PAI/Privacy: id headers for any services when no control is set to send the PAI headers out(no PSX IPSP, SIP HTP or PrivacyProfile->passThruPrivacyInfo configured), one of the mentioned control must be set for the PAI header to go out. The “Add verstat to PAI” Flag is changed to the “Prefer PAI”, to enable sending verstat in From if PAI is not present in the egress INVITE.
  2. The PrivacyParamRestricted->default anonymizes the From and Contact headers when the Privacy: user,id,header,or uri is present in the ingress INVITE. The PrivacyParamRestricted->default anonymization behaviour for privacy: id is retained even when the STI is enabled.
  3. The PrivacyProfile is given preference over the STI service.
  4. The SBC is not removing the “Privacy: User” header after anonymizing the From and Contact header as part of STIR/SHAKEN service, when the IPSP Privacy->Transparency is enabled and Privacy: User header is present in the ingress INVITE. This enables the downstream switch(es) to perform further anonymization.
  5. The format of anonymized From and Contact headers when IPSP->Privacy->Privacy Information is P-Preferred-Id or Remote-Party-ID is retained even when the STI profile is enabled. The example below is for variantType,
From: "Anonymous" <sip:Restricted@example.com>;tag=gK08000282
Contact: "Anonymous" sip:Restricted@example.com:5060
Format of anonymized From and Contact headers when STI profile is enabled, when IPSP->Privacy set to P-Asserted-ID is as follows,
From: "Anonymous" <sip:Anonymous@Anonymous.invalid>;tag=gK080004bb
Contact: "Anonymous" sip:Anonymous@10.54.46.45:5060
79SBX-98566 / SBX-945132

Portfix SBX-94513: The Antitrombone will not have a kickstart but undesired pattern "PCR7400 Direct Media Antitrombone Call" is found in the dbg.

Impact: For a direct media call using X-dmi, the SBC is not preferring X-dmi over anti trombone direct media. This could cause one way or two way audio issue.

Root Cause: The SBC selects the Antitrombone direct media instead of X-dmi.

Steps to Replicate: 

  1. Run a basic XDMI DM call
  2. Run a basic DM with NAT call with XDMI
  3. Run a basic Antitrombone call with XDMI enabled

Platform/Feature: SBC

The code is modified to ensure the X-dmi is preferred over anti trombone
80SBX-98598 / SBX-969512

Portfix SBX-96951: Unable to write to the CDR in the ATTEMPT record due to 3xx.

Impact: Run a redirect scenario and write a SMM CDR operation on the 302 message. The CDR information is not populated in the attempt record.

Root Cause: The CDR information is not being updated to CC in this scenario.

Steps to Replicate: 

  1. Run a Redirect Scenario.
  2. Write a SMM CDR operation on the 302 message.

Platform/Feature: SBC

The code is modified to update the CC about the SMM CDR Information.
81SBX-95970 / SBX-937643

Portfix SBX-93764: The CAC handling is not working with the REFER and INVITE with replaces to 7.2.x.

Impact: In MS Teams call flows, they support music on hold service by default. The “on hold” feature was implemented by sending a REFER to the SBC so that the SBC then generates an INVITE out to the MS Teams music server and the B-leg is then released. The "off hold" feature was added to have the MS Teams phone replace the music on hold server call leg. Customer's are running with the CAC enabled in the lab and have call limit set to 10. Every time the SBC gets an INVITE with replaces, it reduces the CAC count on the ingress trunk group and then eventually fails.

Root Cause: The issue is that the Trunk Group and the Zone CAC are being performed for call pickup. Since CAC has already been performed for a call that is being picked up, a double count occurs that causes incorrect CAC failures.

Steps to Replicate: The steps cannot be reproduced.

Platform/Feature: SBC

The code is modified so the CAC is not performed for call pickup scenarios and for double counting all call licenses for call pickup.
82SBX-968583

A security patch drift for 7.2.4.

Impact: There are Nessus scan vulnerabilities.

Root Cause: There are Nessus scan vulnerabilities.

Steps to Replicate: Run a Nessus scan.

Platform/Feature: SBC

Update vulnerable packages to latest.
83SBX-93229 / SBX-871802

Portfix SBX-87180: Enable to trace with the TRC file SIP message outside the call, such as REGISTER and SUBSCRIBE.

Impact: Trace logs were not coming in the case of OOD when the trace level is set to 1 and the key is ipPeer

Root Cause: The current code does not send the TRC logs for OOD when the level is set to 1, and this option enabled now for OOD.

Steps to Replicate: Pre-Configuration:

-------------------------
admin@ELEANORSBX% show global callTrace | details
errorFilter {
errorType any;
}
maxTriggerCount 10;
callTraceTimer 111;
callFilter Naga {
state enabled;
level level1;
key peerIpAddress;
stopMatch unsupported;
match {
called "";
calling "";
contractor "";
redirecting "";
transferCapability unrestricted;
trunkGroup "";
peerIpAddress 10.54.81.11;
cddn "";
}
mediaPacketCapture disable;
}
signalingPacketCapture {
signalingPacketCaptureTimer 180;
state disable;
}
[ok][2019-04-19 14:44:24]

[edit]

In the configuration above, traces for all methods will be captured,

Platform/Feature: SBC

The code is modified to send the TRC logs when the level is set 1 and the key is ipPeer.
84SBX-986603

The heap-use-after-free in the DnsClientTcpMonitorDnsServerTimeout.

Impact: When using the DNS over the TCP, if there was a failure in reading from the TCP socket, the timeout processing was invoked for the outstanding DNS query and it was reading memory that has already been freed up.

Root Cause: This is an edge case error processing scenario where the pointers were being passed around internally and did not get updated to be null when the memory was freed.

Steps to Replicate: Issue was analysed based on a coredump and code review. The exact call scenario that caused the issue is unknown.

Platform/Feature: SBC

The code is modified to pass around the index values rather than the pointers and memory blocks being retrieved based on the index value that allows the code to verify if the associated memory block is free before accessing it.
85SBX-96686 / SBX-944862

Portfix SBX-94486: The SBC was not releasing the other leg when call was disconnected during hold( MOH enabled).

Impact: The SBC is not releasing the other leg when call is disconnected during hold( MOH enabled).

Root Cause: This is a race condition in CC where the handler for the event ASG_DISC_CMD is not present for the CC state CC_VIRT_ESCR_VDREQ and as a result, the call is hung.

Steps to Replicate: 

  1. Make a TEAMS to PSTN call.
  2. The TEAMS holds the call (MOH).
  3. The TEAMS disconnect the call during MOH.

Platform/Feature: SBC

The code is modified so that, the DISC cmd gets propagated to the other active peer call side and the call gets terminated correctly.
86SBX-945912

The CE_Node2 log fill up disk space causing a switch over.

Impact: The SYS ERRs from the CpcGenericCodecIsRfc3389Applicable() were filling up the SYS log and CE_logs quickly.

Root Cause: Based on the analysis of genCodecData in SCM core file and source code inspection, a bug was found in CpcGenCodecCriterionMatch() that could return an unpredictable value when all attributes are invalid in a specified criterion. In the SCM core, call control blocks were found in the SIPSG with the GSM audio encoding that has all attributes set to invalid in the criterion.

Steps to Replicate: The steps cannot be reproduced.

Platform/Feature: SBC

1. Fix the bug in the CpcGenCodecCriterionMatch().
2. Downgrade the debug message from the SipSgConvNsdMediaRawTransparencyToSdp() to the INFO level.
87SBX-979482

The SBC drops a request from egress to a registered user.

Impact: Non-Invite messages may drop if received immediately after a registration/Subscribe from the AS.

Root Cause: When a request was sent out to the server, internally, it creates a control block for handling the response. When a Peer sends a request back with the same callId, the SBC found the control block that is wrong and causing the SBC to drop.

Steps to Replicate: A register an to B, and the B send message back the SBC.

Platform/Feature: SBC

The code is modified to ensure the internal callId is unique so the incoming request can create a separate one.
88SBX-984012

A SIP-I Issue with HOLD for the SIP-I to SIP call.

Impact: The SIP-I body is not being sent out in a re-INVITE for HOLD.

Root Cause: The SIP subsystem is making a dip into the ISUP stack with wrong even type, that's why ISUP stack is not returning SIP-I body to be sent with.

Steps to Replicate: It is a complex scenario that is run into this situation when the re-INVITE for HOLD is to be sent out. It requires multiple offer/answers before the call is setup to end up in this situation. 

Platform/Feature: SBC: SIP Applications

If flag is set for PROGRESS and MID_CALL_INFO, the precedence is set to send the event as PROGRESS for dipping into the ISUP stack for ISUP body.


89SBX-96816 / SBX-958512

Portfix SBX-95851: The LeakSanitizer detected memory leaks in the DiamCsvAddPeer.

Impact: Unable to resolve the SRV fqdn for a diameter peer. Without this fix, the diameter connection cannot be established towards the diameter peer.

Root Cause: The wrong domain name is attached to diameter peer when a peer is created with the SRV domain fqdn internally in code.

Steps to Replicate: Create a  diameter peer with SRV fqdn.

Platform/Feature: SBC

Removed attaching the wrong domain name to the diameter peer when the SRV based FQDN is configured for a diameter peer.
90SBX-96754 / SBX-946193

Portfix SBX-94619: The intel microcode bundle is not the latest version.

Impact: There are vulnerabilities in hardware.

Root Cause: The CPU microcode is outdated.

Steps to Replicate: Run the Spectra-melt-down script on a host and check vulnerabilities.

Platform/Feature: SBC

The code is modified to reflect the latest version.

Resolved Issues in 07.02.03R000 Release 

The following Severity 1 issues are resolved in this release:


Resolved Issues


Issue IDSevProblem DescriptionResolution
1SBX-917231

Observing the CLI port SWO in the M-SBC is causing the MGMT link to go down.

Impact: On the CLI port, a switchover on packet interface has random connectivity loss for few seconds on other interfaces.

Root Cause: A bug in SWe_NP code was picking the incorrect NIF control blocks for standby ports causing intermittent signalling packet loss and a loss of ICMP packets resulting in connectivity failures. This happens specifically on high call loads, when workers are at 80% capacity.

Steps to Replicate:

  1. Bring up setup with port redundancy and perform multiple CLI switch over.
  2. Observe the link status of various ports.

Platform/Feature: SBC

The code is modified to correct NIF control blocks are chosen for standby ports.
2SBX-912731

The EMA receives a Proxy error whenever an operation takes a long time to complete.

Impact: When the user navigates to a SIP trunk group or DM PM rule creation screen, there is no response from the UI and after approximately a 2 minute interval, "Proxy error" is shown to the user.

Root Cause: The EMA reads the DM PM Rule, DM PM Sub Rule and DM PM Criteria data from the CDB through the Netconf interface. With a large amount of data, there is a significant delay in rendering the UI. The request from the browser times out, resulting in a Proxy Error to the user.

Steps to Replicate:

1. Configure more than 25,000 DM PM Criterias and more than 25,000 DM PM Rules.
2. Navigate to a SiP Trunk Group Creation Screen or DM PM Rule creation screen.
3. The create screen does not load and after some time results in Proxy error.

Platform/Feature: SBC

Instead of a CDB, the EMA reads the data for DM PM Rule, DM PM Sub Rule and DM PM Criteria directly from the Oracle Database, reducing the delay to a larger extent in rendering the UI.

When the Copy Trunk Group operation is performed, it can take up to 3 minutes to complete the copy operations. The 3 minute delay is due to the EMA performing some additional operation compared to new TG creation.

3SBX-91744 / SBX-914811

Portfix SBX-91481: The SamP cored. (Originated in release 6.2.4)

Impact: Under certain conditions, the SBC sends out a duplicate OPEN_ACK, causing the receiving GW to crash.

Root Cause: A bug in the GW Signaling code can cause a duplicate OPEN_ACKS to send when GW Signaling Links are bouncing.

Steps to Replicate: This problem is not reproducible.

Platform/Feature: SBC

The code is modified to only send out one OPEN_ACK per tcp/ip connection.
4SBX-91726 / SBX-878611

Portfix SBX-87861: While performing a port switchover, the SBC active performed a reboot and the Standby did not takeover the calls. (Originated in release 8.1.0)

Impact: An SWe_NP thread hang was observed on a packet port pull out.

Root Cause: A cable pull was calling a reset on an interface that may take more than 5s on a thread health check threshold, causing the thread to lock on reset.

Steps to Replicate:

  1. Bring up setup in port redundancy setup.
  2. Cable pull packet interface to trigger port switchover.

Platform/Feature: SBC

The code is modified to adjust the thread health check mechanism on a port reset.
5SBX-908771

Failover from Node-A to Node-B.

Impact: Healthcheck failure while switching from nodeA to nodeB.

Root Cause: Functions that configure the DRBD subsystem are taking longer and causing a health check timeout.

Steps to Replicate: Switchover from Active to standby.

Platform/Feature: SBC

The code is modified to run DRBD setup commands in the background and unblock the caller immediately.
6SBX-92274 / SBX-913321

The ipPeerCurrentStatistics and ipPeerIntervalStatistics are not working.

Impact: Getting the IP peer current statistics for individual IP peers was not working. The issue is reproduced when multiple IP peers are configured under the same zone.

Root Cause: Multiple IP Peers must be configured under same zone to reproduce this issue. When obtaining specific peer statistics, the peer name comparison within the same zone was missing.

Steps to Replicate: Configure multiple IP Peers under the same zone and then execute the command to obtain IP Peer Current/Interval statistics for a specific peer.

Platform/Feature: SBC

The code is modified by adding the comparison for IP peer specified in the CLI against the IP peer statistics list with other existing validations.
7SBX-91725 / SBX-909471

Portfix SBX-90947: The NP process core dumped while running a load on the HA setup.

Impact: A random SWe_NP crash occurs on a standby node while running a transcoded load.

Root Cause: RTCP resources are not managed properly by application layer on standby node. This causes a restart of already running timers on the SWe that causes a race and random crash.

Steps to Replicate:

  1. Run a large number of transcoded calls, on HA pair.
  2. Perform multiple swtichovers of SWE_NP coredump will be observed on standby node.

Platform/Feature: SBC

Maintain the state in the SWe_NP of running RTCP timers in the context block and guard the double start of timers.
8SBX-919851

The SIP calls drop with vertical service code *65 after a minute.

Impact: The SBC is not able to send ACK to the Egress for call to connect.

Root Cause: A logical error when combined with multi features (e2eAck, e2eReInvite, and DLRBT).

Steps to Replicate:

  1. Configure the e2e Ack, e2e reInvite, and DLRBT.
  2. Egress response 183(sendrecv), 183(onhold), 180(no SDP), 200OK(sendrecv).
  3. Peer change the SDP in 18x/2xx response causing internal offer/answer.
  4. Ingress peer sends the reInvite right after ACK, causing internal state not able to send ACK out.

Platform/Feature: SBC

Correct logical errors when multi features e2e ack, e2e reIvnite, and DLRBT are enabled.
9SBX-926601

The SBC failed over DEADLOCK detected and a ScmP core was generated as a result.

Impact: Access the NULL pointer in NRMA when deleting a tone profile.

Root Cause: The given targets name does not exist.

Steps to Replicate: Use CLI command to delete the non-existing announcement tone profile.

Platform/Feature: SBC

The code is modified to validate the return value from lookup function before accessing the value.
10SBX-921151

The SCMP coredump was related to ARS.

Impact: The SCM process may core dump when the SIP signaling port is out of service, and if calls are in progress and a SIP transaction timeout occurs.

Root Cause: If the SIP signaling port is out of service, and if calls are in progress and a SIP transaction timeout occurs.

Steps to Replicate: The steps cannot be replicated.

Platform/Feature: SBC

The code is modified to check that the SIP signaling port is in service when handling SIP transaction timeout events.
11SBX-917501

Observed "SamProcess" core dump on an active box while running SIP-GW (cyclic) calls.

Impact: The SBC may core if the GW Signaling Port configuration is disabled while GW Signaling Link is up.

Root Cause: The core is caused by an attempted NULL pointer access.

Steps to Replicate: Disable the GW Sig Port while GW Sig Link is up.

Platform/Feature: SBC

The code is modified to check for NULL pointer to GW Signaling Port before attempting to access this pointer.
12SBX-923861

When running the 7.2.1R2 release, the SBC is responding with 'a=inactive' instead of 'a=sendrecv' in a 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 the SBC on hold.

Root Cause: A missing requirement.

Steps to Replicate:

Step 1: Generate SIP scripts for a call flow.
Step 2: Setup 7.2.1 system without a fix.
Step 3: Run the call flow to see that the problem is observed.

Platform/Feature: SBC

The code is modified to send a=sendrecv to make it RFC compliant.
13SBX-920921

A possible memory leak in the 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 in the same AOR is received. This will only happen if multiple contacts in the AOR flag is disabled.

Root Cause: The code does not free certain memory blocks.

Steps to Replicate:

  1. Multiple contacts per AOR flag will be disabled
  2. Do a Register for particular AOR and do a de-register.
  3. Within less than 30 secs, re-send the registration for same AOR so that SIPFE selects the same preferred slot which 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.
14SBX-932851

Observing a box reboot while the application is coming up as standby after a port-failure.

Impact: After a node switchover, the standby node may reboot while the application is coming up.

Root Cause: During a node switchover, when application comes up on standby node, the health monitoring for worker thread fails because of an incorrect evaluation of CPU cycles spent by the thread. A failure to health monitoring causes the standby node to reboot.

Steps to Replicate:

Execute node switchover with the following steps:
1) Bringing down all active ports.
2) Applying the appropriate CLI command.
3) Fail the application on the active node.

Platform/Feature: SBC

The code is modified so the health check monitoring for the worker thread is correct.
15SBX-93553 / SBX-934691

Portfix SBX-93469: The DFW1-CASBC-02 Box A had a SCMP coredump. (Originated in release 7.2.3)

Impact: The SBC cored when accessing Box A, switching over to Box B instead.

Root Cause: Enabling the SDP transparency and the directMediaAllow to show a simple 18x response from the peer may cause a core dump due to access from an invalid address.

Steps to Replicate: Disable either the SDP transparency or the directMediaAllow.

Platform/Feature: SBC

The code is modified to ensure it does not have access with an invalid address.
16SBX-921551

The SBC is releasing the call with 504 when the DLRB and Downstream Forking are enabled.

Impact: The SBC releasing the call with 504 when the DLRB and Downstream Forking are enabled.

Root Cause: The race condition is not handled properly. When first 180 message without SDP is received, the forking list and stored the message were updated. The second time the 180 message with SDP was received, the forking list and stored the 180 message were updated, but since RTP learning was applied earlier, it was not replicated again.

Steps to Replicate: Send the RTP before sending the 180 Ringing (CSeq: 961529 INVITE RSeq: 629928).

Platform/Feature: SBC

If RTP learning happens before the corresponding 18x message with SDP is received, save the SDP into a queue of possible SDPs to cut-thru for use while 200 OK is received.
17SBX-935661

The WALL Signaling PSBC10A01 cored.

Impact: When the MRF Modify is received, the MRFRM fsm state must be OA_ACTIVE. But in this issue, the state is leading to incorrect typecasting.

Root Cause: The defensive was checked.

Steps to Replicate: Run the MRF load.

Platform/Feature: SBC

When the MRFRM is in OA-NULL state, the call must not be in connected state.
18SBX-933121

The SBC Memory has High alerts.

Impact: When the Local Ring back tone is configured on the SBC and egress endpoint sends a 183 Session Progress with 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 on the SBC and egress endpoint sends a 183 Session Progress with SDP followed by a 180 Ringing, the ScmProcess does not free up memory allocated even after call is completed.

Steps to Replicate: Run a call load with the Local Ring back tone configured and monitor the virtual memory usage of the ScmProcess.

With a fix, the virtual memory of ScmProcess must not be high after all calls have been disconnected.

Platform/Feature: SBC

The code is modified to ensure the memory allocated for packet service profile structure is freed when no longer required.
19SBX-918991

SBCv6 Unexpected 183 (CPG) sending - out of PER6608 spec.

Impact: Early cut through may not work for trusted configured RTP Servers on system restart.

Root Cause: The system restores the SIP service group data before the RTP Server data which is incorrect.

Steps to Replicate:

Provisioned the rtpServerTable (OLIVER_RTP_SRV_TBL), and associated it which the egress sipTrunkGroup SBXSUS9_LABSIP2
(as shown below):

admin@sbxsus9> show configuration details addressContext default rtpServerTable OLIVER_RTP_SRV_TBL
rtpServer 10.8.20.75 32;

admin@sbxsus9> show configuration details addressContext default zone ZONE4 sipTrunkGroup SBXSUS9_LABSIP2 media earlyMedia
method rtpServerTable;
rtpServerTableName OLIVER_RTP_SRV_TBL;
forkingBehaviour lastReceivedSdp;

Platform/Feature: SBC

Fixed the ordering of the initialization procedure to restore the RTP server profile configuration data before restoring the SIP service group data.
20SBX-926111

Outbound call Failing with 488.

Impact: Transcode call, after 40 onhold/offhold, call fail.

Root Cause: Internal process Nrma TransactionId did not reset properly after wraparound (12 bits limit). As resulted, it is sending the same transactionId for allocating DRM resources for both Ingress and Egress legs.

DRM reject due to duplicated transactionId.

Steps to Replicate: sip-sip call with transcoding. Call fail after 40 onhold/offhold.

Platform/Feature: SBC

 Properly reset the TransactionId when it reach 12 bit limit.
21SBX-940531

The P-SBC Openstack installation fails with an OAM node and core dumps.

Impact: Upgrade fails if any of the SNMP trap targets are 32 characters in length.

Root Cause: Right sized buffer was allocated to fetch data from the database but passed incorrect length field to database API. In the case where the field being fetched has max allowed length, the API fails because the API verifies that there is not enough room to terminate the field with NULL.

Steps to Replicate:

  1. Create SNMP trap target of 32 character long.
  2. Attempt to upgrade.
  3. The upgrade will fail.
  4. Perform upgrade with the fix, and the upgrade will succeed.

Platform/Feature: SBC

The code is modified to add the correct buffer length to configuration database APIs.
22SBX-937651

CS04A01 lost communication with the CM04A04. Post-recovery, other M-SBCs cannot talk to the CM04A04.

Impact: The IPv6 address becomes unreachable in standby port cable pull scenarios.

Root Cause: The SWe code was not handling saving the multicast mac address list and re-applying it on the 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 that PKT port.
  3. Re-insert the cable for same standby port.
  4. Do a port switchover by plugging out active physical port's cable so that the standby becomes active for same port.
  5. Ping the new configured IP from in step 2 from outside. The ping will result in a failure.

Platform/Feature: SBC

The code is modified to handle the programming of multicast MAC list for standby ports properly.
23SBX-94171 / SBX-941151

Portfix SBX-94115: The I/O scheduler was incorrectly configured after upgrade.

Impact: Kernel scheduling issues are causing intermittent issues, including lost pings across the HA interface. The lost pings induce a split brain and subsequent split brain recovery. Transient calls are lost during the split brain and recovery, and depending on call flow, stable calls may be lost as well.

Root Cause: The I/O scheduler is being reverted from 'deadline' to 'noop' due the upgrade due to a bug in the upgrade script.

Steps to Replicate: After upgrade to 6.2.x or 7.x, verify the scheduler with the following command:

cat /sys/block/sda/queue/scheduler

The output must show brackets around deadline to indicate it is in use, for example:

[root@SBX24-154a log]# cat /sys/block/sda/queue/scheduler
noop [deadline] cfq

Platform/Feature: SBC

The code is modified to properly specify the I/O scheduler.
24SBX-943131

There is a core dump during an A to B tandem call in (GSX)SIP-gw-gw-SIP(SBX) when the egress IP Signaling Profile is not configured.

Impact: The GSX-SIP-Gw-Gw-SIP-SBX has a core dump in the SBC if the egress Signaling Profile is not attached.

Root Cause: The issue was found by providing a fix to another issue, not through attempting a call with no egress signaling profile attached.

Steps to Replicate: Make an A to B call using the GSX-SIP-Gw-Gw-SIP-SBX and on the egress TG in the PSX. Do not attach the egress Signaling Profile. These steps will result in a core dump.

Platform/Feature: SBC

The code is modified to create a zeroed out IPSP and pass it for the system to act on instead of NULL the PTR. When the code looks for specific IPSP flags, none of the flags are enabled, but there is active memory.
25SBX-93931 / SBX-937991

Portfix SBX-93799: A SCM process coredump was observed when the sipParamFilterProfile is configured.

Impact: This issue is a result of a bug in a previous release (Configuring multiple JJ9030 profiles in a single commit does not work) fix.

Root Cause: Reading the Profile XML tag from the confd when the confd iterator is not pointed to a profile.

Steps to Replicate:

Configure the sipParamFilterProfile as shown below:
1. Set the profiles services sipParamFilterProfile as a Test sipHeader to require action passthru all.
2. The SBC will generate SYS_ERROR when the confd iterator is not pointed to the profile.

Platform/Feature: SBC

The code is modified to read XML tag from the confd when the confd iterator is pointed to the profile.

The following Severity 2/3 issues are resolved in this release:


Resolved Issues


Issue IDSevProblem DescriptionResolution
1SBX-924792

In the I-SBC, PKT Port redundancy support is not present in 7.2.2 release.

Impact: The SBC Release 7.2.2 is missing the PKT Port redundancy support, when it is listed as available.

Root Cause: In the I-SBC, the PKT Port redundancy support is added in the 8.x releases, but not present in the 7.2.2 release.

Steps to Replicate: Configure the pkt port redundancy, port the switchover to see the service continuity on PKT ports with redundancy enabled.

Platform/Feature: SBC

Back ported support is added in the 8.x to 7.2.2. releases.
2SBX-88061 / SBX-874043

Portfix SBX-87404: A reInvite is triggered before an ACK is verified. (Originated in release 6.2.4)

Impact: When the online validation (sessId and verId) is set to zero in 200OK, the SIPS fails to save the peer SDP.

Root Cause: When the o-line validation (sessId and verId) is set to zero in 200OK, the SIPS fails to save the peer SDP. This could trigger an unnecessary reInvite.

Steps to Replicate: Configure the SDP o-line version only. The SDP received in 200 Ok (multi codecs) for egress has a sessId and verId of zero. The SBC could send an unnecessary reInvite to the peer.

Platform/Feature: SBC

The code is modified so the peer SDP is saved properly.
3SBX-920372

Optional fax parameters are being parsed by the SBC and, as a result, the 200 Ok is being discarded.

Impact: The SBC returns a parser error (4xx) for unsupported t38 attributes.

Root Cause: When the unsupported t38 attributes are received, the SBC shows it as an error.

Steps to Replicate: When the Incoming call has unsupported t38 attributes, the SBC shows a reply 4xx (parsed error).

Platform/Feature: SBC

The code is modified so the SBC ignores the attributes and does not display an error message.
4SBX-916823

The MS Teams scenario with ICE causes the RTCP port value discrepancy with X when the RTP is Y and when MUX is supported.

Impact: When the SBC sends out re-INVITE messages on a call leg supporting ICE, it can still include a=rtcp:<rtp port + 1> value in the SDP that is different to the previously agreed RTP/RTCP MUX setup with the remote end.

Root Cause: The SBC was not considering the SDP answer from the peer when setting the RTCP port value.

Steps to Replicate:

1. Send INVITE to SBX ingress with valid audio stream in SDP.

2. From the egress endpoint, respond to the INVITE with a 180 ringing and a 200 OK, and in both cases include valid SDP that has an RTP ICE candidate (no RTCP).

a=rtcp-mux

3. At the ingress endpoint, respond to a 200 OK with valid ACK.

4. From ingress endpoint, send a re-Invite that includes an existing audio stream and add a new video stream in SDP.

5. Complete the call signaling and then clear the call.

Platform/Feature: SBC: MS Teams

The code is modified to send a=rtcp:<rtp port> when sending re-INVITE messages for streams previously agreed to support muxed behaviour.
5SBX-89807 / SBX-864953

Portfix SBX-86495: Add a lightweight MPSTAT analysis as a warning to the user. (Originated in release 8.1.0)

Impact: The SBC had random timeouts/healthchecks due to the high %steal (in mpstat output).

Root Cause: There is no warning given when the %steal value is high.

Steps to Replicate: On a VM or cloud machine, manually add a value in the mpstat.log and then run the script.

Plaform/Feature: SBC

The code is modified to check if the system is running with high steal% value and showing a warning to the user.
6SBX-907583

The SIP level4 call trace filter must not be restricted by the maxTriggerCount.

Impact: Level 4 call traces are incorrectly restricted by the maxTriggerCount value.

Root Cause: The intention is that the level 4 traces runs all messages and not be restricted by the system wide trigger count. The count must only apply to per call level 1-3 traces.

Steps to Replicate:

  1. Configure a level 4 call trace.
  2. Configure the maxTriggerCount to a non-zero value.
  3. Change calls that are traced as well as subsequent calls – once maxTriggerCount calls have been made, not be traced.

Platform/Feature: SBC

The code is modified to ensure level 4 traces are unrestricted.
7SBX-92266 / SBX-881222

Portfix SBX-88122: The SBC failed to re-establish media session between the SBC and MS Teams Client after a call transfer initiated by Teams client has failed. (Originated in release 7.2.1)

Impact: In scenarios where MS Teams referred the call to another, the SBC started to play a RBT (ring back tone) and if the REFER failed due to the C-party not answering, the media is not established again between the A and B party.

Root Cause: The media resource used to play the RBT did not get freed up correctly when the REFER failed and this blocked the media flow from A to B being re-established.

Steps to Replicate: Make a call from PSTN to MS Teams, have MS Teams REFER the call to another user. Let the phone ring as C-party but do not answer it.

Platform/Feature: SBC

The code is modified to correctly free up the RBT resources so the A- to-B call can re-establish.
8SBX-908672

The Ssreq coredumped on the SYD SBC.

Impact: The ssreq server has a memory leak that may eat up virtual memory, when there is call load through the ssreq client.

Root Cause: The memory allocated for call data and call trace is not being deleted properly, leaving those memory blocks idle forever.

Steps to Replicate:

  1. Set up the SBC system with a light or heavy call load.
  2. Add a call load through ssreq client to the system, light traffic is enough.
  3. Use the top command to watch the memory growth.

Platform/Feature: SBC

The code is modified to remove the memory blocks promptly.
9SBX-91585 / SBX-915102

Portfix SBX-91510: An ASAN global-buffer-overflow for the IPUtilGetIpAddressForPrefix. (Originated in release 8.1.0)

Impact: In the SBC, while validating whether the peer RTP address is trusted or not, the IP address is validated. While validating the IP Address, the prefix is passed along with the IP Address. The prefix length is passed as 128, irrespective of the IP Address version.

Root Cause: This issue was reported as part of the ASAN Testing on a PCR 8709 regression suite in the SBC lab.

Steps to Replicate: This issue was found while running a PCR 8709 regression test suite.

Platform/Feature: SBC

The code is modified by passing the correct prefix length and by checking the IP Address version (i.e. If IPV4, pass prefix length as 32. If IPV6, pass prefix length as 128).
10SBX-921372

The RTP is sent to RTCP after a monitor success indication.

Impact: The SBC learns the RTCP port number and uses that to send RTP packets to the end point when RTP monitoring is enabled.

Root Cause: When the RTP montoring is enabled for a call and the media stream sends RTCP packet within the number of packets for authorization, an Network Processor (NP) learns the RTCP packet and notifies the application about the sourceIP and sourcePort.

Steps to Replicate:

  1. Enable the RTP monitoring for a call.
  2. Send RTCP packet first and then RTP packets.
  3. The SBC may send to the learned RTP source port.

Platform/Feature: SBC

The SBC does not learn the RTCP packet when the RTP monitoring/x_cnt feature is enabled.
11SBX-91724 / SBX-910902

Portfix SBX-91090: PrsNP process core dump on standby of KVM-ISBC HA while doing an sbxrestart. (Originated in release 8.1.0)

Impact: There is rare potential of race in healthcheck implementation of SWe_NP. It can cause a false healthcheck failure of the SWe thread and a result in SWe_NP thread crash.

Root Cause: Read and write a healthcheck global variable occurred in non-atomic manner from two different cores.

Steps to Replicate: This is a rare occurrence that happens randomly on idle systems. The steps cannot be consistently reproduced.

Platform/Feature: SBC

The code is modified to make the healthcheck variable update as atomic.
12SBX-909463

Replace the cdb_get when processing status commands.

Impact: Multiple issues were reported where the process cored from healthcheck timeout. The application must not call out to the CONFD when processing the CLI status requests.

Root Cause: Application must not call out to CONFD when processing the CLI status request.

Steps to Replicate:

1. Configure IPSEC testbed.

2. Start to run some calls.

3. From CLI, issue the following commands: "show table addressContext <address context> ipsec ikeSaStatus" "show table addressContext <address context> ipsec ikeSaStatistics" "show table addressContext <address context> ipsec ipsecSaStatus" "show table addressContext <address context> ipsec ipsecSaStatistics" "show table addressContext <address context> ipsec systemStatistics"

Platform/Feature: SBC

The code IKE process code is modified to avoid calling out to CONFD when processing CLI status requests.
13SBX-920022

The DALSBX71A core dumped.

Impact: The SBC core dumped while processing a call with the call stack in 5.0.5R000 software.

Root Cause: NRMA has resources getting cleaned up in response to the ingress hanging up. At the same time, in response to egress received 183 Session Progress and 180 Ringing, the activate starts. In this race condition, the ipCktInfo is NULL and code illegally tries to access it and causes a core dump.

Steps to Replicate: No steps to replicate, only a code inspection was done to test the issue.

Platform/Feature: SBC

A null pointer check is put in place.
14SBX-92402 / SBX-912572

Portfix SBX-91257: No Ring back is heard during a blind transfer. (Originated in release 7.2.1)

Impact: The SBC was playing a ring back tone while processing REFER and transferring the call. However, the tone was not heard on the original call leg because MS Teams had put the original call on hold.

Root Cause: The code was intentionally not sending re-INVITE messages in this scenario.

Steps to Replicate: Run any MS Teams transfer call scenario.

Platform/Feature: SBC

The code is modified to send out a re-INVITE message to take the original call off hold so that it can hear the ring back tone being played.
15SBX-920912

Call Graphs are showing more calls after upgrade.

Impact: Stale calls may be found on a newly upgraded SBC if upgrading from a version older then 6.1.0 to a version higher.

Root Cause: As a result of changes that were made to the call ID in 6.1 code, any calls during the LSWU that existed prior to the upgrade and then were modified or terminated after the upgrade started will be left in a hung state.

The only way to clean up these calls is to use the following commands:

unhide debug
request sbx rtm debug command “cleanup <gcid>

Steps to Replicate:

1. Create an audit key greater than 31 by multiple switch over on a HA system or by using instrumented code.

2. The audit key will create GCID values using the high bits ( bit 30-31) of GCID value.

3. Setup SIP calls on the system.

4. Initiate the LSWU on standby and after standby is upgraded to newer version, all the established calls on active will be synced.

5. Start the LSWU on active.

6. At this point, standby will become Active.

7. Hang up calls that were 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. To verify the issue, perform the same steps mentioned above. After upgrading to version with fix, after calls are hung, resources must be released and show table global callSummaryStatus command will not show any orphaned calls.

Platform/Feature: SBC

The code is modified to prevent calls from being hung during an upgrade from versions older than 6.1.
16SBX-917383

When using the metaVariableDynamic, LinkDetection is not activated in the SBC.

Impact: If the LinkDetection interfaces are configured to use addresses specified in the systemMetaVariable dynamic table, those addresses are not properly read and the LinkDetection is not activated.

Root Cause: The addresses were not properly read from the metaVariableDynamic table.

Steps to Replicate:

1. Add new entries to the metavariableDynamic table.
2. Create an ipInterface with meta keys added to metaVariableDynamic table.
3. Configure the Link Detection on the ipInterface.
4. Check the Link Detection status.

Platform/Feature: SBC

The code is modified to properly read the addresses from the metaVariableDynamic table.
17SBX-920013

Memory leaks in the SIPSG.

Impact: While debugging a bug in a previous release (SCM crashed from segmentation fault fired from malloc()), memory leaks were found in the SIPSG related to subscription.

Root Cause: Observed through a source code inspection.

Steps to Replicate: Perform SIP regression tests.

Platform/Feature: SBC

The code is modified to free memory blocks properly.
18SBX-92430 / SBX-906542

Portfix SBX-90654: Unable to retrieve the parked call on MS Teams. (Originated in release 7.2.1)

Impact: The SBC was unable to retrieve a parked call. The call was not working correctly because the NRMA process had incorrectly swapped PSP information on the call legs.

Root Cause: This is a new call scenario being implemented for the MS Teams interop.

Steps to Replicate: Run a test call in the MS teams for call park and retrieve.

Platform/Feature: SBC: MS Teams

The code is modified to correctly process PSP information on the different call legs during parking and retrieving a call.
19SBX-92160 / SBX-919072

Portfix SBX-91907: The SBC fails to mount a cinder volume on first boot. (Originated in release 8.1.0)

Impact: The SBC fails to mount a cinder volume on first boot.

Root Cause: The bootcmd instruction to mount the volume was executed before the cinder volume was attached as part of instance creation. The cinder volume was not mounted on first boot and as a result, the SBC results in a failure.

Steps to Replicate: Launch the SBC instance with a cinder volume attached and ensure volume is mounted properly.

Platform/Feature: SBC

The code is modified to wait until the cinder volume is detected and then proceed with the mount.
20SBX-92414 / SBX-918202

Portfix SBX-91820: In crank back scenarios, the SBC is taring down the SRS call even before the CS call is torn down.(Originated in release 7.2.1)

Impact: The SBC was immediately disconnecting the SRS call after establishing the SIP Rec session with the next available SRS. The initial SRS responds with a failure 4xx response.

Root Cause: The SBC, after finding the next reachable SRS when the initial one has failed with 4xx response, creates a new SIP Rec Call Block data matching to new SRS. In the older version of the SIP Rec Call Block, the state machine was invoked with a incorrect event. The incorrect event in the state machine was causing the deletion of old SIP Rec Call Block along with deleting the new SIP Rec Call Block.

Steps to Replicate:

1. Create a SRS Group with three SRS Servers.
2. Configure the num streams to 2.
3. The SBC tries to send SRS Invite to first 2 SRS.
4. Send the 4xx response from the first SRS and 2xx response from the 2nd SRS.
6. After receiving the 4xx response, the SBC tries to send new INVITE to 3rd SRS.
7. Send a 2xx response from 3rd SRS.
8. At this step, after ACK towards 3rd SRS, SBC immediately sends BYE to 3rd SRS.

Platform/Feature: SBC

The code is modified to invoke the State machine with a proper event so that only the old SIP Rec Call Block data is removed and the new SIP Rec Call Block data is retained. This avoids immediate disconnection of new SIPREC Call that is established with the second SRS.
21SBX-910362

A DTMF transcoding caused the call to disconnect.

Impact: A certain percentage of the traffic (5%of the calls) are failing due to an incorrect DTMF payload being sent by BROADSOFT.

Root Cause: The SBC was expecting that for a single HD CODEC entry in the 200 OK ANSWER, the Peer/Endpoint must send a matching 16K DTMF payload as per the RFC standard. But the BROADSOFT server at the Egress side is non compliant and sending a 8K DTMF, which is causing the call disconnection.

Steps to Replicate:

1. Enable the DTMF either on both the legs and Different Transcode Flag.

2. Send the PCMU with DTMF 8K from Ingress leg.

3. From Egress side, send the PCMU without any DTMF.

4. Ensure that the call is transcoded.

Platform/Feature: SBC

The code is modified so the strict check is now relaxed and for single codec entry, the SBC does not match the DTMF clock with the codec clock frequency.
22SBX-915522

Q.850 reason header has a grammar issue.

Impact: Invalid format in the reason header in a SIP 500 message.

Root Cause: When the reason header transparency is enabled, a bug appears in the code.

Steps to Replicate: Enable the Reason header transparency along with ANM to CPG feature.

Platform/Feature: SBC

The code is modified so that even when transparency is enabled, the Reason header is sent out in the correct format.
23SBX-92658 / SBX-915993

Portfix SBX-91599: There was a ASAN stack-buffer-overflow on the address in the StrNCpyZ.

Impact: There is an array, which is being used with string specifier and is not null terminated, which causes the overflow problem.

Root Cause: A buffer overflow.

Steps to Replicate: The steps are not reproducible.

Platform/Feature: SBC

The log is removed to stop the buffer overflow.
24SBX-926212

*BrmRedBresAlloc messages are overloading DBG logs.

Impact: BRM redundancy messages were filling up DBG logs.

Root Cause: Those were debug messages to help debug resource leaking issue.

Steps to Replicate: Use regression test only.

Platform/Feature: SBC

Downgraded the related BRM redundancy messages to INFO/Minor level to avoid overloading the DBG logs.
25SBX-919522

Oracle Java JDK vulnerabilities were observed for Nessus scans.

Impact: The Nessus Scan was reporting that embedded java in Oracle database has security vulnerabilities.

Root Cause: Oracle 12c has Java 1.6.0_75 embedded.

Steps to Replicate: Run a Nessus scan and the earlier vulnerability will go away.

Platform/Feature: SBC

Upgraded the Oracle 12c 12.1.0.2 embedded java to 1.7.0_221 using the patch provided by Oracle.
26SBX-915702

Calls from MS Teams may have an audio loss for 30 seconds and then switch-over.

Impact: If there is an SBC switch-over after the call is established, there can be a delay (for example, 30 seconds) when re-establishing the media from the PSTN to MS Teams.

Root Cause: The stored SSN value does not get updated before the SBC switch-over occurs, and it causes the SSN to jump backwards after a switch-over, which causes the one way audio issue until the SSN value increments past the previously set value.

Steps to Replicate: Perform a switch-over after the LRBT is played and check that there is no one way audio issue.

Platform/Feature: SBC: MS Teams

After the LRBT is played, the latest SSN value is sent to the standby SBC so it can correctly jump the SSN forward on a switch-over and the media flow continues without delay post switch-over.
27SBX-908752

The LSASBX71 switched over and causes both sides to core.

Impact: A bug in GW Signaling code can cause a core when GW Signaling Links are bouncing.

Root Cause: A bug in GW Signaling code can cause a core when GW Signaling Links are bouncing.

Steps to Replicate: The steps are not reproducible.

Platform/Feature: SBC

The GW Signaling code is modified to prevent a core.

28SBX-917722

The application is generating "User Error: monitoring/0/101 PAM authentication succeeded" in .SEC file.

Impact: The SEC log records all successful PAM authentication, which is causing the disc to fill.

Root Cause: Due to constant value re-organization, successful PAM authentication has been mistakenly logged in to SEC log.

Steps to Replicate:

  1. Ensure that logs are configured at MAJOR level.
  2. Put a TLS load on the SBC.
  3. Many of the similar lines in the SEC log, as shown in the example below:

    154 07092019 155039.345656:1.01.00.56147.MAJOR .CHM: *User Error: monitoring/0/101 pam authentication succeeded via rest

  4. Apply the same procedure in a fix version SBC and those lines will not be seen.

Platform/Feature: SBC

The code is modified to exclude a successful case when logging in PAM authentication failures.
29SBX-933892

The MS Teams call flow when using hold/resume then transfer causes SCM crash.

Impact: When music on hold is used in the deployment and a call is put on hold/resumed and then transferred, the call is causing the SBC to coredump in the SCM process.

Root Cause: The SCM process was de-referencing a null pointer.

Steps to Replicate: Music on hold is used in the deployment and a call is put on hold/resume and then transferred.

Platform/Feature: SBC: MS Teams

The code is modified to validate the pointer as not null before trying to use it.
30SBX-92980 / SBX-924842

Portfix SBX-92484: The SBC is dropping the 2nd codec for a text stream when the sendOnlyPreferredCodec flag is enabled. (Originated in release 8.1.0).

Impact: The SBC was dropping the second payload for a text stream if the "Send Only Preferred Codec flag" was enabled and the offer answer contains both t140 and red as payloads for this stream.

Root Cause: The "Send Only Preferred Codec" flag's logic was applied even to a text stream that resulted in the SBC picking the first codec and dropping the other.

Steps to Replicate:

1. Bring up the setup for an A-B call.

2. Enable the flag t140 on both PSPs.

3. Enable the flag sendOnlyPreferredCodec on both IPSPs.

4. Send INVITE from A with both Audio and text media stream with 2 codecs for text(t140 & red).

5. Send 200 OK from B with both Audio and text media stream with 2 codecs for text(t140 & red). Both of the payload is received through the t140 and red is received and no payload is dropping.

Platform/Feature: SBC

The code is modified to exclude text stream from "Send Only Preferred Codec" logic.
31SBX-925802

The SIP Domain is missing in the FROM header after an upgrade.

Impact: The DM rule for the FROM Uri is not working.

Root Cause: Introduced in a previous release to treat the FROM Uri for theRewriteIdentity only.

Steps to Replicate: Configure the PSX for FROM Uri, and a SIP-SIP call. Verify the FROM header is picking up the DM rule of FROM Uri.

Platform/Feature: SBC

The code is modified to support the old behavior for allowing the FROM URI taking effect, even when RewriteIdentity is disabled
32SBX-929183

Inconsistent handling of the SDP in 200 OK on an egress SIP leg.

Impact: "Send Updated SDP in 200OK" was enabled and GW-GW call will fail when the 2xx response SDP is different from the previous 18x response.

Root Cause: The feature flag "Send Updated SDP in 200OK" is applicable for SIP-SIP call only.

Steps to Replicate: Turn on the flag, make a GW-GW call where the 200OK SDP is different from the previous 18x response.

Platform/Feature: SBC

Added logic to disable the feature even if configuration is enabled
33SBX-924702

The SamP has a memory leak.

Impact: There is possible slow memory leak in the SAM process when running GW-GW calls.

Root Cause: GWFE is leaking a copy of the incoming PDU that was queued internally.

Steps to Replicate: The steps are not reproducible.

Platform/Feature: SBC

The code is modified to free the memory that was being leaked.
34SBX-922522

The SBC was sending an INVITE out for the first user only.

Impact: The Native Forking fails to send out on 2nd route.

Root Cause: If an incoming call that has capital "CALL-ID", the SBC fails to find the parent incoming call.

Steps to Replicate: Configure the native forking feature, and incoming call has capital "CALL-ID".

Platform/Feature: SBC

The code is modified so the "CALL-ID" is case insensitive.
35SBX-925852

The SBC SWe is dropping packets on the pkt0.

Impact: The pkt0 interface stops pinging after a long time.

Root Cause: The SWe_NP code has a slow leak when it is in standby mode, causing the pkt0 to get exhausted after sufficiently long time.

Steps to Replicate: On a standby node, run a program/utility to send packet out of the interface.

Platform/Feature: SBC

Ensure all packets are freed that are read from the KNI devices in SWE_NP code.
36SBX-930562

The SBC failed to generate Enum lookup after updating the dynamic metaVariable.

Impact: The SBC failed to generate Enum lookup after updating the dynamic metaVariable

Root Cause: When the dynamic metaVariable updated for the sipSigPort, the trigger was missing for lwresdProfile and update of sipSigPort IP was not happening that causes the issue.

Steps to Replicate:

1.Configure the SBC for A-B call.
2.Create a dynamic metaVariable to add to sipSig port.
Example:

admin@vsbc1% show addressContext default zone ZONE_ING_V6 sipSigPort sipSigPort 3

{ ipInterfaceGroupName LIG_ING_V6; portNumber 5060; mode inService;

state enabled; transportProtocolsAllowed sip-udp,sip-tcp; ipVarV6 lpl_ing; }

[ok][2018-10-16 15:40:32] [edit] admin@vsbc1% q [ok][2018-10-16 15:40:34]

admin@vsbc1> show table system metaVariableDynamic

CE NAME NAME VALUE -----------------------------------------------------

vsbc1-10.34.195.109 lpl_egg fd00:10:6b50:5d20::c9 vsbc1-10.34.195.109 lpl_ing fd00:10:6b50:5d20::c7


3. Configure for an Enum call and run an Enum call make sure Enum over sipSigPort and observe an Enum call is successful over sipSigPort.
4. Update the dynanamic metaVaribale lpl_ing to fd00:10:6b50:5d20::ec and restart the SBC and try the call.
5. After updating the metaVaribale lpl_ing to fd00:10:6b50:5d20::ec, the Enum call must be successful.

Platform/Feature: SBC

The dynamic metaVariable trigger is added for lwresdProfile to update sipSigPort IP to fix the issue.
37SBX-933072

Configuring the multiple NNI profiles in a single commit does not work.

Impact:

The following tables are not read correctly by the SIP application, if multiple rows are changed in the same commit in the CLI:
E164 Profile
SIP Filter Profile
NNI Profile
Privacy Profile
PSX Script Profile
SIP Security Profile
SIP Param Filter Profile
SRVCC
STI Profile

Root Cause: There was a coding error.

Steps to Replicate:

  1. Configure two or more NNI profiles.
  2. Configure SIP trunk groups using each of the NNI profiles.
  3. When making SIP calls, the controls on only one of the NNI profiles (the one which is displayed first when running show command) are effective.

Platform/Feature: SBC

The code is modified to process multiple rows in a commit.
38SBX-923873

The service instance messages for "Call_Hold" and "Call_Retrieve" are not generated in some GW-GW scenarios.

Impact: When a SIP-SBX-GW-GW-GSX-ISUP call is intercepted, if hold/retrieve is received from either side, the SBC does not send service instance messages to the LI server.

Root Cause: The SBC is not sending the service instance messages to the LI server.

Steps to Replicate:

1. Start the LI server.
2. Initiate the SIP-ISUP call with HOLD from egress.
3. Check LI server logs for service instance msg for hold and retrieve.

Platform/Feature: SBC

The code is modified to pass the Hold/Retrieve indications from one GW to other GW.
39SBX-930892

Admin credentials are visible to non-root users during PM login.

Impact: The credentials for admin were visible to linuxadmin.

Root Cause: Previously a shell was invoked by PHP and inside it pamValidator was called with credentials as arguments.

Steps to Replicate: Run the following in a session as linuxadmin while

  1. Apply pgrep -a pam; done.
  2. Log into PM now credentials should not be present in the output of the command.
30131 /usr/local/bin/pamValidator 30131 /usr/local/bin/pamValidator 30131
 /usr/local/bin/pamValidator 30131 /usr/local/bin/pamValidator 30131
 /usr/local/bin/pamValidator 30131 /usr/local/bin/pamValidator

Platform/Feature: SBC

The code is modified so pamValidator takes input from the ENV instead of cmdline arguments.
40SBX-912113

"X509_STORE_add_cert failed 0" when multiple certificates are created using the same certificate file.

Impact: "X509_STORE_add_cert failed 0" error log is continually logged onto .DBG from the standby (HW only) when a remote certificate is added that does not have a 'success' status.

Root Cause: The certificate does not properly exist in CLI, therefore the certificate cannot be properly read from CDB.

Steps to Replicate: Create multiple certificates using the same remote.

Platform/Feature: SBC

The timer used to import the certificate on the standby now checks the certificate status and successfully exits in cases where the certificate status is not a 'success'.
41SBX-933262

Receiving text populated as null in mediaStream2Codec and in callMediaStatus.

Impact: When audio and text media call is made, the mediaStream2Codec of text is being populated as null.

Root Cause: Text has been removed from a fix in a previous release, which has made "mediaStream2Codec" field not to populate for text media.

Steps to Replicate:

  1. Bring up the box with the latest SBC build that supports T.140 session.
  2. Enable the following CLI and attach to Ingress and Egress TG's.

    -set profiles media packetServiceProfile DEFAULT flags t140Call enable


  3. Send INVITE with Audio+T.140 sessions from UAC.
  4. Send 200 OK with Audio+T.140 sessions from UAS.
  5. Send BYE.

Platform/Feature: SBC

The code is modified to include the text stream to populate "mediaStream2Codec".
42SBX-931243

The SBC changes the format of P-Access-Network-Info header on the 18x and 200OK.

Impact: When transparency is enabled in the P-Access-Network-Info Egress and received by P-Access-Network-Info in the 18x, the message forwarded to the ingress has an incorrect syntax.

Root Cause: A logical error related to double quote string parameter was causing a syntax error to be sent out.

Steps to Replicate:

  1. On SIP-SIP call, enable the header P-Access-Network-Info transparency.
  2. Egress receives P-Access-Network-Info in 18x and forwards to the ingress with an incorrect syntax.

Platform/Feature: SBC

The code is modified to correct the logical error.
43SBX-934762

Fix the double free scenario in NAT and in a multicast scenario.

Impact: There will be a random SWe_NP core dump when either NAT is enabled or the LI is enabled at peak loads.

Root Cause: There was double free of mbuf pointer, which can cause corruption.

Steps to Replicate: Run calls with the LI or NAT enabled at a peak load.

Platform/Feature: SBC

The code is modified to fix the double free of mbuf pointer.
44SBX-93325 / SBX-931752

Portfix SBX-93175: Receiving a null in the mediaStream2Codec and in the callMediaStatus. (Originated in release 8.1.0)

Impact: When a audio+ text media call is made, the mediaStream2Codec is being populated as null.

Root Cause: Text has been removed through a fix in a previous release, which has made "mediaStream2Codec" field to not populate for text media.

Steps to Replicate:

  1. Bring up the box with the latest SBC build that supports T.140 session.
  2. Enable the following CLI and attach to the Ingress and Egress TGs.

    -set profiles media packetServiceProfile DEFAULT flags t140Call enable


  3. Send INVITE with Audio+T.140 sessions from UAC.

  4. Send 200 OK with Audio+T.140 sessions from UAS.

  5. Send BYE.

Platform/Feature: SBC

The code is modified to include the text stream to populate "mediaStream2Codec".
45SBX-93551 / SBX-694123

Portfix SBX-69412: o= version was not incrementing. (Originated in release 6.0.0)

Impact: The SBC responds to an Update without an incremental SDP session version.

Root Cause: Enable the "Only Selected Codec in Session Refresh", peer answer the SDP in 18x, and send an Update with a different SDP. However, the SDP version did not increment.

Steps to Replicate: Enable the "Only Selected Codec in Session Refresh", peer answer the SDP in 18x, and send an Update with a different SDP.

Platform/Feature: SBC

The SBC responds to an UPDATE with a different SDP in a previous Invite. The SBC correctly increments the SDP version.
46SBX-93492 / SBX-907112

Portfix SBX-90711: ELT: Observed Negative accepted packets at the "request sbx xrm debug command acl\ -stat".

Impact: Observed a negative packet count for the ACL and aggregate ACL while running CLI commands.

Root Cause: We were using an incorrect format specifier. We were using %d to print an unsigned long instead of %u.

Steps to Replicate: Tested with pumping packets to specific ACL. The counters are working as expected.

Platform/Feature: SBC

Corrected the format specified usage.
47SBX-937142

Unable to configure more than 2 IPIFs into 1 IPIG.

Impact: Cannot create 4 IP Interfaces under a single IPIG in Yellowfin. As Yellowfin has a single NP, a port map needs to be created for all ports on the NP0.

Root Cause: During the Yellowfin development, creating 4 IP Interfaces in the same Interface groups was not evaluated correctly.

Steps to Replicate:

1. Attempt to create 4 interface groups under the same Interface group.
2. Associate it to other signalling elements such as sipSigPort to validate NP friendly checks.

Platform/Feature: SBC

Create a port map for packet ports pkt2 and pkt3 using the NP0.
48SBX-927803

'request SBC arm debug command' commands stop working after a switchover.

Impact: Request the SBC arm debug command help is not working when a switchover was made from active box to standby one.

Root Cause: Inside the ArmCsv.c, the CsvMgObjRegisterObject() was not enabled when "request sbx arm debug command help" is configured in Debug Mode.

Steps to Replicate:

1. Setup HA.
2. Start both the boxes.
3. Run "request system admin <SBC_NAME> switchover" to do a switchover.
4. Wait for full sync let standby box come as active.
5. Run "request SBX arm debug command help" on the new active SBC (former standby SBC).

Platform/Feature: SBC: CLI, confd

Enable the CsvMgObjRegisterObject(&armCsv->csvCb, "/sbx/arm/debug") function.
49SBX-932552

Unable to change the Source Port to any port on the EMA.

Impact: Unable to change the Source Port to any port on the EMA.

Root Cause: The source port attribute is validated as an integer instead of a Alpha Numeric.

Steps to Replicate:

  1. Successfully verified the loading of the EMA Application.
  2. Successfully changed the SourcePort number from 'any' to 'int' and 'int' to 'any'

Platform/Feature: SBC

The code is modified to validate source port as type Alpha Numeric instead of an integer.
50SBX-932872

The SBC was not responding to 483 for PRACK with the Max-Forwards=0 and rfc7332ValidateMaxForwards enabled.

Impact: If the SBC received a PRACK request with the Max-Forwards header value as zero, the SBC was not rejecting the request with 483 error response.

Root Cause: The part of code was missed from the code merge from 7.2 to main branch.

Steps to Replicate:

Test steps:
1. Send PRACK with Max-Forwards 0.
2. Verify the SBC is rejecting it with 483 Error response.

Platform/Feature: SBC

The code is modified to handle Max-Forward with 0.
51SBX-911542

There is a call failure due to a FQDN in the request URI.

Impact: When the SBC sends a query for SRV record to the external server and the Peer Domain in the reqURI is disabled, the SBC intermittently sends a FQDN in the request URI of egress INVITE. The correct behavior is to send an IP and address in reqURI of egress INVITE.

Without a fix, the SBC will send a 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 the SRV record and a record is found in the cache. As a result, the SBC cannot apply the "Peer Domain in ReqURI" flag in the egress SIP message.

Steps to Replicate:

  1. Use the following configurations on the PSX:
    1. Set the IP PEER as FQDN abc.com instead of IP address.
    2. Enable "noPortNumber5060" on the IPSP (This is for done for NAPTR, SRV query)
    3. Disable "Peer Domain in the reqURI " on IPSP (This is done to ensure FQDN is not sent in egress INVITE's reqURI)
  2. Use External DNS server.
    1. Configure SRV record and A record on the external DNS server with different Time To Live values.
  3. Run high number of calls.
  4. With fix, the SBC is sending IP and Port for all the calls since Peer Domain in ReqURI is disabled.

Platform/Feature: SBC

The code is modified to have the SBC use the saved formatted SIP message when the external DNS query is made for SRV record and a record is fetched from the cache. This allows the SBC to apply the "Peer Domain in ReqURI" flag in the egress SIP message.
52SBX-93562 / SBX-933552

Portfix SBX-93355: P-Charge-Info header not relayed by the SBC in out-of-dialog MESSAGE request even though the transparency setting is enabled.

Impact: P-Charge-Info Header is not relayed transparently for OOD Message even though Transparency profile is enabled for P-Charge-Info.

Root Cause: P-Charge-Info Header is dropped in case of relay framework.

Steps to Replicate: Run the message OOD which has P-Charge-Info Header in the incoming Message and Transparency is enabled for that header.

Platform/Feature: SBC

P-Charge-Info Header is copied in case of relay framework.
53SBX-941412

Call Transfer call to PSTN gets failed second time ,when MOH is played in the initial call.

Impact: After multiple holds and resumes, if the first call transfer fails due to reject by transfer target then the transferee and transferer are reconnected successfully. For any subsequent call transfer, the SBC is rejecting the call transfer request.

Root Cause: Since, the first call transfer failed, the SBC tries to reconnect the original call. As part of this, the original call is not moving to the stable state. So, any call transfer request in such state is getting 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

Added missing code to move the original call state to the stable state during re-connection.
54SBX-934752

IngressIpPrefix data deleted when removing SMM from TG.

Impact: IngressIpPrefix data deleted when removing SMM from TG

Root Cause: When deleting SMM Profile, code is there to delete ipPrefix data as well

Steps to Replicate: Remove a SMM rule from the TG in the EMA it also deletes the ingressIpPrefix metadata causing ingress calls to fail.

Platform/Feature: SBC

Added checks not to delete ipPrefix data when we delete the SMM Profile.
55SBX-93394 / SBX-925543

Portfix SBX-92554: TTY is not enabled for EVRC and EVRCB in the H/W SBC.

Impact: TTY was not enabled for transcoded calls of EVRC and EVRCB codec in the SBC 52x0 and SBC7000 and SBC54xx.

Root Cause: TTY was disabled for unknown reasons.

Steps to Replicate:

  1. Setup EVRC/EVRCB<=>g711 call.
  2. Send media with TTY characters from G711 side.
  3. Observe the PCAP of EVRC/B. TTY has special code points in the EVRC/B. Before the fix, TTY signals were encoded as EVRC codec media. With the fix, you will observe TTY special code points in PCAP.

Platform/Feature: SBC

Enable the TTY. There is no API/CLI to enable TTY.
56SBX-936013

MS Teams Call Park has an intermittent failure.

Impact: In a Microsoft Teams environment, Microsoft has a bug in the client code that can randomly cause messages to be sent out of sequence. For example, when trying to transfer calls, Microsoft can send REFER and then INVITE with a=inactive afterwards. The out of sequence message processing was causing processing issues on the SBC and the call did not complete.

Root Cause: Microsoft agrees that their message sending is broken and are working on a fix.

Steps to Replicate: Repeatedly run Microsoft Teams Call Park scenarios. The problem is not always reproducible and is possibly dependent on the Microsoft server and location of the associated client.

Platform/Feature: SBC: MS Teams

The code is modified to be more defensive against the out of sequence messaging, such as:
1) Reject the INVITE with 491 if REFER is being processed on a call leg.
2) Reject the REFER if the SBC has an outstanding INVITE waiting to be sent.

57SBX-93532 / SBX-934732

Portfix SBX-93473: The SBC is core dumping when the diversionHistoryInfoInterworking flag is enabled in the egress IPSP.

Impact: When the interworking diverts Diversion Headers to History Info for Japan NNI, on a call where ingress SIP performs an INVITE/UPDATE due to preconditions, the SBC core dumps.

Root Cause: The cause is from a code bug.

Steps to Replicate: Make an SIP-SIP call where ingress side has preconditions, such that INVITE/UPDATE sequence is needed. The received INVITE will contain Diversion headers. Egress side is configured with an NNI profile attached to the trunk group with historyInfoInterworking enabled.

Platform/Feature: SBC

The code is modified to no longer core dump.
58SBX-93608 / SBX-917872

Portfix SBX-91787: Debian vulnerabilities are observed for Nessus scans. (Originated in release 7.2.2)

Impact: Nessus scan display vulnerabilities.

Root Cause: Many packages are out of date, which can cause vulnerability.

Steps to Replicate: Run Nessus scan.

Platform/Feature: SBC

Packages and kernels are updated to fix this issue.
59SBX-940622

Unexpected INFO was received.

Impact: DTMF inter-working from RFC 2833 to SIP INFO was not generating signal event packets and only signal-update are coming on the SWe.

Root Cause: On the SWe, due to endian mismatch from low level platforms to SIP applications, the signal event was not raised.

Steps to Replicate: Enable the DTMF inter-working and send the 2833 media from one-leg, observe the SIP signal, signal-update events on the other leg.

Platform/Feature: SBC

The code is modified so that the signal event is generated correctly.
60SBX-90831 / SBX-898602

Portfix SBX-89860: There is no bit-exactness across warp for Mode 8. (Originated in release 8.1.0).

Impact: In the case of GPU AMRWB 23.85kbps, there is no bit-exactness in the output across warps even though the same input is fed to all the warps.

Root Cause: The size of one of the scratch buffers was incorrectly used in a macro. The macro eventually led to memory corruption.

Steps to Replicate: The issue was found in the standalone test and cannot be executed outside development.

Platform/Feature: SBC

The code is modified by rectifying the size in the macro.
61SBX-90816 / SBX-903122

Portfix SBX-90312: ASAN: Heap-buffer-overflow on the address in SipFeGetCseqType. (Originated in release 8.1.0).

Impact: This issue was found during ASAN regression testing. While processing the CSEQ header, the code was reading off the end of allocated memory block.

Root Cause: The code was expecting the CSEQ string to be null terminated and it was not.

Steps to Replicate: This issue is only seen with the engineering ASAN build.

Platform/Feature: SBC

The code is updated to correctly handle the case where the CSEQ is not null terminated.
62SBX-939033

Large SIP messages in TRC are divided into several syslog messages to the rsyslog server.

Impact: TRC PDU's are broken into multiple syslog messages.

Root Cause: There was a limit to the message size of ~1.8K and TRC messages beyond that would be split into multiple syslog messages.

Steps to Replicate:

  1. Reproduce the issue.
  2. Generate TRC files (size>1800) and transfer to remote syslog server.
  3. Single TRC is broken into multiple syslog messages.

Platform/Feature: SBC

The code is modified to transfer a complete TRC PDU as one syslog message.
63SBX-935482

When the transfer call is not answered from PSTN, MS TEAMS client is unable to resume the existing call.

Impact: In a Microsoft Teams call flow where the call gets transferred and the C-party has sent back a 180 without the SDP, which triggers the SBC to play RBT and then C-party sends 183 with SDP and finally rejects with a 6xx, it can result in the SBC internally getting into a bad state. This results in the SBC not being able to resume the call and the call getting released.

Root Cause: The resource management in the SBC was getting confused on the packet service profile for the various call legs that lead to the call being released.

Steps to Replicate:

1.TEAMS to PSTN1 call.
2.TEAMS transfer call to PSTN2.
3.PSTN2 does not answer the call.
4.TEAMS resume the call and transfer again to PSTN2.

Platform/Feature: SBC

The code is modified to correctly manage the packet service profile and other call leg information so it can correctly handle the transfer rejection from C-party.
64SBX-939932

The Quality of Announcement tone played by the SBC is bad.

Impact: Bad Announcement quality.

Root Cause: A software bug in DSP was resetting the first sample of every announcement frame to zero.

Steps to Replicate:

1. The set-up requires the SBC and the PSX. A PSX script is implemented, which has information about what announcement to play and DTMF digits that need to be entered to switch to the second stage of the call.
2. Client makes a call to the SBC. In the first dip, the SBC plays the announcement configured in the script and waits for DTMF digits to be entered.
3. A route is present in the PSX for DTMF digits entered.
4. After entering digits, the PSX now goes for second dip for the new digits entered and returns a route to the SBC.
5. With this route, the SBC calls Egress end point
6. Monitor the announcement quality played at step #2.

Platform/Feature: SBC

The code is modified to not remove the first sample.
65SBX-907522

The ASAN creates a global-buffer-overflow on the address in s_finish.

Impact: This issue was found during ASAN regression testing.

The coding was reading from invalid memory block during the process of a CDB transaction completion event.

Root Cause: The code was looking for CDB worker socket that matched with the CDB transaction completion event and in a case where the worker socket did not exist,the code was reading off the end of an array.

Steps to Replicate: Run the SVT test suite using a ASAN specific build.

Platform/Feature: SBC

The code is modified to ensure it does not read off the end of the worker socket array to prevent the problem.
66SBX-922832

Transport the attribute populated twice in the RURI of INVITE request towards the peer, when the To header transparency is enabled.

Impact: A call directed to the registered endpoint has duplicated the URI parameters in the RURI.

Root Cause: Introduced in a previous release.

Steps to Replicate: Configure the TO header transparency. Endpoint registered with contact has multiple RUI parameters. Server makes a call to the endpoint. The SBC sends out an Invite with a duplicated URI parameters.

Platform/Feature: SBC

The code is modified to avoid duplicated RUL parameters in the RURI.
67SBX-932622

The SBC generates a RTCP goodbye to ingress after the 200 OK.

Impact: When 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: Root cause lies in feature completed in a previous release. The feature required that if the ingress peer does not have 100 rel support, and egress gets multiple 18xs, then the transcode is forced even though pass through is possible to support codec change.

Steps to Replicate: Enable Downstream Forking and forking response as anything except the first prov response.

PSPs are setup to perform a transcode only.

Platform/Feature: SBC

The code is modified according to the following:
1. Downstream forking is enabled.
2. Early media behavior - non FIRST PROV RESP.
3. One forking dialogue.
4. No SDP is sent in 2xx if the 18x reliable.

68SBX-931032

There is no relay of an UPDATE with the SDP when the media mode has changed and when the DRBT is configured.

Impact: When the Downstream Forking and DLRBT is enabled, an UPDATE received from the ingress are not going out to egress (UPDATE received after the media cut-thru has happened because of receipt of RTP from egress).

Root Cause: 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 legs not being marked as OA_COMPLETE due to an incomplete implementation.

Steps to Replicate: Set Downstream Forking and DLRBT as enabled.

Platform/Feature: SBC

The code is modified to mark OA_COMPLETE in all instances where the parallelRingPsp is being appended with the new SDP's received in 18x's.
69SBX-923422

Call diagnostics were not working through EMA.

Impact: Call diagnostics fails due to errors in EMA.

Root Cause: Call diagnostics fails due to the STDERR for CP commands in dumpCommonFunction.

Steps to Replicate:

  1. Open EMA-> Troubleshooting and run call diagnostics.
  2. Save the call diagnostics.
  3. Call diagnostics are saved successfully.

Platform/Feature: SBC

The code is modified by redirecting stderr to /dev/null.
70SBX-91196 / SBX-859382

Portfix SBX-85938: The SMM tears down the Operation on Early dialog, and the SBC sends CANCEL before completing the 18x transaction. (Originated in release 8.1.0)

Impact: The SMM tears down the Operation on Early dialog, and the SBC sends CANCEL before completing the 18x transaction.

Root Cause: In case of End2End, PRACK is enabled and SMMTearDownFunctionality was not working as expected.

Steps to Replicate:

1.Tested the call by triggering an SMM teardown functionality in Invite, the SBC tear downs the call as per the call flow.
2. Tested the call by triggering an SMM teardown in 180 response where PRACK is mandatory, the SBC tear downs the call by initiating a SMM Teardown as per the call flow (after PRACK-200ok is complete).
3.Tested the call by triggering a SMM Teardown in 200 OK of PRACK.
4.Tested the call by triggering a SMM Teardown in 200 OK of Invite.

Platform/Feature: SBC

The code is modified to make the SMM Teardown functionality to initiate and not to take any action if the 18x/PRACK transaction is pending and enedtoendprack is enabled. Once the response of PRACK is received/sent based on the call flow, the teardown is initiated based on the SMMTearDown action state.
71SBX-927782

The Edit route action taking a long time to complete.

Impact: The Edit Route action was taking long time and failing.

Root Cause: Use of special characters, such as # in destination National field, can cause the failure of the Edit route action.

Steps to Replicate:

  1. Create Route with special character in Destination National.
  2. Select the Route that is created in Special Character.
  3. Edit Form must be load.

Platform/Feature: SBC

A few more special characters to support Destination National field in the Edit route are allowed.
72SBX-93959 / SBX-933662

Portfix SBX-93366: The SBC is not able to update a transcode from a pass thru call.

Impact: The SBC is not able to update a transcodec call after a pass thru call.

Root Cause: In this issue, it is changing from the pass thru to transcode because the sendOnlyPreferredCodec was enabled in the IPSP and in ModifyReq(Ans Side new PSP), it is taking RxPT of old PSP.

Steps to Replicate: Tested the call by sending PCMU/G729/PCMA in the 183 call is working as expected.

Platform/Feature: SBC

In the NrmaSelectCodecEntryFromPspForXcode() function, adding a condition to overwrite the PT only if it is a valid RxPT(old psp).
73SBX-941183

EMA CLI script import stays "In Progress" if the script contains a special character.

Impact: EMA CLI script import stays "In Progress" if the script contains a special character.

Root Cause: Non printable characters are present in the error message.

Steps to Replicate:

  1. Log into EMA Application.
  2. Click on Administration->System Administration->File upload->Add the files to queue.
  3. Select the CLI file that you want import.
  4. Click on "Upload All files".

Platform/Feature: SBC

Remove Non printable characters from the error message.
74SBX-940892

SAM crash on standby SBC (SIPFE stby).

Impact: The standby SBC may core when IpPeer deletes or creates the same structure in a different zone.

Root Cause: When using the IpPeer delete, the function will fail to remove the internal data structure from the hashtable. Later on, the IpPeer will create a new structure again in a different zone, it fails to insert a new data structure into the hashtable and deletes the new data structure.

There was a logical error that still has access to the new data structure after free.

Steps to Replicate: Create an IpPeer from one zone. Delete it and create the same IpPeer in a different zone.

Platform/Feature: SBC

The code is modified to fix the initial IpPeer delete issue and ensure not the new data structure is not accessed if it is already freed.
75SBX-94667 / SBX-945802

Portfix SBX-94580: The GWSG is missing a svcGrp entry for the TG while a few duplicate entries in the srvcGrpTbl. (Originated in release 6.2.2).

Impact: Duplicate entries shown in the GWSG service group table.

Root Cause: The root problem is that the create GWSG does not validate the TG name. Currently, the GWSG only goes through the srvcGrpTbl[] and finds the first empty slot’s index. If the new index != original entry’s index, the NamedInsert() will insert SUCCESS and set duplicate entry at the new location in the table, otherwise the NamedInsert() will return FAILURE and the duplicated entry will be freed.

On the standby node, when it is coming up, the GWSG restores all GWSG_SRVC_GRP_STR from the CDB. Once configuration restore is done, the active node will start to sync over all the GWSG_SRVC_GRP_STR, which caused the standby node to have duplicate entries.

Steps to Replicate: Refer to /sonus/sw/Specs/TSBX-94580.txt.

Platform/Feature: SBC: GW-GW

The code is modified to validate if the specified name is already in the table before creating a new one.
76SBX-93562 / SBX-933552

Portfix SBX-93355: P-Charge-Info header was not relayed by the SBC in a out-of-dialog MESSAGE request, even though the transparency setting is enabled.

Impact: The P-Charge-Info Header is not relayed transparently for the OOD Message, even though the Transparency profile is enabled for P-Charge-Info.

Root Cause: The P-Charge-Info Header is dropped, in case of the relay framework.

Steps to Replicate: Run the message OOD that has the 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 a relay framework.
77SBX-943203

The SBC application is resulting in a failure after switchover.

Impact: The SBC results in a failure due to being unable to mount the DRBD post switchover.

Root Cause: Post switchover, the DRBD mount failed as one of the DRBD setup command was being run in the background, but this command needs to complete execution before mounting the DRBD.

Steps to Replicate: Bring up the SBC and perform a switchover. Verify that the switchover is successful and the SBC application comes up fine on both nodes.

Platform/Feature: SBC

The code is modified to run the DRBD command in foreground and then mount the DRBD.

78SBX-94552 / SBX-766693

Portfix SBX-76669: With the sipOod set to unlimited, MAJOR errors are displayed in DBG log.

Impact: With the sipOod set to unlimited, MAJOR errors are displayed in DBG log.

Root Cause: If the sipOod licensedMaxRateLimit is set to UNLIMITED, it was generating a TRAP and MAJOR level logging that is incorrect. 

Steps to Replicate:

Make a OOD call and no MAJOR logs be visible, as presented in the example below:

152 12242018 083916.769675:1.01.00.00493.MAJOR .SIPFE: threshold reached notification for OOD message Rate. Active OOD rate 1 and OOD Rate Limit is 0
152 12242018 083916.769675:1.01.00.00493.MAJOR .SIPFE: threshold reached notification for OOD message Rate. Active OOD rate 1 and OOD Rate Limit is 0

Platform/Feature: SBC: Application, FM/Traps and Alarms

Instead of assigning a value 0 to the variable, the value is assigned to a INTMAX.
79SBX-871192

The SAM Process may core.

Impact: The SAM Process cored due to a deadlock occurring in the SIPCM.

Root Cause: In one thread, the SSL_CTX_add_session() was trying to do cache cleanup and in another thread the SipCmOpenSSLSSessinCacheCleanup() was trying to do cache cleanup at the same time. If the cache entries exceed 20480, then the SSL_CTX_add_session() will start clearing old cache entries. At the same time, the SipCmOpenSSLSSessinCacheCleanup() is also removing entries from entries from cache. This resulted in deadlock.

Steps to Replicate: The steps cannot be replicated.

Platform/Feature: SBC

The code is modified to invoke SipCmOpenSSLSSessinCacheCleanup() only in standby mode.
80SBX-94146 / SBX-930923

Portfix SBX-93092: The npLogRotate (np log rotation) must occur on the basis of a log file size.

Impact: A New SWe_NP log used to be created everyday and used to get rotated after 10 log files. The rotation allowed very limited timeframe for SWe_NP debug log capturing.

Root Cause: The setting in npLogRotate was causing the issue.

Steps to Replicate: Analyse the SWe_NP debug logs.

Platform/Feature: SBC

Create a new SWe_NP log file when a previous file has exceeded certain size (i.e 50M) and not on a daily basis.
81SBX-91727 / SBX-914252

Portfix SBX-91425: Low MOS score on the ingress leg when both legs are recorded with LI.

Impact: Random packets losses are observed, when the called and calling number are set as LI during transcoded calls.

Root Cause: An uninitialized field of structure that is used to hold the incoming packet from DSP in SWe_NP was causing this behavior of a random packet drop.

Steps to Replicate:

  1. Setup was called and calling number as LI.
  2. Run the transcoded call.

Platform/Feature: SBC

Initialize the field correctly.
82SBX-942552

Updated the kernel configuration file that was not installed after the LSWU.

Impact: After the LSWU, the kernel configuration and grub menu is not updated properly as mentioned in the description.

Root Cause: Missing the kernel configuration and an invalid grub menu.

Steps to Replicate: Perform the LSWU and verify the grub menu and kernel configuration file in /boot.

Platform/Feature: SBC

Updated the grub menu and copied the kernel configuration after the LSWU.
83SBX-92346 / SBX-907222

Portfix SBX-90722: There was an inconsistency in generating the sonusSbxTrunkGroupOutOfResourcesNotification2 trap.

Impact: There was an inconsistency in the sonusSbxTrunkGroupOutOfResourcesNotification2 trap generation using the MTRG CAC.

Root Cause: Once the CAC resource usage reaches 100%, the SBC internally marks the congested flag and generates sonusSbxTrunkGroupOutOfResourcesNotification2 trap. During a call release, if the available/free CAC resource reaches above 15%, the SBC must disable the congestion flag. However, the SBC failed to disable/reset internal the congestion flag once the free resource reaches above 15% due to the failed generated trap. (This issue occurs only when the TG's cac callLimit is set to unlimited).

Steps to Replicate:

Procedure:
1. Run 10 calls.
2. Disconnect 2 calls.
3. Run another 2 calls.
4. Disconnect 2 calls.
5. Run another 2 calls.

Expected Result:
1. Trap must be generated when receiving the 10th call.
2. A disconnected call must be successful.
3. When receiving the 2nd call, trap must be generated.
4. Call disconnect must be successful.
5. When receiving the 2nd call, trap must be generated.

Platform/Feature: SBC

The code is modified to reset internal congestion flag when the CAC free resource reaches above 15%.
84SBX-922433

Upgrade failed from 7.1R0 to 8.1R0.

Impact: An upgrade failed between 7.1R0 to 8.1R0.

Root Cause: A mandatory node /eventLog{memusage}/servers{server1} is not created with an upgrade code.

Steps to Replicate: The steps cannot be replicated.

Platform/Feature: SBC

The code is modified to create a /eventLog{memusage}/servers{server1}.
85SBX-91729 / SBX-914672

Portfix SBX-91467: The SBC fails to populate statistics in the callCurrentStatistics under zone for the trunkgroup towards MRF. (Originated in release 8.1.0)

Impact: The SBC fails to populate statistics in the callCurrentStatistics under zone for the trunkgroup towards MRF.

Root Cause: There was code missing to populate statistics in the callCurrentStatistics under zone for the trunkgroup towards MRF

Steps to Replicate:

1) UAC sends an Invite with the PCMU.
2) UAS sends 180 Ringing without the SDP.
3) UAS sends 200 OK with the PCMA.
4) SBC sends an Invite with the m1=PCMU m2=PCMA towards the MRF.
5) MRF responds with 200 OK with m1=PCMU and m2=PCMA.
6) A PCMU-PCMA transcoded call is established.
7) Check the trunkgroupStatus for the TG towards MRF.
8) Check the callCurrentStatistics for the TG towards MRF.

Platform/Feature: SBC

The code is modified to increment the callCurrentStatistics on the MRF legs.
86SBX-92473 / SBX-915082

Portfix SBX-91508: The ASAN frees SipSgClearOtherForkedCalls. (Originated in release 8.1.0)

Impact: As part of the Call Forking testing, the SBC sends multiple requests as part of forking. When one of the forked leg answers the call, the SBC tries to clear the other forked calls. While clearing/releasing the call, some of the elements in the CCB forked structure are accessed/set even after the structure is freed.

Root Cause: This issue was reported as a part of the ASAN Testing on Call Forking regression suite in the SBC lab.

Steps to Replicate: This issue was reported as part of Call Forking feature with regression testing.

Platform/Feature: SBC

The code is modified to release the CCB forked structure at the end (after all the elements in the structure are accessed/set with the correct values).
87SBX-918932

The NOA fields for the redirecting number and the original called number are not supported in the SBC.

Impact: The NOA fields for redirecting number and original called number are not supported in X2 interception in the Service Instance messages and the Signaling Start messages.

Root Cause:

The following message types were never supported for NOA on the SBC:

Service Instance messages:
Calling Party Number
Called Party Number
Redirected From Party Number
Redirected To Party Number

Signaling Start messages:
Calling Party Number
Called Party Number
Last Redirecting Party
Original Called Party

Steps to Replicate: The steps cannot be reproduced.

Platform/Feature: SBC

A new CLI is added to support this feature.

set addressContext default intercept callDataChannel <cdc_name> 
noaParamSupport enabled/disabled


88SBX-93767 / SBX-934903

Portfix SBX-93490: The SBC duplicates the supported header in the outgoing OPTIONS.

Impact: The SBC duplicates the supported header in the outgoing OPTIONS.

Example:
Supported: timer,100rel,199,precondition,replaces,gruu
Supported: timer,100rel,199,precondition,replaces,gruu

Root Cause: When the gruu parameter was present, there was a logical issue in software that adds one additional Supported Header.

Steps to Replicate: For the Registered Endpoint, an OPTIONS message coming with supported Header having gruu parameter will cause this issue.

Platform/Feature: SBC

The code is modified so a duplicate entry is created for the supported Header.
89SBX-93687 / SBX-935722

Portfix SBX-93572: There was a LeakSanitizer in the NrmaSessDescClone.

Impact: There was a memory Leak while running the NrmaSessDescClone. Fax transmissions cannot be performed with T.38 relay mode, when the trunk group is configured as T.38FallbackToG711 and uses voice codec in the G.711-REGR.

Root Cause: As part of Additional offer creation, memory is getting added for session attributes and is not getting freed.

Steps to Replicate: Fax transmissions cannot be performed with T.38 relay mode, when the trunk group is configured as T.38FallbackToG711 and use a voice codec in the G.711-REGR.

Platform/Feature: SBC

Allocated memory is freed.
90SBX-93536 / SBX-934112

Portfix SBX-93411: The ASAN global-buffer-overflow on the address in __interceptor_vsnprintf.

Impact: This is an ASAN issue regarding the buffer overflow.

Root Cause: Boundary conditions are missing, leading to a buffer overflow.

Steps to Replicate: The steps cannot be reproduced.

Platform/Feature: SBC

The code is modified to add additional boundary conditions.
91SBX-92794 / SBX-922682

Portfix SBX-92268: The SBC fails to tear down a call towards the UAS until the 200 OK Invite timeout occurs when the MRF responds with a 3xx message.

Impact: The SBC fails to tear down a call towards the UAS until the 200 OK Invite timeout occurs when the MRF responds with a 3xx message.

Root Cause: The handling missing when the SBC receives a 3xx from the MRF server.

Steps to Replicate:

1) SBC must tear down a call towards the UAS upon receiving a 3xx from the MRF.

2) SBC must not wait for a 200 OK Invite timeout.

Platform/Feature: SBC

Disconnect the call immediately when the SBC receives a 3xx message from the MRF server.
92SBX-92336 / SBX-914462

Portfix SBX-91446: Observing a MAJOR logs flood related to SipSgRedundDeleteMrfCbData during the SSBC SWO. (Originated in release 8.1.0)

Impact: Changing to INFO from MAJOR.

Root Cause: Logs listed as INFO were kept as MAJOR.

Steps to Replicate:

  1. Initiate 1000 cps of load with 60 CHT.
  2. Once the calls are stable, initiate the SSBC SWO.

Platform/Feature: SBC

The code is modified to change unwanted MAJOR logs as INFO.
93SBX-91172 / SBX-908442

Portfix SBX-90844: The SBC must not add the 100 rel for the 180 Ringing without the SDP. (Originated in release 8.1.0)

Impact: The SBC must not add Require:100 rel for 180 Ringing when the other leg does not receive the provided E2E PRACK and the Dialog-Transparency are enabled.

Root Cause: The design was changed in between to handle 18x and PRACK leg specific.

Steps to Replicate:

  1. Enable the dialogTransparency on both egress and ingress leg.
  2. Enable the transcoderFreeTransparency flag on PSP.
  3. Enable the 'downstreamForkingSupport' flag on the egress leg.
  4. Keep the value of 'forkingBehavior' as 'lastProvResponse' in early media on Egress leg.
  5. Enable the preconditions flag on both TG. 6) Enable sdpAttributesSelectiveRelay on both TG.

Replication procedure -

  1. From the UAC, send an initial INVITE with Require header Require: 100rel
  2. From the UAS, send forked 18x with dialog d1.
  3. From the UAS, send 2nd forked 18x with dialog d2 and UPDATE from UAC for dialog d1 at the same time.
  4. Send the 3rd dialog 18x from UAS and 2nd dialog update from UAC at the same time.
  5. Send a 180 Ringing from UAS without sdp for dialog D1.

Platform/Feature: SBC

The code is modified so that the SBTM needs to relay behaviour for non-reliable 18x when the E2E PRACK and Dialog-Transparency are enabled.
94SBX-92881 / SBX-876072

Portfix SBX-87607: The SBC is unable to tear down the leg towards the MRF when the Malformed packet in a 200 OK is received with a 1 m line in the SDP from the MRF.

Impact: The SBC is unable to tear down the leg towards the MRF when the Malformed packet in a 200 OK is received with a 1 m line in the SDP from the MRF.

Root Cause: The handling is missing when the Malformed packet in a 200 OK is received with a 1 m line in the SDP from the MRF.

Steps to Replicate:

  1. USER A sends an INVITE with AMR.
  2. The SBC sends an INVITE to USER B.
  3. USER B responds with a 200 OK with EVRC codec in the SDP.
  4. The SBC sends an INVITE towards an MRF.
  5. MRF responds with a 200 OK with a 1 m line in the SDP.
  6. The SBC sends a BYE towards USER B and a 488 towards USER A.
  7. The SBC tear down the legs towards USER A and USER B, but unable to tear down the leg towards MRF.

Platform/Feature: SBC

Tear down the call when the Malformed packet in a 200 OK is received with the 1 m line in a SDP from the MRF.
95SBX-919873

Multiple 'CONFD_NOTIF_USER_SESSION' logs were in the app.latest.

Impact: Notification messages are printed in the logs.

Root Cause: Session logs are logged as MAJOR.

Steps to Replicate:

  1. Set the logs to Major.
  2. Log into the CLI.
  3. Check the logs and ensure session logs are not printed.

Platform/Feature: SBC

The code is modified to change session logs to DEBUG logs.

Known Issues

Known Issues in 07.02.04R002

There are no known issues in this release.

Known Issues in 07.02.04R001

There are no known issues in this release.

Known Issues in 07.02.04R000 

The following issues exist in this release:


Known Issues

Issue IDSevProblem DescriptionImpact/Workaround
SBX-993102

Support of Identity headers with multiple values.

Platform/Feature: SBC

Impact: The SBC supports standalone multiple Identity headers but does not support single Identity headers with multiple values, each comma separated. 

Workaround: Use the SMM to separate out the comma separated list into individual standalone Identity headers.

SBX-94948

2

On attaching dnsGroup to zone, the SBC failed to link dnsGroup Id with all the TGs of the corresponding zone.

Platform/Feature: SBC

Impact: The SBC uses an incorrect DNS group to resolve the FQDN associated with diameter peer.

Workaround:

  1. After setting the dnsGroup configuration, perform a manual switchover (so during an application restart and all configuration restored properly).
  2. The dnsGroup has to be attached to zone before creating TGs under this zone. When a new TG is created under the zone, it will read as a configured dnsGroup id.

Known Issues in 07.02.02R000 and 07.02.03R000

There are no known issues in this release. 

Known Issues in 07.02.01R002 

The following issue exists in this release:


Known Issues

Issue IDSevProblem DescriptionImpact/Workaround
SBX-877402

LI call not working when standby MSBC is upgraded.

Platform/Feature: SBC

Impact: Interception of LI calls fail during upgrade (for instance, when the setup has S-SBC and the M-SBC running on different versions). The impact is only for in-service upgrade. No impact with respect to LI calls, when the VNF is brought down and re-created for upgrade..

Workaround: No workaround available.

Known Issues in 07.02.01R001 Release 

The following issue exists in this release:


Known Issues

Issue IDSevProblem DescriptionImpact/Workaround
SBX-880031

 If there are any PRACK drops and call fails, a memory leak occurs.

Platform/Feature: SBC

Impact: In the rare case where a PRACK for 18x is dropped and the call eventually fails, a small leak of SCM memory can occur.

Workaround: No workaround available.

Known Issues in 07.02.01R000 Release 

The following issues exist in this release:


Known Issues

Issue IDSevProblem DescriptionImpact/Workaround
SBX-85825 2

When a headend cluster configuration is pushed, the Standby SBC reboots and hangs without getting the Configuration.

When a Standby SBC is rebooted, it transitions to registered online then later unregistered offline. This also happens in #1, Standby reboot after Configuration is pushed.

Platform/Feature: SBC Core: EMA

Impact: When a headend cluster configuration is pushed, Standby SBC fails to download the configuration and so fails to come up properly.

Workaround: To resolve the above issue, the fill rate and bucket size needs to be increased in lca.py script and the Standby SBC system needs to be rebooted so that it can download the configuration again.

SBX-863542

CallMedia and CallDetailstatus do not show in the EMA during the load run.

Platform/Feature: SBC Core: EMA

Impact: Call details Status and Call Media Status are intermittently not visible in the EMA.

Workaround: Call details status and Call Media status can be viewed from CLI.

SBX-852282

Observed M-SBC reboot and PrsProcess crash during 30000 NP based tones playing.

Platform/Feature: SBC Cloud

Impact: Under load with 30,000 simultaneous NP tones playing M-SBC switches over. M-SBC system confirmed to perform fine up to 28,000 simultaneous NP tones.

Workaround: No workaround available.

Known Issues in 07.02.00R002 Release 

The following Severity 1 issues exist in this release:


Known Issues

Issue IDSevProblem DescriptionImpact/Workaround

SBX-86003

1

While UPDATE is pending and a subsequent 18x is received on Egress, the SBC includes SDP in the subsequent 18x on Ingress.

Platform/Feature: SBC Core: SIP Application

Impact: The peer may reject the call.

Workaround: No workaround available.

The following Severity 2/3 issues exist in this release:


Known Issues

Issue IDSevProblem DescriptionImpact/Workaround
SBX-850713

The SBC did not like the <4K size INVITE PDU since the maxPduSizeValue = 6K.

Platform/Feature: SBC

Impact: A PDU of a size less than 6K is rejected with 400 Bad Request, when maxPduSizeValue is set to 6K.

Workaround: Increase the maxPduSizeValue to 15k.

SBX-770542

An LSWU Upgrade from 7.0 to 7.1 failed.

Platform/Feature: SBC 5000/7000 Series: Application

Impact: While upgrading from pre-7.1 releases to 7.1 and 7.2 releases, if the SNMP trap targets are setup with <space> in the name field then the upgrade fails. This affects all the platforms (SBC 5xxx/7xxx/SWe).

Workaround: Prior to the upgrade, the user must check and delete/replace any trap targets that are setup with <space> in the name.

SBX-860942

Call fail after onhold and offhold.

Platform/Feature: SBC Core: SIP Application


Impact: A call onhold/offhold before being connected by Update may fail.

Workaround: Enable E2E Update.


SBX-858592

A race condition occurs under a 3x load scenario where MRF is configured as FQDN and none of the MRF server responds.

Platform/Feature: SBC: DSBC

Impact: The SCM process may core dump.

Workaround: No workaround available.



Known Issues in 07.02.00R001 Release 

The following issues exist in this release:


Known Issues

Issue IDSevProblem DescriptionImpact/Workaround
SBX-760662

The SBC is discarding media packets when the SBC is monitoring and media packets are received from IPV6 terminated peer.

Platform/Feature: SBC CE: Application

Impact:

The RTP monitoring feature will not work for IPv6 terminated peers, and therefore the following behavior will be observed.

  1. If The SBC is in tone playing state and expecting media cut through after successful monitoring, the SBC will continue the tone play even though the expected RTP packet count is received, which is discarded by the SBC because of this issue.
  2. If the SBC does not have conditions for delayed tone play, is not in tone playing state and is expecting media cut through after successful monitoring, the SBC will discard media packets because of this issue.
  3. If the SBC has conditions for delayed tone play, is not in tone playing state, and is expecting media cut through after successful monitoring, the SBC will discard media packets because of this issue and therefore the delayed tone play starts because of the monitoring failure.

Workaround: no workaround for IPv6, but the same feature works for IPv4.

SBX-850713

The SBC did not like the <4K size INVITE PDU since the maxPduSizeValue = 6K.

Platform/Feature: SBC

Impact: A PDU of a size less than 6K is rejected with 400 Bad Request, when maxPduSizeValue is set to 6K.

Workaround: Increase the maxPduSizeValue to 15k.

SBX-770542

An LSWU Upgrade from 7.0 to 7.1 failed.

Platform/Feature: SBC 5000/7000 Series: Application

Impact: While upgrading from pre-7.1 releases to 7.1 and 7.2 releases, if the SNMP trap targets are setup with <space> in the name field then the upgrade fails. This affects all the platforms (SBC 5xxx/7xxx/SWe).

Workaround: Prior to the upgrade, the user must check and delete/replace any trap targets that are setup with <space> in the name.


Known Issues in 07.02.00R000 Release

The following Severity 1 issues exist in this release:


Known Issues

Issue ID

Sev

Problem Description

Impact/Workaround

SBX-74179


1

Cannot ping the G/W from the V6 interface alternatively when Alt_IP's are configured in X710 NIC card server.

Platform/Feature: SBC CE: Application, Platform

Impact: IPv6 with X710 NIC cards in SRIOV mode will not work as multicast packets will be dropped by the PF.

Workaround:

Set the trust mode to "on" for all the VFs on the computes.

ip link set dev <PF name> VF <vf id> trust on

This needs to be done for all computes and all created VFs (this change is not persistent across reboots). This will allow Multicast promiscous mode to work.

Otherwise, add a static neighbor table entry on the remote servers connecting to the SBC using the following command:

ip -6 neigh add <IPv6 address> lladdr <link-layer address> dev <device>

SBX-73218


 1

The S-SBC is unable to register 1M endpoints with 1000 RPS and is having a 180 second refresh Register with RHEL 7.5, RHOSP 13 (Queens) setup.

Platform/Feature: SBC CE: Application

Impact: Virtual ports intermittently stop responding on compute node running on RHOSP 13 (Queens) under certain conditions. Specifically, at 1000 RPS with refresh registration interval at 180 seconds, virtual ports stop responding after reaching 500K registrations. This issue is not seen when the refresh registration interval is configured as 200 seconds and above

Workaround: Use SR-IOV ports only when using RHOSP 13 (Queens) release.

The following Severity 2, 3, and 4 issues exist in this release:


Known Issues

Issue ID

Sev

Problem Description

Impact/Workaround

SBX-73943


2

The SBC does not add all codecs when Update is received with updated SDP from egress and sends 200 OK for Update with all supported codecs towards egress, the SBC is playing tone.

Platform/Feature: SBC Core: Application

Impact: The call signaling and media work properly, but media clipping can occur if the final cut-thru codec received from UAS is different from the codec that is being used for playing tone. 

Workaround: No workaround available.

SBX-74945

 4

Unable to commit pkt and sip-sig config with single commit command. An error message is thrown when the commit command is given.

Platform/Feature: SBC Core: CLI

Impact: Commit cannot be issued in for all set commands until the ipInterfacegroup is committed.

Workaround: Commit should be issued for ipInterfacegroup first and then commit for the remaining set commands can be executed.

SBX-73660


 2

Unable to view TRAPS under Fault Management in Cloud-ISBC (Openstack Nova Platform) in EMS.

Platform/Feature: SBC CE: Application, EMA/EMS

Impact: EMS will not be able to identify the trap since the source IP address is packet interface.

Workaround: Add a static route to EMS from the SBC through management interface.

SBX-725132

Memory congestion was observed when executing around 64K calls in the 32GB SWe system.

Platform/Feature: SBC SWe: SIP-Peering

ImpactOn a SWe system with 32GB 32vCPU, the SBC is only able to scale up to 60K calls instead of 64K, due to per call memory increase.

Workaround: No workaround available.

SBX-713032

Observing 503 response for more time post port SWO in S-SBC.

Platform/Feature: SBC CE: Application

Impact: The load is 1000cps/120K calls. After doing port SWO on S-SBC, SBX rejects calls with a 503 response for 86 seconds. Later SBX again responds with 503 responses for approx 36 seconds. After that, it stabilizes.

Workaround: No workaround available.

SBX-727362

The SBC is not able to handle 150 Sa/Sec IPsec load on the Yellowfin Platform.

Platform/Feature: SBC 5000/7000 Series: SIP

Impact: If the rate for IPsec SA setup using IKE is increased beyond 60 SA/s, errors are seen.

Workaround: No workaround available.

SBX-72652


2

The PSBC observing system is in continuous iRTT congestion during the overload test.

Platform/Feature: SBC CE: Application

Impact: IRTT congestion is observed continuously for the 15 mins duration of 3x overload. There is no congestion during normal 1x load. This is 1000cps/120K in DSBC (PSBC).

Workaround: No workaround available.

SBX-745462

The SBC failed to generate Enum lookup after updating the dynamic metaVariable.

Platform/Feature: SBC CE: Application

Impact: Enum lookup fails to generate if the meta variable related to sipSigPort (used for the Enum lookup) is dynamically updated.

Example:

Before updating sipSigPort with new dynamic metaVariable:

admin@vsbc1% show global servers lwresdProfile

lwresdProfile DEFAULT {

    description          DEFAULT;

    enumDomainNameLabel  DEFAULT_ZONE_LABEL;

    enableLwresdLog      disable;

    type                 signalingIp;

    addressContext       default;

    eDnsGlobalBufferSize 4096;

    eDnsMonitorInterval  120;

    zone                 ZONE_ING_V6;

    sipSigPort           3;

    ipInterfaceGroupName LIG_ING_V6;

}

admin@vsbc1% show addressContext default zone ZONE_ING_V6 sipSigPort

sipSigPort 3 {

    ipInterfaceGroupName      LIG_ING_V6;

    portNumber                5060;

    mode                      inService;

    state                     enabled;

    transportProtocolsAllowed sip-udp,sip-tcp;

    ipVarV6                   IF2.IPV6;

}

[root@VSBCSYSTEM-vsbc1 linuxadmin]# lsof -ni:5060

COMMAND     PID       USER   FD   TYPE  DEVICE SIZE/OFF NODE NAME

CE_2N_Com 32059 sonusadmin  110u  IPv6 3716854      0t0  UDP [fd00:10:6b50:5d20::c9]:sip

CE_2N_Com 32059 sonusadmin  111u  IPv6 3716855      0t0  TCP [fd00:10:6b50:5d20::c9]:sip (LISTEN)

CE_2N_Com 32059 sonusadmin  112u  IPv6 3716856      0t0  UDP [fd00:10:6b50:5d20::a9]:sip

CE_2N_Com 32059 sonusadmin  113u  IPv6 3716857      0t0  TCP [fd00:10:6b50:5d20::a9]:sip (LISTEN) 

ENUM query is successful from sipSigport (fd00:10:6b50:5d20::a9)

After updating sipSigport to new dynamic metaVariable:

admin@vsbc1> show table system metaVariableDynamic

CE NAME              NAME     VALUE                 

-----------------------------------------------------

vsbc1-10.34.195.109  lpl_egg  fd00:10:6b50:5d20::c9 

vsbc1-10.34.195.109  lpl_ing  fd00:10:6b50:5d20::c7 

admin@vsbc1% show addressContext default zone ZONE_ING_V6 sipSigPort

sipSigPort 3 {

    ipInterfaceGroupName      LIG_ING_V6;

    portNumber                5060;

    mode                      inService;

    state                     enabled;

    transportProtocolsAllowed sip-udp,sip-tcp;

    ipVarV6                   lpl_ing;

}

[root@VSBCSYSTEM-vsbc1 linuxadmin]# lsof -ni:5060

COMMAND     PID       USER   FD   TYPE  DEVICE SIZE/OFF NODE NAME

CE_2N_Com 32059 sonusadmin  110u  IPv6 3716854      0t0  UDP [fd00:10:6b50:5d20::c9]:sip

CE_2N_Com 32059 sonusadmin  111u  IPv6 3716855      0t0  TCP [fd00:10:6b50:5d20::c9]:sip (LISTEN)

CE_2N_Com 32059 sonusadmin  112u  IPv6 3716856      0t0  UDP [fd00:10:6b50:5d20::c7]:sip

CE_2N_Com 32059 sonusadmin  113u  IPv6 3716857      0t0  TCP [fd00:10:6b50:5d20::c7]:sip (LISTEN)

ENUM query is not picking new sipSigport (fd00:10:6b50:5d20::c7) updated with dynamic metaVariable


Workaround: Do not update the metavvariable associated with a sipSigPort if Enum is being used.

Example:

Don't update the sipSigport to new metaVariable

admin@vsbc1% show addressContext default zone ZONE_ING_V6 sipSigPort

sipsigPort 3 {

    ipInterfaceGroupName      LIG_ING_V6;

    portNumber                5060;

    mode                      inService;

    state                     enabled;

    transportProtocolsAllowed sip-udp,sip-tcp

    ipVarV6                   IF2.IPV6;

}

SBX-756092

The SBC VM is failing to join back the cluster post switchover after healing (Recreate_destroy) N:1 MSBC VM.

Platform/Feature: SBC CE: Install/Upgrade(Platform)

 Impact: The Ribbon VNF Manager provides functionality to manually heal a VM within an  orchestrated VNF.  There are a number of options for healing provided, including a Recreate_destroy option.  There is an issue if the Recreate_destroy is executed on a VM that has DHCP enabled on its interfaces.  In this case, the VM is provided new IP addresses, causing that VM to be unable to re-join in the cluster.

Workaround: There is no workaround that is not service impacting.  Do not execute the Recreate_destroy option on a VM that has DHCP enabled.

SBX-742692

The IPv6/v4 Interface update with a new dynamic meta Variable is not deleting the old IP address.

Platform/Feature: SBC CE: Application

Impact: The old IP address is not getting deleted when the ipInterfaceGroup is updated with new dynamic meta variable.

Example:

Before updating ipInterfaceGroup with dynamic metaVariable:

admin@vsbc1> show table system metaVariable | match IF2.IPV6

vsbc1-10.34.195.109  IF2.IPV6      fd00:10:6b50:5d20::a9 

admin@vsbc1% show addressContext default ipInterfaceGroup LIG_ING_V6

ipInterface PKT_ING_V6 {

    ceName      SSBCACTIVE;

    portName    pkt0;

    mode        inService;

    state       enabled;

    ipVarV6     IF2.IPV6;

    prefixVarV6 IF2.PrefixV6;

    vlanTagVar  IF2.VlanId;

}

pkt0.609  Link encap:Ethernet  HWaddr fa:16:3e:ee:70:92 

          inet6 addr: fd00:10:6b50:5d20::a9/60 Scope:Global

          inet6 addr: fe80::f816:3eff:feee:7092/64 Scope:Link

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:8954 errors:0 dropped:0 overruns:0 frame:0

          TX packets:9060 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:0

          RX bytes:780288 (762.0 KiB)  TX bytes:902476 (881.3 KiB)                                                          

Creating dynamic metaVariable:

admin@vsbc1> show table system metaVariableDynamic

CE NAME              NAME  VALUE                 

--------------------------------------------------

vsbc1-10.34.195.109  lpl   fd00:10:6b50:5d20::cf 

vsbc1-10.34.195.110  lpl   fd00:10:6b50:5d20::ff 

[ok][2018-11-13 07:11:41]

After updating ipInterfaceGroup with dynamic metaVariable (lpl) old IP (IF2.IPV6) is not deleted from interface

admin@vsbc1% show addressContext default ipInterfaceGroup LIG_ING_V6

ipInterface PKT_ING_V6 {

    ceName      SSBCACTIVE;

    portName    pkt0;

    mode        inService;

    state       enabled;

    ipVarV6     lpl;

    prefixVarV6 IF2.PrefixV6;

    vlanTagVar  IF2.VlanId;

}

pkt0.609  Link encap:Ethernet  HWaddr fa:16:3e:ee:70:92 

          inet6 addr: fd00:10:6b50:5d20::a9/60 Scope:Global

          inet6 addr: fe80::f816:3eff:feee:7092/64 Scope:Link

          inet6 addr: fd00:10:6b50:5d20::cf/128 Scope:Global

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:9093 errors:0 dropped:0 overruns:0 frame:0

          TX packets:9209 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:0

          RX bytes:792396 (773.8 KiB)  TX bytes:917382 (895.8 KiB)


Workaround: To change an addressContext ipInterfaceGroup to use a different ipVarV6 you must delete the ipInterfaceGroup and recreate it.

Example:

Delete the interface group:

 delete addressContext default ipInterfaceGroup LIG_ING_V6

Create interface group with new dynamic metaVariable:

admin@vsbc1% show addressContext default ipInterfaceGroup LIG_ING_V6

ipInterface PKT_ING_V6 {

    ceName      SSBCACTIVE;

    portName    pkt0;

    mode        inService;

    state       enabled;

    ipVarV6     lpl;

    prefixVarV6 IF2.PrefixV6;

    vlanTagVar  IF2.VlanId;

}

pkt0.609  Link encap:Ethernet  HWaddr fa:16:3e:ee:70:92 

          inet6 addr: fd00:10:6b50:5d20::cf/60 Scope:Global

          inet6 addr: fe80::f816:3eff:feee:7092/64 Scope:Link

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:9093 errors:0 dropped:0 overruns:0 frame:0

          TX packets:9209 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:0

          RX bytes:792396 (773.8 KiB)  TX bytes:917382 (895.8 KiB)

 Note: Similar procedure for IPV4.

SBX-758473

The RTCP port is not transparently passed in Direct Media.

Platform/Feature: SBC Core: Application

Impact: In case of a Direct Media call, the SBC will add an RTCP port in the outgoing INVITE SDP, when RTCP is enabled on Egress PSP and the RTCP port was not received in the incoming INVITE SDP.

Workaround: Disable RTCP flag on Egress PSP.

set profiles media packetServiceProfile PSP_DM_DTLS rtcpOptions rtcp disabled


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 7.2, 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 M-SBCs in an N:1 Redundancy Group for the relevant procedure. 

Restricted Functionality with SBC

The following functionalities are not supported with SBC Microservices:

  1. SRTP
  2. Far end NAT traversal
  3. DTMF inter-working
  4. RTCP termination for pass-through calls
  5. Direct Media and Antitrombone
  6. NICE, SIP-REC
  7. Rx, Rf interfaces
  8. Multimedia - MSRP, BFCP  
  9. Fax detection
  10. ICE/STUN
  11. SIP REFER
  12. SIP REPLACE
  13. Two stage calls

  14. H323 support
  15. GW signaling support
  16. Network Licensing Limitations

After switchover during grace period, when the new standby SBC comes up and establishes itself as standby, there is a short period (a few minutes) when the standby is synchronized for normal operation, but the new standby has not yet completed establishing its licensing state using the grace license information. If there is a second SBC switchover during that window, the new active SBC (which became active before completing license state synchronization) will lose calls until it re-acquires the grace licenses.

For configuring Network Wide Licensing, refer to Configuring Network Wide Licensing on D-SBC. This procedure is common for D-SBC and SBC.