SBC Core 08.02.05R007 Release Notes

PortFix SBX-116166 - The  SBC intermittently fails to handle a "Packet Too Big" event and keeps sending the unfragmented packet to the Gateway.

Impact: The IPv6 Path MTU Discovery does not work. The SBC uses the MTU of the outgoing network interface as the Path MTU. The SBC does not update the IPv6 Path MTU properly, even if a router in the path sends an "ICMPv6 Packet Too Big" message with a smaller Path MTU value. The large IPv6 packets require fragmentation to fit the Path MTU from the SBC and will not reach the SIP peer.

Root Cause: The Path MTU does not update the proper entry to the peer while performing the IPv6 route/fib lookup.  The "ICMPv6 Packet Too Big" message does not consider the ipInterfaceGroup and addressCotext fields.

Steps to Replicate:

1. The SBC sends IPv6 packets with a length of 1500 bytes toward the SIP peer when a path to the peer has a smaller MTU (e.g. 1280 bytes).
2. A router with the smaller MTU sends an "ICMPv6 Packet Too Big" message to the SBC.
3. The SBC, with the fix, adjusts the Path MT, performs the fragmentation, and sends fragments to the SIP peer.

The code is modified to add the ipInterfaceGroup and addressContext information when handling the "ICMPv6 Packet Too Big" message in the Linux kernel.

Workaround: Add subnet routes on the packet interfaces that are sent to the peer.

PortFix SBX-117888 - The CE_NodeX.log is getting too large.

Impact: The SBC flooded with logs in the CE_Node.

Root Cause: When the SBC invokes StrNPrintf and the destination space is less than the source, the SBC logs the sys_error to the CE_NODE. The accounting record has a limit of spaces and pass of only 128 bytes for contact header when invoked by the StrNPrintf. The StrNPrintf logs to the CE_Node because there is a  lack of destination space.

Steps to Replicate: 

1. Leg A calls Leg B.
2. Leg B responds with a 200OK.
3. The 200OK has a contact header with a total length that is greater than 129 bytes.

Remove the logging sys_err to CE_NODE. 

Workaround: Continue to monitor the CE_Node logs and delete them.

PortFix SBX-110490: IMS preconditions fail due to an UPDATE message race condition.

Impact: An UPDATE from the calling party is queued by the SBC because the SBC is waiting for an 200 OK for a previous update sent to called party. When a 200 OK is received, the SBC did not forward the queued UPDATE.

Root Cause: Precondition parameters received as part of an UPDATE from ingress endpoint are not updated in the egress CCB.

Steps to Replicate: 

1. Configure preconditions to 'transparent' on both legs.
2. Configure transmitPreconditions for "supported" on both legs
3. Create a script to include the difference in: precondition parameters in INVITE and UPDATE messages from ingress.
   invite: a=des:qos mandatory local sendrecv
   a=curr:qos local none
   a=des:qos optional remote sendrecv
   a=curr:qos remote none
   (AS script)183 in Progress: a=curr:qos local sendrecv
   a=curr:qos remote none
   a=des:qos optional local sendrecv
   a=des:qos mandatory remote sendrecv
   a=conf:qos local sendrecv
   (IAD script)update : a=curr:qos local sendrecv
   a=curr:qos remote sendrecv
   a=des:qos mandatory local sendrecv
   a=des:qos optional remote sendrecv
4. Send the update from the Ingress when the SBC is waiting for a 200 OK from the previous update it sent to egress.

Verify that the SBC sends the queued UPDATE once it receives the 200 OK for the first UPDATE.

The code is modified to set the precondition levels for support to 'transparent' on both legs in the following configurations:

• When the SBC receives precondition parameters (with precondition levels set to'transparent') as part of an UPDATE, the SBC saves the precondition parameters into the egress ccb.
• When the queued UPDATE message is processed, the SBC checks for the presence of the preconditions flag. If enabled, the SBC compares the precondition variables to send the update to the called party.

Workaround: Enable the "Disable media lockdown" flag in the IPSP for an egress leg so that the SBC does not send the first UPDATE.

PortFix SBX-114081: The SecGetTlsProfileDataByName() selects a TLS profile other than the configured one.

Impact: The SBC uses the wrong TLS profile.

Root Cause: The 'lookup by name' function returned with the wrong profile.

Steps to Replicate: 

1. Enable DBG INFO level logging.
2. Create two TLS profiles as described in the example below:
   set profiles security tlsProfile TEST_ACCESS cipherSuite1 rsa-with-aes-128-cbc-sha
   set profiles security tlsProfile TEST_ACCESS allowedRoles server
   set profiles security tlsProfile TEST_ACCESS authClient false
   set profiles security tlsProfile TEST_ACCESS v1_0 enabled
   commit
   set profiles security tlsProfile TEST cipherSuite1 rsa-with-aes-128-cbc-sha
   set profiles security tlsProfile TEST allowedRoles clientandserver
   set profiles security tlsProfile TEST authClient false
   set profiles security tlsProfile TEST v1_0 enabled
   commit
3. Assign a second profile to one of the sipSigPort.
4. Send PDU through the sipSigPort used in Step 3.
5. Check DBG log and look for error messages and compare the profile ID assigned in Step 2.

The code is modified for both TLS and DTLS profile lookup by name routines to return the requested profile.

Workaround: None.

The ActiveRegCount is greater on the INGRESS side.

Impact: When registration(s) take longer than 90 seconds to complete, the ingress zone’s activeRegs count can be incremented and not decremented when the registration terminates. This may cause the ingress zone’s activeRegs count to grow incorrectly, and never reach ZERO (even after all registrations are terminated).

Root Cause: The SIPFE and SIPSG RCB allocation/deallocation become out of sync, indirectly causing the ingress zone's activeRegs count to increment and not decrement.

Steps to Replicate: Perform the endless REGISTER/403, or REGISTER/503, or REGISTER/603 sequence.

The code is modified to handle registration(s) that take longer then 90 seconds to complete. In this case, the SIPFE restarts the registration bind timer (and not "prematurely" deallocate the RCB) so that the FE and SG RCB(s) stay "in-sync".

Workaround: None.

PortFix SBX-113610: Deleting of an adProfile entry caused the PES Process to coredump.

Impact: The PES Process dumps core when an AD profile entry is deleted.

Root Cause: While synchronizing the data from remote domain controller, the PES fetches the AD profile once from the cache and uses the object for various decision making. So, if the ad profile is deleted, the object reference becomes NULL, and it dumps core.

Steps to Replicate:  To create an AD profile, create the dependent profiles.

1. Create an AD Attribute Profile.
   set profiles adAttributeMapProfile DEFAULT_AD_ATTRIBUTE_PROFILE adAttributeList adAttribute1 adAttributeName cn
   set profiles adAttributeMapProfile DEFAULT_AD_ATTRIBUTE_PROFILE adAttributeList adAttribute2 adAttributeName displayName
   commit
2. Create a domain controller profile
   set global servers domainController dc0 userName DcUsername password DcPassword primaryAddress DcIpAddress searchScope base=engineering,dc=some,dc=com ldapQueryCriteria cn=*
   commit
3. Create an AD profile:
   set profiles adProfile DEFAULT_AD_PROFILE delayedSync 2021-09-29T14:00:00 syncInterval 1440 sync enable adServerList 1 dcServer dc0
   commit

After 1-2 minutes of creating the AD profile, delete it.

The code is modified to prevent deleting the AD profile. If you require, for some reason, to stop the synchronization, disable the sync option on the AD profile.

Workaround: If the AD profile is not required, do not  delete the AD Profile but disable the sync option on it. This will stop all the future auto sync operations.

PortFix SBX-109103: An incorrect UDP port was used in Record-Route and Contact on core side.

Impact: The SBC populates invalid port in Contact/Record-Route header towards IMS Core side in call progress (180/200) responses.

Root Cause: During the call progress process, the signaling engine in the SBC modifies the ports without validating the direction of message flow causing the SBC to populate an Invalid port in the SIP responses.

Steps to Replicate: 

1. Send an IMS-AKA registration request from a UE device.
2. Ensure the IMS-AKA registration is successful.
3. Let the registered user receive a call from IMS network.
4. When the UE accepts the call, we can observe in the call progress response sent from the SBC towards the IMS that the SBC Core will have the invalid port in contact/Record-Route headers.

Flow: IMS Core --(SIP UDP)-> SBC ---(SIP IPSec TCP)--> Peer 

The code is modified to know the direction of the call progress before changing ports, and can change only when the flow is towards UE.

Workaround: Use the  SMM to change the ports in the Contact and Record-Route headers.

PortFix SBX-103228: Excessive logging and fast log rolling observed even at MAJOR level

Impact: When testing with Registration CAC enabled, this message is written aggressively per call, and contributes to high disk I/O and ENM processing.

MAJOR .SIPFE: *SipFeEpCacUpdateHpcValues:1506 peer was not static returning.

Root Cause: The message is written at the MAJOR level per call causing frequent log rolling.

Steps to Replicate: Enable registration CAC and make a call. This message is logged for every call and is basically useless at the MAJOR level.

The code is modified so the log event is moved to the INFO level.

Workaround: None.

PortFix SBX-112010: User is Registered on UDP and INVITE (same port/IP) on TCP fails with 403.

Impact: User is Registered on UDP and INVITE (different port) on TCP fails with 403.

Root Cause: Once maskportforRcb flag is enabled, parent RCB is found but child RCB is not. Mask port and mask IP were not considered during child creation.

Steps to Replicate: 

1. Enable maskportforRcb Flag and on ingress side set require registration to required.

2. Send register and receive 200 OK with p-Associated URI (To create child RCB) on UDP.

3. Send an INVITE with child user on TCP without specifying the port.

4. Verify RCB is found and INVITE is routed properly.

The code is modified to ensure that mask port and mask IP are considered during child creation.

Workaround: None.

PortFix SBX-108325: The SBC failed to upgrade to the SBC2, and the SBC2 did not take over.

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

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

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

The code is modified so that the data is consistent.

Workaround: Fix HA link stability issues

PortFix SBX-112091: The SBC is not passing UPDATE to Egress at all.

Impact: The SBC has received two 180 responses (the first is unreliable and the second is reliable) both with same SDP. As a result, the SBC is not passing UPDATE to Egress.

Root Cause: The SBC has received two 180 responses (the first is unreliable and the second is reliable) both with the same SDP, if the SBC sends out a SDP during the unreliable 180, the offer answer state will not get updated after the second 180 according to code

Steps to Replicate:

1. Set the sendSdpInSubsequent18x disable.
2. Set the sendSdpInSubsequent18x enable.
3. Change the SDP in the first unreliable 180 and the second reliable 180. In this case, the SDP gets queued. However, the 180 ringing sent out to Ingress has current SDP in this case and offer answer is completed.
4. Run the same SDP in the first nonreliable 180 and the second reliable 180 in this case offer answer state completed.

The code is modified so the SDP is not listed in an unreliable 18x message and offerAnswer state is not updated. The code is also modified for the 18x updates in the offerAnswer state.

Workaround: None.

PortFix SBX-112561: Regexp string was not exported by “user-config-export”

Impact: In the Regex, the SMM is lost while exporting a configuration using the user-config-export CLI command.

Root Cause: The XML formatting is trimming empty node values.

Steps to Replicate: 

1. Create the SMM Profile using the following command strings:
   
   set profiles signaling sipAdaptorProfile ESMM state disabled
   set profiles signaling sipAdaptorProfile ESMM advancedSMM disabled
   set profiles signaling sipAdaptorProfile ESMM profileType messageManipulation
   set profiles signaling sipAdaptorProfile ESMM rule 1 applyMatchHeader one
   set profiles signaling sipAdaptorProfile ESMM rule 1 criterion 1 type message
   set profiles signaling sipAdaptorProfile ESMM rule 1 criterion 1 message
   set profiles signaling sipAdaptorProfile ESMM rule 1 criterion 1 message messageTypes requestAll
   set profiles signaling sipAdaptorProfile ESMM rule 1 criterion 2 type header
   set profiles signaling sipAdaptorProfile ESMM rule 1 criterion 2 header
   set profiles signaling sipAdaptorProfile ESMM rule 1 criterion 2 header name WWW-Authenticate
   set profiles signaling sipAdaptorProfile ESMM rule 1 criterion 2 header condition exist
   set profiles signaling sipAdaptorProfile ESMM rule 1 criterion 2 header numberOfInstances number 1
   set profiles signaling sipAdaptorProfile ESMM rule 1 criterion 2 header numberOfInstances qualifier equal
   set profiles signaling sipAdaptorProfile ESMM rule 1 criterion 3 type parameter
   set profiles signaling sipAdaptorProfile ESMM rule 1 criterion 3 parameter
   set profiles signaling sipAdaptorProfile ESMM rule 1 criterion 3 parameter condition exist
   set profiles signaling sipAdaptorProfile ESMM rule 1 criterion 3 parameter paramType generic
   set profiles signaling sipAdaptorProfile ESMM rule 1 criterion 3 parameter name realm
   set profiles signaling sipAdaptorProfile ESMM rule 1 action 1 type header
   set profiles signaling sipAdaptorProfile ESMM rule 1 action 1 operation regsub
   set profiles signaling sipAdaptorProfile ESMM rule 1 action 1 headerInfo headerValue
   set profiles signaling sipAdaptorProfile ESMM rule 1 action 1 from
   set profiles signaling sipAdaptorProfile ESMM rule 1 action 1 from type value
   set profiles signaling sipAdaptorProfile ESMM rule 1 action 1 from value 172.xx.xx.xxx
   set profiles signaling sipAdaptorProfile ESMM rule 1 action 1 to
   set profiles signaling sipAdaptorProfile ESMM rule 1 action 1 to type header
   set profiles signaling sipAdaptorProfile ESMM rule 1 action 1 to value WWW-Authenticate
   set profiles signaling sipAdaptorProfile ESMM rule 1 action 1 regexp
   set profiles signaling sipAdaptorProfile ESMM rule 1 action 1 regexp string "
   "
   set profiles signaling sipAdaptorProfile ESMM rule 1 action 1 regexp matchInstance all
   commit
2. Run the following CLI command to export the configuration:
   user-config-export test.xml /profiles/signaling/sipAdaptorProfile
3. Delete the exported profile from the CLI with the following command:
   delete profiles signaling sipAdaptorProfile ESMM
   commit
   user-config-import test.xml
4. Run the following command:
   show configuration profiles signaling sipAdaptorProfile | display set | match string
5. Check if the Regex string field, and restore the original value.

The code is modified to use the external tool "xmllint" to format the XML.

Workaround: Manually edit the field in the XML file after an export and before an import to correct the issue.

PortFix SBX-112307: The customer SBC 7000 SIPREC metadata does not contain the ‘AOR’ parameter value.

Impact: In the SIPREC metadata sender and receiver, the AOR fields for the customer URI were not populated properly.

Root Cause: Due to a defect in the design, these fields were populated incorrectly.

Steps to Replicate: 

1. Configure the SBC with the SIP Rec server.
2. Run a basic call with "tel" URI in the From and To headers.

The code is modified to populate as per the requirements/standard.

Workaround: None.

A Customer SBC rebooted unexpectedly. 

Impact: A misconfiguration of GW Signaling Ports, in which there is a Secondary GW Signaling Port configured but no Primary GW SIG Port was configured, can lead to a core and switchover.

Root Cause: When there is no Primary GW Signaling Port configured but there is a Secondary Signaling Port configured, we enter a code path that attempts to dereference a NULL pointer (pointer to Primary SIG Port) when it is attempting to get the DSCP value to use for the socket.

Steps to Replicate: 

1. Configure an SBC with a Secondary GW Signaling Port without configuring a Primary GW Signaling Port.
2. Send a GW-GW call from a remote GW through this SBC using the address of the Secondary GW Signaling Port on this SBC.

Without the fix, a core occurs.

With the fix, no issue is encountered.

The code is modified to prevent it from attempting to dereference a NULL pointer (pointer to Primary SIG Port) when it is looking up the dscp value to use for the socket.

Workaround: Avoid configuring a Secondary GW Signaling Port without configuring a Primary GW Signaling Port.

There was an unexpected switchover on the SBC 5000.

Impact: The SAM process cored when the SIP code was attempting to lookup an internal SIP Registration Control Block.

Root Cause: The core was the result of the SIP code attempting to use an invalid index when accessing an array element for the purposes of finding a internal SIP Registration Control Block.

Steps to Replicate: This issue was not reproducible. A code inspection revealed the root cause, which is now corrected.

The code is modified to prevent the use of an invalid index when accessing an array element.

Workaround: None.

The Active Register per TG shows more than the total stable registration.

Impact: Under some condition(s), the ingress zone’s activeRegs count increases, but does not decrease when the registration terminates. This causes the ingress zone’s activeRegs count to grow incorrectly, and never reach ZERO (even after all registrations are terminated).

Root Cause: The SIPFE and SIPSG RCB allocation/deallocation become out of sync, indirectly causing the ingress zone's activeRegs count to increase, but not descrease.

Steps to Replicate: Perform REGISTER/401 - REGISTER/403 until the ingress zone activeRegs count issue is detected.

The code is modified to correctly handle the SIPFE's registration bind timer expiration. 

Workaround: None.

PortFix SBX-109200: Missing CDR for Teams call transfer scenario.

Impact: For an MS Teams blind transfer scenario with tonesAsAnnouncements enabled, where the MS Teams user A establishes a call to PSTN user B, then MS Teams user A establishes a call to user C and then invokes a blind transfer to establish the call between B and C. When the call is subsequently cleared, one of the CDR STOP records for the call is not generated.

Root Cause: When the tonesAsAnnouncements are enabled, after a blind transfer is initiated from user A, the subsequent call clearing logic is not correctly deactivating the internal announcement resources causing the call to not fully clear internally which results in STOP record not being generated.

Steps to Replicate: With the SBC configured for MS Teams having DLRBT with announcementBasedTones enabled.

Procedure
--------------

1. Establish a call from MS Teams User A to PSTN user B.
2. Establish a call from MS Teams user A to PSTN user C.
3. Initiate a blind transfer from MS Team user A, between user B and user C.
4. Clear the call and check CDR records.

Expected Results
-----------------------
Calls, transfer and announcements should be successful.

The SBC should generate START and STOP CDR records for A-B and A-C call.

The code is modified to correctly deallocate announcement resources for this call scenario so subsequent call clear can complete successfully and generate the correct CDR stop records.

Workaround: The call scenario works as expected by disabling tonesAsAnnouncements.

When the call is dipped the invite sends only the LRN.

Impact: When ingress INVITE's DIVERSION header does not present and TO header is different from RURI, i.e., it has redirecting original number, the egress RURI will take translated number, i.e., LRN, as RURI in egress INVITE, after LNP dip.

Root Cause: The RURI should take LRN in egress, while DIVERSION header in ingress presents. But the code change for a previous issue has made RURI equal to LRN even DIVERSION header was missing.

Steps to Replicate: 

1. Set up SIP to SIP LNP call, on the SBC and external PSX system.
2. Configure the TO header username (phone number) so it is different from RURI.
3. Ensure there is no DIVERSION header.

This should reproduce the problem and test the fix.

The code is modified the condition to only set RURI equal to LRN while DIVERSION header presents.

Workaround: None.

The SBC is sending a481 for CANCEL in dialog transparency.

Impact: When dialog transparency is enabled and call loops back to the SBC, the SBC does not handle CANCEL sent from ingress endpoint.

Root Cause: The SBC expects a CANCEL to have callinfo header.

Steps to Replicate: 

1. Reproduce the issue by running the following configuration:
   Dialog Transparency is enabled + Call Loops back In.
   After PRACK, Ingress sends CANCEL without callinfo header.
   The SBC sends 481.
2. With a fix, the SBC sends 200OK for CANCEL and relays to egress leg.

The code is modified to ensure the SBC finds the correct SG to handle the CANCEL even when a CANCEL does not have callinfo.

Workaround: None.

The LHXSBCK Redundancy triggered a switchover.

Impact: Dumping core in the IPsec/IKE code when a call is using an IKE Protection Profile that was configured without any algorithms.

Root Cause: We are coring in IPsec/IKE code due to an attempt to dereference a NULL pointer. The pointer is NULL because the IKE Protection Profile being used was configured without any algorithms.

Steps to Replicate: Configure an IKE Protection Profile without any algorithms.
Run a call that will use this profile.

The code is modified to check for a NULL pointer and take the correct error path when the pointer is NULL.

Workaround: When configuring an IKE Protection Profile, ensure that an algorithm is configured for this profile.

PortFix SBX-112445: Conference calls fail when taking a recorded (SIPREC) path, but they work when SIPREC settings are not enabled.

Impact: The SBC performs a cleanup a call during hold retrieval for the transferred call. This issue observed only when the SIP Rec is enabled.

Root Cause: Observed an invalid operation on media resource during call hold/unhold for the transferred call leads call to cleanup. This issue observed only when SIP Rec is enabled.

Steps to Replicate: 

1. Enable the SIP Rec.
2. Make a blind/attended call transfer and after a successful transfer, perform a call hold and unhold.

The code is modified to not perform any invalid operation on media resources during call hold/unhold for the transferred call.

Workaround: None.

Portfix SBX-110755: ACL rules configured with ipInterface are disabled on every SBC start/restart in the SBC5400/10GB pkt configuration.

Impact: IPACL rules created with ipInterface defined are not getting installed on 5400 systems when there is no license present, or after a license is added.

Root Cause: The NP will not install an IPACL rule with an ipInterface defined if that interface is not UP and active. The SBC will retry to install failed rules when it sees the port come up. In this scenario the timing is off, however, it tries too soon as the physical port is up but the associated ipInterface is not yet up.

Steps to Replicate: The test involves a 5400 without a license for its 10G packet port. The IPACL rules with ipInterface defined on that packet port will then fail to install. Once the license is successfully added, the IPACL rules should be installed.

The fix involves adding an additional delay before attempting to reinstall the failed IPACL rules when the port comes up. A check is also added to look for an additional failure, in which case it will start a timer and try again.

Workaround: To work around this issue, do not use IPACL rules with ipInterface defined.

Increased the healthcheck interval.

Impact: Core dumps 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 checks.

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 needs to have 15 consecutive non responses in order for the process to be declared deadlocked and a coredump initiated to recover.

Workaround: None.

PortFix SBX-112304: The SBC discards incoming STUN packets after a second call hold and the call switched from a DM call to a passthru call when going on-hold.

Impact: When a call with ICE changes from direct media to passthru due to 200 OK response, ICE learning does not get enabled on the call.

Root Cause: The code was not re enabling the ICE learning when 200 OK caused a change from direct media to passthru.

Steps to Replicate: 

1. Establish call with ICE on ingress and xdmi on egress, such that call is established as direct media.
2. Send a re-INVITE from ingress to put call on hold, when re-INVITE is received at egress, respond with 200 Ok without xdmi and complete the re-INVITE related signaling.
3. Send stuns to ingress media to complete ICE learning and verify call state changes to established and ICE learning shows as completed.
4. Send a re-INVITE from the ingress to take call off hold, when an re-INVITE is received at egress, respond with 200 Ok without xdmi and complete the re-invite related signaling.
5. Verify that the media can be exchanged between ingress and egress.

The code is modified to re-enable the ICE learning when changing from direct media to passthru to allow receipt and processing of STUN messages to complete ICE learning,

Workaround: None.

There is a misleading TRC message when issuing the callTrace action command start command.

Impact: A misleading TRC message when issuing the "callTrace action command start command".

Root Cause: There was no alarm/log message when running a indicating global call trace start action command.

Steps to Replicate: Run the issue callTrace action command and observe the Trace log.

admin@vsbxsus2> request global callTrace action command start

Sonus Networks, Inc.0000000001600000000000000000000128V08.02.06A002 0000000000000000000000000000TRC2021082014593700000000000000
072 08202021 145941.298910:1.01.00.00002.Info .NRM: Call Trace Reset

The code is modified to display correct message indicating call trace being reset.

Workaround: None.

PortFix SBX-109811: The SBC uses port number RTP+1 for RTCP instead of the learned RTCP port number if the RTCP NAT learning completes before RTP NAT learning.

Impact: The SBC sends the RTCP packets to a destination port number RTP+1 for the RTCP instead of the learned RTCP port number if the RTCP NAT learning completes before RTP NAT learning.

Root Cause: The SBC overwrites the learned RTCP port number with the RTP+1 port number if the RTCP is learned before RTP.

Steps to Replicate: Send RTCP packets first then RTP packets to the SBC. After call is connected, verify the RTCP port number, if RTCP is learned before RTP.

The code is modified to use correct RTCP learned port when RTCP learning occurs before RTP, instead of comparing the RTP and RTCP addresses from callLeg structure.

Workaround: No workaround.

PortFix SBX-108370: The top2 on the SBC takes lot of CPU cycles.

Impact: The SBC performance monitoring tools, such as top2, at times take 20% of a CPU core there by reducing total available CPU resources for management activities on the SBC.

Root Cause: Introduced nice values to sbxPerf commands but still top2 taking around 20-30% at times. So check ways to optimize it to take less CPU using /root/.top2rc.

Steps to Replicate: Install the fix build and use the top command to ensure the CPU utilization of top2 should not be much CPU utilized.

The code is modified to take less CPU utilization of SBX performance monitoring tools like top2.

Workaround: None.

There was an SCM memory growth on Standby.

Impact: The standby SIPSG is leaking memory that was allocated on the Standby for storing the Transit IOI value that was configured in the SIP Trunk Group.

Root Cause: The standby SIPSG is leaking memory that was allocated on the Standby for storing the Transit IOI value that was configured in the SIP Trunk Group. A pointer to this memory is linked off the the call block. This memory should be freed whenever the call block is freed - but this was not happening.

Steps to Replicate: 

1. Configure Transit IOI in Sip Service Group.
2. Make multiple calls.
3. Check for leak on the Standby.

The code is modified to free this buffer.

Workaround: This leak can be avoided by removing configuration of Transit IOI in SIP Trunk Group.

PortFix SBX-112448: The LSWU Register Object is missing from the SMM Dialog Scope Variables fields.

Impact: The LSWU Register Object is missing for the SMM Dialog Scope Variables fields, which means that the values would not be maintained for stable calls following a switchover.

Root Cause: The LSWU Register Object is missing from the following SMM Dialog Scope Variables fields:

SIPSG_MSG_PARAM_REDUND_FIELD_TYPE_INGRESS_SMM_DLG_VAR
SIPSG_MSG_PARAM_REDUND_FIELD_TYPE_EGRESS_SMM_DLG_VAR

Steps to Replicate: 

Perform LSWU with active calls where SMM that uses dialogue variables is applied to the active call. Check that no messages similar to the following are seen in the logs:

PsObjectFactoryManager: Failed to find object's prototype while operating on object ID 147027 (0x23e53)
PsObjectFactoryManager: Failed to find object's prototype while operating on object ID 147028 (0x23e54)

The code is modified for the following fields to address the issue:

SIPSG_MSG_PARAM_REDUND_FIELD_TYPE_INGRESS_SMM_DLG_VAR
SIPSG_MSG_PARAM_REDUND_FIELD_TYPE_EGRESS_SMM_DLG_VAR

Workaround: None.

There was a memory leak since upgrading to v8.2.5R0.

Impact: There are 2 leaks of the same structure that have been fixed with this issue.

1. A memory leak is seen when a relayed SUBSCRIBE message is cranked back and an Alternate Server cannot be found.
2. The code that handles relayed messages may cause a leak in certain error scenarios.

Root Cause: 

1. The code that handles the case of a relayed SUBSCRIBE message that is cranked back and an Alternate Server cannot be found takes an incorrect path through the code - thereby bypassing the code that would free the leaked structure.
2. The code that handles relayed messages may cause a leak in certain error scenarios because the Relay Control Block is not being freed.

Steps to Replicate: 

1. This is a memory leak that may be triggered if a relayed SUBSCRIBE is cranked back and then an Alternate Server is not found.
2. We have been unable to reproduce the other error scenario that causes a leak of the Relay Control Block.

The code is modified to:

1. Take the correct path when an Alternate Server cannot be found while handling a relayed message that has been cranked back.
2. Start a timer when processing a relayed message. In error cases, the Relay Control Block is freed when the timer expires - preventing the structure from leaking.

Workaround: None.

The SBC had a Crash-Application in the rebooting loop.

Impact: A PRS Process core is occurring when the code is processing an ICE STUN packet and there are more than 20 Teams clients ringing. This could potentially happen in a simultaneous call group pickup scenario.

Root Cause: The root cause of the core is a bug in the code that handles the incoming STUN packet. This code is overwriting the end of array by writing too many entries into the array. This results in memory corruption and eventually a core.

Steps to Replicate: Run a call group pickup scenario with more than 20 users all having their Teams clients ringing at the same time.

The code is modified to prevent it from writing too many entries into the array.

Workaround: Disable media-bypass or reduce the number of users in the call group.

PortFix SBX-111126: In case of a delayed offer, the SBC changes the attribute “a=sendonly” into “a=recvonly” before relaying the 200 OK INVITE.

Impact: The direction attribute in the 200OK sent in response to late media re-INVITE is set to an incorrect value when the direction attribute received in 200OK from the other side is a value other than a=sendrecv.

Root Cause: The datapathmode on the side receiving the late media invite is incorrectly copied from the SBC local datapathmode from the answer leg PSP receiving 200OK when sendSbcSupportedCodecsInLateMediaReinvite flag is enabled.

Steps to Replicate: 

1. Enable the sendSbcSupportedCodecsInLateMediaReinvite on TG towards UAC.
2. Send a direction attribute a=sendonly/recvonly/inactive from UAS.

3. Ensure the 200OK sent to the UAC includes the direction attribute as expected (a=sendonly/recvonly/inactive, respectively) and media is as per expectation.

   UAC---------------------------------SBC------------------------------------------------UAS
   INV(no sdp)->
   INV(a=sendrecv)->
   <-200OK(a=sendonly/recvonly/inactive)
   <-200OK(a=sendonly/recvonly/inactive)
   ACK(sdp)->
   ACK(no sdp)->

The code is modified so the datapathmode in the active PSP on late media offer side is recomputed when the sendSbcSupportedCodecsInLateMediaReinvite flag is enabled.

Workaround: Disable the sendSbcSupportedCodecsInLateMediaReinvite IPSP flag on TG receiving late media re-INVITE.

PortFix SBX-110302: A late offer call resulting in the SBC not sending DTMF for AMR-WB in initial offer towards ingress.

Impact: The SBC is not sending DTMF for AMR-WB in initial offer towards ingress in a late media call.

Root Cause: If the PSP initially contains 8k dtmf PT, then the SBC skips over this PT value without accumulating. As a result, the 16k dmtf also takes the same value as the 8k dtmf PT.

Steps to Replicate: Configuration:

Transcode conditional
rel100Support enabled
honorSdpClockRate enabled
DLRBT enabled
Configure multiple codecs on both routes.

To re-create the issue:

1. The UE initiates a Late media convert call.
2. The SBC sends out an 180 answer with the below SDP:
   
   m=audio 1024 RTP/AVP 96 8 97 0 18 9 101
   a=rtpmap:96 AMR-WB/16000
   a=fmtp:96 mode-set=0,1,2; mode-change-capability=2; max-red=0
   a=rtpmap:8 PCMA/8000
   a=rtpmap:97 AMR-WB/16000
   a=fmtp:97 mode-change-capability=2; max-red=0
   a=rtpmap:0 PCMU/8000
   a=rtpmap:18 G729/8000
   a=fmtp:18 annexb=no
   a=rtpmap:9 G722/8000
   a=rtpmap:101 telephone-event/8000
   a=fmtp:101 0-15

Test Result without Fix: The SBC drops the telephone-event/16000 payload type for Late media.

The code is modified to ensure both 8k and 16k DTMF go with correct PT values.

Workaround: None.

PortFix SBX-111720: There was an SCM Process core in the SMM area.

Impact: The SBC may coredump when using the SMM and regex to modify the fieldvalue of request-line.

Root Cause: The SBC was accessing a corrupted pointer, which caused the issue.

Steps to Replicate: Run a SMM using regex to modify fieldvalue of request-line.

Note: This may not be reproducible due to the nature of the access pointer.

The code is modified to address the issue.

Workaround: Change the fieldValue to headerValue. Or change the rule not to use regex.

Portfix SBX-109324: The crankback function does not work if the egress TG is locally OOS.

Impact: This issue occurred only for domain based routing. In case a TG is locally set to out of service, the policy request sent to PSX was not proper for the next route. The domain name in the called URI section of policy request was not updated. So, the SBC was sending an old domain name in Policy request. As a result, PSX server was sending previous route, not the current route.

Root Cause: In case a TG is set to out of service, the domain name in called URI section of policy request was not updated while sending policy request for next route.

Steps to Replicate: 

1. Configure multiple routes using domain based routing.
2. Set one of the routes to out of service.
3. Set the force re-query flag to true in egress IPSP profile.
4. Make a call and send a 3xx with multiple routes in contact header.

After this fix, the SBC should not stop at the out of Service TG. Instead it should try all contacts with TG state as In service.

The code is modified so the domain name in called URI section of policy request is updated properly.

Workaround: None.

Portfix SBX-109384: The 8.2.4F001 SBC 5400 Global level SMM stopped to work.

Impact: The Global SMM function stopped working post upgrade and similar issue was observed after multiple switchovers.

Root Cause: The Global SMM configurations were not being restored.

Steps to Replicate: 

1. Attach an SMM at global level (for 200ok of pathcheck options).
2. Perform multiple switchovers or LSWU to another build.
3. Check if the SMM is being applied.

The code is modified to address the issue.

Workaround: Delete the profile set at global level and configure it again.

PortFix SBX-110323: A SWe media Issue occurred after an active reboot

Impact: Media issue after switchover.

Root Cause: Before a switchover, the loopback call was set up with 2:xx:xx:x:x:x (vbsc1's pkt port mac address) for both src and dst MAC address. After switchover, from packet capture, we found that the SRC MAC address= 2:xx:xx:x:x:xx (vsbc2's pkt port mac address). As a result, using the srcMac and dstMac caused a media issue.

Steps to Replicate: Use the following configurations to test:

• Set up loopback and normal calls for both SBC HW and SWe platforms.
• Do port and SBC switchovers.
• Use single and alternate media IP addresses on the loopback ports.

The code is modified to use loopback flag mirrored to standby BRM, and overwrite both srcMac and dstMac if loopback flag is set to true. This is done only on SWe when enabling or modifying the RID.

Workaround: No workaround.

PortFix SBX-106760: Performance: While running IMS AKA Registrations on SWe KVM, cannot achieve 1000 subscribers with 30 RPS properly.

Impact: The SBC was not able to achieve the IMS AKA registrations even at a lower rate (30 registrations per second).

Root Cause: For one of the IPsec features, the XRM code was modified to perform route lookup and next hop destination MAC resolution during IPsec SA setup. This was causing a delay in setting up IPsec SAs during load causing timeouts during the IMS AKA registration.

Steps to Replicate: Run the IMS AKA Registration load at 30rps.

The code is modified to not invoke the route loopup and destination MAC resolution code that is causing delay in setting up IPsec SA, which addresses the issue.

Workaround: None.

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.

The SBC 7000 LSWU from 6.2.3F007 to 8.2.4F001 stopped after the standby upgrade completed.

Impact: Synchronization may abort and never complete during an LSWU when the relay command block mirror message does not contain a Call ID.

Root Cause: Creation of the relay control block on the standby system fails when the relay command block mirror message does not contain a Call ID.

Steps to Replicate: Send relay command block mirror message that does not contain a Call ID during an LSWU.

The code is modified so that it does not fail and abort the synchronization. The relay command block mirror message is modified to not contain a Call ID.

Workaround: None.

PortFix SBX-109968: The 822R0 SCM Process core dumped.

Impact: The SCM Process core dumped on a SWe.

Root Cause: Active SCM sent a Redundancy message to Standby SCM with a Registration index that was outside of its MAX range. The error handling code caught this and attempted to clean up the Registration Control Block but had a problem because the Control Block had not yet been initialized.

It is most likely triggered by a race condition that results in the Active and Standby to have different numbers for max number of Registrations (on a SWe the max number of Registrations comes from the file callEstimates.txt and in this case, the files on the active and standby do not match).

Steps to Replicate: This problem is not reproducible.

This appears to be a SWe specific issue (the callEstimates.txt file is only used in SWE setups).

The code is modified to initialize the Registration Control Block immediately after allocating it, before any validation checks, so that the error handling code can clean up the RCB without causing a core.

Workaround: There is no known workaround.

A Registration structure update is needed to prevent hijacking/hacking of the user after being rejected with a 403 Forbidden error.

Impact: After a hack, the registers rejected with 403 Calls were not working.

Root Cause: Both a normal and hacker user had very similar Register messages, except that the hacker's Auth header did not include the correct username. Due to this username mismatch, the SBC rejected the hacker with a 403 message, set the Register into 'challenged' state and later deleted the message.

Steps to Replicate: There are 8 combinations of test cases. The major difference is in the username field Auth header.

Test1:

1. Proper registration: Reg->401→Reg (with Auth)→200
2. Hacker registration: Reg->401→Reg (with hacker Auth)→403
3. Proper user refresh
4. Hacker registration: Reg->401→Reg (with hacker Auth)→403

Check for all fields and expiration timer.

Test2:

1. Proper registration: Reg->401→Reg (with Auth)→200
2. Hacker registration: Reg->401→Reg (with hacker Auth)→403
3. Proper user refresh
4. Hacker registration: Reg (with hacker Auth)→403

Test3:

1. Proper registration: Reg->401→Reg (with Auth)→200
2. Hacker registration: Reg (with hacker Auth)→403
3. Proper user refresh
4. Hacker registration: Reg->401→Reg (with hacker Auth)→403

Test4:

1. Proper registration: Reg->401→Reg (with Auth)→200
2. Hacker registration: Reg (with hacker Auth)→403
3. Proper user refresh
4. Hacker registration: Reg (with hacker Auth)→403

Test5:

1. Proper registration: Reg (with Auth)→200
2. Hacker registration: Reg->401→Reg (with hacker Auth)→403
3. Proper user refresh
4. Hacker registration: Reg->401→Reg (with hacker Auth)→403

Check for all fields and expiration timer.

Test 6:

1. Proper registration: Reg (with Auth)→200
2. Hacker registration: Reg->401→Reg (with hacker Auth)→403
3. Proper user refresh
4. Hacker registration: Reg (with hacker Auth)→403

Test 7:

1. Proper registration: Reg (with Auth)→200
2. Hacker registration: Reg (with hacker Auth)→403
3. Proper user refresh
4. Hacker registration: Reg->401->Reg(with hacker Auth)→403

Test 8:

1. Proper registration: Reg (with Auth)→200
2. Hacker registration: Reg (with hacker Auth)→403
3. Proper user refresh
4. Hacker registration: Reg (with hacker Auth)→403

The code is modified so when the SBC rejects the hack because of a username mismatch in the Auth header, it reverts back to previous details and state (that is complete).

Workaround: None.

PortFix SBX-105261: MS TEAMS - The Media Stats are not correct when the DLRBT profile is removed from TGs and ICE is enabled.

Impact: On an SBC was configured for MS Teams LMO centralized mode with ICE, if DLRBT is not correctly configured, this can lead to media not flowing correctly for a call even after ice learning gets completed.

Root Cause: The early ICE learning logic for non DLRBT mode in the SBC was not fully deactivating ICE media resources on receipt of 200 OK . As a result, the resources were unable to be re-activated for end to end media flow.

Steps to Replicate: On an SBC configured as MS Teams LMO centralized mode with ICE on MS Teams TG:

1. Disable DLRBT on PSTN and MS Teams TG's.
2. Establish a PSTN endpoint to MS Teams call that uses primary (Internal) LIF address towards Teams.
3. Once call has established and ice learning has completed, send media (voice) in both directions between PSTN and Teams endpoints.
4. Media should flow as expected in both directions and call Media status should correctly show the number of media packets sent and received for ingress and egress.

The code is modified to correctly deactivate early ice learning media resources on receiving an SDP from MS Teams.

Workaround: The DLRBT should be enabled.

PortFix SBX-104526: The emssftp fails in 9.1R1

Impact: In a EMS registered Cloud 1:1 SBC, the emssftp login was failing that blocks the EMS from carrying out various services on the SBC.

Root Cause: In 1:1 SBC, the code logic of getting emssftp credentials from EMS had some gaps that caused issues with storing and keeping passwords in sync between active and the standby SBC.

Steps to Replicate: After checking a login, after multiple reboots, rebuild with 1:1 and N: 1, along with 1-2 EMS registered.

The code is modified to get and store the emssftp passwords on both nodes of HA.

Workaround: None.

PortFix SBX-104334: The call dropped when being placed on hold - IPv6.

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

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

Steps to Replicate: 

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

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

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

PortFix SBX-101451: The DSP Threshold setting is not generating Trap on the SBC 5400.

Impact: The g711PacketThreshold, g729Threshold, and g726Threshold onset and abate traps are not sent.

Root Cause: The NRM did not receive CLI updates to g711PacketThreshold, g729Threshold, and g726Threshold, and trap generation code used wrong trap names.

Steps to Replicate: Provision threshold levels:
set oam traps dspAdmin dspAvailabilityTrap g729Threshold 40
set oam traps dspAdmin dspAvailabilityTrap g726Threshold 60
set oam traps dspAdmin dspAvailabilityTrap g711PacketThreshold 80
commit

set oam traps admin sonusSbxDspAvailG729OnSetCrossThresholdNotification state enabled
commit
set oam traps admin sonusSbxDspAvailG729AbateCrossThresholdNotification state enabled
commit
set oam traps admin sonusSbxDspAvailG726AbateCrossThresholdNotification state enabled
commit
set oam traps admin sonusSbxDspAvailG726OnSetCrossThresholdNotification state enabled
commit
set oam traps admin sonusSbxDspAvailG711OnSetCrossThresholdNotification state enabled
commit
set oam traps admin sonusSbxDspAvailG711PacketAbateCrossThresholdNotification state enabled
commit

Configure trap target:
set oam snmp trapTarget EMS160 ipAddress 10.xxx.xx.xxx port 162 trapType v2 state enabled
commit

Limit compression resources to make issue readily occur:
set system mediaProfile tone 98 compression 2
commit

Perform several transcoded (e.g., G711 to G729) calls that exceed threshold limits, and see onset traps are sent to the trap target.

Clear the transcoded calls, and see abate traps are sent to the trap target.

The code is modified to support g711PacketThreshold, g729Threshold, and g726Threshold.

Deprecated the support for allThreshold, as it was never implemented in the SBC.

Workaround: None.

PortFix SBX-106732: The CE_Node1.log getting filled up quickly

Impact: The CE_Node1.log got filled fast.

Root Cause: These prints where coming from stack trace dumps on SYS_ERR ( EVLOG ).

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

Converted SYS_ERR( EVLOG ) for concerned logs to NrmaDlog to address the issue.

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

PortFix SBX-108516: The Call Outage was leading to DSP errors.

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

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

Root Cause: 

1. A defect was found in XRM redundancy processing code where xres->options field was not updated on the standby XRM.
2. When modifying media flow in NP if RTCP relay monitor is being modified, 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 the rtcp-xr-relay-drop to TRUE.

1. Save the xres->options field in standby XRM.
2. Provide the rtcpMode in NP_MEDIA_RTCP_REL_MON_STR to NP.
3. When processing the media flow modify request, set the RTCP relay monitor state based on the value in NP_MEDIA_RTCP_REL_MON_STR.

Workaround: Disable the RTCP and RTCP termination in PSP.

PortFix SBX-104935: The Neighbor Advertisement at a high rate - >80 per second.

Impact: A port switchover process that was initiated due to a port failure that was not complete due to system call (ioctl()) timeout. This leaves the application (LVM) and NP in inconsistent state w.r.t port roles.

Root Cause: Based on the perf stats, it was observed that there were some process scheduling issues that resulted in Kernel timing out on MAC address update ioctl() call.

Steps to Replicate: As this issue is related to delay in process scheduling, there is no easy way to reproduce the issue.

The code is modified to handle the ioctl() returning timeout error. In case of other errors, the code is modified to restart application as that leaves the application in the inconsistent state with NP. The code is also modified to send GARPs 3 times instead of sending it once during port switchover.

Workaround: Reboot the instance.

PortFix SBX-105687: The SBC 5400 post upgrade to 9.1 SMM rule for options stopped working.

Impact: The SMM rules were not applied for PATHCHK OPTONS after upgrade to 9.1

Root Cause: The SBC fixed a bug to pick default trunk group for PATHCHECK OPTIONS method and its response. Due to this, the SMM applied on a user defined trunk group will not be used for PATHCHECK OPTIONS.

Steps to Replicate: 

1. Upgrade from 8.1 to any later release.
2. Attach the SMM at the global level for OPTIONS method or response.
3. Configure PATHCHECK so that the SBC generates OPTIONS method.

The code is modified to apply SMM at global level. So the PATHCHECK OPTIONS can use SMM attached at the global level.

Workaround: No workaround.

PortFix SBX-106722: The S-SBC application goes down with a MESSAGE call load of 11 cps or more.

Impact: The SCM coredumps while running a load of MESSAGE method and having Dialog scope variable in the SMM at the ingress.

Root Cause: The SBC is storing ingress dialog scope variable in the Relay CB that is already freed.

Steps to Replicate: 

1. Configure SMM with Dialog scope variable on both ingress and egress.
2. Run a 10 CPS MESSAGE call flow load.

Delaying Relay CB free until we send 200 OK for MESSAGE method

Workaround: Remove dialog scope variable in the SMM Rules at the ingress side

PortFix SBX-108557: The SBC continuously core dumps for SCM process since upgrading to V09.02.01R000.

Impact: The SCM has cored due to memory corruption.

Root Cause: There is code that is using an invalid buffer pointer when writing to a buffer.

This code was added in 9.2.1R0 and was ported to other branches. (This problem is most likely triggered by the receipt of an invalid PDU and/or an SMM rule.)

Steps to Replicate: This problem is most likely triggered by the receipt of an invalid PDU and/or an SMM rule to reject the incoming Invite. And it is random, therefore the issue may not reproduce all the time.

The code is modified to address the issue.

Workaround: If there is SMM rule (ignore the Invite), then the SMM rule need to disable.

PortFix SBX-107972: SBC: Multiple PRS Process coredumps on the pn both active and standby while running a 2 day EVS + T140 -> AMR-WB and T140 load.

Impact: The PRS Process coredumps during 2-3 nights load scenario.

Root Cause: The BRM had validity checks missing for npPoolID before accessing the memory.

Steps to Replicate: Setup:

1. SBC 2:1 - cluster with flavor 16vCPU/20GB RAM/CPU.
2. OAM 1:1 - Flavor 2vCPU/10GB RAM.

Procedure:

1. Start the Call load EVS and T140 to AMR-WB +T140 @20 cps and 13s CHT.
2. The SBC dumped multiple Prs_Process and SCM_Process coredump (Tracked as part of SBX-107799 )

The code is modified to address the issue.

Workaround: None.

PortFix SBX-107853: The SCM core was observed on a standby SBC wile running load with an SBC generated subscribe

Impact: There was an SCM core on Standby while running the load for Reg-Event subscription.

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

Steps to Replicate: 

1. Enable the configuration below 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.

PortFix SBX-105764: A core dump resulted for a TEAMS call flow.

Impact: There was a random crash observed during TEAMs call flow.

Root Cause: There was a Null Pointer exception that lead to SCM Process crash.

Steps to Replicate: Call scenario:

1. Transfer to PSTN end point.
2. Crash observed after re-Invite is received from TEAMs.

The code is modified to prevent a crash.

Workaround: None.

PortFix SBX-106920: The SBC: FmMasterProcess coredumps after a switchover with a stable call.

Impact: The FmMasterProcess core dumps during a 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 time sensitive and requires an event being published from AMF to FM at just the right time in the shutdown sequence. There is no way to reproduce the issue.

The code is modified to avoid the possibility of the deadlock.

Workaround: No workaround.

PortFix SBX-106951: Update the Sudo in the SBC OS to fix CVE-2021-3156: Heap-Based Buffer Overflow in Sudo (Baron Samedit).

Impact: Update the Sudo in SBC OS to fix CVE-2021-3156: Heap-Based Buffer Overflow in Sudo.

Root Cause: The 8.2.x SBC versions prior to 8.2.5R0 have CVE-2021-3156 Heap-Based Buffer Overflow in Sudo.

Steps to Replicate: 

Run the following configuration:

# dpkg -l sudo
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-====================================================-===============================-===============================-==============================================================================================================
ii sudo 1.8.19p1-2.1+deb9u3 amd64 Provide limited super user privileges to specific users
[root@vsbcSystem-ka-sbc1 10.xx.xx.xxx ~]#

The code is modified by applying OS Patch drift for SBC Version 8.2.5R0 that contains a fixed sudo version of 1.8.19p1-2.1+deb9u3.

Workaround: No workaround.

PortFix SBX-107586: The SAM Process coredumps while executing a DoS on the SWe SIP signaling port with malformed Register Message with 80 multiple unique and spoofed IP's.

Impact: The SAM Process coredumps while processing a malformed REGISTER message.

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

Steps to Replicate: Send a REGISTER message only with the Request-URI and no headers.

The code is modified to delete the RCB when the Username, Hostname or PhoneContext is NULL.

Workaround: Run in normal mode instead of sensitive mode for coredump.

PortFix SBX-105263: Observed the PRS Process coredump, followed by "DsPr, Ssre, Cpx" on both active and standby boxes of Openstack S-SBC HA pair and "Ccsp" process core on T-SBC active while running calls on 2CPS with ASAN build.

Impact: There was a memory leak detected by ASAN in an active S-SBC while running G711 to G729 transcoding load on the D-SBC.

Root Cause: ASAN reported a memory leak related to some pointers used to hold remote DSP resource.

Steps to Replicate: Re-run the same load in ASAN and ensure no memory leaks are detected.

The code is modified to free these pointers.

Workaround: None.

Abnormal switchover on the cluster SBC occured.

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

Root Cause: 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 faulty code.

Steps to Replicate: The problem is not reproducible, and the solution was found based on a code review. This is an edge case timing issue where an internal message is sent before a switchover, and the response is processed after the switchover.

The code is modified to validate the tcIcm pointer is not NULL before trying to use it and as a result, avoid the intentional system error crash.

Workaround: No workaround.

There was a switchover and coredump for a customer configuration.

Impact: The SCM Process may core while setting the DTMF relay on the call leg's active packet profile configuration.

Root Cause: There are cases when an active packet profile can be NULL before it sets the DTMF output, which can cause a SCM crash.

Steps to Replicate: Run a coredump analysis and code review.

The code is modified to check for activeProfilePtr before outputting the DTMF.

Workaround: None.

The ipAdaptiveTaransparencyProfile is not working for a re-INVITE coming from Egress.

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

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

Steps to Replicate: Test case 1:

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
2. When egress sends re-INVITE with modified PAI after call is connected , no re-INVITE is generated towards ingress side.

Test case 2:

1. Verify the issue.
2. 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 properly when the sipAdaptiveTransparencyProfile is configured for egress TG.

Workaround: None.

Unable to see video from Cisco 8865/9971 on the ConnectMe BYOD client.

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

Root Cause: The Non-RTCP binding resource was incorrectly picked by the SBC for video stream if the 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. Therefore, the code assumed the audio to be in pass-through mode.

Steps to Replicate: Configuration:

1. Configure the SBC for audio and video calls.
2. Enable the allowAudioTranscodeForMultiStreamCall in the 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 an 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 an audio pass-through call.

The DM/PM rules are ignored by ERE.

Impact: When launching the ENUM SIP AOR query, the ERE is losing the ability to run DM rules configured on the egress TG to the called number.

Root Cause: It is not a bug. It is a restriction in design. A DM on called and translated numbers were restricted if the ENUM service occurred.

Steps to Replicate: 

1. Set up the ENUM call.
2. Configure the egress TG DM rule to modify the called number.

Watch the policy response to see if the called number is expected.

The code is modified so the new flag "ALLOW DBRULE CALLED EGRESS" in ENUM Service Allows customer can bypass that restriction.

Workaround: None, if the DM rule on egress TG applied when ENUM service is used.

The SBC not adding ICE information when the same SDP content in multiple 18x messages is received

Impact: When an egress endpoint sends multiple 18x messages with the same SDP followed by a 200 OK, in certain configurations this causes the SBC to send a RE-INVITE to the ingress endpoint after the 200 OK. However, when ICE is configured on the SBC ingress trunk group, this re-INVITE does not include the expected ICE parameters.

Root Cause: The code that processes the SDP to send in the re-INVITE for this particular scenario is not correctly adding the ICE parameters.

Steps to Replicate: Test 1:

1. Create a setup equivalent to the MS Teams downstream SBC, with ICE enabled on Teams side and with no ICE on the PSTN side.
2. Enable the acceptAlertInfo on ipSignalingProfile associated with egress trunk group e.g.
   set profiles signaling ipSignalingProfile DEFAULT_SIP commonIpAttributes flags acceptAlertInfo enable

Procedure:

1. Send a valid INVITE to Teams TG with ICE parameters.

2. Responds from PSTN side with valid 183 progress message with SDP.

3. Send another 183 progress message from the PSTN side with the same SDP.

4. Send the 200 Ok from PSTN side with same SDP.

5. Verify that the SBC does not send a further re-INVITE to Teams side.

Results

1. The SBC sends an INVITE out to PSTN endpoint.
2. The SBC sends 183 progress to Teams side with valid SDP including ICE parameters.
3. The SBC sends another 183 progress to Teams side with valid SDP including ICE parameters (same as previous 183).
4. The SBC sends 200 Ok to Teams side with same SDP as in previous 183 messages.
5. The SBC should not send re-invite to Teams side.

The code is modified to either not send the RE-INVITE when there is no change to the SDP or to add the required ICE parameters if a re-INVITE is necessary.

Workaround: Certain scenarios cause this issue, for example if the acceptAlertInfo is enabled on egress ipSignalingProfile or ifthe  downstream forking is enabled. If such configurations are not necessary and can be disabled, the issue can be avoided.

The customer SBC clears a call when receiving a 200OK answer - CFNA call.

Impact: The SBC clears a call upon receiving an answer for a MRF transcoded call involving a egress UPDATE followed by tone play.

Root Cause: During a tone play, the SBC detaches the MRF resource from the call since the tone is played by the SBC. However, the media endpoint resource facing the MRF stays with the call that results in a failure later while assigning MRF resource back to the call when answering.

Steps to Replicate: The following events lead to the failure in this call flow:

1. Receiving a 183 with SDP from the egress leads to cut-thru (MRF transcoded call).
2. The egress peer sends a SIP UPDATE to the SBC.
3. Followed by an 180 from egress that arms the RTP monitoring at the SBC.
4. Followed by an RTP failure notification after 2 seconds that starts the Tone.
5. Followed by an answer that results in a failure.

Detach the media endpoint resource facing MRF from the call during tone play to address the issue.

Workaround: None.

There was no audio on media hairpin/loopback calls

Impact: The media loopback call is programed with srcMac = dstMac in NP. When packet port switched over, LVM notified XRM for MAC address update. Then, the loopback call's srcMac got updated, but the dstMac is still set to old MAC address that causes an no audio issue after a port switchover.

Root Cause: The root problem was that in XRM process MAC address update notify routine. The XRM only updated new MAC address in xres->nif->locMacAddr.
But the IP static header is built with both xres->nif->locMacAddr and xres->route->macAddr. So xres->route->macAddr != xres->nif->locMacAddr after a port switchover.

Steps to Replicate: Please test on both SWe and SBC7k platforms:

1. Enable port redundancy on pkt port.
2. Add an altMediaIpAddress on the LIF on the same pkt port.
3. Establish at least 1 regular call and 1 loopback call (with destIP = altMediaIpAddress) on the pkt port and ensure calls stay up after a pkt port switchover.
4. Do a manual switchover of the pkt port.
5. Verify that the calls have two-way audio.

The code is modified to first update all the routes using the old MAC address with new MAC address received from LVM, and then update NIF's locMacAddr.

Workaround: Avoid the use altMediaIpAddress by either deleting those from the LIF if possible, or by configuring the sipTrunkGroup->media->mediaIpAddress with the same media IP address for the trunk groups that could utilize media loopback.

There are various link monitor issues on the SBC SWEs with port redundancy enabled.

Impact: On VMware platform with Intel 82599 SR-IOV packet port VFs, link does not get restored upon toggling the underlying physical link.

Root Cause: Because of VMware PF driver quirks, the DPDK ixgbevf PMD code does not get link up indication from link speed status register for SR-IOV VFs from Intel 82599 card.

Steps to Replicate: 

1. Bring up port redundancy setup on VMware with SR-IOV 82599 VFs packet port.
2. Toggle the carrier link state on the NIC by cable pull or interface link toggle on host through the IP commands.
3. Observe the link status is not restored.

The code is modified to detect the physical link loss from the NACK status set on the hardware mailbox register, specifically for VMware platform.

Workaround: No workaround. Only reboot clears the link state.

The SBC send bye message within dialog sometimes.

Impact: After call is connected, if the SBC triggers internal re-INVITE due to minimizeRelayingOfMediaChangesFromOtherCallLegAll flag on one leg and at the same time, if SBC receives late media re-INVITE on other leg, the SBC clears the call.

Root Cause: Internal offer answer state of call at SBC SIP subsystem becomes invalid.

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

Call Flow:
Ingress (RTP), Egress (RTP)
After a call is connected, the SBC triggers internal re-INVITE to egress with one crypto.
At the same time , Ingress peer sends late media re-INVITE.
LateMedia will get queued up and processed after internal reinvite….
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.
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 , SBC clears up the call.

With fix , verified that SBC correctly sends 491 Request Pending to ingress when handling internal re-INVITE transaction on egress leg.
When 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, the late media re-INVITE on ingress leg responds with a 491 Request Pending with RetryAfter header.

After the egress re-INVITE transaction is completed, if the ingress peer sends 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-98433: Observed a basic swithcover is not working with the customer SBC in ASAN build.

Impact: There was a memory issue reported by ASAN.

Root Cause: The LIF structure was not reset to NULL after the memory was freed.

Steps to Replicate:

1. Create a customer M-SBC.
2. Configure the box.
3. Perform a switchover by killing the SCM Process in any of the active boxes.

Expected:

The switchover should be successful.

The code is modified to set LIF to NULL, after the memory is freed.

Workaround: None.

PortFix SBX-106063: Cranckback not working for a non-INVITE for SIP in core.

Impact: For SIP in core, the Cranckback was not working for a non-Invite.

Root Cause: For non-INVITE requests, there was a check for the Last Tried IP where the SBC compares the next route IP with last route's IP.

In the SIP in core, the route IP is always of SBC2, and as result, this next route was never tried.

Steps to Replicate: 

1. Configure the SIP in the core setup as SBC1 and SBC2.
2. Configure the Cranckback profile.
3. For a non-INVITE, the SBC should Cranckback and try the next route.

The code is modified to not compare the route IP's and as a result, the SBC tries the next route after a Cranckback.

Workaround: NA

Portfix changes are made for SBX-98358 to 8.2.x.

Impact: An alarm was raised for "OS account gets temporarily locked for user cnxipmadmin after too many failed login attempts."

Root Cause: The 'cnxipmadmin' is an internal user that does not get locked on multiple login attempts. In our script, which detects failed OS login, we are not considering the same and raising alarms for 'cnxipmadmin' on failed login.

Steps to Replicate: Try login multiple times with 'cnxipmadmin' as user and wrong password.

The code is modified to ignore failed login attempt in case of 'cnxipmadmin' user.

Workaround: N/A

PortFix SBX-95126: The SCM Process coredumps after PRACK.

Impact: The SCM coredumps when performing a double free of Dialog Scope Variable Data.

Root Cause: Double freeing of the Dialog scope variable data is occurring when both the SipAdapter profile and Flexible Adapter profile is configured on same TG.

Steps to Replicate: 

WARNING: Replicating this issue will produce a core.

1. Create a SMM Rule to store a dialog scope variable for all messages, Flexible Adapter Profile with advanced SMM enabled and dialog scope variable rules for messages.
2. Attach the rule to the ingress TG.
3. Run 18x/Prack call flow.

Expected results: A core will occur.

Modified the code to add a check to ensure the Flexible Adapter Profile does not include dialog scope variable data.

Workaround: Do not enable Advanced SMM on the Flexible Adapter Profile

PortFix SBX-108469: There was a registration issue with a switchover case.

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

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

Steps to Replicate: Test requires a HA setup.

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 which gets rejected by 403 again.
3. Verify the Security Mechanism in CLI is using "show status addressContext default sipActiveRegisterNameStatus" and also try to make a call.

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

1. Ensure to take logs.
2. In the Active node, make a successful registration with a response code other than 200.
3. Send a refresh register, it will be internally rejected with 403 from the SBC. In the 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.
   Note: step 2 and 3 cannot be reproduced in 824R1 build, so try with older build such as 8.2.2.
4. Upgrade the Standby node to 824R2 build. Perform a switchover and send a refresh register. Verify the CLI for security mechanism if set to NONE. Try making a call or send a refresh register again both should be successful.
   Note: If you would like to see the issue, In Step 4 instead of using a 824R2 upgrade, use a 824R1 upgrade.

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

Workaround: Try performing a switchover twice.

PortFix SBX-91127: The ASAN found a leak in CpxAaaGetNextEntry.

Impact: While processing requests to display user information/status, the CPX process was leaking memory.

Root Cause: While processing requests to display user information/status, the CPX process had to allocate internal memory blocks to collect information from the CDB and was not freeing up this memory at the end of the request.

Steps to Replicate: From the CLI, run commands to request user information e.g.
show user
show table oam localauth user

The code is modified to free up the memory at the end of the processing request.

Workaround: None.

The DSP had a coredump, and the system was unstable.

Impact: Some Fax T.38 IAD calls (T.38 protocols version 3) resulted in a DSP crash and reloaded 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, the repeated messages carry the 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 was based on the 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

Before a fix: Call sets up and we get a DSP coredump with a single DSP reload. beforefix.PKT is packet capture and no CM signal is observed from the stack.

After a fix: Call continues without crash.
afterfix.PKT has capture. G711 signal produced by stack shows CM signal.
(cm_fix.raw)

The code is modified to check to see if there is enough space available in tx_bits[] array to avoid overflow and avoid a crash in case of multiple CMs with incremental sequence numbers.

Workaround: Use the Version 0 for T.38 calls.

PortFix SBX-91592: The DRBD tuning is not optimal.

Impact: On non-cloud 1:1 SBCs, due to non-optimal tuning of the DRBD, the DRBD connection between active was getting disconnected leading to full sync and high i/o on drbd partition.

Root Cause: Due to peer not responding within a certain time (ko-count * timeout), ko-count feature of DRBD was disconnecting the peer leading to full sync.

Steps to Replicate: Following are the steps to test the changes:
1. Decrease the timeout value in drbd conf file
2. restart drbd service
3. Resume drbd sync if not already enabled.
4. Check syslog, drbd must not get disconnection logs.

Disabled the DRBD ko-count feature to address the issue.

Workaround: None.

PortFix SBX-92066: Observed the PRS Process core dumps "systemerror healthcheck timeout".

Impact: A PRS Process coredump was found due to healthcheck timeout upon executing a CLI debug command.

Root Cause: The CLI debug command was taking a long time due to too many ACL entries resulting in a health check timeout.

Steps to Replicate: 

1. Add more than 1000 ACL entries.
2. Execute the debug command below:
   Run CLI debug command "request sbx xrm debug command acl\ -stat"

NOTE: The debug commands are not available on customer sites.

Limited the debug command to process only 200 ACL entries to allow CLI to recover sooner.

Workaround: As we do not run debug commands on customer sites, this error should NOT occur.

PortFix SBX-1.07613: The  AMRWB encoder produces a 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 reinitialize the internal buffer.

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

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-107978: There are Coverity issue in SIPSG.

Impact: There was a coverity issue for NULL check. Accessing null pointer can lead to coredump.

Root Cause: The NULL pointer dereferences while handling Session refresh.

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

The NULL check is added before accessing the pointer

Workaround: No workaround.

PortFix SBX-105674: There are Customer coverity issues.

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 is 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-104671: The SBC: CpxAppProc leak for SBC call

Impact: During SBC startup the Cpx process has a small memory leak.

Root Cause: During the SBC startup processing the Cpx process reads various CDB configuration and performs DB schema upgrade validation logic. As part of this processing it was creating temporary internal memory blocks but not releasing them at the end of initialization.

Steps to Replicate: Restart the SBC after it is configured.

The code is modified to correctly release the temporary memory blocks used for initialization processing.

Workaround: None.

PortFix SBX-105496: Fixing the NRMA coverity issue CID:11149.

Impact: Coverity scanning tool identified a potential code leg where a null pointer could be dereferenced which could potentially result in a coredump although not observed in internal testing.

Root Cause: While trying to allocate resources for PCMU to PCMA call where the ingress leg is being tapped and there is a possibility the code could access an invalid pointer resulting in unexpected behaviour and potentially coredumps.

Steps to Replicate: This part of the code could be triggered for PCMU to PCMA call where the ingress leg is being tapped.

The code is modified to verify the pointer is not NULL before trying to use it to avoid potential coredumps.

Workaround: None.

PortFix SBX-105679: The ASAN leaksanitizer errors in CPX and SCM

Impact: SCM and CPX processes have a small memory leak while changing IPSEC and IP interface group configuration

Root Cause: While processing configuration related commands, the SBC was reading information from CDB into temporary memory blocks, but failed to release the memory at the end of the configuration action. This resulted in a small memory leak.

Steps to Replicate: Make configuration changes to IPSEC and IP interface group.

The code is modified to ensure the memory is correctly freed up to avoid the leak.

Workaround: None.

PortFix SBX-105542: Fix the customer coverity issues.

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 is 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-103950: PAI differences between 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 the PSX.

Root Cause: The SBC supports additional functionality that is not present on the GSX and it 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.

In order to provide equivalent signaling on the SBC to the GSX, the SBC code is updated 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.

PORTFIX SBX-106687: Network Tools - Platform Interface Status incomplete

Impact: In 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 make sure that the displayed status message matches with the status message from CLI.

To prevent the browser from interpreting the special characters < and > as HTML block, the element used to display the status message was changed from <textarea> to <pre>

Workaround: Not Available.

PortFix SBX-105850: The SBC: SBC failed to come up after sbxstart.

Impact: At startup of SBC, there is a possible race condition due to which SBC processes may go for an additional restart before they come up and restore config data.

Root Cause: Race condition in the code between threads.

Steps to Replicate: Run installation and startup on various platforms.

Race condition in setting some common variables is avoided by using static path of binaries.

Workaround: None.

PortFix SBX-107642: The SBC terminates call as 491 does not get relayed.

Impact: 491 response to Re-INVITE is not relayed even though relay4xx-6xx and E2E Re-invite are enabled

Root Cause: The SBC was not considering the re-INVITE without SDP to be received from the network. This is causing 491 to be locally handled.

Steps to Replicate: 

Enable relay4xx-6xx flag and E2E re-INVITE.

Send a Re-invite without SDP to SBC and respond 491 for that re-invite.

The code is fixed to set the ReInvite without SDP as locally generated or received from the network.

Workaround: No workaround.

PortFix SBX-103103: The SBC: BFD packet forwarded by the router is not received by the SBC.

Impact: Once the BFD session is established on a port (either primary or secondary), an immediate port switch over is followed due to BFD packets dropped at NP for a brief amount of time (~1 second). This eventually triggers a Node switchover.

Root Cause: A race condition in ACL lookup is the cause of this issue.

Steps to Replicate: 

1. Ensure the BFD session is up on a port (either primary or secondary).
2. Initiate a port switchover.
3. Monitor if BFD session comes back on the switched-over port and an immediate port switch over is not followed.

The code is modified to address the issue.

Workaround: An user ACL can be added as a workaround.

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

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

Root Cause: The code does not check if rport has some valid port number or not. If rport is the last parameter in VIA header, it 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 SBX. "rport" is at the end of VIA header.
3. Run the client script with -p 30333.
4. Verify that SBC replaces rport port number (1111) with its own rport (30333) in VIA header of 200 OK response.
   
   
   

The code is modified so that it checks for any port number in rport parameter (rport is at the end of VIA header of request message), it replaces the port number and appends it's own report.

Workaround: Following SMM can be used as a work around

set profiles signaling sipAdaptorProfile HeaderModifications rule 1 applyMatchHeader one

set profiles signaling sipAdaptorProfile HeaderModifications rule 1 criterion 1 type message message messageTypes response statusCode 200

set profiles signaling sipAdaptorProfile HeaderModifications rule 1 criterion 2 type header header name Via condition exist

set profiles signaling sipAdaptorProfile HeaderModifications rule 1 action 1 type header operation store

set profiles signaling sipAdaptorProfile HeaderModifications rule 1 action 1 headerInfo headerValue

set profiles signaling sipAdaptorProfile HeaderModifications rule 1 action 1 from type header value Via

set profiles signaling sipAdaptorProfile HeaderModifications rule 1 action 1 to type variable variableValue var4

set profiles signaling sipAdaptorProfile HeaderModifications rule 1 action 2 type variable operation regsub

set profiles signaling sipAdaptorProfile HeaderModifications rule 1 action 2 from type value value "rport="

set profiles signaling sipAdaptorProfile HeaderModifications rule 1 action 2 to type variable variableValue var4

set profiles signaling sipAdaptorProfile HeaderModifications rule 1 action 2 regexp string "rport=[0-9]*=" matchInstance one

set profiles signaling sipAdaptorProfile HeaderModifications rule 1 action 3 type header headerInfo headerValue

set profiles signaling sipAdaptorProfile HeaderModifications rule 1 action 3 operation modify

set profiles signaling sipAdaptorProfile HeaderModifications rule 1 action 3 from type variable variableValue var4

set profiles signaling sipAdaptorProfile HeaderModifications rule 1 action 3 to type header value Via

PortFix SBX-107190: Enabling DisableZoneLevelLoopDetection not working on ZONE level.

Impact: When DisableZoneLevelLoopDetection and loopDetectionFeature are both enabled, loop detection is occuring at the zone configured for DisableZoneLevelLoopDetection .

Root Cause: When the loop detection flag is enabled at both zone and global level, global logic was taking precedence over zone.

Steps to Replicate: 

1. Enable disableZoneLevelLoopDetection under zone.
2. Enable the global flag loopDetectionFeature.
3. Run a basic call to loop back into the SBC through a specific TrunkGroup

The code is modified to give precedence to DisableZoneLevelLoopDetection over loopDetectionFeature when the loopdetection flag is enabled at both a zone and global level.

Workaround: None.

PortFix SBX-104136: Unable to login to a CLI session.

Impact: The SWe Active profile configuration may cause a password change commit to hang.

Root Cause: An Internal Configuration change related to sweActiveProfile leaves the changes in candidate database. This causes another commit from SmProcess a deadlock, as sweActiveProfile change subscription needs the SM Subscribers acknowledged.

Steps to Replicate: This cannot be recreated through User Interfaces. Internal error condition.

The code is modified to revert the changes from candidate database, if the sweActiveProfile commit fails.

Workaround: None.

PortFix SBX-107254: The confd connections are not cleaned up properly.

Impact: If the standby experiences a power hit and therefore the confd connections are not properly torn down.

Root Cause: Active side needs to run keepalive and cleanup stale connections to address standby abnormal shutdown.

Steps to Replicate: Test by shuttingdown/pull plug on standby on a HA system.

The code is modified to run the keepalive the connection and cleanup if standby is shutdown abruptly.

Workaround: None.

PortFix SBX-109083: There was a SCM Process core dump during a SipSgAORHashRemove.

Impact: The SCM Process cores due to corruption of entry in Registration hash table post switchover. This corruption is rare and occurs infrequently.

Root Cause: The corrupted AOR entry in hash table was allocated during reconstruction of Active RCB from standby context after switchover. SYS Error logs indicates presence of duplicate AOR entry. This could potential lead to corruption.

Steps to Replicate: 

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

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

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

Workaround: None.

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

Impact: We were 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 a JAVA memory restriction, we were getting Heap error from ByteArrayStream.

Steps to Replicate: 

1. Login into EMA.
2. Run 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 fail with a proxy error.

Use a copy API instead of the write API of IOUtils. This internally copies the data from inputStream into OutputStream.

Workaround: None.

PortFix SBX-104118: The LeakSanitizer detected memory leaks in Scm Process

Impact: While relaying REGISTER messages the SBC could leak memory blocks allocated to hold the record-route header information.

Root Cause: The SBC allocates memory blocks to hold the contents of the record-route headers in the REGISTER message. But if the record-route header information is associated with the SBC IP address then the SBC does not correctly free up the memory blocks causing a leak.

Steps to Replicate: Run test cases for stateless REGISTER relay call scenarios where the IP information in the record-route header is the SBC's IP.

The code is modified to correctly free up memory allocated to store the record route header information.

Workaround: None

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

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

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

Steps to Replicate: 

1. Set sweActiveProfile to use GPU and sweCodecMixProfile to use G729.
2. Make G729AB to G711U call and don't send the media.

RESULT: SWe_UXPAD may crash and SBX application restarts.

NOTE: The issue may not be reproduced always.

The code is modified to initialize the stack variable appropriately.

Workaround: No workaround.

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 refresh REGISTER is bad. Due to this issue, there is difference in count of total stable registrations across zones.

Root Cause: When the load of bad Refresh or initial REGISTERs received at the SBC, some of the registers are not getting userNPhoneContextKey. Due to this issue, the code that is responsible for reducing activeRegCount is not being executed.

Steps to Replicate: 

1. Perform an active Registration.
2. Send one bad refresh REGISTER.

Expected Result: After receiving a 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-104552: After a switchover, the SBC does not send Goodbye packet for Text stream.

Impact: When a call is using T140/TTY interworking, after performing a switchover, the RTCP bye is not sent toward T140 stream endpoint.

Root Cause: In the T140/TTY interworking, the resource for T140 stream is not mirrored properly to standby causing deactivating does not work after switchover

Steps to Replicate: 

1. Make call with T140/TTY interworking (for example, AMR-WB+T140 - PCMU).
2. Once a call is established, switchover.
3. After a successful switchover, end the call and see that RTCP bye is sent properly to T140 stream.

The code is modified to mirror resource correctly for T140 stream in T140/TTY interworking

Workaround: None.

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

Impact: Sending 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. B sends fax tone, on detecting fax tone SBC sends T.38 Re-INVITE towards A and A rejects with 488.
4. When a fallback occurs, the SBC sends G711 Re-INVITE towards A and gets 200 OK. On getting the 200 OK. The SBC sends final AAR that should contain last negotiated SDP information.

The code is modified to send last negotiated codecs in the media-component AVP of AAR message.

Workaround: Not Applicable.

PortFix SBX-104563: The SBC is not updating DNS servers order in DnsServerStatistics on deleting and creating fresh DNS Group.

Impact: The SBC was showing the incorrect DNS Servers Index in DnsServerStatistics command "show table addressContext default dnsGroup <dnsGroupName> dnsServerStatistics " when the DNS Servers were deleted and re-created in a different order with the same server IPs.

After creating the 128 DNS Servers with different unique IPs are and then deleting some of them such that the total number of DNS Servers is less than 128, no new DNS servers created post the delete operations will have the corresponding statistics information, even though the total number of servers is less than 128 on the system.

Root Cause: The DNS Server Statistic blocks are not deleted when the DNS Servers are deleted and continues to remain hashed with the IP with which it was created.

Steps to Replicate: 

1. Configure DNSGROUP.
2. Add 1st DNS server with IP1 to DNSGROUP.
3. Add 2nd DNS server with IP2 to DNSGROUP.
4. Check DnsServerStatistics.
   show table addressContext default dnsGroup <dnsGroupName> dnsServerStatistics.
5. Delete DNSGROUP.
6. Configure DNSGROUP.
7. Add 1st DNS server with IP2 to DNSGROUP.
8. Add 2nd DNS server with IP1 to DNSGROUP with weight1.
9. Check the DnsServerStatistics.
10. IP2 should have 3 as Index and IP1 should have 4 as index in dnsServerStatistics.

The code is modified to delete the DNS Server Statistics block and remove it from the IP hash when the DNS Server is deleted.

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 History to Diversion interworking , though the parameter is present in History Info

Root Cause: No support for the requested functionality existed up to now. Probable cause was the lack of requirements.

Steps to Replicate: On the ingress leg, enable acceptHistoryInfo. On the egress leg, enable diversionHistoryInfoInterworking.

The code is modified to include URI parameter user=phone in diversion header, when history info header has the uri parameter user=phone during interworking.

Workaround: None.

PortFix SBX-105544: The Dialog scope variable is not present after SMM reject on re-invite message.

Impact: TheSMM is not adding the header in the rejected response which is stored in the Dialog scope variable.

Root Cause: The Dialog scope variable was not saved due to the Reject operation in the SMM.

Steps to Replicate: 

1. Store Dialog scope variable for the ReInvite.
2. Reject the ReInvite with 488.
3. Add a header in the 488 response with the value stored in the Dialog scope variable.

The code is modified to store the Dialog scope variable when there is Reject operation in the SMM.

Workaround: No workaround.

External volume is not mounted properly causing LCA to terminate.

Impact: The Cinder Volume was unable to attach itself within a required time frame, which caused the mount check for the same to fail and resulting in terminated LCA.

Root Cause: The mountVolume.sh mounts the Cinder Volume if it finds it, but if Cinder Volume is not found it within 1 minute it skips the mount. This mount is then checked in lca.py and if the check fails LCA is terminated.

Steps to Replicate: In case the mount was successful, we will get this log in lca.log
External volume is mounted on /var/log.

In case of a failure, we will try reboot multiple times, with this being logged in
syslog
<30> 1 2021-04-26T10:24:04.347868-04:00 vsbc lca 2869 - - ERROR:LifeCycleAgent:External volume is not mounted properly.
<30> 1 2021-04-26T10:24:04.348019-04:00 vsbc lca 2869 - - ERROR:LifeCycleAgent:Rebooting to retry mount.
and lca.log
2021-04-26 10:24:04.347 LifeCycleAgent ERROR External volume is not mounted properly.
2021-04-26 10:24:04.347 LifeCycleAgent ERROR Rebooting to retry mount.

The code is modified to wait for 90 seconds for the cinder to attach. If the cinder does not attach, it tries (since the max reboot count of 5 is not reached) to reboot the instance and in turn, triggers the mount logic to access the cinder again.

Workaround: None.

PortFix SBX-108025: Receiving an unexpected CANCEL in SBC-to-SBC GW early media case

Impact: An UPDATE is responded with 503 response and CANCEL is sent out

Root Cause: An UPDATE is removed from the dialog when receiving another UPDATE during the processing of previous UPDATE.

Steps to Replicate: 

1. UAS sends an UPDATE to the SBC.
2. The SBC forwards the UPDATE to UAC.
3. UAS sends one more UPDATE to the SBC.
4. The SBC responds with 500 for the second UPDATE.
5. UAC responds 200 response for the UPDATE.

The code is modified not to remove the UPDATE request from the dialog when receiving another UPDATE.

Workaround: No workaround.

PortFix SBX-105280: There was a Cpx Process Memory leak for single calls on the OAM node.

Impact: The Cpx process can leak small amounts of memory when creating/modifying the SNMP configuration.

Root Cause: While processing the SNMP configuration commands, the SBC was creating temporary internal memory blocks to read and write information from/to CDB. But it was not freeing up this memory at the end of the configuration action.

Steps to Replicate: Modify the SNMP configuration to reproduce the issue.

The code is modified to correctly free temporary memory allocated during the configuration process.

Workaround: None.

PortFix SBX-105389: Dereference after a NULL check and dereference the NULL return value.

Impact: The coverity scanning tool identified a potential edge case scenario where the lawful intercept code could potentially access a null pointer leading to unexpected behavior and potentially a coredump.

Root Cause: While the code was performing X2 peer status updates it retrieved the peer information from a hash table but did not verify that the pointers inside the record it retrieved were valid. It would be an extreme error case for this to result in reading of a null pointer and would likely need to be due to another problem. But coverity highlight it as an edge case issue to fix up.

Steps to Replicate: Run test cases for lawful intercept using packet cable V2.0 configuration.

The code is modified to validate the pointer is not null before using it and avoid any error scenarios.

Workaround: None.

PortFix SBX-108575: CE_2N_Comp_CpxAppProc_EO.CPX.CPX.00450 : NOTICE) CpxUpgradePersistentMacAddressStatus: will move 0 entries to new table macAddress2Status

Impact: While performing an upgrade of LIF group information there was a small memory leak.

Root Cause: The code was reading CDB data and storing the value in local memory while perform CDB schema upgrade. This memory was not being freed causing a small memory leak.

Steps to Replicate: Run LSWU calls.

The code is modified to ensure the local memory is correctly free up after usage.

Workaround: None.

PortFix SBX-93922: The SBC is sending Min-Expires header twice to endpoint for 423 Interval Too brief response

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

Root Cause: 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 the SBC from UAC.
3. UAS sends 423 response to REGISTER message received from the SBC.

The code is modified before adding the header during the processing of Transparency profile.

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

PortFix SBX-107825: The LM (MoH) re-Invite replied 200 OK (video inactive)

Impact: Video stream continues to be on HOLD even though Audio stream is offered as sendrecv when the SBC generates offer for late-media re-INVITE in covert mode.

Root Cause: While send offer in 200 OK for late media re-Invite, the SBC changed the audio DPM to sendrecv but video DPM was not changed and retained as inactive based on the last negotiated DPM on that leg.

Steps to Replicate: To re-create the issue:

A<->B Direct Media call
Configure the Latemedia support as Convert at the SBC.

1. Setup an audio and video call.
2. Endpoint places the call on hold by sending a=inactive for both Audio and Video streams.
3. Then endpoint sends late media re-Invite to resume the call.
4. The SBC sends offer in 200 OK with audio data path mode (DPM) as "sendrecv" and video DPM as inactive.

Test Result with Fix:
The SBC sends offer in 200 OK with DPM as "sendrecv" for both audio and video streams.

The code is modified to change the DPM for both audio and video streams to sendrecv while generating offer for late media re-INVITE in Convert mode.

Workaround: None.

PortFix SBX-108273: SBX-106321 does not work when Require header comes in 18x without 100Rel.

Impact: Proxy Behavior for 18x message not working when Require Header is present in the 18x message, but not 100rel value in it

Root Cause: The code is not present for 100 Rel Proxy behavior when Require Header is present in the 18x message, but not 100rel value in it

Steps to Replicate: Run the scenario below to reproduce the issue.

1. Enable e2ePrack and proxyBehaviourFor18x flags.
2. Run a call flow where 18x as require header but no 100rel value in it.

The code is modified to consider this case when the Require Header is present but not with the 100rel value in it.

Workaround: Not Applicable.

PortFix SBX-74155: The ACL rule is missing on the SBC in LD triggered switchovers and link recovered after

Impact: When an IPACL rule is created that references an IP interface, but that IP interface is down since the system started up, the rule is not successfully created.

Root Cause: When an IP interface is failed on system startup, the system does not add that interface to the kernel. When an IPACL rule is added that references that IP interface, it fails to be added to the NP.

Steps to Replicate: Start an SBC with an IP interface failed, that also has one or more IPACL rules that have been configured that reference that IP interface. Bring up the IP interface and logs will show the IPACL rules have been successfully added.

The code is modified to detect this situation and maintain a retry list. Once the IP interface comes up, it retries the associated IPACL rules that were previously failed.

Workaround: This issue can be worked around by having IPACL rules that do not reference the IP interface.

PortFix SBX-105849: An RTP inactivity call is torn down as expected, but TRAP not sent (even configured).

Impact: Due to RTP inactivity call gets torn down as expected, but TRAP is not generated for some of the calls.

Root Cause: If a call gets torn down due to RTP inactivity and a trap is raised, then SBC sets an internal flag while raising the trap for such a call. However, due to a software bug, this flag was not reset when this call goes down.
Due to performance reasons, one of the sub-system re-uses this memory block again for new calls. Since, the flag from previous call was not reset, it continues to stay set even for this new call and as a result the trap for this new call was not raised.

Steps to Replicate: 

1. Run a call load such that the SBC detects media inactivity and raises traps.

Issue: One would notice that after some time, the SBC fails to raise "media inactivity" trap for some of the calls even though such calls gets torn down due to media inactivity.

Fix: After fix, one would notice that the SBC raises traps for all such calls.

Reset the flag gracefully during call tear down to address the issue.

Workaround: None.

PortFix SBX-103306: Allocated bandwidth for opus call is 1032kb and 1028kb for a 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 Fix:

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

The code is modified to take action if "maxaveragebitrate" is not received in the SDP by deriving its default value according to RFC using "maxPlayBackRate" and mode (mono/stereo).

Workaround: None.

PortFix SBX-65509: Preferred payload number was not used for either dtmf or amrwb when "different2833PayloadType" transcode option is enabled.

Impact: Preferred payload number was not used for either dtmf or amrwb when "different2833PayloadType" transcode option is enabled.

Root Cause: In case of when the Route PSP being configured with the same payload number for both DTMF and Codec, the SBC skipped over this PT value and as a result, this PT value could not be used for either of DTMF or Codec.

Steps to Replicate: 

1. Setup a call with codec as AMR-WB and DTMF as RFC2833
2. Enable different2833palyloadtype flag.
3. Enable honorSdpClockRate flag.
4. Configure preferredRtpPayloadType as 101 in Route PSP's AMR-WB codec entry.
5. Configure preferredRtpPayloadTypeForDtmfRelay as 101 in Route PSP.
6. Verify the PT values used by the SBC for AMR-WB and DTMF.

The code is modified to prefer the configured value for DTMF PT in case of a conflict between the configured PT values.

Workaround: Do not configure the same PT value for DTMF and Codec entries in Route PSP.

PortFix SBX-108479: A switchover to standby was not successful when the active node dumped core and went for deadlock

Impact: Switchover does not get triggered in case of abnormal termination of CPX and PRS process.

Root Cause: Logic to send switchover event is present in PRS process and the PRS cleanup script but in case of abnormal termination, we are unable to get the current node's role and service ID that is needed for checking whether to send switchover event or not.

Steps to Replicate: Kill CPX process and then after 2 seconds, kill PRS process.

The code is modified to save the service ID on the node going down if it was running as active so that the PRS cleanup script can look for the file and send switchover event while going down.

Workaround: No workaround.

PortFix SBX-107543: CDR Field 12 in ATTEMPT record filled incorrectly when Response Profile is configured.

Impact: The CDR code was using the reasonCode from the response profile to populate the call disconnect reason field. But the the reasonCode is the SIP status code, and not the internal CPC disconnect reason.

Root Cause: The code was incorrectly using the reasonCode in preference to the cpcCauseCode.

Steps to Replicate:

1. Run a call flow using the response profile configured in the PSX.
2. Check that the CDR field 12 disconnect reason code contains the CPC disconnect reason code, and not the SIP status code.

The code is modified to only use the cpcCauseCode from the response profile, and not the reasonCode.

Workaround: None.

PortFix SBX-107518: There was a Sync issue after the Standby SBC took over for the Active SBC.

Impact: An active SBC gets into 'syncInProgress' state even after recovering from network glitch.

Root Cause: Since network glitch is detected only on an active SBC side, the standby SBC side does not initiate sync process after the active system recovers from the network glitch.

Steps to Replicate: 

1. Simulate network glitch such that only an active SBC detects it and recovers from it.
2. For this, we can try this command with different sleep values between 5 and 6:
   ifconfig ha0 down; sleep 5; ifconfig ha0 up.

The code is modified to check for the sync state of an active SBC and based on that, it should initiate the sync process with an active SBC.

Workaround: No workaround.

PortFix SBX-105534: The SBC is terminating calls upon a second MSBC switchover.

Impact: Calls are failing during a MSBC switchover due to corrupted neighbor cache on the switch.

Root Cause: During switchover triggered by "reboot" of an active MSBC node, port switchover gets initiated in old active MSBC, which sends out the GARP from disabled NIF, causing the corruption in neighbor cache of the switch.

As a result, packets coming from the SSBC lands on the old active MSBC instance causing call termination.

Steps to Replicate: 

1. Create and configure a customer D-SBC setup.
2. Run a single call and do a switchover by rebooting an active MSBC (say M1).
3. Once the call is shifted to the new active MSBC(say M2), perform the second switchover by rebooting the new active MSBC (M2).
4. Check that there is no GARP being sent out from new active MSBC i.e. M2 and there is no termination of calls after a second switchover.

The code is modified to drop all outgoing packets from DISABLED port.

Workaround: No workaround.

PortFix SBX-104814: A SIPS call load caused SCM to mem congestion and crash.

Impact: While running the call/OOD load with more number of dialog stateful SMM variables configured, and those variables are applied per call/OOD message, there seems to increase in memory usage leading to memory congestion and causing the crash.

Root Cause: Whenever dialog stateful variable is created, default 6144 bytes will be allocated statically per variable. While running the load with more number of dialog stateful variables configured and applied to call, might lead o increase in memory usage

Steps to Replicate: Running the call load with more number of dialog stateful SMM variables configured and used per call.

The code is modified to change the static array to pointer variable and allocate only required memory per dialog stateful variable.

Workaround: None.

PortFix SBX-105412: The CE_2N_Comp_CpxAppProc leak for port SWO (BFD).

Impact: Small memory leak during configuration of packet port with BFD configuration associated.

Root Cause: The configuration code was reading information from CDB and storing information in an internal memory block but not freeing it up.

Steps to Replicate: With a BFD configuration on the SBC disable and enable the pkt port by setting mode OOS and state disabled and then enable the pkt port again.

The code is modified to correctly release the internal memory block at the end of the configuration action.

Workaround: None

PortFix SBX-105310 : The SM Process leak for the SBC call on an active SBC.

Impact: The redundancy group manager (RGM) that is used in conjunction with N:1 deployments has a memory leak.

Root Cause: The RGM handles switchover and fault messages in N:1 deployments and it was not freeing up the ICM message after processing which results in a memory leak.

Steps to Replicate: This issue was observed in an SBC configuration especially when restarted instances.

The code is modified to correctly free ICM messages.

Workaround: None

PortFix SBX-105711: There was a CE_2N_Comp_CpxAppProc leak during disable and enable of pkt port

Impact: Creating an H248 signaling port results in a small memory leak

Root Cause: While processing the H248 signaling port creation command when metavars are defined for the IP value, the SBX allocated memory to hold the metavar value from CDB internally for processing, but never freed up this memory block at the end of the port creation action resulting in a small leak.

Steps to Replicate: Create an SBC 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-105591: Observed that PRS process heap buffer overflow issue on 9.2 ASAN build 63.

Impact: The BRM process was accessing memory after it had been freed. As the memory is being read immediately after being freed, then it is unlikely this would cause a problem.

Root Cause: If the BRM process received an unexpected message then it was trying to print a debug message to indicate the message type. However, the message had already been freed up because it was unexpected. This was observed on the standby server and most likely generated at the point of switchover.

Steps to Replicate: Run normal call load and perform switchovers.

The code is modified to collect the message type information before the message is freed so that the debug log content can be safely generated without accessing freed memory.

Workaround: None.

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

Impact: Issue 1: When the register is sent to registrar 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 not able to make a call due to security mechanism being set to TLS.

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

Root Cause: Issue 1: In 82x build when a Register request is rejected with 403 it moves to terminated state. Also whenever we receive a register we modify the RCB details irrespective of the response we might receive 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 terminated state the code was partially deleting internal memory which led to the RCB mechanism being reported as TLS and none TLS calls where then rejected.

Steps to Replicate: Make the configuration as mentioned in the description and use the config file attached for reference:

1. After configuration 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 was modified to fix the two main issues:
1. When we receive a fake register and 403 response, the RCB remains 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: None.

PortFix SBX-100225: There was an AddressSanitizer: heap-use-after-free in UasProcessMsgCmd on address 0x623000187198 at pc 0x5623cc7b3b42.

Impact: The SCM process is accessing memory after it is freed during timer expiry handling when there is no response to an OPTIONS message that was triggered due to debug optionsPing using an FQDN. Accessing memory after it is freed can cause unexpected behavior and in the worst case potentially coredumps.

Ex:"request addressContext default cmds optionsPing peerFQDN bats3.gsxlab.com peerPort 14090 sigPort 2 transport udp"

Accessing memory after it is freed can cause unexpected behavior and in the worst case, potentially coredump.

Root Cause: The SIP dialog memory block was being removed in two places while handling the timeout for the debug optionsPing command, which could result in unexpected behaviour and potentially coredumps.

Steps to Replicate: run debug optionsPing command
"request addressContext default cmds optionsPing peerFQDN bats3.gsxlab.com peerPort 14090 sigPort 2 transport udp"

The OPTIONS message will be sent out. Let the options timeout (do not send any response).

The code is modified to address the issue.

Workaround: Do not use this debug command, or use it with an IP instead of an FQDN.

PortFix SBX-107752: The PRS Process core dumped on detaching/attaching interface on the SBC SWe.

Impact: The issue is observed only when the interface is is toggled through the root.
ifconfig pkt0 down
ifconfig pkt0 up.

Interface has only the SIPSIG Port IP and IPv6 associated with the LIG was not up with interface.

Root Cause: When the link was down LIG IPv6 removed, but was not configured when LIG was up.
IPv6 associated with LIG was not reconfigured again.

Steps to Replicate:

1. Bring up SBC and configure IPv6 address in pkt0 port.
2. The pkt0 interface is detached from the SBC using the cmd "ifconfig pkt0 down".
3. Re-attach pkt0 interface using cmd "ifconfig pkt0 up".

Result:

The PRS Process should not core after re-attaching the pkt0 interface.

The code is modified to also configure the untagged LIF IPv6 address again when link is bounced.

Workaround: None.

PortFix SBX-107613: A customer encoder produces corrupted output when the 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 the 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-106343: The EVRCB Decoder asserts in Erasure frames simulation test.

Impact: 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 may not be reproduced always.

The code is modified to handle precision errors.

Workaround: No workaround.

PortFix SBX-107179: The Dual Hold music on hold inter lab failed when both user login on secure PCC.

Impact: Dual Hold music on hold inter-lab failed when both user login on secure PCC with "error opening media".

Root Cause: The SBC was keeping all the crypto instead of only common crypto if request was coming from egress side.

Steps to Replicate: Test Cases for the hold/unhold Scenarios:

Hold: Reinvite)(hold) From UAS (with 2 cryptos)->SBC, SBC sends INVITE(with the intersected cryptos)-> UAC, UAC replies with 200OK (one Crypto)->SBC, SBC replies 200OK (with 1 Crypto)->UAS

UnHold: Reinvite)(UnHold) From UAS (with 2 cryptos)->SBC, SBC sends INVITE(with the intersected cryptos)-> UAC, UAC replies with 200OK (one Crypto)->SBC, SBC replies 200OK (with 1 Crypto)->UAS

The code is modified so the SBC only keeps the common crypto when requesting from the egress side.

Workaround: To avoid this issue, the UA should send only single common crypto in UPDATE SDP. There is no workaround from the SBC side.

PortFix SBX-106583: With the Q1912 in a 302 Redirect message, the SBC sends RN and NPDI even though Contact Header in 302 does not have RN and NPDI.

Impact: When making a call where 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 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. But 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.

PortFix SBX-70305: There was 15-16 seconds media outage when UXPAD processes are killed, the switchover is occuring aonly after 15-16 seconds of killing all the UXPAD processes.

Impact: 15 seconds of media outage during switchover triggered by crash of DSP processes on the SBC SWes.

Root Cause: The current DSP health-check mechanism takes up to 15 seconds to ascertain failure, leading to delayed switchover action.

Steps to Replicate: Attempt a switchover by killing one of the SWe_UXPAD processes on a SBC SWe system. Observe media outage during the process.

The code is modified to enhance crash detection of DSP processes on the SBC SWes.

Workaround: No workaround.

PortFix SBX-88007: A call flow should work with 5 video and 1 audio streams that is not working but when one video stream is removed callflow is working.

Impact: Call fails if peer SDP contains six streams (5 video and 1 audio) and directMedia along with ICE is enabled at SBC.

Root Cause: Insufficient memory allocation for this SDP caused the call failure during inter-process communication.

Steps to Replicate: Configuration requirements to run test:

• Ingress TG in Zone1, egress TG in Zone2 and AS TG on SBC
• Call routing:
  UE1 -> ingress TG -> AS TG -> AS peer (sipp) -> AS TG - egress TG -> UE2
  Enable Direct Media on the ingress and egress TGs (but not on AS TG): TG-media > directMediaAllowed enable
  PSP for all TGs: enable DM flag
  PSP: enable useDirectMedia flag
  Enable ICE (webrtc) on the ingress and egress TGs
  TG services: natTraversal, iceSupport, iceWebrtc
  Enable DTLS on the ingress and egress (TGs and PSPs)
  TG > media: dtlsProfileName, defaultDtlsProfile
  PSP: dtlsCryptoSuiteProfile DEFAULT enableDtlsSrtp enable
  Set the directMediaGroupId on the ingress and egress TGs to be identical (e.g. 200), and AS to be different (e.g. 400) from TG-media directMediaGroupId (e.g. 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 the ingress TG, and route towards the AS TG.
2. From 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 AS, send the 180, followed by 200 OK back towards the SBC.

Expected Result: The call succeeds.

Actual Result: The call fails.

Increased the memory buffer size to accommodate six streams.

Workaround: None.

PortFix SBX-103890: ERROR: ASAN reported "AddressSanitizer: heap-use-after-free" error for dialog-id transparency relay scenarios

Impact: Accessing memory after it is freed can cause unexpected behavior which may result in coredumps.

Root Cause: An invalid access of the freed memory occurred in dialog-id transparency relay scenarios.

Steps to Replicate: Relay a call flow with the Dialog-ID transparency feature enabled.

The code is modified to not free the memory until processing completes.

Workaround: None

PortFix SBX-103570: Under the Register load, major logs related to DBL were flooding the SBC.

Impact: Unnecessary message exchanges occurred between the SBC modules, resulting in a flood of logs.

Root Cause: Due to a missing boundary check, the SBC stopped accepting any new entries when too many DBL tracking entries exist (more than 4K). 

Steps to Replicate:

1. Execute a 600K TLS/TCP Registration at 1000 rps.
2. Allow all endpoints to register.
3. Start the Supported call load (Approximately 20K: 254cps * 90cht= 22860) using 50% from the registered Endpoints and 50% from Peering EPs.
4. Configure ext-to-ext Intra-SBC Call load of 5000 (50cps*100cht from SIPP).
5. Ensure DBL applied/removed for Registered endpoints denies entries to 10% of registration/call load. Repeat this 10 times.
6. Let the load run for 3 hours.
7. Use CLI to perform operator-initiated switch-over and revert.

The code is modified to prevent sending unnecessary messages.

Workaround: None

PortFix SBX-103539: Observed flooded Logs for refresh registration in the Standby SBXrestart stopped 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-108951: The ASAN ERROR :==CE_2N_Comp_ScmProcess_0==22395==ERROR: AddressSanitizer: heap-use-after-free on address 0x6200000373c8 at pc 0x560aae46bf67 bp 0x7fc9bc717850 sp 0x7fc9bc717848.

Impact: Heap After Free usage for the hMsgHandle after removed from the pstServerRequestList

Root Cause: Accessing ToTag from the hSipMsgHandle after free, so it is causing ASAN detecting heap-use after free error.

Steps to Replicate: Run a call flow scenario involving PRACK Message with SDP.

The code is modified above few lines before freeing the hSipMsgHandle.

Workaround: None.

PortFix CHOR-6320: The SWelite AKS: UxPAD coredump observed on media container while pumping 2X overload of G711U to G711U DSP (media transcoding disabled) call load.

Impact: The SWe_UXPAD crash was seen during overload transcode test in 2 vcpu SWe deployment in the public cloud.

Root Cause: Potential corruption in packet buffers due to issues related to concurrency specifically in 2 vcpu transcode overload scenarios.

Steps to Replicate: 

1. Configure a 2 vcpu instance.
2. Run 700 G711-G711 transcode sessions for overnight/long duration.
3. Check if there is any UXPAD/NP crash seen.

The code is modified to fix concurrency issues in transcode call scenarios in 2 vcpu SWe deployments.

Workaround: No workaround apart from avoiding overload scenarios for transcoded calls.

SIP over SCTP calls failing for app. 25-30 seconds after enabling a new SIP signaling port

Impact: Disabling/Enabling SIP-UDP signaling port triggers SIP-SCTP packets being sent out of management interfaces (mgt0/mgt1).

Root Cause: Missing ipInterfaceGroup information in SCTP socket created by kernel, not SBC application.

Steps to Replicate: Without the fix in the SBC providing SIP-SCTP connections, disable/enable/add a SIP-UDP signaling port and observe the SIP-SCTP packets leaving from management interfaces.
With the fix, the SIP-SCTP connections continue to use packet interfaces for SIP-SCTP packets.

The code is modified so when the Linux kernel's SCTP stack makes a copy of another SCTP socket created by SamProcess, the ipInterfaceGroup information has to be copied from application-created socket to internally/kernel created socket.

Workaround: None.

The SBC CDR was 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.

For the OOD NOTIFY, the SBC sending 481-Call Leg/Transaction does not exist when the same SBC acting as P-CSCF and IBCF.

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

Root Cause: The 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 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 the example of format of To headers that were tested in 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:7893@10.xx.x.xx;tag = aabcd-1234-012
4. To: <sip:7893@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

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: We have not reproduced the memory leak in house. This problem is funded and reproduced in the customer lab, when they were testing their call load. The private fix is tested in the customer lab too.

The code is modified and the bug fixed in cursor and counter area.

Workaround: Lower call rate should lower the risk.

In a SIP LM call, a re-INVITE was sent in 18x-PRACK stage on ingress.

Impact: The SBC sends re-INVITE to 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 re-INVITE 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 5 seconds.

The code is modified to check to validate the state of the call before re-INVITE out.

Workaround: Disable the PRACK or disable LRBT.

The SRTP video (direct I/O) packets shuffled on the wire (video quality issue).

Impact: Out of sequence media packets are observed on out-going streams of pass-through calls on some NICs when incoming media traffic is bursty.

Root Cause: An absence of hardware computed rss hash causes an issue in the media packet processing subsystem, where the packet distributor ends up distributing packets to workers without maintaining flow ordering.

This problem becomes observable when incoming media arrives in a bursty manner.

Steps to Replicate: 

1. Create VM-ware SR-IOV setup using x520 NIC. Use the std passthrough profile with more than 10vCPU.
2. Establish a single pass-through call.
3. Pump traffic from pcap having bursty media. (Edit pcap by introducing bursts in the capture).
4. Enable call trace to capture the packets. Do a RTP stream analysis on the same capture.

The code is modified to maintain flow ordering even when rss hash is not computed by the NIC.

Workaround: Ensure the incoming media stream is not bursty.

The SBC had High Memory related to SBX-104247.

Impact: There is a PRS leak of structures related to IPSEC.

Root Cause: An upgrade of the debian kernel (from 3.16 to 4.19) took place with V08.00 and higher and has triggered a leak of XRM_IPSEC_SA_STRs memory blocks. The leak is only observed in the newer kernel.

Steps to Replicate: Register the endpoints using IPSEC and make calls, and leak will be observed over time.

The code is modified to free the structure that was leaking.

Workaround: This leak will only affect customers who are using IPSEC.
There is no workaround.

Malformed P-charging vector.

Impact: P-Charging-Vector 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 unrecognised parameter with no parameter compatibility information.
3. Ingress IP profile has Store P-Charging-Vector.
4. Egress IP profile has Create P-Charging-Vector.

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

Workaround: Disable support of CFN message in ISUP signaling profile.

The search function in EMA does not work.

Impact: When a custom perspective is created, Search function does not work

Root Cause: There is a node called URI Parameter Manipulation that has a child node with the same name. When a custom perspective with this node is created and a search is performed, the search enters into an infinite loop and is never completed.

Steps to Replicate: Create a Custom Perspective with "URI Parameter Manipulation" and all its children.
Perform a Search.

The code is modified to prevent making the node itself as both parent and child

Workaround: Delete Custom Perspective and restart the SBC.

The CAC Offender list shows incorrect date/time when new offenders are added.

Impact: The CAC Offender List shows the incorrect first and last reject times
for both registeredEndpointCac and unregisteredEndpointCac.

Root Cause: The first and last reject times were incorrectly obtained and set.

Steps to Replicate: 

1) Create sipCacProfile with following data.
set profiles sipCacProfile CAC-REDESIGN dblAggregateRej ingressRatePeriod 10
set profiles sipCacProfile CAC-REDESIGN dblAggregateRej ingressRate unlimited
commit

set profiles sipCacProfile CAC-REDESIGN callIngressRatePeriod 10
set profiles sipCacProfile CAC-REDESIGN callIngressEmergencyPreference enabled
set profiles sipCacProfile CAC-REDESIGN callLimit 30
set profiles sipCacProfile CAC-REDESIGN emergencyOversubscriptionIngress 1000
set profiles sipCacProfile CAC-REDESIGN emergencyOversubscriptionEgress 100
set profiles sipCacProfile CAC-REDESIGN callIngressAggregatePreference 10
set profiles sipCacProfile CAC-REDESIGN callEgressEmergencyPreference enabled
set profiles sipCacProfile CAC-REDESIGN callEgressRate 5
set profiles sipCacProfile CAC-REDESIGN callIngressAggregateEmergencyPreference 10
set profiles sipCacProfile CAC-REDESIGN callLimitIngress 2
commit

set profiles sipCacProfile CAC-REDESIGN callLimitEgress 2
commit
set profiles sipCacProfile CAC-REDESIGN aggregateMessage ingressBurstSize 1
set profiles sipCacProfile CAC-REDESIGN aggregateMessage ingressRatePeriod 1
set profiles sipCacProfile CAC-REDESIGN aggregateMessage ingressRate unlimited
set profiles sipCacProfile CAC-REDESIGN aggregateMessage egressBurstSize 1
commit

set profiles sipCacProfile CAC-REDESIGN message ingressRatePeriod 1
set profiles sipCacProfile CAC-REDESIGN message ingressRate unlimited
commit

set profiles sipCacProfile CAC-REDESIGN callLimitThreshold 100
set profiles sipCacProfile CAC-REDESIGN callIngressRate 2
set profiles sipCacProfile CAC-REDESIGN emergencyOversubscription 1000
commit

2) Provision unregisteredEndpointCacProfile.
set addressContext default zone ZONE2 sipTrunkGroup SBXSUS9_LABSIP1 cac unregisteredEndpointCacProfile CAC-REDESIGN

[TNT] [SBXSUS9] [TNT]
INGRESS -- udp -- SBXSUS9 -- udp -- EGRESS
INVITE -->
<-- 200 OK

3) Provision registeredEndpointCacProfile
set addressContext default zone ZONE2 sipTrunkGroup SBXSUS9_LABSIP1 cac registeredEndpointCacProfile CAC-REDESIGN

[TNT] [SBXSUS9] [TNT]
INGRESS -- udp -- SBXSUS9 -- udp -- EGRESS
REGISTER -->
<-- 200 OK

4) Do registration for few users

5) Initiate calls from AS side.

[TNT] [SBXSUS9] [TNT]
INGRESS -- udp -- SBXSUS9 -- udp -- EGRESS
<-- INVITE
200 OK -->

The CAC Offender list shows incorrect date/time when new offenders are added.

The code is modified to correctly initialize and obtain the first and last reject times.

Workaround: None.

The RTT-TTY support to verify call flow in the SBC.

Impact: Sometimes, the ASCII letters received in a T140 packet are sent as numbers and figures characters on g711 Baudot side.

Root Cause: The Baudot has two modes: LTRS mode and FIGS mode. After transmitting 72 characters continuously in one mode, the recommendation requires to repeat LTRS or FIGS Baudot tone to reassert the current mode.

The LTRS and FIGS mode have some common Baudot codes such as 0 (BKSP),2(LF), 4(SPACE) and 8 (CR). There is no need to change mode when any of these common characters need to be transmitted.

The issue is that when in LTRS mode 72nd character is received as one of common characters mentioned above, then the SBC incorrectly sends FIGS mode Baudot tone. As a result, all subsequent LTRS characters are interpreted as FIGS and show incorrectly on screen of receiving phone.

Steps to Replicate: Create a t140 pcap with characters in each packet (per line) such as this. 

After the fix, the T140 characters display correctly.

The code is modified to check current LTRS/FIGSmode and send the LTRS/FIGS Baudot code.

Workaround: There is no workaround.

The SBX VM was unable to power on post power off procedure.

Impact: The VMware GPU SWe instance does not come up post reboot or GPU is not visible in the instance.

Root Cause: When the SBC SWe instance runs in GPU mode, persistence mode of the NVIDIA driver is enabled using nvidia-smi to prevent the GPU state from being unloaded, this is a kernel-level solution and creating problem when the hypervisor is VMware.

Steps to Replicate: 

1. Set the sweActiveProfile to use GPU.
2. Reboot the instance after the SBC application is up.
   
   RESULT:
   The instance should come up and GPU should be visible in the instance.

Replaced the kernel-level solution with a more robust user-space solution by using NVIDIA Persistence Daemon to address the issue.

Workaround: No workaround.

There was the wrong format of SIP 400 BAD REQUEST.

Impact: When the SBC receives a message and is unable to find all the required headers, the SBC may respond with a bad 400 with syntax errors itself.

Root Cause: When peer intentionally or possibly unintentionally is sending garbage message, the SBC is replying with the same.

Steps to Replicate: Incoming requests need to contain required headers as part of content body section.

The code is modified to now discard the message.

Workaround: Use SMM to drop the message.

The DTLS: 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

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: Using DTLS client that support these ciphers make a connection to the SBX.

The code is modified to include support for these ciphers.

Workaround: None.

The SBC sends all passthrough or transcode codecs in 200 OK of UPDATE at egress when sendOnlySingleCodecInAns is enabled only in Egress TG.

Impact: The SBC is sending multiple codecs in 200 OK (for UPDATE) when sendOnlySingleCodecInAns flag is enabled on egress trunk alone.

Root Cause: For the new modify offer triggered due to UPDATE from the peer, SBC is not applying the full offer-answer processing. Instead it is using the last negotiated codec list for responding back to the peer in the answer. As a result, the 200 OK(for UPDATE) is having multiple codecs towards the egress peer.

Steps to Replicate: 

1. UAC sends INV with AMR, AMRWB, PCMA to the SBC.
2. The SBC sends INV with AMR, AMRWB, PCMA to UAS.
3. UAS sends 18x with PCMA, AMR to the SBC.
4. The SBC sends 18x with PCMA to UAC.
5. UAS sends UPDATE with PCMA AMR to SBC. This SDP from UAS is same as that of last received SDP in 18x from the peer.
6. The SBC is responding 200 OK(for UPDATE) with AMR, AMRWB, PCMA.

The code is modified so that the SBC applies full offer-answer cycle even if it receives the same SDP in UPDATE as that of last received SDP in 18x from the peer, so that, the SBC can pick a single codec for sending it in the answer to the peer.

Workaround: None.

The SBC should handle MOH version 2

Impact: MS Teams have changed the mechanism for putting an active call on hold and signaling redirection of the call media to music on hold server (MOH). The original mechanism (MOHv1) used to send a REFER to SBC to refer the call to MOH server, the new new mechanism (MOHv2) sends a re-INVITE to SBC which can require the SBC to switch the media from primary to secondary NIFs. The SBC did not support this mid call media switching with a re-INVITE hence the media was not switching correctly to the MOH server.

Root Cause: The SBC code did not support mid call media switching between primary and secondary NIFs with a re-INVITE.

Steps to Replicate:
The tests require enabling MOHv2 on the MS Teams client.

Test 1.
--------
1. Establish a PSTN to MS Teams call such that call uses primary (internal) media interface between SBC and Teams endpoint.
2. Put the call on hold at MS Teams client.
3. Verify hold music is heard by the PSTN endpoint.

Test 2.
--------
1. Establish a MS Teams to PSTN call such that call uses primary (internal) media interface between SBC and Teams endpoint.
2. Put the call on hold at MS Teams client.
3. Verify hold music is heard by the PSTN endpoint.

Test 3.
--------
1. Establish a PSTN to MS Teams call such that call uses secondary (external) media interface between SBC and Teams endpoint.
2. Put the call on hold at MS Teams client.
3. Verify hold music is heard by the PSTN endpoint.

Test 4.
--------
1. Establish a MS Teams to PSTN call such that call uses secondary (external) media interface between SBC and Teams endpoint.
2. Put the call on hold at MS Teams client.
3. Verify hold music is heard by the PSTN endpoint.

Above tests were also repeated in a spoke/hub setup.

The code is modified to allow the media and ICE stun processing to switch between primary and secondary NIFs based on the X-MS headers received in a mid call re-INVITE message.

Workaround: No workaround is supported for MOHv2 but call hold mechanism will work fine with MOHv1.

The SBC does not tear down the call if the INVITE contains Require: 100rel and the rel100Support flag is disabled on the ingress sipTrunkGroup

Impact: The SBC does not reject the call if the incoming INVITE contains Require: 100rel and the rel100Support flag is disabled on the ingress sipTrunkGroup.

Root Cause: The SBC was missing logic to reject the call.

Steps to Replicate: 

1. Disable rel100Support flag on the ingress sipTrunkGroup.
2. Send an INVITE that contains Require: 100rel.
   Assuming SBC will send 18x:
3. The SBC will process the call. Once the SBC sends a 18x response to the ingress peer, it will include Require: 100rel and omit PRACK from the list of methods in the Allow header in the outgoing 18x response.
4. Once the SBC receives a PRACK from the ingress peer, it will reject it with SIP 405 Method not allowed response.

The code is modified to reject incoming INVITE messages with SIP 420 Bad extension response if the incoming INVITE contains Require: 100rel and the rel100Support flag is disabled on the ingress sipTrunkGroup.

Workaround: Use SIP Message Manipulation (SMM) to reject the INVITE with SIP 420 response or enable the rel100Support flag on the ingress sipTrunkGroup.

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: Run basic SIP to SIP call with NAPT & RTCP enabled.
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 to address the issue.

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-106200: The SBC 08.02.05 DSP coring system is 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: 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 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

Before a fix: Call sets up and we get a DSP coredump with a single DSP reload. beforefix.PKT is packet capture and no CM signal is observed from the stack.

After a fix: call continues without crash.
afterfix.PKT has capture. G711 signal produced by stack shows CM signal.
(cm_fix.raw)

The associated scripts are added to the JIRA.

The code is modified so there is a check to see if there is enough space available in tx_bits[] array to avoid overflow and avoid a crash in case of multiple CMs with incremental sequence numbers.

Workaround: Use Version 0 for T.38 calls.

The heap-buffer-overflow in ASAN build for SIPS module.

Impact: Observing heap buffer overflow in SCM process for info level log while decrypting the ROUTE header. Reading memory beyond the end of the allocated buffer can result in memory access faults and coredumps.

Root Cause: Heap overflow is because debug statement is trying to print from a string variable which 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 create a local variable of type character array which gets dynamically created and is always null terminated. This variable will be used in the info log.

Workaround: Not Applicable.

Native Forking and DLRBT are not working.

Impact: With the Native Forking enabled, if the call is answered by Teams endpoint, the call gets released by the SBC.

Root Cause: There are two reasons for Forking and DLRBT calls to fail for TEAMS endpoint.

1. With ICE Learning enabled, binding resource modification was failing which resulted in call teardown.

2. For Forking call, the SBC allocates multiple (depending on number of forked INVITES sent out on egress) media resource (XRES) on ingress using same media resource key (localIP+Port+LIG), and with DLRBT enabled, if one of the media resource is activated, we cannot activate any other media resource that is bound to the same key combination (localIP+Port+LIG). This results in Activation failure.

Steps to Replicate: 

1. Configure native forking+DLRBT and Ice learning.
2. Ensure call is forked to PSTN and TEAMS endpoints.
3. Ensure call answered from TEAMS or PSTN endpoint is successful.

1. The code is modified to not return failure for DUMMY resource modification.

2. Mark the resource as forked media resource, so that if another media resource is associated with same key. Do not return a failure for such activation command.

Workaround: Disable the DLRBT and ICE learning for forked calls.

The IP Interface Group will cause issues when there are the same names with different upper or lower cases

Impact: The IP Interface Group will cause issues when there are the same names with different upper or lower cases

Root Cause: The code reads the attribute value (ignoring case) and selecting the options. As a result, both values are marked selected and last selected option will be shown as selected in GUI.

Steps to Replicate: 

1. Create AC, Zone and Trunkgroup.
2. Create IP Interface Group with same names different case and assign one to media then save.
3. Select the Trunkgroup -> Media.
4. The assigned IP Interface group is selected (whichever case selected).

The code is modified to ignore the case to exact match the value to select based on case sensitive.

Workaround: No workaround.

Portfix SBX-104126: A re-INVITE when 200 OK with crypto line other than 1.

Impact: When the SBC offers multiple crypto suite in an INVITE (offer) and the egress sends answer with crypto suite that is other than the top priority crypto offered by the SBC, the SBC sends an unnecessary re-INVITE to the egress when minimizeRelayingOfMediaChangesFromOtherCallLegAll flag is enabled.

Root Cause: The SBC does not update the media subsystem structures correctly.

Steps to Replicate: Configuration:

minimizeRelayingOfMediaChangesFromOtherCallLegAll flag is enabled on ingress and egress TG.
Multiple crypto suite configured on PSP.
The SBC sends INVITE to egress with multiple crypto and egress endpoint answers with crypto which is other than top priority crypto the SBC sent.

Without a fix, the SBC sends re-INVITE to egress.
With a fix, the SBC suppresses re-INVITE to egress.

The code is modified to ensure the SBC suppresses re-INVITE when egress answer has crypto which is not the top priority crypto as per Packet Service Profile configuration.

Workaround: None.

The sendSbcSupportedCodecs flag not set when log level MAJOR.

Impact: When the DBG log level is MAJOR, the IPSP flag configuration "Send SBC supported codecs in late media Reinvite" does not get applied when the SBC is processing the offer to send out to the first Invite without SDP received on ingress leg.

As a result, all supported codecs on the ingress leg are not offered to ingress endpoint in 18x or 200OK for initial Invite without SDP if DBG log level is not INFO (or) TRC is disabled even if "Send SBC supported codecs in late media Reinvite" flag is enabled.

Root Cause: The code to pass "Send SBC supported codecs in late media Reinvite" flag indication from IPSP extension for ingress leg to other modules was within a block meant for only Info/TRC level log analysis/display.

Steps to Replicate: 

1. Set the DBG log level to MAJOR.
2. Enable the "Send SBC supported codecs in late media Reinvite" flag on ingress leg IPSP.
3. All supported codecs on the ingress leg are not offered to ingress endpoint in 18x or 200OK for initial Invite without SDP.

The code is modified so the "Send SBC supported codecs in late media Reinvite" flag indication is now copied independent of debug log level.

Workaround: None.

The SBC crashed and a coredump occured.

Impact: The SCM process coredumps due to NULL pointer access on a pointer that is freed due to BYE and HOLD race in a transfer call scenario.

Root Cause: There was an illegal memory access, absence of NULL check, 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 code is modified to address the issue.

Workaround: No workaround.

A memory leak was observed in SAM process.

Impact: A memory leak was observed in the SAM process.

Root Cause: There is race condition in the code that handles CALL_AUDITs and CALL_CLEANUPs that can cause a memory leak.

If the response to a CALL_AUDIT takes to long, the code that handles the "late" response has allocates memory for a structure that may never get freed.

Steps to Replicate: This issue is caused by a race condition that cannot be forced and therefore we cannot specify steps to reproduce this issue.

The code is modified to add a timer every time a fault structure is allocated. When the timer expires, if the the structure still exists it is freed.

Workaround: N/A

Portfix SBX-95983: The Customer SBC was seeing STEAL_WARNING:

Impact: Getting a steal warning at login.

Root Cause: The filtering criteria for a high steal value was not well defined.

Steps to Replicate: The script runs as a cron job. This can also be manually tested by making changes in mpstat logs.

The code is modified to detect and warn about high %steal value.

Workaround: N/A

Portfix SBX-103629: The SIP registrations are failing. The SBC was reporting REGISTER_PARSE_ERROR and replies with SIP 500 when it receives retransmitted initial REGISTER (CSEQ 1), followed by REGISTER with Authorization header (CSEQ 1).

Impact: When the SBC recv rexmit of registration (cseq=1) after sending a 401/407, the SBC relays to the AS. At the same time, the IAD sends new registration(cseq=2) for authentication. It triggers a race condition to the SBC and response 500.

Root Cause: The SBC should relay rexmit (cseq=1) registration to the application server.

Steps to Replicate: The IAD send registration(cseq1) to AS, AS response 401 to IAD, IAD rexmit the same sceq1, and send a new sceq2 with auth header.

The code is modified to response rexmit request (cseq=1). As a result, a subsequent one cseq=2 can properly handle the relay to AS.

Workaround: N/A

SIP calls stop when receiving a 183 (Precondition).

Impact: A call stopped working after a 183 received without SDP.

Root Cause: As part of egress precondition interworking, to negotiate the SBC should send an UPDATE to egress endpoint. When 183 received without SDP, the SBC should not try to send UPDATE. The SIPSG call state assumed an UPDATE is sent. As a result, when the next 183 is received it tried to queue the 183 assuming UPDATE is in progress.

Steps to Replicate: 

1. Configure the SBC for precondition egress interworking call flow.
2. Send an initial INVITE from the ingress without precondition attributes.
3. The INVITE is sent with preconditions to egress endpoint.
4. (1) INVITE ====>
   (2) <======= 100
   (3) <======= 181 (without Require)
5. Send the first 183 Session progress without SDP
   (4) <======= 183 (without Require)
6. Send the second 183 Session progress with SDP and precondition attributes.
   (5) <======= 183 (Require: 100rel,precondition)

The above 183 is not processed due to bug in the code. As a result, retransmissions are observed.
(6) <======= 183 ((5) is re-sent)
(7) <======= 183 ((5) is re-sent)

The code is modified to avoid this state transition when 183 received without SDP.

Workaround: Remove the 183 without SDP message using SMM.

Unable to add or Edit route with # in Destination National - CLI or EMA.

Impact: User is not able to store some special characters for the destination number field in the route entity.

Root Cause: The pattern defined for the destination number field did not allow all special characters.

Steps to Replicate: Create a route with special character like #123 for the destination number field in the route entity. It should be successful after this fix.

Portfix SBX-102833: MS Teams calls are dropping when placed on hold.

Impact: When MS Teams puts a call on hold and then attempts to retrieve it while the microphone is disabled, this results in the call being cleared.

Root Cause: MS Teams actions the call retrieve by sending an INVITE with replaces message to the SBC. When the microphone is disabled, this message includes a=recvonly.

The SBC sends a 200 Ok response to the INVITE with replaces with a=sendrecv, while MS Teams is expecting a=sendonly. This causes MS Teams to clear the call.

Steps to Replicate: 

1. Establish a PSTN to MS Teams call through the SBC.
2. Place call on hold from MS Teams.
3. Disable the microphone in the browser running MS Teams, and then retrieve (place off hold) the call.
4. The call is dropped.

The code is modified to respond to an INVITE with replaces containing a=recvonly with 200 OK containing a=sendonly.

Workaround: N/A

Portfix SBX-90251: An SM process healthcheck timeout occurred during a configuration restore on the Cloud SBC.

Impact: The SM process crashes due to a healthcheck failure.

Root Cause: As part of a load configuration, the configuration tar file needs to be untared. The untaring is taking longer than the healthcheck time out, when the size is big.

Steps to Replicate: 

1. Save the configuration.
2. Load the configuration.
3. Check if healthcheck failed and the SM crashed.
4. The SM process should not have crashed and the load configuration must have been completed succesfully.

The code is modified for the running tar command so that the healthcheck does not fail during a load configuration.

Workaround: Override the healthcheck for the tar command.

Portfix SBX-103207: The SBC SWe 8.2.0F1 duplicates audio from call B to call A.

Impact: If CN is not negotiated for G711 codec and remote peer still sends CN packets that match default CN payload type (13), then user on other end may hear cross talk audio of completely unrelated channel or hear own reflect audio.

Root Cause: When a g711 side does not negotiate CN in signaling, DSP does not initialize Comfort Noise Generation object. However, if remote peer still sends CN packet that matches the g711 SID payload type configured in PSP (default 13), DSP accepts the packet. It processes that CN packet incorrectly and as a result uses stale voice buffer which happens to be of another channel. This continues until next voice packet for that channel arrives. Hence, we happen to see cross talk audio from other call during silence period. In some cases, the user may hear own audio also and that is different manifestation of the same problem. This issue is specific to SWe.

Steps to Replicate: 

1. Run the CN in signaling.
2. The DSP will not initialize Comfort Noise Generation object.
3. Send a remote peer to the CN packet that matches the g711 SID payload type configured in PSP (default 13) and the DSP accepts the packet.
4. Process that CN packet and as a result, uses stale voice buffer that happens to be of another channel.
5. This continues until next voice packet for that channel arrives.

The code is modified to initialize the comfort noise object even though CN is not negotiated and process the CN packets correctly.

Workaround: There are multiple workarounds for this issue:

1. Change the default payload type of comfort noise from 13 to something else (say 15) in PSP of peer that is sending CN packets. This will make DSP drop CN packets because payload type will not match. Run the PSP configurationshow

configuration profiles media packetServiceProfile G711_NONE_NONE_NONE..silenceInsertionDescriptor {g711SidRtpPayloadType 13;heartbeat enable;}

2. Enable the silence suppression on PSP of peer that is sending CN packets and keep CN payload type that matches with CN payload type.

SBX-94491

1

It takes 7 seconds for the standby server to detect a switchover triggered by a reboot thus delaying to time to become active (OpenStack 1:1 HA).

Impact: A switchover triggered by the reboot takes 7 seconds to be detected by the standby, increasing the switchover time and causing media takeover issues.

Root Cause: The transport protocol is responsible for noticing the peer has gone away, and with the UDP protocol used for SWe, this process takes too long.

Steps to Replicate:This does not explain the steps to take to replicate the issue. 

The code is modified to alert the peer to take over rather than relying on the transport protocol health check to timeout.

Workaround: None.

Portfix SBX-101628: The CPX process leaks memory for a call load.

Impact: There was a memory leak in MsgClient message queue.

Root Cause: The dispatcherAgent's MsgClient was not instantiated properly, causing messages to be queued and never deleted.

Steps to Replicate: Perform traffic test with ASAN load to confirm that memory leak is no longer present.

Instantiate DispatcherAgent's MsgClient properly and to not use the message queue. Run a clear message queue in destructor of MsgClient to address the issue.

Workaround: None.

Portfix SBX-102737: The SM Process experiences a core dump on both the active and standby after an sbxrestart.

Impact: The SM Process cores at startup due to healthcheck.

Root Cause: System_i::fillSavedConfigurations is trying to read /mnt/gfsvol1/config-versions.txt, but it is taking too long.

Steps to Replicate: 

1. Set up the MRFP system with OAM.
2. Perform an upgrade.
3. Perform a system restart.

Pause healthcheck in System_i::fillSavedConfigurations to address the issue.

Workaround: Reboot the failing node.

Portfix SBX-91476: The PEM header contains a gated parameter.

Impact: The SBC is sending a gated parameter in the PEM sendrecv toward the Ingress
P-Early-Media: sendrecv gated.

Root Cause: By design if the Early Media is gated by a peer or gated locally, the SBC adds the gated parameter towards the Ingress.

Steps to Replicate: 

1. On the Egress Leg, the earlyMedia method should be pEarlyMedia.
2. An INVITE should be received with the P-Early-Media: supported. The tone criteria is configured to play tone with 183 message.
3. The 183 is recvd with the P-Early-Media: inactive.
4. The SBC starts playing the tone as tone criteria matches.
5. The SBC sends a P-Early-Media: sendrecv,gated toward Ingress in 183.

A new flag "suppressGatedParam" is added at the TG level.
If this flag is enabled, the SBC does not add gated param towards the Ingress.

set addressContext default zone <ZONE_INGRESS> sipTrunkGroup <TG_INGRESS>media earlyMedia suppressGatedParam <enabled/disabled>

Workaround: N/A

Portfix SBX-103948: The SBC Application is crashing when a CPaaS to PSTN call is made.

Impact: After a reboot/restart, the CPX process could not read the sdpContent values from "action/from" and "action/to" SMM definitions, as a result while applying the action during a call it does not find the sdpContent and causes a core to happen due to processing a null or incorrect value.

Root Cause: After a reboot/restart, the CPX process is unable to read/action/from/sdpContent and /action/to/sdpContent due to wrong path/invalid pointer.

Steps to Replicate: Configure the SMM rules to delete the SDP line and generate traffic to confirm it works correctly.

The code is modified to read and store the from/sdpContent and to/sdpContent correctly in the SCM Process cache.

Workaround: Disable the SMM that deletes the SDP.

Portfix SBX-101765: The SBC is going down when running NNIProfile CLI

Impact: When the application code was reading the NNI profile from CDB, there was a memory overwrite problem.

Root Cause: The local variables that were used to store the information being read from the CDB were not large enough resulting in memory being overwritten.

Steps to Replicate: Replicate in lab environment only.

The code is modified to use large local variables to avoid the memory overwrite.

Workaround: None.

The SipSignalingPorts OutOfService after switchover.

Impact: The SIP sigPorts stuck in OOS after a switchover.

Root Cause: Customer had the network/pkt port issue, on one of their HA node, which caused pkt port(s) to bounce randomly, i.e. pkt port went DOWN and came back UP within 2 to 3 seconds. So they have been keeping that node as standby node. They also have link detection enabled for pkt port(s) and have around 100 LIFs per pkt port, one per SIP SIGPORT. When pkt port went down, NRS delays the port down event processing for 2 second to allow link failure detection to be ready and also to avoid the race condition between NRS and LVM. When 2 second delay timer is up, NRS starts to take down affected LIFs and notifies local SIPCM and SIPFE so they can take down affected SIP SIGPORTs.

In SIPCM, all the sockets on the affected sigPort are put in a delete pending table and starts a 1 tick timer. Then the socket(s) is being deleted after 1 tick timer is up.
When pkt port came back up, NRS processes the event with no delay and notifies SIPCM and SIPFE as well. Since there are around 100 LIFs, there were many messages exchanges between NRS/XRM/SIPCM/SIPFE. NRS LIF FSM has the mechanism in place to handle the timing issue and LIFs were all back in service. But SIPCM failed to activate some SIP SIGPORT(s) while binding the socket(s). These error messages indicated that SIPCM tried to activate the SIGPORT while it was still pending delete. Therefore SIGPORT got stuck in OOS(broken state) in both SIPCM and SIPFE on standby node. If there was a switchover happened later, user would then noticed one or more SIGPORTs were OOS. They have to manually bounce those SIGPORTs to bring them back in service.

Steps to Replicate: The nature of the problem was the timing caused race condition. There is no good way to re-create/verify the fixes.

The code is modified in the following manner:

1. Introduced a new 1-tick timer in SIPCM_DATA_STR, activateRetryTimerId.
2. In SipCmActivateCallSigPort(), added deletePendingSocketTable so that if sigPort is found in the table, then the 1-tick timer starts. When the timer is up, SipCmActivateCallSigPort() is invoked again. Once the sigPort is activated successfully, SIPCM notifies SIPFE as usual.

Workaround: None.

Portfix SBX-101922: GUI CDR Configuration screen - Syslog server field can not be configured.

Impact: The server section is appearing on the CDR configuration, but the configuration does not participate in configuration.

Root Cause: The child object was added. As default behavior of the EMA, the added child object was not needed.

Steps to Replicate: Log in to the EMA and configure the CDR and ensure the Syslog configuration is not listed on the CDR configuration page.
configuration--> system provisioning --> Base provisioning --> CDR configuration.

Restricted the child object in this particular case to address the issue.

Workaround: None.

The RE-REGISTAR was shorter than 3600 secs due to a child AoR. 

Impact: When the 200 OK response to REGISTER request contains a P-Associated-URI header, the SBC creates a child AOR and forwards all REGISTER refresh requests to the registrar (effectively disabling the SBC fast refresh response).

Root Cause: The creation of child AORs cause all REGISTER refresh requests to be sent to the registrar (effectively disabling the SBC fast refresh response).

Steps to Replicate: 

1. Configure the SBC to perform registration.
2. The 200 OK response to REGISTER request contains a P-ASSOCIATED-URI header.
3. In the error case, the refresh REGISTER requests are all forwarded to the registrar.

Removed the child AOR check from SipRaRegisterRequestCompletedAorNfy(), permitting the SBC to send fast refresh responses.

Workaround: N/A

Portfix SBX-103645: There was a a customer 81.R5 upgrade with a spiltbrain M-SBC boot issue.

Impact: One of the M-SBCs in N:1 mode is not coming up after an upgrade.

Root Cause: The M-SBC node went for multiple reboots due to a configuration profile change and split brains after an upgrade exceeding the max limit for reboot.

Steps to Replicate: Upgrade all M-SBC nodes at one time so that they all come up together.

The code is modified to avoid split brain due to nodeId/serviceId collision by informing the peer nodes about the self node's nodeId/serviceid as soon as it is allocated.

Workaround: Restart the M-SBC application manually on the node that has exceeded max reboot limit.

Portfix SBX-98243: The SIPREC Status command is not showing all four SRS servers after upgrade completes

Impact: The SIPREC status does not correctly display all SIPREC servers if the SBC does a SYNC on an HA set up when more than one SIPREC recording is active. The SYNC occurs when the standby box is restarted while the active remains up. This is not an issue if a new SIPREC call is started while the HA set up is already running in active/standby mode. This problem only impacts the status screen and not the processing of the SIPREC call.

Root Cause: After a SYNC, only one SIPREC entry is maintained in the SIPREC status on the standby server. So if a switchover then occurs, the status screen only shows one active call, although all the other active SIPREC calls are maintained correctly.

Steps to Replicate: 

1. The HA Set up with the SIPREC (Quad or single).
   If the Quad Recording, single call is sufficient.
   If there is a Single recording, there is multiple calls with SIPREC.
2. Trigger the SYNC (Restart the standby box).
3. After SYNC is complete, switch over.
4. Check the status of the recordings.

The code is modified to maintain the status information of all the SIPREC calls from the active server.

Workaround: Do not restart the standby server while there are SIPREC calls running on the active server.

The SBC is rejecting the second Update message from the Egress as a 500 result into a call failure.

Impact: The SBC rejects the second Update from the egress due to a DLRB feature.

Root Cause: The First Update SIPS response locally 200OK but not clear the server request message. As a result, the second Update triggers a SIPS answer 500.

Steps to Replicate: Configure the DLRB, the Egress response 183 with the SDP, the first Update, and the second Update.

The code is modified so after a response 200OK, the SIPS clears the server request so it handles the subsequent one.

Workaround: Disable the DLRB.

A DSP core occurred on the SBC.

Impact: The DSP faults with a memory fault in area that pulls buffers out of EMAC port. Suspicion is on the buffer size that 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: The root cause is a speculation that the EMAC system is occasionally is a incorrect bufSize, similar to a bit flip.

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

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: None.

Portfix SBX-101394: The SBC restarts after receiving 3xx with the embedded Identity in Contact header.

Impact: Global-buffer-overflow error when the SBC received a 3xx with the Identity header embedded in the contact header.

Root Cause: The root cause here is that the number of elements in pstKnownTypes array are less than the length on that the loop was running on.

Steps to Replicate: 

1. The UE1 sends an Invite to the SBC.
2. The SBC sends an Invite to the customer UAS.
3. The UAS-1 sends a 3xx with the Identity header embedded in the contact header.
4. The SBC sends an ACK.

Honor Embedded Headers and Enhanced Local redirection flag are enabled in the egress TG's IPSP.

The code is modified to use the actual length of pstKnowTypes array rather than using the SIP_HEADER_MAX. Calling the SipHdrTranspGetNumKnownTypes() function returns the actual number of elements in pstKnownTypes array.

Workaround: None.

Portfix SBX-99134: There was a SCM process coredump after a second switchover while establishing the SIP-GW-H323 call load.

Impact: During a switchover and switchback while running a load, there may be some stale entries in the SIPSG and CC control blocks. Such entries are cleared on an audit but while clearing, the SIPSG is sending CC_SG_UPD_ACCT_NFY_MSG_STR to the CC. Since the load is running a corresponding entry for the CC, the index may be allocated to a new call. As a result, the msgPtr-> gcid is not matching with the ccbPtr->gcid and the gcid stored in the SIPSG.

When the CC receives this message, the mismatch happens and it logs a SYS_ERR(SE_EVLOG, SE_CC_UNEXPECTED_DATA))

Root Cause: While performing a switchover during a high load run, the SBC should be run in normal mode instead of sensitive mode.

Steps to Replicate: In this scenario, the HA pair and a standalone SBC are used.

1. Use the External PSX to establish SIP->GW calls on the active SBC and GW->SIP calls on a stand alone SBC.
2. Configure the IPv4 GW Trunkgroup between an active SBC and a stand alone SBC. Originate the IPv4 SIP->GW call load on an active SBC.
3. Terminate the IPv4 SIP call load on a stand alone SBC to handle the GW->SIP signaling call load.
4. Successfully establish the required call load (28000 sessions).
5. Restart the active SBC.
6. After restart, successfully establish a required call load (28000 sessions).
7. Then perform a second restart on the currently active SBC.
   The default active SBC should not go down.

The code is modified to not use a sys error if the GCID sent from the SIPSG in a msgPtr is different from the GCID in the ccbPtr during a switchover.

Workaround: N/A

Portfix SBX-99600: After a switchover on SBC 5400 platform, the SCM process is coredumping, due to hitting a SYS_ERR while running in sensitive mode.

Impact: When performing a switchover and switchback while running a load, there may be some stale entries in SIPSG and CC control blocks. Such entries are cleared during an audit, but while clearing these entries, the CC is sending SG_CC_DISC_RSP_MSG to SIPSG. Since the load is running a corresponding entry of the CC , the index might be allocated to a new call. As a result of this issue, the msgPtr-> gcid is not matching with the ccbPtr->gcid in SIPSG.

When the CC receives a message, the mismatch happens and the CC logs the SYS_ERR(SE_EVLOG, SE_CC_UNEXPECTED_DATA))

Root Cause: While performing a switchover during a high load run, the SBC should be run in normal mode instead of a sensitive mode.

Steps to Replicate: 

1. Establish total sessions of 141K call load on the Active box.
2. Perform multiple switchovers.

Observed SCM process coredump should not be seen.

If the GCID sent from the CCin msgPtr is different from the GCID in ccbPtr during the case of a switchover, do not use a sys error to address the issue.

Workaround: N/A

Portfix SBX-102472: ImPr Process core dumped for Default LI with IPSEC.

Impact: When a call is intercepted during switchover, the SBC throws SYS error SE_SYS_HASH_EXISTS and causes coredump.

Root Cause: If a call is intercepted during switchover, the standby SBC may have the duplicate info of the intercepted call. So it throws SYS error "SE_SYS_HASH_EXISTS"
The coredump is due to the above SYS error.

Steps to Replicate: 

1. The SBC is configured for Default LI.
2. Run a load of 5 cps of intercepted calls and trigger switchover on the primary SBC.
3. The secondary SBC comes up as active but the primary SBC dumps core.

The fix is given to handle the duplicate call data of the intercepted call on the Standby SBC.

Workaround: Disable the coredump level.

Portfix SBX-97424: The SCM process core observed in the M-SBC after a switchover with the SIPREC.

Impact: The SCM Process coredump is observed in the M-SBC after a switchover when the SIPRec occurred with a stable call and BYE for the main call is triggered post switch-over.

Root Cause: The recorderType field (field describing the type of recording happening in the SBC) is not mirrored. Post switch-over once the main call is terminated, the SIPREC delete command goes from an S node to M node but this does not carry the recorderType field. When the command reaches M node from S node with recorderType set to zero, the M node accesses a NULL pointer (call data channel).

Steps to Replicate: 

1. Establish a stable SIPRec call.
2. Perform a switch-over.
3. Terminate the main call.

Send a recorderType for all type of monitor commands. Add a Call Data Channel NULL check in the M node while processing a MonitorCommands.

Workaround: N/A

The DSP Threshold setting is not generating a trap on SBC 5400.

Impact: The g711PacketThreshold, g729Threshold, and g726Threshold onset and abate traps are not sent.

Root Cause: The NRM did not receive CLI updates to the g711PacketThreshold, g729Threshold, and g726Threshold, and the trap generation code used wrong trap names.

Steps to Replicate: 

1. Provision the threshold levels:
   set oam traps dspAdmin dspAvailabilityTrap g729Threshold 40
   set oam traps dspAdmin dspAvailabilityTrap g726Threshold 60
   set oam traps dspAdmin dspAvailabilityTrap g711PacketThreshold 80
   commit set oam traps admin sonusSbxDspAvailG729OnSetCrossThresholdNotification state enabled
   commit
   set oam traps admin sonusSbxDspAvailG729AbateCrossThresholdNotification state enabled
   commit
   set oam traps admin sonusSbxDspAvailG726AbateCrossThresholdNotification state enabled
   commit
   set oam traps admin sonusSbxDspAvailG726OnSetCrossThresholdNotification state enabled
   commit
   set oam traps admin sonusSbxDspAvailG711OnSetCrossThresholdNotification state enabled
   commit
   set oam traps admin sonusSbxDspAvailG711PacketAbateCrossThresholdNotification state enabled
   commit
2. Configure the trap target: set oam snmp trapTarget EMS160 ipAddress 10.xxx.xx.xxx port 162 trapType v2 state enabled commit
3. Limit the compression resources to make the issue readily occur: set system mediaProfile tone 98 compression 2 commit
4. Perform transcoded (e.g. G711 to G729) calls that exceed threshold limits, and verify that onset traps are sent to the trap target.
5. Clear the transcoded calls, and see abate traps are sent to the trap target.

The code is modified to support g711PacketThreshold, g729Threshold, and g726Threshold values.

Deprecated the support for allThreshold, as it was never implemented in the SBC.

Workaround: N/A

The code is modified to disable the Path MTU Discovery by setting kernel parameter net.ipv4.ip_no_pmtu_disc to 2. When set to 2, the DF bit is set to 0 for the transmitted packets on every created socket. The configuration parameter is "system admin <name of system> kernelParams ipNoPmtuDisc".

Workaround: The workaround is a hack. It can be used as a one time test only. The hack will not survive Linux reboots.
1. Make changes on the current Standby (assuming SBC1 is currently active, and SBC2 is currently standby)
[root@SBC2 ~]# date; cat /proc/sys/net/ipv4/ip_no_pmtu_disc
[root@SBC2 ~]# date; echo “2” > cat /proc/sys/net/ipv4/ip_no_pmtu_disc
[root@SBC2 ~]# date; sbxrestart
2. Wait until the SBC is up and synched. Ensure the p_no_pmtu_disc is set to 2.
[root@SBC2 ~]# date; sbxstatus | tail -4
[root@SBC2 ~]# cat /proc/sys/net/ipv4/ip_no_pmtu_disc
2
[root@SBC2 ~]#
3. Make changes on the current Active.
[root@SBC1 ~]# date; cat /proc/sys/net/ipv4/ip_no_pmtu_disc
[root@SBC1 ~]# date; echo “2” > cat /proc/sys/net/ipv4/ip_no_pmtu_disc
[root@SBC1 ~]# date; sbxrestart
4. Wait until the SBC is up and synched. Ensure the p_no_pmtu_disc is set to 2.
[root@SBC1 ~]# date; sbxstatus | tail -4
[root@SBC1 ~]# cat /proc/sys/net/ipv4/ip_no_pmtu_disc
2
[root@SBC1 ~]#
5. May perform a switchover to make the SBC to be active.
6. Run customer tests.

The display-name in the Diversion header or History-info header is deleted during interworking.

Impact: The SBC does not send display name present in ingress INVITE's diversion header in history info header in egress INVITE.

The SBC does not send display name present in ingress INVITE's history info header in egress INVITE's diversion header.

Root Cause: The SBC does not consider display name when interworking between the diversion header and history info header.

Steps to Replicate: 

1. Ensure the display name is sent in history info header of egress INVITE when the SBC is converting diversion header to history info header.
2. The SBC should send display name in diversion header of egress INVITE when the SBC is converting history info to diversion header.

The code is modified to ensure the display name is sent when the SBC is interworking history info and diversion header.

Workaround: None.

Portfix SBX-103492: Performance: Observed "Scm" Process core on standby box while running the load on Openstack ISBC HA.

Impact: The SCM process cores after a switchover on Standby (new active) node when running the TCP-TCP load at 100 CPS with 10 secs call hold time.

Root Cause: The issue is due to not setting the "prtSigZoneEntry->nextMnsPortPtr" when the SIP signaling port is removed.

Steps to Replicate: Perform switchover when running TCP-TCP load at 100 CPS with 10 secs CHT.

The code is modified so whenever the SIP signaling port is removed, set the prtSigZoneEntry->nextMnsPortPtr to NULL.

Workaround: None.

Portfix SBX-104494: The PES process cored while testing the Flex AD support with ERE.

Impact: The PES process dumps core while executing an Active Directory (AD) service when no AD profile and/or AD attribute profile configured.

Root Cause: While executing the AD service, PES fetches the AD profile from cache. Since there is no AD profile was configured in this case, cache shall return NULL. The code was missing to check for NULL for the AD profile pointer and dereferencing the NULL pointer results in a coredump.

Steps to Replicate: Configure a AD number translation criteria with ingress TG as the trigger criteria type, but with no AD profile and/or AD attribute profile configured. Make a call on the ingress TG.

The code is modified to check for NULL for an AD profile and AD attribute profile. If there is no profiles configured, the control returns and the service is marked as failed.

Workaround: Configure an AD Profile and AD attribute profile so that the existing code can be executed further.

Portfix SBX-104773: The SBC is not coming up on the VMware when using two NUMAs.

Impact: The SBC fails to come up in the VMware dual NUMA configuration. (cps service failed to come up)

Root Cause: As part of the CPS service, there is one init script that calculates the performance indices. In the VMware dual NUMA scenario, the index calculator binary gets launched in the last core, which happens to be on the 2nd NUMA. Since the huge pages are reserved on NUMA0, so the index calculator binary fails (saying fails to create mbuf pool). As a result, the CPS fails to come up.

Steps to Replicate: 

1. Install an ISO in VMware dual NUMA instance. Ensure the number of vcpu should be large enough so that we get 2 NUMAs in the instance.
2. Verify if the CPS comes up by "service cps status" command.

The code is modified to always launch on the second core, to ensure the NUMA0 is always used.

Workaround: None.

SM Process core on the Server.

Impact: The SM Process crashed while executing the "show table system syncStatus" command.

Root Cause: The shell script used to get the Oracle sync status - PolicyDBSyncStatus.sh - did not return within 10 seconds, causing a healthcheck timeout that caused the coredump.

Steps to Replicate: This problem is not reproducible.

Disable healthchecks while fetching the syncStatus to address the issue.

Workaround: None.

The SBC running version 6.2.2 cannot capture the media with MCT.

Impact: The MCT reload configuration (SBC restart or switchover) will not succeed.

Root Cause: Logic was missing during the restart in order to properly reload the MCT configuration.

Steps to Replicate: The steps are not easily producible. 

The code is modified to properly reload the MCT configuration.

Workaround: User can delete the MCT config and reconfigure it after any restart/switchover.

The PRS process cored, backtrace shows the PrsNpCoreStatusProc(), and the XSC core is spinning.

Impact: Only one customer reported this peculiar issue where the Network Processor (NP) hangs due to an interrupt generated by the internal hardware module because a zero length packet request was sent.
This caused the module to lock up and NP is no longer able to transmit any packets.

Root Cause: We were never able to find anything in the code that would send a packet with zero length.

Steps to Replicate: You really cannot test this change without damaging the Network Processor.
The zero-length check was tested by adding debug code that would force a zero-length check and handle the interrupt.

The code is modified to log the event and not submit the zero length packet to the hardware module. The added code also handles the interrupt and continue running.

Workaround: None.

The SM process and CPX cores prevented the server to come back up as standby after switchover.

Impact: The SM process and CPX processes cored on slot 1 after LDG triggered switchover to slot 2.
The SM process was deadlocked while retrieving peer NTP status.
The CPX cores happened after SM process coredump, when writing SMM profiles into shared memory.

Root Cause: The root cause was SM process deadlock.

Steps to Replicate: This is time sensitive issue. I do not have steps to re-produce or verify the fix.
Suggest to run full regression test with switchovers.

The code is modified to release the smNtpLock_ after issued NTP restart command.

Workaround: None.

Portfix SBX-104769: The SCM process cored while testing the SBX H323 Conformance and Interworking.

Impact: The SCM process will core for the RFC 2833 to Inband DTMF in SIP to H323 interworking call scenario.

Root Cause: Accessing of a NULL pointer caused the core dump.

Steps to Replicate: Run a SIP-H323 interworking call with SIP side rfc2833 and the H323 side Inband DTMF being enabled.

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

Workaround: None.

The SBC was sending m=application 0 UDP/BFCP (null).

Impact: The SBC generates the syntax error m-line UDP/BFCP in 183.

Root Cause: The SBC accesses initializes data when the format m-line for UDP/BFCP.

Steps to Replicate: An incoming call with the m-line UDP/BFCP. ERE/PSX using script NO_ROUTE and triggers an announcement. The internal 183 has m-line UDP/BFCP with invalid syntax.

Make m-line initialize properly to address the issue.

Workaround: Use the SMM to correct m-line syntax error

Crosstalk issue on the SBC 5400.

Impact: When a transcoded call with Opus codec and the Opus termination does not send any packets to the SBC, then another termination of Opus call may hear the audio from another unrelated Opus-transcoded call or it may hear white noise.

This occurs on the SBC5x10/5400/7K but not on the SWe platforms.