SBC Core 11.00.00R000 Release Notes

PortFix SBX-117637: The MNO I-SBC switchover sonusCpRedundGroupSwitchOverNotification.

Impact: The SCM is coring when trying to free memory that has already been freed.

Root Cause: The SCM is coring when trying to free memory because of non-reproducible edge case scenario that caused the memory to be freed before returning from a subroutine – and the calling function didn’t handle this correctly.

NOTE: This scenario can only happen if downstreamForkingSupport is enabled on the SIP Trunk Group.

Steps to Replicate: The steps cannot be reproduced.

The code is modified to prevent the scenario that allows the subroutine to free memory that has already been freed.

Workaround: There is no known workaround.

PortFix SBX-117476: There is congestion memory in a customer lab.

Impact: The SCM process is leaking memory when sendSBCSupportedCodecsForLateMediaReInvite is enabled in the IP Signaling Profile.

Root Cause: The SCM process may not free internally allocated structure when sendSBCSupportedCodecsForLateMediaReInvite is enabled in Ip Signaling Profile.

Steps to Replicate: Run load with “sendSBCSupportedCodecsForLateMediaReInvite” enabled in the IP Signaling Profile and confirm the leak.

NOTE: The call flow must result in a NRMA Modify being sent internally.

The code is modified to ensure that these structures are freed.

Workaround: Disabling sendSBCSupportedCodecsForLateMediaReInvite may prevent this issue.
But, there may be other code paths or scenarios that may trigger this leak.

PortFix SBX-111947: The SBC query on the SysDump.pl script.

Impact: The addition of cloud-init logs collection is the sysdump script requested by the customer.

Root Cause: Unavailability of cloud-init log collection in 8.2.2 sysdump scripts.

Steps to Replicate: Run sysDump.pl on any cloud based setup to check if cloud-init logs are collected.

The code is modified to add cloud-init logs.

Workaround: None.

PortFix SBX-117963: There was a switchover every five minutes on the SWe.

Impact: While reporting statistics for Fault Avalanche Control, SAM process may core if reporting on a call with a callId larger than 24 characters.

Root Cause: While reporting statistics for Fault Avalanche Control, an incorrect "maximum size" is used when copying a callId - resulting in the code writing past the end of an allocated buffer and corrupting memory.

Steps to Replicate: Run some calls with FAC while collecting FAC statistics.

The callids for these calls should be longer than 24 bytes.

The code is modified to use the correct "maximum size" when copying the callId.

Workaround: Disable the Fault Avalanche Control. The Fault Avalanche Control feature is a feature, which blocks SIP messages of certain key elements that it is aware of that have caused multiple coredumps in the past, these calls should be blocked from being processed again.

Portfix SBX-114128: Video calls are not processed the first time.

Impact: The usePsxRouteForRegisteredInvite works only for non TLS transports, the requirement is to enable this flag for TLS transports as well.

Root Cause: The flag usePsxRouteForRegisteredInvite is not working for TLS transports.

Steps to Replicate: 

1. Enable the flag usePsxRouteForRegisteredInvite.
2. Set the transport as TLS.
3. Complete the registration for user over TLS.
4. Make a call towards registered user.

Expected Results: The call should go to PSX returned user instead of RCB's contact.

The code is modified to consider usePsxRouteForRegisteredInvite flag for all transports.

Workaround: None.

PortFix SBX-117064: Increase the number of days for compressed CDR retention.

Impact: Request to increase the maximum days compression from 7 to 14.

Root Cause: The maximum allowed was previously set to 7.

Steps to Replicate: Check that the "Days compression to keep" field in the eventLog typeAdmin screen can now be set to a maximum of 14.

The code is modified to allow the new maximum of 14.

Workaround: None.

PortFix SBX-115937: The SBC switched over due to the Deadlock issue.

Impact: The SBC switched over due to a Deadlock issue.

The CPX process deadlocked while calling CpxTrunkGroupMediaIpSecondaryInterfaceGroupNameValidate to validate the SecondaryInterfaceGroupName while the customer was making several calls to get the authPassword.

Root Cause: Due to the authPassword was being fetched many times a second, that call was occurring at the exact same time as the CpxTrunkGroupMediaIpSecondaryInterfaceGroupNameValidate was called. Both routines used the same global maapiSocket to do maapi calls to read the confd database. Since the same global socket was being used, the maapi_exists call hung.

Steps to Replicate: In one CLI session, make many calls to get the authPassword:
show table addressContext <context> zone <zone> sipTrunkGroup <trunkgroup> signaling authentication authPassword

In another CLI session, run the following command parameters:
set addressContext <context> zone <zone> sipTrunkGroup <trunk group> media mediaIpSecondaryInterfaceGroupName <groupname>

Observe that the CPX does not crash.

The code is modified so a CDB receives the authPassword, so there is not contention for the global maapiSocket.

Workaround: Do not get the authPassword at the same time the setting the mediaIpSecondaryInterfaceGroupName.

PortFix SBX-117393: There was a SCM Process switchover and coredump. 

Impact: The SCM Process has cored when attempting to allocate memory.

Root Cause: The SCM Process has cored when attempting to allocate memory because the memory management code has detected memory corruption.

The memory corruption occurred because the code wrote into a memory block after it is freed. This appears to have occurred when SRS gets blacklisted during setup and call needs to route advance to next SRS.

Steps to Replicate: The steps cannot be reproduced.

The code is modified to prevent writing into this memory block after the memory block is freed.

Workaround: There is no known workaround.

PortFix SBX-114778: The STOP RECORD is missing from CDR VIEWER after a switchover.

Impact: STOP RECORD IS MISSING from CDR VIEWER after a switchover.

Root Cause: With the current Logstash configuration, the logstash reads the TRC and ACT files only from the time when the logstash was started, which means older data is not read by logstash. When a switchover occurs, by the time logstash is started all the calls would have completed thereby updates to TRC and ACT would have stopped.

Logstash does not read the TRC and ACT files until they are updated again. When the updates start, logstash does read from the point where the new data is written and not the old data. This is the reason why stop record of the calls are not shown after the switchover

Steps to Replicate: 

1. Log in to the EMA of an active SBC and Enable CDR Viewer.
2. Run a call with a duration (about 50 seconds) such that it gets stopped before EMA is started in the standby SBC after the switchover.
3. Initiate a switchover.
4. Log in to EMA of a standby SBC (which is the active now).
5. Navigate to CDR viewer screen.

The STOP record should be displayed

The code is modified to read the older data and not just the new data.

Workaround: None.

PortFix SBX-115616: Routing label settings could not be changed in the EMA if created by the CLI.

Impact: Routing label settings could not be changed in the EMA if created by the CLI.

Root Cause: CLI was allowing _ + - . : @ characters in the Routing Label name. The EMA, however, was allowing only _ character in Routing Label name. Due to this Routing Label updates, the settings was failing in the EMA.

Steps to Replicate: 

1. Log in to CLI.
2. Created Routing Label with following special characters (+:.@-) from CLI.
3. Log in to the EMA.
4. Navigate to Routing and selected the Routing Label and edited the same.
5. Edit is successful.

The code is modified to allow special characters + - . : @.

Workaround: No workaround.

PortFix SBX-116386: Azure: An upgrade is failing from 10.1R00 build to 10.1.1 on HFE2.1.

Impact: In the Azure SWe, during the 1:1 upgrade, due to sporadic network connectivity issues in HA network, the upgrade may fail due to a loss of the SBC APP configuration.

Root Cause: Split-brain could occur due to sporadic network connectivity issues in the Azure platform. If this network connectivity issues occurs during the upgrade procedure, then there is a possibility of losing the SBC configuration, that could result in upgrade failures.

Steps to Replicate: 

1. Launch the SBC HA pair in 1:1 mode on Azure with 10.1 build.
2. Subject the SBC HA pair to upgrade from 10.1 to 10.1.1 build from IAC/RAF.
3. Observe that vsbc2 (installed standby) undergoes an upgrade and comes up with 10.1.1 build.
4. Now the upgrade is issued to vsbc1 (installed active), run a switchover - vsbc2(installed standby) takes up the active role.
5. The vsbc1 (installed active) VM comes up and tries to search for vsbc2 (installed standby - current active).
6. Bring down the ha0 interface on vsbc2. The vsbc1 (installed active) VM won't be able to see vsbc2.
   The vsbc1(installed active) VM continues forward with its own processor indices, and comes up with active role.
7. Start the vsbc2 VM. As soon as vsbc2 comes up, vsbc2 detects the self and peer indices to be different, and reboots to recover from split-brain.

The code is modified to ensure that the SBCs wait for more time (approximately 10 minutes from 10 seconds) to make sure that the SBCs do not enter into the split-brain detection procedure early on. This helps prevent split brain occurences.

Workaround: None.

PortFix SBX-118118: Both units went down after unregistering from the EMS.

Impact: Both units went down after unregister from EMS

Root Cause: The code in the ENM process which handles the notification of the deletion of the SnmpAgent snmpTargetMib snmpTargetAddrTable snmpTargetAddrEntry spawns a thread to delete the corresponding trap from the oam snmp trapTarget table that shares a cdb socket with SonusSnmpTrapTarget::ProcSubDelete. This resulted in a deadlock and the ENM process stops to clear the deadlock.

Steps to Replicate: 

1. Register an SBC instance with an EMS.
2. Unregister that instance with the EMS.

Observe that the ENM process does not crash.

The code is modified to use its own cdb socket so that there is not any contention from two threads for the same socket and to avoid the deadlock situation and in turn, avoid another coredump.

Workaround: None.

Portfix SBX-116205: Services are not coming up in standby node after upgrading to 10.1.1 from 9.2.3R1 in hardware 7000 setup.

Impact: The SBC service is not coming up on standby after upgrade.

Root Cause: Standby confd is trying to connect to active confd during upgrade which fails causing SBC application to go down.

Steps to Replicate: Perform standby upgrade and then active upgrade to ensure both the services are coming up during and after the upgrade.

Avoid sonusMgmtIpInterface XML file exchange between active and standby so that standby confd does not connect with active confd during the upgrade.

Workaround: No workaround.

PortFix SBX-114591: After adding AclRule in the S-SBC and enabling it, the OS rebooted and application would not come up.

Impact: The SWe_NP process exits during DPDK ACL trie build operation causing the SBC to go for reboots.

Root Cause: There was no limit set for the memory requirement of DPDK ACL trie build process, this results in DPDK consuming more huge pages than available on the system and causing SWe_NP process to exit.

Steps to Replicate: 

1. Bring up a SBC instance.
2. Apply the configuration for E2E scenario.
3. Verify that the SBC is stable after the configuration.

The code is modified to limit the memory requirement of DPDK ACL trie build process.

Workaround: Increasing the RAM of the instance to 64G could be a possible workaround.

PortFix SBX-116997: Late media pass-through calls fail after an upgrade from 8.2.2R0 to 8.2.6R0 - root cause is the RTCP termination for pass-through calls flag enabled.

Impact: Late media pass-through calls with "RTCP termination for passthrough" flag enabled failed.

Root Cause: There are two receiver IDs in the RTCP termination Bus RESource definition. If one of the RIDs was not enabled during the BRES activation, the ingress XRES (ethernet resource) had not learned the destination MAC address yet, then the RTCP Gen is left enabled according to the design.

When that BRES gets deactivated, skip the sending RID disable command to NP for that not enabled RID, and also missed issuing RTCP Gen disable command to NP.

So when that BRES gets re-activated, the logic detected that RTCP Gen has already been enabled and failed the activation process, which then fails the call.

Steps to Replicate: Establish a late media pass-through call with "RTCP termination for pass-through" flag enabled. The SBC will send a SIP BYE once it receives the SDP answer in the SIP ACK SDP.

The code is modified to send RTCP Gen disable command to NP even when RID is not enabled.

Workaround: Turn off the "RTCP termination for pass-through" flag.

Observing core dumps in the SBC while running bulk configurations.

Impact: A core dump was observed in the SBC.

Root Cause: A core dump was generated as cdb call for ACL taking time. This is race-condition and do not see this often.

Steps to Replicate: 

1. Upgrade the SBC 7000 set up from V09.02.03R004 to V11.00.00A005 (build 95).
2. Ran load and long duration calls.
3. Perform a clearDB before running the RESTAPI bulkconfig script.

The code is modified to disable healthcheck during this operation.

Workaround: None.

The CPX not handling the notification correctly from SDR.

Impact: The SNMP traps destinations set by the FQDN are not resolved correctly to IP.

Root Cause: The ConfD CDB API return inconsistent data when reading from CDB_RUNNING.

Steps to Replicate: 

1. Deploy the SBC.
2. Add DNS records for SNMP trap target.
3. Configure DNS nameserver in the SBC.
4. Configure SNMP trap target FQDN.
5. Validate that the SBC resolve the FQDN and add the corresponding IP address and port.

The Management Agent API (MAAPI) is now being used to read the SNMP trap target information instead of the CDB API.

Workaround: Restart the SBC. 

Possible stack overflow vulnerability in the RTCP processing.

Impact: Potential stack overflow vulnerability was identified through the internal code review in the RTCP generation subsystem of SWe NP module.

Root Cause: The root cause of the problem was identified to the use of variables of an incorrect storage size.

Steps to Replicate: The steps cannot be reproduced. 

The code is modified to address the vulnerabilities.

Workaround: No workaround.

Azure: Upgrade is failing from 9.2.3R4 build to 11.0.0 on standalone.

Impact: Upgrades are failing in Azure using Ribbon IaC package.

Root Cause: Newer versions of the Azure CLI change the way it authenticates, meaning it no longer works with the Ribbon IaC package.

Steps to Replicate: 

1. Log in to the Azure CLI.
2. Attempt to upgrade the Azure SBC using Ribbon IaC.
3. It will fail due to lack of credentials

The code is modified to install Azure CLI version 2.24.0

Workaround: 

1. Uninstall the current Azure CLI version.
2. Install the Azure CLI version set as 2.24.0, using the system package manager.

An upgrade is successful but revert operation failed - V10.1.0R2 to V11.0.

Impact: The SBC application does not come up after revert on Cloud 1:1 mode.

Root Cause: The SBC application gets stuck due to Openclovis model update cache on old active disk.

Steps to Replicate: 

1. Perform upgrade on SBC HA 1:1 on public cloud like AWS from pre-11.0 to 11.0 release.
2. Revert the SBC HA 1:1 to pre-11.0 release.

The code is modified to indicate this model update cache and perform a model update on standby after revert to remove any component that is not needed.

Workaround: 

1. Bring up SBC HA application with pre 11.0 release on public cloud like AWS.
2. Upgrade both active and standby SBC to 11.0 release using the recommended upgrade method.
3. Revert the SBC application to pre 11.0 release.
4. After revert operation, check to see if application is coming up fine on both active or standby.
5. If the application is stuck and not able to get the assigned role, stop SBC application on both active and standby nodes using ‘sbxstop’ command.
6. Remove the following file/directories from both active and standby SBC if existing:
   1. rm -rf /home/cnxipmadmin/peerDynamicHANewComps
   2. rm -rf /opt/sonus/sbx/openclovis/var
7. Start the SBC application on both active and standby nodes using ‘sbxstart’ command.
8. Check to ensure that application is coming up fine on both nodes.
   

Performance: Observed "SIPSG" MAJOR log after sync complete with the first admin switchover while running SIP-SIP cyclic call load for testing 10 admin switchover on Bluefin HA Pair on build #271

Impact: When the SIPREC or Call Notification feature is enabled and an internal error like the SIP transaction occurs for the CS call, the SBC generates MAJOR level logs stating the msgId was not available.

Root Cause: For internally generated response codes for events like transaction timeout on CS calls, there are no message handles and message indexes. The SBC is making an attempt to store SIP headers that are required for call notification and SIPREC features, and since the msgId or msgHandle is not found, an error log is generated.

The logic to store the SIP Headers from SIP response should have worked only when CLI "metaDataSource" in "sipRecMetadataProfile" is set to "fromLatest" but the MAJOR logging is independent of the feature control.

Steps to Replicate: 

1. Enable SIP Rec or call notification feature with CLI "metaDataSource" in "sipRecMetadataProfile" is set to "fromLatest" to capture SIP Headers from latest SIP message to be populated in SIPREC Metadata.
2. Simulate setup for INVITE/Re-INVITE to fail (transactions times out , so the SBC generates internal SIP response code (7xx) and results in MAJOR log.

The code is modified to skip making an attempt to store SIP Headers for internal errors like SIP transaction timeouts as there is no actual SIP response message from network. The SBC should consider SIP headers for metadata population only for actual SIP responses coming from network.

Workaround: None.

The GW-GW Performance load on 7000: System Congestion and the SAM Process crash observed while doing CLI switchover(core dump profile set to sensitive).

Impact: Observed the SAM process core during a GW-GW performance load test.

Root Cause: A GW-GW OPEN REQ was received on an old socket, and at the same time originating GW tried to create new connection (This is due to the original GW being so congested an OPEN REQ took a long time to get from GWFE to GWCM). In a receiver GW, the GWFE requests the GWCM to send OPEN ACK on a new socket.

As a result of this process, this creates new GW-GW link at originated GW, but the receiver GW is still not aware of new GW-GW connection as it replied to old OPEN REQ in new socket.

Originating GW start sending link PING packets, which receiver GW thinks this is invalid event as per Receiver GW new connection not established yet. This created a system error in the receiver GW.

Steps to Replicate: 

1. Establish call load on the SBC HA pair to GSX using a PSX.
2. Set up a max rated SIP-GW signaling sessions.
3. Perform admin switchover on the SBC.

Expected Result: The Max rated SIP-GW call load should be recover successfully after the switchover.

Actual Result: The IM cored in new active box and after that received a "SAM Process" core on a 7000 Adapter.

The code is modified so that the GWCM is sent out OPEN ACK packet on socket it received OPEN REQ message.

Workaround: None.

The Cloud SBC services are taking more time to come than usual after few suites executed successfully (~14) in CICD2 project

Impact: The SBC fails to load sonusMgmtInterface.xml file in CDB while coming up.

Root Cause: In CHM process, resetting of mgmtStaticRoute table and loading of sonusMgmtInterface.xml are run in parallel, which causes issue while loading XML file in some cases due to a race condition.

Steps to Replicate: Launch the SBC on Cloud platform and check for failure in loading sonusMgmtInterface.xml file.

The code is modified to allow resetting of mgmtStaticRoute table to complete before loading sonusMgmtInterface.xml file.

Workaround: No workaround.

The sysDump saved with an owner as root even though sbcDiagnostic 2 is run with linuxadmin as user.

Impact: In the Cloud SBC when sysdumps are generated using sbcDiagnostic command as linuxadmin user, linuxadmin is unable to copy the sysdumps due to restricted permissions.

Root Cause: sbcDiagnostic was generating sysdumps with root ownership, which did not allow linuxadmin to copy them.

Steps to Replicate: 

1. Run sbcDiagnostic 2 command as linuxadmin user in the cloud SBC.
2. Try copying generated sysdumps from /opt/sonus/external/ location.

With a fix, linuxadmin should be able to copy sysdumps.

The code is modified to allow copying.

Workaround: None.

PRS process coredumps generated after a switchover on the SBC (the standby is not coming up).

Impact: PRS process core dumps after a switchover on the SBC.

Root Cause: The race condition happens between BRM and XRM for T.38 implementation.

Steps to Replicate:

1. Configure the SBC for a basic call.
2. Start the basic call.
3. Perform a CLI switchover on the SBC-ACTIVE.
4. Calculate the signaling switchover time.
5. Calculate media switchover time.
6. Check for coredumps.
7. Terminate the call.

The code is modified to check that the BRM context already created on standby before it retrieves BRES ID.

Workaround: Not available.

Observed IpSockAddr (0.0.0.0) and Port (0) for Egress leg in GW1 and Ingress leg in GW2 for GW-GW HPC call scenario.

Impact: The IpSockAddr and Port fields are 0 in the global callDetailStatus status command in a GW-GW HPC call scenario.

Root Cause: In 9.2.4R001, the code was added to not send CPC_OP structures unknown to the GW-GW encoder layer over the GW-GW link to reduce the size of the GW-GW message sent to older SBCs and the GSX. However, it was found that at least one of these unknown CPC_OP Structures, CPC_OP_SIP_ZONE_AC_NAME_STR was used to transfer information used in the global callDetailStatus status command.

Steps to Replicate: 

1. Set up two SBCs that communicate over the GW-GW.
2. Place a GW-GW HPC call scenario call.
3. Observe that the IpSockAddr and Port fields are not 0 after running the global callDetailStatus status command.

The code is modified to send the unknown CPC_OP structures to the GW-GW encoder layer over the GW-GW link.

Workaround: None.

After multiple transfer's, the call is failing when trigger a switchover in the D-SBC HA.

Impact: A calls B.
B refers to C.
C refers to D.
A is connected to D.

There are three gcids (gcid1, gcid2, gcid3) are involved here.

Issue:

1. In the transfer case above at the end one of the gcid (First transfer, gcids) media resources are released. On the re-Invite, NRMA is adding a DFE in the cpclist to be given to RTM , even when the media resources from a callLeg are released. Because of this, the RTM sends RTM_CALL_DATA_SYNC_NFY_STR to DFE. DFE does not respond to this request and RTM is never able to put this gcid in Stable state. This is followed by  a switchover and the call is disconnected.
2. Once the issue above was addressed, on a switchover when the new Active box takes up, NRMA initiates an audit and it was again sending the call Verify Request to DFE. The DFE is not aware of the gcid2
   (NrmaProcExtensiveAuditNfy→NrmaSendCallVerifyRequestsToCpcs), and as a result, the callcleanup was initiated by NRMA.

Root Cause: 

1. In the transfer case above at the end one of the gcid (First transfer, gcids) media resources are released. On the re-Invite, NRMA is adding a DFE in the cpclist to be given to RTM , even when the media resources from a callLeg are released. Because of this, the RTM sends RTM_CALL_DATA_SYNC_NFY_STR to DFE. DFE does not respond to this request and RTM is never able to put this gcid in Stable state. This is followed by a switchover and the call is disconnected.
2. Once the issue above was addressed, on a switchover when the new Active box takes up, NRMA initiates an audit and it was again sending the call Verify Request to DFE. The DFE is not aware of the gcid2
   (NrmaProcExtensiveAuditNfy->NrmaSendCallVerifyRequestsToCpcs), and as a result, the callcleanup was initiated by NRMA.

Steps to Replicate: Run a basic call, and the call load is tested.

The code is modified to:

1. Add the DFE only when the media resources are present on a callLeg.
2. The DFE only when media resources are present. Previously, this was per call that is now modified to be per callLeg.

Workaround: None. 

Portfix SBX-107636: Observing wrong MGMT gateway IP for an active SBC in mgmtStatic route of the SBC.

Impact: The loadConfig with a configuration dump taken from a different network, loses network connectivity to the management interface.

Root Cause: When loadConfig is attempted from a configuration dump taken from a different network, default management routes are not reset. Because of this, the node is not reachable.

Steps to Replicate:

1. Run the sbxrestart on Openstack 1-to-1.
2. Run the SBC cleanup on Openstack 1-to-1.
3. The saveConfig on an instance, delete instance and loadConfig this config on a new instance.

The code is modified to delete and load management static routes of active and standby at every startup,

Workaround: Manually load the XML file by logging on to console.

Portfix SBX-114693: Need to Update all the Application code to set the V6 loopback address.

Impact: The SBC fails to identify an address as loopback address for an IPv6 call.

Root Cause: There is a disconnect between the method used to set the IPv6 loopback address and the method used to check it.

Steps to Replicate:

1. Run a NATed call from IPV6 end point.
2. A call has to be established successfully and media should flow from EP1 to EP2 through the SBC.

The code is modified so that the SBC identifies the loopback address for an IPv6 call correctly.

Workaround: None.

PortFix SBX-117280: Apache Axis security issues

Impact: The following vulnerabilities related to Apache 1.2 are identified within the Ribbon SBC application:

1. The CLI uses the unsupported Apache Axis 1.2 (2005) on the JBoss 5.1 (2009).
2. The CLI exposes the Apache Axis AdminServlet without authentication (default for Axis 1.2).
3. The CLI runs as the sonusadmin user which is a privileged account.

Root Cause: The CLI uses the unsupported Apache Axis 1.2 (2005), exposes the Apache Axis AdminServlet without authentication, and runs as the sonusadmin user which is a privileged account.

Steps to Replicate:

1. Access the url https://{SBC hostname}/liTargetProvisioning/services/AdminService from the browser.
2. An Axis error "No service is available at this URL" is displayed
3. Access the url https://{SBC hostname}/liTargetProvisioning/services/AdminService?wsdl from the browser
4. An Axis error "Could not generate WSDL! There is no SOAP service at this location" is displayed.

There is no required fix for issue number one.  Axis 1.2 has three vulnerabilities that do not affect the SBC application:

• CVE-2018-8032
• CVE-2014-3596
• CVE-2012-5784

Axis 1.4 has the same vulnerabilities plus one new vulnerability that could impact the SBC application.

• CVE-2019-0227

The SBC has not been upgraded to Axis 1.4. 

For issues two and three, the code is modified to remove AdminService.

Workaround: None

PortFix SBX-117921: A de-reference a NULL return value.

Impact: The SCM process allocates a null pointer resulting in a crash.

Root Cause: While trying to remove the EVS codecs from a call with a leg associated to the MRF/MRFP, the associated call leg is removed due to a race condition and the code dereferences a NULL pointer.

Steps to Replicate: The steps cannot be reproduced.

The code is modified to defend against the race condition and validates that the associated call leg pointer is not NULL before dereferencing it to avoid a coredump.

Workaround: None.

PortFix SBX-118051: DTLS client Hello being ignored.

Impact: The SBC ignores the DTLS Client Hello message resulting in no audio in the STUN/ICE/DTLS calls when the endpoint performs STUN checks for two candidates and they overlap.

Root Cause: The SBC stores a remote IP/port in the nominated candidate list even if the BREQ/BREQ_UC messages have started to be sent out. When the BREQ message resends the SBC uses the remote IP/port from the stored nominated candidate array and causing confusion.

Steps to Replicate: Establish a STUN/ICE/DTLS call and have the endpoint initiate the STUN connection checks with two candidates. The STUN checks should overlap in the following manner:

1. A Binding Request from candidate 1 (C1) is received by the SBC.
2. The SBC replies with a Binding Success Response to C1 and initiates a Binding Request to C1.
3. A Binding Request from candidate 2 (C2) is received by SBC.
4. The SBC overwrites the stored candidate with C2, sends a Binding Success Response to C2 and initiates a Binding Request to C2.
5. The SBC receives a Binding Success Response from C2 and sends a new Binding Request with the USE-CANDIDATE attribute to C2.
6. The SBC receives a Binding Success Response from C1.
7. The SBC internally uses the C1's IP and port although the USE-CANDIDATE is set to C2. The DTLS Client Hello messages from C2 is discarded by the SBC rogue media policer.

The code is modified:

1. To avoid updating the nominated candidate list if the BREQ or BREQ_UC are already sent out.
2. Not to send the BREQ during the window where the SBC has switched from sending BREQ to BREQ_UC.
3. To wait for the timer to be fired before resending BREQ.

Workaround: None

PortFix SBX-113150: The SBC alarm type field is missing.

Impact: The SBC alarm type field is missing.

Root Cause: Details about the alarm type are missing.

Steps to Replicate:

1. Log into the EMA.
2. Navigate to Alarms -> Cleared Alarms.
3. Select the Alarm.
   • Additional Info, Type and Reporter field are removed
   • Status, Description and Severity are added.

The Alarm Type is replaced. Additional information is provided for the alarm severity and description fields. The alarm reporter field is removed.

Workaround: None

PortFix SBX-116044: The ipPeer pathcheck command is not working.

Impact: The ipPeer pathcheck command is not working.

Root Cause: The URL is not encoded as the backend expects. The URL expects it to be in encoded format from 8.x.

Steps to Replicate:

1. Log into the EMA.
2. Navigate to Configuration -> System Provisioning -> Ip peer -> Path check.
3. Select Remote Admin State from the commands dropdown. Path check that the command opens successfully.
4. Select Local Admin State from the commands dropdown. Path check that the command opens successfully.

The code is modified to encode the URL before sending it to the backend.

Workaround: None.

Portfix SBX-114814: The SAM process cores after the surrogate registration executes.

Impact: The SAM process cores after the surrogate registration executes.

Root Cause: The SIPFE_SURRREG_MAX_PROFILES is at 256 and needs to be increased to 1000.

Steps to Replicate:

1. Configure the entries in the surrogateRegistrationProfile and check that the configuration is applied successfully.
   
   % set profiles services surrogateRegistrationProfile prof1 aorUserName 9480000002
% comm


2. Ensure that there is no SAM Process core.

The SIPFE_SURRREG_MAX_PROFILES is increased to 1000.

Workaround: None

Portfix SBX-115735: The interception of a challenged SUBSCRIBE message on the SBC fails.

Impact: The SBC fails to intercept a challenged SUBSCRIBE message.

Root Cause: Due to a design issue, the SBC fails to intercept a challenged SUBSCRIBE message.

Steps to Replicate:

1. Configure the SBC and the PSX with LI configurations.
2. From the UAC send a challenged SUBSCRIBE message.

The code is modified to intercept a challenged SUBSCRIBE message.

Workaround: None.

PortFix SBX-115978: The import operation is not working in the EMA SWE setup.

Impact: The import operation is not working in the EMA SWE setup.

Root Cause: The exportCmd in the SWe is used to start the import operation and is taking more than five seconds to start. The status in the UI is not updating and the import appears not to have started. 

Steps to Replicate:

1. Login to the EMA.
2. Navigate to the configuration import/export screen
3. Start the import operation.
4. The import operation starts and the status is shown in the UI.

The code is modified to add an additional five seconds delay in the UI before calling the getStatus API to get the status of the import operation. The UI will now make a getStatus call ten seconds after starting the import. 

Workaround: None.

PortFix SBX-117900: The Azure-SWe SLB reboots as a result of memory corruption.

Impact: The Azure-SWe SLB reboots as a result of memory corruption.

Root Cause: A memory corruption issue produces a memcpy into a buffer that isn't large enough. This memcpy is in code related to the SLB function.

Steps to Replicate: The steps cannot be reproduced.

The code is modified to verify the buffer size before the memcpy.

Workaround: None.

PortFix SBX-114818: An 18x/200 Contact header sent by the SBC contains a port number different than 5061.

Impact: The endpoints are registered over the TLS with a CDC configured SBC. The sig port that the SBC picks for outgoing messages keeps increasing. The messages are sent to non-existing ports.

Root Cause: The CLI changes the sig port table which should be configured as sig port.

Steps to Replicate: 

1. Create a basic SIP access scenario where an endpoint registers over the TLS (REGISTER – 401 – REGISTER – 200).
2. Provision the following (the assumption is that you already created an IP interface group named LIG with at least 1 IP interface in it):
   
   set addressContext default intercept nodeNumber 10001
comm
set addressContext default intercept callDataChannel LigCDC interceptStandard etsi ipInterfaceGroupName LIG
set addressContext default intercept callDataChannel LigCDC mediaIpInterfaceGroupName LIG
comm
set addressContext default intercept callDataChannel LigCDC vendorId utimaco
set addressContext default intercept callDataChannel LigCDC dsrProtocolVersion 1
comm
set addressContext default intercept callDataChannel LigCDC mediationServer dfxa media udp
set addressContext default intercept callDataChannel LigCDC mediationServer dfxa media udp ipAddress 10.117.94.211
set addressContext default intercept callDataChannel LigCDC mediationServer dfxa media udp portNumber 37502
set addressContext default intercept callDataChannel LigCDC mediationServer dfxa media udp dscpValue 16
comm
set addressContext default intercept callDataChannel LigCDC mediationServer dfxa media udp mode inService
set addressContext default intercept callDataChannel LigCDC mediationServer dfxa media udp state ena
comm
set addressContext default intercept callDataChannel LigCDC mediationServer imsa signaling
set addressContext default intercept callDataChannel LigCDC mediationServer imsa signaling ipAddress 10.117.94.202
set addressContext default intercept callDataChannel LigCDC mediationServer imsa signaling portNumber 38154
set addressContext default intercept callDataChannel LigCDC mediationServer imsa signaling dscpValue 16
set addressContext default intercept callDataChannel LigCDC mediationServer imsa signaling protocolType tcp
comm
set addressContext default intercept callDataChannel LigCDC mediationServer imsa signaling mode inService
set addressContext default intercept callDataChannel LigCDC mediationServer imsa signaling state ena
commit
   
   
3. Once the CDC is configured, register the endpoint. The SBC includes an incorrect port number (5062, 5063 and similar) in the Contact header of all messages sent to the endpoint.

The code is modified to configure the sig port table.

Workaround: This problem occurs only when the CDC is configured and registered via the TLS. 

PortFix SBX-116011: The SBC should not send registration request to LM when it is in N to 1 Mode Standby.

Impact: If an SBC is running as an N to 1 standby, and licenses are installed but the capacity license is not present, after 90 days the standby license count will revert to 0.

Root Cause: Since license usage statistics are not collected on the standby, registration with the license manager will fail.

Steps to Replicate:

1. Bring up an N to 1 cluster.
2. Verify that there are no traps related to the license manager on that standby.
   
   
   

The standby on the N to 1 system will no longer attempt to register with the License Manager until the standby becomes active. When it becomes active, the last successful registration time from the former active will determine the grace period left on the newly promoted active. For example, if the former active had not been able to register with the license server for 30 days, then the newly promoted active would now have 60 days left of the default 90 day grace period to successfully register with the License Manager.

Workaround: Switch over to the standby before the end of the grace period.

Portfix SBX-113553: Interworking between a 100 REL compliant UAS and a non 100 REL UAC. 

Impact: Interworking between a 100 REL compliant UAS and a non 100 REL UAC

Root Cause: The UAC is not 100 REL compliant and the SBC cannot forward the UPDATE to the UAC. It fakes a local answer 200 OK for this UPDATE with all the supported codecs of the UAC. This makes the SBC pick a pass through codec which is different from the codec already communicated to the UAC. An audio issue results until the call gets connected.

Steps to Replicate:

1. The UAC doesn't have a 100 REL support and UAS support 100 REL. Enable SendSingleCodecinAns for both the legs
2. The UAC sends an INVITE with the G729, AMR, AMRWB and PCMA to the SBC.
3. The SBC sends INVITE with G729 AMR, AMRWB and PCMA to the UAS.
4. The UAS sends 18x G729 and PCMA to the SBC.
5. The SBC sends 18x G729 to the SBC.
6. The UAS sends an UPDATE PCMA to the SBC.
7. The SBC sends a 200 OK Update message with the PCMA.
8. The call is transcoded from G729 to the PCMA.

The code is modified so that the SBC fakes the local answer 200 OK (for UPDATE here) with the last negotiated codec which is already communicated to the peer. The codec selection remains the same even after the offer-answer completion during an UPDATE-200OK handshake and there will not be any audio mismatch.

Workaround: None

PortFix SBX-114056: An RTCP goodbye message is sent after a 183 RESPONSE.

Impact: When monitoring a profile is enabled with an early media configuration, the early media from the endpoint is triggered. The
RTCP Bye packet is sent with the SSRC of the endpoint. The media continues with the same SSRC, resulting in issues because it is not compliant to the RFC.

Root Cause: The indication to stop monitoring is passed as soon as the early media is received. The deactivation and reactivation of resources cause it to send the RTCP bye packet with the SSRC. The SSRC is received from the endpoint.

Steps to Replicate:

1.  Configure monitoring profile with an early media authorization (EMA) flag enabled and the RTCP gen.
2. Configure the early media and create scripts with the P- early media supported.
3. The UAC sends an invite with the p-early media supported,
4. The UAS sends a 183 with a SDP that has a local PRACK and media with the SSRC1.
5. The UAS sends a 200 OK and media with the SSRC1.

The RTCP bye packet is suppressed for early media when the endpoint is playing the media.

Workaround: Disable the monitoring profile.

PortFix SBX-116206: The Relay Flag "Reason Phrase 4xx-6xx ", in the ERE is not working properly

Impact: The Relay Flag "Reason Phrase 4xx-6xx " is not set properly when the command is executed in the ERE.

admin@vsbc1-192.168.0.178% set profiles signaling ipSignalingProfile DEFAULT_SIP commonIpAttributes relayFlags reasonPhrase4xx6xx
[disable,enable] (disable): enable
[ok][2022-01-18 03:15:34]

[edit]
admin@vsbc1-192.168.0.178% comm
Commit complete.
[ok][2022-01-18 03:15:35]

[edit]
admin@vsbc1-192.168.0.178% show profiles signaling ipSignalingProfile DEFAULT_SIP commonIpAttributes relayFlags reasonPhrase4xx6xx
reasonPhrase4xx6xx disable;

Root Cause: The yang file and the SBX PIPE file values are not in order.

Steps to Replicate:

1. Install the SBC.
2. Open the CLI for the ERE and enable the flag with the following command:
   set profiles signaling ipSignalingProfile DEFAULT_SIP commonIpAttributes relayFlags reasonPhrase4xx6xx enable
commit
   3. Check for the value using the SHOW command.

The code is modified in the yang file.

Workaround: None.

PortFix SBX-116942: The XRM/NP CPU is utilized by a system task.

Impact: In the SWe, a few sbxPerf processes (example: top2, atop) have to run on the system core0 but instead are running on different cores.

Root Cause: In the SWe, the sbxPerf process has to run exclusively on the system core0.

Steps to Replicate:

1. Install a fix build in the SWe.
2. Check to see if the sbxPerf processes run on the core0.

Move the execution of the cset.sh script from the system core0 to the system cgroup.

Workaround: None

Portfix SBX-115464: The SBC auto-registration in the EMS is not working with the EmsFqdn.

Impact: The SBC auto-registration in the EMS is not working with the EmsFqdn.

Root Cause: The SDR is not setting the RD bit in the DNS query. This causes a query to the Route53 DNS to fail as the DNS recursion is required to resolve the entries by using the default DNS setting.

Steps to Replicate:

1. Create the EMS.
2. Launch the  SBC using the EmsFqdn and SdRegistry parameters.
3. Validate the SBC register with the EMS.

The code is modifIed and the SDR now sets the RD bit in the DNS query by default.

Workaround: Modify the SDR DNS backend setting through the ConfD to set resolve.recurse to true.

PortFix SBX-116335: The SBC EMA presents only the SSL server certificate, instead of the full certificate chain.

Impact: The SBC EMA/PM web server isn't sending the full certificate chain while negotiating the TLS with clients.

Root Cause: The SSLCACertificateFile option is commented in SBC which makes the EMA/PM server send only its serverCertificate to the clients.

Steps to Replicate:

1. Initiate the TLS connection from the browser to the SBC EMA/PM server and capture packets using Wireshark on the client.
2. The CA certificate does not show up in the packets.

The code is modified to add the SSLCACertificateFile option. Now the EMA/PM web servers will send the CA certificate along with the server certificate during TLS negotiations.

Workaround: None.

PortFix SBX-115994: The SBC is removing the DTG information on receipt of 3xx, when configuring the last trunk as incoming/outgoing.

Impact: The SBC is removing the DTG information on receipt of 3xx, when configuring the last trunk as incoming/outgoing.

Root Cause: While performing a TRM lookup for DTG information in the TrmProcessIpLookupCmd():

TRM_IP_LOOKUP_EGRESS_TYPE_DTGNAME_ONLY,

it iterates through all the Contact headers and saves the DTG information (for example: TG name, blocking status, and Trunk Type) in:

CPC_OP_TRM_IP_TRUNKGROUP_LOOKUP_DATA_STR *entry

The same CPC structure is used in SipSgFillDestTgrpToCpcMsgInfo() to copy the DTG information of all the TGs in the CPC_MSG. The DTG information is then used to route the call where the TRM lookup is done through DTG name.

But in the TrmProcessIpLookupCmd(), the TG blocking status STATUS and the TRM_IPTG_CB_STR *ipTgCbPtr of the last Contact header is used to send a TRM reply. The DTG of the last Contact is blocked and the TRM reply fails causing a DTG information loss.

Steps to Replicate:

1. Make a SIP-SIP call configuration using the PSX.
2. At the Egress zone, create 3 TGs in addition to the Egress TG. 
3. On the SBC, configure "ingressIpPrefix" of all 3 TGs (TG1, TG2, TG3) with different server IPs addresses (IP1, IP2, IP3).
4. Send 3 times with 3 contact headers.
5. Configure the same ingressIpPrefix address in the contact headers of all 3 messages such that the first contact header is set to IP1, the second contact header is set to IP2 and the third contact header is set to IP3.
6. Set the blockDirection of the TG3 to outgoing.
7. On the PSX, enable the Force Re-query for Redirection flag in the IPSP of the Egress Trunkgroup.
   
   Example:
   
   Contact: <sip:14135;tgrp=<TG_NAME>;trunk-context=meta1001-1002.grandma.ukelele.org.uk@IP1>;q=1
Contact: <sip:14135;tgrp=<TG_NAME>;trunk-context=NN.121.199.10@IP2>;q=0.9
Contact: <sip:14135;tgrp=<TG_NAME>;trunk-context=meta3001-3002.grandma.ukelele.org.uk@IP3>;q=0.8


8. Make a SIP-SIP call, send 3 times from the Egress peer with these 3 Contact headers.
9. The SBC sends an INVITE to the first Contact header through TG1.
10. If the first contact is not reachable, the SBC tries the second contact using TG2 and so on.
11. Verify that after receipt of 3 times with multiple contact headers, the TRM debugs are logged in the DBG with the Trunk group names of all three contact headers and there is no TRM failure message.

Two new local variables are created in the  TRM_IP_LOOKUP_EGRESS_TYPE_DTGNAME_ONLY :

• TRM_IPTG_CB_STR *ipTgCbPtrTemp and
• UCHAR statusTemp 

After each iteration, when the status != FOUND_BLOCKING, these new local variables are populated and then used in the TrmIpSendLookupRpyNfy() for the TRM reply.

Workaround: None.

Portfix SBX-107636: The AWS is observing the wrong management gateway IP for the active SBC in the mgmtStatic route of the SBC.

Impact: The loadConfig, with a configuration dump taken from a different network, loses network connectivity to the management interface.

Root Cause: When the loadConfig is attempted from a configuration dump taken from a different network, the default management routes are not reset resulting in the node being unreachable.

Steps to Replicate:

1. Restart the SBC on Openstack 1-to-1.
2. Clean up the SBC on Openstack 1-to-1.
3. Run the saveConfig on an instance, delete the instance, and loadConfig this configuration on a new instance.

The code modified to delete and load management static routes for active and standby at every startup,

Workaround: Manually load the XML file by logging on to the console.

PortFix SBX-117799: The SBC fails to recognize the PRACK in a multi-dialog (different TO tags) if 18X and 200OK are received simultaneously.

Impact: For dialog transparency and a forked call, the SBC may reject a PRACK request due to a rise condition of back to back 18X and 200OK.

Root Cause: After receiving a 200OK, the SBC finalizes the active remote tag and queues up to send out to the ingress as a result of a pending PRACK. When the PRACK is received, the SBC rejects it because the PRACK is coming from a different remote tag which does not match with the one in 200OK.

Steps to Replicate:

1. Configure the dialog transparency, forking, and the E2E PRACK enable.
2. Leg A calls Leg B.
3. B1 and B2 answer with an 18X message.
4. Next, B2 responds with a second 18X, and B1 with a 200OK (no SDP), simultaneously.

The SBC validates the remote tag based on the forking list not the finial one.

Workaround: Disable the PRACK.

PortFix SBX-116605: The SBC does not log SIP messages to the TRC file when routing calls using the DNS Lookup.

Impact: The SBC does not log SIP messages to the TRC file when routing calls using the DNS Lookup.

Root Cause: During a DNS lookup, the LogInfoSpec is not set with the proper logging details in the SIPCall data structure.

Steps to Replicate: Make a call from the Ingress side with the DNSLookup enabled. Post the call as successful and check the TRC file.

The code is modified to address the issue.

Workaround: None.

PortFix SBX-116307: Once the /var/log partition is filled in the SWe N:1 HA setup, the SBC services do not shut down.

Impact: Once the /var/log partition is filled in the SWe N:1 HA setup, the SBC services do not shut down.

Root Cause: The system fails to handle the condition that fills up 95% of the /var/log partition during the SWe setup.

Steps to Replicate:

1. Set up an instance in the SWe N:1 mode.
2. Continue filling in the /var/log partition disk.
3. When the /var/log partition fills up to 95%, the SBC application shuts down.

The code is modified to include the SBC SWe.

Workaround: None.

PortFix SBX-116807: The upgrade fails in one of the MRFP nodes due to OS issues while mounting the log disk volume.

Impact: An install or upgrade fails due to OS issues while mounting the log disk volume.

Root Cause: After mounting the log volume, the system is stuck while trying to reboot. All appropriate logs are written to the new mount point.

Steps to Replicate:

1. Bring up the 1:1 OAM and the 5:1 MRFP setup in V09.01.00R005 Build: 423
2. Start a call load with 12,000 sessions across five active instances with a 100cps.
3. Start the upgrade of the OAM using the IAC.

The code is modified to use the systemctl commands to reboot the instance.

Workaround: If the system gets stuck, then perform a manual reboot to continue.

PortFix SBX-116698: The SBC is sending out an Error-Info header in a 400 Bad Request even when the suppressErrorInfoHdr flag is enabled.

Impact: The SBC is sending out an Error-Info header in a 400 Bad Request even when the suppressErrorInfoHdr flag is enabled.

Root Cause: After the SBC restarts, the suppressErrorInfoHdr flag value is not updated correctly.

Steps to Replicate:

1. Enable the suppressErrorInfoHdr flag:
   --set global signaling sipSigControls suppressErrorInfoHdr enabled
2. Restart the SBC.
3. Send a Malformed INVITE from the UAC.
4. The SBC sends a 400 bad request in response to the malformed INVITE when the Error-Info header is eliminated.

The suppressErrorInfoHdr Flag value is updated properly after a restart.

Workaround: None.

Portfix SBX-115343: The SAM Process crashes during a 256,000 surrogate registration run on a SBC 5400 HA set up.

Impact: The SBX 5100 can support the surrogate registrations up to 110,000. When the number of surrogate registrations configured is more than the accepted limit, a SAM Process crash results.

Root Cause: There is no limit applied for a surrogate registration configuration based on the HW type.

Steps to Replicate: Configure more than 110,000 surrogate registrations in the SBC 5100 box.

The code is modified to apply limits for surrogate registration configurations based on the HW type.

Workaround: None.

Portfix SBX-114730: For AWS, errors related to the SD registration should be removed in case no values are provided during the SBC launch

Impact: While running the command sbcDiagnostic 2 shows the following errors on the AWS when no sdregistry servers are given in the configuration.
------------------
SBC Application Version: V10.01.00-R000********* Start Cloud SBC Diagnostic ***********
cloud-init service is active : ok
cps is initialized : okLCA is coming up. Please wait...
2021-11-23 23:55:19.799 LifeCycleAgent ERROR Error in SD.ConfigureBackends: Received empty registry in provided data - [{u'type': u'dns', u'servers': [u'']}]
2021-11-23 23:55:19.814 LifeCycleAgent ERROR Could not configure Service Discovery Representative: string indices must be integersLCA bringing-up SBC Application. Please wait...********* SBC Status ***********
---------------------

Root Cause: The JSON data is converted into unicode instead of a string when the meta data and user data load.

Steps to Replicate:

1. Launch the HFE HA SBC on the AWS using the 10.1 template.
2. Leave the EMS and SD Registry parameters blank in the template while launching. 

The code is modified to address the issue.

Workaround: None.

PortFix SBX-116842: Observed Major Logs (.MBS: .CCS .PsObjectFactoryManager: Failed to find object's prototype while operating on object ID 171553 (0x29e21)) on 5:1 setup during an MRFP 9.1R5 to 9.1R6 upgrade.

Impact: There are number of instances of the following log message in the .SYS log during an MRFP upgrade:

165 03092022 173545.777690:1.01.00.00434.MAJOR .MBS: .CCS .PsObjectFactoryManager: Failed to find object's prototype while operating on object ID 171553 (0x29e21)

Root Cause: Fault avalanche (FAC) logic was enabled by default on the MRFP, and FAC logic was sending some unexpected messages.

Steps to Replicate: 

1. Bring up 1:1 OAM and 5:1 MRFP setup in V09.01.00R005 Build : 423.
2. Perform the upgrade to build V09.01.00R006 Build: 461 using IaC.
3. Check the SYS logs for errors following the upgrade.

The code is modified to automatically disable fault avalanche on MRFP.

Workaround: None.

Application communication failure with the JSON CLI output format.

Impact: When user tries to format CLI output as JSON, may cause error "Application communication failure"

Root Cause: The issue is due to some tables that are deprecated/obsoleted many years back still have a confd call point and is causing the failure.

Steps to Replicate: Pipe the CLI output through display filter and ensure that appropriate information is retrieved. 

The code is modified to address the issue.

Workaround: Use 'xml' formatter instead of json.

The removeSavedConfig does not delete a saved config file unless 'show table system savedConfigList' is called beforehand.

Impact: The removeSavedConfig does not delete a saved config file unless 'show table system savedConfigList' is called beforehand.

Root Cause: When savedConfig and removeSavedConfig called one after the other, the internal list did not have the path to delete the file.

Steps to Replicate: 

1. Run the Saveconfig.
2. Run the removeSavedConfig.

The code is modified to update the internal list with path and file name.

Workaround: Before calling the removeSavedConfig, call the "show table system savedConfigList"

A pre-upgrade BMC version check has issues.

Impact: In an upgrade case, if the BMC is incompatible with app version, a pre- upgrade check should give a warning and complete the pre-upgrade checks. But the pre-upgrade is stopped with incompatible BMC version as a error.

Root Cause: In the pre-upgrade, the script incompatible BMC version set as error message and stopped pre-upgrade checks.

Steps to Replicate: Upgrade the app with an incompatible BMC version.

The code is modified to continue the pre-upgrade checks and set incompatible the BMC version as a warning.

Workaround: Upgrade the BMC to the required version.

Traps are not generated for Ingress and egress Packet loss when Packet loss action set to 'Trap' in both PSPs. 

Impact: Traps are not generated for Ingress and Egress Packet loss when Packet loss action set to 'Trap' for the SBC.

Root Cause: Packet loss reporting is disabled if a silence detection threshold of zero is specified along with setting the Packet loss action to 'Trap'.

Steps to Replicate: Set Packet loss action to 'Trap' with a silence detection threshold of zero. Verify that traps are generated for any packet loss.

The code is modified so that the packet loss reporting is not disabled if a silence detection threshold of zero is specified along with setting the Packet loss action to 'Trap'.

Workaround: Ensure that the specified silence threshold value is a non zero value.

The Metavar search is failing on OAM for different CLI's on different OAM nodes.

Impact: The metavar validation failed during automation.

Root Cause: The metavar validation failed during automation. This is a race-condition mainly when multiple CDB data queries are done.

Steps to Replicate: Run the metavar related configuration in automation. When running normal a CLI configuration, we do not see this race-condition.

The code is modified for the CDB, even if it was present.

Workaround: Manually fail the CLI command, as this is only observed during automation.

Egress congestion handling should only be enabled for the 503 with a retry.

Impact: The SBC was treating 503 with or without Retry-After header as peer overload scenario. But the SBC should only treat 503 responses with retry-after because those are unambiguously overload related.

Root Cause: The SBC was not verifying for the presence of Retry-After header to consider it as a peer overload scenario.

Steps to Replicate: Send a 503 with Retry-After header for a SIP INVITE.

The code is modified to address the issue.

Workaround: None.

The SBC init.d script checkForUpgradeRevert() file parsing is forgiving and can facilitate arbitrary command execution.

Impact: One of the scripts on the SBC has a security issue that in a particular scenario can cause potential privilege escalation from sonusadmin to root.

Root Cause: Script was running a marker content without input validation and location of marker was not secure.

Steps to Replicate: This code block gets executed only when an upgrade from version which has single debian root partition to three partition model. It is not applicable for any 6.0 or later installations.

The code modified to move the marker to a secure location owned by root and input validation is added in script as a added measure.

Workaround: No workaround.

An additional UPDATE is being triggered by the SBC when the server side sends 18x with Valid Video Port.

Impact: In a delayed tone play scenario, the SBC is sending an additional UPDATE when egress EP sends 18x with valid audio and video ports

Root Cause: The SBC completed an initial offer-answer in INV and 18x with valid Audio and Video ports.

Later, due to delayed tone play logic, the SBC started playing the tone. As part of this tone play activation, the SBC is trying to switch OFF the video stream by triggering an UPDATE with video port as zero. The 200 OK (for UPDATE) is causing the SBC to abort the tone which is not supposed to happen.

Steps to Replicate: 

1. UAC sends INVITE with Audio and Video.
2. UAS sends 183 with Audio and Video
3. The SBC starts playing tone due to delayed ring back tone configuration.
4. The SBC triggers an UPDATE with video port as zero towards ingress EP.
5. A 200 OK (for UPDATE) response makes the SBC abort the tone.

The code is modified so that the SBC does not stop the tone play upon receiving a 200 OK (for UPDATE) response from the ingress EP.

Workaround: None.

While expecting BYE, the SBC is sending an INVITE to egress side.

Impact: The SBC sending a re-INVITE with text stream disabled when the egress EP sends 200 OK with Audio stream alone.

Root Cause: Since, the egress EP sent 200 OK with only audio stream, SBC internally disables the text stream on both call legs that is resulting in triggering of a Re-INV with text stream disabled towards UAS side.

Steps to Replicate: 

1. UAC sends INVITE Audio + Text to the SBC.
2. SBC sends INVITE Audio + Text to UAS.
3. UAS sends 18x Audio + Text (port=0) to the SBC.
4. The SBC sends an INVITE to MRF server and MRF server responds back with valid Audio and Text Ports.
5. The SBC sends 18x Audio + Text to UAC.
6. UAS sends 200 OK Audio stream alone.

The code is modified so that if the peer already disables any media stream and if the SBC tries to trigger a re-INVITE towards the peer for disabling the same media stream, then suppress the triggering of the re-INVITE.

Workaround: None.

The NULL pointer passed as an argument, which is declared to never be NULL.

Impact: Call forking scenarios can access the NULL pointer while comparing Call ID information.

Root Cause: The behavior of performing a string comparison on a null pointer is undefined. It has not been seen to cause any customer issues to date.

Steps to Replicate: 

• The SBC should be configured to use ERE.
• All the required configuration to make a basic call should be done on SBC.
• Assuming three endpoints (or end devices) say PBX1, PBX2 and PBX3. All uses same number and are connected across different devices (PBX)
• Create VOIP subscriber and AoR group in the SBC.
• For example create AoR group with entries sip:2413338235@pbx1.sonusnet.com, tel:+91-xx-2413338236, tel:+91-xx-241333823 respectively.
• Attach AoR group to VOIP subscriber.
• Each route for a member of AoR in group is assigned with different egress IPTG/IP Peer and all the IP-Peers are configured with FQDN.
• Configure "Delay Before Call Attempt" to 50 seconds to the second number AOR2 tel:+91-80-2413338236 (PBX2).

Procedure:

1. Make a call from EP1 to a VOIP subscriber.
2. The SBC receives '100 Trying' for forked INVITE.
3. Answer the call from endpoint connected to AOR1 before 50 seconds.

The code is modified to check that the Call ID pointers are not NULL before performing a comparison on the contents to avoid any unexpected behavior.

Workaround: None.

The S-SBC is unable to send the UPDATE towards the UAS endpoint for 183 dialog-3 during EGRESS precondition interworking scenario.

Impact: The S-SBC is unable to send the UPDATE towards the UAS endpoint for 183 dialog-3.

Root Cause: When ingress was not supporting UPDATE, the SBC was trying to send out and stuck in this state.

Steps to Replicate: 

1. Send the initial INVITE message without precondition attributes.
2. The SBC sends the INVITE to UAS with precondition attributes.
3. Send a 183 dialog-1 from UAS with precondition attributes.
4. Before preconditions met for 183 dialog-1 , Send the 183 dialog-2
5. Once preconditions met for 183 dialog-1, Send the 183 dialog-3 after the 183 dialog-2(retransmission)
6. Now, the SBC process the 183 dialog-2 and send it UAC.
7. Before completing the preconditions for 183 dialog-2, send the 183 dialog-3 again from UAS (retransmission).
8. After preconditions met for 183 dialog-2, the SBC should dequeue the 183 dialog-3 and process it.
9. The SBC should generate UPDATE message for 183 dialog-3 and send to UAS.

The code is modified to locally answer the UPDATE when ingress peer does not allow UPDATE

Workaround: None

A call between Cisco EP and PSTN failed as the SBC is sending incorrect attribute value for Video port 0.

Impact: The SBC sends a=sendrecv instead of a=inactive when video stream is received with port 0.

Root Cause: When changes were made to support additional video parameters in 9.2.x release, the datapath mode WSA set to default(a=sendrecv) when video stream was marked as absent. This was causing the SBC to send a=sendrecv.

Steps to Replicate: 

1. Initiating call from Cisco phone to PSTN endpoint and PSTN sends back 180 Ringing.
2. The SBC added SDP in the 180 Ringing for LRBT and sent back to CUCM Cisco phone.
3. Ensure SBC added audio m line with valid IP and port, and for Video added port Zero with a=inactive.
4. Answering the call from PSTN phone.
5. Now ensure that POLYCOM phone is in CONNECTED state after answering call.
6. Media Validation for Call between PSTN user and Cisco User on Cisco Phone.

The code is modified to inactive when video stream is marked as absent when port 0 is received.

Workaround: No workaround.

The value set against GPU flag in /opt/sonus/conf/swe/capacityEstimates/.activeCallMixInput.json file is not an integer value" error message in DBG

Impact: On Managed N:1 MRFP node, when a custom CPU profile is applied, from OAM, by specifying the value against the useGPUForTranscoding field to false, following critical level message is logged in the .DBG file: 

" The value set against GPU flag in /opt/sonus/conf/swe/capacityEstimates/.activeCallMixInput.json file is not an integer value. "

This log does not indicate any issue with the the functionality of the profile activation.

Root Cause: On N:1 Managed MRFP node, the CDB gives the value against the filed useGPUForTranscoding as False(string), rather than 0(integer).

Application takes the value for the corresponding field as 0 by default, but a critical error message is logged in .DBG log.

Note: For the useGPUForTranscoding field value set to True, the corresponding logic was already in place, no issues in this scenario.

Steps to Replicate: For reproducing the issue on Managed N:1 MRFP, activate a traffic profile with useGPUForTranscoding value set to false, from the OAM, as shown below:

%set system sweTrafficProfiles VzW_callmix_profile useGPUForTranscoding false
%commit

% request system admin vsbcSystem saveAndActivate rebootSBCs true
%commit

All the N:1 MRFP nodes will go for a reboot and once the application comes up, observe the following logs in latest DBG logs:

" The value set against GPU flag in /opt/sonus/conf/swe/capacityEstimates/.activeCallMixInput.json file is not an integer value. "

The code is modified to address the issue.

Workaround: No workaround.

Note: The log does not indicate an error in the functionality of profile activation.

Deletion of a SMM Profile with 768 rules is failing.

Impact: Deletion of a SMM Profile with 768 rules is failing

Root Cause: There was a restriction of 1000 transactions per commit to avoid health check issues leading to failure while deleting SMM profile with large number of rules.

Steps to Replicate: Validate that deletion of SMM profile with 768 rule succeeds.

The code is modified as the operation was already being performed by disabling the healthcheck timeout for the duration of operation.

Workaround: No workaround.

There was a HDIO_DRIVE_CMD(identify) and NVMe Disk Issue.

Impact: Running a sysdump on AWS instance having NVMe disk was giving error as:
--------
Collecting OS information...
HDIO_DRIVE_CMD(identify) failed: Inappropriate ioctl for device
/bin/cat: /sys/block/nvme0n1: Is a directory
--------

Root Cause: The primary_disk variable added with new line character that was producing the error in cat command.

Steps to Replicate: Spawn a SA instance on AWS using cloud Formation template.

Run "sbcDiagnostic.sh 2 " command to collect the sysdump on AWS.

Trimmed the new line character from primary_disk variable to address the issue.

Workaround: No workaround.

Serf Logs and Upgrade marker files are missing from sysDump.

Impact: Serf logs and upgrade marker files were missing from sysDump.

Root Cause: Capturing only specific log files without * regex.

Steps to Replicate: Run sysDump.pl script.

The code is modified to capture all the files including rolled over files.

Workaround: No workaround.

There are GW message parameter sending issues.

Impact: The calls that arrived at the SBC with m=text SDP content and are routed to a GSX via GW-GW can be released with disconnect reason CPC_DISC_GW_GW_MSG_PDU_TOO_LONG_FOR_PEER(0xD6) due to the GW-GW message being too large for the GSX to handle.

Root Cause: The SBC was sending parameters to the GSX that the GSX could not use and this was making the GW-GW PDU message larger than the GSX could process.

Steps to Replicate: 

Make a call with m=audio and m=text in the SDP of the INVITE and try to route over GW-GW to a GSX. Check the call is successful.

The following control should be enabled:

set global signaling oldGsxSupport enabled

The code is modified to delete certain parameters that are not required on the GSX to reduce the GW-GW PDU size and avoid calls being released because the PDU is too big.

Workaround: Use SMM to delete m=text SDP content coming into the SBX which is potentially routed over GW-GW to a GSX.

SIPREC: A SIPREC recording failed for REFER call on a D-SBC setup.

Impact: SIP recording sessions fail on a D-SBC setup, when the CS call goes through a call transfer scenario and the recording session is to be required on the new leg.

Root Cause: The SIPREC on a D-SBC for call transfer scenarios was not supported.

Steps to Replicate: 

1. Enable SIPREC feature with egress leg recording.
2. Run a CS with call transfer scenario and initiate a transfer from B leg.
   (blind or attended transfer).

The code is modified to support SIPREC on the D-SBC for call transfer scenarios.

Workaround: None.

The SBC is not sending SDP offer in outgoing INVITE with all the codecs that are configured in PSP.

Impact: The SBC is not sending out INVITE with all configured codecs (passthru + transcodable) when Audio + Text is received.

Root Cause: The issue only occurs when the D-SBC ( S/M/T ) set up receives an INVITE from Ingress peer with Audio and T.140 stream.

During offer processing, the SBC was checking the transcode capabilities for both Audio and text stream, causing this issue.

Steps to Replicate: 

1. Configure multiple codecs in Ingress and Egress PSPs.
2. Send multiple codecs in INVITE from Ingress Peer. (Audio + Text )
3. The SBC should sent all passthru and transcodable codecs configured in the PSP to Egress Peer.

The code is modified to address the issue.

Workaround: None.

Need to update the script to properly do the zip CSAR for SOL3 deployment.

Impact: On boarding, the CSAR zip in the SOL3 deployment fails.

Root Cause: While zipping with CSAR with python script, it compresses both folders and their files. The unzipping in VNFM expects only the compression of files not the folders.

Steps to Replicate: Test the CSAR created in SOL3 deployment.

Fix is given to pack folders without compress, but compress only files.

Workaround: Unzip the CSAR and re-zip with Linux zip utility.

The SBC is not sending Re-INVITE towards Egress side.

Impact: On the D-SBC, there was a memory leak in the cluster transcoding capability during UPDATE with preconditions call flow.

Root Cause: On the D-SBC, the reference to cluster transcoding capability held in the current working PSP context was being lost, and as a result was leading to memory leak.

Steps to Replicate: 

1. Run a G711-G711 transcoded call that should transition to fax, after fax tone detection.

The D-SBC would fail to send the re-INVITE to transition to fax.

The code is modified to avoid losing a reference to the current working PSP context cluster transcoding capability memory, by saving it to the pending ACK PSP context and ensuring to free this memory during the offer answer processing.

Workaround: No workaround.

The SBC Dialog scope variable (New Header) not present after an SMM reject.

Impact: The SBC SMM has rule to add the Dialog scope variable as new Header in response. But the new header is not getting added.

Root Cause: The SMM rule has SMM reject operation followed by another rule with adding a dialog scope variable value in new header. When reject operation is performed, the dialog scope variable is deleted. As a result, this produces the issue. 

Steps to Replicate: 

1. Create a SMM profile with rules, storing dialog stateful variable, reject operation and adding dialog stateful variable in new header.
2. Make a call.

The code is modified to remove the dialog scope variables while applying a reject operation.

Workaround: None.

Observed a heap-buffer-overflow on address 0x6260000bf802 at pc 0x56063d63cca4 bp 0x7fe633ce2b00 sp 0x7fe633ce2af8.

Impact: A heap-buffer-overflow is observed when Option header with too many spaces or tab is received.

Root Cause: When too many space are inserted after Option header.

Pdullen is calculated wrongly and include all the spaces also so while doing pre parsing pdulen reaches beyond PDU and leads to coredump.

Steps to Replicate: Send option Message with large no spaces or tab such as: 
OPTIONS \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \tsip:9611912691@10.xx.yy.zzz:7050 SIP/2.0

The code is modified to change the startIndex so that it points to Offset Length that is equivalent to the Header length.

Now while calculating the PDU length, it is taken from Offset. With these changes, all spaces are taken into consideration and the length is correct.

Workaround: None. 

The SBC is sending multiple Update requests towards the Egress when DLRBT is enabled.

Impact: The SBC is sending multiple Update requests towards Egress when DLRBT is enabled.

Root Cause: When Ingress leg does not support PRACK and egress leg support PRACK and update IENT toward ingress is locally answered due to codec mismatch between Peer PSP and PeerPSP Sent, the SBC is triggering an UPDATE towards egress.

Steps to Replicate: 

1. Ingress sends a Invite request with 0,8.
2. Egress sends 183 response reliably.
3. Egress sends 2 subsequent Update requests with 8 with O line having same number.
4. Egress sends 180 ringing with increased O line SDP.
5. Egress sends 2 subsequent Update requests with 8 with O line having same number (increased O line than 180 SDP).
6. The SBC sends lockdown invite to egress.
7. Egress responds with a 200Ok.

Expected Results: The SBC should not core and process all the update requests.

The code is modified to copy PeerPsp in PeerPspSent so that both are same in this specific scenario. As a result, this does not trigger an update towards egress.

Workaround: None.

A call between CUCM EP and PSTN failed as the SBC is adding additional codecs that are not configured during 18x LRBT play.

Impact: The SBC sending all codecs received in the initial INVITE, in the 18x LRBT play.

Root Cause: The root cause for this issue is, when TFT and Audio Transparency is enabled, the SBC uses the codec in NSD, during tone play rather from PSP.

As part of multi-audio and other bug fixes, the NSD generation for tone Play changed, which is causing this issue.

Steps to Replicate: 

1. Configure the SBC for A-B call with Tone.
   Enable transcoderFressTransparency and seectiveSdpRelay flag.
2. Send multiple codecs in INVITE from UAC.
3. The SBC should send an INVITE out and should receive 18x from UAS.
4. The SBC should play tone with whatever codec that is configured in the PSP.

The code is modified so when the TFT and Audio Transparency is enabled, the SBC uses the older way to generate the codecs.

Workaround: None.

An unexpected re-INVITE from the SBC towards UAS (Egress Leg)

Impact: Unexpected Re-invite from SBC towards UAS (Egress Leg)

Root Cause: The issue here is that, the uchRelaxSdpChange flag is not getting RESET after the SBC sent UPDATE to UAS. Due to this, after receiving a 200 OK (for UPDATE) from UAS, the SBC is triggering another UPDATE towards UAS.

Steps to Replicate:

1. Make an audio call from UAC.
2. Upgrade the audio call to video call.
3. Now, downgrade the call again to audio.

Reset the uchRelaxSdpChange flag after the SBC sends an UPDATE to UAS to address the issue.

Workaround: None.

Observed a leak for the subscribe flow.

Impact: When running a subscribe 401 call flow memory leak is found "48 bytes in 1 blocks are definitely lost".

Root Cause: cpcZoneNamePtr was not freed properly in the Error condition

Steps to Replicate: 

1. Run the Valgrind.
2. Make a subscribe call. 
3. Send 401 response to subscribe. 
4. Capture the Valgrind memory leak and check if any block of memory is lost.

The code is modified to free cpcZoneNamePtr in the Error condition and also for different error scenarios.

Workaround: None.

An SCM coredump is observed after local response of a 200OK for UPDATE received from UAC

Impact: An SCM coredump is observed after a local response of 200OK for UPDATE received from UAC

Root Cause: After a second Update with sendonly is received from UAC, the SBC aborts the tone and the CC attempts to do cutthru. 

When NRMA tries to activate resource while doing cutthru, a coredump occurs since no answer is received from the UAS. 

Steps to Replicate: 

1. Run the following on the ingress IPSP:
   disableMediaLockDown enable
relayDataPathModeChangeFromOtherCallLeg enable
minimizeRelayingOfMediaChangesFromOtherCallLegAll enable
sendOnlyPreferredCodec enable
alwaysReplyInactiveIfReceivedInactive enabled
2. On the Egress IPSP:
   disableMediaLockDown enable
relayDataPathModeChangeFromOtherCallLeg disable
minimizeRelayingOfMediaChangesFromOtherCallLegAll enable
mapDpmToSendrecvForInitialDialog enable
3. Send an initial INVITE from UAC with a=inactive.
4. Send the first UPDATE with a=sendonly.
5. Send the second UPDATE with a=sendonly.
6. Send an 200OK INVITE from UAS.

When an Update is received instead of abort tone and cutthru, the SBC swaps the tone resource with the new codec to address the issue.

Workaround: None. 

Portfix SBX-114693: Need to Update all the Application code to set the V6 loopback address.

Impact: The SBC fails to identify an address as loopback address for an IPV6 call

Root Cause: New feature that was added in the 10.1 release exposes this issue.

Steps to Replicate: Run a NATed call from IPV6 end point.

The call must be established successfully and media should flow from EP1 to EP2 through the SBC.

The code is modified so that the SBC identifies the loopback address for an IPV6 call correctly.

Workaround: None.

EMA: Terminate call is not working from EMA

Impact: Terminate call command is failing from EMA

Root Cause: When terminate call operation is performed, the terminate call xpath is encoded by the UI and sent to the backend. The backend, however was not decoding the xpath due to which the operation was failing.

Steps to Replicate:

1. Run a long duration call (approximately for two mins or more).
2. Log in to EMA and go to All->Address Context ->Call Media Status Detail and note the GCID.
3. Click on All->Global and from commands, drop down select Terminate Call and give the value of GCID in the popup.
4. Click on terminateCall.

The call should get terminated

The code is modified to decode the xpath in the backend.

Workaround: No workaround.

Number Translation criteria was not appearing after importing the file that contains number translation criteria.

Impact: Number Translation criteria was not appearing after importing the file that contains number translation criteria.

Root Cause: This issue is caused by a feature code check-in, in the SBC release 9.2.3.

Steps to Replicate: 

1. Log into the PM.
2. Navigate to Administration --> System Administration --> Profile Import/Export.
3. Click on Export Profile button.
4. Provide a File Name and Select the Type "Number Translation Criteria".
5. Check if all instances of that profile are listed.
6. Select an instance of the profile.
7. Click on the Export button.
8. Delete the profile from Number Translation Criteria.
9. Import the exported file that contains the Number Translation Criteria.

Expected Results: The number translation criteria should appear after the import.

Observed Issue: The number translation criteria is not appearing after the import.

The code is removed from all occurrences policy/SBXPIPE/SbxNumberTranslationCriteriaEntity.cpp

tfpem.serviceDmPmRuleIb.setData((char *)CONFD_GET_BUFPTR(key));
tfpem.serviceDmPmRuleIb.setDataNull(GUISVR_BOOL_FALSE);
tfpem.serviceDmPmRuleIb.setLoaded(GUISVR_BOOL_TRUE);

Workaround: No workaround.

Enabled a full GPU coredump support.

Impact: The full coredump collection with large GPU memory foot print fails.

Root Cause: There were two root causes:

1. When a GPU software failure occurred, the GPU driver would sometimes hang instead of detecting a failure and reading data from the GPU memory.
2. The current coredump timeout value for collecting GPU core-dump was inadequate.

Steps to Replicate: The steps cannot be reproduced.

The code is modified to:

1. The latest version resolving the hang issue that sometimes occurred when detecting a GPU software failure.
2. Increase the timeout value to a safe value of 500 seconds based on testing.

Workaround: None.

Failed to create a surrogateRegistrationProfile.

Impact: Failed to create a surrogateRegistrationProfile.

admin@CESBX148% set profiles services surrogateRegistrationProfile prof1 aorUserName 9482520019 aorState enabled
[ok][2022-03-17 10:17:25][edit]
admin@CESBX148% com
Aborted: 'profiles services surrogateRegistrationProfile prof1 aorUserName': Max surrreg count reached...!
[error][2022-03-17 10:17:26][edit]

Root Cause: The max count for the surrogate registration entries was incorrectly initialized to 0, which prevented a configuration from being applied.

Steps to Replicate: Configure entries in the surrogateRegistrationProfile and check that the configuration is applied successfully.

admin@CESBX148% set profiles services surrogateRegistrationProfile prof1 aorUserName 9482520019 aorState enabled
[ok][2022-03-17 10:17:25][edit]
admin@CESBX148% comm

The code is modified to correctly initialize the maximum number of surrogate registration entries that can be configured to 25600.

Workaround: None.

The Holiday profile export was failing with an instance not specified error, even though the instance was selected.

Impact: While exporting a Profile type Holiday with selected, the profile instance threw an error saying profileinstance is not selected and the profileinstance list should be in format like "1,january,22" but displayed like "1".

Root Cause: The code fix in a fix introduced in release 10.1.1 is the root cause. 

Steps to Replicate: Install the fix build and check whether it lists in format "1,january,22" in profileInstance dropdown for profileType holiday in the EMA UI.

Reverted back the changes made in a fix for release 10.1.1, which displays only the profile Instance name in both EMA and CLI. 

Workaround: None.

AddressSanitizer: stack-buffer-overflow on address 0x7febefa8f200.

Impact: There is stack-buffer-overflow issue in the SBCPIPE, and due to this issue, it is unable to append new string to the variable.

Root Cause: The character array has not initialized to NULL, which leads to a memory overlap.
char sucscriberData[256];

Steps to Replicate: The steps cannot be reproduced.

The code is modified to address the issue.

Workaround: None.