SBC Core 08.02.00R000 Release Notes

About SBC Release Notes

This release note describes new features, the latest hardware and software requirements, known limitations and other pertinent release information for the latest release of SBC Core.

Please note that all Ribbon bugs reported by customers on a given software release will be fixed in the latest release on that software release branch.

To view and download the latest End of Product Sale (EoPS) and other End Of Life (EOL) notices, navigate to the Resource Library on the corporate website (https://ribboncommunications.com/company/get-help/resource-library).

Release Notes Use and Distribution

Ribbon Release Notes are protected under the copyright laws of the United States of America. This work contains proprietary information of Ribbon Communications, Westford, MA-01886, USA. Use, disclosure, or reproduction in any form is strictly prohibited without prior authorization from Ribbon Communications.

Associated Ribbon Announcements

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

Warning-17-00022847: The DNS configuration parameters within the address contexts may cause certain configurations to fail during an upgrade
Warning-17-00022689: Duplicate Trunk Group or Zone names can cause unexpected behavior
Warning-14-00020748: Verify system and databases are fully in sync prior to Live Software Upgrade (LSWU). Applies to all SBC platforms (HW, SWe, Cloud) except for SBC's deployed in a Distributed SBC (D-SBC) architecture.
Bulletin-18-00028529: The System Security Intrusion Detection AIDE Reports False Positive Alarms
Warning-21-00029972: The SBC upgrade may truncate the SQL configuration database due to too many historical alarms.

To view/download Ribbon announcements, do the following:

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

Problems or Questions

For problems or questions, contact the Global Support Assistance Center:

Ribbon Support Portal: https://ribboncommunications.com/services/ribbon-support-portal

Voice: +1-833-RIBBON1 (1-833-742-2661)

About SBC Core

The SBC Core platforms address the next-generation needs of SIP communications by delivering media transcoding, robust security and advanced call routing in a high-performance, 2RU, and 5RU form-factor devices enabling service providers and enterprises to quickly and securely enhance their network by implementing services like SIP trunking, secure Unified Communications and Voice over IP (VoIP).

For more product information, refer to the section About SBC Core in the main documentation space.

Interoperability

The SBC Core software interoperates with the following:

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

H.323-SIP and SIP-H323 Calls

When using H.323-SIP and SIP-H.323 call flows, an additional Re-invite/Update may get generated towards the SIP side. To suppress this, enable the IP Signaling Profile (IPSP) flag Minimize Relaying Of Media Changes From Other Call Leg at the SIP side.

For CLI IPSP flag details, refer to Flags - CLI.
For EMA IPSP flag details, refer to Common Ip Attributes - Flags.

Note

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

Compatibility with Ribbon Products

Tip

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

Info

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

Refer to SBC Core Portfolio Interoperability Matrix for the latest and minimum compatible product versions supporting the 08.02.00R000 release.

Sample Heat Templates Included in This Release

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

SBC Heat Templates

Template Name	Description
heatRgNoDhcp.yaml	Used to instantiate no DHCP, IPv4 or IPv6 deployments. The template supports I-SBC, M-SBC, S-SBC, MRFP and SLB node types. This template includes instructions to enable port redundancy.
heatOamNoDhcp.yaml	Used to instantiate an OAM node.
heatRgNoDhcp-TSBC-template.yaml	Used to instantiate a T-SBC node.

Note

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

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

SBC SWe Cloud Requirements for OpenStack

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

Server Hardware Requirements

Configuration	Requirement
Processor	Intel Xeon processors (Nehalem micro-architecture or above) with 6 cores and above (processors should support hyper-threading). Note Ribbon recommends Westmere (or newer) processors for better SRTP performance. These processors have the AES-NI instruction set for performing cryptographic operations in hardware.
RAM	Minimum 24 GiB
Hard Disk	Minimum 100 GB
Network Interface Cards (NICs)	Minimum 4 NICs. Note Make sure NICs have multi-queue support which enhances network performance by allowing RX and TX queues to scale with the number of CPUs on multi-processor systems. Note The Intel I350, x540, x550, and 82599 Ethernet adapters are supported for configuring as SR-IOV and DirectPath I/O pass-through devices. Note The PKT ports must be 10 Gbps SR-IOV enabled ports. Note 6 NICs are required to support PKT port redundancy.

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

S-SBC SWe Requirement

S-SBC SWe Requirements for 1000 CPS/120K Signaling Sessions	Notes
32 vCPUs	Due to the workload characteristics, allocate 20 physical cores with two hyper-threaded CPUs from each core to the SBC.
128 GiB RAM	Must be Huge Page memory. The minimum page size is 2048 KiB, but 1048576 is recommended.
100 GB Disk	None
4 vNICs/6 vNICs	Attach MGT0 port to the Management VirtIO Tenant network. HA port has to be on IPv4 VirtIO Tenant network. Attach PKT0 and PKT1 ports to SR-IOV and Provider network. You must have 6 vNICs to enable PKT port redundancy. For more information, refer to the SBC SWe Features Guide.

M-SBC SWe Requirement

M-SBC SWe Requirements for 40K Media Sessions	Notes
16 vCPUs	Due to the workload characteristics, allocate 10 physical cores with two hyper-threaded CPUs from each core and from single NUMA node to the SBC.
32 GiB RAM	Must be Huge Page memory. The minimum page size is 2048 KiB, but 1048576 is recommended.
100 GB Disk	None
4 vNICs/ 6 vNICs	Attach MGT0 port to the Management VirtIO Tenant network. HA port has to be on IPv4 VirtIO Tenant network. Attach PKT0 and PKT1 ports to SR-IOV and Provider network. You must have 6 vNICs to enable PKT port redundancy. For more information, refer to the SBC SWe Features Guide.

Note

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

OpenStack Requirements

The SBC SWe supports the following OpenStack environments:

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

Note

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

SBC SWe Requirements for KVM

The following table lists the server hardware requirements.

KVM Hypervisor Server Hardware Requirements

Configuration	Requirement
Processor	Intel Xeon processors (Nehalem micro-architecture or above) with 6 cores and above (processors should support hyper threading). Note Ribbon recommends using Westmere (or newer) processors for better SRTP performance. These processors have the AES-NI instruction set for performing cryptographic operations in hardware. Note The supported CPU Family number is 6 and CPU Model number must be newer than 26. Refer to the Intel Architecture and Processor Identification document for more information.
RAM	Minimum 24 GB
Hard Disk	Minimum 500 GB
Network Interface Cards (NICs)	Minimum 4 NICs Note Make sure NICs have multi-queue support which enhances network performance by allowing RX and TX queues to scale with the number of CPUs on multi-processor systems. Note The Intel I350, x540, x550, and 82599 Ethernet adapters are supported for configuring as SR-IOV and DirectPath I/O pass-through devices.
Ports	Number of ports allowed: 2 Management ports. For more information on the second Management port, refer to Second Management Port for SWe Deployed on KVM Hypervisor. 1 HA port 2 Media ports

SBC SWe Requirements for VMWare

Warning

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

The following table lists the server hardware requirements:

Server Hardware Requirements

Configuration	Requirement
Processor	Intel Xeon processors (Nehalem micro-architecture or above) with 6 cores and above (processors should support hyper threading). Note Ribbon recommends using Westmere (or newer) processors for better SRTP performance. These processors have the AES-NI instruction set for performing cryptographic operations in hardware. Note The supported CPU Family number is 6 and CPU Model number must be newer than 26. Refer to the Intel Architecture and Processor Identification document for more information. Note ESXi 6.5 and later releases require approximately 2 physical cores to be set aside for hypervisor functionality. The number of VMs which can be hosted on a server must be planned for accordingly.
RAM	Minimum 24 GB
Hard Disk	Minimum 500 GB
Network Interface Cards (NICs)	Minimum 4 NICs, if physical NIC redundancy is not required. Note Make sure NICs have multi-queue support which enhances network performance by allowing RX and TX queues to scale with the number of CPUs on multi-processor systems. Note The following NICs are supported for configuring as SR-IOV and DirectPath I/O pass-through devices. SR-IOV is supported only with 10 Gbps interfaces (x540/82599/x710): Intel I350, x540, x550, x710 and 82599, Mellanox Connect - 4x, and Mellanox Connect - 5x. The VMware Enterprise Plus license is required for SR-IOV.
Ports	Number of ports allowed: 2 Management ports. For more information on the second Management port, refer to Second Management Port for SWe Deployed in VMware. 1 HA port 2 Media Ports (no port-redundancy) 4 Media ports (with port-redundancy)

Requirements for Using the Infrastructure as Code Environment with SBC SWe

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

iac-1.1-20190808-060356.tar.gz

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

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

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

Required Software and Firmware Versions

The following SBC 51x0/52x0, SBC 5400 and SBC 7000 software and firmware versions are required for this release. For 5xx0, the BIOS is installed during application installation; whereas, for 5400 and 7000, the BMC/BIOS is included in the firmware package and installed during the firmware upgrade.

Required Software and Firmware Versions

Components	Software/Firmware	Version
SBC Platform	SBC 51x0/52x0 BMC	V03.21.00-R000
	SBC 51x0/52x0 BIOS	V2.7.0
	SBC 5400 Firmware	BMC: V03.21.00-R000 BIOS: V1.18.0
	SBC 7000 Firmware	BMC: V03.21.00-R000 BIOS: V2.14.0
SBC Application	Operating System (OS) Version	V07.02.00-R000
	SonusDB	V08.02.00-R000
	SBC Application	V08.02.00-R000

Note

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

How to Verify Currently Installed Software/Firmware Versions

Use the EMA to verify the currently installed software and firmware versions.

Log on to the EMA, and from the main screen navigate to Monitoring > Dashboard > System and Software Info.

Software Bundles

The following software release bundle is available for download from the Customer Portal:

SBC5x7x_8.2

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

SBC 5000 Series (51x0/52x0) Firmware

firmware-5XX0-V03.21.00-R000.img
firmware-5XX0-V03.21.00-R000.img.md5
bmc5X00_v3.21.0-R0.rom.md5sum
bmc5X00_v3.21.0-R0.rom

SBC 5400 Firmware

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

SBC 7000 Series Firmware

firmware-7X00-V03.21.00-R000.img
firmware-7X00-V03.21.00-R000.img.md5

Note

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

SBC Core Operating System Installation Package

The ConnexIP Operating System installation package for SBC Core:

sbc-V08.02.00R000-connexip-os_07.02.00-R000_4_amd64.iso
sbc-V08.02.00R000-connexip-os_07.02.00-R000_4_amd64.iso.md5

Note

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

SBC Core Application Package

The SBC Application installation and upgrade package for SBC Core:

sbc-V08.02.00R000-connexip-os_07.02.00-R000_4_amd64.qcow2
sbc-V08.02.00R000-connexip-os_07.02.00-R000_4_amd64.qcow2.md5
sbc-V08.02.00-R000.x86_64.tar.gz
sbc-V08.02.00-R000.x86_64.md5
sbc-V08.02.00-R000.x86_64.signature

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

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

These files are for SBC SWe deployments in the OpenStack cloud using VNFM.

For VNFM deployment, the VNF Descriptor (VNFD) file is provided in a Cloud Service Archive (CSAR) package for the type of SBC cluster being deploying. VNFs are independent and CSAR definitions are imported into the VNFM via an Onboarding mechanism. There is a procedure for producing the required CSAR variant, for different personalities (S-SBC, M-SBC), different interface types (virtio, sriov).

Files required for CSAR creation:

createVnfmCsar.py
vnfmSol001VnfdTemplate.yaml
sbc-V08.02.00R000-connexip-os_07.02.00-R000_4_amd64.qcow2

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

For details on CSAR creation, refer to Creating a CSAR Package File.

Upgrade Notes

Warning

A LSWU on an SBC 7000 should only be performed when the total number of active calls on the system is below 18,000. If the criteria is not met, a double failure during the upgrade may occur, thereby losing all active calls. If such a failure occurs, both active and standby SBC services will go down. Contact Ribbon Support immediately.

Note

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

Note

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

Note

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

Note

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

Note

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

Note

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

Note

The number of rules across SMM profiles in a system is limited to 10000, and the number of actions across profiles in a system is limited to 50000.

Ensure the above conditions are met before LSWU.

Note

In NFV environments, the method used for upgrades involves rebuilding the instance, which requires additional disk space on the host. The minimum disk space needed for this operation is listed in the table below.

Disk Space Requirements

Flavor	Extra Space Required (GB)
S-SBC	80
M-SBC	80
PSX-M	360
PSX-S	360
PSX-Test	360
EMS_SA	150

Note

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

Note

SWe SBC software enforces I-SBC instances to run only with a single vNUMA node in order to achieve deterministic performance. SWe SBC VM having >8 vCPUs hosted on dual-socket physical server with VMware ESXi software needs to follow the steps below to correct vNUMA topology before upgrading to latest SWe SBC software:

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

vsish -e get /net/pNics/<PKT port name - vmnicX>/properties | grep "NUMA"

If any of the above settings requires modification, follow the steps below on SWe SBC HA system:

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

numa.autosize.once = FALSE

numa.nodeAffinity’ = 0 or 1 (based on PKT port NIC affinity)

On ESXi 6.5 and above releases, vSphere web client can be used to add above rows under Edit settings > VM options > configuration parameters > add parameters;

On ESXi 6.0 and below releases, it can be added under Edit > Advanced > general > configuration parameters > add rows using vSphere client.

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

For more information, refer to:

08.02.00R000 Upgrade Information

Warning

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

Usernames can begin with A-Z a-z _ only.
Usernames cannot start with a period, dash, or digit.
Usernames can contain a period(.), dash(-), alphabetic characters, digits, or underscore(_).
Usernames cannot consist of digits only.
Usernames can contain a maximum of 23 characters.

The following names are not allowed:

tty disk kmem dialout fax voice cdrom floppy tape sudo audio dip src utmp video sasl plugdev staff users nogroup i2c dba operator

Note: Any CLI usernames consisting of digits only or not conforming to new user naming rules will be removed after performing a restore config in release 8.2.0R000.

Warning

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

Warning

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

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

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

Preparing for Upgrade (All Platforms)

Warning

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

Note

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

Warning

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

Supported Live Software Upgrade (LSWU) Paths

Attention

This release includes all bug fixes implemented in the releases which are documented in the Supported Upgrade Paths table of this release note.

To view bug fixes in previous releases, refer to the release note(s) of interest from the SBC 5xx0-7000-SWe Documentation Home page.

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

Supported Upgrade Paths

V06.xx	V07.xx	V08.xx
V06.00.00R000	V07.00.00R000	V08.00.00R000
V06.00.00R001	V07.00.00F001	V08.01.00R000
V06.00.00F001	V07.00.00F002	V08.01.00R001
V06.00.00F002	V07.00.00F003
V06.00.00F003	V07.00.00F004
V06.00.00F004	V07.00.00F005
V06.00.00F005	V07.00.00F006
V06.00.00F006	V07.01.00R000
V06.00.00F007	V07.01.00R001
V06.00.00F008	V07.01.00R002
V06.00.00F009	V07.01.00R003
V06.00.00F010	V07.01.00R004
V06.00.00F011	V07.01.00F001
V06.00.00F012	V07.01.00F002
V06.01.00F001	V07.01.00F003
V06.01.00F002	V07.02.00R000
V06.01.00F003	V07.02.00R001
V06.01.00R000	V07.02.00R002
V06.01.00R001	V07.02.00S809
V06.01.00R002	V07.02.00S810
V06.01.00R003	V07.02.01R000
V06.01.00R004	V07.02.01R001
V06.01.00R005	V07.02.01R002
V06.01.00R006	V07.02.01R003
V06.01.00R007	V07.02.01R004
V06.01.00R008	V07.02.01F001
V06.01.00R009	V07.02.01F002
V06.02.00R000	V07.02.01F004
V06.02.01R000	V07.02.01F005
V06.02.01R001	V07.02.02R000
V06.02.01R002
V06.02.01F001
V06.02.01F002
V06.02.01F003
V06.02.01F004
V06.02.01F005
V06.02.01F006
V06.02.01F007
V06.02.01F008
V06.02.02R000
V06.02.02R001
V06.02.02F001
V06.02.02F002
V06.02.02F003
V06.02.02F004
V06.02.02F005
V06.02.02F006
V06.02.02F007
V06.02.02F009
V06.02.02F010
V06.02.03R000
V06.02.03F001
V06.02.03F002
V06.02.03F003
V06.02.03F004
V06.02.04R000
V06.02.04F001

New Features in Release 08.02.00R000

SBX-41671 TTY/TDD Interworking Support for RFC-4103 and/or RFC-4351

The SBC supports Text over Internet Protocol (ToIP), including the inter-working between ToIP and the Text Telephone (TTY) protocols employed in Code Division Multiple Access (CDMA) wireless networks and wire-line VoIP networks (using Baudot).

The support is applicable for SBC deployments in virtual and cloud environments (I-SBC and D-SBC).

The following interworkings and related transcodings are supported:

Supported Interworkings and Transcoding

Interworking	Transcoding
T.140 to TTY	AMR-NB to EVRC/EVRC-B AMR-WB to EVRC/EVRC-B
T.140 to Baudot	AMR-NB to G711A/U AMR-WB to G711A/U
TTY to Baudot support	EVRC/EVRC-B to G711

Note

The SBC supports pass-through for all the text transmission protocols mentioned above.
The SBC performs T.140 to TTY/Baudot Interworking only when the call is transcoded. However, the SBC does not add DSP/transcoding resource just to perform this interworking.

Note

The following limitations apply:

Ribbon supports only 45.45 bps Baudot.
Maximum buffering for T140 packets is approximately 30 seconds.

Note

To configure this feature, ensure that the t140Call parameter is set to enable, by using the following syntax:

% set profiles media packetServiceProfile <profile_name> flags t140Call enable

For more information, refer to the following pages:

SBX-41671 TTY/TDD Interworking Support for RFC-4103 and/or RFC-4351

Guide/Section

Page

SBC Core Features Guide

Text Over IP and TTY Support

CLI Reference Guide

Packet Service Profile - CLI

Show Table System

Show Status System

EMA User Guide

Packet Service Profile - RTCP Options

DSP Status - DSP Usage

DSP Res - DSP Usage Current Statistics

DSP Res - DSP Usage Interval Statistics

SBX-58717 + SBX-67514 P-Early-Media and DLRBT Enhancements

Note

To avail this feature, set the PSX flag DelayedRBTWithToneContinuation to enabled.The flag is available under the entity Tone Generation Criteria in the PSX.

When a caller sends a SIP INVITE to the SBC (irrespective of the presence of "P-Early-Media: supported" header in the Session Description Protocol (SDP) of the INVITE), the SBC adds P-Early-Media header in its 18x (180 or 183) response towards ingress call leg only if:

The SBC monitors and detects early media from the egress call leg.

Note

The SBC has an "observation" window for monitoring the stream of RTP packets. It also has a "silence" window before it restarts monitoring, to reject RTP packets from a previous announcement.
The SBC plays a Ring Back Tone (RBT).

Note

The SBC plays LRBT only if it does not receive any early media from the egress call leg at the end of a monitoring cycle. If the SBC starts playing LRBT, it continues to play even if it detects RTP in the subsequent monitoring cycles, or exchanges a new set of SDP answers with the egress call leg.
When the SBC receives an UPDATE from the egress call leg, and the caller (ingress call leg) does not support UPDATE, the SBC continues to feed tone in the same codec. When the ingress call leg supports UPDATE, the SBC feeds tone in a modified codec after a successful offer-answer negotiation.

Note

If egress call leg responds with P-Early-Media header in its 18x response, the SBC transparently relays it to the ingress call leg.

For more information, refer to the following pages:

SBX-58717 + SBX-67514 P-Early-Media and DLRBT Enhancements

Guide/Section

Page

SBC Core Features Guide

Tones and Announcements

CLI Reference Guide

Tone and Announcement Profile - CLI

EMA User Guide

SIP Trunk - Media - Advanced - Early Media

Local Ring Back Tone - Flags

SBX-62459 Support for Public-key-Based Peer Authentication Method for IPSec

The SBC is enhanced to support a Public Key-based peer authentication method for IPSec on SBC. In past releases, the SBC used a Preshared key-based authentication method for Peer authentication during IKE negotiation for establishing IKE and IPSec Security associations. To meet Common Criteria certification requirements, the SBC is now capable of using x.509 digital certificates for Peer authentication. Note: Not currently supported on SBC Cloud and D-SBC platforms.

For more information, refer to IPsec Peer - CLI.

SBX-64041 IPSP flag “send SDP In Subsequent 18x” Evolved to “send SDP In Subsequent 18x if not reliable”

RFC 6377 requires that, after the SBC sends an answer in a reliable provisional response to an INVITE, it must not include any Session Description Protocol (SDP) in subsequent responses to the INVITE.

To satisfy the requirement, the behavior of the existing flag sendSdpInSubsequent18x is enhanced. Enable the flag to allow the SBC to send SDP in subsequent 18x response messages after it sends the answer in non-reliable provisional response (until it is sends in reliable 18x message) to the INVITE. When disabled, the SBC does not send SDP in the subsequent 18x response messages.

For more information, refer to the following pages:

SBX-67554 LCQ CC/SIP Issue - Multiple Call Transfer - SIP Layer Stops Responding

The SBC is enhanced with the parameter maxNumTransfers under the object global signaling. The range for the maxNumTransfers is 10-100, with 10 as default.

Note

The SBC retains the configured value for maxNumTransfers in case of a switchover (for HA configurations), and also when you perform an LSWU between two versions supporting the parameter. If you perform an LSWU from an unsupported to a supported version, the upgraded instance has the default value.

For more information, refer to the following pages:

SBX-67554 LCQ CC/SIP Issue - Multiple Call Transfer - SIP Layer Stops Responding

Guide/Section

Page

CLI Reference Guide

Signaling - Global - CLI

Show Table Global

EMA User Guide

Global - Signaling

SBX-68878 CDR for SIPREC Sessions

The SBC is enhanced with CDRs for the SIPREC sessions.

Currently, the SBC generates Session CDRs and adds recorder IP:Port details in a CDR session. The SBC Core is enhanced to show detailed diagnostics information about the SIPREC call legs and to report if there are any failures in setting up the SIPREC call legs. The SBC generates RECORDING records for SIPREC completion.

These SIPREC CDRs (RECORDING records) are used by Ribbon Protect and SIPREC platforms, and are useful for debugging. SIPREC CDRs (RECORDING records) carry the SIP protocol information, metadata used, and some additional media statistics. These records also carry the original communication session information. When the SBC records the same call towards multiple recorders, it generates a CDR for each recording session towards each SRS separately, including any call attempts. The SBC also generates a SIPREC CDR for recording sessions initiated by CLI/REST command.

For more information, refer to Accounting - CLI and Accounting and Logs - Admin.

SBX-70005 Relay Changes in PAID as per RFC-5876

The SBC is enhanced with the addition of the profile sipAdaptiveTransparencyProfile to configure SIP header transparency for P-ASSERTED-IDENTITY.

When the profile is enabled for a Trunk Group and the SBC receives an updated P-ASSERTED-IDENTITY header as part of SIP Request Methods (INVITE/UPDATE), or in SIP Responses (200/180/183), the SBC relays the SIP message transparently to the other leg of the call.

Note that SIP privacy handling takes precedence over the SIP Adaptive Transparency Profile.

For more information, refer to the following pages:

SBX-70005 Relay Changes in PAID as per RFC-5876

Guide/Section

Page

CLI Reference Guide

SIP Adaptive Transparency Profile - CLI

Privacy Profile - CLI

SIP Trunk Group - Services - CLI

Flags - CLI

SIP TG - Signaling - SDP Flags - CLI

SIP Trunk Group - Media - CLI

SIP TG - Signaling - 100rel Support - CLI

Show Table Profiles - Services

EMA User Guide

Services - SIP Adaptive Transparency Profile

SIP Adaptive Transparency Profile - SIP Methods

SIP Methods - Trigger Header

SIP Adaptive Transparency Profile - SIP Response

SIP Response - Trigger Header

Services - Privacy Profile

SIP Trunk Group - Services

Common IP Attributes - Flags

SIP Trunk Group - Signaling - SDP Transparency

SIP Trunk Group - Media

SIP Trunk Group - Signaling - All

SBX-70465 STIR/SHAKEN: Option to Signal Verification Failures in Backward Provisional Responses

The ATIS specification defines an optional capability to signal verification failures in backward provisional responses. If a terminating carrier B fails verification for an originating carrier A subscribers, but continues to deliver the call to the carrier B called party, carrier A will have no way to know. The terminating carrier can use failed verification to indicate robocalling status to the called party. In this case, carrier A has no way to know that their subscribers' calls are being flagged as robocalls to the terminating party.

The capability described in the ATIS specification solves this issue if carrier A has tools in place to find these indications in the SIP messaging.

For more information, refer to STI Profile - CLI.

SBX-70938 RTCP for T.140 Pass-through

Some endpoints require RTCP in T.140 media streams as a keep-alive. These endpoints can timeout and shut down the T.140 media stream if there are no text messages in the timeout window.

However, some endpoints are not capable of generating RTCP in a T.140 media path. Therefore, when inter-working two such networks there exists a condition where endpoints in one network require RTCP but endpoints in another are not capable of generating RTCP.

This feature will make it possible to configure specific trunk groups/PSP to generate RTCP for T.140 pass-through media streams. Additionally, the SBC will not generate RTCP if it is received from the endpoints.

RTCP packets generated by the SBC follow RFC 3550. It contains the following:

Sender Report (SR) or (Receiver Report (RR) if no packets were sent)
Source Description (SDES)

A flag, generateRTCPForT140IfNotReceivedFromOtherLeg, and a parameters, t140RtcpMonitorInterval, are added as a part of this feature to generate RTCP for T.140 media streams based on whether RTCP is received within the monitor interval.

For more information, refer to:

SBX-71386 Qualify Mellanox-based NIC Cards for SBC SWe – No OVS Offload

Mellanox-based NIC cards MCX4121A-XCAT and MCX512A-ACAT are qualified for use with SR-IOV on an Openstack platform RHOSP13 (Queens) with RHEL 7.6.

SBX-73110 - Support for Teams Direct Routing Using an SBC Hub

The Ribbon SBC adds a configuration option and new processing capabilities to enhance its support of the Microsoft Phone System's Direct Routing capability. Administrators can configure a network of SBCs in a manner that reduces the requirement for public IP addresses. The SBC is able to interpret headers sent from the Microsoft Phone System to optimize media routing decisions.

Refer to Microsoft Teams Direct Routing Using an SBC Hub

SBX-75174 - Generate or Replace SSRC Values for Calls Toward a Kandy Link WebRTC Gateway

The synchronization source (SSRC) identifier uniquely identifies media streams within an RTP session and is included in SDP signaling when establishing or modifying media sessions. The WebRTC specification requires that the SSRC value in an RTP stream match the SSRC sent in the SDP. However some endpoints, such as PSTN gateways, are not capable of generating SSRC values so they are not present in the SDP. Other endpoints change the SSRC during call hold/resume scenarios. The SBC can be configured to address these potential interoperability issues in WebRTC deployments.

You can configure the SBC to generate an SSRC and related attributes to ensure that the required values are present in calls toward a WebRTC gateway such as the Kandy Link WebRTC gateway. When enabled, the SBC generates an SSRC value for audio or video streams and includes it in SDP signaling and RTP/RTCP streams. You can also configure the SBC to update SSRC values in call hold/resume scenarios. When configured to modify the SSRC, after the call resumes, the SBC generates a new SSRC value and includes both the previous and new SSRC values in SDP signaling. Note that the SBC only makes mid-call modifications to the SSRC if it is also configured to generate the SSRC.

For more information, refer to Packet Service Profile - CLI, Packet Service Profile - Flags, and System Provisioning - Packet Service Profile.

SBX-75865 Alarm Generation when SBC Receives RCODE Except for 0

If the SBC receives an error response (except for 0) toward the DNS query, it raises an alarm to notify the user to resolve the IP address of the far end carrier.

The SBC uses the DNS Server IP as a key in the alarm.

For more Information, refer to

SBX-76436 - Increase CDR Retention with Compression

The SBC is enhanced to allow writing accounting files containing CDRs into a compressed format. The compressed files are retained for a user-specified time period; thereafter, they are automatically deleted after a specified number of days. The compressed files are stored in the evlog directory or another directory that you specify. The compressed files are saved using names intended to make them globally unique across all of the user's machines, by including the server information and timestamp.

In order to support existing functionality that reads the uncompressed accounting files, the ability to also write both compressed and uncompressed accounting files simultaneously is added. This enables sftp file transfer to the DSI, viewing the accounting logs in EMA, and transfer of the data to Ribbon Protect. The compression method used is gzip streaming compression. This compression results in a file being compressed to between 10 and 15% of its original size. Encrypet file transfer is not supported through sftp push.

For more information, refer to Event Log - CLI and Event Log - Type Admin.

SBX-76610 Selection Feature for ARS Recovery Algorithm

Currently, the uses a common ARS recovery algorithm for all the selected blacklist algorithms . If the trunk group had more than one peers and one of the peers did not support the selected recovery algorithm, it became difficult to recover that particular peer.

The SBC is enhanced with a new flag to select the recovery mechanism for each blacklist algorithm selected.

The SBC supports selecting of ARS recovery algorithms for each of the following blacklist algorithms.

For more information, refer to:

SBX-85716 Re-initiate Pre-condition Negotiation Towards Ingress

Currently, the SBC supports ingress precondition interworking when the ingress side of the call supports precondition attributes, but the egress side of the call does not. The sends out the initial INVITE to the egress when it meets the ingress side preconditions.

With this enhancement, the SBC re-initiates the precondition procedure whenever the ingress side Session Description Protocol (SDP) changes due to an 18x/200 OK or UPDATE received from the egress side.

For more information, refer to:

SBX-85818 + SBX-85655 Support for SIP-ISUP

To support interworking between different variants of SIP, the SBC is enhanced with the following profiles:

calledPrefixMatchProfile
carrierCodeToIoiMappingProfile
ioiToCarrierCodeMappingProfile
sipJJ9030InterworkingProfile

You can attach the profiles calledPrefixMatchProfile and sipJJ9030InterworkingProfile with a SIP Trunk Group.

The parameter contractorNumInterworking is added under the NNI Profile.

For more information, refer to the following pages:

SBX-85818 + SBX-85655 Support for SIP-ISUP

Guide/Section

Page

SBC Core Features Guide

Support for SIP-ISUP

CLI Reference Guide

Called Prefix Match Profile - CLI

Carrier Code to Ioi Mapping Profile - CLI

Ioi to Carrier Code Mapping Profile - CLI

SIP JJ9030Interworking Profile - CLI

NNI Profile - CLI

Show Table Profiles - Signaling

EMA User Guide

Signaling - Called Prefix Match Profile

Called Prefix Match Profile - Prefix Match

Signaling - Carrier Code To Ioi Mapping Profile

Signaling - Ioi To Carrier Code Mapping Profile

Signaling - SIP JJ9030Interworking Profile

Signaling - NNIProfile

SIP Trunk Group - Signaling

SBX-86008 Cloud SBC Avalanche Fault - Detection and Control

Packets that cause a direct SBC fault can lead to a catastrophic failure of an SBC service, which is known as a packet-stimulated fault avalanche. These packets appear for various reasons, such as: the SBC adds a new Session Initiation Protocol (SIP) endpoint, upgrades or replaces a peering endpoint or gateway (GW), changes a configuration on a peer, or introduces a new call scenario. The SBC does not currently check for double faults, which is when the SBC has a failover and then another failover. Double faults cause call loss.

The goal of Avalanche Fault Detection and Control is not to prevent individual crashes, but to detect and control continuous "avalanche" faults that can lead to complete service outages. This feature uses the information from the existing faults to attempt to prevent future faults.

For more information, refer to CLI Configure Mode and System - Fault Avalanche Control.

SBX-86658 Offer-Answer Timer Configuration

In specific call scenarios, the SBC treats the Offer-Answer (OA) as a MODIFY Offer-Answer cycle, but the peer treats it as an INITIAL Offer-Answer cycle. According to RFC 3261, the response from the peer is expected within 300 seconds. The SBC, however, assumes a 20-second response, and therefore any delay in the response from the peer which exceeds of 20 seconds causes call failure.

To overcome this limitation, the SBC is enhanced with a new parameter offerAnswerTimer to configure this OA timer.

Note

During switchover, the active calls use the old timer value at the start of the call. After switchover, the new calls use the latest configured value.

For more information, refer to the following pages:

SBX-86789 - SBC Should Create TLS Connection Based on Contact Header

In access deployments when a user submits a REGISTER request through the SBC, the SBC stores both Contact header information and the source IP address from where the REGISTER request originated. By default, when the SBC sends a call from the internal network to a registered user over TLS transport, the SBC directs the call to the source IP address it stored during registration of the target user. However, you now have the option to configure the SBC to instead direct the call to the Contact header address the SBC stored for the target user.

Refer to SIP TG - Signaling - Honor Contact in Register for TLS Calls - CLI

SBX-87239 Response Code Change When SBC Fails DNS Query

When the SBC fails a DNS query, it generates a 503 or 500 error response. These error codes are now mapped to a configurable response code.

For more information, refer to Internal SIP Cause Map Profile - CLI.

SBX-88422 - Support FQDN as GW SIP Address for PSX Proxy Calls

In SBC deployments that use an external PSX to provide routing policy, SBCs can be added as gateways within PSX to then use optimized routing (SIP in Core) to route calls to other SBC gateways. The PSX 12.2 release adds support for configuring a PSX gateway entity with an FQDN as its SIP address (as an alternative to configuring a specific IP address). The FQDN configuration supports SBC SWe N:1 S-SBC deployments in which a cluster of up to 4 SBC nodes can be active at the same time. Each of the SBC nodes in the N:1 cluster share a homogenous configuration and register with the PSX using a common gateway name.

With SIP in Core configured, when the core SBC sends a Diameter request to the PSX for routing, the PSX returns the gateway FQDN if the S-SBC cluster is the next hop. The core SBC does a DNS lookup to resolve the FQDN to the individual IP addresses of the active nodes within the cluster. For subsequent call requests, the core SBC load balances among the active nodes using a round robin method to rotate among the individual IP addresses.

Refer to Configuring the SBC to use SIP in the Ribbon IP Core.

SBX-88542 - Prefix-based TG Selection using SMM

By default, the SBC selects the ingress trunk group for an incoming SIP request based on its source IP address and port. However, using SIP Message Manipulation (SMM) operations and a new type of profile, you can extract a value from the incoming message and use the value to select a new ingress trunk group. This secondary trunk group selection enables applying trunk group policies and profiles on a more granular basis in subsequent processing of the session.

Refer to:

SBX-88601 + SBX-88885 – SMM: Support Global Configuration and Increased Number of Rules

To enable application of SMM rules more broadly, the SBC adds support for applying SIP message manipulation (SMM) profiles (SIP adaptor profiles) at both the global and address context levels. The new profiles are in addition to the existing support for input and output profiles applied at the zone and trunk group levels. You have the option to define profiles at any or all of the levels.

If more than one profile applies to a session, you can enable "fixed order" execution of the profiles (smmProfileExecution=fixedOrder). In fixed order execution, the SBC logically concatenates the rules in the applicable profiles and executes them in the following order: global, address context, zone, SIP trunk group. The collection of rules are treated as though they reside in a single profile and therefore variables set at the beginning of the sequence are accessible to rules that follow in the sequence.

To support additional uses of SMM, the SMM rules and actions maximum limits are increased as specified below.

SMM Entity	Maximum Supported
Profiles	512
Rules	10,000
Actions	50,000
Criteria	80,000

For more information, refer to:

SBX-88947 Test 2nd Management port on SWe platforms

SBC SWe has been enhanced to support use of a second management port in VMware-based deployments.

For more information, refer to Second Management Port for SWe Deployed in VMware.

SBX-89252 Generate SIP User-Agent Header to Identify SBC Platform and Release

Microsoft Teams use the contents of the user-agent header to determine the remote peer, and then generate telemetry information such as the SBCs manufacturer, sessions success rate and failures to Generate SIP User-Agent Header. This helps in ensuring customers are using Microsoft Teams direct-routing-supported SBC. This enhancement gives the SBC the ability to generate and send UserAgent header towards MS Teams for MS Teams direct routing deployments. The user Agent header now contains:

- The vendor Name (Ribbon SBC)
- The SBC platform ( RIbbon SBC 5400 /7000/ SBW SWE)
- The application software version (such as SBC 8.2.0)

As part of this work some additional native capabilities were added for MS Teams zones in order to remove the need for some SMM.

The Lifetime attribute (”|2^31”) will always be added to the crypto line natively for Teams and avoids the need for SMM.

“a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:9bJEC9N5sqNNGDE9z/0UcOP2btmUfHdryTjLUzDw|2^31”

The gr parameter is automatically removed from the contact header for MS Teams zones to avoid it triggering contact header transparency.
The max-forwards value is automatically set to 0 in the OPTIONS message on MS Teams zone so the SBC processes it locally.
Transport=tls in the 200 OK response to the Invite with replaces in a CallQ scenario.

SBX-90436 Capacity Scaling Support with OVS-DPDK Virtio Interfaces

The SBC is enhanced to apply RX-TX architecture for OVS-DPDK virtio interfaces, similar to support of SR-IOV interfaces. Estimated capacity sessions have been adjusted accordingly.

For more information, refer to VNF Performance Tuning and KVM Performance Tuning.

SBX-87348 ARS support on SIPREC Trunk

SBC uses the Address Reachability Service (ARS) to determine if a server (SRS) is reachable. This allows the SBC to “blacklist” a server IPv4 or IPv6 address if it is deemed unreachable, and address subsequent requests to that destination appropriately.

SBX-85320 Implement Q-series Release 10.0 LI Interface

The SBC now supports the same packet cable 2.0 specification so that the LI users do not have to make changes when Q-series SBC is replaced with the SBC core.

SBX-76608 Expected Error Response Based on Call Statistics

In response to a customer request, certain OIDs were examined and error responses were changed.

SBX-90410 Limit on Recording Criteria

Recording criteria is expanded from 128 to 1024.

Resolved Issues

Resolved Issues in 08.02.00R000 Release

The following issues are resolved in this release:

Resolved Issues

Issue ID	Sev	Problem Description	Resolution
SBX-87879	3	When signalingNapt is disabled on the ingress TG, the SBC populates the "PeerIP/Port" with the IP address and port from the Contact header of the incoming INVITE. When signalingNapt is enabled on the ingress TG, the SBC populates the "PeerIP/Port" with the IP address and port where the INVITE came from. The expected behavior is that the PeerIP/Port would always be populated with the real IP:port where the INVITE came from. Impact: PeerIP/Port is populated inconsistently. Root Cause: The SBC is populating PeerIP/Port incorrectly based on whether signalingNapt is enabled or disabled. Steps to Replicate: N/A Platform/Feature: SBC	The code is modified to pick IP and port from where the invite is received from despite signalingNat being enabled or disabled.
SBX-94820 / SBX-91567	1	PortFix SBX-91567: The RX/TX PDUs/BYTEs not getting updated correctly in the SBC stats file for "SipSigPortStatisticsStats" Impact: Statistics for the signalling port were not getting updated correctly in the .pms file. Root Cause: Statistics were not fetched from SIPCM, which is where statistics are maintained. Instead, fields were directly updated from the SIPFE perspective and as a result, the stale counters were observed in the .pms file. Steps to Replicate: T1: Configured 2 signalling ports, 1 at ingress and the other at egress then made some calls and observed the .pms file without running the CLI. T2: Configured 1024 signalling ports at ingress and 1024 signalling ports at egress then made some calls at 100th, 500th and 1000th signalling port, respectively and ensured proper update of statistics in the .pms file. Platform/Feature: SBC	The code is modified to fetch the statistics from SIPCM and writing to the .pms file correctly.
SBX-94748	2	(Disable NP Policing based on feature flag) fix was not working on the D-SBC. Impact: With the spikeAction set to Alarm, the SBC must not discard the non-confirming policer packets. However, on the D-SBC, the SBC was still discarding these packets. Root Cause: On the D-SBC, the "spikeAction" configuration is found on the M-SBC, while the command to allocate resource comes from the S-SBC. Due to the allocated resources, the policerMode set from S-SBC is not matching with the policerMode (BYPASS) configured on the M-SBC to allow the over flow packets. Steps to Replicate: The steps cannot be reproduced. Platform/Feature: SBC	On the M-SBC, when resource allocation/BwChange/Select command is received from the S-SBC, overwrite the policerMode based onthe "spikeAction" configuration on the M-SBc.
SBX-94607	3	Incorrect String with Response Error code 500. Impact: The SBC is replying to request with 500 error response code to the client with error string as "Internal Server Error". Root Cause: The SBC is sending string "Internal Server Error" is not correct as per RFC3261 standards. Steps to Replicate: Verify the SBC responds to the request with "Server Internal Error" instead of the "Internal Server Error" for 500 response code. Set Up: Configure the SBC. Make a configuration changes so that the SBC replied with 500 Response. Example: `disable the Ingress sip trunk group.` Make a call. Expected Result: Verify the SBCs reply with the "Server Internal Error" string for the 500 response code. Platform/Feature: SBC	The code is modified so the error string for 500 response code is a "Server Internal Error".
SBX-94397 / SBX-94250	2	Portfix SBX-94250: The S-SBC does not send any response after sending "100 Trying" for an incoming INVITE with a SDP that has no codecs in the PSP. Impact: The SBC does not send any response after sending "100 Trying" for incoming INVITE with SDP that has no codecs in the PSP when precondition interworking is in progress. Root Cause: The SBC waits on a precondition to complete from the ingress peer and as a result, does not send any response in this failure case. Steps to Replicate: Configure the SBC for ingress precondition interworking. Send an INVITE with codecs not present in PSP. The SBC must terminate the call. Platform/Feature: SBC	When there is no codecs in the PSP and precondition interworking is in progress, the SBC now terminates the call with a 500 internal server error.
SBX-94358 / SBX-93248	1	Portfix SBX-93248: The sonusDatabaseConfigPolicyDataOutOfSync notification is raised from the S-SBC in the OAM network. Impact: The configuration data is not stored in the policy DB for OAM and managed VM nodes. The PIPE application was used to raise the out of sync traps. Root Cause: Existing PIPE logic was used to raise out of sync error whenever there is an out of sync condition. The logic is used between a policy DB and config DB. Steps to Replicate: There is a PIPE thread that periodically checks for consistency between the Config DB and Policy DB. The interval is configurable. CLI Command `[set profiles dbSyncCheckProfile DEFAULT syncCheckInterval <interval duration>`. Through CLI as well the user can trigger to verify DB integrity. `request system admin TACKS verifyDatabaseIntegrity Id all` The command will trigger a check for the DB integrity and update the sync status and time stamp. It also raises trap if there is mismatch. So, a new status type "notApplicable" is added when this command is executed. `show table system databaseIntegrity` This command fetches the data updated by the above command and display on the console. Also, the output of this command will show the sync status as "notApplicable". SBC Application restart. Platform/Feature: SBC	The SBC application restart used to raise the trap sync during startup of the PIPE application is used to check for the DB integrity. There is not any out of sync trap seen after the fix is applied.
SBX-94286	2	The error response of PRACK must be relayed to the endpoint when the End-End PRACK is enabled and call must not be teared down. Impact: Call is terminated whenever the error response is received for PRACK and End to End PRACK is enabled. Root Cause: The SBC terminates the call whenever an error response is received for PRACK. Steps to Replicate: End to End PRACK is enabled. PRACK responded with an error response. Platform/Feature: SBC	The code is modified so the SBC does not terminate the call when an error response is received for the PRACK and the End to End Prack is enabled.
SBX-94285 / SBX-91820 / SBX-90540	2	Portfix SBX-91820: When the SRS does not respond to the SBCs request and if no redundant SRS is configured, the SBC sends BYE towards the SRS without XML. In case of load scenario when there are 'n' number of active calls towards a SRS and if scenario above occurs, the SBC releases entire 'n' recording calls in bulk. Impact: When the SRS does not respond to the SBCs request and if no redundant SRS is configured, the SBC sends BYE towards the SRS without XML. In case of load scenario when there are 'n' number of active calls towards a SRS and if scenario above occurs, the SBC releases entire 'n' recording calls in bulk. Root Cause: The API that is responsible for building XML body was not invoked when the release cause code was SIPSG_REC_REL_CLEANUP. This is designed to release the entire recording call when a recorder does not respond for a single call. Steps to Replicate: 1. The Recording session is established with SRS server. 2. Trigger a Re-Invite scenario in the CS call. 3. The SBC triggers a separate Re-Invite towards the SRS. 4. Let SRS not reply to the Re-Invite. 5. Invite timeout at the SBC will case the above problem. Platform/Feature: SBC	The code is modified to invoke the API responsible for building the XML body when the release cause in the code is SIPSG_REC_REL_CLEANUP. The design was modified to only terminate that particular call that had no response from the SRS.
SBX-94263 / SBX-93261	2	Portfix SBX-93261: The MSBCs switchover restarted two nodes. Impact: On a node switchover on the D-SBC setup, the MSBC or SSBC can have SWe_NP coredump. Root Cause: The issue occurred due to a code optimization in kni thread. The kni thread starts taking 100% CPU on the SWO due to large amount of ICM message flows. Steps to Replicate: On the D-SBC setup, perform the switchovers on the MSBC Platform/Feature: SBC	A revert the code optimization done in kni.
SBX-94244 / SBX-76605	2	Portfix SBX-76605: The SBC must not depend on the processSgCOnfigureWhenTGOOS setting. Impact: The SBC must not depend on the processSgCOnfigureWhenTGOOS setting. Root Cause: The SBC is taking the precedence of the processSgCOnfigureWhenTGOOS flag over the internalSipCauseMapProfile. Steps to Replicate: 1. Configure "TrunkGroupOutOfService" in the existing internalSipCauseMapProfile. `[set profiles signaling sipCauseCodeMapping internalSipCauseMapProfile <profile_name> causeMap` `TrunkGroupOutOfService sipCause 504].` 2. Attach the configured profile to the signaling zone. `[set addressContext <addressContext_name> zone <ZONE_INGRESS> signaling causeCodeMapping` `sipInternalCauseMappingProfile <profile_name>]` 3. Set the mode of the "ingress" trunk group as outOfService on the SBC. `[set addressContext default zone <ZONE_INGRESS> sipTrunkGroup <TG_INGRESS> mode outOfService]` 4.Enable processSGConfigWhenTGOOS `set addressContext default zone <ZONE_INGRESS> sipTrunkGroup <TG_INGRESS> processSGConfigWhenTGOOS disabled` 5. Make an A-B basic call. Platform/Feature: SBC	The code is modified to make the internalSipCauseMapProfile independent of the processSgCOnfigureWhenTGOOS flag.
SBX-94145 / SBX-93765	1	Portfix SBX-93765: The CS04A01 lost communication with the CM04A04 and in post-recovery, other m-sbcs cannot communicate to the CM04A04. Impact: The IPv6 address becomes unreachable in a standby port cable pull scenarios. Root Cause: The SWe code was not saving the multicast MAC address list and re-applying it on a hardware port during a link up/down event for standby ports. Steps to Replicate: Bring down any standby port by cable pull on host. Configure a new IPv6 address on the pkt port. Re-insert the cable for same standby port. Perform a port switchover by plugging out active physical port's cable so that standby becomes active for same port. Ping the new configured IP from in step 2 from outside. The ping will fail. Platform/Feature: SBC	The code is modified to handle the programming of multicast MAC list for standby ports correctly.
SBX-94138 / SBX-94092	1	Portfix SBX-94092: The MGMT port is not reachable in the SLB. Impact: The SWe_NP failed to come up in a large SLB cloud instance (i.e. 16 vcpu or more) with port redundancy enabled. Root Cause: In the cloud, the default value of "DosSupportSecPktPorts" flag is set to "true", and requires an additional rx/worker thread to be spawned in case of port redundancy. SLB and S-SBC uses standard_signaling_profile for the core partition. S-SBC only uses one worker for all vcpu configurations, where the SLB uses 2-workers for larger vcpus( > 16vcpu). If the DosSupportSecPktPorts=true, there will be additional worker threads required, so for this instance for the SLB, there will be secondary worker threads for each single worker. This case is not supported. Steps to Replicate: Spawn a 16 vcpu SLB instance in the cloud using a Heat template. Check the MGMT port reachability. Platform/Feature: SBC	The code is modified to avoid having secondary threads in case of port redundancy when having two workers.
SBX-94113 / SBX-90581	2	Portfix SBX-90581: The PCAP file list (PCAP) is not displayed correctly if the file count exceeds more than 130. Impact: When using the EMA and accessing the Call Trace/Logs/Monitors > Log Management > TShark, the screen does not list the files if there are more than 130 files in the directory. Root Cause: Mismatch in the response header transfer-encoding. Steps to Replicate: Create more than 130 PCAP files and try to display them under TShark screen. Platform/Feature: SBC	The code is modified to display all files when a large volumes of PCAP files are present.
SBX-93957 / SBX-93900	1	Portfix SBX-93900: The IPIGs with underscores fails on a MSRP/RCS call on a decomposed P-SBC. Impact: The MSRP call on the DBSC fails when configuring an IP interface group name greater than 7 characters. Root Cause: Incorrect type cast was used while handling the GCID allocation response in the MSBC. Steps to Replicate: Test a basic MSRP call with an ingress and egress interface group name set to "INTERFACE_LIG1" and "IPINTERFACE_LIG2" respectively. Platform/Feature: SBC	Use the correct typecasting for all remote resource allocation requests.
SBX-93789 / SBX-91154	2	Portfix SBX-91154: A call failure due to a FQDN in the request URI. Impact: When the SBC sends a query for the SRV record to the external server and the Peer Domain in ReqURI is disabled, the SBC intermittently sends a FQDN in the reqURI of egress INVITE. The correct behavior is to the send IP and address in the reqURI of an egress INVITE. Without a fix, the SBC will send FQDN in reqURI even when Peer Domain in ReqURI is disabled. Root Cause: The SBC does not use a formatted SIP message when the external query is made for finding a SRV record and a record is found in cache. The SBC cannot apply the setting of "Peer Domain in ReqURI" flag in an egress SIP message. Steps to Replicate: The following configurations on PSX Set IP PEER as FQDN abc.com instead of an IP address. Enable "noPortNumber5060" on IPSP [ This is for done for NAPTR, SRV query ] Disable "Peer Domain in ReqURI " on IPSP [ This is done to make sure we do not send FQDN in egress INVITE's reqURI ] Use External DNS server. Configure a SRV record and a record on the external DNS server with different Time To Live values. Run a high number of calls. Platform/Feature: SBC	The code is modified to have the SBC use a saved formatted SIP message when the external DNS query is made for a SRV record and a record is fetched from the cache. This allows the SBC to apply the setting of "Peer Domain in ReqURI" flag in the egress SIP message.
SBX-93679	2	The SIP call never connects on the ingress intermittently. (GW-GW call). Impact: For two-node M-SBC passthrough call, the SIP call never connects on ingress. The call hangs until the call control 5-minute timer expires. Root Cause: An improper Node GCID setting on the second M-SBC node of a two-node M-SBC passthrough call causes an internal failure, resulting in a hung call. Steps to Replicate: The steps cannot be replicated. Platform/Feature: SBC: SIP	The code is modified to add a proper node GCID setting on a second M-SBC node of a two-node M-SBC passthrough call that results in successful call setup.
SBX-93678	2	The DSBC IP and SIP SIG port IP was not reachable after the switchover. Impact: LIF is activated on standby, even before the PRS process is cleaned up on standby in case the AMF process is terminated. Root Cause: During the cleanup, the presence of a PRS process was not checked before sending a switchover event to peer. Steps to Replicate: Kill the AMF process on active and ensure that LIF is not activated on standby before the PRS process is down on active. Platform/Feature: SBC: Platform, Redundancy	Check for the presence of PRS process before sending the switch-over event to the peer.
SBX-93557 / SBX-93312	1	Portfix SBX-93312: The SBC Memory was reading high alerts. Impact: When the Local Ring back tone is configured on the SBC and the egress endpoint sends a 183 Session Progress with a SDP followed by a 180 Ringing, the SCMProcess does not free up memory allocated even after call is completed. Without a fix, the SCMProcess will leak memory. Root Cause: When the Local Ring back tone is configured and the egress endpoint sends a 183 Session Progress with a SDP followed by a 180 Ringing, the SCMProcess does not free up media session descriptor structure. Steps to Replicate: Run a call load with Local Ring back tone configured and monitor virtual memory usage of the SCMProcess. With a fix, the virtual memory of SCMProcess will not be high after all calls have been disconnected. Platform/Feature: SBC	The code is modified to ensure memory is allocated for the packet service profile structure is freed when no longer required.
SBX-93390 / SBX-92252	2	Portfix SBX-92252: The SBC was sending an INVITE out for the first user only. Impact: Native Forking fail was sending out on the 2nd route. Root Cause: If incoming call has a capital "CALL-ID", the SBC will fail to find the parent incoming call. As a result, forking will not occur. Steps to Replicate: Treat the "CALL-ID" as case insensitive. Platform/Feature: SBC	The code is modified to treat the "CALL-ID" as case insensitive.
SBX-93355	2	The P-Charge-Info header was not relayed by the SBC in an out-of-dialog MESSAGE request, even when the transparency setting is enabled. Impact: The P-Charge-Info Header is not relayed transparently for OOD Message, even when the transparency profile is enabled for P-Charge-Info. Root Cause: The P-Charge-Info Header is dropped in case of relay framework. Steps to Replicate: Run the message OOD that has P-Charge-Info Header in the incoming Message and transparency is enabled for that header. Platform/Feature: SBC	The P-Charge-Info Header is copied in case of relay framework.
SBX-93099 / SBX-92580	2	Portfix SBX-92580: The SIP domain was missing in the FROM header after an upgrade. Impact: The DM rule for FROM Uri is not working. Root Cause: It was introduced by a previous bug to treat the FROM Uri specifically for the RewriteIdentity only. Steps to Replicate: Configure the PSX for the FROM Uri, and a simple SIP-SIP call. Verify the FROM header is picking up the DM rule of the FROM Uri. Platform/Feature: SBC	The code is modified to support the old behavior for allowing FROM Uri to take affect, even when the RewriteIdentity is disabled.
SBX-93070 / SBX-92092	1	Portfix SBX-92092: A possible memory leak in SAM process. Impact: The SAM process will leak memory in the case where a de-REGISTER is received and then within less than 30 seconds, another REGISTER for same AOR is received. This will only happen if Multiple contacts per AOR flag are disabled. Root Cause: The code does not free certain memory blocks in this case. Steps to Replicate: 1. Multiple contacts per AOR flag must be disabled. 2. Perform a Register for particular AOR and perform a de-register. 3. Within less than 30 secs, re-send the registration for same AOR so that SIPFE selects the same preferred slot that was used for registering the same AOR earlier. By registering multiple users with same time period, leak will be reproduced. Platform/Feature: SBC	The code is modified to free the memory blocks.
SBX-93065	2	The SBC discards the inbound RTP stream. Impact: The SBC discards media packets when a NAT is enabled, with Signaling and media IP listed the same, but the media port is translated by a NAT device. Root Cause: In 7.2 the SBC has logic to disable a media NAT when the Peer IP and media IP are the same. The logic is causing issues when these IPs are set as true, but the Port is still being translated by a NAT device. In this case, the peer IP and advertised media IP are 100.65.1.210. The media advertised port is 1132. The actual media is being sent from port 1097. Due to the disabled media NAT, there is no access to the UDP port, resulting in policed media and no audio. Steps to Replicate: Enable the media NAT and a new flag (disableMediaNatIfSameMediaAndSigIP) Make a SIP-SIP call with the media IP and Signaling IP configured the same. Ensure the media NAT is disabled. Enable the media NAT and disable a new flag (disableMediaNatIfSameMediaAndSigIP) Make a SIP-SIP call with the media IP and Signaling IP configured the same. Ensure the media NAT is enabled. Platform/Feature: SBC	The code is modified to enable/disable the logic introduced in a previous release. New CLI configuration is introduced as shown below: `addressContext->zone->sipTrunkGroup->Services->natTraversal- >disableMediaNatIfSameMediaAndSigIP` CLI Syntax example: `set addressContext <name> zone <name> sipTrunkGroup <name> service natTraversal disableMediaNatIfSameMediaAndSigIp enable` NOTE: The default value of the CLI commands is disabled.
SBX-93063	1	The SBC SWe 8.01R000 is outOfSync between the CDB and PG/policyDB after Restoring the DB from V07.02.01R002 release. Impact: The SBC SWe 8.01R000 is outOfSync between the CDB and PG/policyDB after Restoring the DB from V07.02.01R002 release. Root Cause: The proper code was not present to display load configuration notification at the time of Platform manager login. Steps to Replicate: The steps cannot be replicated. Platform/Feature: SBC	The code is modified to display load config notification at the time of Platform manager login.
SBX-93044 / SBX-92458	1	The ATT P-SBC DelayedRBTOnlyIf180Rxd was not working. Impact: The ATT P-SBC DelayedRBTOnlyIf180Rxd was not working. Root Cause: When a 183 with the SDP PEM inactive is received, the SBC is going for tone play when Delayed RBT if a 180 received is enabled. Steps to Replicate: Delayed RBT if the 180 is received in tone Profile. The EMA is enabled and THE Tone Profile is enabled. The Tone criteria must match for delayed RBT if the 180 is received. The 183 Response is received with the PEM inactive. The SBC must not be directed to tone play. Platform/Feature: SBC	The code is modified so the SBC will not use the tone play when Monitoring is failed due to an ENO condition.
SBX-92962	2	The IngressIpPrefix data was deleted when removing the SMM from the TG. Impact: The IngressIpPrefix data was deleted when removing the SMM from the TG. Root Cause: When deleting a SMM Profile, the code is deleting the ipPrefix data as well. Steps to Replicate: admin@SBC5210b> show table metadata trunkGroupIpPrefixMeta PREFIX TG NAME IP ADDRESS LENGTH ------------------------------------ ASTERISK_SIP 10.158.171.6 32 GG_INGRESSTG 10.6.30.137 32 GW_TG 0.0.0.0 0 Platform/Feature: SBC	The code is modified to not delete ipPrefix data when a SMM profile is deleted.
SBX-92785 / SBX-92470	2	Portfix SBX-92470: The SAMP had a memory leak. Impact: Possible slow memory leak in the SAM process when running GW-GW calls. Root Cause: GWFE is leaking a copy of the incoming PDU, which was queued internally. Steps to Replicate: The steps cannot be replicated. Platform/Feature: SBC	The code is modified to free the memory that was being leaked.
SBX-92731 / SBX-91985	1	Portfix SBX-91985: The SIP calls drop with a vertical service code 65 after a minute. Impact:* The SBC is unable to send the ACK to Egress for a call to connect. Root Cause: There is a logical error when combining multi features (e2eAck, e2eReInvite, and DLRBT) Steps to Replicate: Configure: e2e Ack, e2e reInvite, and DLRB Issue 1: Egress response 183(sendrecv), 183(onhold), 180(no SDP), 200OK(sendrecv). Peer change SDP in the 18x/2xx causing internal offer/answer. Issue 2: Ingress peer sends reInvite rigth after ACK, causing the internal state is unable to send ACK out. Platform/Feature: SBC	The code is modified when multi features e2e ack, e2e reIvnite, and DLRBT are enabled.
SBX-92614	2	The NESSUS scan reports TLS violations against the SBC 8.0 OAM VNF. Impact: On OAM nodes for EMA/PM, the TLS 1.0 is enabled along with TLS 1.2. By default only, the TLS 1.2 must be enabled. Root Cause: On OAM nodes for EMA/PM, the TLS 1.0 is enabled along with TLS 1.2. By default only, the TLS 1.2 must be enabled. Steps to Replicate: Deploy an OAM node and check in /etc/apache2/sites-enabled/EMA.conf and 000-default.conf. The SSLProtocol will be set to +TLSv1.0 +TLSv1.2. With fix build, it must be set to +TLSv1.2 only. Platform/Feature: SBC	The TLS 1.0 is removed from default SSLProtocol list of the PM/EMA.
SBX-92548 / SBX-92037	2	Optional fax parameters being parsed by the SBC and as a result, the 200 OK was being discarded. Impact: There was a parser error for the unsupport t38 attributes. Root Cause: There was a parser error for the unsupport t38 attributes. Steps to Replicate: Perform an incoming call with unsupported t38 attributes. Platform/Feature: SBC	Modify the parser to ignore the unsupported t38 attributes.
SBX-92518 / SBX-92091	2	Portfix SBX-92091: Call Graphs were showing more calls after an upgrade. Impact: Stale calls may be found on a newly upgraded SBC, when upgrading from a version older then 6.1.0 to a newer release. Root Cause: As a result of changes that were made to the call ID in 6.1 code, during LSWU any calls that existed prior to the upgrade and were then modified or terminated after the upgrade started will be left in a hung state. To clean up the call, use the following commands: unhide debug request sbx rtm debug command “cleanup <gcid> Steps to Replicate: 1. Create audit key greater than 31 by multiple switch over on HA system or by using instrumented code. 2. This will create GCID values using the high bits ( bit 30-31 ) of GCID value. 3. Setup SIP calls on the system. 4. Initiate LSWU on standby and after standby is upgraded to newer version , all the established calls on active will be synced. 5. Start LSWU on active. 6. At this point standby will become Active. 7. Hang up calls which established before standby became Active. 8. Issue "show table global callSummaryStatus" CLI command and for all those calls data will be Unavailable. 9. These calls will consume resources. Platform/Feature: SBC	The code is modified to prevent calls from being hung during an upgrade from versions older than 6.1.
SBX-92180 / SBX-90877	1	Portfix SBX-90877: There was a failover from Node-A to Node-B. Impact: There was a healthcheck failure while switching from Node-A to Node-B Root Cause: Functions that configure the DRBD subsystem are taking longer and causing a healthcheck timeout. Steps to Replicate: The steps cannot be replicated. Platform/Feature: SBC	The code is modified to run the DRBD setup commands in the background and unblock the caller immediately.
SBX-92173 / SBX-90619	2	Portfix SBX-90619: The error status of the import CLI configuration is not reflected in the GUI. Impact: The error status of the import CLI configuration is not reflected in the GUI. Root Cause: The session was deleted before the failure message propagated to the UI. Steps to Replicate: The steps cannot be reproduced. Platform/Feature: SBC	The code is modified to handle the session timeout.
SBX-92117	2	After an upgrade, the SWAP partition has the wrong UUID. Impact: File the /etc/fstab had an incorrect UUID for the swap partition, with the timeout logs were seen on the boot-up. Root Cause: As part of multiple upgrades going through different versions, the swap partition UUID had been changed but the same is not reflected in the fstab file. Steps to Replicate: Install/Upgrade to fix version and ensure there is no swap entry in fstab file and that there also is no timeout logs. Platform/Feature: SBC	The code is modified to remove the swap entry from the /etc/fstab file as swap is not enabled on the SBC. After installing/upgrading to the fix version, timeout logs are not seen on the boot-up.
SBX-92111 / SBX-90584	2	Portfix SBX-90584: The EMA SMM regular expression was inconsistent. Impact: EMA SMM regular expression inconsistency. Root Cause: Earlier when \n\r was used in regular expression in CLI, the corresponding characters (\n,\r) were not visible in EMA. Steps to Replicate: The steps cannot be reproduced. Platform/Feature: SBC	The code is modified so if \n\r is used in CLI, it will show the same in EMA as well.
SBX-91904	2	The CLI stops at D2SSBC11. Impact: The SBC web server sessions including the configuration import session were getting terminated during log rotation. Root Cause: Process was getting killed because of the application session expiring. Steps to Replicate: The steps cannot be replicated. Platform/Feature: SBC	Existing sessions are preserved during log rotation. The configuration import is done with the NOHUP command to prevent session termination.
SBX-91326 / SBX-90875	2	Portfix SBX-90875: The LSASBX71 switched over and as a result, both sides cored. Impact: A bug in GW Signaling code can cause a core when the GW Signaling Links are bouncing. Root Cause: A bug in GW Signaling code can cause a core when the GW Signaling Links are bouncing. Steps to Replicate: The steps cannot be replicated. Platform/Feature: SBC	The code is modified to prevent this core.
SBX-91274 / SBX-90442	2	Portfix SBX-90442: Dead air on the SBC terminated calls when playing announcements. Impact: A fix correctly calculates the amount of memory that needs to be freed from the NP (say Y, which is a multiple of certain number of fixed sized buffers) to fit in a new announcement of size WavFile_X. Due to the design, Y is not equal to WavFile_X. Root Cause: This issue was caused because the max amount of announcements cached in the system was tampered. Steps to Replicate: Run a customer flow with customer's announcements all dumped into the system. Platform/Feature: SBC	The code is modified to fix the size calculation, so that the new announcements get added properly.
SBX-90976	1	The trunkGroupQoeStatus shows the incorrect values. Impact: The SBC was showing the static output as 94/93 for Qos parameters even when the trunk was running call. While checking the CDR for the call, the CDR contained invalid values (that depends in RTP packets) for QOS field. Root Cause: For cloud platforms, the Routing state was fetched from "configContextPtr" where as the Routing state is stored under the "currentContextPtr." Steps to Replicate: Set the global qoeCallRouting signalingQosBasedRouting to disabled. Set the global qoeCallRouting mediaQosBasedRouting to enabled. Make a call with the Media. Show the table addressContext default zone as ZONE1 trunkGroupQoeStatus. Verify the value of outbound RFactor. Platform/Feature: SBC	The code is modified so the QOs value is fixed from the correct context.
SBX-90791 / SBX-90415	3	Portfix SBX-90415: A bug in the EMA table views. Impact: All filters are not displayed for the tables like Call Detail Status, Call Media Status, and Call Resource Detail Status. Root Cause: The code changes were done to display the filters for all columns in the tables mentioned. Steps to Replicate: 1. Login to the EMA. 2. Navigate to Monitoring > Trunks and Subscribers > Sessions > Call Detail Status screen. 3. Filter the boxes above and the column will be displayed. Platform/Feature: SBC	The code is modified so all the attributes are marked irrelevant for the filter.
SBX-90761 / SBX-85820	3	Portfix SBX-85820: The CDR records are broken into multiple syslog messages. Impact: The CDR records are broken into multiple syslog messages. Root Cause: There was a limit to the message size of ~1.8K and the CDR messages beyond that will be split into multiple syslog messages. Steps to Replicate: Generate CDR's(size>1800) and transfer to remote syslog server. The SBC now transfers CDR's (size >4K) over to syslog server without breaking into multiple messages. Platform/Feature: SBC	The code is modified to transfer a complete CDR as one syslog message.
SBX-90601	1	The Santa Clara SBC02B failover. Impact: A CHM thread acquired a lock and started a long running operation. The health check timer on another thread waiting for the lock expired and the app crashed. Root Cause: The issue was from an existing code with locks. Steps to Replicate: Installed a fix build and ran sanity tests. Platform/Feature: SBC	The code is modified around the locks used in the CHM and also around health checks that are disabled for certain activities to ensure no crashes occur due to health check timeouts.
SBX-90283	2	The ScmP cored while importing CLI commands from the SBC Configuration Manager. Impact: The SIP process dumps core while importing the bulk CLI from the configuration manager. Root Cause: Due to duplicated bug, the FXS files (CLI schema files) were copied to the directory /opt/sonus/sbx/fxs. The copied FXS files resulted in near doubling of CLI execution time, resulting and delayed responses to the health check requests. Overtime, the SIP processing module is unable to respond to the health check request and dumps core. Steps to Replicate: Source the bulk configuration using the CLI. Platform/Feature: SBC	The code is modified to prevent the duplicate FXS files from being copied to /opt/sonus/sbx/fxs directory.
SBX-89741	1	The CPX may core during an upgrade from V05.01.05R000 to V07.02.01R001. Impact: The LSWU CLI command returned as a failure due to failure to create a package sub-dir under external directory but the upgrade continued at the backend. Root Cause: The upgrade script needs to be fixed here to stop the upgrade and exit if the CLI command returns with a sub-dir creation failure. Steps to Replicate: Test the LSWU to the fix version and verify if the upgrade is successful. Platform/Feature: SBC	The code is modified to ensure the package sub-dir creation is successful and if the CLI command returns failure, the upgrade will not be continued any further.
SBX-88673 / SBX-87527	1	Portfix SBX-87527: Conflicting IP address settings in the SBC. Impact: The SBC allowed the user to use the same IP address for route next top that caused a loss of traffic to all off-net peers across this interface. Root Cause: A 8.2.0 original issue. Steps to Replicate: set addressContext default ipInterfaceGroup PKT1_53_PUBLIC ipInterface PKT1_53_PUBLIC altMediaIpAddresses 66.43.97.129 set addressContext default staticRoute 47.44.160.79 32 66.43.97.129 PKT1_53_PUBLIC PKT1_53_PUBLIC preference 100 Platform/Feature: SBC	The code is modified to validate that static route's next hop IP address is not same as the IP interface's altMediaIpAddress.
SBX-86030	3	Remove the alarm that shows that the licenses exceeds the system limit. Impact: The sonusCpConfiguredExceedSystemLimit alarm was raised for the SWE and CLOUD instances. The session limit is depending on the HW(VCPU) being used and the alarm is only applicable for the Hardware platform. Root Cause: There was no check completed for platform before raising this alarm. Steps to Replicate: Verify the SWE or CLOUD SBC instance does not raise the sonusCpConfiguredExceedSystemLimit alarm when the license is installed more than 64000. Spawn the instance on the CLOUD or SWE Install the license bundle if on nodelocked /NWDL with any number of session license(SBC-RTU). Expected Result: sonusCpConfiguredExceedSystemLimit alarm will not be raised. Platform/Feature: SBC	The code is modified so only the hardware platform has raised the sonusCpConfiguredExceedSystemLimit alarm as a session limit.
SBX-75803	3	The SIP ReInvite race condition causes a call failure for relay cases. Impact: The SIP ReInvite race condition causes a call failure for relay cases Root Cause: When the End To End Re-Invite is enabled and the Session Refresh is received, the SBC used to only relay it to another leg skipping Offer-Answer negotiation. This is causing the Race-Conditions and causing call failures. Steps to Replicate: Enable the End-To-End Re-Invite and run a Session Refresh call flow. Platform/Feature: SBC	When the End To End Re-Invite is enabled and a Session Refresh is received, the SBC will process without skipping the Offer-Answer negotiation.
SBX-71623	3	The SMM header criteria was not matching the complete header value. Impact: The SMM header was criteria not matching the complete header value, it was only checking for the value between <>. Root Cause: The SMM was only checking the value enclosed between <>. Steps to Replicate: Write a criteria on header value and the issue will be reproduced. Platform/Feature: SBC	The code is modified to consider the entire header when comparing the criterion.
SBX-63721	2	The Asymmetric PRACK Interworking" was not working as described. Impact: Whenever any CodecEntry is deleted from codec list in PSP in the PSX, it re-arranges the codec list immediately. There will not be any empty codec entry on the list. Root Cause: When any CodecEntry is deleted, it was not re-arranging the CodecEntry, which adds a NULL value in that place. Steps to Replicate: 1. Configure CodecEntry1, CodecEntry2 all the way to CodecEntry12 2. Delete any CodecEntry. Result: Call will succeed. Platform/Feature: SBC: ERE	The code is modified so in PostRoute, the CodecEntry value is re-arranged. There is no NULL value in between two CodecEntry's.
SBX-94117 / SBX-93456	2	Portfix SBX-93456: The SWe_NP worker segfault was crashing. Impact: There is an issue in the JIO (SBX-93456), where the SWe_NP was crashing multiple times due to a skb_work->skb corruption. Root Cause: When observing the SWe, there is a point in normal media processing ( RTP and RTCP path), where there is an update with the skb_work->skb from addr_ptr that is not necessary, and it may corrupt the skb_work->skb. The corruption occurs in the path of processing RTCP XR packets, where the addr_ptr moves ahead by few bytes, but the UPP processing expects the MBUF address to be present back at 58 bytes from the addr_ptr. Steps to Replicate: Run JIO scenarios. Platform/Feature: SBC	The code is modified to avoid overwriting skb_work->skb from add_ptr.

Known Issues

Known Issues in 08.02.00R000 Release

The following issues exist in this release:

Known Issues

Issue ID	Sev	Problem Description	Impact/Workaround
SBX-93992	2	Post switchover SBC generates RTCP packets for ongoing calls which have RTCP relay between endpoints and have RTCP termination enabled.	Impact Statement: The SBC generates RTCP post switchover for ongoing calls, irrespective of RTCP generate state, which are Halt or Generate RTCP. New calls will behave as expected, acting upon RTCP Generate state. Workaround: None
SBX-94346	1	Transcoded HPC call failures observed when running high load for GETS beyond recommended call capacity for HPC.	Impact Statement: HPC calls and normal calls are dropped with 503 reason code when the SBC is operating beyond recommended call capacity. Workaround: Decrease the HPC call load to 12% of call capacity, wihich is within the recommended value.
SBX-94352	2	Packetloss and packet discards are not logged in CLI and CDR for T.140 streams with total packets less than 32.	Impact Statement: For T.140 streams with total packet less than 32 no packet loss statistics is reported. Statistics are reported correctly for T.140 steams with more than 32 packets. Workaround: None
SBX-94491	1	Media switchover delay can be around 5 seconds for ungraceful reboots of cloud SBC.	Impact Statement: Media switchover over delay can be around 5 seconds for specific case of active SBC ungraceful reboot. This is not applicable to I-SBC, SBC 5400 or 7000. Workaround: Issue sbxstop before reboot to ensure graceful reboot.
SBX-94532	2	Exposure to few security vulnerabilities that require kernel patch and updates.	Impact Statement: Exposure to few security vulnerabilities for SPECTER and MELTDOWN that requires kernel patch and updates. Workaround : None
SBX-94598	2	SBC relays the RTCP for text streams from MRF towards UE even though RR/RS is set to zero.	Impact Statement : SBC relays the RTCP from MRF towards UE even though RR/RS=0 as MRF is not honoring the RR/RS=0 for text streams. Workaround: Apply SMM to add RR/RS=0 for text stream in 2xx received from MRF if the offer sent by the SBC had RR/RS=0.
SBX-94693	2	Media information is not updated in Recording CDRs for SIPREC calls in D-SBC.	Impact Statement: Media Information is not updated in Recording CDRs on a DSBC Setup for SIPREC calls. Impacts debugging of SIPREC calls. This issue is not seen on I-SBC, SBC 5400 or SBC 7000. Workaround: None
SBX-94838	2	Securelink access does not work for SBC 5400 Standby server when all four management interfaces are configured and in use.	Impact Statement: Securelink connection establishment fails on 5400 when all four management interfaces are configured and in use. Workaround: Add static route for securelink server via mgt0 and mgt1: `ip route add securelink_ip via next_hop_ip mgt0` or `ip route add securelink_ip via next_hop_ip mgt1`
SBX-93930	2	I-SBC generates unexpected Re-Invite towards egress leg for T.140 transcode call.	Impact Statement: I-SBC sends an unnecessary Re-Invite to egress leg after receiving 200 OK for T.140 transcode call. This should not impact the ongoing call. Workaround: Enable minimizeRelayingOfMediaChangesFromOtherCallLegAll in PSPs.
SBX-94559	2	SBC spordically fails to accept calls with RTCP generation enabled under load conditions.	Impact Statement: The SBC fails to enable RTCP packet generation on one in million calls and drops the call. Workaround: Disable the RTCP generation.

Known Limitations

The following limitations exist in this release:

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.
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.
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.
The Antitrombone feature is not supported on the D-SBC.
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.
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.
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.
A LSWU on an SBC 7000 should only be performed when the total number of active calls on the system is below 18,000. If the criteria is not met, a double failure during the upgrade may occur thereby losing all active calls. If such a failure occurs, both active and standby SBC services will go down. Contact Ribbon Support immediately.

The VLAN tagged SRIOV packet interfaces are unable to ping endpoint Gateway IPs in the VMware platform because of an issue with VMWare.

Performing Heat Stack Update when userdata is Updated with SSH Keys

When upgrading SBC SWe cloud instances to release 8.0, you must update your Heat template userdata section to include mandatory SSH key information. An issue in OpenStack requires that you use the stack-update process rather than re-launch after updating the template, which leads to a new UUID for the instance. As a result, you must regenerate and apply new license bundles to the upgraded instances during the upgrade.

Refer to Upgrading SBC SWe N:1 HA Nodes on OpenStack using Heat Templates for the relevant procedure.

Restricted Functionality with SBC

The following functionalities are not supported with SBC Microservices:

Direct Media and Antitrombone
Far end NAT traversal
NICE
Rx, Rf interfaces
Fax detection
ICE/STUN
SIP REFER
SIP REPLACE
Two stage calls
H323 support
IMS LI support for multiple streams
MS Teams
Tones and Announcement using TSBC
Support for video only call

Space shortcuts

Page tree

SBC Core 08.02.00R000 Release Notes

Table of Contents

About SBC Release Notes

Related Documentation

Release Notes Use and Distribution

Associated Ribbon Announcements

Problems or Questions

About SBC Core

Interoperability

H.323-SIP and SIP-H323 Calls

Compatibility with Ribbon Products

Sample Heat Templates Included in This Release

SBC SWe Cloud Requirements for OpenStack

OpenStack Requirements

SBC SWe Requirements for KVM

SBC SWe Requirements for VMWare

Requirements for Using the Infrastructure as Code Environment with SBC SWe

Required Software and Firmware Versions

How to Verify Currently Installed Software/Firmware Versions

Software Bundles

SBC 5000 Series (51x0/52x0) Firmware

SBC 5400 Firmware

SBC 7000 Series Firmware

SBC Core Operating System Installation Package

SBC Core Application Package

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

Upgrade Notes

08.02.00R000 Upgrade Information

Support of maddr Post-Upgrade

SBC SWe Pre-Upgrade Requirements

VM CPU resource allocation requirements

Disable Call Trace feature prior to LSWU/upgrade

Manually check for Hostcheck Validation Failed message

Preparing for Upgrade (All Platforms)

Supported Live Software Upgrade (LSWU) Paths

New Features in Release 08.02.00R000

SBX-41671 TTY/TDD Interworking Support for RFC-4103 and/or RFC-4351

SBX-58717 + SBX-67514 P-Early-Media and DLRBT Enhancements

SBX-62459 Support for Public-key-Based Peer Authentication Method for IPSec

SBX-64041 IPSP flag “send SDP In Subsequent 18x” Evolved to “send SDP In Subsequent 18x if not reliable”

SBX-67554 LCQ CC/SIP Issue - Multiple Call Transfer - SIP Layer Stops Responding

SBX-68878 CDR for SIPREC Sessions

SBX-70005 Relay Changes in PAID as per RFC-5876

SBX-70465 STIR/SHAKEN: Option to Signal Verification Failures in Backward Provisional Responses

SBX-70938 RTCP for T.140 Pass-through

SBX-71386 Qualify Mellanox-based NIC Cards for SBC SWe – No OVS Offload

SBX-73110 - Support for Teams Direct Routing Using an SBC Hub

SBX-75174 - Generate or Replace SSRC Values for Calls Toward a Kandy Link WebRTC Gateway

SBX-75865 Alarm Generation when SBC Receives RCODE Except for 0

SBX-76436 - Increase CDR Retention with Compression

SBX-76610 Selection Feature for ARS Recovery Algorithm

SBX-85716 Re-initiate Pre-condition Negotiation Towards Ingress

SBX-85818 + SBX-85655 Support for SIP-ISUP

SBX-86008 Cloud SBC Avalanche Fault - Detection and Control

SBX-86658 Offer-Answer Timer Configuration

SBX-86789 - SBC Should Create TLS Connection Based on Contact Header

SBX-87239 Response Code Change When SBC Fails DNS Query

SBX-88422 - Support FQDN as GW SIP Address for PSX Proxy Calls

SBX-88542 - Prefix-based TG Selection using SMM

SBX-88601 + SBX-88885 – SMM: Support Global Configuration and Increased Number of Rules

SBX-88947 Test 2nd Management port on SWe platforms

SBX-89252 Generate SIP User-Agent Header to Identify SBC Platform and Release

SBX-90436 Capacity Scaling Support with OVS-DPDK Virtio Interfaces

SBX-87348 ARS support on SIPREC Trunk

SBX-85320 Implement Q-series Release 10.0 LI Interface

SBX-76608 Expected Error Response Based on Call Statistics

SBX-90410 Limit on Recording Criteria

Resolved Issues

Resolved Issues in 08.02.00R000 Release

Known Issues

Known Issues in 08.02.00R000 Release

Known Limitations

Performing Heat Stack Update when userdata is Updated with SSH Keys

Restricted Functionality with SBC