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).
The SBC Core 10.00.00 documentation is located at the following Wiki space: SBC Core 10.0.x Documentation.
Ribbon Release Notes are protected under the copyright laws of the United States of America. This work contains proprietary information of Ribbon Communications, Plano, TX-75023, USA. Use, disclosure, or reproduction in any form is strictly prohibited without prior authorization from Ribbon Communications.
The following Ribbon announcements (formerly known as WBAs) are referenced in this release note:
To view/download Ribbon announcements, do the following:
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)
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.
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.
H.323 is not supported on SBC SWe cloud deployments.
When upgrading your network, ensure to upgrade each product to the most current release to take advantage of the latest features, enhancements, and fixes.
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 this release.
The following table lists and describes the new features in this release.
Issue ID | Feature | Description |
---|---|---|
SBX-62641 | Input Sanitization for the EMA REST Interface | An interceptor is added to the SBC that does not impact the SBC Manager or User-Interface. This interceptor runs the action through the standard validation framework, which in turn checks the data (param) against any validation rules for all the fields. If the validation fails, an error message is generated. The following services/modules are captured in the new feature enhancement:
|
SBX-69037 | TLS support for MSRP B2BUA | The SBC provides additional support for communication over secure channels by extending TLS support to Message Session Relay Protocol (MSRP) and application sessions. In supporting TLS for MSRP, the SBC accepts SDP containing "TCP/TLS/MSRP" in the media description, such as the following example: m=message 7654 TCP/TLS/MSRP * For MSRP TLS sessions, the SDP path header must contain "msrps," such as the following example: a=path:msrps://456@10.54.81.88:1031/jshA7taswez;tcp The SBC only establishes a TLS connection if it receives an appropriate TLS certificate with a fingerprint that matches the TLS fingerprint in the SDP. Specifically, for INVITE requests, the SBC only establishes a TLS connection if the SDP fingerprint matches the fingerprint in the TLS certificate the SBC receives on the ingress leg. For 200 OK responses, the SBC only establishes a TLS connection if the SDP fingerprint matches the fingerprint in the TLS certificate the SBC receives on the egress leg. In either case, if the fingerprints do not match, the SBC does not establish a TLS connection but the SIP session is still active. The peer is responsible for releasing the session. In conjunction with this feature, the TLS profile now contains a parameter to specify a hash type. The options are:
The SBC supports MSRP and application TLS sessions for certificates generated for each one of these hash types. Further, the SBC Packet Service Profile (PSP) now provides an option (nonRtpTlsProfileName) to specify a TLS profile to apply specifically to TLS for non-RTP streams. For more information, see: |
SBX-91868 | Global Crankback Profiles | A crankback profile consists of a list of call release codes that the SBC uses to determine whether to reroute (or "crankback") a call. When egress signaling returns a release code that is in the list in the crankback profile, the SBC attempts to reroute the call. If a release code is not in the list, the SBC returns the release code to ingress signaling rather than attempting to reroute the call. Users can control which release codes trigger rerouting by adding or removing release codes from the active crankback profile. The SBC provides a default crankback profile (named "default"), the contents of which can be edited. Or, users can create their own crankback profiles. The SBC supports a total of 20 crankback profiles in the system. For flexibility, crankback profiles are configured at three levels: trunk group, zone, and global. By default, the "default" crankback profile is assigned at the SBC global level, while the trunk group and zone level crankback profile settings are initially empty (" "). Thus in the SBC default configuration, trunk groups and zones inherit the default crankback profile from the global level. However, if a user configures a profile at the trunk group or zone level, the user-specified profile assigned at the most specific level takes precedence. For more information, see: |
SBX-93115 | Web Socket on the SBC | WebRTC uses WebSocket as transport protocol mainly between the client (browser) and the WebRTC Gateway (GW). The WebRTC GW communicates with Core Session Control elements, such as SBCs, through traditional transport protocols including TCP and UDP. New WebRTC deployment models feature SIP/Session functionality supplied to the browser through JavaScript. For such cases, the browser uses the WebSocket transport to directly communicate with the SBC for SIP-based session control. This document defines requirements to support this model in the context of Ribbon SBC portfolio. SIP over Websockets (SIPoWS) enables SIP endpoints in web-deployment environments to communicate reliably over TCP/TLS. As the endpoint sends SIP over websockets, the SBC acts as gateway/B2BUA which converts SIPoWS to SIP in forward direction, and from SIP to SIPoWS in reverse. For more information, see: |
SBX-93883 | Support for Configurable Ciphersuites for the EmaTlsProfile | This feature allows users to configure ciphersuites for the SBC EMA TLS Profile. The list of ciphersuites configured in EMA TLS Profile are the ciphers enabled in Apache's SSLCipherSuite configuration for EMA and PM. This feature provides the following options:
|
SBX-95456 | Unable to Add Root Certificate of Domain Controller to the SBC Through EMA | This feature adds the Domain Controller root certificate to the SBC through the EMA. The new EMA interface imports the DC root certificate and stores the certificate content in the CDB/DB. In the earlier versions, the user needs to install and apply the Domain Controller root certificate manually. Also, the AD root certificate was not persistent during the SBX upgrade. For more information, see: |
SBX-96898 | EVENT Record does not Populate User-Agent and MAC Information | The SBC displays the following sub-fields of the Ingress/Egress Signaling Information field in the Event record for the Register message.
However, these sub-fields were not populated in the CDR even when the respective SIP headers were received in the Register message. This feature implementation ensures the above sub-fields are populated in the CDR when the corresponding headers are received in Register message. For more information, refer to EVENT Accounting Records for Ingress and Egress Fields. |
SBX-98550 | The SBC SWe Alarm Status: Include localTimeStamp and localInitialTimeStamp | The SBC supports Time Stamp and Initial Time Stamp in Alarms - Current Status and Time Stamp in Alarms - History Status. These fields provide the information of the time the alarm was last raised and initially raised. This feature introduces additional fields in the two CLIs (currentStatus and historyStatus), namely localTimeStamp and initialLocalTimeStamp for currentStatus, and localTimeStamp in historyStatus to provide the time in local time zone. In earlier versions, the SBC provided this information in GMT0 timezone, regardless of the timezone. There was a discrepancy in the GUI and the SBC CLI, as the GUI used local time and the SBC CLI used the GMT0 time. For more information, refer to: |
SBX-99809 | Ensure the RTCP TERM BRESs are not re-used during call modification | A feature is added to the the SBC to ensure the RTCP TERM BRESs are not re-used during a mid-call modification (including HOLD/RESUME) on "a transcoded call with RTCP enabled" or "pass-through call with the RTCP terminated on the SBC". This change is introduced to ensure the SBC does not re-use the RTCP TERM binding resources. |
SBX-100135 | ISUP Mime body is now in readable form in the L4 PDU trace file | The SBC can trace sent and received SIP messages. Although the message body is dumped to the trace file, it is neither machine readable (because Carriage Return +Line Feed is replaced by just Line Feed), nor human readable. This feature adds an additional trace for messages containing an ISUP MIME body to dump that information in a format which is both machine and human readable. |
SBX-101165 | Privacyprofile issues on applyPrivacyid & SupportedPrivacyId 2 | The SBC provides the flexibility in the transparency behavior of the From header and the PAI header. The SBC can send privacy:User toward egress through a new configuration flag sendPrivacyUser in the privacy profile. The SBC can apply privacyUser logic when when either of the privacy:user or privacy:id is received on Ingress using the new configuration flag ifRcvdPrivacyUserOrIdOrBoth. Anonymization procedures according to privacy profile configuration has been given higher precedence. If anonymization is not applied, the SBC gives higher precedence to the display name set by DM/PM rule and STI Display name. For more information, refer to: |
SBX-101539 | CLONE - SHAKEN Verification Does Not Populate Result Headers | The SBC supports sending the PSX derived STI parameters by decoding the received Identity from the STI-AS, based on the control at the PSX. In earlier versions, the SBC sends the Ingress received P-Origination-Id and P-Attestation-Indicator. For the verification, the PSX now adds the capability to base64, decode the payload part of the SHAKEN Identity header to derive the STI parameters, in the absence of these parameters in the verification response from the STI-VS. |
SBX-101783 | FAC Enhancements | The SBC implemented Fault Avalanche Control feature, a feature, which blocks SIP messages of certain key elements that it is aware to have caused multiple coredumps in past, to be blocked from being processed again. Currently key elements tracking and capturing is only done in SIPSG when some message comes from SIPFE. Other messages/icm modules (like CC, NRMA, etc.) are not tracked/captured. The feature is now extended to monitor the coredumps for the duration of the call as well as extended the scope to monitor the CC, NRMA, and SIPFE. This feature is configured the same as SBX-86008 (addressed in the 8.2.0 Release). For more information, see: |
SBX-102400 | Policy Profile Support for STIR SHAKEN | STIR-SHAKEN deployments require Policy Profiles, CPFP, and DM/PM rules support. This is for all SIP deployments. This feature provides flexibility for choosing different IP Signaling Profiles and STI profiles. The PSX adds the STI Generic Profile to give flexibility in choosing STI profiles on a per call basis.
In the PSX, the Inter Gateway IP Signaling Profile and Egress IP Signaling Profile entries under the 'Use SIP In Core' and 'SIP Used In Core' sections of the egress trunk group are added to configure IPSPs in SIP In Core calls for 'Use SIP In Core' or 'SIP Used In Core' or 'Regular SIP' call legs. The IPSP Generic Profile in the TG is used to provide flexibility in choosing IPSP for 'SIP In Core' calls. The SBC sends the SIP requests/responses based on the signaling parameters returned by the PSX. |
SBX-103464 | SBX-103497 | SBX-103706 | The DfGroupName is Different from the Realm Name | The field The field For more information, see: |
SBX-103607 | SSRC Randomization for SRTP Calls | The synchronization source (SSRC) identifier uniquely identifies media streams within an RTP session when establishing or modifying media sessions. In its standard processing, the SBC generates an SSRC when it transcodes a media stream and relays the SSRCs in pass-through calls. To provide flexibility in managing SSRC values in SRTP media flows, the SBC provides a configuration option (
The option for randomizing the SSRC for SRTP occurs as a flag within the Packet Service Profile (PSP). Through the PSP you assign to the ingress and egress trunk group for a call, you can control whether to enable the option on the ingress leg, egress leg, or both legs of a call flow. If the option is disabled on either call leg, the SBC relays the SSRC it receives from the peer on that leg. Note that the existing PSP flag For more information, see: |
SBX-103845 | SBX-105658 | Add SUBSCRIBE Transaction Failure Counter | This feature provides an Out of Dialog (OOD) relay SUBSCRIBE failure counter in the statistics 'sipSubCountStatistics'. In earlier versions of the SBC, the statistics 'sipSubCountStatistics' contained counters for sipSubCountAttempts, sipSubCountCumCompletions, and sipSubCountStable. This feature adds a new counter 'sipSubCountFailures' to report the SIP subscription failure counts for the SIP endpoints. In earlier versions, the SBC did not provide a way to track SUBSCRIBE request failures outside of the system congestion statistics SIP_SUBS_REJECTS. This statistics was only pegged during system congestion. With this feature, the SBC provides a KPI for all SUBSCRIBE request failures. For more information, refer to: |
SBX-105398 | The SBC was improperly populating the Egress TO header when stiProfile was configured on the Ingress TG | This feature overrides the User Info Value of FROM / TO / PAI even when transparency is enabled. |
SBX-105446 | Allow for comments in SMM | The SMM that is deployed in customer networks is often very complicated and the history behind why it is added or explanation on what it is trying to achieve is often lost. This feature adds the ability to include comment fields in the SMM configuration so the author can provide details on what the SMM is doing and why. |
To instantiate the SBC instances, use the following templates:
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. |
Example template files are packaged together in .tar.gz and .sha256 files separate from the SBC Core application installation and upgrade files:
The system hosting the SBC SWe Cloud must meet the below requirements.
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.
The SBC 5100, SBC 5110, SBC 5200, and SBC 5210 platforms are no longer supported beginning with the SBC Core 10.0.0R0 release. This release supports SBC 5400/7000/SWe platforms. Contact Ribbon Sales for upgrade information.
Required Software and Firmware Versions
Components | Software/Firmware | Version |
---|---|---|
SBC Platform | SBC 51x0/52x0 BMC | V03.22.00-R000 |
Kernel: 3.10.108 Busybox: v1.27.2 Openssh: 7.9p1 Openssl: 1.0.2n Lighttpd: 1.4.48-r0 Qualys security issues Password encryption method is SHA512 Lighttpd is secured and supports only TLS1.2 cipher. | ||
SBC 51x0/52x0 BIOS | V2.7.0 | |
SBC 5400 Firmware | BMC: V03.22.00-R000 BIOS: V1.18.0 | |
SBC 7000 Firmware | BMC: V03.22.00-R000 BIOS: V2.14.0 | |
SBC Application | Operating System (OS) Version | V09.00.00-R000 |
SonusDB | V10.00.00-R000 | |
SBC Application | V10.00.00-R000 |
The firmware package of SBC 5400 and 7000 series includes BMC, BIOS, and other binaries. The firmware is upgraded from the BMC.
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.
The following software release bundles are available for download from the Customer Portal:
Download the appropriate software packages for your desired configuration from the Customer Portal (https://ribboncommunications.com/services/ribbon-support-portal-login) to your PC:
When upgrading from release 9.0 and above, upload the SHA256 checksum file. Otherwise, use the MD5 file.
firmware-5XX0-V03.22.00-R000.img
firmware-5XX0-V03.22.00-R000.img.md5
bmc5X00_v3.22.0-R0.rom.md5sum
bmc5X00_v3.22.0-R0.rom
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.
The ConnexIP Operating System installation package for SBC Core:
Once the ConnexIP ISO procedure is completed, the SBC application package is automatically uploaded to SBC platforms.
The SBC Application installation and upgrade package for SBC Core:
sbc-V10.00.00R000-connexip-os_09.00.00-R000_256_amd64.qcow2.sha256
sbc-V10.00.00-R000.x86_64.tar.gz
sbc-V10.00.00-R000.x86_64.md5
For detailed information on installation and upgrade procedures, refer to SBC Core Software Installation and Upgrade Guide.
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:
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.
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 SBC 5110 and 5210 platforms require 24GB of RAM to run 6.x code or higher.
Release 8.2 and later requires additional user account security practices for SBC SWe deployments in Openstack cloud environments. During upgrade of SBC SWe cloud instances deployed using Heat templates, you must use a template that includes SSH keys or passwords for the admin and linuxadmin accounts. The example Heat templates have been updated to include information on how to specify this type of data in the userdata section of a template.
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.
Customers using network licensing mode will be converted to node locked mode (formerly legacy mode) after upgrade from SBC 8.0.0 Release and onwards.
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.
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.
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 |
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:
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:
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.
For more information, refer to:
Before beginning the upgrade on a SBC running code prior to 8.2R0, the following commands on all the DNS Groups needs to be issued if “ednsSupport” is enabled.
Failure statistics are not being mirrored correctly, and the LSWU state may stay in “syncing” if the “ednsFailures “ count is non-zero.
admin@PLUM> request addressContext default dnsGroup DnsGrp dnsServerReset
reason DNS Server statistics are Reset
[ok][2020-11-06 04:08:13]
admin@PLUM> show status addressContext default dnsGroup DnsGrp
dnsServerStatistics 2
{ ipAddress 10.54.81.77; queries 0; timeouts 0; errors 0; referrals 0; totalTcpConnection 0; tcpConnectionFailed 0; tcpConnectionSuccess 0; tcpConnectiontorndown 0; tcpFallback 0; ednsStatus supported; ednsFailures 0; }
[ok][2020-11-06 04:08:22]
admin@PLUM>
2. Disable the ednsSupport to stop mirroring of the statistics if the error count is constantly incrementing or likely to increase during the upgrade.
set addressContext default dnsGroup DnsGrp ednsSupport disabled
Note: The ednsServer stats will be lost/reset during the upgrade.
If the TRF/MRB Features are configured and enabled – some calls are unable to be cleared post upgrade if using the TRF/MRB attributes.
The upgrade is successful and calls continue but some calls may fail to clean up release post upgrade. Session KeepAlive and RTP Inactivity functions will clean any stale calls.
Enable the sessionKeepalive or rtpInactivity monitoring to ensure that mirrored calls are cleaned up post upgrade.
set addressContext default zone ZONE_AS sipTrunkGroup TG_AS_SIPP signaling timers sessionKeepalive <value>
OR
set system media mediaPeerInactivity <value>
set profiles media packetServiceProfile DEFAULT peerAbsenceAction peerAbsenceTrapAndDisconnect
Upgrade from a pre 9.2 release with globalization support for registration enabled will see a registration drop during an upgrade.
If the following localNumberSupport is enabled, those registrations will be dropped after first switchover during LSWU.
% set addressContext <name> zone <name> sipTrunkGroup <name> signaling localNumberSupport <disabled | enabled>
Prior to performing an upgrade to this release, you must remove usernames that do not conform to the SBC user-naming rules to prevent upgrade failure. Upgrade can proceed successfully after removing all invalid usernames. The following user-naming rules apply:
Usernames can 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 10.0.0R000
Prior to performing an upgrade to the 10.0 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.
Prior to performing an upgrade to 10.0 release, the duplicate trunk groups or zones must be removed. The steps are included in announcement "W-17-00022689".
CPU resource allocation requirements for SBC SWe VM are strictly enforced. You must review and verify these VM settings (including co-hosted VMs) against the documented "VM Configuration Recommendations" on the For VMware page in the Hardware and Software Requirements section before upgrading.
If you encounter a problem, correct the CPU reservation settings as specified in step 6 of the "Adjust Resource Allocations" procedure on Creating a New SBC SWe VM Instance with VMXNET3:
Set the CPU reservation for the VM so that it equals the physical processor CPU speed, multiplied by the number of vCPUs divided by two.
For example, a configuration of 4 vCPUs with a processor of 2.99 GHz CPU speed, reserve: 2992 * 4/2 = 5984 MHz
If the VM uses the same number of vCPUs as the number of physical processors on the server, this reservation may not be possible. In this case, reduce the number of vCPUs assigned to VM by one and set the CPU reservation to the appropriate value.
When using the show table system serverSoftwareUpgradeStatus
command during the upgrade, the Standby server's LSWU status will always display "Upgrading" even though the upgrade may have failed due to host checker validation. To check if host validation failed for the Standby, check for HostCheck Validation Failed message in the upgrade.out
log.
Perform the following procedure on the Standby to check for the Hostcheck Validation Failed message in the upgrade.out
log.
/opt/sonus/staging/upgrade.out
(this log shows the Hostcheck Validation Failed error).show table system serverSoftwareUpgradeStatus
to confirm the successful upgrade.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".
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 the SBC 9.2 - MS Teams Solution Guide.
For more information on IaC for Vmware, refer to Using the Ribbon IaC Environment to Deploy SBC SWe on VMware.
For more information on IaC for Azure, refer to Instantiate Standalone SBC with Terraform on Azure
Public Cloud Images:
AWS Image: ami-0d3bbd6d129a3cc13
Azure Image: release-sbc-v10-00-00r000-05-21-21-17-49.img
GCP Image: release-sbc-v10-00-00r000-05-21-21-17-48
IAC/RAF Builds/Scripts:
iac_sustaining_21.05_b270.tar.gz
sbc-V10.00.00R000-provisioning.tar.gz
sbc-V10.00.00R000-kvm_automation_scripts.tar.gz
sbc-V10.00.00R000-aws_automation_scripts.tar.gz
sbc-V10.00.00R000-aws_container.tar.gz
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
V07.xx | V08.xx | V09.xx |
---|---|---|
07.02.03S400 | 08.00.00R000 | 09.00.00R000 |
08.01.00R000 | 09.01.00R000 | |
08.01.00F001 | 09.01.00R001 | |
08.01.00R001 | 09.01.00R002 | |
08.01.00R002 | 09.01.00R003 | |
08.01.00R003 | 09.01.00R004 | |
08.01.00R004 | 09.02.00R000 | |
08.01.00R005 | 09.02.00R001 | |
08.01.00R006 | 09.02.00R002 | |
08.01.00R007 | 09.02.01R000 | |
08.01.00R008 | ||
08.02.00R000 | ||
08.02.00F001 | ||
08.02.00F002 | ||
08.02.00R001 | ||
08.02.00R002 | ||
08.02.01R000 | ||
08.02.01R001 | ||
08.02.01F001 | ||
08.02.01F002 | ||
08.02.01F003 | ||
08.02.02R000 | ||
08.02.02R001 | ||
08.02.02R002 | ||
08.02.02R003 | ||
08.02.02R004 | ||
08.02.02R005 | ||
08.02.02R006 | ||
08.02.03R000 | ||
08.02.03R001 | ||
08.02.03F001 | ||
08.02.04R000 | ||
08.02.04F001 | ||
The following table displays the security vulnerabilities that were resolved in this release.
CVE | Risk | Description |
---|---|---|
CVE-2021-26937 | Critical | encoding.c in GNU Screen through 4.8.0 allows remote attackers to cause a denial of service (invalid write access and application crash) or possibly have unspecified other impact via a crafted UTF-8 character sequence. |
CVE-2016-2147 | High | Integer overflow in the DHCP client (udhcpc) in BusyBox before 1.25.0 allows remote attackers to cause a denial of service (crash) via a malformed RFC1035-encoded domain name, which triggers an out-of-bounds heap write. |
CVE-2021-3348 | High | nbd_add_socket in drivers/block/nbd.c in the Linux kernel through 5.10.12 has an ndb_queue_rq use-after-free that could be triggered by local attackers (with access to the nbd device) via an I/O request at a certain point during device setup, aka CID-b98e762e3d71. |
CVE-2019-19816 | High | In the Linux kernel 5.0.21, mounting a crafted btrfs filesystem image and performing some operations can cause slab-out-of-bounds write access in __btrfs_map_block in fs/btrfs/volumes.c, because a value of 1 for the number of data stripes is mishandled. |
CVE-2020-28374 | High | In drivers/target/target_core_xcopy.c in the Linux kernel before 5.10.7, insufficient identifier checking in the LIO SCSI target code can be used by remote attackers to read or write files via directory traversal in an XCOPY request, aka CID-2896c93811e3. For example, an attack can occur over a network if the attacker has access to one iSCSI LUN. The attacker gains control over file access because I/O operations are proxied via an attacker-selected backstore. |
CVE-2021-26930 | High | An issue was discovered in the Linux kernel 3.11 through 5.10.16, as used by Xen. To service requests to the PV backend, the driver maps grant references provided by the frontend. In this process, errors may be encountered. In one case, an error encountered earlier might be discarded by later processing, resulting in the caller assuming successful mapping, and hence subsequent operations trying to access space that wasn't mapped. In another case, internal state would be insufficiently updated, preventing safe recovery from the error. This affects drivers/block/xen-blkback/blkback.c. |
CVE-2021-27364 | High | An issue was discovered in the Linux kernel through 5.11.3. drivers/scsi/scsi_transport_iscsi.c is adversely affected by the ability of an unprivileged user to craft Netlink messages. |
CVE-2021-3347 | High | An issue was discovered in the Linux kernel through 5.10.11. PI futexes have a kernel stack use-after-free during fault handling, allowing local users to execute code in the kernel, aka CID-34b1a1ce1458. |
CVE-2021-28831 | High | decompress_gunzip.c in BusyBox through 1.32.1 mishandles the error bit on the huft_build result pointer, with a resultant invalid free or segmentation fault, via malformed gzip data. |
CVE-2020-27815 | High | A flaw was found in the JFS filesystem code in the Linux Kernel which allows a local attacker with the ability to set extended attributes to panic the system, causing memory corruption or escalating privileges. The highest threat from this vulnerability is to confidentiality, integrity, as well as system availability. |
CVE-2020-11023 | Medium | In jQuery versions greater than or equal to 1.0.3 and before 3.5.0, passing HTML containing <option> elements from untrusted sources - even after sanitizing it - to one of jQuery's DOM manipulation methods (i.e. .html(), .append(), and others) may execute untrusted code. This problem is patched in jQuery 3.5.0. |
CVE-2021-26932 | Medium | An issue was discovered in the Linux kernel 3.2 through 5.10.16, as used by Xen. Grant mapping operations often occur in batch hypercalls, where a number of operations are done in a single hypercall, the success or failure of each one is reported to the backend driver, and the backend driver then loops over the results, performing follow-up actions based on the success or failure of each operation. Unfortunately, when running in PV mode, the Linux backend drivers mishandle this: Some errors are ignored, effectively implying their success from the success of related batch elements. In other cases, errors resulting from one batch element lead to further batch elements not being inspected, and hence successful ones to not be possible to properly unmap upon error recovery. Only systems with Linux backends running in PV mode are vulnerable. Linux backends run in HVM / PVH modes are not vulnerable. This affects arch/*/xen/p2m.c and drivers/xen/gntdev.c. |
CVE-2017-15873 | Medium | The get_next_block function in archival/libarchive/decompress_bunzip2.c in BusyBox 1.27.2 has an Integer Overflow that may lead to a write access violation. |
CVE-2020-29568 | Medium | An issue was discovered in Xen through 4.14.x. Some OSes (such as Linux, FreeBSD, and NetBSD) are processing watch events using a single thread. If the events are received faster than the thread is able to handle, they will get queued. As the queue is unbounded, a guest may be able to trigger an OOM in the backend. All systems with a FreeBSD, Linux, or NetBSD (any version) dom0 are vulnerable. |
CVE-2021-28038 | Medium | An issue was discovered in the Linux kernel through 5.11.3, as used with Xen PV. A certain part of the netback driver lacks necessary treatment of errors such as failed memory allocations (as a result of changes to the handling of grant mapping errors). A host OS denial of service may occur during misbehavior of a networking frontend driver. NOTE: this issue exists because of an incomplete fix for CVE-2021-26931 |
CVE-2021-23841 | Medium | The OpenSSL public API function X509_issuer_and_serial_hash() attempts to create a unique hash value based on the issuer and serial number data contained within an X509 certificate. However it fails to correctly handle any errors that may occur while parsing the issuer field (which might occur if the issuer field is maliciously constructed). This may subsequently result in a NULL pointer deref and a crash leading to a potential denial of service attack. The function X509_issuer_and_serial_hash() is never directly called by OpenSSL itself so applications are only vulnerable if they use this function directly and they use it on certificates that may have been obtained from untrusted sources. OpenSSL versions 1.1.1i and below are affected by this issue. Users of these versions should upgrade to OpenSSL 1.1.1j. OpenSSL versions 1.0.2x and below are affected by this issue. However OpenSSL 1.0.2 is out of support and no longer receiving public updates. Premium support customers of OpenSSL 1.0.2 should upgrade to 1.0.2y. Other users should upgrade to 1.1.1j. Fixed in OpenSSL 1.1.1j (Affected 1.1.1-1.1.1i). Fixed in OpenSSL 1.0.2y (Affected 1.0.2-1.0.2x). |
CVE-2020-36158 | Medium | mwifiex_cmd_802_11_ad_hoc_start in drivers/net/wireless/marvell/mwifiex/join.c in the Linux kernel through 5.10.4 might allow remote attackers to execute arbitrary code via a long SSID value, aka CID-5c455c5ab332. |
CVE-2021-3178 | Medium | ** DISPUTED ** fs/nfsd/nfs3xdr.c in the Linux kernel through 5.10.8, when there is an NFS export of a subdirectory of a filesystem, allows remote attackers to traverse to other parts of the filesystem via READDIRPLUS. NOTE: some parties argue that such a subdirectory export is not intended to prevent this attack; see also the exports(5) no_subtree_check default behavior. |
CVE-2020-27825 | Medium | A use-after-free flaw was found in kernel/trace/ring_buffer.c in Linux kernel (before 5.10-rc1). There was a race problem in trace_open and resize of cpu buffer running parallely on different cpus, may cause a denial of service problem (DOS). This flaw could even allow a local attacker with special user privilege to a kernel information leak threat. |
CVE-2020-11022 | Medium | In jQuery versions greater than or equal to 1.2 and before 3.5.0, passing HTML from untrusted sources - even after sanitizing it - to one of jQuery's DOM manipulation methods (i.e. .html(), .append(), and others) may execute untrusted code. This problem is patched in jQuery 3.5.0. |
CVE-2021-27363 | Medium | This vulnerability has been modified since it was last analyzed by the NVD. It is awaiting reanalysis which may result in further changes to the information provided. |
CVE-2020-29130 | Medium | slirp.c in libslirp through 4.3.1 has a buffer over-read because it tries to read a certain amount of header data even if that exceeds the total packet length. |
CVE-2020-29660 | Medium | A locking inconsistency issue was discovered in the tty subsystem of the Linux kernel through 5.9.13. drivers/tty/tty_io.c and drivers/tty/tty_jobctrl.c may allow a read-after-free attack against TIOCGSID, aka CID-c8bcd9c5be24. |
CVE-2020-28916 | Medium | w/net/e1000e_core.c in QEMU 5.0.0 has an infinite loop via an RX descriptor with a NULL buffer address. |
CVE-2019-19813 | Medium | In the Linux kernel 5.0.21, mounting a crafted btrfs filesystem image, performing some operations, and then making a syncfs system call can lead to a use-after-free in __mutex_lock in kernel/locking/mutex.c. This is related to mutex_can_spin_on_owner in kernel/locking/mutex.c, __btrfs_qgroup_free_meta in fs/btrfs/qgroup.c, and btrfs_insert_delayed_items in fs/btrfs/delayed-inode.c. |
CVE-2015-9261 | Medium | huft_build in archival/libarchive/decompress_gunzip.c in BusyBox before 1.27.2 misuses a pointer, causing segfaults and an application crash during an unzip operation on a specially crafted ZIP file. |
CVE-2019-19318 | Medium | In the Linux kernel 5.3.11, mounting a crafted btrfs image twice can cause an rwsem_down_write_slowpath use-after-free because (in rwsem_can_spin_on_owner in kernel/locking/rwsem.c) rwsem_owner_flags returns an already freed pointer, |
CVE-2021-26931 | Medium | An issue was discovered in the Linux kernel 2.6.39 through 5.10.16, as used in Xen. Block, net, and SCSI backends consider certain errors a plain bug, deliberately causing a kernel crash. For errors potentially being at least under the influence of guests (such as out of memory conditions), it isn't correct to assume a plain bug. Memory allocations potentially causing such crashes occur only when Linux is running in PV mode, though. This affects drivers/block/xen-blkback/blkback.c and drivers/xen/xen-scsiback.c. |
CVE-2021-20181 | Medium | A race condition flaw was found in the 9pfs server implementation of QEMU up to and including 5.2.0. This flaw allows a malicious 9p client to cause a use-after-free error, potentially escalating their privileges on the system. The highest threat from this vulnerability is to confidentiality, integrity as well as system availability. |
CVE-2021-20221 | Medium | An out-of-bounds heap buffer access issue was found in the ARM Generic Interrupt Controller emulator of QEMU up to and including qemu 4.2.0on aarch64 platform. The issue occurs because while writing an interrupt ID to the controller memory area, it is not masked to be 4 bits wide. It may lead to the said issue while updating controller state fields and their subsequent processing. A privileged guest user may use this flaw to crash the QEMU process on the host resulting in DoS scenario. |
The following Severity 1 issues are resolved in this release:
Severity 1 Resolved Issues
Issue ID | Sev | Problem Description | Resolution | |
---|---|---|---|---|
1 | SBX-100881 | 1 | The SBC incorrectly sends a call release to the H.323 side. Impact: The SBC is sending a call release to the H323 side. Root Cause: During the codec selection on H323 side, the SBC ran into some offer-answer collision due to ACK SDP from SIP side. As a result, the SBC is terminating the call. Steps to Replicate:
| The code is modified so that the codec selection on the H323 side occurs independently during a modify offer-answer is in progress. Workaround: NA |
2 | SBX-105657 | 1 | An SBC Upgrade failed. Impact: The LSWU upgrade failed from 7.2.2R0 to 8.2.3R0. Root Cause: The /tmp partition was running out of disk space and the restoration failed during an upgrade. Steps to Replicate: Run a LSWU upgrade from 7.2.2R0 to 10.0.0. | The code is modified to ensure there is enough space available. Workaround: A workaround done at the field is freed some space in /tmp dir and re-ran the upgrade. |
3 | SBX-108325 | 1 | SBC1 failed to switch over to SBC2; SBC2 did not take over. Impact: The safplus_gms process crashes when coming out of a split brain. Root Cause: Incorrect/inconsistent data results in the code asserting. Steps to Replicate: This problem is not easily reproducible and is caused by HA link instability/flapping. | The code is modified so that the data is consistent. Workaround: Fix HA link stability issues. |
4 | SBX-105687 | 1 | The SMM rule for options stopped working after the SBC 5400 upgrade to 9.1. Impact: The SMM rules were not applied after upgrade to 9.1 for the Options Ping Scenario. Root Cause: The code was modified to pick the same TG for request and response. In the Options ping scenario, request and response use defaultiptg and as a result, the SMM was not being applied. Steps to Replicate:
| The code is modified to apply the SMM at the global level for OPTIONS Ping. Workaround: NA |
5 | SBX-108388 | 1 | The SBC set "user=phone" on Dummy History-Info header Impact: When interworking between diversion header and history info header if the diversion count is more than 2, then the SBC generates dummy history info headers. These dummy history info headers contain user=phone which some end points reject. Root Cause: The code was mistakenly adding the user=phone attribute even when no phone number was present in the dummy history info header. Steps to Replicate: Configure the SBC to support interworking from diversion header with a count of 5 to history info headers and check that the dummy history info headers do not include user=phone. | The code is modified to not include user=phone in the dummy history info headers. Workaround: The SMM could be used to remove the user=phone attribute from the dummy history info headers. |
6 | SBX-105439 | 1 | When configuring “serverCertName” in the TLS profile, the SBC does not check if “serverCertName” actually exists Impact: The SBC is not validating that a certificate is present during the configuration of “serverCertName” as part of the TLS profile. Root Cause: The SBC is not validating whether certificate is present or not during configuration of “serverCertName” as part of TLS profile. Steps to Replicate:
Expected result: | The code is modified to validate if a configured certificate is present on the SBC. Workaround: Enter valid configuration information. |
7 | SBX-106691 | 1 | Adding IPSP fails with an application error. Impact: The error message is not descriptive when the addition of an IPSP fails due to 'includeDtg' option. Root Cause: The error message is not set properly during the validation of adding the IPSP profile for 'includeDtg' parameter. Steps to Replicate: Create a IPSP with "includeDtg" parameter as shown below: | The code is modified to set the correct error message. Workaround: No workaround. |
8 | SBX-109464 | 1 | The leadership algorithm workaround for old openclovis issue can cause a core dump. Impact: The safplus_gms process crashes when coming out of a split brain. Root Cause: Incorrect/inconsistent data results in the code asserting. Steps to Replicate: The problem is not easily reproducible and is caused by HA link instability/flapping. | The code is modified so that the data is consistent. Workaround: Fix HA link stability issues. |
9 | SBX-106920 | 1 | The SBC FmMasterProcess dumped core after a switchover with stable call. Impact: The FmMasterProcess core dumps during a shutdown. Root Cause: The FmMasterProcess may deadlock during a shutdown due to receiving an event while trying to shutdown/finalize the event handling. Steps to Replicate: This is extremely timing sensitive and requires an event being published from AMF to FM at just the right time in the shutdown sequence. There is no way to consciously reproduce the issue. | The code is modified to avoid the possibility of the deadlock. Workaround: No workaround exists. |
10 | SBX-107987 | 1 | SBC:UXPAD dumped core for EVS call modification scenario. Impact: When a PCMU to EVS or vice versa, the 3pcc call is run with a Modify Channel on the EVS Leg to PCMU, the SWe_Uxpad coredumps with a Segmentation Fault while de-initializing the EVS Channel. Root Cause: The root cause of the issue is that the function to initialize a new Codec was called before de-initializing the previous Codec in a Call Modify Scenario. This was leading to corruption of some variables in previous Codec's data that was then being accessed during de-initializing the same Codec. Steps to Replicate:
The call should be successful without any core-dumps. | The fix is to call de-initialize the first and then init in a call Modify Scenario. Workaround: None. |
11 | SBX-107954 | 1 | The SBC CPXA coredump after an EVS+T140 SBC call. Impact: Occasionally, when the show global callDetailStatus command is executed in the CLI, the CPX process coredumps. Root Cause: If information is not available for a particular call, the data returned did not have a valid type for the Ip addresses returned. This caused a timeout out in confd because the CPX did not return information for the global callDetailStatus. Steps to Replicate: The steps cannot be reproduced. |
Workaround: Do not run the global callDetailStatus command. |
12 | SBX-107492 | 1 | The SCM Process core dump was observed after 2 hours of load run with EVRCB to G711 transcode calls. Impact: During a call load, the SIPFE module was crashing while writing the date to a mapped address. Root Cause: The written map address files are causing a delay and leading to health check time outs causing core dumps. Steps to Replicate: Run a 100 cps SIP-SIP call load for about 2- 6hrs period of time. | The code is modified from file to Shared memory, which solved the problem Workaround: None. |
13 | SBX-107690 | 1 | Call failures were observed on T140 load with various MAJOR logs in DBG. Impact: A call fails due to RID Enable errors. (where RID = receiver ID and is mapped to an allocated resource). Root Cause: When the RTCP Generation is disabled, the RTCP RID for the call is expected to be disabled by Network Processor (NP). Steps to Replicate: Enable Packet Service Profile //Resources/profiles/media/packetServiceProfile/rtcpOptions/generateRtcpForT140IfNotReceivedFromOtherLeg. | The code is modified so the Bus Resource Manager (BRM) knows whether RTCP RID is allocated and needs to be disabled by NP. Workaround: Disable RTCP and disable RTCP termination. |
14 | SBX-109922 | 1 | The snprintf buffer too small. Need 50 Have 26 File:getting this error on executing the RTCP enhancements feature. Impact: The buffer used while printing PSP's was running out because of large PSP. Root Cause: The buffer used while printing PSP's was running out. Steps to Replicate:
| The code is modified to accommodate bigger strings. Workaround: NA |
15 | SBX-108126 | 1 | Observed a SAM Process crash in another active node during SIPFE crash testing. Impact: The SAM Process coredumps due to a buffer overflow. Root Cause: Key:value length of incoming Message is max 255 Bytes. Steps to Replicate: Steps:
Expectation:
| The code is modified to handle 255 bytes string, so the buffer overflow does not happen and display is not truncated. Workaround: NA |
16 | SBX-107976 | 1 | Disable the FAC feature in M-SBC, SLB. Impact: Non-SIP personalities should not have FAC feature. So when the Non-SIP instance coredumped, then FAC handler Process was invoked to generate a core file. Root Cause: Do not have check of personalities of instances when setting core pattern. Steps to Replicate: Verify the user defined core pattern is not set in /proc/sys/kernel/core_pattern when instances are spawned with the personalities M-SBC, SLB, MRFP irrespective of facState. | The code is modified to not to set the user defined core pattern for personality type MSBC, MRFP, and SLB. Workaround: Disable the FAC Feature. |
17 | SBX-108612 | 1 | A SCM Process coredump occurred when INVITE with message size of 31700 bytes is sent. Impact: Receipt of SIP messages with Content-Type: multipart/mixed and more than 10 content entries cause coredump, if a message manipulation rule is active with criterion on message body. Root Cause: Missing handling for an unexpected message received. Steps to Replicate: Configure and apply a message manipulation rule with criterion messageBody. | The code is modified that if more than 10 content entries are present, the message is not considered for MM rule actions with criterion on message body. Workaround: None. |
18 | SBX-108219 | 1 | A SAM Process coredump was observed in SLB for 1000 cps Peering Call load. Impact: In a load run, there was a core being observed in the SLBDEBUG call when it hits the default states as part of the SBC message processing. Root Cause: In the SLB debug call, there was new line (\n) being passed as part of a string. Steps to Replicate: Observed this issue in load run, so specific functional test cases is not identified, we can run the same load run to reproduce this issue. | The code is modified so the new line (\n) is not part of the debug string. Workaround: There is no workaround identified for this issue. |
19 | SBX-109597 | 1 | Observed an SCM process crash on the newly active SSBC during SWO testing. Impact: While the SBC is running in sensitive mode, observed the SCM Process core during a switchover testing under the 1000 cps call load. Root Cause: As part of switchover, all the connected calls are rebuilt on a newly active SBC. But, there may be a chance that the SBC can hold few stale entries related to active calls in the system, which will be cleaned up after some time. If any of these stale entries receive an unexpected events, that leads to a core dump. Steps to Replicate:
| The code is modified to identify these events for the stale entries and ignore them to avoid a coredump when the SBC running in the sensitive mode. Workaround: None. |
20 | SBX-109616 | 1 | A core dump was observed in the SCM process in 2vcpu system. Impact: Fault Avalanche Control is enabled by default from release 9.2. If it is disabled, it can result in a coredump. Root Cause: When the Fault Avalanche Control is disabled, the mem map file is disconnected, but the application can still try to access the mem map as the mem map pointer was not set to NULL. Steps to Replicate: Disable the Fault Avalanche Control and run calls. | The code is modified so the mem map pointer is set to NULL to when feature is disabled to address the issue. Workaround: Without this fix, avoid disabling the Fault avalanche Control. |
21 | SBX-107972 | 1 | There are multiple PRS Process coredumps on both the active and standby while running a 2 day EVS + T140 -> AMR-WB + T140 load. Impact: Multiple PRS Process coredumps occurred on both the active and standby while running a 2 day EVS + T140 -> AMR-WB + T140 load. Root Cause: The message drops in internal queues due to a momentary congestion. This resulted in cascading call-failures, which in turn resulted in in PRS core dump. Steps to Replicate: Setup: 1. SBC 2:1 - cluster with flavor 16vCPU/20GB RAM/CPU Procedure: Start the call load EVS + T140 to AMR-WB +T140 @20 cps and 13s CHT, and run the load for 2-3 days. | The code is modified by ensuring the control messages experience a larger queue depth while traversing internal queues, and as a result the PRS core dump is not seen in this bug. However, as part of making the module more robust, additional NULL checks are introduced to ensure we do not access invalid NP Pool data. Workaround: None. |
22 | SBX-109953 | 1 | Observed a NP_WRK0 Core on an active instance on the OpenStack while using VIRTIO. Impact: The SWe_NP can crash during a sbxrestart or sbxstop in the extra small memory profile. Root Cause: There is corruption due to incorrect use of global variable in an extra small memory profile. Steps to Replicate:
| The code is modified to address the issue. Workaround: None. |
23 | SBX-106760 | 1 | While running the IMS AKA Registrations on the SWe KVM, cannot achieve 1000 subscribers with 30 RPS properly. Impact: The SBC was not able to achieve the IMS AKA registrations even at a lower rate (30 registrations per second). Root Cause: For one of the IPSec features, the XRM code was modified to perform route lookup and next hop destination MAC resolution during IPSec SA setup. This was causing a delay in setting up IPSec SAs during load causing timeouts during the IMS AKA registration. Steps to Replicate: Run the IMS AKA Registration load at 30rps. | The code is modified to not invoke the route loopup and destination MAC resolution code that is causing delay in setting up IPSec SA, which addresses the issue. Workaround: None. |
24 | SBX-107182 | 1 | Observed the "154 02172021 101624.655260:1.01.00.07241.MAJOR .NRS: ARP lookup for 172.10.2.3 on interface pkt0.2 with addrContextId 1 failed: SIOGARP error, error 6" MAJOR Logs on the SBC while running the IMS AKA Registrations. Impact: The MAJOR logs related to the ARP lookup was getting logged in the .DBG files, when the IMS AKA registration load is run. Root Cause: The log is generated when there is no ARP entry in the ARP table. The debug log was generated for each UE IP, for which there is no ARP entry. For one of the IPSec features, the XRM code was modified to perform a route lookup and destination MAC resolution during the IPSec SA setup. The ARP lookup is done as part of MAC resolution. Steps to Replicate: Run IMS AKA Registration load. | The code is modified to not invoke the route loopup and destination MAC resolution code that is causing delay in setting up IMS AKA registrations, which addresses the issue. Workaround: None. |
25 | SBX-106871 | 1 | An application timeout occurred while checking callDetailStatus. Impact: The CLI 'show table global callCountStatus' timed out after a call setup failure due to the codec license not being available. Root Cause: The call setup failure in early stage caused an internal out of sync of the call resource, that triggers a handler of 'show table global callCountStatus' timeout when accessing the call resource. Steps to Replicate: Create a call in the SBC with no available codec license of the call. | The code is modified to clear the call resources in all related internal modules upon call failure in early stage. Workaround: None. |
26 | SBX-110184 | 1 | While pumping the emergency call load on top of normal call load, the HPC calls are getting rejected with a 488 SIP error due to a DSP overload even though resources were reserved on the Openstack DSBC HA. Impact: The HPC calls are rejected with 488 even though the SBC has sufficient DSP resources reserved for such calls through the highPriorityCompressionReservation configuration. Root Cause: In a DSBC setup, when DSP allocation request is received, the T-SBC applies the call admission policy to know whether the call can be admitted or not before proceeding with DSP allocation. In this process, the T-SBC was not considering if the allocation request was for HPC call or normal call. As a result, the HPC calls were treated like normal call leading to rejections if this T-SBC is running under high load. Steps to Replicate:
| The code is modified to give preferential treatment to HPC calls during call admission policy at the T-SBC. Workaround: No workaround. |
27 | SBX-106475 | 1 | The SBC instances are not coming up after fresh installation or rebuild and mgmt IP is unreachable in BLR-PC3. Impact: The SBC instances are not coming up after a fresh installation or rebuild and the mgmt IP is unreachable when using the X710 sriov vfs for pkt interfaces. Root Cause: It is sometimes seen that the X710 reset takes times to finish. So after the OS boot as part of renaming of the interfaces done by sonusudev, we restart the X710 driver after renaming and expect it to come up immediately. But as the X710 takes time in reset, it does not come up immediately and due to that, the next cloud-init service fails and the system is not in proper state. Steps to Replicate: The SBC instances should come up properly after fresh installation or rebuild and mgmt IP should be reachable with all supported sriov vfs for pkt interfaces. | The code is modified so after the renaming is done and the network driver is restarted, the SBC waits for to ensure all NIC ports are up and running in sonusdev before exiting the service. This blocks all other dependent service from starting. Once the NIC ports are up, proceed with the system bring up. With these code changes, the NIC does not come up. Then, the SBC logs it as critical log, and expects the user to check it. Workaround: None. |
28 | SBX-109224 | 1 | An ius fails with an error message "instance is not reachable" even though the upgrade status is "success :true". Impact: The AWS upgrade was failing due to instance non-reachability. In actuality, the VNFC was up and running, but the VNFR showed VNFC status as non-reachable. Root Cause: The VNFR-VNFC communicates using a ZMQ and VNFR updates the VNFC health check using the same ZMQ thread mechanism. There is a Zmqclient and ZmqServer. After an undetermined point in time, the VNFC(ZmqClient) is waiting for an infinite time to get a response from the VNFR(ZmqServer). This is leading blocking state. Steps to Replicate: Run an upgrade/revert operations on 9.2.2/10.0.0. | The code is modified so the ZMQ communicates in non-blocking mode. Workaround: For the workaround, the user needs to run the pre check command from vnfr_intf before upgrade/revert operations and needs to take action provided as a part of output table. |
29 | SBX-109747 | 1 | The SBC (PRS) is dumping core while updating Meta Variables table to add a new SIP signaling port. Impact: The SBC PRS Process stops when a new SIP signaling port is added that specifies an ipAddress using a meta variable in the system metaVariableDynamic table. Root Cause: The code that reads the meta variable from the metaVariableDynamic table was hanging on a confd cdb_get_values call. Steps to Replicate:
| The code is modified to use the confd cdb_get_str call to retrieve the entry from the metaVariableDynamic table. Workaround: Do not reference entries in the metaVariableDynamic table when adding SIP signaling ports. |
30 | SBX-109702 | 1 | Post-switchover, the CHM process cored on the Active Node on V10.00.00-A007. Impact: The CHM coredumps as the DRBD fails to unmount during a CHM termination. Root Cause: The dataagent service is running and accessing the DRBD partition that causes the DRBD unmount to fail. Steps to Replicate: On the Hardware or SWe 1:1, perform a switchover so that current active node goes down. | The code is modified to prevent a CHM coredump by stopping the dataagent before unmounting DRBD service and start dataagent service again. Workaround: None. |
31 | SBX-108237 | 1 | Observed the SAM and SCM process coredump for FAC enabled execution on the SBC 5400. Impact: The SCM coredumps when the Invite gets a transaction timeout and the 200 Ok for Invite is received at the same time. Root Cause: In the problem scenario, the SBC is trying to send ACK for the 200 OK, the SCM cores when creating a SIP Transaction for ACK Message. Steps to Replicate:
A race condition might occur and result in coredump. | The code is modified not to send ACK in this scenario as the CseqType and CseNumber are unknown and 0 respectively. Workaround: None. |
32 | SBX-108225 | 1 | A coredump occurred after a fresh install of SBC SWe on VMware. Impact: The SSREG and SLWRESD processes a coredump on SBC SWe on VMware because the time value was set to the past. Root Cause: When the SBC is installed using ISO and then app is installed, the ntp sync is occurring while the application is running and in case the time is set in the past, it causes SSREQ and SLWRESD processes to core dump. Steps to Replicate: Launch with the NTP IP other than a default IP, check if a coredump occurs due to time being set in the past. | The code is modified to update the /etc/ntp.conf before the SBC comes up so the runntpdate can access the NTP server IP. Workaround: None. |
33 | SBX-108127 | 1 | The 9.1.0R3 to 10.0.0R0 LSWU failed with reason "Failed_to_install_or_configure_database". Impact: The LSWU failed with the reason "Failed_to_install_or_configure_database". Root Cause: Ownership for the files in /var/log/postgresql is getting changed at the time of the upgrade. Steps to Replicate: Perform an upgrade from any version to 10.0x. | The code is modified to restore ownership of the log files in /var/log/postgresql to postgress. Workaround: None. |
34 | SBX-106452 | 1 | Standby AWS SWe is not coming up. Impact: There are hardcoded references to the admin user in the SBC LCA code; and if the admin user is removed, a bring up may fail on virtual platforms. Root Cause: There was no exception handling around admin user usage that causes bring up process to error out. Steps to Replicate:
| The code is modified to address the issue. Workaround: Follow the MOP:
|
35 | SBX-108080 | SBX-108413 | 1 | PortFix SBX-108080:The SBC does not add ICE information when receiving the same SDP content in multiple 18x messages. Impact: When the egress endpoint sends multiple 18x messages with the same SDP followed by a 200 OK, in certain configurations this causes the SBC to send a re-INVITE to the ingress endpoint after the 200 OK. However, when ICE is configured on the SBC ingress trunk group, this RE-INVITE does not include the expected ICE parameters. Root Cause: The code that processes the SDP to send in the re-INVITE for this particular scenario is not correctly adding the ICE parameters. Steps to Replicate: Test ------- Enable acceptAlertInfo on ipSignalingProfile associated with egress trunk group, e.g. Procedure
Results
| The code is modified to either not send the RE-INVITE when there is no change to the SDP or to add the required ICE parameters if RE-INVITE is necessary. Workaround: Certain scenarios cause this issue, for example if acceptAlertInfo is enabled on egress ipSignalingProfile or if downstream forking is enabled. If such configurations are not necessary and can be disabled, the issue can be avoided. |
36 | SBX-107517 | SBX-110505 | 1 | PortFix SBX-107517: Importing the configuration produces two different final status results depending what is observed Impact: The postgres DB restore fails that leads to other CLI issues. Root Cause: The postgressDB restore is failing due to restricted permissions. Steps to Replicate: Set up required: 1-to- S-SBC virtual platform and register it within Direct-Single type of cluster on the EMS.
After the fix, re-attempt the four steps. The delete is successful. | The code is modified to give permissions to postgres user while restoring pg_policy dump. Workaround: Use the following script: #cd /opt/sonus/sbx/scripts find Run the script above on both active and SBY box. |
37 | SBX-107983 | SBX-108365 | 1 | PortFix SBX-107983: The LSWU from V07.02.00-R002 to V09.02.00-R001 has failed with the error "CpxIntfErrorExit" Impact: The upgrade fails with a SNMP table update error. Root Cause: The incorrect upgrade code that tries to update with a non existent key. Steps to Replicate: Test the upgrade from 7.2 with a different version of the SNMP trap targets configured. | The code is modified to use the correct keys. Workaround: None. |
38 | SBX-106852 | SBX-108090 | 1 | PortFix SBX-106852: An SBC switchover and coredump occurred while modifying DTMF relay params. Impact: The SCM Process may core while modifying DTMF relay parameters on a call leg's active packet profile. Root Cause: There was a case where the active packet profile was null when it tried to update DTMF output params that can cause the SCMprocess to crash. Steps to Replicate: Coredump analysis and code review. | The code is modified to check for activeProfilePtr before modifying DTMF settings. Workaround: None |
39 | SBX-104334 | SBX-106057 | 1 | PortFix SBX-104334: An IPV6 call drop occurred when placing a call on hold. Impact: "anonymous.invalid" signaled in c-line for IPv6 media is not considered as a on-hold request and rejected. Root Cause: There is no handling for "anonymous.invalid" while handling hold. Steps to Replicate:
| The code is modified to check for "anonymous.invalid" and if present consider it as call hold and avoid going for DNS resolution. Workaround: Use SMM to modify "anonymous.invalid" to "::" on the incoming side. |
40 | SBX-108516 | SBX-109089 | 1 | PortFix SBX-108516: A call outage leads to DSP errors. Impact: Call fails due to RID Enable errors. Root Cause:
Steps to Replicate: Test with calls that use the RTCP terminations and will set rtcp-xr-relay-drop to TRUE. | The code is modified to provide the following:
Workaround: Disable RTCP and RTCP termination in PSP |
41 | SBX-110247 | SBX-110310 | 1 | PortFix SBX-110247: The "sonusSbxNodePolicerMinorAlarmNotification" alarm is generated by the SBC. Impact: Packets arriving on a unallocated port do not get marked as rogue media. Root Cause: The issue only occurs on ports that were used and disabled. Packets arriving on this port get marked as grace-media packets. This is because a very high value of grace period is being incorrectly programmed for the udp port instead of the default 4 seconds. The high value is because of endianness. Steps to Replicate:
| The code is modified to perform appropriate endianness translation on the affected fields to arrive at the correct value. Workaround: No workaround. This does not affect normal media processing, or associated statistics. |
42 | SBX-108194 | SBX-108507 | 1 | PortFix SBX-108194: No audio on media hairpin/loopback calls Impact: With port redundancy enabled, the RID of loopback call is programed with srcMac = dstMac in NP. After port switchover, LVM notified XRM for MAC address update. Then the same RID of loopback call's srcMac got updated, but the dstMac is still set to old MAC address which cause no audio issue after port switchover. Root Cause: The root problem was that in XRM process MAC address update notify routine, XRM only updated new MAC address in xres->nif→locMacAddr. But IP static header is built with both xres->nif->locMacAddr and xres->route->macAddr. So xres->route->macAddr != xres->nif->locMacAddr after port switchover. Steps to Replicate: Test on both SWe and SBC 7000 platforms
| The code is modified to first update all the routes using the old MAC address with new MAC address received from LVM, and then update NIF's locMacAddr. Workaround: Single IP address on pkt port. |
43 | SBX-109055 | SBX-109180 | 1 | PortFix SBX-109055: An error occurred in the EMA when modifying and saving sipAdapterProfile. Impact: An error occurred in the EMA when modifying and saving sipAdapterProfile. Root Cause: The scenario comes up when profile name has ellipses in datatable. If profile is too big, ellipses (...) at the end will be added. Steps to Replicate:
| The code is modified so the title is not available in profile name without ellipses and as a result, taking the text from selected entry. Workaround: No workaround. |
44 | SBX-109893 | SBX-109916 | 1 | PortFix SBX-109893: The SBC frequently performs a switchover with a coredump after 9.2.1R0 upgrade. Impact: An SCM core occurred in code that is executed only when the STI feature is enabled. The core was the result of the code in SipSgStiCopyDisplayNametoCPC() attempting to de-reference a NULL pointer. Root Cause: There is code in an STI specific function that attempted to de-reference a NULL pointer. A NULL pointer check is missing in this code. Steps to Replicate: The specific steps to reproduce this issue are not known. The root cause and the fix were found by code inspection and core analysis. | The code is modified to address the issue. Workaround: The only known workaround is to disable STI. |
45 | SBX-104522 | SBX-109477 | 1 | PortFix SBX-104522: The dm/pm rules are ignored by the ERE. Impact: When launching an ENUM SIP AOR query, the ERE is losing the ability to do DM rules configured on the egress TG to called number. Root Cause: This is not a bug. It is a restriction in design. The DM on Called and Translated numbers was restricted if ENUM service occurred. Steps to Replicate:
| The code is modified so the customer can bypass that restriction. Workaround: None, if DM rule on egress TG applied when the ENUM service is used. |
46 | SBX-109174 | SBX-109309 | 1 | PortFix SBX-109174: The SBC is unable to load configuration after upgrading from 7.2.3S400 to 10.0A006. Impact: After upgrading a cloud SBC from a pre 9.2.0 version, cannot reload the config when the 'SystemName' is not set to 'vsbcSystem'. Root Cause: The configuration filename (pre-9.2.0) uses 'vsbcSystem' instead the of the defined 'System Name', meaning the SBC is unable to find the file to load it. Steps to Replicate:
| The code is modified so both the filenames have 'System Name' and 'Actual System Name' in them. Workaround: Change the configuration filename to be that of the set 'SystemName'. |
47 | SBX-106611 | SBX-107114 | 1 | PortFix SBX-106611: The SBC sends a bye message within dialog occasionally. Impact: After a call is connected, if the SBC triggers internal re-INVITE due to minimizeRelayingOfMediaChangesFromOtherCallLegAll flag on one leg; and at the same time, if the SBC receives a late media re-INVITE on other leg, the SBC clears the call. Root Cause: Internal offer answer state of call at the SBC SIP subsystem becomes invalid. Steps to Replicate: Configuration: After the call is connected, the SBC triggers internal re-INVITE to egress with one crypto. This is wrong. When the SBC receives another late media re-INVITE on ingress leg, the SBC sends it to egress and this second re-INVITE transaction completes successfully. | The code is modified to ensure if the SBC is handling internal re-INVITE on egress leg, late media re-INVITE on ingress leg is responded with 491 Request Pending with RetyAfter header. After the egress re-INVITE transaction is completed, if ingress peer send another late media re-INVITE, it is sent to the egress leg correctly and offers answer transaction succeeds for this second re-INVITE. Workaround: Suppress internal re-INVITE on egress leg. |
48 | SBX-108557 | SBX-109025 | 1 | PortFix SBX-108557: The SBC continuously core dumps for the SCM process since upgrade to V09.02.01R000. Impact: The SCM Process may coredump due to memory corruption. Root Cause: There is code that is using an invalid pointer when writing to a buffer. This code was only added recently in 9.2.1R0. Steps to Replicate: This problem is triggered by the receipt of an invalid PDU and/or an SMM rule to reject the incoming Invite and an early ATTEMPT record was attempted to be written. The issue is random and depends on what info is NOT available when trying to write the accounting record, therefore the issue may not reproduce all the time. | The code is modified to address the issue. Workaround: If there is SMM rule (ignore/reject the Invite), then the SMM rule needs to be disabled until patch is applied. |
49 | SBX-109336 | SBX-109985 | 1 | PortFix SBX-109336: The BIOS was not updated to 2.07 post-upgrade as specified in release notes. Impact: The BIOS is not upgrading as part of the SBC app upgrade. Root Cause: The flashrom utility is using /dev and /proc file system to upgrade BIOS. These file systems are un-mounted part of grub2 configuration upgrade. Steps to Replicate: Upgrade the SBC app from 7.x (BIOS=2.6) to >= 8.1.x.(BIOS = 2.7). The BIOS should upgrade part of the app upgrade. | The code is modified to mount /dev and /proc file system before calling BIOS upgrade. Workaround:
This scripts will take few minutes to update BIOS, after it has done reboot host. In next boot, it will boot up with new BIOS. |
50 | SBX-105917 | SBX-106092 | 1 | PortFix SBX-105917: The SBC fails to relay 4xx-6xx responses when IPTG authentication is enabled after 100 trying. Impact: When the IPTG authentication is enabled, the SBC maps all 4xx-6xx SIP codes to CPC 176. As a result, the SBC is unable to relay cause code from egress to ingress endpoint. Example: 486 Busy Cause code was not relayed to ingress side. Root Cause: When the IPTG authentication is enabled, the SBC maps all 4xx-6xx SIP codes to CPC 176. Steps to Replicate:
The SBC correctly sent 486 BUSY received from egress to ingress. | The code is modified to ensure that receiving an error code other than 401 and 407 clears the authentication flag and relays the actual cause code from egress to ingress. Workaround: Use CPC mapping to map CPC code 176 to required SIP cause code. |
51 | SBX-110003 | SBX-110192 | 1 | PortFix SBX-110003: The SBC 5400 coredumped after an MSRP call with direct media. Impact: A PRS core was encountered when customer was running MSRP with direct media and MSRP Multiplexing was enabled. Root Cause: The root cause is that MRM code is using an invalid array index to get a pointer to an array element. Steps to Replicate: This is not reproducible as it is most likely triggered by a race condition. | The code is modified to ensure that MRM uses the correct array index when attempting to get a pointer to an array element. Workaround: The only known workaround is to avoid running MSRP with direct media and MSRP Multiplexing. |
52 | SBX-110354 | 1 | After upgrading from V08.02.04R000 to 10.00.00R000 successfully, reverting from 10.00.00R000 to V08.02.04R000 is failing. Impact: Revert from a higher software version to a lower software version is failing. Root Cause: OAM does not upload the restored revision against lower software version (ie. restore of config tar ball which was created on lower software version before upgrade). And after following the MOP for downgrade when OAM comes up, it downloads the last revision uploaded on EMS (in this case config revision for higher software version). As a result, it fails to to start the service because of version mismatch. Steps to Replicate:
Expected O/P: | The code is modified to upload the configuration when a revision that is created on a lower software version is restored. And after a downgrade, it picks the revision with software version where the downgrade is completed. Workaround: None. |
53 | SBX-106063 | 1 | The cranckback is not working for a non-INVITE for SIP In Core. Impact: For a SIP In a core, Cranckback was not working for non-INVITE. Root Cause: For non-INVITE requests, there was a check for the Last Tried IP where the SBC compares the next route IP with last route's IP. Since in a SIP In core, the route IP is always of SBC2, and due to this the next route was never tried. Steps to Replicate:
| The code is modified not compare the route IP's and as a result, the SBC tries the next route after cranckback. Workaround: None. |
54 | SBX-109323 | 1 | TOD Routing broken for non-ALL timeRangeProfiles Impact: TOD Routing broke. Root Cause: The appropriate bits are not getting set for hexadecimal value during conversion of hexa value. Steps to Replicate:
| Code changes are done to set correct value. Workaround: None |
55 | SBX-109208 | 1 | Increase healthcheck interval Impact: Coredumps are occasionally seen in the field due to health check timer expiries when process gets stuck. Root Cause: In SWE environments its possible there are disk / cpu timing issues which can lead to the process slowing down and hitting these health checks e.g. over subscription of host machine. Steps to Replicate: This issue was only reproduced using debug code. | The health check logic has been updated to be more forgiving to cope with short spikes. The health check ping interval has been changed to 2 seconds and needs to have 15 consecutive non responses in order for the process to be declared deadlocked and a coredump initiated to recover. Workaround: None |
The following Severity 2-3 issues are resolved in this release:
Severity 2-3 Resolved Issues
Issue ID | Sev | Problem Description | Resolution | |
---|---|---|---|---|
1 | SBX-101432 | 3 | Query on "DSP insertion" CDR field | |
2 | SBX-107164 | SBX-107655 | 2 | PortFix SBX-107164: Teams: The SBC should handle MOH version 2. Impact: MS Teams changed the mechanism for putting an active call on hold and signaling redirection of the call media to music-on-hold server (MOH). The original mechanism (MOHv1) sent a REFER to the SBC to refer the call to the MOH server. The new new mechanism (MOHv2) sends a re-INVITE to the SBC that may require the SBC to switch the media from primary to secondary NIFs. The SBC does not support this mid-call media switching with a re-INVITE. As a result, the media was not switching correctly to the MOH server. Root Cause: The SBC code does not support mid-call media switching between primary and secondary NIFs with a re-INVITE. Steps to Replicate: Tests will require MOHv2 enabled on MS Teams client:
| The code is modified to allow the media and ICE stun processing to switch between primary and secondary NIFs based on the X-MS headers received in a mid call re-INVITE message. Workaround: No workaround is supported for MOHv2, but call hold mechanism will work fine with MOHv1. |
3 | SBX-60855 | 2 | Customer FTTH Stat for TG-A and TG-C Stat was not matching. Impact: Not decrement active register count on ingress TG when refresh REGISTER is incorrect due to this there is difference in count of total stable registrations across zones. Root Cause: When the load of bad Refresh or initial REGISTERs received, at SBC for some of the registers not getting userNPhoneContextKey due to this the code that is responsible for reducing activeRegCount is not executed. Steps to Replicate:
Actual Result: After a bad refresh REGISTER, the SBC sends 400 Bad to Refresh REGISTER and also reduces the activeRegCount on the ingress side, but it will not reduce count on egress side. Expected Result: The SBC should not do any count changes when refresh register fails. | Remove the check of userNPhoneCOntextKey. The check is not needed, there might be some load cases where we do not get username. Workaround: None. |
4 | SBX-107825 | 2 | The LM (MoH) re-INVITE replied 200 OK (video inactive). Impact: The video stream continues to be on HOLD even though the Audio stream is offered as sendrecv, when the SBC generates an offer for late-media re-INVITE in covert mode. Root Cause: While sending an offer in 200 OK for late media re-Invite, the SBC changed the audio DPM to sendrecv but video DPM was not changed and retained as inactive based on the last negotiated DPM on that leg. Steps to Replicate: To re-create the issue: Configure the Latemedia support as Convert at the SBC.
| The code is modified to change the DPM for both audio and video streams to sendrecv while generating offer for late media re-INVITE in Convert mode. Workaround: None. |
5 | SBX-105050 | 2 | The SBC DRBD mount was not visible on the active SBC. Impact: The SBC DRBD mount was not visible on the active SBC. Root Cause: When the sbxrestart is issued from platform manager, the DRBD gets mounted on apache's mountspace. Steps to Replicate:
| The code is modified to address the issue. Workaround: None. |
6 | SBX-107960 | 2 | The AWS IPs remain assigned to the standby SBC. Unnecessary dual restarts. Impact: If communication between the active and standby is broken (over ha0 interface), both assume active roles (split brain). When this happens, standby node that becomes active calls AWS APIs to move IP address to self. Once the ha0 link is restored machine which becomes active does not call AWS API to move IP addresses, this might cause issue when node which has IP doesn't come up as active, in this case IPs are assigned on standby and another node becomes active. Root Cause: Root cause of this issue is not calling AWS switchover API (move IPs) during split brain recovery. Steps to Replicate: Do a split brain test and recovery of the SBC HA, and verify that API query is send by the active SBC after a recovery. | The code is modified to call AWS APIs to move IP to current active machine during split brain recovery path. Workaround: Manually move all secondary IPs to current active machine to restore calls. |
7 | SBX-107518 | 2 | The Active SBC gets into 'syncInProgress' state even after recovering from network glitch. Impact: The Active SBC gets into 'syncInProgress' state even after recovering from network glitch. Root Cause: Since the network glitch is detected only on the Active SBC side, the standby SBC side does not initiate sync process after the active system recovers from the network glitch. Steps to Replicate: Simulate a network glitch such that only the active SBC detects it and recovers from it. For this, we can try this command with different sleep values between 5 and 6: | The code is modified so the standby SBC checkfs or the sync state of the active SBC and based on that, it initiates the sync process with the active SBC. Workaround: No workaround. |
8 | SBX-103985 | 3 | The SBC use disabled the user for a configuration import in the Profile Import/Export. Impact: When importing the configuration using configuration import feature, a random Administrator group user is getting used. Root Cause: The user was randomly picked regardless of the one who initiated the action in import configuration. Steps to Replicate:
| The code is modified so the import is done using the same user who initiated import. Workaround: None. |
9 | SBX-106242 | 3 | The FS errors verification can be incorrect in a pre-install or pre-upgrade scenarios. Impact: Pre-install checks can fail to find FS errors. Root Cause: The FS errors in the kernel log may be unable to be read if non-ascii exist or if it has been rolled. Steps to Replicate: Write the message 'EXT3-fs error' to /dev/kmsg. Attempt to upgrade the system. | Look for FS errors from a file of errors from dmesg instead to address the issue. Workaround: Do not upgrade the system if the sonusCpSystemFaultyHardDiskNotify trap is triggered and is not resolved. |
10 | SBX-101409 | 3 | A T140 call - one-way stream - zero media port (NAPT media). Impact: The call ends up in one-way audio after the called party puts the call on hold and off hold twice. Root Cause: As a result of call-modify a couple of times, the RTCP NAPT learning completes before RTP NAPT learning. This results in RTCP Remote Address being updated, which has remote RTCP Port. Due to incorrect code in RTCP modify flow, remote RTCP port, gets assigned to RTP port. This results in one-way media. Steps to Replicate:
| Set the correct RTP Port as part of RTCP modify flow. Workaround: Since the issue is caused to RTCP NAPT learning completed before RTP during multiple hold/unhold scenario, a workaround could be:
|
11 | SBX-108173 | 3 | Openclovis split-brain recovery data was not always correct. Impact: On recovery from a split brain, a leader may not be properly chosen and both machines could stay running for multiple minutes. Root Cause: The data passed to the leader election algorithm does not properly indicate both nodes are leaders. Steps to Replicate: Repeatedly break and reconnect the HA connection checking that the nodes realize they are coming out of split brain (via logs) and one node properly restarts to again become standby. | The code is modified so that the isLeader field is properly set and the leader election algorithm can properly detect when coming out of split brain. Workaround: None. |
12 | SBX-105609 | 3 | Add check for /boot partition free space in the pre-checks. Impact: Upgrade failure due to insufficient disk space on /boot partition. Root Cause: Upgrade failed due to failure to copy the new boot images as part of upgrade due to insufficient disk space in /boot partition. Steps to Replicate: Upgrade to the fix build and ensure upgrade is successful. | The code is modified to ensure a minimum of 40MB free disk space is available on /boot partition. Workaround: None. |
13 | SBX-107190 | 2 | Enabling the DisableZoneLevelLoopDetection not working on ZONE level. Impact: When the DisableZoneLevelLoopDetection and loopDetectionFeature are both enabled, loop detection is occuring at the zone configured for DisableZoneLevelLoopDetection. Root Cause: When the loop detection flag is enabled at both zone and global level, the global logic was taking precedence over zone. Steps to Replicate:
| The code is modified to give precedence to DisableZoneLevelLoopDetection over loopDetectionFeature when the loopdetection flag is enabled at both zone and global level. Workaround: None. |
14 | SBX-106167 | 2 | The call ends up in one-way audio after the called party puts the call on and off hold twice. Impact: The call ends up in one-way audio after the called party puts the call on hold and off hold twice. Root Cause: As a result of call-modify a couple of times, the RTCP NAPT learning completes before RTP NAPT learning. This results in RTCP Remote Address being updated, which has remote RTCP Port. Due to incorrect code in RTCP modify flow, remote RTCP port, gets assigned to RTP port. This results in one-way media. Steps to Replicate:
| Set the correct RTP Port as part of RTCP modify flow. Workaround: Since the issue is caused to RTCP NAPT learning completed before RTP during multiple hold/unhold scenario, a workaround could be:
|
15 | SBX-103619 | 2 | The SBC Stripping SS Attribute causing the call to drop. Impact: The SBC is not relaying the "a=silenceSupp:Off" attribute received in the answer from the UAS when the initial offer from UAC does not contain the silence suppression attribute. Root Cause: When the answer is received from UAS with silence suppression:Off attribute present in the SDP, the egress SIPSG is able to decode the codec from the SDP as G711 only. But, while feeding this answer to NRMA, the OA-FSM is changing it to G711S causing NRMA to send the same codec information to the ingress SIPSG. Due to this, the SBC is not sending the attribute in the answer towards the UAC. The logic in OA-FSM is such that, if the SBC offers a single codec(which is G711S) towards UAS and if it receives a single codec in the answer(G711), then it feeds the NRMA with the offered codec as an answer to NRMA. In this case, the egress OA-FSM is sending G711S as an answer when 200 OK is received from UAS instead of G711. Steps to Replicate:
| The code is modified to match and feed the right codec that is received from the Peer towards NRMA Workaround: None. |
16 | SBX-102726 | 2 | The diameter RX inputted the wrong data in media-component AVP post T.38-488. Impact: On detecting the fax tone, the SBC sends a T38 re-INVITE towards end point and at that time it triggers preliminary AAR with T38 Codec-Data AVP. When receiving a 488 for T38 Re-INVITE, a fallback occurs and the SBC triggers the G711 re-INVITE from SIPSG. And when receiving a 200 OK for re-INVITE, the SBC should send the final AAR with offer and answer the codec-data AVP having G711 (last negotiated). Instead of sending the final AAR offer, the SBC was sending g711 in answer codec-data AVP and T38 in offer codec-data AVP, which is wrong. Root Cause: On getting 488 for T.38 Re-INVITE, a fallback to the G711 occurs at SIPSG itself and on getting 200 OK for G711 re-INVITE. Steps to Replicate:
| The code is modified so the SBC sends the last negotiated SDP information in offer and answer codec-data AVPs of final AAR, so added fix for this. Workaround: Not applicable. |
17 | SBX-104507 | 2 | The SBC is not passing URI parameter while History to Diversion interworking. Impact: The SBC is not passing URI parameter user=phone while History to Diversion interworking, though the parameter is present in History Info Root Cause: There was no support for the requested functionality was present until date. Most likely, it was a miss due to lack of requirements. Steps to Replicate:
| The code is modified to include URI parameter user=phone in diversion header, when history info header has the uri parameter user=phone during interworking. Workaround: None. |
18 | SBX-104733 | 2 | There was an SCM process coredump for the healthcheck. Impact: The SCM Process cored when too many set operations executed in a single commit. Root Cause: The SIPSG task takes longer than 10 sec when subscribing the changes made to TrunkGroup. Steps to Replicate: Configured 12 TG. Modify 11 TG in a single commit CLI will throw following error: Aborted: 'addressContext default zone ZONE_IAD sipTrunkGroup': Too many set operations between commits. Revert the session and retry(max set operations 10). Again modify 10 TG in single commit. | The code is modified to 10. Previously, it was 50. Workaround: It is recommended to perform a commit after each single commit. |
19 | SBX-105763 | 2 | Move the dmesg monitoring from the SM to a platform cronjob. Impact: Move the dmesg monitoring from the SM to a platform cronjob. Root Cause: On the long running, the SBCs since dmseg can be big and can take longer to dump logs, the function can take longer and can cause the SM healthcheck. Steps to Replicate: Check for "/var/log/sonus/tmp/dmesgErrorMarker.tmp" after manually running the script. | Developed a new script to run every minute as a cron job to find i/o and filesystem errors in dmesg. If error is found, it creates a marker file in tmp that can be later used by other script to check sanity of the system. Workaround: None. |
20 | SBX-102469 | 2 | The time zone is defaulting to EST/EDT on the SBC instances while using image based instantiation. Impact: The time zone is defaulting to EST/EDT on the SBC instances while using image based instantiation. Root Cause: The timezone value in sbx.conf is not being picked up and used to update ntp xml and /etc/timezone. Steps to Replicate: Launch instance with timezone other than default timezone. It should show the appropriate timezone. | Update timezone value from sbx.conf in ntp xml and set /etc/timezone. Workaround: None. |
21 | SBX-109688 | 2 | The incorrect appVersion is getting displayed after upgrading the SBC Cluster from V08.02.04R000 to V10.00.00A008. Impact: The incorrect app version is showing on the rgstatus in case of split brain. Root Cause: The older serf event is processed and used for updating the join time. Steps to Replicate: Upgrade to 10x from 8.2 so in case split brain occurs, the rgstatus should not show incorrect version. | The code is modified to not process serf events until 5 seconds delay after member join event is processed. Workaround: None. |
22 | SBX-88007 | 2 | The call flow does not work when using six streams (5 video + 1 audio). Impact: The call fails if peer SDP contains six streams (5 video and 1 audio) and directMedia along with ICE is enabled at the SBC. Root Cause: Memory allocated for this SDP was not enough during the inter process communication resulted in the failure. Steps to Replicate: Test requires ingress TG in Zone1, egress TG in Zone2 and AS TG on the SBC, with call to be routed as follows: UE1 -> ingress TG -> AS TG -> AS peer (sipp) -> AS TG - egress TG -> UE2
Actual Result: The call fails. | The code is modified to accommodate six streams. Workaround: None. |
23 | SBX-105175 | 2 | The SBC sends re-INVITE while the media is played on ingress side in GW-GW early media call. Impact: In a GW-GW call scenario, while the media is played on ingress Gateway, the egress SBC is sending a Re-INV to UAS. Root Cause: Before the ingress GW completes its end to end activation, it received a MODIFY OFFER request from egress GW due to the change in SDP received in 200 OK for lockdown INV. This caused the ingress GW to process modify offer first and then end to end activation later that triggered a Re-INV towards UAS. Steps to Replicate:
| The code is modified so while the modify offer-answer is handled properly during end to end activation. Workaround: None. |
24 | SBX-106163 | 3 | The term side had a disconnect issue. Impact: For redirection scenario, re-INVITE is sent out by the SBC to redirected server under following condition:
Root Cause: When the Enhanced local redirection flag is enabled, re-INVITE was generated to redirected endpoint even after call is cleared (i.e. discReason set to CPC_DISC_NORMAL_CALL_CLEARING). Steps to Replicate: Procedure:
| The code is modified to fix the issue by adding discReason check of CPC_DISC_WITH_NEW_DESTINATION in addition to Enhanced Local Redirection flag check. Workaround: None. |
25 | SBX-106629 | 2 | While expecting the 200 OK, the SBC is sending 503 Service Unavailable. Impact: In a late media convert call scenario with LRBT enabled, the SBC is sending 503 service unavailable when connect is received from egress EP. Root Cause: The SBC was trying to initiate an UPDATE without checking whether it has received SDP in the PRACK from the ingress Peer that is resulting in the call failure. Steps to Replicate: The LRBT is enabled on the ingress Trunk.
| The code is modified to check whether the SBC is received any SDP from the peer, so that, the call establishment occurs successfully. Workaround: None. |
26 | SBX-106127 | 2 | The SBC Product name is incorrect for the SBC on AWS in release 10.0. Impact: The sbcDiagnostic incorrectly prints product name as "ConnexIP5000" instead of "AWS". Root Cause: Platform type is determined by querying platform data using dmidecode command, due a bug in the query platform type is returned as unknown. As a result of this bug, the sbcDaignostic shows generic product name ("ConnexIP5000"). Steps to Replicate: Run sbcDiagnostic command from Linux shell of the SBC. It shows the following: ************SBC Information ********* ************SBC Information ********* | The code is modified to return correct platform type. Workaround: No workaround. |
27 | SBX-105391 | 2 | The SBC SmProcess leak on OAM active for MRFP SWO Impact: While carrying out operations like a config upload to EMS, memory is leaked. Root Cause: The Python/C APIs cause a memory leak while using functions to the upload/download configuration from the EMS. Steps to Replicate: Create a direct single instance (ASAN build) registered with the EMS, carry out operations saveAndActivate/restoreRevision and change glog/sanitizer_SmProcess* and verify there no leaks due to the operation above. | Change the implementation from using Python/C APIs to libcurl. Workaround: NA |
28 | SBX-105711 | 2 | The CE_2N_Comp_CpxAppProc leak during disable and enable of pkt port Impact: Creating an H248 signaling port results in a small memory leak. Root Cause: While processing the H248 signaling port creation command when metavars are defined for the IP value, the SBX allocated memory to hold the metavar value from CDB internally for processing, but never freed up this memory block at the end of the port creation action resulting in a small leak. Steps to Replicate: Create an MRFP instance where metavars are used to define the IP value for the H248 signaling port. | The code is modified to correctly free the memory block at the end of processing the signaling port creation. Workaround: None. |
29 | SBX-109084 | 2 | The IPv6 SBC traps are not received to the EMS. Impact: For trapTargets, certain IPv6 addresses are sent to the incorrect IPv6 address. Root Cause: If the IPv6 address, converted to the form of 16 decimal octets was separated by periods have a length greater than 47 digits, the address will be truncated. Steps to Replicate: Provision an OAM SNMP trapTarget with an address of 253.0.0.16.107.80.97.176.97.176.97.176.0.0.97.176 | The code is modified so the IPv6 string is stored in a buffer of 64 characters that accommodates any IPv6 address. Workaround: None. |
30 | SBX-105387 | 2 | LeakSanitizer:SCMP_3 gave memory leaks at MemAlloc2 and the same gave Heap overflow issue, both from the same caseID. Impact: The Heap use after free detected in the ASAN for a downstream forking call flow. Root Cause: When copying multiple contacts from a different downstream forking response, the username of the contact header was not updated from the call block to sip message handle. The SIP Message handle was holding an address that was already freed. Steps to Replicate: Run Downstream Forking Call Scenario as shown below:
| The code is modified with the correct username from the call block for every downstream forking response. Workaround: None. |
31 | SBX-109017 | 2 | SBC: Observed MAJOR logs for BRM "BrmAsyncCmdErrHdlr" on T140 load. Impact: Occasionally enable the RID errors in NP when the system is subjected to large number of call flows that employ RTCP termination. Root Cause: The message drops in internal queues due to momentary congestion. Steps to Replicate: Run an SBC AMRWB<>T140 full load with the RTCP enabled. | Ensure the control messages experience a larger queue depth while traversing internal queues. Workaround: No workaround. |
32 | SBX-105735 | 2 | SBC: Deleting VMG and adding it again with same IP and Port from OAM node throws an error "Signaling Ip and Port must be Unique" Impact: Deleting the VMG and adding it again with the same IP and Port from OAM node throws an error "Signaling Ip and Port must be Unique". This was happening because the check for uniqueness for an IP port was not being executed as metavar support for delete operation code was not done. Root Cause:This is a day 1 issue. Since the metavar was introduced, the delete operation for h248sigport was not taken care of (meaning code was not there). This support was given in 9.2 onwards. Steps to Replicate: Use metaVar for adding ip+port h248sigport for VMG -> adds to h248SigPortAddrMeta Delete the added entries --> deleted from h248SigPortAddrMeta Add the same IP+PORT combination again --> this operation should let the user to add the entries again because the earlier entry is deleted from the "h248SigPortAddrMeta". As a result, there is no duplicate, and uniqueness is maintained. This should not throw any error. | When the h248sigport is added (or deleted), it is usually done as a IP+PORT combination.(both being mandatory fields). So while adding h248sigport for VMG, the IP+PORT is added to a metatable named "h248SigPortAddrMeta". This table is used to maintain the uniqueness of the IP+PORT added. So, whenever any h248sigport is added, the IP+PORT combination is stored in "h248SigPortAddrMeta". And when deleted from the CLI, the corresponding entry is deleted from the table as well. This is done to maintain the uniqueness, so that user does not to add the same h248sigport with same IP and port. The code is modified as the input was not taken care of, hence the validation from "h248SigPortAddrMeta" was also not occurring. As a result, the error "Signaling Ip and Port must be Unique" was encountered. Workaround: There is no workaround. This is a straightforward test of adding and deleted the h248sigport for VMG using metaVar |
33 | SBX-107179 | 2 | The dual hold "Music on hold" inter lab failed when both user logins were on secure PCC. Impact: The "Music on hold" failed when both the user login on a secure PCC with "error opening media". Root Cause: The SBC was sending all the crypto choices in the response instead of only common crypto if a request was coming from the egress side. Steps to Replicate: Test Cases for the hold/unhold scenarios: 1. Hold: Reinvite)(hold) From UAS (with 2 cryptos)->SBC, SBC sends INVITE(with the intersected cryptos)-> UAC, UAC replies with 200OK(one Crypto)->SBC, SBC replies 200OK (with 1 Crypto)->UAS OffHold : (Reinvite)(UnHold) From UAS (with 2 cryptos)->SBC, SBC sends INVITE(with the intersected cryptos)-> UAC, UAC replies with 200OK(one Crypto)->SBC, SBC replies 200OK (with 1 Crypto)->UAS | The code is modified to send only one single common crypto in the SDP instead of sending all crypto. Workaround: To avoid this issue, configure the UA to send only single common crypto in UPDATE SDP. There is no workaround from the SBC side. |
34 | SBX-108575 | 2 | The CpxUpgradePersistentMacAddressStatus: will move 0 entries to new table macAddress2Status. Impact: While performing an upgrade of LIF group information, there was a small memory leak. Root Cause: The code was reading the CDB data and storing the value in local memory while perform CDB schema upgrade. This memory was not being freed causing a small memory leak. Steps to Replicate: Run the LSWU calls. | The code is modified to ensure the local memory is correctly free up after usage. Workaround: None |
35 | SBX-108479 | 2 | SBC: Switchover to the standby was not successful when the active node dumped core and went for deadlock. Impact: A switchover does not get triggered in the case of an abnormal termination of the CPX and PRS process. Root Cause: The logic to send a switchover event is present in the PRS process and the PRS cleanup script but in case of abnormal termination, we are unable to get the current node's role and service ID, which is needed for checking whether to send switchover event or not. Steps to Replicate: Kill the CPX process and then after 2 seconds, kill the PRS process. | The code is modified to save the service ID on the node going down if it was running as active so that the PRS cleanup script can look for the file and send switchover event while going down. Workaround: No workaround. |
36 | SBX-106170 | 2 | The AddressSanitizer: detected a heap-use-after-free on address 0x60f000047d38 at pc 0x562fcd2973a5 bp 0x7f3963983f40 sp 0x7f3963983f38 READ of size 20 at 0x60f000047d38 thread T7 Impact: ASAN reported an issue trying access a structure pointer, which is freed already. Root Cause: The SBC is trying to access structure pointer to get socket address, but that structure pointer is already freed in other function. Steps to Replicate: Use ASAN build for testing:
| The code is modified so now a user gets the socket address from pstSrcAddr structure. Workaround: None |
37 | SBX-70800 | 2 | AWS: Observing that metaVariable table is getting modified on loading the backup config file of one instance in other instance. Impact: When loading the backup configuration from one SBC instance to another, the metavar table is getting populated with the list of metavars from both instances. This by itself does not cause any issues so long as the metavars are unique, its just confusing to see the metavars for another instance in the table. Root Cause: The code was not removing the existing metavars prior to loading the configuration of another instance. This meant the metavar table had both sets of information. Steps to Replicate:
| The code is modified to flush the metavars for the existing instance prior to loading the configuration from another instance. Workaround: None. |
38 | SBX-106004 | 2 | There was an EMA display error when the SMM was deleted through the CLI. Impact: There was an EMA display error when the SMM was deleted through the CLI. Root Cause: In the EMA, we are checking the ordering of the rules. If the Order is not continuous, then we are throwing the error. Steps to Replicate:
| Removed that code to correct the issue. Workaround: NA. |
39 | SBX-109418 | 2 | The LeakSanitizer: detected memory leaks Direct leak of 883820 byte(s) in 413 object(s) Impact: The SBC was not freeing memory in one of the failure cases. Root Cause: The SBC was not freeing memory in few cases where incoming INVITE handling fails. Steps to Replicate:
| The code is modified to free up memory allocated, in all cases when the INVITE handling fails. Workaround: NA |
40 | SBX-107975 | 2 | The Serf event processor is unable to restart because the restart check marker file is not getting removed. Impact: The Serf event processor is unable to restart because the restart check marker file is not getting removed. Root Cause: The restart check marker was only being removed if serfeventProcessor starts successfully, so if it fails to start, any attempts to restart it would be prevented because the marker is not removed. Steps to Replicate:
| The code is modified to allow time for the serfEventProcessor to start so that the user can attempt a restart. Workaround: None. |
41 | SBX-108411 | 2 | [ASAN]: sanitizer.CE_2N_Comp_ScmProcess_2.30828:==CE_2N_Comp_ScmProcess_2==30828==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61b00008dc88 at pc 0x5621c53c6946 bp 0x7f9854100bc0 sp 0x7f9854100bb8 Impact: While running a INVITE CANCEL Proxy Call, the UAS observed a Address Sanitizer leak in SCM process and the SBC services stopped. Root Cause: Issue in parsing string when string is blank and very large that lead to a heap buffer overflow. i.e Via: SIP/2.0/UDP 10.54.48.31:7009;sigcomp-id=" LWS " When the token length becomes large (i.e. a LWS length of 100) and the token length point is outside the PDU, we will see this issue. Steps to Replicate: Send INVITE with a VIA header as the last header. | The code is modified to use temptokLen instead of the tokLen. As a result, the tokLen does not reach outside the PDU. Workaround: The VIA header should not be last header, and the empty token string should be small. |
42 | SBX-105261 | SBX-108112 | 2 | Portfix SBX-105261: The Media Stats are not correct when a DLRBT profile is removed from TGs and ICE is enabled. Impact: On an SBC configured for MS Teams LMO centralized mode with ICE, if the DLRBT is not correctly configured, this can lead to media not flowing correctly for a call even after ice learning gets completed. Root Cause: The early ICE learning logic for non DLRBT mode in the SBC was not fully deactivating ICE media resources on a receipt of a 200 OK. As a result, the resources were unable to be re-activated for end to end media flow. Steps to Replicate: On an SBC configured as MS Teams LMO centralized mode with ICE on MS Teams TG, run the following steps to reproduce the issue:
| The code is modified to correctly deactivate early ICE learning media resources on receiving an SDP from MS teams. Workaround: The DLRBT should be enabled. |
43 | SBX-109177 | 2 | The SbcSftp throws an error as "Failed to add ACL". Impact: The sbcsftp application does not remove the ACL created correctly. Root Cause: The permissions to delete the ACL gets lost while lowering permissions to ensure the sbcsftp can only access the current user's files. Steps to Replicate:
| The code is modified so that we can raise the permissions again once SFTP is complete. Workaround: None. |
44 | SBX-108619 | 2 | A runtime error: signed integer overflow: 2002002002 * 10 cannot be represented in type 'int' Impact: A runtime error is seen in the SAM process. When an INVITE is sent out and response code received is very large, we will see the issue: Runtime error: signed integer overflow: cannot be represented in type 'int'. Root Cause: When the SIP Response code is very large, there is a signed integer overflow during the processing of the SIP PDU. Steps to Replicate: An INVITE is sent out to the egress. | The code is modified so if the SIP response is greater than or equal to max response code, the SBC throws an error. Workaround: None |
45 | SBX-106543 | 2 | SBC cored while running UAS Notify Request. Impact: The SBC coredumps while processing the UAS Notify Request with the XML body. Root Cause: In API SipsCheckForAnyBody(), the loop that the string pointer pch is incremented each time was being accessed before validating for the boundary condition that caused the crash. Steps to Replicate: Send a NOTIFY with XML body from UAC towards the SBC. | The code is modified to add a check before accessing the pointer value. Workaround: None. |
46 | SBX-109167 | 2 | The AddressSanitizer: detected SEGV on unknown address 0x000000000028 (pc 0x55810d4c1823 bp 0x7f6227387c30 sp 0x7f62273873c0 T9) Impact: During Preparsing the Messagebody, the SEGV on an unknown address is observed in SipsPreParseMsgBody(). Root Cause: When the Content-Type is NULL during a strcaseCmp, there is no NULL check for a HeaderField value and as a result, this issue is seen during strcasecmp(pstGenericVal->pchHdrFieldValue, "multipart/mixed"). Steps to Replicate:
| The code is modified to address the issue. Workaround: None. |
47 | SBX-108572 | 2 | The runtime error: index 20 out of bounds for type 'sip_nameval_str [20]'. Impact: When the Publish message is received with 20 params in the Contact Header, the SBC throws a runtime error: index 20 out of bounds for type 'sip_nameval_str. Root Cause: The param check for boundary condition was missing while parsing the contact header. While it was checking, the number of params should be less than 20, but the condition to handle number of params is not specified. Steps to Replicate: The steps cannot be reproduced. | The code is modified so if the number of params is 20, the SBC should throw a parse error. Workaround: None. |
48 | SBX-105688 | 2 | The TapId of ingress target was not getting embedded in CCID for IMSLI (both leg interception). Impact: When both leg interception is enabled for Out Of Dialog messages for IMSLI flavor, the X2 messages corresponding to the ingress leg that are sent towards Mediation server have TapId of Egress as a target instead of TapId of Ingress Target embedded in the Correlation-ID (CCID) and in the TAP ID AVP field (202). Root Cause: The SBC always stored only one tapId, the TapId present in 0th index of the LI criteria table that is returned by PSX as part of policy OUTPUT. When both legs are intercepted, 0th index in the above said criteria table will have Egress target information. As a result, whenever both legs are intercepted for OOD messages, the TapId of Egress target is always embedded in CCID for X2 messages corresponding to ingress leg. Steps to Replicate: Procedure:
| The code is modified to store and process the TapId of the second target criteria (Ingress Leg). Workaround: None. |
49 | SBX-94852 | 2 | Security, Audit and other logs are modifiable (including deletion) Impact: The admin can delete and modify evlog files. Root Cause: Users belonging to upload group(like admin) had write access on the evlog dir, which allows them to delete/modify log files. Steps to Replicate: Log into the sftp into evlog dir using admin and try modifying/deleting log files. | The code is modified that prevents the admin from having writing access on the files owned by other users. Workaround: None. |
50 | SBX-103183 | 2 | The SBC incorrectly formatting the rport in a VIA header. Impact: The SBC incorrectly formats the rport value in the VIA header of response message if the rport has a valid port number and is at the end of a VIA header of request message. Root Cause: The code does not check if a rport has some valid port number or not. If a rport is the last parameter in VIA header, it appends "=<source port>". Steps to Replicate:
| The code is modified so that it checks for any port number in rport parameter (rport is at the end of VIA header of request message), it replaces the port number and appends its own rport. Workaround: The following SMM can be used as a work around: set profiles signaling sipAdaptorProfile HeaderModifications rule 1 applyMatchHeader one set profiles signaling sipAdaptorProfile HeaderModifications rule 1 criterion 1 type message message messageTypes response statusCode 200 set profiles signaling sipAdaptorProfile HeaderModifications rule 1 criterion 2 type header header name Via condition exist set profiles signaling sipAdaptorProfile HeaderModifications rule 1 action 1 type header operation store set profiles signaling sipAdaptorProfile HeaderModifications rule 1 action 1 headerInfo headerValue set profiles signaling sipAdaptorProfile HeaderModifications rule 1 action 1 from type header value Via set profiles signaling sipAdaptorProfile HeaderModifications rule 1 action 1 to type variable variableValue var4 set profiles signaling sipAdaptorProfile HeaderModifications rule 1 action 2 type variable operation regsub set profiles signaling sipAdaptorProfile HeaderModifications rule 1 action 2 from type value value "rport=" set profiles signaling sipAdaptorProfile HeaderModifications rule 1 action 2 to type variable variableValue var4 set profiles signaling sipAdaptorProfile HeaderModifications rule 1 action 2 regexp string "rport=[0-9]*=" matchInstance one set profiles signaling sipAdaptorProfile HeaderModifications rule 1 action 3 type header headerInfo headerValue set profiles signaling sipAdaptorProfile HeaderModifications rule 1 action 3 operation modify set profiles signaling sipAdaptorProfile HeaderModifications rule 1 action 3 from type variable variableValue var4 set profiles signaling sipAdaptorProfile HeaderModifications rule 1 action 3 to type header value Via |
51 | SBX-90978 | 2 | CPU resources are allocated without complete utilization of GPU resources Impact: The CPU DSPs are getting utilized for GPU supported codecs without complete utilization of GPU resources. Root Cause: Changes introduced to change the behavior of the NRMA to request the DRM to allocate the first codec in the egress PSP. If the egress peer responds with a different codec, the NRMA checks if the existing allocation supports the new codec. If it does, then the same DSP resource is reused for the call. The side effect of the case above for hybrid transcoding is the following: If the first codec in the PSP is a CPU based codec, then the DSP resource will be taken from a CPU UXPAD. If the response from the egress peer is for a different codec, the same CPU UXPAD resource will be reused since CPU UXPADs support all codecs. Because of this, CPU UXPADs can potentially be used for GPU codecs. Steps to Replicate:
| The code is modified so if the system is detected to be in gpuMode (has support for GPU DSP), then for CPU codecs also the DSP is allocated with support for only requested codec and G711/SS as it is done in case of a GPU codec. In this case, when the egress peer replies with a GPU codec a new GPU DSP needs to be allocated as the previously allocated CPU channel cannot support the new codec Workaround: None. |
52 | SBX-105437 | 2 | CDR issues for non-INVITE messages when blacklisting is involved. Impact: In case of handling of failure responses for non-INVITE messages, before writing the CDR for current failure cause code, the SBC was finding out next route and sending a message on network. This worked fine in normal cases as after sending out a request, the response was processed later, after writing a CDR for current failure response. However in a backlisted entry case, no actual message is sent out, so the blacklisted entry CDR was written before the previous CDR response code. Root Cause: Whenever a blacklisted entry was involved, the CDR entries were messed up for this blacklisted entry and the previous entry. Steps to Replicate: Configure Routes for non-INVITE as follows: R1 The CDR's should be printed in order R1, R2, R3, R4 after a fix. | The code is modified to write the CDR for the current failure response code, and later find next route and send a request on the new route. Workaround: NA |
53 | SBX-107973 | 2 | The SBC adding RR and RS attributes twice in the egress INVITE when multiple m lines present in SDP Impact: The SBC was adding RR and RS attributes twice in the egress INVITE when multiple m lines present in a SDP. Root Cause: The SBC is not setting the default value of M lines present in SDP when number of lines is greater than 1 and as a result, the SIPS value is getting added. Steps to Replicate: Configure these: set profiles media packetServiceProfile DEFAULT rtcpOptions rtcp enable set profiles signaling ipSignalingProfile DEFAULT_SIP commonIpAttributes flags sendRTCPBandwidthInfo enable set addressContext default zone ZONE_EGRESS sipTrunkGroup TG__EGRESS media multipleAudioStreamsSupport enabled An incoming INVITE has multiple Audio line with: | The code is modified so that if value is set to default and it is not getting modified, the SIP does not send the RR and RS value twice. Workaround: Enable sdpAttributesSelectiveRelay to prevent the SBC from sending RR and RS twice. |
54 | SBX-108143 | 2 | Set the FAC as enabled by default. Impact: The FAC was enabled by default in 9.2, but was disabled in release 9.2.1. FAC is reverted back to being enabled by default in future releases of 9.2.x and 10.0. Root Cause: The FAC was temporarily disabled by default until performance issues were fixed. Steps to Replicate: Run the FAC impacts performance on high cps, and perform load test. | The code is modified so the shared memory is used instead of memory mapped files. Workaround: Keep the FAC disabled if using high cps until you upgrade the SBC to a fixed version. |
55 | SBX-105900 | 2 | Resize the log volume on every boot. Impact: The log volume is not being resized on every boot. Root Cause: Currently, we build the filesystem on cinder volume only on the first boot. Steps to Replicate:
Check if the cinder volume is resized to 100GB. | The code is modified to check if file system is already built. If the file system is not built, the volume is resized. Workaround: None. |
56 | SBX-107646 | 2 | A revision not present in the OAM or EMS, upon doing restore error should be thrown. Impact: Not showing the proper failed message when failing to download from the EMS. Root Cause: The confd was not waiting for the EMS download error as the EMS download was done in a different thread context. Steps to Replicate: Case 1:
Case 2:
Case 3:
| The code is modified to run the restoreRevision procedure on the same thread context and help to display proper error in case of a failure. Workaround: None. |
57 | SBX-106693 | 2 | Wrong warning message on a Direct-SBC while doing a restore. Impact: The wrong warning message played during a restoreRevision. Root Cause: Rewording of the text message required when restorerevision was invoked. Steps to Replicate:
| The code is modified to reword the text messages. Workaround: None. |
58 | SBX-105674 | 2 | There were customer coverity issues part2. Impact: While processing SUBSCRIBE messages, the coverity tool has highlighted that the code could dereference a pointer that is potentially NULL. Although no bad behavior has been observed during testing, there is a small chance that it could result in coredumps if the pointer really was NULL. Root Cause: Based on other validation in the code, the coverity highlighted that some legs of code could result in accessing a pointer that might be NULL. Derefencing NULL pointers can cause unexpected behavior and in the worst case coredumps. Steps to Replicate: Run various SUBSCRIBE related test cases. | The code is modified to validate that the pointer is not NULL before using it to avoid any potential issues/coredumps. Workaround: None. |
59 | SBX-105804 | 2 | The CDR field is not populated even though the SBC writes the value to CDR field for '200 Ok of BYE' received/sent. Impact: After SMM manipulation, the SBC writes the value to CDR field as seen in the DBG but the CDR field ‘STOP’ record is empty. Root Cause: The logic to write the ACT file for the incoming 200 OK of Bye was absent. Steps to Replicate:
| The code is modified to fill the stop record for the incoming 200OK of BYE for the SMM CDR fields. Workaround: Attach the SMM to BYE instead of the 200OK of BYE. |
60 | SBX-105457 | 2 | An error is thrown on EMA while configuring the SMM Profile having messageBody criteria with regex. Impact: An error is thrown on the EMA while configuring the SMM Profile having messageBody criteria with a regex. Root Cause: The EMA assumes that the Num Match was a mandatory field but it is an optional field (user may enter that value or he may not). Steps to Replicate:
| The code is modified to make the Num Match field optional. Workaround: None. |
61 | SBX-109591 | 2 | Reject Invite with 100Rel when TG flag rel100Support is disabled and E2E Prack is disable on that leg after PSX DIP Impact: The SBC does not tear down the call if the INVITE contains a Require: 100rel and the rel100Support flag is disabled on the ingress sipTrunkGroup, as per RFC3262. Root Cause: When the rel100Support flag is disabled and INVITE contains Require: 100rel, the SBC was not rejecting the Invite with 420 Bad extension. This scenario was not handled. Steps to Replicate: Set this flag: When the INVITE is received with Require: 100rel and endToEndPrack is disabled, the SBC should reject the call with a 420 Bad extension and the SBC should send header Unsupported :100rel toward the ingress. | The code is modified so that when rel100Support flag is disabled and endToEndPrack is disabled. If the INVITE contains a Require: 100rel, the SBC will reject the INVITE with 420 Bad extension and the SBC will send header Unsupported :100rel toward the ingress. Workaround: None. |
62 | SBX-108951 | 2 | The AddressSanitizer: detected a heap-use-after-free on the address 0x6200000373c8 at pc 0x560aae46bf67 bp 0x7fc9bc717850 sp 0x7fc9bc717848. Impact: The ASAN detected "AddressSanitizer: heap-use-after-free" when accessing a To tag from the message handle. Root Cause: Accessed a ToTag from the message handle after it is freed. Steps to Replicate: Run a call flow scenario involving a Prack Message with SDP. | The code is modified to access the To tag before freeing it. Workaround: Not Applicable. |
63 | SBX-107613 | 2 | The AMRWB encoder produces a corrupted output when channel is reused by lower mode. Impact: Audio is degraded in the AMRWB stream when the AMRWB (GPU) call load is running, particularly when each call uses a different bitrate. Root Cause: The problem occurs when the same codec context is reused and the previous used was for a higher bitrate. The root cause was identified due to reinitialization logic for an internal buffer. Steps to Replicate:
RESULT: | The code is modified to appropriately reinitialize the internal buffer. Workaround: The problem does not occur when all channels use the same bitrate. |
64 | SBX-104619 | SBX-109912 | 2 | PortFix SBX-104619: The FM process cored. Impact: The FM Process crashed and wrote a coredump. Root Cause: The FM Process tried to read the /proc/meminfo file, which should always exist, but it got a file not found error. Steps to Replicate: It is not known how to reproduce this issue, and the defensive code added to prevent a NULL read/write. | The code is modified to return the last good value read instead of a NULL to prevent the crash. Workaround: None. |
65 | SBX-106815 | SBX-107964 | 2 | PortFix SBX-106815: The PES Process was leaking memory. Impact: In certain circumstance with high enough call rate, the SBC may experience PES memory leak. Root Cause: The newly ported Postgres code mishandled Postgres DATABASE cursor and counter. Steps to Replicate: The memory leak was not reproduced in house. This problem had been found and reproduced in customer lab, when they were testing call load. A private fix has been tested in customer lab as well. | The code is modified in cursor and counter area. Workaround: There was a lower call rate should lower the risk. |
66 | SBX-105598 | SBX-107806 | 2 | PortFix SBX-105598: The Native Forking and DLRBT were not working. Impact: With Native Forking enabled, if the call is answered by Teams endpoint, the call gets released by the SBC. Root Cause: Two Reasons for Forking and DLRBT calls to fail for TEAMS endpoint.
Steps to Replicate:
| 1. The code is modified to not return a failure for DUMMY resource modification. Workaround: Disable the DLRBT and ICE learning for forked calls. |
67 | SBX-108469 | SBX-109088 | 2 | PortFix SBX-108469: There was a registration issue with switchover case Impact: The Security Mechanism of Registration is set to TLS in RCB with two different scenarios. The scenarios are of basic registration that does not have any security profile. Root Cause: The cause is when Reconstruction of RCB occurs during a switchover by default security is set to TLS without verifying Digest structure. Also, whenever Digest structure is deleted for any reason the code is not setting security back to NONE. Steps to Replicate: Test requires a HA setup.
| The code is modified to set security back to NONE when deleting a Digest structure. Workaround: Try performing switchover twice. |
68 | SBX-109083 | SBX-109329 | 2 | PortFix SBX-109083: The SCM Process coredumps during the SipSgAORHashRemove. Impact: The SCM Process cores due to corruption of entry in Registration hash table post switchover. This corruption is rare and occurs infrequently. Root Cause: Below is likely cause of the core as per core dump and SYS error logs. The corrupted AOR entry in hash table was allocated during reconstruction of Active RCB from standby context after switchover. The SYS Err logs indicates presence of duplicate AOR entry. This could potential lead to corruption. Steps to Replicate:
| The code is modified to ensure only one AOR entry exists in hash table after switchover on an Active SBC's cache. If the AOR entry is not found during remove operation, we manually remove the entry to avoid the corruption later. Workaround: None. |
69 | SBX-107944 | SBX-108536 | 2 | PortFix SBX-107944: SBC - High Memory. Impact: There is a PRS leak of structures related to IPSEC. Root Cause: The upgrade of the debian kernel (from 3.16 to 4.19) has triggered a leak of XRM_IPSEC_SA_STRs. Steps to Replicate: The unit testing was not necessary because this fix has been tested in other branches. | The code is modified to free the structure that was leaking. Workaround: This leak will only affect customers who are using IPSEC. There is no workaround. |
70 | SBX-103616 | SBX-108504 | 2 | PortFix SBX-103616: The search function in the EMA does not work. Impact: When a custom perspective is created, the search function does not work. Root Cause: There is a node called URI Parameter Manipulation that has a child node with the same name. When a custom perspective with this node is created and a search is performed, the search enters into an infinite loop and is never completed. Steps to Replicate:
| The code is modified to prevent making the node itself as both parent and child. Workaround: Delete Custom Perspective and restart the SBC. |
71 | SBX-109993 | SBX-110011 | 2 | PortFix SBX-109993: The PRS Process is coring with pkt SWO with loopback call. Impact: The PRS cored when testing a pkt port switchover. Root Cause: In a previous fix, the statement to log the debug message was missing a string parameter. Steps to Replicate:
| The code is modified to address the issue. Workaround: No workaround. |
72 | SBX-105901 | SBX-106713 | 2 | PortFix SBX-105901: Detected a heap-buffer-overflow in ASAN build for SIPS module. Impact: Observing heap buffer overflow in SCM process for info level log while decrypting the ROUTE header. Reading memory beyond the end of the allocated buffer can result in memory access faults and coredumps. Root Cause: There was a heap overflow is because debug statement is trying to print from a string variable that is not null terminated. Steps to Replicate: Execute a test case where INVITE message contains encrypted route-header and verify that there are no failures. | The code is modified to create a local variable of type character array that gets dynamically created and is always null terminated. This variable will be used in the info log. Workaround: Not Applicable. |
73 | SBX-110290 | SBX-110307 | 2 | PortFix SBX-110290: Observed a CpxApp coredump on an Active SBC while running a weekend load. Impact: The CPX coredumped due to a health check failure. Root Cause: Unhide the debug command that was being run as part of a test did not return for more than 10 secs resulting in health check fail. Steps to Replicate: Run similar tests that frequently call "unhide debug", verify that the CPX does not coredump similarly. | The code is modified to override the healthcheck for unhide debug command. Workaround: None. |
74 | PSX-36804 | SBX-108538 | 2 | PortFix PSX-36804: The systems appear to be adding rtcp-mux parameter to SDP in invites. Impact: If the "Media Packet COS" value is 4-7 in the Packet Service Profile, the flag "RTCP-MUX" is always set even though this flag is not selected from the PSP profile. Furthermore, if "Media Packet COS" value is 1, 5 and 7, the flag "Force Route PSP Order" of PSP is always set even though this flag is not selected. Root Cause: In the PES module, it assigned the "left shift of 7 bits" of "Media Packet COS" value to both Options2 and Options3 fields when sending the Diameter message to SBC. The COS value is only associated with Options2 field. This assignment of Options3 corrupted the bits 8-10 of actual options3 value defined in the Diameter interface: Steps to Replicate: Assigned different values of COS field, combined with enabling/disabling flag "RTCP-MUX" and "Force Route PSP Order" for the Packet Service Profile and Preferred Packet Service Profile. Verify the value of Options2 and Options3 fields are set properly when sending the message to the SBC. | The code is modified to address the issue. Workaround: None. |
75 | SBX-106042 | SBX-108136 | 2 | PortFix SBX-106042: The RCB(s) can be hijacked and effect on registered users/EPs. Impact:
Root Cause:
Steps to Replicate: Make a configuration and use a configuration file for reference:
| The code is modified for the following:
Workaround: None. |
76 | SBX-109105 | SBX-109766 | 2 | PortFix SBX-109105: The OOD PUBLISH vs. OOD INFO different NRM triggers/congestion profiling. Impact: The OOD PUBLISH vs. OOD INFO different NRM triggers/congestion profiling. Root Cause: Some of the OOD message types were not being checked for triggering NRM congestion. Steps to Replicate: Please run OOD PUBLISH messages which should trigger NRM congestion and calculate CPS resource. | The code is modified to trigger the NRM congestion to include all OOD messages. Workaround: There is no workaround. |
77 | SBX-109286 | SBX-109633 | 2 | PortFix SBX-109286: The IP Interface Group will cause issues when there are the same names with different upper or lower cases. Impact: The IP Interface Group will cause issues when there are the same names with different upper or lower cases. Root Cause: The code reads the attribute value (ignoring case) and selecting the options. As a result, both values are marked selected and last selected option will be shown as selected in GUI. Steps to Replicate: Create an AC, Zone and Trunkgroup | The code is modified the exact match the value to select based on case sensitive. Workaround: No workaround. |
78 | SBX-95106 | SBX-109027 | 2 | PortFix SBX-95106: The SIP over SCTP calls are failing for approximately 25-30 seconds after enabling a new SIP signaling port. Impact: Disabling/Enabling the SIP-UDP signaling port triggers SIP-SCTP packets being sent out of management interfaces (mgt0/mgt1). Root Cause: Missing ipInterfaceGroup information in SCTP socket created by the kernel, not the SBC application. Steps to Replicate: Without the fix in the SBC providing SIP-SCTP connections, disable/enable/add a SIP-UDP signaling port and observe the SIP-SCTP packets leaving from management interfaces. With the fix, the SIP-SCTP connections continue to use packet interfaces for SIP-SCTP packets. | The code is modified to copy the ipInterfaceGroup information from application-created socket to internally/kernel created socket. Workaround: None. |
79 | SBX-105361 | 3 | The SSH access was not re-enabled on SBC 5400 for linuxadmin after upgrade. Impact: SSH is enabled for root user in SBC 5400 after a LSWU or PM upgrade. Root Cause: The getVirtualType function in sonusUtils.sh is set virtual type wrongly on SBC 5400. Steps to Replicate: Enable SSH and run a LSWU, the SSH should not enable for the root user. | The code is modified to address the issue. Workaround: None. |
80 | SBX-94984 | 3 | Passphrases are included in the configuration export. Impact: The following entries are being displayed in the configuration backup: Root Cause: The exportConfig does not filter any specific paths while exporting the configuration backup. Steps to Replicate: Configuration: | The code is modified to address the issue. Workaround: No workaround. |
81 | SBX-103963 | 3 | Both the SBCs restarted at the same time and both mounted the DRBD0. Impact: Both the SBCs restarted at the same time and both mounted DRBD0. Root Cause: The PRS Process was not updating the syncStatus flag value due to which the the standby was also rebooting thinking the sync is not complete yet. Steps to Replicate: When both the the nodes are up and running, restart standby. And while the standby is coming up, run switchover from active CLI. The switchover should be successful. | The code is modified to use the SMA API to check syncStatus instead of PRS and CHM local syncStatus flags Workaround: None. |
82 | SBX-107254 | 2 | The confd connections are not cleaned up correctly. Impact: If the standby experiences a power hit, the confd connections will not be properly torn down. Root Cause: The active side needs to run keepalive and cleanup stale connections to address standby abnormal shutdown. Steps to Replicate: Test by shutting down/pull plug on standby on a HA system. | The code is modified to run keepalive the connection and cleanup if standby is shutdown abruptly. Workaround: None. |
83 | SBX-109006 | 2 | There was a DSP DHC failure and failed to coredump. Impact: The FPGA based a DSP Health Check (DHC) fails and no DSP core-dump is collected, Root Cause: Root cause for the DHC failure is not known. However, subsequent coredumps failed due to DSP BOOTP packets not responding, which causes a hard failure. It is speculated that both issues are related. Steps to Replicate: The code has been instrumented. | The code is modified so on a DHC failure and subsequent coredump failure due to not receiving DSP BOOTP packets, node is rebooted instead of the application being restarted. Workaround: None |
84 | SBX-108410 | 2 | The AddressSanitizer: detected a heap-use-after-free on address 0x6190001c77dd at pc 0x558bcc9ff877 bp 0x7fea305f4e00 sp 0x7fea305f45b0. Impact: The ASAN reported "AddressSanitizer: heap-use-after-free" error when a Subscribe request was having a NULL character in quoted string. Root Cause: An invalid access of the freed memory occurred. Accessing memory after it is freed can cause unexpected behavior that may result in coredumps. Steps to Replicate: Use the codenomicon subscribe-notify suite. | The code is modified to send a parser error when ever the SBC received a NULL character in the quoted string. Workaround: None. |
85 | SBX-106822 | 2 | There was a crash observed in a four GPU Codec Scenario. Impact: The G729AB GPU codec may crash when there are lost packets in the incoming G729AB stream, which in turn leads to SWe_UXPAD crash and the SBC application restart. Root Cause: An uninitialized stack variable in GPU G729AB decoder code was identified as the root cause. Steps to Replicate:
RESULT: The SWe_UXPAD may crash and the SBC application will restart. | The code is modified to initialize the stack variable appropriately. Workaround: No workaround. |
86 | SBX-108577 | 2 | The AddressSanitizer: detected an SEGV on an unknown address 0x000000000000. Impact: The SBC was performing a write operation on one of the un-allocated memory spaces while restoring NTP server configuration, causing an SEGV on unknown address. Root Cause: This issue was caused because a flag variable was not initialized. As a result, the if condition was evaluated true instead of false and write operation was performed. Steps to Replicate: Configuring NTP server and restoring the configuration by switchover or restart this error should not come up. | The code is modified to address the issue. Workaround: None. |
87 | SBX-97661 | 2 | The IAC code needs to modified to bring up the 2vCPU instance. Impact: To support small SWe setups in the AWS, changes are required to RAF. Root Cause: In the AWS, 2vCPU instance types only allow up to 3 interfaces. Therefore, the SBC will only have (Mgt0, HA and PKT0) interfaces. Steps to Replicate: Attempt to create a AWS SBC standalone setup using RAF, while making the following changes to the terraform.tfvars:
The terraform will fail. | The code is modified to support creating an AWS SBC with no PKT1. Workaround: Create a setup using small SWe CFN templates. |
88 | SBX-105644 | 2 | The sonusSbxCertificateExpireSoonWarningNotification trap does not show for all certificates in current and for the history of alarms. Impact: The sonusSbxCertificateExpireSoonWarningNotification trap does not show individual alarms for separate certificates on the alarm status screen. Root Cause: The SBC alarm for sonusSbxCertificateExpireSoonWarningNotification was just using trap ID as key identifier. Steps to Replicate: Add multiple certificates to a 1:1 HA system that will expire and configure certificate expiry date. Confirm:
| The code is modified so the SBC alarms now use certificate name as well as trap ID as key identifiers to show alarm. Workaround: None. |
89 | SBX-105160 | 2 | The CHM Process coredumps on the standby OAM after a reboot. Impact: The CHM process coredumps on the standby OAM after a reboot due to the gluster coredump. Root Cause: The SBC application continues to come up even when the zapAsp is called from a sbxCleanup. The CHM tries to access ceNum, which is not properly set due to failure in sbxCleanup.sh and causes coredump. Steps to Replicate: Fail the sbxCleanup, and the SBC should not be coming up. | The code is modified to avoid the SBC bringup if any errors are reported in the sbxCleanup. Workaround: No workaround. |
90 | SBX-106759 | 2 | In the N:1 mode, the SBC switches over for the different node than the one, which the switchover request is honored. Impact: In N:1 during few scenarios, the SBC performs a switchover to node that was not request honored. When the issue occurred, the switchover will be processed to the other node instead of processing to request honored node. Root Cause: During a switchover process, the SBC was not checking the node that was requested honored. It was switching over to node that comes first/was available while processing. Steps to Replicate:
| The code is modified to check the service ID of the request honored node before a switchover. Workaround: None |
91 | SBX-107639 | 2 | The CA CMR with the offset 2 and priority LOW is not being processed or rejected. Impact: When a Channel Aware Mode CMR for priority LOW and offset 2 is the first CA. The CMR received in a call, the CMR was not processed. Root Cause: The present default value of curFecIndOffset in the code was set to 0, which corresponds to offset 2 and priority LOW. Steps to Replicate: Test 1:
Expected Result:
Actual Result:
Test 2:
Expected Result:
| The code is modified so that it does not match any of the valid curFecIndOffset which is 0-7. Workaround: None. |
92 | SBX-109221 | 2 | The dpf_core.c "runtime error: shift exponent 432 is too large for 64-bit type 'long long unsigned int'" in np.log. Impact: In the ASAN build, a runtime warning is observed in SWe_NP while running AMR-EVS audio call and insert T140 to both the streams through a RE-INVITE. Root Cause: Incorrect use of bitmask operation to extract dscp field from packet. Steps to Replicate: In an ASAN build, make a AMR-EVS audio call and insert T140 to both the streams through a RE-INVITE. AMR+T140-> EVS+T140. Observe ASAN warning in the np.log. | The code is modified to address the issue. Workaround: None. |
93 | SBX-109443 | 2 | The AddressSanitizer: detected heap-use-after-free on address 0x61900412bbce. Impact: The ASAN reported "AddressSanitizer: heap-use-after-free" error for a subscribe message received with Proxy-Authorization header having auts parameter. Root Cause: An invalid access of the freed memory occurred in this case. Accessing memory after it is freed can cause unexpected behavior that may result in coredumps. Steps to Replicate: Send SUBSCRIBE message received with Proxy-Authorization header having auts parameter. | The code is modified to address the issue. Workaround: None. |
94 | SBX-107844 | 2 | Observed the DRM congestion for G711 to G711 transcode calls load with only 70% of the dsp capacity. Impact: There was DRM congestion observed for G711 to G711 transcode calls load with only 70% of the dsp capacity. Root Cause: More MIPS being consumed when the RFC2833 detection is enabled on either one/both the legs. Steps to Replicate: Run a 90% G711A<=>G711U load on an MRFP set-up with RFC2833 enabled on both the legs. The load should run without any DRM congestion. | The code is modified to make the cache aligned and G711A and G711U Encoder is made into a look-up table. Workaround: None. |
95 | SBX-109187 | 2 | There was a runtime error: the NULL pointer passed as argument 2, which is declared to never be NULL. Impact: The NULL pointer access during the codenomicon test with an ASAN SBC build. Root Cause: Codec Attribute has been accessed in the SDP without proper NULL check. Steps to Replicate:
| The code is modified to add the defensive NULL check. Workaround: Not Applicable. |
96 | SBX-108620 | 2 | A runtime error: load of value 24752, which is not a valid value for type 'SIP_MSG_TYPE'. Impact: While processing an in dialog NOTIFY message, the check for message type was not done using proper data type. Root Cause: Message type check for NOTIFY message was not correct. Steps to Replicate:
| The code is modified to address the issue. Workaround: None. |
97 | SBX-109424 | 2 | The SBC sends a 420 Bad Extension response when the INVITE with both supported and the required 100rel is sent. Impact: The SBC sends a 420 Bad extension when the require:100Rel is received in the initial INVITE and e2e Prack flag is enabled. Root Cause: The wrong code has been added to reject an INVITE with Require:100Rel when rel100Support flag is disabled and e2e prack flag is enabled. Steps to Replicate:
| The code is modified for the rejection in require:100rel Scenarios. Workaround: The SMM can be used to remove the Require:100Rel Header. |
98 | SBX-106854 | 2 | The ASAN runtime flatbuffer serialization unit test fails with asan=1. Impact: The ASAN build is failing due to automated test failures related to serialization. Root Cause: Automated unit test is failing because of uninitialized variables. Steps to Replicate: Create an ASAN build and it should be successful. | The code is modified to initialize the variables that were causing the Unit tests to fail. Workaround: None. |
99 | SBX-103306 | 2 | Allocated bandwidth for the opus call is 1032kb and 1028kb for a single call. Impact: If "transcoderFreeTransparency(TFT)" is enabled at the Route PSP, then extra bandwidth is allocated for an opus call in case the maxaveragebitrate attribute is not received in the SDP from the endpoints. Root Cause: If the maxaveragebitrate is not received in the SDP, then the SBC was using the max value of 510kbps as the default value (which was not as per RFC). Later, this bitrate value gets intersected with Route PSP configured value. However, for TFT calls, this intersection with route PSP does not happen. As a result, the SBC continues to maintain this value as 510kpbs which results in extra bandwidth allocation. Steps to Replicate: Configuration:
| The code is modified so if "maxaveragebitrate" is not received in SDP, then it derives the default value according to RFC using "maxPlayBackRate" and mode(mono/stereo). Workaround: None. |
100 | SBX-108574 | 2 | The CE_Node2.log:snprintf buffer too small. Needs a 327 with a 128 File: /localstore/ws/jenkinsbuild/sbxmainasan/marlin/SIPSG/sipsgLibUtils.c Line: 2524 Impact: The length of the destination buffer was smaller than the source buffer, while using the the snprintf function, and as a result the buffer was too small to be seen. Root Cause: The destination buffer size was smaller than the source buffer while calling the snprintf. Steps to Replicate:
| The code is modified to increase the character array size to upper limit of source buffer size. Workaround: None. |
101 | SBX-109412 | 2 | The buffer was too small. Needs a 256 with a 256 File: /sonus/p4/ws/jenkinsbuild/sbxAsan100/marlin/SIPS/sipsParse.c. Impact: During the snprintf function call, the destination buffer was not big enough to copy the source string. Root Cause: The size of the destination buffer was smaller than the source buffer. The destination buffer length check was not present. Steps to Replicate: When the callId length was more then the defined max callId length, this error was seen. Run a call with callId length greater than 256 bytes. This error should not appear. | The code is modified for the string smaller callId buffer. Workaround: None. |
102 | SBX-110201 | 2 | A late offer call resulting in the SBC not sending DTMF for AMR-WB in initial offer towards ingress. Impact: The SBC is not sending DTMF for AMR-WB in initial offer towards ingress in a late media call. Root Cause: If working the PSP already contains 8k dtmf PT intially, then the SBC skipped over this PT value without accumulating, and as a result 16k dmtf also takes the same value as 8k dtmf PT. Steps to Replicate: Configuration: Transcode conditional To re-create the issue:
Test Result without Fix: The SBC drops the telephone-event/16000 payload type for Late media. | The code is modified to ensure both 8k and 16k DTMF go with correct PT values. Workaround: None. |
103 | SBX-110178 | 2 | The PRS Process gave a heap use after free on address on latest 10.0 build. Impact: The PRS Process gave a "heap use after free on address" error while running HA suite on ASAN build. Root Cause: The interface number was being returned after typecasting the main structure to packet LIF structure, and not management LIF structure. Steps to Replicate: Run the SBX_504_HA suite on ASAN build. | The code is modified to correct the typecasting. Workaround: None. |
104 | SBX-109220 | 2 | The monitor.c "runtime error: signed integer overflow: 0 - -9223372036854775808 cannot be represented in type 'long int'" error in np.log. Impact: Internal ASAN builds report a runtime signed integer overflow error in SWe for standard deviation metric for jitter meant for consumption by Ribbon Protect. Root Cause: Existing algorithm of standard deviation metric did not handle integer overflow issues. Steps to Replicate: Stream the custom RTP packet where expected standard deviation and verify through the Ribbon Protect metric that computed standard deviation values are in range. | The code is modified to handle the overflow. Workaround: No workaround. |
105 | SBX-108356 | 2 | Various runtime errors found in the np.log. Impact: Internal ASAN builds report runtime errors on the SWe platform related to left shift of signed integers. Root Cause: Appropriate integer casts were missing in code, which caused ASAN runtime warnings related to bit shift. Steps to Replicate: Bring up ASAN build on SWe platform and observe if np.log contains ASAN runtime warnings related to bit shifts. | The code is modified to fix the runtime warnings in ASAN builds. Workaround: No workaround. |
106 | SBX-103474 | 2 | SBC:~50ms delay introduced for the LDG port switchover. Impact: A media glitch of more than 200ms is observed in port switchover. Root Cause: The Linux netdevice callback thread had a higher sleep duration, leading to increased latency for processing of netdevice operations that occur during port switchover. Steps to Replicate:
| Linux netdevice callback thread sleep duration was reduced. Workaround: There is no workaround for this issue. |
107 | SBX-109407 | 2 | MicroFlows are failing in the REGISTER Performance of 2400 RPS (256000 REGISTRATIONS) with Error code 0xf9. Impact: Unable to support 256k concurrent subscriber registrations in Default memory profile for the SBC SWe. Root Cause: Existing logic for determining the flow hash causes increased number of hash collisions leading to increased depth of hash buckets, leading to buffer starvation. Steps to Replicate:
| The code is modified to minimize hash collisions. Workaround: There is no workaround for this. |
108 | SBX-102598 | 2 | There were MFG Intermittent test failures. Impact: Xaui link is not always coming back up after enabling/disabling the internal loopback mode. Root Cause: Xaui link is not always coming back up after enabling/disabling the internal loopback mode. Steps to Replicate: Run the ESS test mode for days. | The code is modified to the enable/disable loopback code. Workaround: None. |
109 | SBX-108005 | 2 | The CDR pattern was missing in "42.71", "42.72" fields for START and "52.71" ,"52.72" fields for STOP. Impact: By the introduction of new STI service, the type will corresponds to generic profile execution. The CDR values need to be update to NULL, if any of the STI services are not executing. Root Cause: The root cause occurred due to the additionof the new STI service type at PSX. Steps to Replicate: Run a normal call and check for CDR's and it will be populated with NULL values. | The code is modified in case the STI service state is disabled. Workaround: None. |
110 | SBX-108190 | 2 | The callTracing does not work after reverting a switchover. Impact: The callTrace can not be enabled on calls after a switchover under the following circumstances: When maximum calltrace count is reached before the switchover, all these calls with calltrace enabled are terminated after the switchover. Root Cause: The internal calltrace state was not properly synchronized to the standby node that caused no new calls with calltrace ON request can be enabled. Steps to Replicate:
These new calls should have calltrace enabled. | The code is modified so the calltrace works after a switchover. Workaround: Reboot both the SBC nodes. |
111 | SBX-106897 | 2 | The SBC does not send a notify for successful trace activation. Impact: The SBC does not send calltrace notify to C3 in a call setup with calltrace ON request for the ADD commands of both first termination and second termination of the call, but the ADD command failed for the second termination. Root Cause: The SBC code logic was to send calltrace NOTIFY after the ADD commands of both termination have been processed, but this results in calltrace NOTIFY not being sent for the first termination failure and the ADD second termination. Steps to Replicate:
Expect Result:
| The code is modified to send calltrace NOTIFY for successfully ADDed termination. Workaround: None. |
112 | SBX-105856 | 2 | The URL version is incorrect after restoring an older version. Impact: There was the wrong version in URL after a restoring an older version. Root Cause: The URL is picked from CDB from path "/system/objectStoreParameters/url", which is independent of software version of revision. Steps to Replicate:
| The code is modified to update the URL with the software version for the revision being restored. Workaround: None. |
113 | SBX-106869 | 2 | The SBC Node branch information is inconsistent after a Cleanstart/Restore Revision is performed in the OAM's. Impact: The SBC Node branch information is inconsistent after a Cleanstart/Restore revision is performed for the OAMs. Root Cause: Managed VMs registration failed with the active and standby OAMs as OAMs were not up. The VMs did not try to re-register again. Steps to Replicate: After the issue is fixed, create a setup OAM + S/M/T SBC.
| The code is modified to keep retrying to register with active and standby OAMs. Workaround: None. |
114 | SBX-108198 | 2 | There are coverity issues in the nrsPktLifCsv.c Impact: There was a coverity issue during the validation process. Root Cause: A previous fix was added for a coverity error. Steps to Replicate: The steps cannot be replicated. | The code is modified to address the issue. Workaround: None. |
115 | SBX-107796 | 2 | The MS TEAMS call is failing when the DLRBT profile removed from TGs and ICE is enabled. Impact: The MS TEAMS call is failing when DLRBT profile removed from TGs and ICE is enabled Root Cause: Two Reasons for Forking+DLRBT calls to fail for a TEAMS endpoint.
Steps to Replicate:
Test Step:
|
Workaround: Disable the DLRBT and ICE learning for forked calls. |
116 | SBX-104817 | 2 | The SBC does not answer SDP correctly when remote SDP contains both session and media port state attributes Impact: The SBC sets the incorrect media port state in SDP in reply of a MODIFY command, when the media port state is present in both session level and media level. Root Cause: The SBC parsed the media port state incorrectly when it is present in both session level and media level, and put them both at media level in the reply SDP. Steps to Replicate: Create a 3pcc call, then send a re-invite that triggers C3 sending a MODIFY with media port state present in both session level and media level. The SBC should keep them the same session level and media level in the SDP in the reply. | The code is modified so when parsing media port state attribute when it is in both session level and media level. Workaround: None. |
117 | SBX-108956 | 2 | The default bitrate for the G722 codec should be 64kpbs in MRFP but it is 48 kbps. Impact: The SBC is using 48kbps bit rate for G722 codec instead of 64kpbs when setting up G722 calls. Root Cause: The 48kbps bitrate is wrongly chosen for G722 codec, resulted in the media packets being generated with 48kbps bitrate. Steps to Replicate: Make one g722 to g711 transcode call and observing the RTP stream for g722 codec. | The code is modified to change the bitrate to 64kpbs when setup G722 calls. Workaround: None. |
118 | SBX-110128 | 2 | The SBC auto-registration in the EMS is not working with the EmsFqdn. Impact: The SBC auto-registration in the EMS is not working when using the EMS FQDN. Root Cause: The service discovery is unable to resolve EMS FQDN using system DNS because there is no ACL rule to allow DNS query to go through. Steps to Replicate:
| The code is modified to allow the DNS query to go to the configured nameserver. Workaround: None. |
119 | SBX-109873 | 2 | The SBC includes the "text port = 0" in its response for the re-INVITE to insert a text at the mid call. Impact: The SBC rejects the t140 stream in handling a MODIFY command that changes the audio codec from PCMU to AMR-WB and a t140 stream, with "adaptive codec" enabled. Root Cause: The SBC delays the process of MODIFY command when "adaptive codec change" is enabled, as a result the MODIFY reply is sent back to C3 without t140 stream media resource allocation (IP and RTP port, etc). Steps to Replicate: With the adaptive codec change enabled on a VMG, create a 3pcc call from EVS + t140 — PCMU + t140. Then modify the T2 side to AMR-WB + t140 and the SBC should reply with a valid port number for t140 stream. | The code is modified so that the normal handling of the MODIFY command with audio codec change with t140 stream is carried out and t140 media resource is allocated and valid port is replied back to C3. Workaround: None. |
120 | SBX-109298 | 2 | The DSP fails to modify ptime. Impact: When the SBC receives a re-INVITE with change in the ptime for EVS, the DSP Modify command fails. Root Cause: The handling of the DSP Modify command for a ptime change EVS was not present. Steps to Replicate: Run a EVS to G711 call, send a re-INVITE on the EVS leg with change in ptime. The change in ptime should be put into effect through a DSP Modify. | The code is modified for allowable ptime changes that include 20, 40, 60, 80 and 100ms. Workaround: None. |
121 | SBX-108008 | 2 | Observed MAJOR logs with MegacoSendAmmsResp failure after a switchover during a EVS + T140 -> Mulaw Load Impact: There was a MegacoSendAmmsResp: MegacoSendAmmsResp: Failure while encoding a response. Error code = 197 Major logs was observed after a switchover for the SBC during a load run of a call setup with an audio and text stream. Root Cause: The text stream is not properly synchronized to the standby node and triggers the H.248 message encoding error in reply to a H.248 MODIFY command. Steps to Replicate: Perform a failover during call load run with EVS +ToIP on the ingress side and a G711U+Baudot on egress side. | The code is modified to address the issue. Workaround: None. |
122 | SBX-109030 | 2 | After an upgrade from 9.2.1R00 To 10.0.0, the extra SNMP trapTargets are created. Impact: When upgrading an SBC running an SBC release of 9.1 or greater, extra trap targets are created in the OAM SNMP trapTarget table. Root Cause: In the 9.1x and above releases, when a trap is created in the oam snmp trapTarget table, the corresponding trap that is added in the OAM snmpAgent snmpTargetMib snmpTargetAddrTable has a -0 appended to the end of its name (Example: emaTarget-0). During the upgrade, the upgrade code was looking for an oam snmp trapTarget with a name that has a -0 at the end (Example: emaTarget-0) and since it did not exist, created the extra entry. Steps to Replicate:
| The code is modified so the -0 suffix is removed before the corresponding trap in the oam snmp trapTarget is searched. Workaround: Delete the extra entries in the OAM SNMP trapTarget table. |
123 | SBX-110179 | 2 | The LeakSanitizer detected memory leaks. Impact: A memory leak occurs when a logical management interface is added or modified. Root Cause: A confd cursor element was not closed when exiting the routine that validates the logical management interface being added or changed and this resulted in a memory leak. Steps to Replicate: Make changes to the logical management interfaces and check for memory increasing in the CPX process. | The code is modified to ensure the associated memory is freed to avoid the leak. Workaround: None. |
124 | SBX-109209 | 2 | Observed the MAJOR logs for SIPFE "/localstore/ws/jenkinsbuild/sbxMain/marlin/SIPFE/sipFeSigPortCsv.c, SipFeGetSipSigPortStatisticsGetNextReqMsg, 1111] Another Query in process" on T140 load. Impact: MAJOR logs. Root Cause: The addressContext zone sipSigPortStatistics table is not supported on the SBC, so the code used to return the information was sometimes not returning, causing the MAJOR logs. Steps to Replicate:
| The code is modified so the SipFeGetSipSigPortStatistics routines return immediately. Workaround: Do not query that table. |
125 | SBX-103570 | 2 | Observed major logs flooding for "MAJOR .SIPSG: sipsgMsgProc.c (-19034) 49487. SipSgRemoveDblTrackingEntry, Hash entry not found" Impact: Under a Register load, the major logs related to DBL were flooding the SBC. Root Cause: Due to a missing boundary check, the SBC stopped accepting any new entries when too many DBL tracking entries exist (more than 4K). Steps to Replicate:
| The code is modified to prevent sending unnecessary messages. Workaround: Not applicable. |
126 | SBX-108435 | 2 | The CPX App Process coredumps on the standby OAM. Impact: The CPS process coredumps occasionally when the SBC is stopped. Root Cause: The Replication Engine thread is not stopped when the CPX process receives a deactivate request. Steps to Replicate: It is rarely reproducible. | The code is modified so the Replication Engine is now stopped when the CPX deactivates. Workaround: None. |
127 | SBX-109439 | 2 | There was a activeRevision failure when the state for even type audit is set to on/off. Impact: The configuration playback on the managed VMs fails on the command: set oam eventLog filterAdmin vsbc1 audit audit level major state off Root Cause: Playback engine does not use the user context. Steps to Replicate:
| The code is modified to exclude the Playback engine commit of log level from the user validation. Workaround: Reboot on managed VMs to get the configuration at startup. |
128 | SBX-109157 | 2 | Error while logging in to admin mode: "Your last successful login was from p¢/H." Impact: The buffer that was holding the v6 address was not big enough to store a large IPv6 address. When a large expanded format IPv6 address is stored in the buffer it overflowed and as a result, CLI output was unusable. Root Cause: The buffer that was holding the IPv6 address was not large enough to store large V6 address. Steps to Replicate: Log in to the admin session with a large v6 address. Repeat the same test that was done to find this issue. | The code is modified increased the buffer size. Workaround: No workaround. |
129 | SBX-102925 | 2 | There are issues in the Ova\QCow2 installation. Impact: Differing prompts and root passwords are created for the SBC SWe installed through the ISO, and the SBC SWe created through the image launch method, Root Cause: While installing through the image launch method, the SBC SWe was configured with the Cloud SBC method of creating the root password and prompt. Steps to Replicate:
Results from step 1 and 2 should be same. | The code is modified to ensure both image launch method and ISO install method of the SBC SWe has no root password and the same CLI prompt. Workaround: A user can manually remove root password on ISO installed SWEs using the command below: |
130 | SBX-104126 | 2 | Re-INVITE when a 200 OK with crypto line is listed other than 1. Impact: When the SBC offers a multiple crypto suite in an INVITE (offer) and the egress sends answer with crypto suite that is other than the top priority crypto offered by the SBC, the SBC sends an unnecessary re-INVITE to egress when minimizeRelayingOfMediaChangesFromOtherCallLegAll flag is enabled. Root Cause: The SBC does not update the media subsystem structures correctly. Steps to Replicate: Configuration: The SBC sends INVITE to egress with multiple crypto and egress endpoint answers with crypto that is other than top priority crypto that the SBC sent. | The code is modified to ensure the SBC suppresses the re-INVITE when the egress answer has crypto, which is not the top priority crypto as per the Packet Service Profile configuration. Workaround: None. |
131 | SBX-109681 | 2 | Low MOS score for UNENCRYPTED_SRTP calls. Impact: In the SRTP for unencrypted, authenticated case, the SRTP packets were being discarded at NP due to an authentication key mismatch. Root Cause: In the SRTP for unencrypted, authenticated combinations, the key size is required in NP to derive the session authentication keys. Since a cipher key size was not being passed to the NP, the session authentication key was incorrectly calculated. Steps to Replicate: Test Setup on the SBC:
Procedure: Endpoint1 sends an offer SDP with crypto attribute SRTP/SHA-1-80 and with Session Parameters UNENCRYPTED_SRTP Endpoint2 replies with crypto attribute SRTP/SHA-1-80 and with Session Parameters UNENCRYPTED_SRTP | The code is modified so the SBC application is passing the cipher key size also to the NP to calculate session authentication keys. Workaround: The workaround is to not send unencrypted SRTP. Use cases with encrypted SRTP and authentication show no issues. |
132 | SBX-108273 | 2 | The SBC will not work when the require header comes in 18x without 100Rel. Impact: The 18x message is not relayed when the 100rel is not present in the Require Header. Root Cause: The functionality is not present to handle the use case for proxy behavior when 100rel is not present in the Require header. Steps to Replicate: Run the scenario below:
| The code is modified to consider this case when the 100rel is not present in the Require header. Workaround: Not Applicable. |
133 | SBX-105436 | 2 | There are CDR issues for REGISTER. Impact: There were issues while writing the CDR's for REGISTER method. Root Cause: Below issues were present w.r.t REGISTER CDR's:
Steps to Replicate:
| The code is modified to address the following:
Workaround: None. |
134 | SBX-107192 | 2 | The M-SBC should not check the UDP checksum value with "m=application". Impact: The M-SBC drops ESP packets with "0" checksum of the UDP header over "m=application" on IPv6. Root Cause: The M-SBC always validates for the checksum in the UDP packet received, if the checksum value is 0 then it drops the packet causing failures. Steps to Replicate:
| The code is modified so the M-SBC accepts zero checksum and sends a valid checksum. Workaround: None. |
135 | SBX-104319 | 2 | Conflicted design between two features “sdpRelayAttribute” and “Send RTCP Bandwidth Info”. Impact: The SBC sends duplicate b=RR and b=RS values when “sdpRelayAttribute” and “Send RTCP Bandwidth Info” are enabled together. Root Cause: The SBC was not honoring "sendRTCPBandwidthInfo" only when “sdpRelayAttribute” was enabled with TFT. Due to this, the duplicate of b=RR and b=RS was seen, when “sdpRelayAttribute” was enabled without TFT. Steps to Replicate: Configuration:
Procedure:
Also, the SBC should not add duplicate b=RR and b=RS parameters in the SDP honoring the configured bandwidth values in the PSP. | The code is modified so if “sdpRelayAttribute” is enabled separately without TFT, and "sendRTCPBandwidthInfo" is enabled, then the SBC does not honor "sendRTCPBandwidthInfo" and does not send a duplicate value of b=RR and b=RS. Workaround: None |
136 | SBX-109862 | 2 | The SBC is not rejecting the SRTP call when the disallowSrtpStream is enabled. Impact: The SBC is not rejecting the SRTP call when disallowSrtpStream is enabled in ingress PSP and an INVITE is received with only a SRTP stream. Root Cause: This is specific call flow when the disallowSrtpStream is enabled and a INVITE is received with only a SRTP stream. Steps to Replicate: Procedure:
| The code is modified so that when the disallowSrtpStream is enabled and an INVITE is received with only SRTP stream, the call is rejected with a 488. Workaround: None. |
137 | SBX-106913 | 2 | The SCM Process coredumps for the register with a timeout from the application server with no response. Impact: When the REGISTER message is sent to the redirect server and if there is no response to REGISTER message, the SBC is dumping core. Root Cause: The coredump is caused due to a missing NULL check. Steps to Replicate:
After step 4, the SBC coredumps. | The code is modified to avoid the core dump. Workaround: None. |
138 | SBX-108232 | 2 | There was an ERROR: AddressSanitizer: heap-use-after-free on address 0x61800000a5a8 at pc 0x559e8989c4ac bp 0x7f4411fde290 sp 0x7f4411fde288 READ of size 8 at 0x61800000a5a8 thread T9. Impact: While the SBC node is shutting down it can access memory after its been freed, this could result in unexpected behavior and in the worst case a coredump. But this would have limited impact as it only happens when shutting down. Root Cause: During sbxstop/sbxrestart or switchover because of race-condition, when the SBC is in deactivation the oamNodeRegisterRetry can access an already deallocated resource leading to a core dump. Steps to Replicate:
| The code is modified to handle this race condition. Workaround: None. |
139 | SBX-108058 | 2 | SBC: There was a CpxAppProc memory leak. Impact: During the SBC startup processing, there is a small memory leak. Root Cause: During the startup processing, the SBC is allocating memory while reading configuration information and it is not being freed up correctly at the end of the provisioning steps. Steps to Replicate: This issue was only observed while running with ASAN images in the engineering lab as the amount of memory leaked is small and cannot be checked. | The code is modified to correctly free the memory allocated while processing the configuration data. Workaround: None. |
140 | SBX-109453 | 2 | The SBC is closing the socket for a DNS query over the TCP frequently. Impact: The SBC is closing the socket for DNS query over the TCP frequently. Root Cause: Whenever the TCP connection is closed FIN packet is sent towards the SBC from DNS server. But, the application was not closing connection by sending a FIN and Even after connection is closed by DNS server, the Application is still holding socket information. These details were used in future queries has cause TCP connection to reset. Steps to Replicate:
Actual behavior: In step 3, the SBC will query DNS server to resolve NAPTR records over TCP connection. The NAPTR query should be successful in step 4. | The code is modified to close the TCP connection (Sending FIN to close connection). Also, the connection information in application is freed. Workaround: None. |
141 | SBX-101432 | 2 | There was a question about DSP insertion. Impact: Customer was seeing the "DSP insertion/rejection reason" CDR fields set to "Rejected codec unlicensed" and wanted to know why. Root Cause: The documentation did not provide any guidance as to when this value could appear. Steps to Replicate: The customer call scenario is unknown. | The code is modified to provide guidance on when it could happen as per below.
In any of the above cases if passthru is possible and if the call is successful then DSP Rejection reason will be updated after successful offer answer. Its also possible this value might appear in the case where the offer/answer exchange did not complete. As the customer was unable to provide details on the specific call flow additional info level logging and call trace logs have been added to provide more details for the future. Workaround: None. |
142 | SBX-106077 | SBX-105188 | 2 | Portfix SBX-105188: The SBC does not use Replacement field in NAPTR response for SRV query. Impact: The SBC does not use a Replacement field in NAPTR response for SRV query. Root Cause: The SBC is not accepting replaceHost value's recieved in NAPTR response, when transportPreference or transport type1 are configured and dnsNaptrAlways flag is enabled. Steps to Replicate: show addressContext default zone ZONE_AS_1 sipTrunkGroup SIP_EXT_TG services dnsNaptrAlways dnsNaptrAlways enabled
Expected result: The SBC should parse host part of NAPTR response and use it in future SRV query. | The code is modified to accept the replaceHost value's, even when the transportPreference or transport type1 are configured and the dnsNaptrAlways flag is enabled. Workaround:
|
143 | SBX-108457 | SBX-107142 | 2 | Portfix SBX-107142: The SBC VM was unable to power on post-poweroff procedure. Impact: The VMware GPU SWe instance does not come up post reboot or the GPU is not visible in the instance. Root Cause: When the SWe instance runs in GPU mode, the persistence mode of the NVIDIA driver is enabled using the NVIDIA-smi to prevent the GPU state from being unloaded. This is a kernel-level solution and was creating problem when the hypervisor is VMware. Steps to Replicate:
RESULT: The instance should come up and the GPU should be visible in the instance. | The code is modified by using the NVIDIA Persistence Daemon. Workaround: None. |
144 | SBX-109496 | SBX-109871 | 2 | Portfix SBX-109496: The SBC is not registered in EMS using Ansible playbook. Impact: The SBC is not registered in EMS using the Ansible playbook. Root Cause: In case of an iso based installation where the lca module is not installed, the location for the getAndUpdatePasswords.py file is different. Steps to Replicate:
| The code is modified to verify the file location. Workaround: None. |
The following known issues exist in these releases.
Known Issues
Issue ID | Sev | Problem Description | Impact/Workaround |
---|---|---|---|
SBX-109855 | 2 | The SBC sends unwanted Update with AMRWB in LRBT call. | Impact Statement: TheSBC is unable to establish the call successfully. Scenario: The SBC is configured to play LRBT.
Workaround: None. |
The following limitations exist in this release:
Due to a known EMA GUI issue, it can take up to 10 minutes to process and commit an SMM profile. This may be seen when the profile contains the max of 256 rules within it and provisioning of the SMM profile is being done using the EMA GUI. This will be fixed in a future release.
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 OAM Node 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.
When upgrading SBC SWe cloud instances from any release prior to 9.1 to release 10.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.
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
MS Teams
Support for video only call