SBC Core 09.01.00R001 Release Notes

SBX-101057 | SBX-101133

1

Portfix SBX-101057 Both applications coredumped.

Impact: If an INVITE arrives requiring ICE support and only contains TCP candidates and the SBX is configured with SMM storeIpTg configuration, then it causes the SBC to crash.

Root Cause: The SBC does not support ICE requests with only TCP candidates, this was occurring due to network configuration issue in a MS Teams deployment. MS Teams normally sends UDP ICE candidates but as there was no UDP connection available it tried to use TCP. The SBC was trying to reject the call due to no UDP candidates but the additional storeIpTg configuration resulted in the code taking a different code path and access invalid memory resulting in a coredump.

Steps to Replicate: Send an INVITE to the SBC, which only contains TCP ICE candidates with the SBC configured for iceSupport and using SMM storeIpTg logic to swap to a different ingress trunk group.

The code is modified to avoid accessing invalid memory in this failure scenario.

Workaround: Run the SMM to drop incoming call with UDP ICE candidates.

SBX-101934 | SBX-102485

1

Portfix SBX-101934 The call is failing intermediately due to an Unsolicited Call Cleanup.

Impact: The call is failing intermediately due to an Unsolicited Call Cleanup.

Root Cause: The affected call failed due to the XRM having received an error response from the NP for a modify RID command. This was most likely the race condition in NP because the RID enable and modify commands were issued within the same seconds, but was from two different NP users (BRM and XRM) for that particular call flow.

Steps to Replicate: Due to nature of race condition, it is not guaranteed to reproduce the problem.
However, run a NAPT(RTP and RTCP) regression tests on SWe to possibly reproduce the issue.

The code is modified use the same NP interface user handle when sending the RID enable and modify the commands to NP for that special case.

Workaround: No workaround.

SBX-101978 | SBX-102293

1

Portfix SBX-101978 The call forking with the MS Teams and GW-GW fails.

Impact: The call forking with the GW-GW may not work correctly.

Root Cause: The call forking logic was not copying all of the internal parameter information when grouping the routes based on each AoR tag. This results in the SRTP enabled information being lost and the call was initiated using plain RTP instead of SRTP.

Steps to Replicate: Make a call forking call over GW-GW where one egress end point requires the SRTP and the other does not. Check that the SRTP call is correctly setup.

The code is modified to correctly copy all of the route parameters between the PSX response and the forking queues.

Workaround: No workaround.

SBX-102006 | SBX-102267

1

Portfix SBX-102006 The SBC failed to send ACK to the correctIP.

Impact: After a call connected with egress received RR in 2xx, the SBC sends a reInvite, and received the rexmit of 2xx. Later on, the SBC sends ACK to the wrong destination.

Root Cause: The retransmit of 200OK accidentally deletes the previous RR.

Steps to Replicate: A call B, B responds with 200OK with RR. A reInvite triggers the SBC reInvite to B. B responds with 2xx and rexmit 2xx. The SBC sends ACK to the wrong destination (based on contact not from previous RR received).

The code is modified so the SBC ignores the update for the data dialog.

Workaround: No workaround.

SBX-100164 | SBX-101533

1

Portfix SBX-100164 Back-to-back cores occurred on the server.

Impact: A SCM cored due to memory corruption while parsing an INVITE with a very long and invalid CallId field, while parseError trace logging was enabled.

Root Cause: A SCM core is caused by memory corruption that is the result of the Trace Logging code overwriting a buffer.

This can occur when the SIP parser encounters an invalid CallId that is also very long.

It is also possible that other parsing errors can trigger this core, especially if the parse error was encountered for a particular header that is very long.

Steps to Replicate: This can be reproduced by enabling parseError trace logging and then sending a INVITE, which includes a badly formatted CallId that is the maximum allowed side for a CallId:
"set global callTrace errorFilter errorType parseError"

The code is modified to ensure that it does not overwrite the end of the buffer when it is attempting to write a very long error message string.

Workaround: Disable parseError tracing.

SBX-101547 | SBX-101675

1

Portfix SBX-101547 Switchover and coredump after a call is placed on hold.

Impact: The code was dereferencing a NULL pointer and causing the SCM process to crash.

Root Cause: The customer had the passThruPrivacyInfo control enabled on both the ingress and egress privacy profiles. However, the ingress side of the call did not pass through some expected information related to the INVITE message and it caused the code to dereference a NULL pointer.

Steps to Replicate: Unable to reproduce this issue, the code has been fixed based on code review and coredump analysis.

The code is modified to validate the pointer is not NULL before trying to use it.

Workaround: Disable the passThruPrivacyInfo controls.

SBX-101329 | SBX-101670

1

Portfix SBX-101329 The PSBC call drops on the PM-SBC failover.

Impact: The media packets are not transmitted after a switchover of an M-SBC with the RTP Monitoring Profile enabled on egress PSP.

Root Cause:
1. The SBC activates both the ingress and egress resources first.
2. The RTP monitoring is started. The RTP flow mode change to rcv-only on active box:
a. The flowchange cmd will issue a Modify Command to standby, it will trigger to de-cache the route.

Since the modify flag does not have any remote IP change flag set, it will not create a new route on standby.

3. The RTP monitoring moves to idle state, another flow change issued on active box:
a. On standby, since this flow change still did not have the remote IP change flag set, it will not create the route again. The route on standby will keep NULL in this case until SWO, the BRM RID enable failed when standby transitions to active.

Steps to Replicate: Establish a stable call on the M-SBC with RTP Monitoring Profile enabled on egress PSP.

Perform a M-SBC switch-over through the CLI.

The code is modified so the XRM detects the DPM change to receive only. This does not have any repercussions if the route is retained on the SBY, even after it transitions to active, it does not make a difference as flowMode will be rcv-only.
Moreover, there is code just below it, to de-cache and create a route again for the new address if remote address is updated as part of modify.

Workaround: Disable RTP Monitoring.

SBX-102029 | SBX-102836

1

Portfix SBX-102029  Issue with the Packet loss calculation on the NP

Impact: The packet loss count is not correct when packets are lost at the end of a call.

Root Cause: The packet loss algorithm did not account for the last 32 packets that are possibly lost.

Steps to Replicate: Send an RTP stream where there are jumps in the sequence number in the last 32 packets sent.

The code is modified to check if packets are lost in the last 32 packets.

Workaround: No workaround.

SBX-100088 | SBX-101333

1

Portfix SBX-100088 Switchover after TLS certificates are renewed

Impact: When a customer modified the certificates through CLI, it resulted in sam process core. This is due to memory corruption.

Root Cause: When certificate is modified, the SBC freed the old certificate and updated the new certificate.
By freeing the old certificate, the pointer is not set to NULL which can cause undefined behavior due to an invalid access.

Steps to Replicate: The steps are not reproducible.

The code is modified to set the pointer to NULL to avoid an invalid access of the pointer.

Workaround: None.

SBX-100063 | SBX-100162

1

Portfix SBX-100063 From header wrongly impacted by SMM

Impact: The SMM was adding duplicated generic parameters in header with tel scheme.

Root Cause: After the first rule, treat header as uri, the 2nd rule treat as generic, SMM format the 2nd rule actions with duplicated generic parameters.

Steps to Replicate: Run the first rule testing with uri parameter type. The second rule store the header value into local var and create a new header based on local var.

The code is modified on the second rule when trying to reconstruct the uri header into generic header that adding duplicated generic parameters.

Workaround: Avoid using uri parameter from the first rule. One may want to use regex instead.

SBX-97791 | SBX-101208

1

Portfix SBX-97791 The yc02 switchover with PrsP core.

Impact: The PRS process cored due to memory corruption.

Root Cause: The customer encountered a PRS process core due to an internal list in the XRM contained corrupt data. The corrupt data appears the be the result of an item being put on two different list at the same time.
There is an underlying root cause of the how the item ended up on 2 different list at the same time (since this may have happened long before the core).

Steps to Replicate: This is not reproducible. The basic regression load should be run.

The code is modified to prevent the PRS process from coring under these circumstances. This fix prevents an item from being put on a list if it already on another list.
Extra logging is also added so that if it does happen again, there is more information to find the underlying cause.

Workaround: There is no workaround.

SBX-100249 | SBX-100593

1

Portfix SBX-100249 - PRS Process core occurred on Standby Server

Impact: The PRS process cored due to the XRM accessing a NULL pointer inside of XRES data structure.

Root Cause: The root problem was that pkt2 on standby node was stuck in the DOWN state, due to possible network switch issue while the pkt2 on active node was functioning as normal. All activated XRESs selected on LIFs of pkt2 were mirrored to standby and got inserted in the deferredXresList waiting for standby pkt2 to be UP.
Then when one of those XRESs is reused for a different call and mirror to standby node, that XRES may still stuck in the deferredXresList because the deallocate request may have not been processed yet on the standby node. Then PRS hit coredump caused by XRM accessing the NULL pointer inside of XRES data structure.

Steps to Replicate: 1. The SBC HA pair, active node has pkt ports all UP, and standby node has at least one of the pkt port DOWN.
2. Start at a fairly high call load and to ensure calls are picking LIFs of pkt1 on active node in the example, and to make sure XRES on pkt1 are being re-used.
Note that the standby pkt1 should stay DOWN all the time during the test.

The code is modified to properly free the XRES in deferredXresList so that it is re-used for the new call.

Workaround: Manually keep the pkt ports sync between active and standby nodes.

SBX-103278 | SBX-103418

1

Portfix SBX-103278 Kandy - Double SBC Scm Coredump

Impact: The SBC may core for the antiTromboneData feature.

Root Cause: The SBC may access a NULL pointer in the antiTromboneData feature.

Steps to Replicate: Run A to call B, the B(sdp) loop back to the SBC (Bprime). The antiTromboneData is enabled for B and Bprime.

NOTE The Bprime also has a replacement header to replace a call that does not exist in the SBC, causing an SBC reply 481.

The code is modified to validate pointer before accessing the pointer.

Workaround: Disable the feature.

SBX-101050 | SBX-101352

1

Portfix SBX-101050 The SBC SWe was not generating a switchover for the trap-sonusCpRedundGroupSwitchOverNotification.

Impact: A switchover notification trap may not get generated.

Root Cause: The event used to generate the trap that is incorrectly dropped due to incorrect code that treats the event as stale.

Steps to Replicate: To reproduce the issue, perform a switchover and check if the trap is missing (This problem only occurs during slow processing).

The code is modified to improve event handling so that necessary events are processed and not mistakenly dropped.

Workaround: The problem only occurs during slow processing. Avoid anything that can slow processing down like info level logging, and any external influences on the disk.

SBX-99874 | SBX-100955

1

Portfix SBX-99874 A second Invite with a replace gets wrong PSX route

Impact: There was a second INVITE with REPLACES that receives the wrong PSX route.

Root Cause: There was a design gap in case of multilevel INVITE with REPLACES, which the SBC was sending a light weight PSX look up with incorrect source and destination trunk group. Due to this issue, the SBC is receiving incorrect TG configuration from PSX.

Steps to Replicate: 1. A and B are connected.
2. C sends INV with REPL to replace A.
3. D sends INV with REPL to replace C.
4. D sends Re-INV with a=inactive.

The code is modified so that the SBC sends a light weight PSX lookup with correct source and destination trunks to get the corresponding TG level configuration.

Workaround: No workaround.

SBX-101652 | SBX-102271

1

Portfix SBX-101652 The SIPFE lookup returned the RCB pointing to the wrong SCM post .

Impact: After an upgrade,the registrations mirroring on the SIPFE is corrupted. As a result, the incoming traffic for the AOR may route to the wrong SCM and rejected by SBC.

Root Cause: The packing redundancy data structure and the send to standby were incorrect due to a word alignment issue (using sizeof() to pack the data).

Steps to Replicate: Use multiple AOR registers from a different source. After an upgrade, a call for the register end point may route to the wrong SCM.

The code is modified to avoid using sizeof() to calculate the size of the data structure.

Workaround: No workaround.

SBX-101284 | SBX-102660

1

Portfix SBX-101284 The SBC Software Edition SWe was not sending media to the MS Teams client

Impact: When there are more than 10 MS teams endpoints that are potential media candidates for an outgoing ICE call to MS teams, in some cases the ICE learning may not complete resulting in media path not being enabled when the call is answered.

Root Cause: For each outgoing call, the SBC has an internal nominated candidates list of up to 10 entries for storing ICE information received in the stun requests from potential media candidates (that can be received before response with SDP). On receiving the SDP, stored entries are checked to see if ICE has been learned for the media stream in the SDP. However, if the SDP media is from the 11th or higher endpoint to have sent a stun (that would not have been stored) that can result in ICE learning not completing.

Steps to Replicate: 1. Initiate a PSTN to MS teams ICE call through the SBC.
2. Before 200 OK with SDP from MS Teams, send ICE stun requests using a candidate from 80 different endpoints.
3. Answer the call from the 80th endpoint that sent a stun (so 200 Ok from MS teams will have 80th endpoints media stream).
4. Verify that voice media flows successfully in both directions on the call.

The code is modified to allow for up to 80 endpoints as the potential media candidates.

Workaround: There is no workaround if more than 10 teams potential endpoints are necessary for a call, but it works fine for up to 10.

SBX-101294 | SBX-101694

1

Portfix SBX-101294 Intermittently, the SBC SWe uses access to the sipSigPort for sending SIP messages to the core side.

Impact: The Relay Options with registration may route to the wrong Sip Signaling Port and cause a call to fail from AS to IAD.

Root Cause: When the IAD send registration arrives from SSP1 and the Relay Options from another SSP2, since the options from SSP2 does not match with RCB from SSP1, the SBC treats the options from the AS and triggering invalid routing to the wrong destination.

Steps to Replicate: Configure the SSP1 and SSP2, maskRcbPort enable. Registration from the SSP1 success. The options from the SSP2 will trigger relay back to the IAD (not AS). The subsequent call from AS may fail or refresh registration.

The code is modified to detect relay messages from the IAD or AS based on what the RCB looks up (not just based on SSP).

Workaround: Disable the maskRCBPort or use the SMM to have the SBC respond to the Options (not relay)

SBX-102803 | SBX-103041

1

Portfix SBX-102803  The SIP-I calls cause a platform switchover when the Map Calling party to PAI is set.

Impact: The SBC may core while configuring the sipSigSrvcGrpURIPreference SIP on the egress when an incoming call cotains tel and pai (tel).

Root Cause: The SBC accesses an invalid diversion address.

Steps to Replicate: This is specific test case from a customer, and cannot be reproduced.

Validate the diversion address before accessing the egress.

Workaround: Disable the feature sipSigSrvcGrpURIPreference.

SBX-102072 | SBX-102938

1

Portfix SBX-102072 Malformed OTG after upgrade to 7.2.4R2 on GWGW calls

Impact: In a SIP-GW-GW-SIP call, if ingress SIP INVITE contains "tgrp" in the Contact Header, the contents of the "otg" parameter in the egress SIP INVITE will be incorrect.

Root Cause: An incorrect pointer value was being used when creating the OTG parameter.

Steps to Replicate:

1. In the "Egress IP Signaling Profile", set "Include OTG" in Originating TrunkGroup Options field.
2. Send a SIP-GW-GW-SIP call with a Contact Header that includes a "tgrp" parameter.
3. Look at the contents of the "otg" parameter in the "From" header in the egress INVITE. The information should be incorrect.
4. Load up the code with the fix.
5. Run the same call (with the same "Include OTG" configuration.

The "otg" in egress INVITE should be the originating TG on the originating GW.

The code is modified to use the correct pointer when creating the OTG parameter.

Workaround: Do not send the "tgrp" parameter in the ingress INVITE.

SBX-100779 | SBX-101120

1

Portfix SBX-100779 The SBC20-SPO adding extra application/ISUP ACM content

Impact: The 200OK Bye has duplicated the isup body.

Root Cause: When e2e bye was enables, the 200OK duplicated the isup body.

Steps to Replicate:

1. Configure the isupMineBodyRelay and e2e bye.
2. Run a sipi-sipi call.
3. The SBC sends a 200OK bye that has a duplicated isup body.

The code is modified so when accessing the e2e bye and isupMineBodyRelay, the SBC does not create an isup body internally.

Workaround: Disable the e2e bye.

SBX-102236 | SBX-102998

1

Portfix SBX-102236 The SBC CLI responds significantly slower while entering the ping command when one or more options are specified.

Impact: Attempting to run the SBC CLI commands ping, ping6, traceroute, traceroute6 or aaarule-display-generatecli with multiple parameters causes the CLI session to freeze.

Root Cause: Parsing of parameters on these CLI commands is not working correctly.

Steps to Replicate: Try to run the following command from CLI:
ping -I mgt0 -c 5 1.2.3.4

The code is modified to correct the parameter parsing.

Workaround: Use Linux equivalents to the commands, rather than using the SBC CLI or, if using the SBC CLI, limit the number of parameters, e.g. ping 1.2.3.4.

SBX-96001

1

SBC 7000 has wrong value for call duration

Impact: The call service duration (CDR field numbers 10 and 14) has the wrong values causing billing issue.

Root Cause: This issue is seen when there is mid call message in this case session refresh. Due to this session refresh, there are mid call messages(INV/200OK/ACK) happens end to end. This makes the "callServiceEstTime" in the function CcRelayInfoMsg() overwritten every time causing the CDR fields 10 and 14 wrong values.

Steps to Replicate:

1. Enable IPSP flag "End to End ACK" on both TGs.
2. Disable the flag "No CDR Change in End to End Ack" .
3. Make a call from A to B and let the call be connected with session refresh enabled.
4. Once the session refresh happens, disconnect the call and check the CDR.

The code is modified in the function CcRelayInfoMsg() so that the "callServiceEstTime" does not get overwritten once it is recorded initially during the initial offer-answer.

Workaround: 1. Enable the flag "No CDR Change in End to End Ack".

SBX-90251

1

SM process healthcheck timeout during config restore on Cloud SBC

Impact: The SM process crashes due to a healthcheck failure.

Root Cause: As part of load configuration, the config tar file needs to be untared. This 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 loadConfig must have completed successfully.

Overriding the healthcheck for running tar command so healthcheck does not fail during loadConfig fixes the issue.

Workaround: Override the healthcheck for tar command.

SBX-95983

1

The SBC is  a seeing STEAL_WARNING:

Impact: Receiving a Steal Warning at login.

Root Cause: Filtering the criteria for high steal value was not well defined, causing the issue.

Steps to Replicate: The script runs as a cron job. This can also be manually tested by making changes in the mpstat logs.

The code is modified to detect and warn about threshold values that exceed 5%.

• If the number of high values from individual CPUs are greater than 5% of the total number of samples in last 60 mins, then generate log event warning.

• If the above condition is false:

• Then if the average value (CPU all) is high in last 60 min logs.

• Generate log event warning.

Workaround: None.

SBX-101922

1

GUI CDR Configuration screen - Syslog server field can not be configured

Impact: The server section has been 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.

Restrict child object in this particular case to address the issue.

Workaround: None.

SBX-99472

1

P-Asserted-Identity is not sent out in the OPTIONS

Impact: When the SBC is configured as PCSCF, when receiving the OOD OPTIONS (with SDP) from IMS core towards Registered UE, the SBC was supposed to send the P-Asserted-Identity to send transparently, but was not sending.

Root Cause: This particular scenario, the internal variable is not being updated.
Update the aulOtherLegHdrMask, since the option was only received from core side, but was setting privacy related headers for transparency only in the aulHeaderMask and not in aulOtherLegHdrMsk.

Steps to Replicate: Verify the behavior of PCSCF, upon receiving p-Asserted-Identity in OOD OPTIONS(with SDP) from IMS CORE towards Registered UE and UE is sent transparenty.

UAC[UE-1 and UE-2] <> SBC[PCSCF] <> I-CSCF/S-CSCF[UAS - IMS CORE]
Assumption: [UAS] I-CSCF/S-CSCF will be simulated using SIPp or other simulators.
Purpose: To Ensure whether PCSCF is transparently passing the SDP body in OOD OPTIONS method received from IMS CORE and the corresponding 200 OK responses from UE (UE terminating scenario).
Pre-Condition:
1. Configure the SBC5x00 for SIP to SIP Call(IP-V4 to IP-V4).
2. Enable all the P-CSCF related flags. (Eg: Path,Service-Route,PCV,PCFA,PVNI,PANI,MMTEL related flags).

Procedure:
1. Register the user-A \'user1@nnnnn.com\' from IP-1(V4).
a) Register msg shall contain Require, Proxy-Require & Authorization header with the Private user identity \'TestUser@<domain>.com\'
b) From and To headers contain the AOR as \'user1@<nnnnn>.com\'

2. Send 200 OK response from IMS CORE.
a) The 200 OK response will contain P-Associated-URI header with set of Public user identities(Implicit Registration set).
eg: P-Associated-URI: <sip:user1@<nnnnn>.com> <sip:user2@<nnnnn>.com> <sip:user3@<nnnnn>.com>

3. Send OOD OPTIONS message with SDP body from IMS CORE towards Registered UE.
a) Accept header contains message body type as \'application/sdp\'
b) Request-URI and To headers points to the user-A SIP URI information.
c) From header contain the Originating user\'s SIP URI information(User-B).
d) SDP body with the capabilities of User-B.
e) Route header contains reg-info parameter.

4. Send 200 OK response with SDP body from UE for the OPTIONS.
a) The Accept header contains message body type as \'application/sdp\'
b) The SDP body with the capabilities of User-B.|

Expected Results
After step 1 and 2:
a) Registration should be successful.
b) PSCF will store all the 3 AOR\'s received in the P-A-URI header in the Active Registration table.

After step 3,
a) PCSCF will accept the OOD OPTIONS and forwards the same towards Registered UE alson p-Asserted-Identity transparently.
b) PCSCF will transparently pass the SDP body from IMS CORE towards UE.
After step 4,
a) PCSCF will accept the 200 OK response and forwards the same towards IMS CORE.
b) PCSCF will transparently pass the SDP body in 200 OK from UE towards IMS CORE.

The code is modified to take care of sending the P-Asserted-Identity transparently.

Workaround: None.

SBX-102110

1

SBC unable to resolve IPv6 EMS IP from FQDN

Impact: The SBC was unable to resolve the IPv6 EMS IP from FQDN.

Root Cause: The serviceDiscoveryInterface wrongly parses the IPv6.

Steps to Replicate: Created an SBC using IPv6 EMS address.

The code is modified for parsing the IPv6.

Workaround: None.

SBX-101741

1

AWS:SBC is not coming up after installing voip monitor and rebooting

Impact: The SBC is not coming up after installing the voip monitor and rebooting .

Root Cause: The root cause was an impact of public cloud stream merge (9.0).

Steps to Replicate: Enable the Voip Monitoring and bring up the instance.

The code is modified to address the issue.

Workaround: None.

SBX-102908

1

SamProcess coredump seen while executing OCSP stapling feature

Impact: The SAM Process cores randomly when running a TLS call with the OCSP Stapling enabled.

Root Cause: Sometimes, the SIPCM finds socketPtr to be NULL that is causing an invalid access of a NULL pointer.

Steps to Replicate: Running TLS call with OCSP Stapling enabled.

The code is modified to check a NULL for the socketPtr.

Workaround: When the OCSP Stapling is disabled, the SAM process does not core.

SBX-94491

1

Switchover triggered by reboot takes 7 secs to detect by standby becomes active on 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: There was an issue a reboot from both the command prompt and the CLI.

The code is modified to alert the peer to take over rather than relying on the transport protocol health check to timeout.

Workaround: None.

SBX-101628

1

MRFP: CPX process leaks memory for call load

Impact: There are memory leaks in the MsgClient message queue.

Root Cause: The DispatcherAgent's MsgClient not instantiated properly, causing messages to be queued and never deleted.

Steps to Replicate: Can replicate in lab environment only.

The code is modified to instantiate DispatcherAgent's MsgClient properly and to not use the message queue. Clear message queue in the destructor of MsgClient.

Workaround: None.

SBX-101407

1

MRFP: CpxApp process is dumping the core on the managed node when we grep NTP from OAM node

Impact: The CPX process cores on an application shutdown.

Root Cause: There was an improper ConfdProxy object destruction.

Steps to Replicate: Stop application while traffic load is running is best to reproduce.

The code is modified to properly delete the ConfdProxy object.

Workaround: None.

SBX-102737

1

MRFP: SmProcess coredump on both active and standby after an sbxrestart

Impact: There was a SM process coredump at the startup due to a healthcheck.

Root Cause: The System_i::fillSavedConfigurations is trying to read /mnt/gfsvol1/config-versions.txt, but it is taking too long and causing a coredump.

Steps to Replicate: 1. Setup a 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.

SBX-101394

1

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 .

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) UE1 sends an Invite to the SBC.

2) The SBC sends an Invite to UAS-1.

3) UAS-1 sends a 3xx with the Identity header embedded in the contact header.

4) The SBC sends an ACK.

Honnor 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.

SBX-102494

1

Service Discovery: SBC should go through complete lca process when EMS IP is updated

Impact: The SBC is not sending an instanceup to the EMS after re-registering to an EMS following an EMS IP change in the service registry.

Root Cause: The SBC LCA is not performing the complete registration sequence when starting from a change of EMS IP detected by the service discovery.

Steps to Replicate: 1. Bring up EMS and create a SBC cluster.
2. Instantiate the SBC.
3. Do not pass EMS_1 and EMS_2 details.
4. provide restusername/restpassword for EMS registration.
5. Provide ems_fqdn as FQDN.
6. Provide sd_registry with valid DNS server details.
7. Check the SBC's that are registered with EMS.
8. Delete EMS created in Step 1.
9. Bring up new EMS with existing cinder and new EMS IP.
10. Rediscover the Insight node once EMS is up and running.
11. Update the DNS entry with new EMS details.
12. Check that the SBC is sending registration and instance up notification to new EMS IP.

On the EMS IP, a change is detected by the service discovery and perform the complete registration sequence, not just the register message to address the issue.

Workaround: None

SBX-101728

1

Resolve the EMS IP by Service Name(FQDN) is not working

Impact: Resolve the EMS IP by Service Name(FQDN) is not working.

Root Cause: The sd_registry information gets mangled by Python, resulting in an invalid json.

Steps to Replicate: 1. Create SBC Cluster in EMS.
2. Configure the DNS with the EMS IP.
3. Check DNS is able to resolve the IP.
4. Bring up 1:1 OAM SBC by passing ems_fqdn and sd_registry.
5. Check if the SBC is able to resolve the EMS IP from FQDN and the SBC registered with EMS.

Attempt to dump/load SDR backend information to accept format that is not valid JSON but contains a valid configuration to address the issue.

Workaround: Properly format the SBC userdata "sd_registry".

SBX-101765

1

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 and it resulted in memory being overwritten.

Steps to Replicate: Can replicate in lab environment only.

The code is modified to use large local variables to avoid the memory overwrite.

Workaround: None.

SBX-100237

1

MRFP: CpxApp process is dumping the core on the managed node when callMediaStatus CLI is run from OAM node.

Impact: There was a CpxAppProc core when accessing the callMediaStatus of managed VMs from OAM through the node branch.

Root Cause: There was a data serialization bug that caused the issue.

Steps to Replicate: Access the callMediaStatus of managed VM from OAM through node branch.

The code is modified to address the core issue.

Workaround: None.

SBX-103492

1

Performance: Observed "Scm" Process core on standby box while running verifying TOOLS-71636 JIRA 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.

SBX-88654

1

PKT interfaces not pinging in 7.2.0 S400 build when NP is stubbed its reachable

Impact: PKT interfaces are not pinging in VMWare setup with 7.2.0S400 build.

Root Cause: The root cause of this issue was -
For vmxnet3, we started using multiple rx queues which was not intentional, but got enabled as part of multi q support for virt-io. As a result, SWe_NP was not receiving any packets from pkt0 interfaces and ping was failing.

Steps to Replicate:

1. Use the mentioned build and create an instance in VMWare with vmxnet3 pkt interface.
2. Apply basic configuration and after that try to ping pkt interface from outside.
3. Ping should not work.

The fix was done to use/enable single Rx queue for vmxnet3 interface.

Workaround: No workaround for this.
We need to use the build after the fix.( mentioned in "Fixed in Build")

SBX-102472

1

ImPr Process core dumped for Default LI with IPSEC

Impact: When a call is intercepted during switchover, SBC throws SYS error SE_SYS_HASH_EXISTS and causes coredump.

Root Cause: If a call is intercepted during switchover, 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: The SBC is configured for Default LI.
Run a load of 5 cps of intercepted calls and trigger switchover on the primary SBC.
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.

SBX-101028

1

Ike Process core dump after running IMSLI IPSEC call

Impact: The Ike Process core dumps after running a IMSLI IPSEC call.

Root Cause: This issue is a side effect of the SBX-100461 JIRA changes. The NULL check was missing before accessing the pointer.

Steps to Replicate: Procedure:

1. Setup was brought up in V09.01.00-A002 build.
2. Configure for a basic IMS LI IPSEC call with Egress side interception.
3. The call was successful and the interception towards IPSEC server was encrypted as expected.
4. After the call, an Ike Process core dump was observed and the application went down.

The code is modified so a proper NULL check is added before accessing pointer's.

Workaround: None.

SBX-101784

1

[GW-GW] Observed SamProcess coredump in SBC2 while running, 10 Identity header with 1024 bytes received in ingress invite for STIR/SHAKEN

Impact: Without this fix, when the receiver gateway receives a gateway pdu larger than 14352 bytes, it dumps the core.

Root Cause: When the receiver gateway receives a gateway pdu larger than 14352 bytes, the receiver buffer in application is overwritten causing a memory corruption, which results in a core dump.

Steps to Replicate: Use the 9.1 GW to respond to older gateways and run the call flow that involves 10 Identity headers.

The code is modified to negotiate the acceptable buffer length when the GW-GW connection is established. The sender GW does a validation check for whether the receiver gateway can process the buffer or not based on the negotiated buffer lengths and sends the GW message only if the peer can handle that buffer.

Workaround: None.

SBX-75563 | SBX-99932

2

PortFix SBX-75563 Port number in the DBG log.

Impact: For non-UDP calls, the peer IPs of all status messages sent from the SBC to UAC in TRACE log will be displayed as Via header's IP.
The message themselves are sent to the right IP, which sent the request message to SBC.

Root Cause: The original code would overwrite the SipMsg's peerIp with Via header. That PeerIp will be used to print in trace log.

Steps to Replicate:

1. Set up TCP calls, and TLS calls.

2. Make VIA header's IP different from UAC IP.
3. Make the call, collect the TRC log. DBG log could be also collected as debug tool.
4. Make sure that all out going msg are sent to right IP:Port in displayed in TRC log.

The code is modified so the SipMsg's peerIp is set to source IP.

Workaround: No workaround needed. This is a display problem. It does not affect the SBC functionality.

SBX-100989 | SBX-103008

2

PortFix SBX-100989 The SCM process coredumped.

Impact: The SCM processs may coredump during gateway-to-gateway calls using SDP transparency.

Root Cause: The software packed and unpacked unsupported content header types causing NULL pointer access.

Steps to Replicate:
1. Configure the SBC for gateway to gateway calls using external PSX.
2. Configure transparencyProfile on both ingress and egress trunk groups enabling sipMessageBody all.
3. Configure direct media and SDP transparency on both ingress and egress trunk groups.
4. Preform SIP gateway to gateway call flow: INVITE, 183 w/sdp, PRACK, 200 (prack), 180 w/sdp, PRACK, 200 (prack), 200 w/sdp, ACK, BYE, 200.

The code is modified to prevent unsupported content header types from being packed and unpacked.

Workaround: Disable the signaling SDP Transparency 'sdpTransparencyState' flag.

SBX-92584 | SBX-100979

2

PortFix SBX-92584 The flag 'statusUpdateSupport' is not working.

Impact: The SBC includes "Accept" and "Allow" headers while generating an OPTIONS ping request towards the peer, even when the statusUpdateSupport flag is disabled.

Root Cause: The code was not setting the flag correctly and passed the "Accept" and "Allow" headers irrespective of the statusUpdateSupport flag.

Steps to Replicate: To replicate/verify the issue, configure the path check profile and set the stausUpdateSupport flag disabled. The SBC does not send the "Accept" and "Allow" header in the OPTIONS ping towards the peer.

The code is modified to handle the statusUpdateSupport flag correctly.

Workaround: Operators can use SMM rule to remove the Allow and Accept headers from the OPTIONS ping.

SBX-98317 | SBX-101303

2

Portfix SBX-98317 The call load, along with switchovers and provisioning, coredumps.

Impact: The Ipsec data is stored for all signaling ports. The Ipsec state array size was different from signaling Ports array. As a result, overwriting the Ipsec state array was the primary solution.

Root Cause: Overwriting the array beyond its size led to memory corruption.

Steps to Replicate: While configuring the SBC, add sigPort with index 4096 .

1. Load testing at 500 cps for 15 hrs
2. Run Switchover testing.
3. Run Physical port redundancy testing during load.
4. Run Customer configuration testing during load.

A crash should not happen.

The code is modified to increase the ipsec state size of array so that it can hold same number of entries as signaling ports array.

Workaround: While adding the sigPorts, do not add sigPort index 4096.

SBX-102069 | SBX-102639

2

PortFix SBX-102069 SCM process memory leak.

Impact: The standby SBC is leaking a per call structure that is used for Relay calls.
This leak can carry over to active when there is a switchover.

Root Cause: The leak is happening because the code is overwriting the pointer to the structure - thereby preventing this structure from being freed when the call is completed.

Steps to Replicate: Root cause was found by code inspection - exact call flow that would trigger this leak is unknown.

The code is modified to free the structure before the field that stores a pointer to it is overwrritten.

Workaround: No workaround.

SBX-100984 | SBX-101772

2

PortFix SBX-100984 The Teams zone detection should be case insensitive.

Impact: MS Teams zone detection logic might not work to provide native support for functionality.

Root Cause: In the 8.2 release the SBC was updated to provide native support for MS Teams functionality previously implemented using SMM. This is done by reading the FQDN from the pathchk logic in the zone. It was assumed that the FQDN would be in lower case but some operators have configured in upper case and the code is not matching this format. This results in the native functionality not being provided.

Steps to Replicate: Configure all the FQDNs in the patchcheck configuration in upper case.

The code is modified to perform non-case-sensitive checking for the pstnhub.microsoft.com FQDN.

Workaround: Change the sip.pstnhub.microsoft.com FQDN in the pathchk configuration to use lower case instead of uppercase or leave SMM in place from older releases.

SBX-103265 | SBX-103289

2

PortFix SBX-103265 Error during a switchover.

Impact: When emergency call is terminated with delay and incoming TG is marked out of service, SCM Process may core.

Root Cause: When emergency call is terminated with delay and incoming TG is marked out of service triggers null pointer exception

Steps to Replicate: Run emergency call and make sure SBC does not core.

The code is modified to ensure SIP service group pointer is checked before de-referencing.

Workaround: No workaround.

SBX-101401 | SBX-101679

2

PortFix SBX-101401 Call disconnected when 10 PSX routes returned.

Impact: Run a Invite Call Flow with the customer config where PSX returns 10 Routes in the call, SBX is disconnecting the call

Root Cause: IcmParamInsert is failing for one of the paramtype in NrmaCcSelectEgressSgCmd as the size is exceeding max size ( ICM_REQUEST_MAX_12)

Steps to Replicate: Run a call flow with the customer config where the PSX returns 10 Routes per call.

Maximum size has been increased to ICM_REQUEST_MAX_14.

Workaround: No workaround.

SBX-99361 | SBX-99825

2

PortFix SBX-99361 Memory leak in the SBC.

Impact: Bug in the “clearTcpConnectionsforRegistration" functionality that causes a memory leak.

Root Cause: Code that handles the clearTcpConnectionsforRegistration flag is allocating memory to store Hostname and Username, but it never freeing this memory.

Steps to Replicate: Set up customer configuration with the “clearTcpConnectionsforRegistration” flag set. Reproduce the issue by running load with Registrations and de-Registrations.

The code is modified to free the memory that is allocated to store Hostname and Username.

Workaround: The workaround is to set clearTcpConnectionsforRegistration to Disabled on the TG.

SBX-101818 | SBX-102486

2

PortFix SBX-101818 SBC memory leak.

Impact: When inbound calls to the SBC are released early, the SCM process leaks memory.

Root Cause: When inbound calls are released early, the ScmProcess does not release memory allocated to store SIP PDU.

Steps to Replicate: To reproduce the issue:
1. Change the mode of ingress TG to 'out of service'.
2. Send a high number of calls (10000 +) to ithe ingress TG with 1 cps.
    All calls will get rejected.
3. Check memory of ScmP.
    A memory leak occurs.

The code is modified to ensure the SCM Process releases memory after an early attempt call fails.

Workaround: None.

SBX-101154 | SBX-101332

2

PortFix SBX-101154 The transcode percentage required to load DSPs in sweTrafficProfile is incorrect.

Impact: On the specified 100% tonesPercent in custom profile without selecting any transcode percentage in SWe Traffic profile, the tpads are not loaded and dspStatus does not show any tones resource available.

Root Cause: This is due to incorrect check that considers only the transcode percentage to allocate dsp resource in a custom profile activation script(partition_util.py).

Steps to Replicate:

1. Create a custom profile.
2. Allocate tone percent as 100.
3. Load the profile.
4. Check for show status system dspStatus.
This shows no toneAvailaible.

The code is modified to consider that transcode as well as tones percentage in the SWe traffic profile for allocating the dsp resources in custom profile activation script(partition_util.py).

Workaround: Allocate some transcodePercent in the custom profile.

SBX-98844 | SBX-101268

2

Portfix SBX-98844 The SDP attribute a=X-nat duplicated for selective sdp relay.

Impact: Due to a change in 8.2, the b line's length was not considered properly, so the "a=X-nat" was added twice.

Root Cause: Due to a change in 8.2, the b line's length was not considered properly, so the "a=X-nat" was added twice. As a result, "a=X-nat" line was added twice, once as part of b line and once as an a line.

Steps to Replicate: Send an INVITE with b line and a line in the SDP as shown below.

v=0
o=UAC 203537 229017 IN IP4 10.220.182.193
s=SIP Media Capabilities
c=IN IP4 10.220.182.191
b=AS:84
t=0 0
a=X-nat:0
m=audio 1086 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=sendrecv

The "a=X-nat " line should not be added twice on egress side.

The code is modified to copy the exact b line bytes as part of adding a b line on the egress. The "a=X-nat" line is added only once as expected.

Workaround: None.

SBX-102617 | SBX-102650

2

PortFix SBX-102617 SIPFE crash, corruption on the msgObject, and possibly double freeing of memory.

Impact: Using SNMP to query ipPeer statistics may core if an invalid zone or ipPeer name is entered.

Root Cause: When SNMP walk for invalid zone/ippeer, the SBC may double free memory (introduced by SBX-51006).

Steps to Replicate: Using snmptool to walk thru the data:
snmpwalk -c admin -t 20 -v 2c -m all sbxsus5-1 1.3.6.1.4.1.2879.2.10.2.243.1.2.14.65.68.68.82.95.67.79.78.84.
   69.88.84.95.49.5.90.79.78.69.50.4.84.78.84.49

The code is modified to avoid double free memory.

Workaround: Enter the valid zone/ippeer when querying.

SBX-103039 | SBX-103112

2

PortFix SBX-103039 The SIPFE SG allocation calls land always on the SCM0 until it is exhausted.

Impact: Call from AS without registration may always lands on SCM0.

Root Cause: The SBC accidentally selected prefer SCM0 when no registration found.

Steps to Replicate: Configure the zone xxx remoteDeviceType appServer, incoming call to zone xxx and w/o registration. Call will route to SCM0 until system exhausted.

The code is modified so if there no registration, the SBC equally selects the SCMs.

Workaround: No workaround.

SBX-102974 | SBX-103045

2

Portfix SBX-102974 The SBC does not transfer contents of /var/log/syslog to a remote server whenever the log file is rotated.

Impact: syslogLog, sftpLog, consoleLog, ntpLog and platformAuditLog fail to send logs via syslog, when file sizes are decreased (for example when logs are rotated).

Root Cause: If a file size decreases but inode stays the same, then rsyslog does not (by default) know that the there is new logs being written to the files, therefore will not send these new logs.

Steps to Replicate:

1. Setup logging to remote server for log type
2. Run logrotate: logrotate -f
3. Verify if new logs are written to the remote server

The code is modified so it reopens a file if it detects the the file was truncated

Workaround: Edit /etc/rsyslog.conf and add reopenOnTruncate="on" to all input() rules.

INS-39555 | SBX-102372

2

PortFix SBX-102299 The EMS SBC Manager import of SMM remains "In Progress" even if it is completed.

Impact: The EMS SBC Manager import of the SMM remains "In Progress" even if it is completed.

Root Cause: When performing a "start import" operation from the Configuration script and template import screen that stay on the same screen, the SBC Manager makes a getStatus API call that reads the status(using platform manager getStatus API) and updates into a map object.

If the operator switches  to another screen (except for the Configuration and profile import/export screen), the issue is not seen. If the operator swicthes to the Configuration and profile import/export screen, that makes the platform manager getStatus API call, which does not update the a map object. After completion of start import, the operator can read the status from the map and display to the UI.

Steps to Replicate:

1. Login to EMA.
2. Navigate to Administration -> System Administration -> File Upload.
3. Upload a CLI file.
4. Navigate to Administration -> System Administration -> Configuration script and template Import screen.
5. Select the uploaded cli file and click on start import.
6. Navigate to Configuration and Profile Import/Export screen .
7. Stay here until complete that start import.
8. Navigate to Administration -> System Administration -> Configuration script and template Import screen.
9. If the CLI executes successful or failed, the correct status should be shown.

The code is modified to make difference in the EMA call or PM call.

Workaround: No workaround.

SBX-100373 | SBX-101204

2

PortFix SBX-100373 The Standby SBC memory at 94% has SCM process memory leaking.

Impact: The SCM process on standby is running out of memory when the path headers are included in Registration messages.

Root Cause: The SCM process on standby is running out of memory when the path headers are included in Registration messages.

Steps to Replicate: Run a Registration load that includes path headers in egress Registration messages.

The code is modified to free the structure that had been leaking.

Workaround: There is no workaround for this issue.

SBX-98646 | SBX-101777

2

PortFix SBX-98646 The AddressSanitizer detected a heap-buffer-overflow on address 0x607000326fe4 at pc 0x563429a99aac bp 0x7f371d414210 sp 0x7f371d4139c0.

Impact: When the END to END ACK control is enabled and making calls between the SBC and GSX, the GSX sends a bad parameter to the SBC and it causes the SBC to read invalid memory and occasionally coredump.

Root Cause: GSX using the wrong enumeration range for an internal CPC parameter type. The associated parameter it creates does not contain any data. This causes the SBC to assume a completely different parameter that is expected to contain mandatory parameter data. The SBC reads the data, which results in it reading off the end of the message block.

This has been broken since original implementation and generally does not cause issues. But if the message memory block happens to be at the edge of the valid memory range then it can result in an invalid memory read, which triggers a coredump.

Steps to Replicate: This issue is highlighted when using ASAN enabled images in the engineering lab, but it has been known to cause occassional coredumps in production.

The code is modified to ignore the bad parameter information coming from the GSX to avoid reading invalid memory. The GSX code is being updated under GSX-61505 to stop sending bad parameter information.

Workaround: Disable the END to END ACK control if possible.

SBX-102130 | SBX-103230

2

PortFix SBX-102130 The public alt IPs are not used for SDP negotiation if they are part of the initial SBC configuration.

Impact: The Public IP address associated with the Alternate IP address is not configured when the altIpVars and ipPublicVar are added to an existing ipInterface in the Cloud SBC.

Root Cause: The ipPublicVar is not processed when an altIpVars and ipPublicVar parameter are set to an existing ipInterface.

Steps to Replicate:

1. Configure ipInterface in a Cloud SBC, and enable it.
2. Add altIpVars and ipPublicVar to the ipInterface.
3. Run SIP calls and notice the public IP address (ipPublicVar), not private IP address (altIpVars), is used in the media packets.

Read and handle the ipPublicVar, if configured, when an altIpVars and ipPublicVar parameter are set to an existing ipInterface to address the issue.

Workaround: Configure the altIpVars and ipPublicVar for the ipInterface before enabling the ipInterface.

SBX-102495 | SBX-102893

2

PortFix SBX-102495 The Authentication processing is not performed when calling for OTT.

Impact: New calls from the child subscriber numbers of a particular AOR would fail after deletion of one or more subscriber numbers from the same AOR.

Root Cause: The ConfD version was upgraded from 6.4 to 6.7 in 7.2.0R0.
In the ConfD version 6.4, addition or deletion of elements from the subscriberNumbers list was being notified to the SBC application as MOP_VALUE_SET and the SBC was invoking the function to handle modification to the list. Deleting the entire list was being notified as MOP_DELETED and the SBC invoked the function to handle deletion of the entire list.

In the Confd v6.5 and above, adding elements to subscriberNumbers list gets notified as MOP_CREATED and deleting elements gets notified to the SBC application as MOP_DELETED. So post upgrade to 7.2.1R9, when the user deleted a few elements from the list, the SBC got notified with MOP_DELETED and it invoked the function to handle deletion of entire list (as it used to do earlier).

Steps to Replicate:

1. Create a surrogate registration profile with AOR and child subscriber numbers.
2. Validate that call from a child subscriber number is working upon successful registration of the AOR.
3. Delete a subscriber number from the AOR.
4. Validate that call from the deleted subscriber number is not authenticated upon receiving challenge from the proxy.
5. Validate that calls from remaining subscriber numbers are validated/authenticated by the SBC upon receiving challenge response from proxy.

The code is modified to handle MOP_CREATED and MOP_DELETED notifications from the ConfD to handle cases of creation,modification and deletion to the subscriberNumbers list.

Workaround:

1. Delete the entire subscriberNumbers list
delete profiles services surrogateRegistrationProfile <profName> aorUserName <aorName> subscriberNumbers
commit
2. Add back the subscriber numbers needed
set profiles services surrogateRegistrationProfile <profName> aorUserName <aorName> subscriberNumbers <num1> <num2> <num3>
commit.

SBX-101431 | SBX-101484

2

Portfix SBX-101431 The PKT1 gateway meta-var and ip is missing in metavariable table.

Impact: The GWv4 metavariables are sometimes not created for all interfaces in the AWS.

Root Cause: The DHCP request is slow in the public cloud, and occasionally the default route fails to create, so we cannot read the gateway to create the metavariable.

Steps to Replicate: Verify all GWv4 metavariables are populated in the AWS.

The code is modified to work out the correct gateway IP from the subnet CIDR. In AWS, the second IP address in a subnet CIDR is always reserved to be subnet gateway.

Workaround: None.

SBX-101749 | SBX-102101

2

PortFix SBX-101749 The SBC will not transparently pass a complete contact header when there is no isfocus parameter.

Impact: The SBC will not transparently pass the complete contact header when there is no isfocus parameter.

Root Cause: The SBC was transparently passing complete contact header, when there is no isfocus parameter and contactTransparencyForIsFocusMediaTag enabled on both TGs.

Steps to Replicate:
1. Configure the SBC for A to B call.
2. Enable the flag contactTransparencyForIsFocusMediaTag on both TGs.
3. Make a SUBSCRIBE-NOTIFY call flow.
4. In the Notify Message isFocus param should be present and in the 200ok of Notify it should not be present.

When the contactTransparencyForIsFocusMediaTag is enabled and when isfocus parameter is not present in 200ok of Notify, the SBC does not transparently pass a complete contact header.

Workaround: None.

SBX-101209 | SBX-101646

2

PortFix SBX-101209 NVIDIA V100 Based GPU instance fails to come up in the VMWARE.

Impact: Nvidia V100 GPU Accelerated instance does not come up on VMware host.

Root Cause: Due to large PCI memory requirements for V100 card, the V100 based VMware instance does not come up in legacy BIOS mode.

Steps to Replicate: Bring up SBC VM with EFI BIOS instead of legacy BIOS.

V100 based VMware instance needs to be booted in EFI mode. Necessary software changes are made to bring in EFI boot support.

Workaround: There is no workaround for this issue. V100 based VMware instance needs to be booted in EFI mode.

SBX-100916 | SBX-101106

2

PortFix SBX-100916 Invalid read with the STI diversion/history-info headers.

Impact: When STIR/SHAKEN functionality is enabled and historyInfo or diversion headers are received the SBC code is reading off the end of a memory buffer..

Root Cause: When the SIP code was building the internal structure to send to the PSX it was using multiple internal buffers but maintaining the parameter size equal to the total memory size required. When the internal parameter was later moved the logic was reading off the end of the buffer as it did not account for the multiple buffer logic. In normal process there is no impact, but in the edge case where the primary memory block is on the edge of the heap then it could result in accessing invalid memory and a coredump.

Steps to Replicate: This issue is only reproduced when running with ASAN images in the engineering lab.

The code has been modified to use a single internal buffer so that the size value and buffer are consistently managed to avoid reading off the end and accessing invalid memory location..

Workaround: None

SBX-100286 | SBX-103023

2

PortFix SBX-100286 The trace file containing SIP Rec PDU is not imported in Ribbon Protect properly.

Impact: When a level 4 call trace is active, if a SIP PDU is too large to fit on a single trace line, it is split over multiple lines. However, Ribbon Protect only reads the first line. There is no way for it to know subsequent lines are continuation lines.

Root Cause: Design issue.

Steps to Replicate:

1. Enable level 4 call trace.
2. Send a SIP PDU to be traced towards the SBC of total size 2000 bytes.

The code is modified to put the same header onto each level 4 trace line. Include two new fields into the header, MSG ID and PART to allow Ribbon Protect to recombine multiple trace lines to recover the original message. The equivalent Jira VIGIL-17137 is required for Ribbon Protect compatibility.

Workaround: None.

SBX-93790 | SBX-103070

2

PortFix SBX-93790 For calls initiated by a PSTN user, the Teams user is unable to resume a call when the transfer is failed.

Impact: During a Refer, if transfer target sends early answer in 18x, but then rejects the call, SBC fails to resumes the previously active call

Root Cause: During call transfer, after tone play, while processing early answer in 183, the SBC wrongly freed the previous cut-thru context and instead retains the previously activated tone context (for A-B call).
As a result, after transfer target rejects the call, the SBC attempts to resumes the previously active call (A-B) which fails due to unavailability of correct context.

Steps to Replicate:

1) Execute the following call flow:
PSTN1 to TEAMS call
TEAMS transfer call to PSTN2
PSTN2 rejects the call
TEAMS resume the call

2) Execute the following call flow:
PSTN1 To TEAMS call
TEAMS transfer call to PSTN2
PSTN2 does not answer the call
TEAMS resume the call

The code is modified to retain the previously activated cut-through context and free the previously-activated tone context if the current tone context is more recent.

Workaround: None

SBX-101474 | SBX-101804

2

PortFix SBX-101474 Potential memory leak of ICM message in SG FSM when switching to secondary the NIF for an MS Teams call.

Impact: Possible small memory leak in an MS teams media optimization configuration for each PSTN to Teams call that uses the secondary (public) media interface to teams endpoint. Over a large number of such calls (estimate 10,000 +) this could result in enough memory loss to cause new calls to fail to establish.

Root Cause: When an ICE call to MS teams switches to the secondary media interface, the existing egress ICE context for the primary interface is replaced by a new one for the secondary interface. This context switching involves inter task messaging on the SBC, there was a potential path in the code where one of these messages was not releasing its used memory correctly.

Steps to Replicate: Establish and release a large number (10,000 +) of PSTN to MS teams calls that use the secondary (public) media interface to teams endpoints.

The code is modified to remove the inter task message that could have lead to the issue.

Workaround: No workaround.

SBX-100799 | SBX-101320

2

PortFix SBX-100799 The SYS is filling up with "mcsEncodeCPC_MSG_INFO_STR: CPC_OP_STR parameter length mismatch".

Impact: The following log message is filling up the SYS log when STIR/SHAKEN feature is in use:
MAJOR .GWCM: mcsEncodeCPC_MSG_INFO_STR: CPC_OP_STR parameter length mismatch: sizeof length 152: parameter length 216, parameter:397

Root Cause: There is code in SAM that is checking for an internal inconsistency and logging this message when it detects an internal inconsistency.
In this particular case, the message is being logged unnecessarily and it does not indicate any impact on customer functionality.

Steps to Replicate: Setup the SBC and PSX for STIR/SHAKEN call flows and run a GW-GW call.

The code is modified to ensure that this message is no longer logged in this very specific scenario.

Please note that this specific message (for parameter:397) does not indicate any impact on customer functionality.

Workaround: There is no workaround.

SBX-99299 | SBX-101418

2

PortFix SBX-99299 The SBC was routing calls to wrong port number when targets are defined by SRV records and 1 or more targets get blacklisted.

Impact: When the IP peer is configured as FQDN and FQDN resolves into two IP addresses and port combinations, when one of the peer is blacklisted, the SBC may start sending a call to invalid IP address or port combination.

Root Cause: When one of the peer is blacklisted, the SBC uses port from blacklisted peer.

Steps to Replicate: Reproduce the scenario :
1. Configure FQDN as IP PEER.
2. Configure DNS server to respond with 2 records.
3. One of the peer is down or unresponsive.
4. After certain number of calls, the SBC starts sending call to invalid IP and port combination.

The code is modified to ensure the SBC uses the correct port when the IP Peer is configured as a FQDN and one of the peer is blacklisted.

Workaround: None.

SBX-102081 | SBX-102154

2

PortFix SBX-102081 During a RTP-VTP 10 CPS, the 100 CHT G729 passthrough load found CPU Congestion and CPU Spike multiple times.

Impact: Intermittent CPU congestion reported for two vcpu overnight run.

Root Cause: With two vcpu setups, there is no dedicated SIG core. Both the mgmt core and signaling cores are shared and the spikes in mgmt threads are causing the SIG congestion.

Steps to Replicate: Run a two vcpu ovenight passthrough load.

The code is modified to disable the CPU congestion monitoring for < 3 vcpu, as it does not have any detrimental effect.

As a result, the momentary spikes of mgt processes does not cause call failures, but raises false alarms of CPU congestion.

Workaround: None.

SBX-101571 | SBX-101644

2

PortFix SBX-101571 The AddressSanitizer detected heap-use-after-free on address 0x6110000a302c at pc 0x55bcb2c39996 bp 0x7fbf04828250 sp 0x7fbf04828248 READ of size 2 at 0x6110000a302c thread T9.

Impact: The "heap use after free" occurs when an IP Peer is created.

Root Cause: This issue occurs when accessing memory that is already freed.

Steps to Replicate: Re-Create an IP Peer with the same name, IP Address and IP Port to reproduce this issue.

The code is modified to address the issue.

Workaround: Do not create same IP Peer with the same name, IP Address and IP Port.
If required, delete the old IP Peer and re-create the same name, address or port.

SBX-96565

2

An Active sbxstop can lead to /dev/drbd0 not being mounted on new Active.

Impact: The sbxstop Active can lead to the /dev/drbd0 not mounted on a new Active.

Root Cause: The DRBD was getting unmounted right after the mount when a switchover happens.

Steps to Replicate:
- On node A, run the switchover from platform manager.
- The B will become active, wait for A to become standby.
- Run sbxrestart on B so that A becomes active again.
- Check df or /proc/mounts for drbd mount status.

The code is modified so the cron job runs once whenever the node becomes active and mount the DRBD partition.

Workaround: None.

SBX-100454

2

The SBC fails to transcode between the G711X in certain SIP - GW-GW scenarios with the HDCodecPreferred and preferNBPassthruOverHDTranscode flags enabled.

Impact: The SBC fails to transcode between G711X in certain SIP - GW-GW scenarios with the HDCodecPreferred and preferNBPassthruOverHDTranscode flags enabled.

Root Cause: If the HD flag is enabled, the ingress GW is using the egress codec as selectedCodecEntry instead of codec entry from audioEncode array. However, the selected Codec Entry is not fully qualified since it is not intersected with Route PSP.

Steps to Replicate: SIPA - SBC1 (GW-GW) SBC2 - SIPB
1. SIP A is offering G711U along with other codecs.
2. SIP B is answering with G711A.
Ingress Route PSP -> G711U,G729A,G722
Gateway Route PSP -> G711U,G729A,G711A,G722
Egress Route PSP -> G711U,G711A
3. When SBC01 receives answer with G711A codec, it fails to transcode the call between G711U on the ingress SIP call leg and G711A on the egress GW2GW call leg. call is disconnecting with 488 error.

The code is modified to use matching codec entry from audioEncode array instead of selected codec in the answer PSP on ingress GW.

Workaround: Testcases:

Case-1: Disable diff in SS flag and keep HD flags enabled.

Case-2: Disable HD flags and keep Diff in SS flag enabled.

Enabled both HD and diff in SS flag:

Case-3: The Ingress and Egress Route PSP has G711USS,G711ASS respectively and GW route PSP has G711-DEFAULT.

Case-4: Ingress and Egress Route PSP has G711USS,G711ASS respectively and GW route PSP has G711SS-DEFAULT.

SBX-101156

2

On a video call hold, the SRTP context for video is omitted.

Impact: The SBC offers RTP context for a video stream instead of SRTP during RESUME re-Invite after HOLD is performed with a video mediaPort being zero.

Root Cause: Certain code was copying the SRTP info from previous active SDP in order to retain the same SRTP key in subsequent call modifications.

However, it does not handle the case if that particular stream is removed in between and then added back

Steps to Replicate:

Configuration:
1. Configure video BW at both Route PSPs.
2. Enable SRTP and allowFallback at egress Route PSP.

Test Procedure:
a) Setup Audio and Video RTP to SRTP pass-Thru call.
b) Ingress peer (RTP side) sends re-Invite to disable video stream (sends re-Invite with audio stream having valid media port and sendrecv AND video stream having port=0 and inactive).
c) Ingress peer (RTP side) sends a re-Invite to add video stream back (sends re-Invite with audio stream having valid media port and sendrecv and video stream having valid media port and sendrecv).

Expected Result:
a) RTP-SRTP Audio and Video call gets established.
b) The SBC disables video stream and sets up RTP-SRTP call with audio stream.
c) The SBC re-establishes Audio and Video RTP-SRTP call.

Actual Result:
a) RTP-SRTP Audio and Video call gets established.
b) The SBC disables video stream and sets up RTP-SRTP call with audio stream
c) The SBC re-establishes Audio and Video RTP-SRTP call.

The code is modified to copy SRTP info from previous active SDP only if stream is valid in that SDP.

Workaround: None.

SBX-101355

4

The SYDP-LAB-SWE-SBC-01-A was not stable after an upgrade to 8.2.2R0 and had a serf.conf file corruption RCA.

Impact: On an upgrade of SBC SWe to version 8.2, the primary upgrade status was not updated causing post-upgrade checks failure.

Root Cause: Missing peerHAIp entry(169.254..88.1) in serf configuration file on the primary node.

Steps to Replicate: Perform an upgrade of the SBC SWe to fix version 9.1.0 and ensure HA IPs are updated in serf.conf file.

The code is modified to ensure HA IPs of both nodes are added to the serf conf file.

Workaround: None.

SBX-100081

2

The "Bandwidth Usage" of packet port is none-zero on the standby.

Impact: Standby SBC. Allocated Bandwith of the Packet Port "pkt3" is at 99%. The active SBC isn't anywhere close to 99%.

Root Cause: One of the pkt Port on SBY went down and came back up.
This resulted in bandwidth allocated on that pkt port NOT getting freed. Hence, when bandwidth got allocated for new calls on standby, the bandwidth usage on standby was higher than on Active.

Steps to Replicate:

1. Setup around 5,000 stable calls on 1:1 HA setup (5,000 calls will ensure there is some usage percentage seen).
2. Check the "Bandwidth Usage" on Active SBC CLI using below command,
"show table system ethernetPort packetPortStatus"
3. Bring down pkt0 on standby.
4. Bring up pkt0 on standby
5. Check the bandwidth usage on Active SBC CLI using below command,
"show table system ethernetPort packetPortStatus"
6. Ensure the Usage on pkt0 of standby is same as it was before.

The code is modified to free the bandwitdh on standby interface when pkt port on standby goes down.
Also, the code is modified to allocate bandwidth on standby interface when the pkt port is back up.

Workaround: There is no work around for this issue.

SBX-85825

2

The SBC fails with LCA errors upon initial EMS Cluster Config push.

Impact: Packet drop between the SBC and EMS while downloading the configuration.

Root Cause: Due to small fill rate and bucket size, the traffic between the SBC and EMS is flow controlled.

Steps to Replicate: Reboot the SBC so that it registers with EMS and download configuration from EMS. Capture the packets between the two to ensure that there is no drop.

The code is modified to increase the fill rate and bucket size to accommodate large configuration size (~40MB).

Workaround: No workaround.

SBX-96018

2

The configuration and Profile Import/Export fails on the OAM SBC nodes.

Impact: The OAM and managed nodes have access to the user-config-import CLI command. The configuration issue can be introduced if this command is used as OAM manages the configuration.

Root Cause: There is no display condition check for the user-config-import CLI command.

Steps to Replicate:

Test #1:
- Deploy VNF with OAM.
- Check that user-config-import CLI command is not available on OAM and the managed nodes.

Test #2:
- Deploy VNF without OAM.
- Check that user-config-import CLI command is available on nodes.

The code is modified to check for the user-config-import CLI command.

Workaround: Do not use the user-config-import command.

SBX-95210

2

The OAM skipped the validation of state when deleting the altIpVars from ipInterface.

Impact: When deleting altIpVars that are in use in an OAM configuration, the validation does not prevent them from being deleted.

Root Cause: Validating metavars on the SBC VMs from the OAM VMs was complicated, and omitted from 8.x OAM development, by checks for "isOam" that would skip the validation if it was on an OAM VM.

Steps to Replicate: Delete the altIpVars that are in use in an OAM configuration.

The code is modified so that if it is invoked from an OAM, it runs a remote lookup, but otherwise when invoked locally on an SBC (or in a configuration without an OAM) it performs the same lookup locally in the static/dynamic metavar table. However, much of the validation was still disabled by "isOam" checks. For this fix, the "isOam" checks are removed, and the lookup function is replaced by a remote lookup function.

Workaround: This validation is only used when attempting to delete altIpVars that are still in use. The workaround is to not delete altIpVars when they are in use, if you are in a load without this fix.

SBX-101359

2

The primary node upgrade got stuck at PostUpgrade check - Timedout_waiting_for_CLI_upgrade_state_change.

Impact: On an upgrade of the SBC SWe to version 8.2, the primary upgrade status was not updated causing post-upgrade checks failure.

Root Cause: This issue was due to the missing peerHAIp entry (169.254..88.1) in the serf configuration file on the primary node.

Steps to Replicate: Perform the upgrade of the SBC SWe to version 8.2 and ensure HA IPs are updated in serf.conf file.

The code is modified to ensure HA IPs of both nodes are added to the conf file.

Workaround: None.

SBX-100597

2

Unable to dump configuration from the SBC.

Impact: The configuration export fails.

Root Cause: There is a missing dummy SBXPIPE callpoint definition.

Steps to Replicate: Export the customer configuration.

The code is modified to include all the missing dummy SBXPIPE callpoint definitions.

Workaround: None.

SBX-99904

2

ASAN stack-buffer-overflow detected in CommandLineParser::isBindProcess.

Impact: The Stack_Buffer_Overflow in the CommandLineParser::isBindProcess that causes the PIPE Process to get killed.

Root Cause: Create a commandLineParser on the stack, and given the address of it to PIPE_PROCESS.

When the function then exits, the stack variable goes out of scope, but PIPE_PROCESS has a pointer to it and it uses it, even though the variable does not exist.

Steps to Replicate: This problem can only been observed when using ASAN specific build in the engineering lab.

The code is modified so that variable does not go out of scope.

Workaround: None.

SBX-102745

2

The C_LIST macro for consistent memory was freeing.

Impact: When making changes to the local auth user configuration on the SBC, it was leaking small amounts of memory.

Root Cause: While processing the list of configured users, the application code was reading the CDB information into local buffers and then not freeing it, leading to a small memory.

Steps to Replicate: This issue is highlighted when make local user configuration changes in the engineering lab with ASAN images.

The code is modified with standard macros to delete the list structures in a generic manner to avoid this problem in the future.

Workaround: None.

SBX-101597

2

The LeakSanitizer detected memory leaks in the CpxAppProcess.

Impact: When making changes to the D-SBC signaling port configuration, the SBC is leaking a small amount of memory.

Root Cause: While reading configuration changes from the CDB, the SBC application code allocates local buffers and they are not getting freed up at the end of processing leading to a small memory leak.

Steps to Replicate: The issue is seen when using ASAN enabled images in the engineering lab and making configuration changes to the DSBC signaling port configuation.

The code is modified to correctly free the memory allocated to the local buffers to avoid the memory leak.

Workaround: None.

SBX-101727

2

The LeakSanitizer detected memory leaks in the SAM Process (DFe process).

Impact: When making configuration changes to the D-SBC profile, the SBC leaks a small amount of memory.

Root Cause: The SBC application code uses local buffers while reading profile changes from the CDB and this memory was not getting freed up correctly, leading to a leak.

Steps to Replicate: This problem is highlighted when using ASAN enabled build in the engineering lab and making DSBC profile changes.

The code is modified to correctly access the local buffers to avoid the memory leak.

Workaround: None.

SBX-102056

2

The AddressSanitizer detected a heap-buffer-overflow in SipsgRedundMsgParamLoadSubsCbStr.

Impact: While printing the debug messages as part of making subscriber data redundant, the SBC was reading off the end of a buffer.

Root Cause: Some of the buffers used to hold string information were not large enough to include a NULL terminator so when printing out debug messages, the printing code was reading off the end of the buffer.

Steps to Replicate: This problem is highlighted when using ASAN enabled images in the engineering lab.

The code is modified to ensure the strings for the subscriber data are NULL terminated to avoid the code reading of the end of the string buffer.

Workaround: None.

SBX-102054

2

The LeakSanitizer detected an error in CpxAaaGetElem.

Impact: When adding new users, a small amount of memory leaked.

Root Cause: While processing the addition of new users, the code allocated temporary memory blocks to hold information retrieved from the CDB about existing users this memory was not getting completely released after use.

Steps to Replicate: This issue is observed when running with ASAN images in the lab.

The code is modified to ensure the temporary memory allocated is freed up after use.

Workaround: None.

SBX-102060

2

Leak detected while running the SBX-93279 HA cases, especially on the SCM and IM process.

Impact: When making a CAC profile configuration change, the SBC leaks a small amount of memory.

Root Cause: When reading configuration changes from CDB, the application code was storing information in local buffers and not freeing it up correctly, leading to a memory leak.

Steps to Replicate: This problem is highlighted when using ASAN enabled images in the engineering lab and making CAC profile configuration changes.

The code is modified to correctly free up the memory in local buffers to avoid the leak.

Workaround: None.

SBX-101229

2

AddressSanitizer detected a stack-buffer-overflow in SipsGetSmmProfileForDlgScopehashUpdate.

Impact: Stack buffer overflow when the 487 response is triggered toward the ingress leg.

Root Cause: A stack buffer overflow occurs because of accessing the freed memory in stack for hSipMsgHandle->pstlocalTsap.

Steps to Replicate: Repeat the CANCEL call scenario to reproduce the issue.

Fixed the issue by populating the right memory in hSipMsgHandle->pstlocalTsap.

Workaround: No workaround.

SBX-100253

2

The SBC services are not coming up with an ASAN build.

Impact: On the SBC5100/5200, there was an ASAN flags error while processing the negative Boot Init Response received from the DSP.

Root Cause: While processing the Boot Init response, variables that are not defined for DSPs on SBC5100/5200 is being accessed. Since memory is not allocated to these variables, accessing them is invalid.

Steps to Replicate: None.

The code is modified where if it is SBC5100/5200 DSP, the mentioned variables are not accessed.

Workaround: None.

SBX-100864

2

The ASAN detected heap-use-after-free in DnsClientTcpSocketRecvMsg.

Impact: When a connection to a DNS server running on transport protocol TCP closes, memory is accessed after it has been freed, potentially leading to unexpected behavior.

Root Cause: A connection to a DNS server running on transport protocol TCP closes.

Steps to Replicate: Address Sanitizer (ASAN) build is used to find the issue. Configure a DNS server with transportProtocol TCP. Run a call which requires DNS lookup.

The code is modified to correct management of DNS connections running on transport protocol TCP.

Workaround: None.

SBX-100658

2

The SBC fails to add an instance ID to Via and the FROM header when changes to the global signaling sipSigControls are made.

Impact: If a configuration change is made on sip sig controls after an SBC is registered to SLB, subsequent calls may fail.

Root Cause: The slbinstance id used by SBC to determine SLB usage mode and route the calls gets reset when SIP signaling controls configuration is changed.

Steps to Replicate:

1. Configure the SBC with SLB and register it to the SLB.
2. Toggle a configuration in SIP signaling controls and make a call through the SLB .

The code is modified to use SLB usage config instead of instance id to set the instance id.

Workaround: After making any sip controls config change, toggle SLB usage configuration, or restart the SBC.

SBX-102629

2

PRS process memory leak for object based messages.

Impact: There was a slow memory leak in PRS.

Root Cause: Object based messages are not properly being deallocated. This leakes both fm fault notifications and fp stats request messages.

Steps to Replicate: Overtime watch PRS memory size increase.

The code is modified to properly free the messages.

Workaround: No workaround.

SBX-103005

2

The RequestURI header content is not correct in SIPREC Metadata profile.

Impact: The request URI header populates in the metadata is not added the URI scheme.

Root Cause: This scenario was not handled from day one.

Steps to Replicate: Make A to B call.

The code is modified to fix the issue.

Workaround: None.

SBX-100701

2

The buffer Overflow of dnsGrpId was detected while configuring the dns group.

Impact: There is a buffer overflow when configuring the dnsgrp.

Root Cause: The local variables that were used to store the information being read in from the CDB were not large enough and it resulted in memory being overwritten.

Steps to Replicate: This issue is only highlighted engineering lab when running with ASAN enabled images.

The code is modified to use a large local variables to avoid the memory overwrite.

Workaround: None.

SBX-99311

2

When the criteria "for" is selected as "Specific response messages", the EMA is not automatically picking the following "with" dropdown.

Impact: The default selection for dropdown elements were not selected.

Root Cause: The root cause was due to upgrade in the jQuery library from 1.8.0 to 3.4.1
In jQuery 1.8.0 library, the first item was selected in dropdown when dropdown selection is emptied.
In jQuery 3.4.1, this behavior is changed and the dropdown selection was kept empty instead of selecting first item.

Steps to Replicate:

1. Login to EMA.
2. Navigate to All-> Profiles-> Signaling-> SIP Adaptor Profile.
3. Click on New SIP Adaptor Profile.
4. Provide the required information like name.
5. Go to criteria and select "Specific response messages" from "for" tab.
6. Verify if the following two tabs have items "of any type" and "a response code of" selected by default.

The code is modified to selected the first item of the dropdown whenever the dropdown selection is empty but with dropdown items.

Workaround: Select the dropdown values manually.

SBX-99960

2

The MRFP instances were not coming up when using SILK NB and WB codecs.

Impact: Unable to provision the SILK NB and WB codecs on the SBC.

Root Cause: The code introduced to fetch the information from the OAM was not equipped to handle SILK NB and SILK WB codecs.

Steps to Replicate: Configure and activate a traffic profile with SILK WB and SILK NB codecs in the codec mix profile associated with the traffic profile. The instance goes for reboot and application fails to come up in the next boot.

The code is modified to handle the SILK NB and SILK WB in the configuration fetching logic in the SBC.

Workaround: None.

SBX-99647

2

The XRM SBX_GoalwoPolicy coverity issues.

Impact: While processing the signaling port configuration, the lifGroupId value was being read as a 32 bit value into a 16 bit storage location causing the memory to be overwritten.

Root Cause: The code was using the wrong API to read the configuration resulting in potential memory corruption.

Steps to Replicate: This issue can only be reproduced using ASAN images in the engineering lab.

The code is modified to only read the lifGroupId as a 16 bit value.

Workaround: None.

SBX-99561

2

The ASAN detecting heap-use-after-free in the CcProcCallFsmMsg. SBC ASAN build failure when testing epcac DBL with SLB.

Impact: SBC accessing call control memory block after the memory block had been freed.

Root Cause: The call control logic maintained a queue of call control blocks that had outstanding events which needed processing. However, in some places the code processed the outstanding events and did not remove the call control block from the queue. While processing call cleanup events, it was possible that the same call control block got added to the queue twice. When the call control instance was released, it removed one instance from the queue but later processing code then noticed there was still a call control block left in the queue and tried to read the memory to process it after it had been freed.

Steps to Replicate: This issue is only highlighted in engineering lab while running with ASAN enabled images. Run call load and trigger bulk call failure.

The code is modified to ensure that call control blocks are removed from the pending queue when all outstanding events are processed to avoid accessing memory after it is freed.

Workaround: None.

SBX-98984

2

Multiple Sequential SRS switchovers on the D-SBC (Openstack) not working.

Impact: Without this fix, Multiple SIPRec server redundancy will not work. The SBC will be able to respond to only one other SRS server after the first SRS is blacklisted but the SBC will not move on to the next one if the current SRS server also gets blacklisted.

Root Cause: One of the Hash lookups that control the logic of finding the next available SRS server depend on recorderId. This is one of the keys for a hash look. There was a mismatch in this key, when multiple SRS redundancy is started.

Steps to Replicate: Make a stable call that will trigger SIPRecording.
Bring down SRS1, the SBC connects to SRS2, bring down SRS2 as well.

The code is modified so the inconsistency in one of the keys (recorderId) for Hash look ups to determine the next available SRS server is fixed.

Workaround: None.

SBX-96625

2

The marker bit is not set in the second termination of the 3pcc call flow.

Impact: The marker bit is not set for the first packet sent out of the SBCthe in the second termination of 3pcc call flow.

Root Cause: The marker bit should be set. only when the packet transmission is enabled, 
The check for packet transmission was missing in the code that resulted in the marker bit being set for any empty packet is not transmitted at all.

Steps to Replicate:

1. Make ALAW to MULAW tranodecoded 3PCC call on an MRFP setup with a C3.
2. Analyze the pcap captured on the both the terminations of the SBC.
Check for the setting of the marker bits for the first packets sent out in either of the terminations

The code is modified so the Marker Bit setting is now done when packet transmission is enabled for the second termination that is when the IP and port of UAS is known to the SBC. The information about the packet transmission being enabled or disabled is communication to the DSP from the upper layers.

Workaround: None.

SBX-98954

2

Unable to configure the HW/SWE SBCs into SLB deployment.

Impact: The SLB cannot be supported with the h/w SBC's.

Root Cause: The CPX validation check prevented a configuration on the h/w SBC's to configure the SLB.

Steps to Replicate:

1.  Configure the SLB.

2. Configure the HW/SWE SSBC in the order below:

   1. Enabled the SLB usage.

   2. Configure the SLB common Interface.

   3. Configure the 'slbAddress' and 'ipAddress'.

   4. Tried configuring zone and ssp.

The code is modified to allow a configuration of SLB on the h/w SBCs.

Workaround: None.

SBX-102470

2

SAM Process memory leak while running the TLS/SRTP load on the Openstack I-SBC.

Impact: The SIP-TLS with an Client Authentication (authClient=true in tlsProfle) causes about 1.2 KB of memory leak per TLS handshake on the SBC.

Root Cause: After verifying the peer certificate, the SBC SAM process did not free memory allocated for accessing the public key.

Steps to Replicate:

1. Run 50,000 SIP-TLS sessions with Client Authentication, and observe the memory used by SamProcess.
2. Run another 100,000 SIP-TLS sessions with Client Authentication, and observe the memory used by SamProcess.
3. Compute the extra memory used for additional 100,000 SIP-TLS sessions.

The code is modified to free the memory allocated for accessing public key after its use.

Workaround: None.

SBX-102478

2

Automated upgrade failure for SLB/SBC from 9.0 to 9.1.

Impact: The newly upgraded OAM VM did not properly boot. On investigation, it was seen that the Cluster IP was not set correctly, even though an upgrade was received from VNFM, which contained the correct Cluster IP.

Root Cause: The updated userData.json received from VNFM was overwritten with the initial boot userData.json (which did not contain the Cluster IP), even though there is code in convertVnfm.py specifically to prevent that from happening. Bad propagation of fixes from other releases into main introduced an indentation problem. Indentation is significant in python, and the bad indentation made the code that checked for an updated userData.json fail to work properly.

Steps to Replicate: Use different types of auto-upgrades should be tested, because they seem to expose the problem with non-updated userData.json more easily than a normal orchestration.

The code is modified so the correct indentation is restored.

Workaround: If the orchestration is failing without this fix, a restart of the VM should be manually triggered to have it re-run the code in question. This needs to be done before VNFM fails the upgrade (1 hour).

SBX-102399

2

Re-registration is failing when the DNS server is down at the SBC instantiation and comes back after instantiation.

Impact: When the DNS server is down at the SBC instantiation and come back after instantiation, the SBC will be attempting to send re-registration request to EMS and re-registration request is failing due to missing ACLs.

Root Cause: Missing the ACL rule to allow the register to the EMS message to go out when the LCA detects a change of EMS IP in the service registry.

Steps to Replicate:

1. Instantiate the SBC.
2. Pass EMS_1 and EMS_2 details.
3. Provide restusername/restpassword for EMS registration
4. Provide the ems_fqdn as FQDN (example : instance1.sanjay.com to ensure this details not available in DNS server).
5. Provide sd_registry with valid DNS server details.
6. Check that the SBC is registered using the EMS IP's shared in Userdata since service discovery is unable to get IP's from FQDN.
7. Updated the DNS zone file such a way that the ems_fqdn is able to resolve both EMS_1 and EMS_2 and reload the configuration.
8. Check lca.log.

Create an ACL rule when performing the registration sequence from the service discovery watch code.

Workaround: None.

SBX-102370

2

Subscription State is not updated as per expires parameter received in NOTIFY.

Impact: The subscription State is not updated based on the expired parameter received in the NOTIFY.

Root Cause: The SBC was not processing the expires in the Subscription-State header of the NOTIFY.

Steps to Replicate:

1. Run SUB-200 OK.
2. Send NOTIFY1 from UAS with expires paramter time t1.
3. Send NOTIFY2 from UAS with expires paramter time t2. (t2<t1)

The code is modified to consider the expires value in header, during the state "active" or "pending".

Workaround: None.

SBX-102600

2

Duplicate Traps are getting generated in the GR setup J1336.

Impact: Duplicate Traps are getting generated.

Root Cause: Modifying the trap target through netconf was not implemented correctly since the modification to support FQDN for trap targets.

Steps to Replicate:

1. Login to the EMS.
2. Register the SBC/SLB.
3. Raise a trap using (set oam eventLog typeAdmin acct fileCount 6).

The code is modified to allow modifying a SNMP trap target through the netconf.

Workaround: None.

SBX-102747

2

The USAGE_LIMIT and IN_USE columns of SystemLicenseInfoStats are updated with double the actual value of all the features in the licenseInfo table.

Impact: After a cloud instance running in Nto1 switches over, the USAGE_LIMIT and IN_USE columns of the SystemLicenseInfoStats are updated with double the actual value of all the features in licenseInfo table.

Root Cause: The code was not correctly updating the list of SBC processes that are contacted to obtained stats.

Steps to Replicate:

1. Run an N to 1 instance with at least 2 nodes.
2. Failover the active.
3. Check that the license SystemLicenseInfoStats pms file does not contain double the number in the USAGE_LIMIT and INUSE columns that is reported in system licenseInfo.

The code is modified to properly update the list of SBC processes that are contacted to obtained stats.

Workaround: After the former active restarts, restart it again.

SBX-102813

2

LSWU upgrade failed from 9.0 to 9.1.

Impact: LSWU upgrade failed from 9.0 to 9.1.

Root Cause: The parameter enableREST was not set in the sbx.conf file after a qcow2 installation of the base version 9.0.0R000.

Steps to Replicate: Perform an LSWU from 9.0 to 9.1 in KVM using qcow2.

The code is modified to address the issue.

Workaround: None.

SBX-102767

2

Call from subscriber number was not allowed after multiple switchover/standalone restart.

Impact: Configured Subscriber list for a surrogate AOR is not restored if the SBC is restarted/Switchover/LSWU. Call from the configured subscriber for an surrogates AOR will fail.

Root Cause: When restoring the IpPeer configuration from shared memory as part of SBX-62864, restore of surrogate subscribe was missed from the SIPFE module. Since optimizing the configuration, the load time feature has large changes.

Regression suite was not present for the SBX-56811 feature. Regression is now covered for SBX-56811 under SBX-102963

Steps to Replicate:

1. Configure Surrogate Registration Profile and the AOR with configured Subscriber list.
2. Attach it to an IpPeer and enable surrogate registration state at Profile and IpPeer.
3. Make a call for a configured subscriber call will be allowed and 401 challenge will be authenticated.
4. Restart the SBC.
5. Make call for a configured subscriber call will be allowed and 401 challenge will be not be authenticated.

The code is modified so the surrogate Registration AOR subscription list is restored the SBC restart/Switchover/LSWU.

Workaround: The SBC every restarted/Switchover/LSWU disable and re-enable surrogate state at IpPeer.

SBX-102184

2

The SBC retries the registration after 1 hour of successful registration with the EMS.

Impact: The SBC restarts the registration to EMS every hour.

Root Cause: The service discovery watch code was not handling a context timeout after one hour of waiting.

Steps to Replicate:

1. Create the SBC Cluster in EMS.
2. Configure the DNS with EMS IP.
3. Check the DNS is able to resolve the IP.
4. Bring up the Direct-Single(1:1) SBC by passing the ems_fqdn and sd_registry
5. Check the SBC registered successfully to resolved EMS IP.
6. Wait one hour.
7. Check the SBC does not resend register to EMS.

The code is modified to improve the error handling.

Workaround: None.

SBX-102689

2

Observing "too many ping" logs in the CE_Node logs of the SBC instances.

Impact: Observing "too many ping" logs in the SBC instances in the CE_Node logs.

Root Cause: The GRPC keep-alive was not properly configured, causing the connection between a GRPC client and the server to be reset every 6 hours.

Steps to Replicate:

1. Orchestrate the SBC.
2. Wait more than 6 hours.
3. Check the CE_Node logs.

The code is modified to properly configure the GRPC keep-alive on client and server side.

Workaround: None.

SBX-102225

2

The SBCs fail to terminate call upon the receipt of BYE from MRFP due to the rtp inactivity timeout.

Impact: The SBC fails to terminate the call if the disconnection is received from the MRF for a session where the tone has been played and egress peer has performed mid-call modification.

Root Cause: In this call flow, after receiving a disconnect from MRF, the SBC wrongly picked up the tone context instead of the MRF context resulting in failure to terminate the call.

Steps to Replicate:

1. Early answer in 18x resulting in MRF transcoded call.
2. UAS sends 180 resulting in the SBC playing tones.
3. UAS sends SIP UPDATE to perform mid-call modification to change the codec.
4. MRF has been configured for RTP inactivity detection. Due to some reason, it does not receive any RTP packets. MRF sends BYE to the SBC.

Expected Result:
The SBC terminates the call gracefully after receiving BYE from MRF.

Actual Result:
The SBC is not terminating the call.

The code is modified to pick the correct context holding the MRF resource.

Workaround: None.

SBX-102429

2

Coverity issues in the Policy/DATABASE.

Impact: The database structure indication members are not initialized that can lead to undefined behavior.

Root Cause: The database structure indication members are not initialized.

Steps to Replicate: This issue is only highlighted by coverity source scanning tool, not known to cause field issues.

The code is modified so the database structure indication members are initialized to default value.

Workaround: None.

SBX-95851

2

The LeakSanitizer detected memory leaks in DiamCsvAddPeer.

Impact: One-time loss: 1626 bytes are lost during configuration time when the FQDN only diameter peer is created.

Root Cause: One of the data structures associated with the FQDN only diameter peer is not freed when the same peer is deleted.

Steps to Replicate: Create a FQDN only Diameter peer, once the connection is established delete the same.

The code is modified to free the corresponding data structures when the FQDN only diameter peer is deleted.

Workaround: None.

SBX-103135

2

SBC sending an INVITE with incorrect b= line values.

Impact: The SBC sends the wrong RR and RS values in the outgoing INVITE for a transcoded call.

Root Cause: On the D-SBC, the NrmaComputeOfferPspForAnswerLeg() gets executed twice when intersecting. Once with ingress route PSP and once with egress Route PSP and even though we pass the right route PSP to the function, the rtpOptions passed to the function is wrong that results in the wrong computation of RR and RS values.

Steps to Replicate: The SBC is configured to make a SIP-SIP call procedure:

1. Configuration: Egress PSP: AMR (WB) Bandwidth efficient. Ingress PSP: AMR (WB) Bandwidth efficient.
2. RTCP is enabled only on egress PSP and RR/RS bandwidth is configured as 500.
3. Flag 'Send RR/RS in SDP' is enabled in IP signaling profile for Egress.
4. Initiate a SIP-SIP Audio call with the Audio codec as AMR WB without RTCP bandwidth related parameters (RR/RS not present in SDP).
5. Observe the SBC sending wrong RR and RS values in outgoing INVITE.

The code is modified to pass the correct rtpOptions for computing the RR and RS values.

Workaround: None.

SBX-102151

2

D-SBC is not sending the rtp packets to other end after transfer in a transcoded call.

Impact: On the D-SBC, one way media was observed with no media towards calling party A post call transfer by B to C for the scenario: First call (A-SBC-AS, AS-SBC-B), Second call(B'-SBC-AS, AS-SBC-C), where AS=Broadsoft application server.

From packet capture on A-SBC leg of the single DSP transcode call, the sequence number of packets sent by the SBC was reset to zero after A is put off hold. This issue is not seen on the I-SBC.

Root Cause: In the D-SBC, with every modify(ex: hold/resume) a new DSP(s) is allocated for a transcode call. The RTP sequence number and RTP timestamp from previous the DSP deactivation were not being passed to the subsequent DSPs allocated in the context of the same RTP stream(SSRC).

Steps to Replicate: Ways to replicate the issue:

1. A simple UAC(G711)-SBC-UAS(G729) transcode call on DSBC platform which uses a single DSP.
Perform a call hold and resume from UAS and observe the RTP packets sequence numbers towards UAC.
The sequence number is reset to zero post resume leading to one way media (no media towards UAC post resume).

2. With call transfer:
Test Setup:
A1,A2,A3 -------------DSBC--------------NS,AS,MS(HOSTED)
Preconditions:
1. Endpoints A1, A2, and A3 are registered with operator AS through SBC5K(DSBC).
Procedure:
1. A1 calls A2, answer the call on A2.
2. User A2 initiates a attended transfer to User A3, User A3 answers the call.
3. Disconnect the call from A1/A3.
4. After A1 is put off hold after successful transfer, the sequence number would be reset to zero leading to one way media (no media towards A1).

The code is modified to ensure the RTP sequence number and the RTP timestamp statistics of both G711 side of DSP and non-G711 side of previous DSP deactivation are passed to the subsequent DSP, so that the sequence number continues incrementing sequentially within the same media stream/SSRC instead of restarting from zero for every modify.

Workaround: No workaround.

SBX-100825

2

SCM process memory leak in the ARS and use of a bad shift in the SIPSG during a switchover.

Impact: Leaks were observed in the SCM due to following reasons:
1. The Confd memory leak.
2. There was a bad shift operation.

Root Cause:

1. Memory was allocated for the confd variable that was not freed, as a result of a direct leak was observed.

2. The variable that was used to store the information from the shift operation was not large enough and it resulted in a bad shift.

Steps to Replicate: This issue is only highlighted engineering lab when running with ASAN enabled images.

The code is modified to free the Confd variable to avoid the leak and to use a large variable to avoid the bad shift.

Workaround: None.

SBX-103224

2

The ipsecSaStatus with local SPI is failing, as well as ikeSaStatus and ikeSaStatistics with ikeSaIndex is failing.

Impact: The show command for ikeSaStatus and ikeSaStatistics was not displaying information for the IPSEC calls of type ikev2 when trying to display with specific key field information.

Root Cause: The display logic was missing to output call information for the type ikev2 with specific parameters.

Steps to Replicate: Make IPSEC calls of type ikev2 and then run the status and statistics commands using the remoteSpi as a parameter.

The code is modified to correctly display information for the IPSEC calls of type ikev2 with specific parameters.

Workaround: The display prints out all information correctly when no parameters are specified.

SBX-99387

2

The baseUdpPort accepts values below 5000.

Impact: On the MRFP, the SBC 5000 is previously the default base UDP port value, but not explicitly enforced. User can configure the baseUdpPort less than 5000, which does not support on the MRFP.

Root Cause: The MRFP was missing a validation to prevent port value assignment less than 5000.

Steps to Replicate:

1. Configure baseUdpPort with value less than 5000.
set system media mediaPortRange baseUdpPort 4999
2. Ensure the commit will fail due to the validation.

The code is modified to prevent the port value assignment less than 5000.

Workaround: Configure the base UDP port with a value of 5000 or more.

SBX-101188

2

The SBC halts when the disconnectSignalSequenceProfile is configured.

Impact: Configuring the disconnectSignalSequenceProfile in the ASAN build causes the SBC to halt.

Root Cause: A stack-buffer-overflow was occurring because of a mismatch in the data types accessed.

Steps to Replicate: Configure the disconnectSignalSequenceProfile in the latest ASAN build, and the SBC should not halt.

The code is modified so the data type was changed from UCHAR to int32.

Workaround: None.

SBX-70305

2

15-16 seconds media outage when the UXPAD processes are killed, the switchover is occuring only after 15-16 seconds of killing all the UXPAD processes.

Impact: 15 seconds of media outage during a switchover triggered by the crash of DSP processes on the SWe SBCs.

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

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

The code is modified to enhance the crash detection of DSP processes on the SWe SBCs.

Workaround: No workaround.

SBX-97598

2

The LeakSanitizer detected memory leaks at SipSgGetHpcCallProfileFromDb.

Impact: There was a memory leak when configuring and updating the HPC Call Profile gets the Strings Feature Code, Access Number and Number Translation.

Root Cause: Configuring and Updating the CLI Hpc Call Profile gets the Strings Feature Code, Access Number and Number Translation.

Steps to Replicate: None.

The code is modified so while de-allocating the list's while retrieving the data in the Feature Code, Access Number and Number Translation.

Workaround: None.

SBX-101883

2

The configuration upload to EMS is failing when the SBC is brought up using "Resolve the EMS IP using FQDN."

Impact: The configuration upload to the EMS is failing when the SBC is brought up using a "resolve the EMS IP using the FQDN."

Root Cause: The SM Process cannot start the EMS upload thread while probing for "is_ems_configured" from sonusTasks.sh.

Steps to Replicate: Spawn a OAM VNF and create a new revision save. Activate and check if new revision gets saved.

The code is modified so the SM process looks for emsFqdn parameter, in the absence of the emsIp and starts the thread responsible for the configuration upload.

Workaround: None.

SBX-101630

2

The SIP-Etag header is missing in the 200 OK sent by the SBC for PUBLISH.

Impact: The SIP-Etag header is missing in 200 OK sent by the SBC for PUBLISH, even though the sipHeader transparency is enabled for the SIP-ETag.

Root Cause: A recent change in design in 9.0 caused this issue.

Previously, the header Transparency was applied on the originating side of the message. This was changed to terminating sided due to the issue. However, the code change was missing for the OOD message and caused a breakage as a result.

Steps to Replicate:

1. From the UAC, send a REGISTER message to the P-CSCF.
2. From the IMS Core, send 200 OK for REGISTER, with Service-Route header.
3. From the UAC, send a PUBLISH message with SIP URI (domain name) in RURI, From Header and To Header & with Event : Presence & Content-Type: application/pidf+xml having application/pidf+xml MIME Body, to P-CSCF.
4. From the IMS Core, send 200 OK for PUBLISH with SIP-ETag and Expires Header.

The code is modified for OOD messages and address the issue.

Workaround: None.

SBX-99793

2

The LeakSanitizer detected memory leaks at SipSgCreateOfferAnswer, while executing sipsgAsymmetricPrack feature.

Impact: A memory leak is observed when the Asymmetric feature is executed.

Root Cause: Allocated the memory for for message body and the memory was not freed.

Steps to Replicate: Run the Asymmetric feature with an ASAN build.

Instead of allocating memory, the memory started using static memory for the message body.

Workaround: None.

SBX-99086

2

Unable to submit SIP peering when the IP Peer is skipped.

Impact: Unable to submit the SIP peering when the IP Peer is skipped. As a result, unable to create configuration wizard if the IP interface group name is not selected manually.

Root Cause: The yin file has modified with the must condition that was not handling in the EMA code. So, the Netconf request was containing the IP interface group name as empty that was causing the error.

Steps to Replicate: Use the following steps to reproduce the issue:

1. Login to EMA as admin user.
2. Go to Configuration-Configuration Wizards and select SIP Peering.
3. Select Address context and Zone.
4. Click Next.
5. Configure Sip Signalling port and click on next button.
6. Configure Sip Trunk group and click on next button.
7. Click on "No" to add more sip trunk groups.
8. Click on Skip button (skip configuring IP Peer).
9. Click on finish and save.

The code is modified to handle the must condition to make it as mandatory field in the EMA UI.

Workaround: Select the IP interface group name manually when configuring the SIP trunk group in the configuration wizard.

SBX-99512

2

The SBC is sending 183 with SDP Media Description, as application 0 UDP/BFCP (null)' instead of the application 0 UDP/BFCP *.

Impact: Issue is raised when the Application media stream is tested with 18x response with SDP.

Root Cause: No code to handle the application stream for the 18x response.

Steps to Replicate: Test the call with 18x having an application stream SDP.

The code is modified to handle application stream for the 18x response.

Workaround: When the 18x response does not have SDP, the issue is not seen.

SBX-101146

2

Duplicate traps are getting generated in the MRFP device.

Impact: A trap target configuration received through the netconf is configuring a "/SNMP-TARGET-MIB/snmpTargetAddrTable/​snmpTargetAddrEntry" entry. The MRFP/SBC code then create a "/snmp/trapTarget" entry with this information and move the original entry to a different name to include an index. If the entry is received twice, the second time it will be recreated, but the code will not take an action since the equivalent "/snmp/trapTarget" entry already exist. As a result, there are now 2 trap entrieswith the same information.

Root Cause: The trap target configuration coming from EMS through netconf is applied twice.

Steps to Replicate: Create trap target through the netconf interface.

When a "/SNMP-TARGET-MIB/snmpTargetAddrTable/​snmpTargetAddrEntry" entry is added, ensure it does not already exist under a different name to avoid entry duplication.

Workaround: Update the trap target entry using the CLI.

SBX-101211

2

The MIM Hash memory leak for an IMSLI call in the D-SBC only.

Impact: One of modules (MIM) used for IMS Lawful Interception leaks a hash entry every time an IMS Lawful interception is triggered for a call.
Without this fix, there will be a continuous memory leak of a hash entry for each IMS Lawful intercepted call.

Root Cause: An IMS Lawful interception stop indication is not being propagated to one of the modules used for IMS Lawful interception. As of a result of this, the hash entry created to achieve/keep track of IMS interception is not freed even after interception for that call stops.

Steps to Replicate: Make an IMS Lawful intercepted call.

The code is modified to the corresponding module so that it can cleanup the concerned hash entries.

Workaround: None.

SBX-100561

2

"Fac Total Block Count Stats" page not loading in EMA.

Impact: The Fac Total Block Count Stats page not loading in the EMA.

Root Cause: In the SIPFE application, the "Global_facTotalBlockCountStats_keybuf" object was not registered with ICM. This led the ICM message sending to SIPFE fail due to this EMA query failed.

Steps to Replicate:

1. Launch EMA.
2. Go to All -> Global -> Fac Total Block Count Stats.

The missed object registration is done to address the issue.

Workaround: None.

SBX-100557

2

The SBC fails to send NOTIFY with 200 OK in the message body in Attended Call Transfer.

Impact: The SBC fails to send the final SIP NOTIFY message to transferor in the attended call transfer scenario.

Root Cause: The SBC fails to communicate the call transfer complete notification across the two call processing modules that led to this issue. The communication was broken due to recent fix for SBX-96711.

Steps to Replicate:

1. Make a basic call configuration.
2. User A Calls User B through the SBC.
3. User B puts User A on hold.
4. User B calls User C through the SBC.
5. User B puts User C on hold.
6. User B sends REFER with replaces info of user A dialog details to replace A - B call with A - C.
7. The SBC transfers the A - B call to A - C.
8. Sends BYE towards User B for A - B Call.
9. Send final NOTIFY to user B to communicate transfer is successful.
10. User B sends BYE for the B - C Call.
11. Finally A - C call continues.

The code is modified to satisfy both the SBX-96711 fix and to rebuild the broken communication across call processing modules.

Workaround: Avoid the attended call transfer scenario.

SBX-100533

2

The cpshistory data is not populating on all active MRFP nodes in 3:1 setup.

Impact: The cpshistory data is not populating on all the active MRFP nodes in 3:1 setup.

Root Cause: The debug command seems like there is an issue for all nodes in N:1 setup except the first node.

Steps to Replicate: Create a 3:1 MRFP setup and check the cpshistory debug command.

The code is modified to print this debug command on all nodes in N:1 setup.

Workaround: None.

SBX-100515

2

Calls are getting rejected with 403 instead of 480, when configured subscribeBurstMax is more than subscribeRateMax.

Impact: The subscriber request are getting rejected with 403 instead of 480, when configured, the subscribeBurstMax is more than subscribeRateMax.

Root Cause: The EndPoint Rate policy for the SUBSCRIBER request putting into OOD (OUT OF DIALOG) request bucket and request handling was treated as SUBSCRIBER, as a result it response causes the code mapping was not working for subscriber.

Steps to Replicate:

1. Configure the subsIngressEndPointRatePolicing in internalSipCauseMapProfile. [set profiles signaling sipCauseCodeMapping internalSipCauseMapProfile <profile_name> causeMap subsIngEpRatePolicing sipCause 480].
2. Configure the internalCauseString ex: "subscription rate exceeded" for subsIngEpRatePolicing [set profiles signaling sipCauseCodeMapping internalSipCauseMapProfile <profile_name> causeMap subsIngEpRatePolicing internalCauseString subscription rate exceeded].

3. Set TG level subscribe rate as 4 in ingress Cac [set addressContext default zone <Ingress_zone> sipTrunkGroup <Ingress_TG> cac ingress subscribeRateMax 4 subscribeBurstMax 6].
4. Send 8 subscribe per second to SBC from ingress Trunk group.

The code is modified to keep the EndPoint Rate policy for SUBSCRIBER in the SUBSCRIBER rate policy bucket.

Workaround: None.

SBX-100483

2

Observed a coredump Comp_SamP after disabling the sipSigPort.

Impact: While disabling the SIP signaling port, the SBC dumped core due to system error.

Root Cause: In the SBC, the wrong context ID was used to fetch the metavar related information while configuring (enabling/disabling) the SIP signaling port. As a result, the SBC has generated a system error.

Steps to Replicate: Bring up a Public Cloud (AWS) 1:1 HA system. Restart the standby SBC box. Try to disable the SIP signaling port. The SBC generated the coredump due to system error.

The code is modified to pass the correct context ID information while fetching the metavar related information while configuring the SIP signaling port.

Workaround: Execute the disabling of the SIP signaling port when the standby is up and running.

SBX-100959

2

The OAM does not validate VlanTag and activate the configuration to the managed nodes even if it used and leads to -1 activeRevision at managed nodes.

Impact: When adding the vLanTags in an OAM configuration, the validation does not prevent identical vLanTags from being added.

Root Cause: Validating the metavars on the SBC VMs from the OAM VMs was complicated, and omitted from 8.x the OAM development, by checks for "isOam" that would skip the validation if it was on an OAM VM.

Steps to Replicate:

1. Configure all the required metavariables on the OAM and do saveAndActivate.
2. Configure the CLI below on OAM and do saveAndActivate.
set addressContext default ipInterfaceGroup MRFP_MEDIA ipInterface MRFP_MEDIA1 ipVarV6 IF3.IPV6 vlanTagVar IF3.VlanId portName pkt0 prefixVarV6 IF3.PrefixV6 mode inService state enabled.
3. Configure the CLI below on OAM and do saveAndActivate. Ensure that portName and vlangTagVar are having the same value as in step 2.

set addressContext default ipInterfaceGroup MRFP_MEDIA_2 ipInterface MRFP_MEDIA3 ipVarV6 VMG2.IngressMedia.IPV6 vlanTagVar IF3.VlanId portName pkt0 prefixVarV6 IF3.PrefixV6 mode inService state enabled

The code is modified so that if it is invoked from an OAM, the SBC does a lookup, but otherwise when invoked locally on an SBC (or in a configuration without an OAM) it looks up the same locally in the static/dynamic metavar table. However, much of the validation is still disabled by "isOam" checks. For this fix, the "isOam" checks are removed, and the lookup function is replaced by a remote lookup function, that checks for duplicate vLanTags.

Workaround: Fill in the correct VlanTag, and not impacted by the missing validation in older loads without this fix.

SBX-100910

2

The CE_2N_Comp_CcsP coredump is seen in the SWE after disabling the interface.

Impact: A CCS Process coredump was observed due to a healthcheck failure. This occurred while the software was establishing a connection to the third-party software serf, which it starts up to detect and communicate with other nodes in the cluster.

Root Cause: The healthcheck failure occurs when a software object does not respond quickly enough to a health check message. This occurs in this case because the software was waiting for serf to finish starting up and did not respond to the message in time.

Steps to Replicate: Stop/start the SBC with networking down or disable/enable the interfaces on a running system. These steps will trigger the code to start up serf and reconnect to it.

The code is modified to introduce a new timer for when the serf is started up, to allow the software to remain responsive to other messages. As an added precaution, healthchecks are temporarily disabled while connecting to serf, to avoid any chance of a healthcheck failure.

Workaround: None.

SBX-100805

2

The LCA does not exit even if the DRBD configuration fails in a 1to1 mode.

Impact: The LCA does not exit even if DRBD configuration fails in 1to1 mode.

Root Cause: The reConfigureHa.pl(Which configures DRBD) script's execution status was not checking in LCA.

Steps to Replicate: Removed the DRBD disk and try to bring up the SBC. With the changes, the LCA run stopped.

The code is modified to check the status of the execution of reconfigureHa.pl script and when it fails, stop running of LCA.

Workaround: None.

SBX-100853

2

The trap resync is not working properly for certain traps.

Impact: The traps with the varbinds containing 4 commas are not getting resynced to the EMS.

Root Cause: The Trap Resync functionality to the EMS is provided by the EMA. Traps generated by the SBC is processed and stored by the EMA. While processing traps, the EMA splits the varbind based on two commas. If there are more than two commas, the trap is ignored leading to the resync issue.

Steps to Replicate:

1. Generate a trap with 4 commas in the varbind.
2. Run a trap resync from EMS.

The code is modified to process trap with more than two commas in the varbind.

Workaround: None.

SBX-100829

2

The SBC is not allowing four calls without a license installed.

Impact: The SBC SWe should allow 4 passthrough calls install license, however only 1 call is working and passing through.

Root Cause: Limit was not updated when the Public Cloud stream was brought into the mainline.

Steps to Replicate: Attempt 4 passthrough calls without a license installed.

The code is modified to limit the passthrough calls to 4.

Workaround: None.

SBX-100817

2

Application failure when lab suffered a power failure.

Impact: The problem was caused by an abrupt shutdown of the host causing the SBC software failure.

Root Cause: Lack of UPS based power source on host in SWE environment.

Steps to Replicate: None.

Documentation being updated with a recommendation that operators install a redundant power source (based on UPS) on the host.

Workaround: None.

SBX-100938

2

The SCM process core dump observed on the SBC for Blind Transfer no Answer from the customer when replied with 603 Decline.

Impact: On the refer failure tone was not aborted. Due to this, the media resources were in the wrong states. So when the SBC tried to revert to original call, it crashed.

Root Cause: Design was not aborting the tone on refer failure. This lead to issue in media handling.

Steps to Replicate: 1. Initiate a basic C2C from the customer app through KL user to Cisco EP1.
2. Call is answered.
3. Initiate a transfer call from the customer app to PSTN POLYCOM EP.
4. After REFER for Transfer is received on the SBC, KL will be out of call.
POLYCOM EP do not answer the call and sends 603 Decline.

At this point crash should not happen and the SBC should revert to original call

The code is modified to abort tone on refer failure.

Workaround: None.

SBX-100647

2

The GUI (EMA) does not allow to create the RoutingLabel for second TG/peer.

Impact: The GUI does not maintain the TG/Peer values upon changing values in RLR form.

Root Cause: On changing the TG/IP Peer in RLR Form, values are getting replaced to the first value as values are not retained.

Steps to Replicate:

1. Go to All -> Global -> Call Routing
2. Go to Routing Labels + Routing Label Route and click on Create button
3. Give name and fill appropriate Values and Save it.
4. Select the Created Routing Label for Edit.
5. Click on Add Routing Label Route button
6. The form will be opened along with tables below Edit Routing Label Section.
7. Select Values of Zone TG and Peer and save it.

The code is modified to retaining values on the changing TG/Peer values.

Workaround: No workaround.

SBX-100752

2

The "Filter Status" page stuck in loading while selecting a value from the list.

Impact: The "Filter Status" page stuck in loading while selecting a value from the list.

Root Cause: The reload icon is not removed after the loading the screen.

Steps to Replicate:

1. Log in to the EMA.
2. Navigate to Administration -> Accounting and Logs -> Event Log -> Filter Status.
3. Try selecting a value from the "Filter Status list". After clicking on the radio button, the page is stuck in loading phase.

The code is modified to remove the reload icon.

Workaround: None.

SBX-100409

2

The OOD INVITE with Replaces fail with multiple I-SBCs behind the SLB.

Impact: The OOD Invite with a replaces header needs to be sent to the same SBC that handled the initial INVITE.

Root Cause: There was no support to parse the to-tag of the Replaces header and pick the instance ID present in that to-tag so that the INVITE with replaces header can be routed to the same instance that handled the initial INVITE.

Steps to Replicate: Verify that OOD INVITE with Replaces header should be routed to the same SBC that handled the initial INVITE.

The code is modified to parse the to-tag present in the replaces header and route the OOD invite to the same SBC that handled the initial INVITE.

Workaround: None.

SBX-97818

2

The audio stream with port=0 appears in callDetailStatus.

Impact: The audio stream with a port=0 shows up in the .

Root Cause: Currently, for an audio stream, there is no condition for stream absent. As a result, an audio stream is retaining even if a port is 0.

Steps to Replicate: Video and Audio (Audio Port = 0)
1. Make a basic video only call from A-B.
2. On a re-invite, add a Audio stream with valid port.
3. On the final re-invite change Audio port to 0.
 
Existing Behavior:
When Audio port is 0, audio stream is displaying in callMediaStatus and callDetailStatus

New Behavior:
When the Audio port is 0 complete Audio stream is removed from callMediaStatus and callDetailStatus.

The code is modified for an audio stream so that in a Video and Audio (audio port = 0) call, the audio stream gets removed from callMediaStatus and callDetailStatus.

Workaround: None.

SBX-102729

2

SCM memory leak while running STIR/SHAKEN with RPH Signing/Verification.

Impact: The memory Leak is caused at the SCM process for a STIR-SHAKEN failure.

Root Cause: When a STIR-SHAKEN call is performed and the STIR-SHAKEN functionality resulted in failure, then the STIR-SHAKEN "Reason Code Text" is populated in order to know the reason for the failure.

As a result, the STIR-SHAKEN failure "Reason Code Text" is then communicated in backward messages.

While populating "Reason Code Text", the intended function will execute twice for a given call. For the second invocation, the existing "Reason Code Text" memory was neither reused or freed. Instead, the call was newly allocated each time for the same call.

This resulted in memory leak for every STIR-SHAKEN call failure.

Steps to Replicate: Run the configuration and execution of a STIR-SHAKEN Call.
The STIR-SHAKEN functionality to result in a failure.

The code is modified to fix the following:

• If "Reason Code Text" memory is already allocated before, then the same memory is reused again by resetting the memory.

• If "Reason Code Text" memory is not allocated previously, then new memory is allocated and used.

Workaround: None.

SBX-102992

2

The SBC is blacklisting a peer when the mid dialog request gets timed out even though "midDialogArsScreenLevel" flag is set to "never" in sipArsProfile.

Impact: The SBC is blacklisting peer when a mid dialog request gets timed out even though the midDialogArsScreenLevel flag is set to never in sipArsProfile.

Root Cause: The original design only covered original INVITE messages and not mid-call INVITE messages.

Steps to Replicate:

1. Make a call from UAC.
2. Answer the call on UAS.
3. When the call is stable send a Re-INVITE request from UAC.
4. The SBC forwards this Re-INVITE request to UAS.
5. Do not send any response to this Re-INVITE from UAS.
6. The SBC sends BYE and terminates the call.
7. Check the "sipArsStatus" on egress zone.

The code has been modified to correctly handle mid-dialogue INVITE's as well as original INVITEs.

Workaround: None.

SBX-95584

2

The LeakSanitizer detected memory leaks at packet handler.

Impact: While reading the configuration data, the SBC was overwriting stack memory and also leaking small amounts of memory.
The SBC was also leaking ICM memory while processing the disable commands on a signaling port that was already disabled.

Root Cause: A number of fields in the SBC configuration where defined as boolean however confd had implemented these as integers. When reading the contents from CDB, the local variable store defined as boolean was not large enough to hold the configuration value and resulted in memory being overwritten.

While the SBC was processing configuration data for users and groups, it was not freeing up all the memory that was allocated, resulting in a leak.

While processing the disable signaling port commands, if the port was already disabled, it resulted in an edge case where the ICM message was not freed correctly.

Steps to Replicate: Most of the problems can only be reproduced in the development lab while testing with ASAN image to pinpoint the small memory leaks.

The ICM leak may be visible on a larger system when continually taking the LIF down and then trying to disable the ports - the following error message can be seen in the DBG log at MAJOR level when it occurs.

"SipSgRemoveSigPort - Could not locate sigport %d"

The code is modified to use the correct size of local variable to avoid memory being overwritten. The code is also modified to correctly free memory / ICM messages to avoid leaks.

Workaround: None.

SBX-93899

2

The createVnfmCsar.py has differences in CSAR generated when the "all: option is used.

Impact: When specifying the parameters "-f, -h, -i, and --personality", then the specified csar will be created. When omitting some of these parameters, a selection of csars are created, but it may not contain exactly what is expected.

Root Cause: It is somewhat of a misunderstanding of what the default value for these parameters are. It is listed as "all", but it is not really all possible values. In fact, the default is only a subset of configurations, that match all the other parameters given. So omitting "-i" does not generate all interface types.

Steps to Replicate: Repeat the commands given in the original test, and compare the output.

The code is modified to generate a warning when an incompatible set is used, and to add some additional SBC combinations to the subset of configurations.

Workaround: As described in the documentation, if you specify the desired value for "-f, -h, -i, and --personality", then this problem will not occur.

SBX-102059

2

Mismatch in the count of ipPeers on Routing page.

Impact: There was a mismatch in the Zone, and IpPeer counts on the UI.

Root Cause: The backend logic using the contained predicate that fetches all the related data.

Steps to Replicate: Go to the Route screen, select trunkGroup and verify the Zone, IpPeer counts.

The code is modified from contained to match, and is now only associated data being fetch based on the parent selected.

Workaround: None.

SBX-102146

2

Observing the "FAC: *FacSendGetRecordRequest get record request already Sent:192.168.8.114" major log on overnight load.

Impact: Getting the FacSendGetRecordRequest major log during the overnight MRFP load run.

Root Cause: The FacSendGetRecordRequest Log has been made as major log but ideally it should be an info level log.

Steps to Replicate: Run the Overnight MRFP load and check for the FacSendGetRecordRequest major log.

The code is modified to address the log issue.

Workaround: None.

SBX-102123

2

The CpxA processes a core on OAM upon configuring the NTP server.

Impact: The CpxProcess cores on an application shutdown.

Root Cause: There was an improper ConfdProxy object destruction.

Steps to Replicate: Stop the application while a traffic load is running to reproduce the issue.

The code is modified to properly delete the ConfdProxy object.

Workaround: None.

SBX-101941

2

The SBC discovery in the EMS fails when the instance is created using VNFM.

Impact: If the csar is created using the "--mgt_vip" option and mgt0 is IPV4, then the SBC discovery in EMS is failing due to the ssh failure to the SBC IP. The debugging shows that the logical IP is used when the actual IP should be.

Root Cause: If the csar is created using the "--mgt_vip" option and mgt0 is IPV4, then there is a problem with the convertVnfm.py script. Generally, it treats the "mgt" and "pkt" interfaces the same, but for an IPV6 mgt interface, it instead uses a "LOGICAL_MGMT" prefix instead of the "VIP" prefix that it uses for the pkt interfaces. This was added to correct this exact problem, but it was only added if the interface was IPV6.

The mgt IPV4 interfaces (as used here) are incorrectly being treated the exact same way as the pkt interfaces, and being added to a VIP section of /opt/sonus/conf/metaData.json.

Steps to Replicate: Create a CSAR with the "--mgt_vip" option, and IPV4 for mgt0 and an EMS. Perform an orchestration with and see if the EMS discovery works properly.

The code is modified for IPv6 to propagate to IPv4. This gives special treatment to the MGT VIP interfaces.

Workaround: Do not use the "--mgt_vip" option in loads without this fix (if you are using IPV4 for mgt0 and an EMS). It does not work without this fix, so omit this option if you do not have this fix.

SBX-101894

2

The RTCP packets are not being sent and received by the SBC in UDP SRTP in a UDP SRTP call scenario.

Impact: With a small SWe SBC profile in the GCP platform, when the SecureRTCP is enabled, the RTCP packets were not generated/relayed by the SBC.

Root Cause: With a dynamic range of resources allocated based on SWe capacity model, the media enc context range check was using a wrong value in packet processing, resulting in rtcp packet drops that required encryption with in the SBC.

Steps to Replicate: With the GCP platform for a small SWe configuration, enable the RTCP relay/termination with a SRTCP support and check the RTCP packets flow.

The code is modified to use the correct media enc range value for the SBC media packet processing to encrypt the RTP, RTCP packets.

Workaround: Enable the RTCP relay/termination without a SRTCP.

SBX-101555

2

Application timeout error for the "show table node" on the OAM.

Impact: The 'show table node' aborts with a timeout.

Root Cause: There is no handling for empty statistics.

Steps to Replicate: Execute a 'show table node'.

The code is modified to handle the empty statistics by returning an empty response.

Workaround: None.

SBX-101853

2

Issue with a restore operation in 9.1.

Impact: A restored configuration is not applied to the Standby OAM and managed nodes.

Root Cause: Configuration updater scripts do not detect the restored revision and do not reboot to apply it. This occurs when only two revision entries are present in /mnt/gfsvol1/config-versions.txt.

Steps to Replicate: Ensure only one revision entry is present in the /mnt/gfsvol1/config-versions.txt
Restore to a previous revision.

The code is modified to check the revisions available.

Workaround: None.

SBX-101464

2

The SBC/ Call is getting cleared upon a second M-SBC switchover.

Impact: A call is getting cleared upon a second M-SBC switchover.

Root Cause: A switchover is taking more than 15 seconds to complete causing the DCM control channel to experience a timeout. The CHM switchover is taking almost 7 seconds causing this delay to complete a switchover.

Steps to Replicate: Initiate an M-SBC switchover within 15-20 seconds of sync completion.

The code is modified by running the encrypted store and CDB related calls in the background, and as a result making some of the calls more time efficient.

Workaround: None.

SBX-101427

2

A newly active OAM Previous Standby) gives warning for setting rebootSBCs flag to true after a switchover, though the traffic profile is activated with a previous active OAM(Newly Standby) with rebootSBCs flag set to true.

Impact: After a switchover, the new Active OAM request for the saveAndActivate rebootSBCs flag is used.

Root Cause: The traffic profile marker file is created on the Standby OAM before the switchover. The standby OAM only replays changes, so the marker file is not deleted.

Steps to Replicate: 1. Make traffic profile changes, commit and saveAndActivate.
2. Wait for all nodes to be back up.
3. Perform a switchover.
4. Make a configuration change, commit and saveAndActivate.

Create marker file only on Active OAM to address the issue.

Workaround:

1. Request a system admin vsbcSystem saveAndActivate rebootSBCs true
2. Manually delete a marker file:
/opt/sonus/conf/swe/capacityEstimates/.oamRebootSbcIfActProfileChange

SBX-101551

2

The trap target is not getting updated on the SBC.

Impact: The trap target is not getting updated correctly.

Root Cause: Modifying trap target through netconf was not implemented correctly since there was a modification to support the FQDN for trap targets.

Steps to Replicate: 1. Login to EMS.
2. Navigate to Network->NodeManagement
3. Click on "New Register Node" button.
4. Select the SBC Core from drop down.
5. Select SNMP security level as AuthPriv or NoAuthNoPriv or AuthNoPriv.
6. Enter all mandatory fields in node registration page.
7. Save and Discover the node.

The code is modified to allow modifying a SNMP trap target through the netconf.

Workaround: None.

SBX-103222

2

The SBC is not sending an INVITE to the MRF for a modified transcode call.

Impact: Run a MRF call flow by configuring the MRF profile.

Root Cause: The MRF Profile values are not correctly read by the application.

Steps to Replicate: 1. Configure the System for doing the MRF call flows.
2. Try the MRF call flow, the MRF must be invoked.

The code is modified to read the values from a proper MRF path.

Workaround: The sbxrestart should solve the issue.

SBX-103154

2

The SBC:9.1 Comp_EnmProcessMain is coredumping.

Impact: Observed a EnmProcess coredump in a AWS instance when the license is applied immediately after the SBC comes up.

Root Cause: When the SBC comes up, the EMA loads default configurations on to the SBC (in this particular case it was loading the trap target configuration) and at the same time, the automation suite run by Design triggered the license installation. The race condition between the EMA trigger and the license command caused a deadlock because no command was able to proceed to completion and EnmProcess cored.

Steps to Replicate: To simulate the simultaneous trigger from EMA(REST API) and CLI, the following script was running to create and delete the trap target. While the script was running, a CLI session was opened and license installation command was run:

#!/bin/bash
while : ; do
curl -kisu admin:admin -XPUT -H "Content-Type: application/vnd.yang.data+xml" https://<EMA IP>/api/config/oam/snmp/trapTarget/target1 --data '
<trapTarget xmlns="http://sonusnet.com/ns/mibs/SONUS-ORCA/1.0">
<name>target1</name>
<ipAddress>127.0.0.1</ipAddress>
<port>8163</port>
<trapType>v2</trapType>
<targetUsername>admin</targetUsername>
<targetSecurityLevel>noAuthNoPriv</targetSecurityLevel>
<state>enabled</state>
</trapTarget>
'
curl -kisu admin:admin -XDELETE https://<EMA IP>/api/config/oam/snmp/trapTarget/target1
sleep .5;
done

The code is modified to handle license installation to a thread so that it is not blocked by any other command and it does not block any command.

Workaround: Delay the license installation for a few seconds after the SBC is up and running.

SBX-103137

2

The Ingress SBC is tearing the call down by sending unexpected BYE to the ingress endpoint.

Impact: The HDCodecPrefered flag is not working as expected if the SDP contains the first two codecs as HD.

Root Cause: If the SDP has first two consecutive HD codecs and HDCodecPreferred flag is enabled, the SBC is incorrectly considering the second HD Codec as NB.
This results in the SBC treating a HD codec as NB while applying the HD rules.

Steps to Replicate: The HD Codec preferred flag enabled
The offer contains multiple HD codecs (the first two being HD)

1. Create the Codec entries with codec G722,G711,G722.1,G729.
2. Configure PSP HDPSP1 with codecs (G722,G711,G729,G722.1), gw PSP GWHDPSP with codecs (G722.1,G711,G729,G722) and HDPSP2 with codecs (G711,G722,G722.1,G729).
3. Enable the following flags:
a) 'HDCodecPreferred and SRPP' flags in gw PSP.
b) 'All Codecs Allowed For Transcoding' in PSPs.
4. Make a LRBT call in which UAC sends INVITE with G722,G722.1.
5. UAS reply '180' without SDP
6. UAS reply '200 OK' with G711.

Expected:
1. Egress side INVITE must have codecs as per the sequence below, G722.1,G722,G711,G729.
2. Ingress side '200 OK' must have codecs as per the sequence below,
G722.
3. A call should be successful with G722 to G711 transcode on ingress side and G711 passthrough on egress side.

Do not tear down the call, due to the SBC treating the second HDCodec as NB.

The code is modified to consider it as a HD codec.

Workaround: None.

SBX-101791

2

Observed the CpxA Process coredump on a MRFP with 10% Packet loss introduced on the HA interface.

Impact: The CpxProcess cores while a traffic load is running.

Root Cause: There is a segmentation fault in MsgClient::checkBuffering

Steps to Replicate: Execute a traffic run.

The code is modified to be more robust by checking for NULL pointer values.

Workaround: None.

SBX-101830

2

The SBC services are going down while running the CLI to create a toneCodecEntry.

Impact: There was a stack buffer overflow while executing the toneCodecEntry for AMR files.

Root Cause: This issue is from day one since the USHORT was used instead of the ULONG for coding the rate variable.

Steps to Replicate: Execute the toneCodecEntry CLI for the AMR codec.

The code is modified to not use usCodingRate(USHORT) and instead use ulCodingRate(ULONG).

Workaround: No workaround.

SBX-101810

2

The SdRegistry parameter was not updated properly in the metadata when the instance spawned using the vnfd.

Impact: The sdRegistry parameter was not updated properly in the metadata when the instance spawned using a VNFD.

Root Cause: The sd_registry information gets mangled by Python, resulting in an invalid JSON.

Steps to Replicate:

1. Upload the 1:1 or n:1 SBC CSAR in VNFM.
2. Instantiate the SBC by passing the SdRegistry as 10.23.3.10.
3. Check /var/opt/sonus/sbcRegistration and /opt/sonus/conf/instanceLcaData.json files are created with proper format for SdRegistry.

Try to dump/load the SDR backend information to accept format that are not valid JSON, but contains a valid configuration.

Workaround: Properly format the SBC userdata "sd_registry".

SBX-101876

2

Possible NRS ICM message leaks.

Impact: There is a small memory leak when adding and deleting ACL rules.

Root Cause: The internal ICM message that is used to trigger the addition and removal of ACL rules in the NRS subsystem is not being freed up.

Steps to Replicate: Add and remove ACL rules and check for memory increasing.

The code is modified to correctly free the ICM memory block after it is processed to avoid the memory leak.

Workaround: None.

SBX-101803

2

The SBC is not sending a 400 Bad request for the From tag length more than 272.

Impact: The SBC is not sending 400 Bad request when the From tag has a length more than 272, though the logs show 095 07132020 161318.327763:1.01.00.45444.Info .SIPCM: *SipsParseMessage: from tag too long.

Root Cause: As part of the SBX-89384 fix, the SipCmSendIncomingPduUind has been modified to add the dscpValue. But in the case of sip parse failure, while calling SipCmSendIncomingPduUind in the SipCmProcessRemotePdu, the DSCP value is wrongly placed in the position of receiveFlags, so the receiveFlags is setting the value of the DSCP that is 46. As a result, enabling the SIP_AKA_SECURITY_ENABLED and the value of receiveFlags is wrongly given to cmFeFlags and the flag is set and it is dropping the PDU before sending a 400.

Steps to Replicate: 1. Configure SBX for below SIP-SIP call
EP1 --> SIP --> SBC --> SIP --> EP2
2. Client sends INVITE message to the SBC with fromtag length equal to 273 and a DSCP value

The code is modified for the DSCP value while calling SipCmSendIncomingPduUind in SipCmProcessRemotePdu.

Workaround: None.

SBX-103098

2

The To tag in To header is corrupted when the SBC forwards the OOD Message.

Impact: The To Tag in OOD messages from the registered users are getting corrupted when relayed.

Root Cause: This is because of a logic issue in the stack function.

Steps to Replicate:

1. Register an End Point.
2. Send a MESSAGE request from same source IP/Port from registered endpoint.
3. Perform a switchover.
4. Send a MESSAGE request from same source IP/Port from registered endpoint.
5. Send a MESSAGE request from different source IP/Port.

The code is modified in stack function and also rejected the OOD messages from the Registered users with "To Tag", similar to SBX-76003 that was done as part of recent customer requirement.

Workaround: No workaround.

SBX-103004

2

The Content-Length header is missing for the SIPREC Metadata message body.

Impact: The content-length header is missing for the SIPREC Metadata message body.

Root Cause: This was not supported from day one.

Steps to Replicate: Make A to B call.

The code is modified in the SIPREC Metadata message body to address the issue.

Workaround: No workaround.

SBX-103006

2

The SIPREC Metadata schema has wrong value for the nameID AOR tag.

Impact: The nameId AOR formed in the metadata is incorrect when the P-Preferred-Identity header with alphabets in the UserName is received.

Root Cause: Username of P-Preferred-Identity header is modified internally based on E164 format.
P-Preferred-Identity is copied for SIPREC metadata purpose after the above modification. As a result, this caused the issue.
NOTE: The P-Preferred-Identity header with the numeric UserName is handled already.

Steps to Replicate: Make a A-B call with the P-Preferred-Identity header sent from A party and A party is recorded.

The code is modified for SIPREC metadata purpose before the E164 modification.

Workaround: No workaround.

SBX-103002

2

The diameter connState is closed after a switchover.

Impact: Without this fix for Hardware and 1:1 deployments post-switch over from the new Active, the diameter connection towards the diameter peers will not be initiated.

Root Cause: During a transition of standby to active, one of the data types present in fetching the diameter peer from CDB is wrong. Because of this, the diameter peer configurations are not fetched from CDB.

Steps to Replicate: In Hardware or 1:1 HA setup, use the following steps to reproduce the issue:
1. Establish diameter connection from the active SBC.
2. Perform a switch-over
3. After the standby becomes active, connection towards the diameter peers are not initiated.

The code is modified so that the diameter peer configurations are fetched properly by the application.

Workaround: None.

SBX-102996

2

The wrong CSeq number was sent for BYE as part of a call termination after a SBC switchover.

Impact: The wrong CSeq number was sent for BYE as part of a call termination after an SBC Switchover.

Root Cause: When a In dialog Event INFO is received containing body/content type as 'media_control'. The SBC generates a new INFO request towards peer. Due to this the Cseq, in a dialog gets increased, this modified Cseq value was not mirrored to the SBY.

Steps to Replicate:

1. The call is established between PSTN User-B to Cisco User-A.
2. User-B initiates a Blind transfer call to PSTN User-C and answered on C.
3. Various INFOs are exchanged.
4. Perform SBC Failover after answering the call on User-C.
5. Send OOD Refer from Kandy Link having Refer-To header with method = BYE, valid Target-Dialog header and Request-URI points to SBC for Call Termination of PSTN User-C.
6. SBC sends BYE to both User C and User A.

The code is modified to the SBY during the INFO flow fixes the problem.

Workaround: Avoid the fail overs and use the stand alone setup.

SBX-102985

2

The CDR field 'Ticks from Setup Msg to Service Est.' of a START record is getting logged with the wrong value.

Impact: The CDR field 'Ticks from Setup Msg to Service Est.' of the START record is getting logged with the wrong value when the "End To End ACK" is enabled and "No CDR Change in End To End ACK" is disabled.

Root Cause: Since the E2E ACK is enabled and No CDR Change in E2E Ack is disabled, the call connect time was not getting updated during the 200 OK and the value is still '0'. Due to this issue, the time difference of a call attempt time and the connect time was coming as a huge value.

Steps to Replicate:

1. Enable IPSP flag "End to End ACK" on both TGs.
2. Disable the flag "No CDR Change in End to End Ack".
3. Make a call from A to B and let the call be connected with session refresh enabled.
4. Once the session refresh occurs, disconnect the call and check the CDR.

Do not trigger the CDR start record when NRM call stable notification is received. Instead, delay it until the ACK is received from the ingress, so that, the call connect time gets recorded before generating the start record.

Workaround: None.

SBX-102976

2

The diam process crashed while doing Rf specific configurations.

Impact: The "revert" option should be used before proceeding when there is an error returned from the confd. The DiamProcess coredumps when diamNode is configured incorrectly and proceeded without "revert" option.

Root Cause: A missing NULL check is the root cause for this issue.

Steps to Replicate: None.

Added NULL check to fix the issue.

Workaround: The "revert" option can be used when the confd throws an error and then proceeds with the further configuration.

SBX-102906

2

The LSWU from 6.2.1R0_2 to 9.1.0R0_8904 fails.

Impact: An upgrade failed due to an unsupported timezone.

Root Cause: The customer timezones are no longer supported, but the upgrade of these timezones were not handled.

Steps to Replicate:

1. Configure one of the three customer timezones.
2. Do an upgrade to 9.1R0(with fix).
3. The upgrade should succeed.

The code is modified to support the customer timezones. After an upgrade, the customer's three timezones are upgraded to Asia/Riyadh.

Workaround: None.

SBX-102932

2

When the Egress leg is tapped, a request-uri parameter is not sent in the SIPREC Metadata.

Impact: The request-URI is not added into the callData section of metadata sent towards the SRS while tapping the egress leg, though it is configured in SipRecMetaDataProfile.

Root Cause: This is day one issue where the RequestURI addition was not handled while tapping the egress leg.

Steps to Replicate: Make A to B call.

The code is modified to handle the requestURI while tapping the egress leg.

Workaround: No workaround.

SBX-101316

2

Root access is not working after the clearDb in the SWE.

Impact: The root access after running a ClearDb on a SWE with the SSH keys enabled is not working. The access to the SBC instance and the user is unable to login.

Root Cause: When the LCA was being run after the ClearDb, there was no clause to support a SWe from being overwritten with the password and the SSH keys were being disabled again.

Steps to Replicate:

1. Launch SWE with SSH keys enabled by RAF.
2. Login with private key SSH to linuxadmin user.
3. Run `sudo su -`.
4. Root user should not be asking for password.

The code is modified to allow the SWe along with Openstack to not be overwritten by the default password when the user is "linuxadmin".

Workaround: Entering a default password when the root user is prompted.

SBX-101235

2

The OAM does not output the ntpq command.

Impact: The NTP server CLI command is not applied to the OAM.

Root Cause: The NTP server CLI command logic was skipped for the OAM due to blind logic change from SmaIsConfigurator() to SmaIsOAM().

Steps to Replicate: Run the following CLI:

configure
set system ntp serverAdmin 169.254.120.4 state disabled
commit
set system ntp serverAdmin fd00:10:6b50:4500::11
set system ntp serverAdmin fd00:10:6b50:4500::11 state enabled
commit
<<<App on OAM nodes gets restarted>>>
request system admin vsbcSystem saveAndActivate
<<<App on managed nodes gets restarted>>>

OAM prompt:
ntpq -p [is successful]

Remove the erroneous check for the OAM node type to address the issue.

Workaround: None.

SBX-100278

2

Disallowed password saved incorrectly.

Impact: A disallowed password saved incorrectly.

Root Cause: There was missing logic for unescaping XML entities and handling special characters in a disallowed word.

Steps to Replicate:

1. Login to EMA and go to Administration > Application Management.
2. Create a New Disallowed password and click Save.
3. The Save operation is successful. Delete operation works as expected.
4. Special characters appearing as expected.

The code is modified to handle special characters and the XML entities while performing the CRUD operations on disallowed words.

Workaround: None.

SBX-100158

2

The MRFP application is not coming up on 5:1 cluster once destroyed and re-created.

Impact: The activation of custom traffic profile with a name as a sub-string of an existing standard traffic profile results in failure when bringing up of the application after redeploying the cluster.

Root Cause: The code base responsible for parsing the traffic profile, from the downloaded configuration coming from the OAM fails when the activated custom profile has a name that is sub-string of any existing standard traffic profiles.

Steps to Replicate:

1. Activate a traffic profile that has a name that is sub-string of any existing standard traffic profile.
2. Activate the traffic profile.
3. Now the configuration is saved in the OAM. Re-deploy the instances with this new configuration. The application fails to come up.

The code is modified to address the issue.

Workaround: While activating a traffic profile, please ensure that the name of the profile is not a substring of an existing standard traffic profile.

The names of the existing traffic profile can be seen from the following command:
> show table system sweTrafficProfile

SBX-100242

2

On the Live Monitor, the chart settings are not saved.

Impact: The chart settings in the Live monitor is not saved.

Root Cause: The chart settings are saved but on a refresh, the charts are not retaining the correct order and chart size.

Steps to Replicate:

1. Login to EMA and open Home > Live Monitor.
2. The live monitor is enabled.
3. Select few charts from "Configure Live Monitor" button.
4. Expand all charts to full width, rearrange the charts and note down the order.
5. Reload the page.

Charts settings are saved and displayed in the order and size user made after refreshing the page

The code is modified so the retrieved chart settings and rearranged the charts in saved order and the size as the user made.

Workaround: No workaround.

SBX-100250

2

The KVM Direct-Single HA MRFP are not uploading configuration to the EMS.

Impact: The 1:1 on the KVM is not creating a configuration store directory.

Root Cause: The hwSubType variable value for the KVM is not consider by the lca.py script.

Steps to Replicate: Deploy the 1:1 on the KVM.

Consider the hwType variable value instead of the hwSubType. This works for all virtual deployment types.

Workaround: None.

SBX-101496

2

The heap-buffer-overflow is detected in the DdhXpadDebugStatCpy.

Impact: There was a heap-buffer-overflow when the DSP debug chan stats are triggered.

Root Cause: The dsp debug chan stats require a DSP Id and chan Id for processing.
In the case of an invalid dsp Id or chan Id (that is a dsp or chan Id, which there is no call), the command was being processed and accessing some invalid data that was resulting in the heap-buffer overflow condition.

Steps to Replicate:

1. Run a transcoded call.

2. During the call execute " dspchanstat dsp <dspId> chan chanId>" by proving the dspId and chanId where the call lands.

3. Next, execute the same command with a different chanId.

4. Before the fix, the PrsProcess crashes throwing the ASAN-error.

5. After the fix, for an invalid channel number, the dspchanstat, just throws and error.

The DSP debug command is not processed for an invalid DSP Id or chan Id to address the issue.

Workaround: None.

SBX-90561

2

TCP “SACK Panic” vulnerability on the SBC.

Impact: There was a recent branded TCP “SACK Panic” vulnerability (CVSSv3 7.5) that can lead to a Denial of Service attack against any TCP interface with TCP SACK enabled (default in Linux). Although the risk is not very high, all of the SBC core released versions were vulnerable to this vulnerability.

CVEs: CVE-2019-11477, CVE-2019-11478 & CVE-2019-11479

Root Cause: The vulnerability was in some of the base debian packages that are installed on the SBC.

Steps to Replicate: None. This is a branded vulnerability and not caused by SBC software.

The code is modified in all active releases to address the issue.

Workaround: Login to system with root privileges and run below commands:

sysctl -w net.ipv4.tcp_sack=0
echo "net.ipv4.tcp_sack=0" >> /etc/sysctl.conf
sysctl -a |grep -i tcp_sack (make sure net.ipv4.tcp_sack = 0)

SBX-101668

2

The LeakSanitizer detects the memory leaks at the hdb_handle_create.

Impact: The leak sanitizer was reporting some memory leaks because of memory allocation done in the CcSetLiCdcMediaTypeFromDb() function in a ccCsv.c file.

Root Cause: The CcSetLiCdcMediaTypeFromDb() function in memory is dynamically allocated for the mediaIpInterfaceGroupName but not freed, which caused the memory leak.

Steps to Replicate: Run a 3xx call with LI configuration on an ASAN build and this leak should not appear.

The code is modified to free the memory allocated to mediaIpInterfaceGroupName after the use of this variable is completed.

Workaround: None.

SBX-100702

2

Observing the "ERROR : Channel 146 already in de-activated state" in the dsp log.

Impact: The dsp.log is overwhelmed with the "ERROR: Channel ## already in de-activated state" prints.

Root Cause: In the GPU design, as part of the command optimization, if there are more than one command for a channel in a particular time slot, the most recent command for the channel is sent to GPU for processing.

The call flow exercised, activates and de-activates the channel immediately, which could be potentially result in sending the activate command followed by de-activate command for the channel in the same time slot. Due to the command optimization mentioned above, the de-activate command is sent for the channel. Since the channel is already in de-activated state and an attempt is made to de-activate it, a message is printed.

Steps to Replicate: Activate and de-activate a channel immediately within 20ms.

The code is modified to disable the prints to not overwhelm the log and impact performance.

Workaround: None.

SBX-88376

2

The SBC interop with Ribbon AS: Upstream Forking was not working consistently using the TLS.

Impact: For a non UDP transports, in an upstream forking scenario where as on ingress side, the SBC receives multiple INVITE with the same Call-Id, From, and To.
In such a scenario, the SBC is not sending all the received INVITEs out to the end points that are registered on same username.

Root Cause: The SBC used to drop off those forked INVITE's that are received during the processing of initial INVITE.

Steps to Replicate: On a non UDP transport, send multiple forked INVITE's towards the SBC with the same Call-Id, From, To, Request URI.

Queuing the subsequent forked INVITE's and processing them in the same order received solves the problem.

Workaround: None or use the UDP as transport.

SBX-102444

2

The link does not get restored for the mgmt interface for an I-SBC in centralized mode.

Impact: The link state in the portMonitorStatus command does not show the correct state when the LDGs are disabled and enabled in a specific order.

Root Cause: In a HA setup, each instance (for example, Node A and B) maintains its own Port Monitor configuration where as both instances maintains the link monitors configuration of both nodes. When the state of Link Monitor configured on Node B is modified, this CDB notification goes to both nodes A and B. As both of them have the configuration, they update the state and reset a link status maintained in a port monitor to UNKNOWN. Then, ICMP Pings are sent only on node B. When it receives a response, it updates the link state of a portMonitor configured on that node and generates a event notification. When the node A gets this event notification, it recognizes that this notification is from peer and only updates the Link Monitor fault state and port monitor link state remains as UNKNOWN on this node.

Steps to Replicate:

1) Instantiate the I-SBC in a centralized mode.
2) Configure the LDG for MGMT interface.
3) Disable the LDG for vsbc2.
4) Disable the LDG for vsbc1.
5) Enable the LDG for vsbc2.
6) Enable LDG for vsbc1.

The code is modified to not initialize link state of port monitor on local node when admin state of peer node LM configuration is changed.

Workaround: The sequence of the LDG state modification has to be changed.

SBX-101586

2

The MSRP call is upgraded to the MSRP and Audio call with payload change from 240KB-255KB, the egress stats is not resetting on the Re-Invite.

Impact: The MSRP call is upgraded to MSRP and Audio call with a payload change from the 240KB-255KB. On the Re-Invite, the Ingress stats are getting set to 0 but the egress stats is not resetting. As a result, when the 255 KB is sent ingress stats show (255*1024 value) but the egress stats adds up the (240*1024)+(255*1024).

Root Cause: If the socketPtr was not having stats, the MRES was being reset.

Steps to Replicate:
1. Make a Re-Invite call so that MSRP call is upgraded to MSRP and audio call.
2. For the Initial Invite sending PDU of 240 KB on the Re-Invite PDU is increased 255 KB.

The code is modified to avoid the the MRES stats reset.

Workaround: None.

SBX-99813

2

Observed the PRS process coredump on two active MRFP instances in the 3:1 mode.

Impact: The application fails to come up and the PRS Process core dumps when activated with a custom GPU traffic profile having the following codec percentage distribution:
"G711" : 18%"AMRWB": 22%"AMR" : 23%"EVRC" : 11%"EVRCB": 7%"G729" : 9%"G722" : 3%"OPUS" : 7% Tone = 10%

Root Cause: The PRS process fails to load the content of DSP device Mapping file, since it consists of an empty line in-between the GPU UXPAD and tone resource definition, in absence of the CPU UXPAD configuration.

Steps to Replicate: Configure and activate a GPU traffic profile with the following codec Mix profile attribute on a SWe/Cloud SBC:
"G711" : 18%"AMRWB": 22%"AMR" : 23%"EVRC" : 11%"EVRCB": 7%"G729" : 9%"G722" : 3%"OPUS" : 7% Tone = 10%

The instance goes for a reboot for applying the traffic profile and during the application bring up, the PRS Process crashes.

The code is modified so the empty line in DSP device map file does not introduce a blank like in the absence of the CPU UXPAD resources.

Workaround: Remove the blank line in /opt/sonus/conf/dspDeviceMap.txt and restart the application(sbxrestart).

SBX-100868

2

The OAM does not push the configuration after a switchover to the standby OAM.

Impact: The configuration changes on the standby OAM is not rejected. After a switchover, it would not take the same configuration changes as it is already done locally. It will not playback either the save and activate as there is no playback logs created. There is no way to push the changes to the managed nodes until another switchover.

Root Cause: Skipping the playback log creation on the standby OAM caused an inconsistent state between the local configuration store and the playback logs.

Steps to Replicate: Perform a switchover with the same configuration to reproduce the issue.

The code is modified so attempts to make configuration changes on the standby OAM node are now rejected.

Workaround: Switchover back to the original active and restart the standby node so that it resyncs with the active.

SBX-102795

2

The configuration flag "Sdp100relIwkForPrack" behavior is incorrect.

Impact: In a latemedia passthrough call, the SBC is not sending ACK for 200 OK when an Asymmetric PRACK Interworking feature is used.

Root Cause: The SBC fails to relay 200 OK for UPDATE in late media passthrough and a reverse offer scenario. This issue is fixed but the given fix breaks the Asymmetric PRACK feature functionality.

Steps to Replicate: Configuration:
1. Set the flag lateMediaSupport to passthru on the ingress TG.
2. Enable the 100rel Support on the ingress TG.
3. Enable the flag Sdp100relIwkForPrack on the egress TG.

Procedure:
UAC sends the Initial INTIVE request to SBC without sdp and has 100rel in Require header
UAS sends the 180 towards SBC with no sdp after receiving offer less Invite.
UAC sends PRACK with SDP answer after receiving 180 with SDP offer.
UAS sends the 200 OK towards SBC with sdp offer.
UAC sends ACK after receiving 200 OK.

Expected Result:
SBC should send ACK with SDP answer on the egress side.
After re-negotiation media communication should be done as per final offer answer communication

The code is modified to address the issue.

Workaround: None.

SBX-100713

2

Observing the major log "XrmAsyncCmdErrHdlr: ERROR NpMediaIntf cmd 2a gcid" in all nodes of the 2:1 cluster.

Impact: Observed the major log "XrmAsyncCmdErrHdlr: ERROR NpMediaIntf cmd 2a gcid" in all nodes of 2:1 cluster.

Root Cause: As the error did not have a valid GCID, the error log becomes unidentified, since there is no action taken by application based on this error message.

Steps to Replicate: Setup:

1. MRFP 2:1 cluster with flavor 32vCPU/32GB RAM/100GB disk /2GPU per instance
2. OAM 1:1 . Flavor 4vCPU/6GB RAM/25GB disk
3. C3 - MGC
4. Pktart
5. EMS
6. AMRWB-G711U call flow.
7. Load sharing enabled in C3 to distribute the load between two active nodes.
8. Custom traffic profile and codec profile are configured.

Procedure:

1. Ensure the MRF1 and MRFP3 are active nodes and MRFP2 is a standby.
2. Place calls at 394 CPS and 62s as CHT.
3. Calls are distributed between MRFP1 and MRFP3.
4. The below log messages are found in all nodes of the 2:1 cluster.

The code is modified to move the error message below the GCID validity check.

During the validation if any issue is found, there is only valid points.

Workaround: None.

SBX-99468

2

The EMA readonly.jsp pages are broken.

Impact: There was a Javascript error was displaying in the developer tools.

Root Cause: The supporting the Javascript file was missing as the error appeared in the console.

Steps to Replicate: 1. Go to All > System > Admin > Sftp user password.
2. Change the dropdown value and select the SBC name.

The console error did not appear in the developer tools.

The code is modified to clear the error that was appearing in console.

Workaround: None.

SBX-99233

2

The SBC SWe fails to load a Secondary management interface.

Impact: The SBC SWe failes to load a secondary management interface.

Root Cause: The secondary management feature was not located in the SWe.

Steps to Replicate: Enable the secondary management interface.

The code is modified by adding a secondary management for the SWe.

Workaround: None.

SBX-102703

2

The SM segFault fails due to an issue in the setEmaConf().

Impact: The SM segFault fails due to an issue in the setEmaConf().

Root Cause: Using a placeholder %s for int32 type instead of %d.

Steps to Replicate: 1. Run a full build.
2. Wait for application to come up.

The code is modified to replace the %s with a correct placeholder.

Workaround: None.

SBX-101948

2

The Fault Avalanche Feature Records are not archived in the sysdump.

Impact: The FAC feature related faultRecords are not getting archived in the sysdump.

Root Cause: The FAC feature related faultRecords are not getting archived in the sysdump.

Steps to Replicate:

1. Enable for Test purpose crash.
2. Send a crash, causing SIP message.
Expected Result:
The system crashes.
A fault record is generated.
After 30 minutes (default expiry time), the fault records are removed from faultrecord dir and moved to expiredRecords dir.

The fix requires the following Platform side changes:

At the SBC Installation time, creating a new folder under /home/sftproot/evlog/faultrecord namely "expiredRecords".

When running sysdump tool, archiving all files, sub-folder and files in sub-folder under /home/sftproot/evlog/faultrecord directory.

It also requires the following Application side changes:

When a fault record expiry occurs, moving the records from /home/sftproot/evlog/faultrecord to
/home/sftproot/evlog/faultrecord/expiredRecords folder.
The application side changes are done from Application team.

Workaround: Test in the hardware machine.

SBX-100782

2

A routeResponseMsg failed error occurs on the SLB if the transparency profile is enabled and PDU Size is set to 4KB.

Impact: If a configuration change is made on a SIP transparency profile and pdu size changed after an SBC is registered to SLB, the subsequent calls may fail.

Root Cause: The slbinstance id used by the SBC to determine the SLB usage mode and route the calls was reset when the SIP transparency profile and SIP pdu size configurations are changed.

Steps to Replicate: 1. Configure the SBC with the SLB and register it to the SLB.
2. Toggle a configuration SIP transparency profile, SIP pdu size and make a call thru SLB.

The code is modified to use the SLB usage configuration instead of the instance id to set the instance id.

Workaround: After making any SIP controls configuration changes, toggle the SLB usage configuration or restart the SBC.

SBX-100413

2

Support for adding the second mgmt IP details through the createConfigDrive script.

Impact: The configdrive tool was not asking inputs for the second MGT port.

Root Cause: The second mgt interface will be not configured if the instance launches with the configdrive.

Steps to Replicate: Generate the config drive and launch an instance.
The SBC should configure both the mgt ports.

The code is modified to get input from the user to configure the second mgt port.

Workaround: None.

SBX-101462

2

The feature "To add VLAN-ID using X-Header for the monitoring interface" that was introduced in 9.0 under SBX-87520 does not work when the system is upgraded from an older version to 9.0 or higher.

Impact: The feature "To add VLAN-ID using X-Header for the monitoring interface" that was introduced in 9.0 under SBX-87520 does not work when the system is upgraded from an older version to 9.0 or higher.

The feature works only for a new installation. A possible workaround for the problem was to disable/enable all the sipSigPorts that are monitored, in order to fetch the vlanTag into the application but this is not acceptable as this workaround would disrupt the live traffic.

The application does not fetch the vlan tag information of the sipSigPorts that are already present during an upgrade scenario.

Steps to Replicate:

1. Install HA pair with 8.2 set up and packet network with VLAN.
2. Perform an Upgrade to 9.1.
3. Capture packets on monitoring server vlantag value will be populated.

The code is modified so that the standby box fetches the vlan tag information of the sipSignalingPorts into the application, so that when the box transitions to active in an upgrade scenario, the vlan tag information is available.

Workaround: None.