SBC Core 09.02.01R003 Release Notes

Portfix SBX-107397: There was an SBC switchover DEADLOCK detected for sysID 62, task SIPSG.

Impact: An SIP call load can trigger a healthcheck timeout in the SIPSG module.

Root Cause: The problem was with the flags that is used for creation of shared memory between SCM process and fault avalanche handler process. As a result of incorrect setting of flags some of the writes to the shared memory was taking more time resulting in the SCM thread getting blocked and health check timeout.

Steps to Replicate: 

1. Run a 50 cps SIP-SIP call load for an extended period of time.
2. Ensure that the fault avalanche control feature is turned on.

"show system faultAvalancheControl facState" should be enabled.

The code is modified to disable fault avalanche control functionality by default.

Workaround: Disable the Fault Avalance control functionality using the following configuration control.

set system faultAvalancheControl facState disabled

The SBC SWe crashes when making a video call with a certain type of phone. 

Impact: The SBC SWe NP crashes when IPsec fragmented signaling packets scenario calls made by using IPsec crypto as NULL encryption.

Root Cause: During the IPsec crypto null processing of fragments (chained mbuf segments) by the SWe NP, an incorrect first segment length corrupted adjacent buffers, which resulted in a crash of the SBC SWe.

Steps to Replicate: Establish IPsec session with null encryption and make calls.

The code is modified to address the issue. 

Workaround: Use IPsec non-null encryption suites such AES/3DES.

The SBC/GSX fail to decode trigger response received from the PSX and leads to call failure.

Impact: Call failures are seen at the SBC when the STI Service is executed for a Trigger Request on the PSX.

Root Cause: For a two-staged call, the SBC performs a trigger request following an initial policy request to the PSX. If any STI service like signing or verification is executed for this trigger request, the SBC fails to decode a trigger response received from the PSX and leads to a call failure.

Compiled diameter Read methods for STI AVPs that are executed on the GSX and SBC are incorrectly looking for TRG_REQ (trigger request) tag while decoding TRG_RESP (trigger response), which is leading to decode errors on the GSX/SBC and resulting in a call failure.

Steps to Replicate: 

1. Perform a two stage call flow with the STI service enabled.
2. Ensure that the SBC sends a trigger request to the PSX for a two stage call call flow and perform the STI service.
3. Observe that there are no diameter decode errors on the SBC that can lead to a call failure.

The code is modified to look for the correct TRG_RESP tag. The SBC builds updates to use new diameter read methods.

Note: This fix only stops the DIAMETER decoding errors and a further fix is being tracked under another JIRA for a future release to have the SBC pass STI information in the trigger request, as well as process the information in the trigger response to STI service works in conjunction with 2-stage calls.

Workaround: As a workaround, STI service escapes for a trigger request.

Portfix SBX-109013: Increase the healthcheck interval.

Impact: Coredumps are occasionally seen in the field due to the health check timer expiring when the process gets stuck.

Root Cause: In SWe environments, disk/CPU timing issues can lead to the process slowing down and hitting these health check issues.

Steps to Replicate: This issue was only reproduced using debug code.

The code is modified to be more forgiving to cope with short spikes. The health check ping interval is now 2 seconds and must have 15 consecutive non responses in order for the process to be declared deadlocked and a coredump initiated to recover.

Workaround: None.

Portfix SBX-109153: DTLS: A 503 Service Unavailable with GCM Ciphers.

Impact: The following ciphers could not be used with DTLS:

1. ECDHE_RSA_WITH_AES_128_GCM_SHA256
2. ECDHE_RSA_WITH_AES_256_GCM_SHA384
3. RSA_WTIH_AES_128_GCM_SHA256
4. RSA_WITH_AES_256_GCM_SHA384
5. ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

Root Cause: The TLS profile had been updated with additional ciphers listed below but the DTLS code was not updated to support these.

Steps to Replicate: Use aDTLS client that support these ciphers make a connection to the SBC.

The code is modified to include support for these ciphers.

Workaround: None.

D-SBC: The calling party cannot hear disconnect treatment announcement if M-SBC is a N:1 cluster.

Impact: The connection IP is not updated when a different M-SBC is selected in clustered D-SBC deployment during disconnect treatment. The SBC was using the old connection IP which was causing the Ingress Peer endpoint not being able to hear the Disconnect Announcement.

Root Cause: The newly allocated M-SBC media IP during Disconnect Treatment is not used by NRMA due to incorrect validation check and the previous one is used which caused the one way audio issue.

Steps to Replicate: 

1. Configure Disconnect Tone Treatment in the SBC with an M-SBC cluster.
2. From the Ingress endpoint, send SIP INVITE to the SBC.
3. From Egress side send SIP 404 USER NOT FOUND in response to the INVITE.
4. Ensure Ingress side endpoint hears "Disconnect Tone TreatMent".

The code is modified to not use the newly allocated M-SBC media IP during Disconnect Treatment by the NRMA (due to incorrect validation check), and instead use the previous treatment that caused the one-way audio issue. 

Workaround: None.

A call hold from both ends causes a re-INVITE handling issue.

Impact: Call Holds received from both ends results in a re-INVITE handling issue.

Root Cause: UserA to UserB call is connected. UserA puts call on hold. Later, UserA triggers a latemedia re-INVITE, and the SBC sends 2xx with offer SDP with a=sendrecv, the local dpm mode changes to sendrecv. The ACK received from UserA with a=inactive. call is still on hold.

When userB also initiates the hold (ie., hold from other direction), it should be relayed to UserA. But the SBC not relaying the re-INVITE. Due to improper late media re-INVITE handling, the SBC media state changed, which blocks the relaying of hold re-INVITE from other direction.

Steps to Replicate: 

1. UserA to UserB call is connected.
2. UserA puts call on hold.
3. UserA triggers latemedia re-INVITE, the SBC sends 2xx with offer sdp with a=sendrecv. The ACK received from UserA with a=inactive.
4. UserB sends re-INVITE to put call on hold (ie., hold from other direction).
5. Nothing will be sent to UserA.

The code is modified to relay the hold re-INVITE from the other direction.

Workaround: None.

Portfix SBX-109465: The Leadership algorithm workaround for the openclovis issue can cause a core dump.

Impact: The safplus_gms process crashes when coming out of split brain.

Root Cause: Incorrect/inconsistent data results in the code asserting.

Steps to Replicate: This issue is not easily reproducible and is caused by HA link instability/flapping.

The code is modified so that the data is consistent.

Workaround: Run HA link stability.

Portfix SBX-109893: The SBC frequently switches over 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.
The fix is to add a check for NULL before attempting de-reference the pointer.

Root Cause: The root cause is that 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: 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 check for NULL before attempting de-reference the pointer.

Workaround: The only known workaround is to disable the STI.

A registration issue with a switchover case.

Impact: Security Mechanism of Registration is set to the TLS in the RCB with two different scenarios. The scenarios are of basic registration, which does not have any security profile.

Root Cause: Cause is when Reconstruction of RCB happens during switchover by default security is set to TLS without verifying Digest structure. Also whenever the Digest structure is deleted for any reason the code is not setting security back to NONE.

Steps to Replicate: Test requires a HA setup.

Scenario 1:

1. In Active Node make a successful registration. Send a Fake registration such that it gets rejected with 403 error from server side.
2. Now perform a switchover and when standby node becomes active make another fake registration that gets rejected by 403 again.
3. Verify the Security Mechanism in CLI using "show status addressContext default sipActiveRegisterNameStatus" and also try to make a call.

Scenario2: (This is for pre-present TLS security before upgrade)

1. In Active node, make a successful registration with response code other than 200 ex: 202 Accepted. [send 202 instead of 200 in server script]
2. Now, send a refresh register, it will be internally rejected with 403 from the SBC. In logs, you will see these statements "invalid state auth-rcvd" and "Refresh register did not meet security requirements". If you verify the security Mechanism it should show TLS.
3. Upgrade the Standby node to 824R2 build. Perform a switchover and send a refresh register to verify the CLI for security mechanism if set to NONE. Try making a call or send a refresh register again both should be successful.

The code is modified so when RCB reconstruction occurs, it verifies the Digest structure whether to set security to TLS or NONE based of the DigestWithoutTLS variable. Whenever the Digest structure is deleted for any reason, the code sets security back to NONE.

Workaround: Try performing switchover twice.

Portfix SBX-109083: The SCM process core dumps during a SipSgAORHashRemove.

Impact: The SCM Process core dumps due to an entry corruption in the Registration hash table post switchover. This corruption is rare and occurs infrequently.

Root Cause: The result below is likely to core as a result of the core dump and SYS error logs.

The corrupted AOR entry in hash table was allocated during the reconstruction for an Active RCB from standby context after switchover. The SYS Err logs indicate the presence of duplicate AOR entry. This could potential lead to corruption.

Steps to Replicate: 

1. Run a Basic Registration test with switchover.
2. Test with application server sending more than one P-Associated URIs.

The code is modified to ensure that only one AOR entry exists in the hash table after a switchover on the Active SBC's cache.

If the AOR entry is not found during remove operation, manually remove the entry to avoid the corruption later.

Workaround: None.

The AWS IPs remain assigned to the standby SBC, causing unnecessary dual restarts.

Impact: If the communication between the active and standby is broken (over ha0 interface), both assume active roles (split brain). When this occurs, the standby node that becomes active, calls AWS APIs to move IP address to self. Once ha0 link is restored, the machine, which becomes active, does not call AWS API to move IP addresses, this might cause an issue when the node that has IP does not come up as active, in this case IPs are assigned on standby and another node becomes active.

Root Cause: The root cause of this issue is not calling a AWS switchover API (move IPs) during split brain recovery.

Steps to Replicate: Run a split brain test and recovery of SBC HA, and verify that API query is send by the active SBC after 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.

Portfix SBX-70800: Observing that the metaVariable table is getting modified on loading the backup configuration 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 alone 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: 

1. Create a backup configuration of one cloud instance (instance1).
2. Loaded the backup configuration file into a new cloud instance (instance2).
3. Check the metaVariables table and see if it contains the metavars from both instances.

The code is modified to flush the metavars for the existing instance prior to loading the configuration from another instance.

Workaround: None.

Portfix SBX-109694: The /node/actualCeName is not updated with new name when there is a change.

Impact: If a cloud instance is completely rebuilt with a new HA IP value and actualCeName, the new actualCeName is not getting updated into the CDB. The CDB is left with the original actualCeName value. This leads to the SBC being unable to process the new configuration data as it is still trying to read the metavar information based on the original actualCeName value. This in turn leads to the SBC application being unable to start.

This problem happens when the textual part of the actualCeName matches but the IP address is different.

Root Cause: The code was only using the textual part of the name to check if the data in CDB already existed and was not updating the full actualCeName if there was a match on the textual part of the name.

Steps to Replicate: 

1. Rebuilt a cloud instance using the same node name but new IP address and then try to apply this configuration to an instance that is already up and running with the same node name.
2. Check that the SBC application is up and running following the application of the new configuration.

The code is modified to correctly update the actualCeName, even if the node name (textual part of the name) already exists in the CDB.

Workaround: None.

Portfix SBX-108173: The openclovis split-brain recovery data was not always correct.

Impact: On recovery from 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 that 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 (through logs) and one node will properly restart to again become standby.

The code is modified so that the "isLeader" field is properly set and the leader election algorithm can properly detect we are coming out of split brain.

Workaround: None.

The SBC continuously core dumps for 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.

There was call failures observed on T140 load with various MAJOR logs in DBG.

Impact: Call fails due to RID Enable errors. (where RID = receiver ID and is mapped to an allocated resource)
DBG log shows many BrmAsnycnCmdErrHdlr logs with cmd 0x30 (RID Enable):
MAJOR .BRM: *BrmAsyncCmdErrHdlr: ERROR NpMediaIntf cmd 0x30 gcid 0x2128915e

Root Cause: When RTCP Generation is disabled, RTCP RID for the call is expected to be disabled by Network Processor (NP).

With introduction of SBX-86241 Streaming RTCP packets to Protect Server, there is now a case where RTCP Generation is enabled to stream RTCP packets to Protect Server but RTCP packets are not generated for the call and RTCP RID for the call is not enabled.

When RTCP Generation is disabled NP uses rtcpMode=RTCP Terminate to indicate RTCP RID needs to be disabled.
This is incorrect, since rtcpMode=RTCP Relay Monitor also has RTCP RID enabled and NP is expected to disable the RTCP RID.

If a call has rtcpMode=RTCP Relay Monitor and RTCP Generation is disabled, leak this particular RTCP RID resource.

The next time the particular RTCP RID is allocated, the NP returns an error indicating RTCP RID is already allocated.

Steps to Replicate: 

1. Enable the Packet Service Profile //Resources/profiles/media/packetServiceProfile/rtcpOptions/generateRtcpForT140IfNotReceivedFromOtherLeg.
2. On the SBC, set //System/media/mediaRtcpControl/t140RtcpMonitorInterval to 20 seconds.
3. Start a T140 call but do not send RTCP packet. Terminate the call in 10 seconds.
4. If you keep making this type of call, you will eventually see the Enable RID error. The DBG log will have the BrmAsynCmdErrHdlr entry.

The code is modified so that the BRM indicates the RTCP RID needs to be disabled or not. When the NP receives the command, it uses this new parameter to decide if RTCP RID should be disabled or not.

Workaround: Disable the RTCP and disable RTCP termination.

A call outage led to DSP errors.

Impact: The call fails due to the RID Enable errors.

The DBG log shows many BrmAsnycnCmdErrHdlr logs with cmd 0x30 (RID Enable):
MAJOR .BRM: *BrmAsyncCmdErrHdlr: ERROR NpMediaIntf cmd 0x30 gcid 0x2128915e

Root Cause: 

1. A defect was found in the XRM redundancy processing code where xres->options field was not updated on the standby XRM.
2. When modifying a media flow in NP if RTCP relay monitor is being modified, the XRM did not provide rtcpMode in the media flow modify command. And NP is assuming the RTCP relay monitor is enabled by default.

Steps to Replicate: Test with calls that use RTCP terminations and will set rtcp-xr-relay-drop to TRUE.

When processing media flow modify request, the code is modified to set the RTCP relay monitor state based on the value in NP_MEDIA_RTCP_REL_MON_STR.

Workaround: Disable RTCP and RTCP termination in the PSP.

Portfix SBX-101155: A DSP coredump occurred on the SBC.

Impact: The DSP faults with a memory fault in area that pulls buffers out of EMAC port. Suspicion is on buffer size which is reported by EMAC buffer. These errors result in a DSP reload, which is essentially ensures call continuation. Any calls which are using this DSP could have a small media outage while the DSP is reloaded.

Root Cause: Root cause is a speculation that EMAC system is occasionally is a incorrect bufSize, similar to a bit flip.

Steps to Replicate: This issue cannot be reproduced, it has been fixed based on code review and coredump backtrace analysis.

The code is modified to look for consistency in packet size and EMAC buffer size reported. In case an inconsistency is found, the packet is rejected, avoiding illegal memory access.

Workaround: There is no workaround.

PortFix SBX-104334: Call Drop when being placed on hold - IPv6.

Impact: The "anonymous.invalid" in IPv6 media is not considered as as a call hold, and is rejected.

Root Cause: There is no handling for "anonymous.invalid" while handling calls on hold.

Steps to Replicate:

1. Establish a normal IPv6 media call.
2. Send a reInvite with "anonymous.invalid" in the c line of the media.
3. Check that the reInvite is not rejected and handled as call hold.

Check for "anonymous.invalid" and if present, consider it as call hold and avoid going for DNS resolution.

Workaround: Use the SMM to modify "anonymous.invalid" to "::" on the incoming side.

PortFix SBX-106452: The Standby SBC SWe on AWS is not coming up.

Impact: There are hard-coded references to the admin user in SBC LCA code whereby if the admin user is removed, bringing up the SBC may fail on virtual platforms.

Root Cause: The lack of exception handling to account for admin user usage caused the startup process to error out.

Steps to Replicate: Create a new Administrator user from CLI/EMA on the Cloud SBC and delete default admin user.
Reboot the SBC to check if the SBC comes back up as active or standby.

The code is modified to address the issue.

Workaround: Follow the MOP:

1. From Active's CLI: Create another Administrator user (e.g. newadmin)

CLI commands:
set oam localAuth user emsadmin accountRemovalState disabled
set oam localAuth user emsadmin passwordAgingState disabled accountAgingState disabled
set oam localAuth user newadmin group Administrator

2. From the Active's CLI, delete emsadmin user.

CLI commands:
delete oam localAuth user emsadmin

3. From shell of both instances, create admin user:

Shell command:
useradd -p Sonus@123 -G Confd,sftponly,upload,Administrator -s /bin/sh -d /home/sftproot/Administrator/admin admin

4. Reboot the standby instance.

5. Delete the admin user and group from both instances using shell command.

Shell commands:
userdel admin
groupdel admin

6. Login as 'newadmin' user and add 'admin' user

CLI commands:
set oam localAuth user newadmin accountRemovalState disabled
set oam localAuth user newadmin passwordAgingState disabled accountAgingState disabled
set oam localAuth user admin group Administrator
set oam localAuth user admin passwordLoginSupport disabled passwordAgingState disabled accountAgingState disabled accountRemovalState disabled
commit
request oam localAuth userStatus admin setRsaKey keyName adminKey rsaKey "<YOUR-PUBLIC-KEY-HERE>”

Execute the shell command below on both boxes to reset keep admin user value in cdb.

/opt/sonus/sbx/tailf/bin/confd_cmd -o -c "set /SYS:system/admin[0]/sftpUserPassword/keepAdminUser true"

7. Now, the admin user present in /etc/passwd file of both instances.

PortFix SBX-106175: An SBC 5400 post upgrade to 9.1, the SMM rule for options stopped working.

Impact: The SMM rules were not applied after an upgrade to 9.1.

Root Cause: The logic was modified to pick the same TG for request and response. In the Options ping scenario, request and respond with defaultiptg.

Steps to Replicate: 

1. Upgrade from 8.1 to any later release.
2. Attach the SMM at zone.

The code is modified to address the issue.

Workaround: NA

PortFix SBX-105961: The SBC reInvite with sendonly was causing a one-way audio.

Impact: The SBC unexpectedly sends out a 'reInvite sendonly' when the relay DPM is disabled.

Root Cause: Internal logical error to queue the SDP on ingress when egress send 18x (sendonly).

Steps to Replicate: Enable minimize and disable relay DPM on ingress.
A call B, B answer 183 (sendrecv), 183 (sendonly), 183 (sendrecv)...200 (sendrecv)

The code is modified so when subsequent 183 (sendonly) received on egress, the SBC updates the queue sdp (recvonly). Since the relay DPM is disabled, the SBC does not change the direction of datapath on ingress.

Workaround: n/a. This is an application bug per rfc, and the SDP should not change in subsequent 18x.

PortFix SBX-106178: There was a switchover // sonusCpSystemProcessCoredumpGeneratedNotification.

Impact: The SCM process has cored.

Root Cause: The SCM has cored when attempting to write a log message because the code is attempting to de-reference a NULL pointer to access information for the log message.

Steps to Replicate: There are no specific steps for reproducing this issue. This core will only occur in a multi-transfer scenario.

The code is modified to check that the pointer is non-NULL before de-referencing it.

Workaround: There is no workaround. This core will only occur in a multi-transfer scenario.

PortFix SBX-106611: The SBC sends a BYE message within dialog sometimes.

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 late media re-INVITE on other leg, the SBC clears the call.

Root Cause: The internal offer answer state of call at the SBC SIP subsystem becomes invalid.

Steps to Replicate: Config:
minimizeRelayingOfMediaChangesFromOtherCallLegAll enabled.
lateMediaSupport --> passthru
E2E Ack Enabled.
Egress PSP crypto and SRTP Enabled.

Call Flow:
Ingress ( RTP ), Egress ( RTP ).

1. After call is connected, the SBC triggers internal re-INVITE to egress with one crypto.
2. At the same time , Ingress peer sends late media re-INVITE.
3. LateMedia will get queued up and processed after internal reinvite.
4. But as SBC receives 200OK from egress , it generates 200OK to ingress as a response to late media re-INVITE from ingress.

This is wrong. The SBC also sends re-INVITE to egress ( late media ).
Due to this internal state gets messed up and after receiving ACK with SDP from Ingress, the SBC clears up the call.

With a fix, verified that the SBC correctly sends 491 Request Pending to ingress when handling internal re-INVITE transaction on egress leg.

When the SBC receives another late media re-INVITE on ingress leg , 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 the ingress peer send another late media re-INVITE it is sent to egress leg correctly and offer answer transaction succeeds for this second re-INVITE.

Workaround: Suppress the internal re-INVITE on egress leg.

PortFix SBX-106691: Adding IPSP fails with the application error.

Impact: Adding IPSP fails with application error when ipSignalingProfile destinationTrunkGroupOptions is includeDtg, but the error message is not descriptive.

Root Cause: ERE validates to ensure the check box 'Include DTG' is not selected in the IP signaling profile. The validation was done guiserver but error message was not set and return for why instead of meaningful error message, a very generic error message was coming.

Steps to Replicate: admin@SBXPLTF1H% set addressContext ADDR_CONTEXT_1 zone ZONE_IAD sipTrunkGroup TG_SIPART_IAD policy signaling ipSignalingProfile AANN
[ok][2021-02-02 19:22:08]

[edit]
admin@SBXPLTF1H% co
Aborted: 'sipServiceGroupExt TG_SIPART_IAD ipSignalingProfile': IP Signaling Profile Id 'AANN' cannot be assigned as it is DTG(Destination TrunkGroup) option is selected.

The code is modified to set the error message and and return to provide error message during configurations.

Workaround: N/A

PortFix SBX-106206: An existing hairpin call gets silenced after a switchover.

Impact: A media loopback is not happening in after switchover.

Root Cause: There was extra check performed during NP incoming path for the combination of MAC address and loopback flag.

Steps to Replicate: 

1. In the SWe SBC Active-Standby HA setup.
2. Using AS/3GPP call flow scripts/setup establish a call that creates an SBC internal loopback media flow.
3. Verify the media flow and then issue a switchover.
4. Verify the media path on this existing active call.

The code is modified to address the loopback media issue and also saves the NP cpu cycles.

Workaround: None.

PortFix SBX-106968: There was an abnormal switchover on a cluster SBC.

Impact: The PRS process cored due to accessing NULL destination ICM handle provided by DRM.

Root Cause: The DRM does not mirror txIcm handle in DRES data structure to standby and the code was not validating the pointer in one specific code path. The code intentionally crashed to identify the bad code.

Steps to Replicate: The problem could not be reproduced and the solution was found based on code review. There was Edge case timing issues where internal message sent before a switchover and response is processed after a switchover.

The code is modified to validate the tcIcm pointer that is not null before trying to use it and thereby avoids the intentional system error crash.

Workaround: No workaround

The S-SBC application goes down with a the MESSAGE call load of 11 cps or more.

Impact: Run the message call flow with the SMM configured with Dialog Scope variables on ingress and egress sides.

Root Cause: Memory corruption is occuring when we store ingress dialog scope variable id in the Relay CB as it is already freed.

Steps to Replicate: Run the message call flow with SMM configured with Dialog Scope variables on ingress and egress sides.

Run 10 CPS load.

Delaying Relay CB free until we send 200 OK for Message

Workaround: Disable the Ingress dialog Statefull variable for the SMM rules.

A SAM Process coredump occurred while executing DoS on an SBC SWe SIP signaling port with a malformed Register Message containing 80 multiple unique and spoofed IPs.

Impact: SIPSG is sending an update to SIPFE for deleting the RCB details with Username, Hostname and PhoneContext as 0 when Register is received with malformed PDU.

Root Cause: In this malformed Register PDU scenario SIPSG should not send a Delete update to SIPFE.

Steps to Replicate: Run a load with Register Malformed PDU from IXia or any test tool.

The code is modified for non zero phone context key in SIPSG for sending delete operation update to the SIPFE.

Workaround: Run in normal mode instead of sensitive mode.

A customer teams core dump occured in a TEAMS call flow.

Impact: A SCM Process core dump resulted for TEAMS call flow.

Root Cause: Null Pointer exception lead to a SCM Process core dump.

Steps to Replicate: The steps cannot be reproduced.

The code is modified to prevent the crash.

Workaround: None.

The SCM process core dump was observed on the standby SBC while running a load with the SBC generated subscribe.

Impact: The SCm process cores on the standby while running the load for a Reg-Event subscription.

Root Cause: There is a leak on the standby for SIP dialog data structure, which is causing a SYS_ERROR on the standby.

Steps to Replicate:

1. Enable the below configuration for Reg-Event feature.
   set profiles signaling ipSignalingProfile DEFAULT_SIP commonIpAttributes subscriptionPackageSupport supportRegEvent enable
2. Run the load of REGISTRATION for Reg-Event subscription feature.

The code is modified to fix the leak of SIP dialog structure on the standby SBC.

Workaround: No workaround

Multiple coredumps were observed during a Load run for generated Subscription call Flow tested during Registration Display Enhancement feature.

Impact: Multiple coredumps were observed when Reg-Event Subscription feature flag gets enabled.

Root Cause: Core 1:
Incorrect type cast of a structure led to invalid memory access and core was observed.

Core 2:
During a switchover, the list "pendingCcDsIcmList" was never initialized; however, it was incorrectly getting freed.

Core 3:
Accessing of a NULL pointer led to this core.

Steps to Replicate: Load test for Reg-Event Subscription initiation.

Core 1:
The code is modified to point to valid memory.

Core 2:
In case of a switchover, the code is modified to initialize the list correctly.

Core 3:
Before accessing the pointer, the code is modified to resolve the issue.

Workaround: N/A

PortFix SBX-105905: Observed the NP crash during an overload test.

Impact: Possible memory corruption in NP KNI request queue when KNI requests are not processed in time.

Root Cause: An older KNI request buffer in the KNI request queue could be concurrently overwritten by a new request while user-space NP logic is still processing it, leading to memory corruption. This issue is more frequent with Mellanox NICs, particularly with multicast mac programming flow.

Steps to Replicate: Perform an sbxrestart on the SBC with port redundancy enabled, and using a Mellanox-based NIC.

The code is modified to ensure currently handled requests are not overwritten by a new request from the KNI module.

Workaround: None.

PortFix SBX-105269: An SBC crash during a call trransfer produced a coredump.

Impact: The SCM Process coredumped due to NULL pointer access for a pointer that was freed due to BYE and HOLD race condition in a transfer call scenario.

Root Cause: There was an illegal memory access, absence of NULL check, and exposed due to race condition.

Steps to Replicate: A calls B, B REFERs to C and now A and C talk. After sometime, A sends BYE and C sends re-INVITE with a=inactive at the same time.

The core is modified to address the issue.

Workaround: None.

PortFix SBX-105888: The SBC is sending the wrong TO tag to AS side.

Impact: The response 200OK for Multi Notify has invalid ToTag.

Root Cause: Internal logical error when process the 2nd 200OK Notify from AS. The application misinterpretation of the direction of the relay message as IAD. And passing down the wrong data down to SIPS for relaying 200OK to AS.

Steps to Replicate: IAD Subscribe to AS. the AS sends multiple Notify immediately one after another.
The 2nd 200OK of Notify sends to AS has wrong ToTag.

The code is modified so the correct data passes down to the SIPS.

Workaround: Peer can send 1 Notify at a time. N/A on the SBC.

PortFix SBX-108081: Unable to see Video from Cisco 8865/9971 on ConnectMe BYOD client.

Impact: The SBC drops RTCP packets for video stream if audio stream is transcoded by SBC for a multi-stream call.

Root Cause: Non-RTCP binding resource was incorrectly picked by the SBC for video stream if audio is transcoded in a multi-stream call. The reason for picking this resource is, natively the SBC did not support audio transcode for a multi-stream call. As a result, the code assumed audio to be in pass-thru mode.

Steps to Replicate: Configuration:
---------------------

1. Configure the SBC for Audio,Video Call.
2. Enable the allowAudioTranscodeForMultiStreamCall in PSP.
3. Enable the rtcp
4. Configure thisLeg and otherLeg, so that audio call will be transcoded.

Procedure:
-----------------

1. Place an Audio transcoded and Video Relay call through the SBC.

Without a Fix:
--------------
The SBC drops RTCP packets for video stream.

With a Fix:
------------
The SBC relays RTCP packets for video stream.

The code is modified to pick the RTCP binding resource for video stream irrespective of audio being pass-through or transcoded.

Workaround: Disable the allowAudioTranscodeForMultiStreamCall flag at Route PSP which would result in Audio pass-through call.

PortFix SBX-106329: The SBC disconnects a call every few seconds after recovering a DNS server.

Impact: The SBC disconnects a call every few seconds after recovering a DNS server.

Root Cause: The DNS client sends a failed lookup response to a DNS agent ( SCM ID 03,01 ...) when a probe query fails to get a response for a blacklisted DNS server because a probe query and regular query were used the same FQDN, record type and zone id.

The timeout response for probe query in the DNS client process as triggered DNS failed response towards SCM process.

Steps to Replicate: DNS settings: Three DNS servers are configured. Each weight is set to 50.

DNS#1 10.xxx.x.xxx has RRs with ttl=5
DNS#2 10.xxx.x.xxx has RRs with ttl=0
DNS#3 10.xxx.x.xxx has RRs with ttl=0

<Time series>
DNS#1 10.xxx.x.xxx process was down (Pkt No.29615). DNS#2 and DNS#3 were available.
After few Seconds DNS#2 10.xxx.x.xxx process was down. Only DNS#3 was available.

The code is modified so the DNS probe query does not trigger any response towards a DNS agent from DNS client.

So do not send any failure response to the DNS agent in case of probe query failure.

Workaround: None.

PortFix SBX-105439: The SBC does not check if “serverCertName” exists while configuring it as part of the TLS profile.

Impact: The SBC allows the configuration of the certificate, “serverCertName”, as part of the TLS profile even though that certificate is not present in the SBC.

Root Cause: The SBC is not validating that a certificate is present during configuration of “serverCertName” as part of TLS profile.

Steps to Replicate: Verify the SBC does not configure a certificate which is not installed.

Steps to verify issue:

1. Bring up the instance.
2. Configure the certificate that is not present in the below path.
   show system security pki certificate.
   set profiles security tlsProfile defaultTlsProfile serverCertName <Name>

Expected result:

The SBC does not allow configuring “serverCertName” as part of the TLS profile.

Steps to verify fix:

1. Bring up the instance.
2. Configure certificate that is present in the below path.
   show system security pki certificate.
   set profiles security tlsProfile defaultTlsProfile serverCertName <Name>

Expected result:

The SBC allows configuring “serverCertName” as part of the TLS profile.

The code is modified for the SBC to validate whether a certificate being configured is present or not on the SBC.

Workaround: None.

PortFix SBX-106224: An SBC failover with the SCM process core dumps due to memory corruption.

Impact: When Prack is enabled on the ingress and advanced SMM for "variableScopeValue message" is enable, the SBC may core when the egress responds with 18x/2xx in quick succession, and the Prack is still pending.

Root Cause: When 18x/2xx is queuing on the ingress, the SBC did not allocate proper resources for "variableScope" data. By the time the SBC sends the data out, it accesses invalid data.

Steps to Replicate: This is random issue that is not easily reproducible.

1. Egress: inbound config variableScopeValue message and send to ingress. For example: store "*99" in var1.
2. Ingress: prack enable, outbound read the var1 and append to the userName of To Header.
3. Egress: send multiple 18x/200 fast to trigger some delay on ingress for sending.
4. Run a load.

The code is modified to properly allocate resource for "variableScope" data.

Workaround: Disable prack.

PortFix SBX-106476: The ipAdaptiveTaransparencyProfile is not working for a re-INVITE coming from Egress.

Impact: When the sipAdaptiveTransparencyProfile is configured for Egress TG and re-INVITE comes from egress peer with change in P-ASSERTED-ID, the SBC does not relay the invite from egress to ingress.

Root Cause: The SBC code does not set service bit for reINVITE transparency for re-INVITEs coming from egress peer.

Steps to Replicate: Test case 1.

Configure the sipAdaptiveTransparencyProfile for Egress TG for re-INVITE.

config
set profiles services sipAdaptiveTransparencyProfile ADP2 sipMethod INVITE triggerHeader P-ASSERTED-ID action new-value trigger value-change
set profiles services sipAdaptiveTransparencyProfile ADP2 state enabled
set addressContext ADDR_CONTEXT_1 zone ZONE4 sipTrunkGroup SBXSUS7_LABSIP2 services sipAdaptiveTransparencyProfile ADP2
commit

When egress sends a re-INVITE with modified PAI after call is connected, no re-INVITE is generated towards the ingress side.

Test case 2

Verify the issue.

With a fix, the re-INVITE is relayed to ingress for both late and early media cases.

The code is modified to ensure the SBC sets the service bit for egress properly when the sipAdaptiveTransparencyProfile is configured for egress TG.

Workaround: None.

PortFix SBX-106920: The FmMasterProcess dumped core after a switchover with stable call.

Impact: The FmMasterProcess core dumps during shutdown.

Root Cause: The FmMasterProcess may deadlock during shutdown due to receiving an event while trying to shutdown/finalize the event handling.

Steps to Replicate: This is extremely time-sensitive and requires publishing an event 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.

PortFix SBX-107041: The OAM and MRFP goes down due to component error time reset for SsreqProcess,SLwredProcess, and when the FmMasterProcess is going down.

Impact: The OAM and MRFP goes down due to component error time reset.

Root Cause: The NTP is not synced before the SBC comes up. As a result, when the sync occurs after the SBC comes up and the new time is older than the current time, the SBC goes down.

Steps to Replicate: 

1. Launch the SBC with a time zone and the NTP in sbx.conf.
2. Check if the NTP server was properly synced and there was no issue of "time getting reset to past" in the SBC logs.

Run NTP sync operations before starting serf to avoid any issue when the time sync occurs and time gets reset to past.

Workaround: No workaround.

The CE_Node1.log is filling up quickly.

Impact: The CE_Node1.log file size grows to an excessive size cauing a hard disk space alarm.

Root Cause: An excessive number of log prints were coming from stack trace dumps on a SYS_ERR (EVLOG).

Steps to Replicate: Run a suite of REFER call scenarios and see that NrmaCpcCallVerifyTimerFunc is not being written in CE_Node log.

Converted the SYS_ERR( EVLOG ) event for the concerned log event to NrmaDlog, so the CE_Node.log file no longer contains the back trace.

Workaround: echo > CE_Node.log when it grows too big.

The SWe_NP - KNI was out of memory

Impact: On the Azure platform with Mellanox ConnectX-3 accelerated NICs, the packet port interfaces may lose connectivity.

Root Cause: The buffer pool associated with Packet interfaces was getting exhausted due to lazy free logic in DPDK's driver for Mellanox ConnectX-3 NIC.

Steps to Replicate: Route few calls to the same packet interface as incoming and some calls to the other packet interface.

The code is modified in order to alleviate stress on the buffer pool.

Workaround: None.

After an SBC switchover, a DEADLOCK was detected for sysID 62, task SIPSG.

Impact: The SIP call load can trigger healthcheck timeout in SIPSG module.

Root Cause: The problem was with the flags that is used for creation of shared memory between SCM process and Fault Avalanche handler process. As a result of incorrect setting of flags, some of the writes to the shared memory was taking more time resulting in the SCM thread getting blocked and health check timeout.

Steps to Replicate: 

1. Run a 50 cps SIP-SIP call load for an extended period of time.
2. Make sure that the fault avalanche control feature is turned on.
   "show system faultAvalancheControl facState" should be enabled.

The code is modified to disable Fault Avalanche control functionality by default.

Workaround: Disable the Fault Avalance control functionality using the following configuration control:

set system faultAvalancheControl facState disabled

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: This problem has been fund and reproduced in Comcast lab, when they were testing their call load.

The colde is modified in cursor and counter area.

Workaround: Lower call rate should lower the risk.

PortFix SBX-107593: There is DTLS support for version 1.2.

Impact: The SBC did not support DTLS clients which only supported DTLS version 1.2 to connect.

Root Cause: The SBC was hardcoded to only support DTLS version 1.0.

Steps to Replicate: Make a call from the DTLS client that only supports DTLS version 1.2 and check that the SBC is able to establish the call.

The code is modified to allow support for up to DTLS version 1.2.

Workaround: None.

PortFix SBX-105483: There was a malformed P-charging vector.

Impact: P-Charging-Vector was not passed transparently to egress on SIP-I to SIP call, when Create P-Charging-Vector is selected on egress IP profile and Store P-Charging vector is selected on ingress IP profile.

Root Cause: The SIP-I INVITE contains IAM with a bad parameter and no parameter compatibility, causing the SBC to send 183 with CFN message and not transit the P-Charging-Vector.

Steps to Replicate: 

1. Make SIP-I to SIP call.
2. SIP-I IAM contains an unrecognized parameter with no parameter compatibility information.
3. Ingress IP profile has Store P-Charging-Vector.
4. Egress IP profile has Create P-Charging-Vector.

Correct code to ensure P-Charging-Vector is passed to egress in this case

Workaround: Disable support for the CFN message in ISUP signaling profile.

PortFix SBX-105674: Turk Telecom 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 behaviour 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 coverity highlighted that some legs of code could result in accessing a pointer that might be null. Derefencing null pointers can cause unexpected behaviour 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.

PortFix SBX-105497: The wrong format of the SIP 400 BAD REQUEST.

Impact: When the SBC received a message that is unable to find the required headers, the SBC responses 400 with syntax errors itself.

Root Cause: The peer intentional sending garbage message.

Steps to Replicate: Incoming request with have required headers as part of content body section.

The code is modified so the SBC discards the message.

Workaround: Use the SMM to drop the message.

PortFix SBX-102277: The debug command caused ScmP to coredump

Impact: We are hitting a Healthcheck timeout when displaying the output of the following debug command:
"request sbx sipsg debug command "svcgrp -ce 0 -scm <x> -1""

Root Cause: The Heathcheck timeout is because it is taking too long to display the data for all of the service groups when there are very large number of trunk groups configured.

Steps to Replicate: 

1. Configure the 1000 TGs
2. Issue the following command:
   "request sbx sipsg debug command "svcgrp -ce 0 -scm <x> -1""

The code is modified to only display up to 50 service groups in order to prevent this Healthcheck timeout.

Workaround: To prevent this issue: Avoid using the following command if there are large number of TGs configured:
"request sbx sipsg debug command "svcgrp -ce 0 -scm <x> -1""

PortFix SBX-105160: There was a CHM process coredump on standby OAM after reboot.

Impact: The SBC application continues to come up even when asp.py zap (zapAsp() call in sbxCleanup.sh) is invoked from sbxCleanup.sh script. When we try to access ceNum in one of the places, since it is not properly set due to failure in sbxCleanup.sh, it results in CHM coredump

Root Cause: The SBC application continues to come up even when asp zap is called.

Steps to Replicate: Fail sbxcleanup in one of the places and ensure the SBC in not being brought up.

The code is modified to avoid the SBC bring up if any errors are reported in sbxCleanup.

Workaround: The issue is fixed, no workaround is required.

PortFix CHOR-7376: There was a Swe_UxPad coredump observed during Teams Testing.

Impact: The SWe_UXPAD process crashes due to the health check failure in extra-low memory SWe configuration on Microsoft Azure with presence of outgoing STUND/DTLS traffic.

Root Cause: The root cause was identified to exhaustion of an internal buffer pool during the presence of STUN/DTLS traffic.

Steps to Replicate: Launch a 6GB SWe instance in azure using accelerated NIC. Run a teams test suite for multiple iterations which would trigger STUN/DTLS traffic to go out from SWe.

The code is modified to adjust the internal buffer pool size in order to account for additional requirements of STUN/DTLS traffic.

Workaround: No workaround.

PortFix SBX-107420: Failed to download the Call Diagnostics file.

Impact: Unable to download a large size call diagnostics log file.

Root Cause: When we tried to download a large size call diagnostics log file. It was failing with JAVA heap error because IOUtils toByteArray API was created internally ByteArrayStream to store file data into byte format. Due to java memory restriction, we were getting a Heap error from ByteArrayStream.

Steps to Replicate: Steps to reproduce the issue:

1. Login into EMA.
2. Troubleshooting > Troubleshooting Tools > Call Diagnostics.
3. Click on Save Call Diagnostics button to generate the log file.
4. Go to the Call Diagnostics Data Files section and try to download the tar file.
5. If the file size is more than 400MB, it should get failed with a proxy error.

The code is modified to internally copies the data from inputStream into OutputStream.

Workaround: NA

PortFix SBX-105290: The SBC CDR: Redirecting digits captured incorrectly.

Impact: The redirecting number recorded in the CDR was not correct if the first policy dip route was used for the call but there was an updated redirecting number from a later route in the policy dip.

Root Cause: The code was incorrectly using the last per route redirecting number from the policy response to overwrite the redirecting number from the received INVITE message and using this to populated the redirection information field in the CDR record.

Steps to Replicate: Configure the PSX routing label with two different route with two different ingress trunkgroups, and in each trunk add a DM rule for RDN. Now, make a call check what is the RDN from the CDR logs. If the call gets success with route 1 then it should have RDN according to DM rule in route1.

The variations in tests:

Test1 => route1 has DM/PM rule to remove CC in RDN and OCN, route 2 has DM/PM rule to modify RDN and OCN. CALL SUCCESS with Route1

TEST2 => route1 has DM/PM rule to remove CC in OCN No rule for RDN, route 2 has DM/PM rule to modify RDN and OCN. CALL SUCCESS with Route1

TEST3 => route1 has DM/PM rule to remove CC in RDN No rule for OCN, route 2 has DM/PM rule to modify RDN and OCN. CALL SUCCESS with Route1

The code is modified to populate the CDR using the per route redirecting number digits or the contain received from the INVITE.

Workaround: Not Applicable.

PortFix SBX-105901: There is a heap-buffer-overflow in the ASAN build for SIPS module.

Impact: Observing the 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: A heap overflow occurs because the 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, which gets dynamically created and is always null terminated. This variable is used in the info log.

Workaround: Not Applicable.

PortFix SBX-103183: The SBC incorrectly formatted the rport in the VIA header.

Impact: The SBC incorrectly formats the rport value in the header of the response message when rport has a valid port number and is at the end of VIA header of request message.

Root Cause: The code does not verify that rport has a valid port number. If rport is the last parameter in VIA header, the SBC appends "=<source port>".

Steps to Replicate: 

1. Setup: SIPp - SBX - SIPp
2. Send Register message with "rport=1111" in VIA header from client SIPp script with to the SBC. "rport" is at the end of VIA header
3. Run the client script with -p 30333
4. Verify that the SBC replaces rport port number (1111) with its own rport (30333) in VIA header of 200 OK response.
   
   
   

PortFix SBX-104975: The MCF id sent back to the ingress as MPS during T.38 Fax to G.711 transmission.

Impact: Some fax T.38 endpoints send an entire DCS V.21 signal in one packet as opposed to 1 octet per packet. This can causes fax failures.

Root Cause: A burst of octets in a single packet is essentially a burst, and causes potential problems as these packets get queued for modulation and cause delay and later TCF (high speed) signal some packets get dropped.

Steps to Replicate: Refer to unit test description in the JIRA.

The code is modified to accommodate such larger bursts.

Workaround: This bug is a specific interoperability problem with such endpoints which exhibit burst single packet DCS signals. For such endpoints, a workaround is not available unless some configurations are available on those devices to modify this behavior.

After 72 characters of same mode (LTRS or FIGS) the stack sends LTRS/FIGS baudot code. If 72nd characters is common code such as BKSP, SPACE, CR or LF and the if previous mode was LTRS, stack sends FIGS baudot tone.

Fix to check current LTRS/FIGSmode and send the LTRS/FIGS baudot code.

Workaround: There is no workaround as such.

PortFix SBX-106822: There was a crash observed in Four GPU Codec Scenario.

Impact: The G.729AB GPU codec may crash when packets are lost in the incoming G.729AB stream which, in turn, leads to SWe_UXPAD crash and an SBC application restart.

Root Cause: An uninitialized stack variable in GPU G.729AB decoder code was identified as the root cause.

Steps to Replicate: 

1. Set sweActiveProfile to use GPU, and sweCodecMixProfile to use G.729.
2. Make a G.729AB to G.711U call, and don't send the media.
   RESULT: SWe_UXPAD may crash and the SBC application restarts.

NOTE: The issue is not always reproducible.

The code is modified to initialize the stack variable appropriately.

Workaround: No workaround.

PortFix SBX-105413: Support for 3072-bit long RSA keys is missing.

Impact: The SBC needs to support 3072-bit RSA keys in certificates.

Root Cause: A feature change is required to support 3072-bit RSA keys in certificates in addition to 2048-bit and 4096-bit RSA keys.

Steps to Replicate: 

1. Test 3072-bit RSA key certificate on client. Make SIP-TLS call from the client to the SBC acting as TLS server.
2. Configure remote certificates with 3072-bit RSA key.
3. Configure local certificates with 3072-bit RSA key.
4. Test 3072-bit RSA key certificate on SBC acting as SIP-TLS server.

The code is modified to provide support for 3072-bit RSA keys in certificates.

Workaround: None.

PortFix SBX-106149: The PSP QoS non-zero value of msrpDscp cause PES to crash.

Impact: The PES process crashes when apps starting up if msrpDscp in PSP QoS values configured with non-zero.

Root Cause: A debug statement tried to print a integer as a string, causing memory problem.

Steps to Replicate: 

1. Configure the non-zero msrpDscp value.
2. Restart the SBC.

Before the code change, the PES will crash.

After the code change, the PES will not crash.

The code is modified to print integer as integer.

Workaround: Do not configure a non zero msrpDscp.

PortFix SBX-107348: The SIP LM call re-Invite sent in the 18x-PRACK stage on ingress.

Impact: The SBC sends a reInvite to the late media while the call is still in prack pending state.

Root Cause: Logical error that fail to detect the state of call not connect yet and the SBC tries to send the reInvite out.

Steps to Replicate: 

1. Configure the LRBT.
2. Incoming late media with prack support.
3. Egress 180 trigger play tone, 180 again again, and 200OK(sdp).
4. Ingress delay sending prack for 5secs.

The code is modified to  validate the state of the call before reInvite out.

Workaround: Disable prack or disable LRBT.

PortFix SBX-104113: The mediationServer signaling channel was online even interface went down.

Impact: Without this fix, the LI - mediationServer signaling channel stays online even after ipInterfacegroup attached to call data channel(CDC) is disabled post a switch-over.

Root Cause: The SBC code, handling the LI - mediation server signalling socket functionality did not register for ipInterfaceGroup operational status in standby mode.
As a result, post switch-over it does not get any notification when ipInterfaceGroup attached to CDC toggles. The signaling connection towards mediation server is not closed.

Steps to Replicate: 

1. Create CDC and configure it for IMSLI and validate that the LI signaling channel is inService.
2. Perform a switch-over.
3. Disable the ipInterfaceGroup attached to the CDC.

The code is modified to register for the ipInterfaceGroup that is attached in CDC in standby mode as well so that if and once it becomes active due to switch-over it would get operational status of the ipInterfaceGroup attached to CDC.

Workaround: N/A

PortFix SBX-105711: There was a ASAN MRFP: 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 SBC 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.

PortFix SBX-103306: Allocated bandwidth for opus call is 1032kb and 1028kb for single call.

Impact: If "transcoderFreeTransparency(TFT)" is enabled at Route PSP, then extra bandwidth is allocated for opus call in case maxaveragebitrate attribute is not received in SDP from the endpoints.

Root Cause: If maxaveragebitrate is not received in 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:

1. set profiles media packetServiceProfile DEFAULT packetToPacketControl transcode transcoderFreeTransparency
2. set profiles media packetServiceProfile DEFAULT secureRtpRtcp flags enableSrtp enable allowFallback enable (Ingress)

To re-create the issue:

1. UAC sends INVITE with OPUS codec and SDP does not contain "maxaveragebitrate" attribute.
2. Since "maxaveragebitrate" is not received from UAC, the SBC defaults to max value of 510kbps and sends the same to UAS.
3. UAS responds 200OK with OPUS codec and SDP does not contain "maxaveragebitrate".
4. The SBC sends out 200OK with maxaveragebitrate=510kbps to UAC.

Test Result without a fix:

Since maxaveragebitrate defaults to 510kbs, the SBC ends up allocating more bandwidth than expected.

If "maxaveragebitrate" is not received in SDP, then derive the default value according to RFC using "maxPlayBackRate" and mode(mono/stereo).

Workaround: None.

PortFix SBX-107611: The AMRWB bit-exactness problem in case of mixed mode test.

Impact: Degraded audio in AMRWB stream when AMRWB (GPU) call load is running, particularly when each call uses different mode.

Root Cause: Root cause was identified to an issue with context rearrangement code of GPU AMRWB codec.

Steps to Replicate: 

1. Set sweActiveProfile to use GPU and sweCodecMixProfile to use AMRWB.
2. Make AMRWB to G711U call load using multiple AMRWB clients, each client using different mode.
   
   RESULT:
   Some of the calls may have degraded audio in AMRWB stream.

The code is modified to address the issue.

Workaround: No workaround.

PortFix SBX-107924: The OAM services are not coming up with 6GB Ram with network interface mapping error.

Impact: The SWe_NP process fails to come up in a 6GB OAM instance configured with only 2 interfaces (ha0 and mgt0).

Root Cause: Lack of sufficient huge pages in this particular scenario causes SWe_NP initialization failure.

Steps to Replicate: Bring up a OAM node with 6GB RAM instance and configure two interfaces (without any pkt interfaces). The OAM instance would fail to come up.

The code is modified to reserve enough huge pages required for SWe_NP.

Workaround: Configure OAM instance with >= 16GB.

This is the officially supported configuration for OAM instance.

PortFix SBX-60855: The OPTIMA FTTH Stat for TG-A and TG-C Stat mismatching.

Impact: The active register count on ingress TG is not decremented when a bad refresh REGISTER is received. 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: 

1. First make one active Registration.
2. After active registration send one bad refresh REGISTER.

Expected Result:

After bad refresh REGISTER, the SBC sends 400 Bad to Refresh REGISTER and also reduces the activeRegCount on ingress Side but it will not reduce count on egress side,

The code is modified to address the issue. 

Workaround: None.

PortFix SBX-102700: The number mapping (translated, RDI, To hdr, R-URI) is unexpected.

Impact: The SBC is not adding translated number received from PSX to RequestURI when Diversion header is present in the ingress Invite.

Root Cause: If the ingress Invite does not contain Diversion header, then the SBC is adding translated number to RURI. So same result is expected when diversion header is present.

Steps to Replicate: 

1. Make a SIP call by sending an Invite with Diversion header from UAC.
2. Configure PSX to return "translated number" for the called party number in policy response.
3. The SBC includes the translated number in Request URI and routes the call.

The fix is to populate the RequestURI with the translated number even when the Diversion header is present in the initial Invite.

Workaround: None.

PortFix SBX-104507: The SBC is not passing URI parameter while History to Diversion interworking

Impact: The SBC is not passing URI parameter "user=phone" while interworking History-Info header to Diversion header.

Root Cause: The SBC was not adding "user=phone" during interworking History-Info header to Diversion header for the SIP uri.

Steps to Replicate: 

1. On the ingress leg, enable acceptHistoryInfo.
2. On the egress leg, enable diversionHistoryInfoInterworking.
3. Run a basic call with History-Info header having SIP uri and "user=phone" parameter.

The code is modified to add "user=phone" during interworking History-Info header to Diversion header for the SIP uri.

Workaround: None.

PortFix SBX-106042: The RCB(s) can be hijacked and effect on registered users/EPs.

Impact: Issue 1: When the register is sent to the registrar, the SBC creates a RCB for that particular User. When a fake/hijacked register is rejected with 403, some of the parameters in RCB are being modified and users were unable to make a call due to security mechanism being set to TLS.

Issue 2: If a timeout on the RCB leads to it moving to a terminated state and a refresh register arrives, subsequent calls are rejected.

Root Cause: Issue 1: When a Register request is rejected with a 403, it moves to the terminated state. Also, when a register is received, the RCB details are modified irrespective fo the response received from the registrar.

Note: A register is considered fake when we receive a 403 response for that.

Issue 2: When the RCB was moved to the terminated state, the code was partially deleting internal memory that led to reporting the RCB mechanism as TLS, and not rejecting the TLS calls.

Steps to Replicate: Use the conas mentioned in the description and use the config file attached for reference:

1. After config make a successful registration, later make a register so that it gets rejected with 403 error.
2. Verify the parameters in RCB using this command:
   show status addressContext default sipActiveRegisterNameStatus
3. Check for all the displayed parameters and also check for sipSigPort and other essential parameters in Debug logs.

The code is modified for:

1. When we receive a fake register and 403 response the RCB should remain in previous state with the previous information. The RCB contents are backed up so they can be restored on failure.
2. Remove the security mechanism of TLS when the RCB is in terminated state.

Workaround: No Workaround.

PortFix SBX-102726: The Diameter RX had the wrong data in media-component AVP post T.38-488.

Impact: Sending the wrong data in media-component AVP (codec-data) when T.38 failback fails.

Root Cause: Instead of sending last negotiated codec, the SBC was sending previous offer-answer data in the media-component AVP of AAR message.

Steps to Replicate: 

1. Configure PSPs for faxfallback and enable Rx feature.
2. Run transcode call (A(PCMA) and B(PCMU)).
3. The B sends fax tone, on detecting fax tone the SBC sends T.38 Re-INVITE towards A and A rejects with 488.
4. When a fallback happens, the SBC sends G711 Re-INVITE towards A and gets 200 OK. On getting 200 OK. The SBC sends final AAR that should contain last negotiated SDP information.

The code is modified to address the issue.

Workaround: Not Applicable.

PortFix SBX-105450: A failure to delete remote server configured with FQDN for multiple commits.

Impact: Failure to delete remote server configured with FQDN for multiple commits.

Root Cause: The confd iter stops on returning failure for not finding any child remote servers for the first remote server and we fail to process the delete request for the second remote server that leaves the child remote servers of the second remote server as is.

Steps to Replicate: 

1. Configure multiple FQDN remote servers such that first server fails to resolve FQDN and the second server creates child remote servers.
2. Disable both the remote servers.
3. Delete the first remote server and then the second in a single commit.
4. The remote servers created by second remote server fails to delete.

Return success from delete remote server function so that next CDB operation is processed. Failure to find a server is anyways logged and is not shown on the CLI as an error.

Workaround: Delete the remote servers in separate commits.

PortFix SBX-106913: There was a SCM process coredump for register with timeout from Application server with no response.

Impact: The coredump observed when the SBC logs account info incase of register timeout.

Root Cause: There was a NULL check miss in the code so coredump observed when we try to access account information.

Steps to Replicate: 

1. Send a REGISTER from UAC, the SBC sends towards AS.
2. The AS sends 302 to REGISTER.
3. The SBC sends redirected REGISTER to next AS and tries for 5 times since there is reply from AS.

The code is modified to address the issue.

Workaround: Not applicable.

PortFix SBX-105050: The SBC DRBD mount not visible on active the SBC.

Impact: The SBC DRBD mount was not visible on the active SBC.

Root Cause: When the sbxrestart is issued from platform manager, DRBD gets mounted on apache's mountspace.

Steps to Replicate: 

1. Bring up both the nodes.
2. Do an SBC restart from pm on active.
3. The new active must have drbd mounted.

Modify the apache service file and set the resposible parameter (PrivateTmp) to false.

Workaround: None.

PortFix SBX-105736: Sending the m=application 0 UDP/BFCP (null) in case of UPDATE.

Impact: The SBC sends m=application line in incorrect format in SIP UPDATE message.

Root Cause: The SBC does not format m=application line for UDP/BFCP when sending UPDATE message.

Steps to Replicate: Test case

1. Reproduce the issue.

The SBC sends a INVITE with SDP(with audio and video lines and m=application) and receives rel 18x with SDP(with audio and video lines only) followed by final 200OK with SDP (with audio and video lines and m=application) if flag is enabled then SDP of 200OK should be ignored by the SBC.

UPDATE message content: m=application 0 UDP/BFCP (null).

2. Verify the issue. Repeat step 1. 

UPDATE message content: m=application 0 UDP/BFCP *

The code is modified to ensure the SBC sends m=application line in correct format.

Workaround: None.

PortFix SBX-104851: The SBCb is down and the standby registration with active failed, error 160004.

Impact: The standby is not allowed to join cluster and fails to start

Root Cause: The safplus checkpoint file is corrupt and the section needing to be overwritten is not found.

Steps to Replicate: The root cause of the checkpoint corruption is unknown/cherckpoint corruption cannot be forced and therefore, directly testing this fix is not possible.

The code is modified to re-add the missing section if it is not found.

Workaround: A complete outage is required as the active must be restarted.

PortFix SBX-102469: Time zone is defaulting to EST/EDT on the SBC instances while using image based instantiation.

Impact: Time zone is defaulting to EST/EDT on the SBC instances while using image based instantiation because the timezone details passed during launch are not being applied when the SBC is brought up.

Root Cause: The timezone details passed during launch are not being applied when the SBC is brought up.

Steps to Replicate: Launch the SBC on the SWE. Provide values for timezone and NTP in sbx.conf. Check if proper timezone values and NTP configuration is applied on launch.

The code is modified to update timezone with value in sbx.conf.

Workaround: No workaround other than setting timezone manually in cli.

PortFix SBX-106231: The Metallic noise present in the stream coming out from G722 side.

Impact: Metallic noise in G722 stream when GPU G722 to Narrow band codec call is made.

Root Cause: Resampled output is incorrectly copied in GPU G722 Encoder upsampling (narrowband to wideband) code.

Steps to Replicate: 

1. Set sweActiveProfile to use GPU and sweCodecMixProfile to use G722.
2. Make G722 to G711U call.

RESULT:
G722 stream contains metallic noise.

The code is modified to properly copy the resampled output.

Workaround: No workaround.

PortFix SBX-106343: The GPU EVRCB decoder asserts in Erasure frames simulation test.

Impact:The GPU EVRCB decoder may crash when there are lost packets in the incoming EVRCB stream, which in turn leads to SWe_UXPAD crash and the SBC application restart.

Root Cause: Precision errors in the floating point comparison in EVRCB decoder code was identified as the root cause.

Steps to Replicate: 

1. Set sweActiveProfile to use GPU and sweCodecMixProfile to use EVRCB.
2. Make EVRCB to G711U call and do not send the media.

RESULT:
SWe_UXPAD will crash and the SBC application restarts.

NOTE: The issue is not always reproducible.

The code is modified to handle precision errors.

Workaround: No workaround.

PortFix SBX-107613: The AMRWB encoder produces corrupted output when channel is reused by lower mode.

Impact: Degraded audio in AMRWB stream when AMRWB (GPU) call load is running, particularly when each call uses different bitrate.

Root Cause: Problem occurs when the same codec context is reused and the previous used was for higher bitrate, the root cause was identified due to reinitialization logic for an internal buffer.

Steps to Replicate: 

1. Set sweActiveProfile to use GPU and sweCodecMixProfile to use AMRWB.
2. Make AMRWB to G711U call load using multiple AMRWB clients, each client using different mode.
   
   RESULT:
   Some of the calls may have degraded audio in AMRWB stream.

The code is modified to appropriately reinitialize the internal buffer.

Workaround: Problem does not occur when all channels use the same bitrate.

PortFix SBX-106004: The EMA display error when SMM deleted through the CLI.

Impact: When a rule is deleted from SMM through CLI and if we try to load the SMM from EMA, an error is displayed in the UI.

Root Cause: EMA checks the ordering of the rules and if the Order is not continuous then an error is shown in the UI.

Steps to Replicate: 

1. Delete any SMM rule (other than the last) from CLI.
2. Login to EMA.
3. Navigate to Profiles > Signaling > SIP Adaptor Profile.
4. Select the SMM whose rule was deleted from CLI.
5. SMM is shown without any error.

The code is modified to address the issue. 

Workaround: N/A

PortFix SBX-105387: LeakSanitizer:SCMP_3 gave memory leaks at MemAlloc2 and same gave Heap overflow issue, both from the same caseID.

Impact: Heap use after free detected in ASAN for a downstream forking call flow. Accessing memory after it has been freed can cause unexpected behavior and in the worst case potentially coredumps.

Root Cause: When copying multiple contacts from 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 a address that was already freed.

Steps to Replicate: 

1. Run Downstream Forking Call Scenario.
2. UE sends Initial INVITE towards UAS through the SBC.
3. The SBC receives multiple 18x with different to tag and different username in the Contact header.
4. The SBC receives 200 OK for any of the downstream forking dialog.

The code is modified with the correct username from the call block for every downstream forking response.

Workaround: None.

PortFix SBX-106167: The call ends up in one-way audio after the called party puts the call on hold and off hold twice.

Impact: 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, 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: 

1. Run basic SIP to SIP call with NAPT and RTCP enabled.
2. Hold/Unhold the call a few times to check for proper 2-way audio.

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. Work around could be:

1. Disable RTCP or
2. Disable NAPT.

PortFix SBX-105804: The CDR field is not populated even though the SBC writes the value to CDR field for '200 Ok of BYE' received/sent.

Impact: The CDR field added by SMM is not present in the ‘STOP’ record.

Root Cause: The SBC was not adding CDR field in the STOP record that was added during the process of 200 response of BYE method.

Steps to Replicate: 

1. Attach the SMM profile which will add the CDR field for 200 response of BYE method.
2. Enable endToEndBye flag.
3. Run a basic A-B call.

The code is modified for updating the CDR field in the STOP record during the processing of response of BYE method.

Workaround: Add the CDR field in the SMM for BYE method instead of 200 response of BYE method.

PortFix SBX-103570: Observed major logs flooding for "MAJOR .SIPSG: sipsgMsgProc.c (-19034) 49487. SipSgRemoveDblTrackingEntry, Hash entry not found"

Impact: Flood of Error logs are seen during load testing of TLS/TCP Registration and certain Register messages are under the scanner of DBL.

Root Cause: The DBL has limitations on the offenders list. When this limitation is reached, due to certain bug in the code, the DBL was sending unintended messages to other modules. Due to this message, the flood of logs were observed.

Steps to Replicate: 

1. Execute a 600K TLS/TCP Registration at 1000 rps.
2. Let all the endpoints register.
3. Start the Supported call load (here Approx 20K, 254cps * 90cht= 22860). 50% from the registered Endpoints and 50% from Peering EPs.
4. Ext to Ext IntraSBC Call load of 5000, 50cps*100cht from SIPP.
5. The DBL applied/removed for Registered endpoints should deny entries to 10% of registration/call load. Repeat this for 10 times.
6. Let the load run for 3 hours.
7. Do operator initiated CLI switch-over and revert.

The code is modified to address the issue.

Workaround: Not Applicable.

PortFix SBX-99258: For OOD NOTIFY, SBC sending 481-Call Leg/Transaction Does Not Exist when same SBC acting as P-CSCF and IBCF.

Impact: SBC fails to send NOTIFY if the User part is not present in the To Header.

Root Cause: SBC is not able to find the entry in the hash-table as to-tag is not parsed properly, because of user part being absent in the To header.

Steps to Replicate: 

1. Make a basic Subscribe-Notify call, ensure that in From header of subscribe and To header of NOTIFY does not have User part.
   eg: To: sip:10.xx.x.xx;tag = abcd-1234-012
2. See that for Notify, the SBC will respond with 481 call leg does not exist.
3. Try the same with Fixed build, notify should reach the subscriber.

The examples below are To headers that were tested in the Notify:

1. To: sip:10.xx.x.xx;tag = abcd-1234-012
2. To: <sip:10.xx.x.xx>;tag = abcd-1234-012
3. To: sip:xxxx@10.xx.x.xx;tag = aabcd-1234-012
4. To: <sip:xxxx@10.xx.x.xx>;tag = aabcd-1234-012

The code is modified to fetch the tag properly even if the user part is not present in To header.

Workaround: No Workaround.

PortFix SBX-88007: The call flow should work with 5 video and 1 audio streams, which is not working, but when one video stream is removed then the callflow is working.

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 inter process communication resulted in the failure.

Steps to Replicate: Configuration:
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
Enable Direct Media on the ingress and egress TG's (but not on AS TG):
TG - media directMediaAllowed enable
PSP for all TG's should have DM flag enabled
PSP - flags useDirectMedia enable
Enable ICE (webrtc) on the ingress and egress TG's:
TG - services natTraversal iceSupport iceWebrtc
Enable DTLS on the ingress and egress. TG's and PSP's
TG - media dtlsProfileName defaultDtlsProfile
PSP - dtlsCryptoSuiteProfile DEFAULT enableDtlsSrtp enable
Set the directMediaGroupId on ingress and egress TG's to be same e.g. 200 and AS to be different e.g. 400
e.g. TG - media directMediaGroupId 200
Enable Direct Media Anti Trombone on AS TG:
TG - media directMediaAntiTrombone enable

Steps:

1. From UE1 send an INVITE with ICE and DTLS in the SDP with 5 video and 1 audio stream to ingress TG and route towards the AS TG
2. From the AS send back an INVITE to AS TG of the SBC, the C line of the sent SDP must match the C line of the received SDP.
3. From UE2, send 180 with no SDP followed by 200 OK with ICE and DTLS in the SDP (UE2-sdp 1 audio and 5 video).
4. From the AS send the 180 followed by 200 OK back towards the SBC.
   
   Expected Result: The call succeeds.
   
   Actual Result: The call fails.

The code is modified so the memory buffer size is increased to accommodate six streams.

Workaround: None.

PortFix SBX-103539: Observed flooded Logs for refresh registration in the Standby SBC restart stop for sometime "sipsgRegSecurity.c (-2745) 1752. SipRaDigestTlsProcessRefreshRegister: No Digest TLS negotiation in progress"

Impact: The DBG logs were filling up with the following MAJOR level log.
167 09142020 143342.220452:1.01.05.41210.MAJOR .SIPSG: sipsgRegSecurity.c (-2745) 1753. SipRaDigestTlsProcessRefreshRegister: No Digest TLS negotiation in progress

Root Cause: This is an information message and should not have been getting generated at MAJOR level.

Steps to Replicate: Run registration call flows.

The code is modified to address the issue.

Workaround: None.

PortFix SBX-106170: The AddressSanitizer: heap-use-after-free on address 0x60f000047d38 at pc 0x562fcd2973a5 bp 0x7f3963983f40 sp 0x7f3963983f38 READ of size 20 at 0x60f000047d38 thread T7.

Impact: The ASAN reported of accessing a structure pointer that is already freed.

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.

1. Send INVITE from UserA, respond from the DNS1 with RCODE error 4 for A query and respond from DNS2 with RCODE 0 with proper DNS answer for A query and check dnsServerStatistics.
2. Run a show command to check the dnsFallback flag and ednsFailures stats:
   show addressContext <addressContext_Name> dnsGroup <dnsGroup_Name> dnsFallback
   show table addressContext default dnsGroup <dnsGroup_Name> dnsServerStatistics
   
   

The code is modified so now getting socket address from pstSrcAddr structure.

Workaround: No workaround.

PortFix SBX-102115: The SBC modifies the Replaces parameter with wrong Call-ID and tags if the Replaced call was looped back to the SBC through a SIP Proxy that does not modify SIP Call-ID and tags

Impact: Relay refer with replaces for loopback call, the SBC picks up the wrong call leg.

Root Cause: The SBC query for the replaces callId, and found matching both legs (loopback). The SBC pick up the wrong leg.

Steps to Replicate: This is specific to customer call flow.

If loopback is detect, only pick the one with to-tag match local-tag. This is per RFC-3891, section 3.

Workaround: None.

The DSP is coring and the system unstable

Impact: Some Fax T.38 IAD calls (T.38 protocols version 3) result in a DSP crash and reload and calls are not successful.

Root Cause: This condition is caused because this specific V3 IAD is sending CM messages with incrementing UDPTL seq numbers. Typically, repeated messages carry same UDPTL seq number to indicate that they are redundant. Packets with unique seq numbers are assumed to be independent and data from these is causing an unchecked buffer overflow in 3rd party T.38 stack code.

Steps to Replicate: The main cause of the crash based on core inspection seems to be multiple CM messages with incrementing UDPTL seq numbers Rx by stack.

As a result, the test case involves a setting up G711 to V3 call with such CM packets.

UAC: start call in G711 and reinvite to V3 and send CM
g711v3t38_cmseq.xml
UAS: start in g711 and accept a re-invite to silsup-off
uas_reinvite_g711.xml
PCAP: cmt38seq.pcap

Delete beforefix.PKT and afterfix.PKT entries because they refer to files attached to the JIRA, which customers don't have access to.

Before fix: The call is set up, and a DSP coredump occurs with a single DSP reload.

After fix: The call continues without crash.

The code is modified to address the issue.

Workaround: Use Version 0 for T.38 calls.

The EMA Configuration Script and Template import page file list doubles each time the search magnifier is used

Impact: When the search magnifier is hit, the entries are doubled.

Root Cause: Table with old data is not cleared before starting a new search. As a result, entries were doubled in dataTable.

Steps to Replicate: 

1. Have some entries in the table.
2. Apply a filter and click search button.
3. Entries are not doubled.

The code is modified to clear the data in the table before starting a new search.

Workaround: No Workaround.

With the Q1912 in a 302 Redirect msg, the SBC sends rn and npdi even though the Contact Header in 302 does not have rn and npdi.

Impact: When making a call where the INVITE contains NPDI/RN parameters and the SIP variant on the ingress trunk group is set to Q1912 when the call goes through 3xx processing the wrong called party number is sent in the subsequent INVITE.

e.g.
The initial INVITE contains
INVITE sip:11111111;npdi;rn=222222@<IP>:<PORT>

The policy dip performs an ENUM query and gets a new called party number of 33333333

The initial INVITE goes out with
INVITE sip:33333333@<IP>:<PORT>

The end point responds with 3xx and the subsequent INVITE then contains
INVITE sip:1111111@<IP>:<PORT>
because when using the Q1912 the TOA_PORTED_NUMBER of 11111111 is passed up to in the second policy dip and confuses the routing logic.

Root Cause: When processing the 3xx and making a second policy dip, the code was meant to remove the generic number parameter of type TOA_PORTED_NUMBER. The code assumed there would only ever be one generic number parameter present. However, when the ingress SIP variant is set to Q1912 the SIP code internally creates a generic number parameter of type additional calling party number based on the contents of the FROM header. In this scenario, the code was unable to delete the generic number of type TOA_PORTED_NUMBER and this was passed back to the PSX in the second policy dip and resulted in routing confusion and unexpected parameter content in the INVITE following the 3xx.

Steps to Replicate: Perform a call where the SIP variant on the ingress trunk group is set to Q1912 and the INVITE contains the npdi/rn parameters e.g.
INVITE sip:1111111;npdi;rn=222222@<IP>:<PORT>
The initial INVITE goes out with
INVITE sip:3333333@<IP>:<PORT>
The end point responds with 3xx and the subsequent INVITE then contains
INVITE sip:3333333@<IP>:<PORT>

The code is modified to correctly delete the generic number parameter of type TOA_PORTED_NUMBER associated with the number translation information from the first policy dip to avoid routing confusion on the second policy dip.

Workaround: If possible change the SIP variant on the ingress trunk group to be "sonus" instead of "Q1912" to avoid the creation of the generic number parameter of type additional calling party number based on the FROM header contents.

There are PAI differences between the SBC and GSX.

Impact: The SBC was using the ingress calling URI information to create the egress PAI header contents, even when the calling party number digits are all removed using DM/PM rules in PSX.

Root Cause: Because the SBC supports additional functionality that is not present on the GSX, the SBC can use the contents of the calling URI from the ingress side of the call even when the PSX does not set the username mask flag in the calling URI parameter in the policy response.

Steps to Replicate: Configure the PSX to generate the PAI header on the egress INVITE, but remove all the calling party digits, all the calling URI username digits and the generic name parameter. Then make a basic call and check that the SBC does not include PAI in the egress INVITE.

The code is modified to check that the PAI header contains username and/or displayname parameters before adding it into the egress INVITE. On the PSX, when the customer wants to delete the calling party number digits, they also need to remove the calling URI username and the generic name information.

Workaround: Need to use SMM to remove the PAI header.

The PKT port manualSwitch triggered twice.

Impact: Executing port switchover command from CLI triggers port switchover twice.

Root Cause: Link detection sub system on standby node subscribes to port switchover action command with CDB (Confd) twice:

1. When the node comes up as standby.
2. When it initiates switchover to become active.
   
   When standby node becomes active, executing port switchover command from CLI results in notifying link detection sub system twice due to duplicate subscription. This results in initiating port switchover twice.

Steps to Replicate: 

1. Bring up nodes with port redundancy in HA mode.
2. Initiate CE switchover to make sure standby node becomes active.
3. Execute port switchover command on new active node and validate the behavior.

The code is modified to not subscribe for action command when the node is in standby mode and subscribe only upon switchover when it transitions from standby to active.

Workaround: None.

Observing lot of errors in DGB files since upgrading to 9.2.0R001.

Impact: Recently, a fix was added in the SBC for updating the subscription timer on getting a NOTIFY message with the value of expires param in Subscription-State header. But as per RFC 3265 this param is a "should" and is not mandatory.

Root Cause: When the SBC updated the subscription timer on receiving a NOTIFY message, the case for the expired param missing was not considered.

Steps to Replicate: Create a subscription on the SBC, with SUBSCRIBE relay.

1. From UAC send SUBSCRIBE to the SBC, which it relays to UAS.
2. Send a NOTIFY without expires param to the SBC from UAS.
3. The log "SipSgStartUpdatedSubscriptionTimer: Invalid subscription timer 0 second for callId" should not be seen after fix.

The code is modified to address the issue.

Workaround: If it is really required, SMM could also be used to send some expires param in NOTIFY Subscription-State header.

The LeakSanitizer: CpxDnsCreate leaks observed during SBX-85432/<redacted> E2E C-SBC automation run.

Impact: There is a small memory leak in the Cpx process when DNS elements are added or deleted.

Root Cause: As part of adding/deleting DNS entries the Cpx process reads in the interface group name from CDB and stores it in a local buffer but does not free it when finished processing.

Steps to Replicate: Add DNS server entries.

The code is modified to correctly free up the local buffer at the end of the configuration logic.

Workaround: None.

There are coverity issue in the SIPSG.

Impact: There are coverity issues for NULL check.

Root Cause: The null pointer dereferences while handling a session refresh.

Steps to Replicate: Run a call where re-INVITE does not contain SDP.

The code is modified to add the NULL check before accessing the pointer.

Workaround: No workaround.

Adjust the MAX_LEN_REALM in camRfAppRedund.h to correct length.

Impact: If the realm string under realmRoute of a diamNode configuration is configured with more than 129 characters, there is a possibility of the string value not being retrieved correctly from the cdb after the SBC restarts or not being made redundant correctly on a HA system.

Root Cause: The maximum size for the realm string was incorrectly defined as 129.

Steps to Replicate: 

1. On a HA SBC system, Configure diamNode with a realmRoute that has realm string greater than 129 chars. For example:
   set addressContext default diamNode DIAMNODE realmRoute RX.EXAMPLE.COM realm ims111111111122222222223333333333444444444455555555556666666666
      7777777777888888888899999999990000000000111111111122222222223333333333
   mnc094.mcc235.3gppnetwork.org peer RX.EXAMPLE.COM appId rx
2. Show addressContext default diamNode to verify configuration has applied correctly and realmRoute has realm value string as configured.
3. Perform a switchover the SBC.
4. On the newly active SBC, show the addressContext default diamNode to verify configuration is the same and realmRoute has realm value string as configured.

The definition of maximum size for the realm string is  modified to 257.

Workaround: The realm string should be limited to 129 characters.

The Platform Interface Status was incomplete.

Impact: In the Network Tools, the Platform Interface Status section can be used to display the status of Interface selected from the left side section.
For certain interfaces like pkt0, pkt1, mgt0, mgt1 the status message was incomplete.

Root Cause: For interfaces like pkt0, pkt1, mgt0, mgt1 the status message displayed in textarea element, had more than one < and > characters and so the text within them was considered as HTML block by the browser and it was hidden.

Steps to Replicate: 

1. Login to EMA, open Administration > System Administration > Network Tools.

2. Select interfaces in the "Platform Interface Status" section and ensure that the displayed status message matches with the status message from CLI.

The code is modified from <textarea> to <pre> to address the issue.

Workaround: Not Available.

The SBC is not generating the UPDATE message towards the UAC for the 183 Dialog-2 when there is delay in PRACK message.

Impact: A call failure was observed during the processing of second dialog provisional response with SDP for downstream forking scenarios when PRACK is delayed at ingress.

Root Cause: When the SBC needs to send UPDATE at ingress during downstream forking for codec re-negotiation while PRACK is pending, it tries to formulate an internal auto answer. If the UPDATE is offered with a new codec other than previously locked, the SBC while forming such local answer adds the previously negotiated codec. This created a mismatch in offer-answer state machine resulting in call failure.

Steps to Replicate: 

1. Enable customer configurations.
2. Send 183 Dialog-2 from UAS.
3. Once 183 Dialog-2 received to UAC, Send PRACK for that 183 after 2 seconds delay.
4. Check if the SBC sends UPDATE for the second dialog 18x.

The code is modified to consider presence of "doNotAutoAnswer" TrunkGroup flag to decide if a local answer needs to be formed or wait until PRACK comes to release the UPDATE.

Workaround: Not Applicable.

The SBC is releasing the call during customer-1-1-4 call flow when 200OK answered with dialog-1 and delay in ACK from UAC

Impact: Call failure observed during processing of second dialog provisional response with SDP for downstream forking scenarios when PRACK is delayed at ingress

Root Cause: When the SBC need to send UPDATE at ingress during downstream forking for codec re-negotiation while PRACK is pending, it tries to formulate an internal auto answer. If the UPDATE is offered with a new codec other than previously locked, the SBC while forming such local answer adds the previously negotiated codec. This created a mismatch in offer-answer state machine resulting in call failure.

Steps to Replicate: 

1. Enable customer configurations.
2. Send 183 Dialog-2 from UAS.
3. Once 183 Dialog-2 received to UAC, Send PRACK for that 183 after 2 seconds delay.
4. Check if the SBC sends UPDATE for the second dialog 18x.

The code is modified so consider the presence of "doNotAutoAnswer" TrunkGroup flag to decide if such local answer need to be formed or wait until PRACK comes to release the UPDATE.

Workaround: Not Applicable

The /opt/sonus/sbx/bin/opensslSelftest cmd failed in the SBC 7000.

Impact: When the FIPS mode is enabled on hwType SBC7000 (7k), services will fail to come up and the SBC becomes inaccessible.

Root Cause: After enabling the FIPS mode when FIPS selfTests run, opensslSelfTests fails due to using a deprecated SSL engine on SBC 7000.

Steps to Replicate: 

1. Enable FIPS mode from CLI.
2. Ensure the SBC services are accessible after reboot.

The code is modified to remove the deprecated SSL engine from opensslSelfTest and this allows FIPS mode to function as expected.

Workaround: None.

The EMA display error when the SMM is having criteria with reg-exp like "cpm.msg|cpm.largemsg".

Impact: The EMA display error when SMM is having criteria with reg-exp like "cpm.msg|cpm.largemsg".

Root Cause: The EMA is not checking whether nonmatch value is present in database or not.

Steps to Replicate: 

1. Log into the SBC from CLI.
2. Configure the profile rules provided in the Description in the DB.
3. Log into the EMA GUI.
4. Navigate Profiles->Signaling ->sipAdaptorProfile.
5. Edit the Configured profile that is done from the CLI.
6. There we can see the issue is fixed.

The code is modified to address the issue.

Workaround: Not Applicable.

The SBC is not triggering UPDATE to ingress and egress for 183 Dialog-2 during E2E precondition interworking. Issue with ISBC(SIP_FW)

Impact: The SBC was not sending UPDATE towards ingress while process downstream forking call.

Root Cause: Precondition values are not properly updated in the data structures, resulting in failure to send the UPDATE.

Steps to Replicate: 

1. Bring up customer E2E setup.
2. Transparency precondition scenario.
3. Send 18x dialog-2 with same SDP that of 1st dialog 18x.

The code is modified so now the SBC processes the precondition values and triggers an UPDATE to ingress.

Workaround: None.

The SBC is not generating UPDATE message for 183 Dialog-2 when 183 Dialog-1 and 183 Dialog-2 having same SDP.

Impact: The SBC was not sending UPDATE towards ingress while process downstream forking call.

Root Cause: Precondition values are not properly compared at egress, resulting in failure to send the UPDATE.

Steps to Replicate: 

1. Bring up customer E2E setup.
2. Transparency precondition scenario.
3. Send 18x dialog-2 with same SDP that of 1st dialog 18x.

The code is modified to compare the precondition values and if there is change an indication message is sent to ingress leg which further triggers an UPDATE.

Workaround: None.

The SIPSG_MSG_PARAM_SIPSG_REDUND_ACT_STR is not registered for serialization correctly before 10.0 release

Impact: After LSWU, some of the event record fields are not serialized properly for the calls related to Register and OOD messages.

Root Cause: Event record accounting details are not registered for Serialization.

Steps to Replicate: 

1. The SBC is an older release(< 9.2.1).
2. Configure to generate event record for Register.
3. Make a Register call.
4. Send a Refresh register.
5. LSWU to 9.2.1.
6. Complete the registration call.
7. Check the details of generated event record.

The code is modified to address the issue.

Workaround: None.

Receiving an unexpected CANCEL in the SBX-SBX GW early media case.

Impact: 503 is sent for Update because of Server Request not present for Update Request

Root Cause: Update Server Request is removed from SIP Dialog Structure because we are unable to send a 200 OK for the Update.

Steps to Replicate: In this scenario Update is received from Egress and it is sent to ingress. In the Ingress, the 200 OK for this Update is delayed and not sent immediately.

In the mean time, there is one more Update is received from egress. This is rejected with 500 Internal Error stating request already pending.

Now, the 200 OK for the First Update is received from ingress and it is being sent to egress

The code is modified to  not remove an Update request from Server request list in the SIP dialog request.

Workaround: None.

The mid call tracing is collecting only MGSG logs.

Impact: If the C3 sends MODIFY command with only CallTraceActReq=ON and without any media parameters, then the media logs are not captured in TRC file even if media parameters are changed in subsequent MODIFY command from C3.

Root Cause: Whenever the MRFP/MGSG receives MOD command with only CallTraceActReq=ON, the MGSG does not send any MODIFY command to NRMA and as a result call tracing info is not updated in NRMA and other media related modules.

Steps to Replicate: 

1. Establish a MRFP call.
2. Send MODIFY command from C3 with only callTraceActReq=ON, no change in media parameters.
3. Send MODIFY command from C3 with changes in media parameters.
4. Verify that .TRC file contains logs from NRMA, XRM and other media related modules.

The code is modified to send modify command to NRMA whenever MGSG receives MOD command with only callTraceActReq=ON.

Workaround: No Workaround.

The SBC terminates a call as 491 does not get relayed.

Impact: Run a Scenario with Re-invite without SDP and send 491 request pending for that re-invite. 491 is not being relayed even though relay4xx-6xx is enabled and E2E Re-invite is enabled.

Root Cause: Even though Re-invite is received from the Network the following bit bIsE2ENtwkReInviteReq in the SIP call structure is not set to true. This is causing 491 to be handled locally.

Steps to Replicate: Run a Re-invite without SDP scenario and send 491 for that re-Invite.

The code is modified to address the issues.

Workaround: None.

The SBC is rejecting the call when 200OK of INVITE is answered with Dialog-1 .Dialog-1 is having the AMR-WB codec and Dialog-2 having the EVS codec

Impact: Call failure observed during certain downstream forking scenarios when 200 OK of initially negotiated dialog comes.

Root Cause: When the SBC need to send Re-Invite at ingress during downstream forking for codec re-negotiation while ACK is pending, it tries to formulate an internal auto answer. If the INVITE is offered with a new codec other than previously locked, the SBC while forming such local answer adds the previously negotiated codec. This created a mismatch in offer-answer state machine resulting in call failure.

Steps to Replicate: 

1. Enable customer configurations.
2. Send 183 Dialog-1 with the AMR-WB codec.
3. Send 183 Dialog-2 with the EVS codec.
4. 200OK of INVITE sent with the dialog-1.

The code is modified to consider presence of "doNotAutoAnswer" TrunkGroup flag to decide if a local answer needs to be formed or wait until ACK comes to release the Re-Invite.

Workaround: Not Available.

The SBC is sending Min-Expires header twice to endpoint for 423 Interval Too brief response.

Impact: The Min-Expires header is sent twice in the REGISTER response.

Root Cause: The Min-Expires header was sent twice as it was getting added by the application and the transparency profile.

Steps to Replicate: 

1. Enable Min-Expires headers in the Transparency profile.
2. Send a REGISTER message to SBC from UAC.
3. UAS sends 423 response to REGISTER message received from SBC.

The code is modified to address the issue.

Workaround: Remove the Min-Expires headers from the Transparency profile.

The SBC is not relaying the 183 Dialog-2 towards UAC when it receives UPDATE with preconditions from UAS for Dialog-1.

Impact: The SBC was not relaying the second dialog 18x to ingress after the completion of preconditions UPDATE for first dialog during downstream forking scenario

Root Cause: The SBC was consuming the second dialog 18x at egress and skipped further processing. When P-Early-Media value received as part of second dialog 18x had less precedence than that of previous dialog, the SBC did not process the second dialog 18x.

Steps to Replicate: 

1. Bring up the customer E2E setup.
2. From UAS sent 183 Dialog-1 with preconditions.
3. The SBC would send the UPDATE message for the preconditions met for dialog-1
4. UAS sends 183 Dialog-2 with P-E-M sendonly.

The code is modified to follow second dialog 18x and not to consider P-Early-Media value precedence during this process.

Workaround: Modify the value of P-E-M header to sendrecv using SMM.

The "Deleting the a=maxptime" SMM is not working after an SBC restart.

Impact: SMM with sdpContent not getting applied after restart.

Root Cause: At time of restart CPX trying to read SMM with sdpContent from the wrong path.

Steps to Replicate: 

1. Spawned an HA setup.
2. Configured SMM rule with sdpContent and run the scenarios.
3. Switchover the system and re-run the scenario.
4. Switchover again and re-run the scenario.

Fixed the path from where sdpContent will be read for a SMM action.

Workaround: Delete the SMM rule and configure again.

Dialog scope variable is not present after SMM reject on re-invite message.

Impact: Dialog scope variable is not present when it is saved in the request which is rejected by SMM reject Operation.

Root Cause: Dialog scope saved in case of rejected request seems to be not inserted in hash and freed.

Steps to Replicate: Run a Re-invite call flow and reject the re-invite with 488 and have a SMM Rule to store dialog scope variables for that re-invite,

The code is modified to address the issue.

Workaround: None.

Enabling the facstate flag can cause healthcheck timeout in SBC.

Impact: The 'facState' flag if enabled, may result in some potential crash that is caused by health check timeouts.

Root Cause: The thread that is writing per call key elements in to the file is taking more time and resulting in health check failures.

Steps to Replicate: Run the calls at 100cps rate for around 5 to 6 hours with flag enabled may hit the health check failure problem.

The code is modified to address the issue.

Workaround: Disable the facState flag.

Multiple threads are writing to same socket and causing issues.

Impact: In case of CE_switchover, active went down and standby did not come up as new ACTIVE which led to unstable state until the active becomes stable again.

Root Cause: To track a healthcheck, the VNFR used a ZMQ mechanism to send/receive messages from VNFCs. As a result, multiple threads tried to write at same time, which caused failure to send messages from VNFR to VNFCs.

Steps to Replicate: Run multiple CE switchovers with fix.

The code is modified to use the mutex to avoid  concurrent writing at same time with its lock/unlock mechanism.

If one thread is writing then other threads need to wait in queue until the previous one is not done.

Workaround: None.

The eventLog combined log size calculation does not consider the disk size properly.

Impact: For the SBC5400 product, the user is allowed to configure the maximum accounting file size and the maximum number of accounting files so that those files can consume up to 150GB of diskspace. However, the maximum amount of disk space allowed should be 80GB.

Root Cause: The code that calculates the limit did not properly compute the disk limit if the product was the SBC 5400.

Steps to Replicate: 

On an SBC 5400,
set oam eventLog typeAdmin acct fileSize 65535 fileCount 2047
[ok][2021-02-17 15:02:03]

commit
Aborted: 'oam eventLog typeAdmin': The fileSize and fileCount values configured for the event logs would result in a potential combined log file usage of 128.4GB, which exceeds the maximum of 80.0GB allowed
[error][2021-02-17 15:02:06]

The preceding error message should be displayed indicating that the maximum log file usage is 80GB.

The code is modified to properly compute the limit for the disk limit if the product was the SBC 5400. The disk limit is 80GB.

Workaround: Ensure that the sum of the filesize*fileCount for each of the SBC log files does not exceed 83886080.

There was an error when dumping System Diagnostics md5 files on the EMA.

Impact: The checksum files were not shown while generating a system dump through the EMA/PM.

Root Cause: The EMA/PM only searches for sha256 checksum files now, but the checksum generated was md5, so it was not visible in the list present in EMA GUI.

Steps to Replicate: Use the EMA/PM to generate System Dump, and verified the presence of sha256 checksum file for every tarball generated.

The code is modified so the System Dump program now generates a sha256 checksum, instead of md5. This is visible to EMA/PM.

Workaround: None.