SBC Core 08.01.00F001 Release Notes

V05.01.00F007

In a post-recovery, other m-sbcs cannot talk to the CM04A04.

Impact: The IPv6 address becomes unreachable in standby port cable pull scenarios.

Root Cause: The SWe code was not saving a multicast mac address list and re-applying it on a hardware port during a link up/down event for standby ports.

Steps to Replicate:

1. Bring down any standby port by cable pull on the host.

2. Configure a new IPv6 address on the pkt port.

3. Re-insert the cable for the same standby port.

4. Do a port switchover by plugging out an active physical port cable so that the standby becomes active for same port.

5. Ping the new configured IP from step 2 on the outside.

Platform/Feature: SBC

The code is modified to handle the programming of multicast MAC list for standby ports correctly.

IPIGs with underscores fail an MSRP/RCS call on a decomposed P-SBC.

Impact: An MSRP call on a DBSC fails on configuring the IP interface group name greater than 7 characters.

Root Cause: The incorrect type cast was being used while handling the GCID allocation response in the MSBC.

Steps to Replicate: 1. Test a basic MSRP call with a ingress and egress interface group name set to "INTERFACE_LIG1" and "IPINTERFACE_LIG2" respectively.

Platform/Feature: SBC

No RBT in the VoLTE to ATT call flow.

Impact: The TT sends the 180 without a SDP with PEM in the first Monitoring cycle. The vP-SBC relays the 180 without a SDP with PEM:sendrecv.

In this case, the SBC is sending wrong PEM state. The SBC must not be sending any PEM.

Root Cause: When the 180 does not have a SDP is rxd, it is not monitoring (an 180 without the SDP is received during the first monitoring cycle).

The result is the system going in backward compatibility mode and inserting a P-Early-Media:sendrecv in the outgoing 180 without a SDP.

Steps to Replicate:

1. Ingress Leg EMA is disabled, EGress Leg PEM Method is SessionAnswer
2. UAC (VoLTE) --> vP-SBC --> UAS (ATT)
3. UAS sends 183 with SDP no PEM. vP-SBC relays it to UAC (no PEM)
4. UAS sends 180 without SDP no PEM, SBC send 180 without sdp ( NO PEM)

Platform/Feature: SBC

P-SBC openstack installation fails and has OAM node coredumps.

Impact: Upgrade fails if any SNMP trap targeted is 32 characters in length.

Root Cause: Right sized buffer was allocated to fetch data from database but passed incorrect length field to database API. In the case where the field being fetched has max allowed length, the API fails due to the database thinking there is not enough room to terminate the field with NULL.

Steps to Replicate: Create SNMP trap target of 32 character long, try to upgrade, upgrade fails. Perform upgrade with fix.

Platform/Feature: SBC

Mgmt port is not reachable in the SLB.

Impact: SWe_NP failed to come up in large SLB cloud instance (i.e. 16 vcpu or more) with a port redundancy enabled.

Root Cause: In the cloud, the default value of "DosSupportSecPktPorts" flag is set to "true", which means an additional rx/worker thread needs to be spawned for a port redundancy.

The SLB and SSBC use standard_signaling_profile for their core partition. The SSBC uses only one worker for all vcpu configurations whereas the SLB uses 2-workers for larger vcpus( > 16vcpu). If DosSupportSecPktPorts=true, there will be additional worker required. In such a case of SLB, there needs to be a secondary worker thread for each of the worker. This functionality was not supported.

Steps to Replicate: Spawn a 16 vcpu SLB instance in cloud using Heat template. Check the mgmt port reachability.

Platform/Feature: SBC

The SBC fails to play delayedRBT towards the ATT when the 180 is received with a SDP followed by the 182 without a SDP.

Impact: The SBC fails to play delayedRBT towards the ATT when the 180 is received with a SDP followed by the 182 without a SDP(within the first monitoring cycle).

Root Cause: When a subsequent 18x is received within first monitoring cycle, the SBC continues to monitor and was not playing the tone during a monitor failure. The correct behaviour is when the SBC plays the tone on monitoring cycle.

Steps to Replicate:

1. ATT sends an Invite with the PCMU and PCMA towards the Vz volte without PEM: supported.
2. Vz Volte legacy handsets responds with the 180 with a SDP PCMU without PEM.
3. PRACK/200 OK is complete.
4. Vz Volte legacy handsets responds with the 182 without SDP and without PEM within the first monitoring cycle.
5. TMO sends a PRACK/200 OK for the provisional response received.
6. VoLTE far end sends 70 RTP packets.
7. Volte far end sends UPDATE with PCMA.
8. TMO sends the 200 OK with SDP PCMA for an Update received.
9. Volte far end feeds the RTP (120 packets) followed by a continuous stream of RTP.
10. Volte sends the 200 OK without SDP.
11. Volte far end feeds the RTP.
12. Check the callDetail and callMedia status.
13. TMO sends a BYE.
14. Check the CDR.

Platform/Feature: SBC

When subsequent 18x is received within first monitoring cycle, the SBC continues to monitor and play the tone on a monitor failure. To not Play tone on monitoring failure, when subsequent 18x is received within first monitoring cycle is only applicable if the configuration delayedRBtIf180isreceived in the ToneProfile is enabled.

No configuration is pushed post upgrade from V08.01.00R001 to V08.01.00F001.

Impact: Unable to upgrade from R to F version.

Root Cause: Perform a successful R to F version upgrade.

Steps to Replicate: Perform a successful R to F version upgrade.

Platform/Feature: SBC

Configuration is pushed from the OAM to only one selected node but not to the entire cluster.

Impact: In a VNF deployment or upgrade without a controlled sequential procedure, the managed SBC VMs finishing to install or upgrade before the OAM VMs will not have the necessary configuration available to startup and operate correctly.

Root Cause: In a previous fix, the solution was not considered/adjusted as part of recent fix solution.

Steps to Replicate: Deploy or upgrade an entire VNF without a controlled sequential procedure.

Platform/Feature: SBC

The SBC failed to re-establish the media session between the SBC and Teams Client after a call transfer initiated by Teams client failed.

Impact: In scenarios where MS Teams referred the call to another, the SBC started to play a RBT (ring back tone) and if the REFER failed due to the C-party not answering, the media could not be established again between the A and B party.

Root Cause: The media resource used to play the RBT did not get freed up correctly when the REFER failed and this blocked the media flow from A to B being re-established.

Steps to Replicate:

1. Make a call from PSTN to MS Teams.
2. Have MS Teams REFER the call to another user.
3. Let the phone ring as C-party but do not answer it.

Platform/Feature: SBC

The code is modified to correctly free up the RBT resources so the A to B call can be re-established.

A createVnfmCsar.py's simplex CSAR file includes unnecessary virtual IP addresses.

Impact: Unnecessary virtual IPs are allocated whenever the io_type is not virtio. This is not needed, particularly for the mgt0 interface, where they actually interfere with proper EMS registration, because the EMS uses the physical mgt0 port.

Root Cause: When adding support for virtual IPs, it was added in cases where it was not supposed to be added -- to all non-virtio interfaces.

Steps to Replicate:

To test this, run the createVnfmCsar.py script without these parameters and the "--io_type provider" parameter. Then load the resulting CSAR into VNFM, and when start orchestrating it, notice that the additional interfaces are not requested in the Address/Port section of the "Instantiate" screen.

If desired, repeat this with a new VNFM, this time using the "--mgt_vip" parameter to the createVnfmCsar.py script, and notice that additional interfaces appear.

Platform/Feature: SBC

The LSASBX71 switched over and both sides cored.

Impact: A bug in the GW Signaling code can cause a core when the GW Signaling Links are bouncing.

Root Cause: A bug in the GW Signaling code can cause a core when the GW Signaling Links are bouncing.

Steps to Replicate: These steps cannot be replicated.

Platform/Feature: SBC

Observing a memory leak in the SCM process of an active SSBC, during the NP based announcements load.

Impact: Observed a memory leak in the SCM process of an active SSBC, during the NP based announcements load

Root Cause: The Tone PSP memory was not freed for each call correctly.

Steps to Replicate:

1. Configure the setup to play the NP based announcement tones.
2. Initiate 1000 CPS of load with 120 CHT making 8K concurrent tones per MSBC is being played.
3. Let the load run for more than hour.

Platform/Feature: SBC

The ATT PSBC generates PRACK locally.

Impact: The PSBC generates PRACK locally. End to end PRACK is required.

Root Cause: If previous 18x is not reliable, the SBC will disable the E2E PRACK flag internally, which causes the later 18x handle PRACK locally.

Steps to Replicate: Send the first 18x with out Require 100 rel Header and send the Second with Require 100 rel Header from UAS to the SBC.

Platform/Feature: SBC

For a REFER Scenario, the 4th HPC Call is not getting released between A and B party once the 4th call is in queue at TG3.

Impact: In a call transfer scenario, when the HPC call queuing occurs on the egress trunk group towards the referred party, and queue timer expires, the transferred call is released. The SBC is not re-establishing the original call.

Root Cause: The original call is initially in a "stable" state. After call transfer, the call moves to "updating" state. Call transfer is not successful because of a queue timeout. The SBC moves the original call to "stable" state, but the original call remains in an "updating" state.

Steps to Replicate:

1. Configure TG1 towards A, TG2 towards B and TG3 towards C.
2. Configure HPC call queuing on TG3(queue length 1) and CAC call limit 1 and HPC oversubscription: 100%
3. Make 3 HPC calls at a time as mentioned below.
4. Establish A to B call. A refers B to C. B to C call is established and A to B is call is released.

The first 2 calls will be transferred and become stable.
The 3rd call will be queued on the TG3.

Platform/Feature: SBC: Application

The SBC sends an UPDATE, removing max-red=0 towards the voLTE for a AMR-WB codec with modeset 0,1,2, when the SBC plays a delayed tone over AMR-WB.

Impact: The SBC sends an UPDATE, removing max-red=0 towards the voLTE for a AMR-WB codec with modeset 0,1,2, when the SBC plays a delayed tone over AMR-WB. Call is a AMR-WB to EVRCB trascoded call.

Root Cause: The SBC, while playing a tone, was using the max-red attribute of the Route PSP (Value = 0). When the tone is stopped and USER AUDIO from the Egress Sprint side is transcoded from EVRCB to AMWB, the SBC used the max-red attribute from the PeerPSP where it is set to "ABSENT".

SIP engine of the SBC was detecting this change in max-red value in the SDP of the Ingress side leg and was sending the extra UPDATE.

Steps to Replicate:

1) Below tone criteria must be configured on VoLTE TG.
“180 w sdp, EMA = no, DelayedRBT”
“180 w sdp, EMA = e-no, DelayedRBT”
“183 w sdp, DelayedRBTonlyIf180Rxd”
“180 w/o sdp, sdp-offer-answer-complete = yes, EMA = yes, DelayedRBT
“180 w/o sdp, EMA = e-no, DelayedRBT, sdp-offer-answer-complete = yes”
“180 w/o sdp, EMA = e-yes, DelayedRBT, sdp-offer-answer-complete = yes”

2) pEarlyMedia header transparency is enabled on VoLTE TG.
3) AMR-WB is cofigured with restricted mode set 0,1,2 in route PSP for Volte.
4) Sprint TG supports sessionAnswer.
5) VoLTE supports pEarlyMedia with defaultGatingMethod as none.

Platform/Feature: SBC

There was a 4.8-5.3 seconds of media loss observed during a SWe_NP kill triggered the SWO.

Impact: A media switchover is taking 1 second more, as compared to 8.0, if SWE_NP kill is done in the M/T-SBC. There is no change in the CLI switchover time or switchover induced due to the PrsProcess kill when compared to 8.0.

Root Cause: Monit is taking more time to detect and issue a reboot of the system resulting into more time to issue a switchover command to peer.

Steps to Replicate: Kill the SWe_NP on the active and measure a media switchover time for the existing call.

Platform/Feature: SBC

A call from the MS Teams, and audio loss for 30 seconds and a switchover.

Impact: The MS Teams to PSTN call flow with DLRBT are enabled on a software SBC. If there is an SBC switch-over after the call is established, there can be a delay (e.g. 30 seconds) in re-established the media from PSTN to MS Teams direction.

Root Cause: The stored SSN value does not get updated before the SBC switch-over occurs, and it causes the SSN to jump backwards after a switch-over, which caused the one way audio issue for sometime until the SSN value increments past the previously sent value.

Steps to Replicate: Perform a switch-over after the LRBT is played and check that there is no one-way audio issue.

Platform/Feature: SBC: MS Teams

The SBC is not preserving the mid-call updated wps value after a switchover, or across GW-GW, and it is not sending a 400 response for mid-call invalid ets/wps.

Impact: The SBC only mirrors the wps value to standby when the call goes stable (i.e. on receiving 200 OK for INVITE). When the wps value is updated mid-call, it is not mirrored to the standby so it is not preserved on a switchover.

Root Cause: The root cause of these issues is derived from the feature functionality was all newly developed. These issues were identified late in the 8.1.0R0 release test process and that the fixes would be delivered in the subsequent 8.1.0R1 release to allow for thorough testing to take place.

Steps to Replicate:

1. Send mid-call wps updates and ensure those wps values are maintained after switchover.
2. Ensure the updated wps values are present on the egress SBC for GW-GW calls.
3. Ensure the SIP messages (except BYE and CANCEL) containing an invalid ets/wps received on a TG provisioned for rejecting invalidEtsWps, are rejected with a 400 response.

Platform/Feature: SBC

The MS Team scenario with ICE causes the RTCP port with X when the RTP is Y and mux supported.

Impact: When the SBC sends out re-INVITE messages on a call leg supporting ICE, it can still include "a=rtcp:<rtp port + 1>" value in the SDP that is different to the previously agreed the RTP/RTCP mux setup agreed with the remote end.

Root Cause: The SBC was not considering the SDP answer from the peer when setting the RTCP port value.

Steps to Replicate:

1. SBX routes the INVITE to egress endpoint via egress TG. INVITE should have valid SDP including -
In SDP audio stream -
RTP and RTCP ICE candidates
a=rtcp-mux
a=rtcp: which has port number of audio rtp+1

2. SBX should send 180 and 200 OK to ingress endpoint and include valid SDP for audio stream.

3. Valid ACK received.

4. SBX routes the re-INVITE to egress endpoint via egress TG. re-INVITE should have valid SDP including -
In SDP audio stream -
RTP ICE candidates (no RTCP as egress has already agreed rtcp-mux)
a=rtcp-mux
a=rtcp: which has same port number as audio RTP(as this is not initial offer for this stream and rtcp-mux has already been agreed)

In SDP video stream -
RTP and RTCP ICE candidates (as this is initial offer for the video stream)
a=rtcp-mux
a=rtcp: which has port number of video rtp+1 (as this is initial offer for the video stream)

5. Call signaling completed and then call cleared.

Platform/Feature: SBC: MS Teams

The WALL Signaling PSBC10A01 cored.

Impact: When the MRF Modify is received, the MRFRM fsm state must be OA_ACTIVE. But in this issue, the state is wrong and leads to an incorrect typecasting.

Root Cause: Root cause has not been found, but defensive has been checked.

Steps to Replicate: Run the MRF load and this issue will be displayed.

Platform/Feature: SBC

The SBC is producing SCM Process coredump after a third switchover.

Impact: After a third switchover, a SCM Process coredump occurs in the SBC.

Root Cause: On a 5210, up to 60,000 calls may be tried on an HA system. The SBC may breach the memory threshold if continuous switchovers are done with more than 60,000 calls.

Steps to Replicate: Test steps involve doing multiple switchovers in a HA setup with number of system calls more than and equals to 60,000.

Platform/Feature: SBC

Portfix SBX-91481: Under certain conditions, the SBC sends out a duplicate OPEN_ACK, causing the receiving GW to crash.

Impact: A bug in GW Signaling code can cause a core when GW Signaling Links are bouncing.

Root Cause: A bug in GW Signaling code can cause a core when GW Signaling Links are bouncing.

Steps to Replicate: This problem is not reproducible.

Platform/Feature: SBC

The ATT SBC removes a PEM:sendrecv in the SIP 180 post update when a prior update 18x has no PEM.

Impact: When the SBC receives a PEM:sendrecv in 180 response after an update transaction, no PEM is received prior to the SBC receiving a PEM. The SBC is not sending a PEM:sendrecv in 180 response in an outgoing response.

Root Cause: A PEM header is added based on monitoring state, which is not reset after every response sent out in a particular case. Based on previous state, a PEM is not inserted in the 180 response sent out.

Steps to Replicate: While sending 180 response out, the SBC adds PEM header.

Platform/Feature: SBC

HPC queue stat hpcQueueOverflows is incremented twice for egress queuing.

Impact: When queuing occurs at the egress leg, hpcQueueOverflows is incremented twice for a full queue causing the SBC to trigger another 182 towards the ingress side. Thus, all TRM APIs are called twice.

Root Cause: When the queue timer starts at the TRM for a queued call, the Call Counter strarts the Queue Guard Timer of 90 seconds. Before expiring this QueueGuardTimer, if the QueueTimer at the TRM expires, then the Call Counter initiates a second pass.

The code is modified to align the behavior with GSX legacy functionality.

Refer to the 8.1.0R0 feature SBX-50523 in the SBC Core 08.01.00R000 Release Notes for additional details.

The ATT sends an 181 PEM:sendonly to PSBC. The PSBC removes an PEM:sendonly towards an IMS.

Impact: The SBC does not add PEM header in an outgoing 181 Call is being forwarded and the 182 Call requested is Queued.

Root Cause: The SBC does not add PEM header in an outgoing 181 Call is being forwarded and the 182 Call requested is Queued.

Steps to Replicate: Enable an PEM in both ingress and egress. The INVITE from ingress peer has a PEM supported header and the INVITE sent to egress has PEM supported header. An 181 Response from egress peer comes with a PEM header, while sending an 181 response to ingress in the SBC to add a PEM header.

Platform/Feature: SBC

Portfix SBX-90768: Ensure the cron logs do not flood the /var/log/syslog. (Originated in release 6.2.5).

Impact: The Cron logs are being logged to /var/log/syslog due to the default configuration and the syslog is flooded with cron logs.

Root Cause: This is due to the default configuration.

Steps to Replicate: Installed the fix build and confirmed that cron logs are not logged in syslog.

Platform/Feature: SBC

Make OOM killer the configurable.

Impact: The threshold that coredumps of top memory consuming processes are taken when memory usage is high.

Root Cause: The threshold was not configurable.

Steps to Replicate:

set system outOfMemoryCoredump threshold 75
set system outOfMemoryCoredump numberOfProcessesToCoredump

Run a memory consumption utility to consume 75% of system memory
Verify that 3 core dump files are present in the /var/log/sonus/oom/ directory

Platform/Feature: SBC

Two new cli configuration options is added:

set system outOfMemoryCoredump
Possible completions:
numberOfProcessesToCoredump - The number of processes to take a core dump of when memory utilization is high
threshold - The memory utiliization threshold to determine when to take coredumps of high memory consuming processes

set system outOfMemoryCoredump threshold
Possible completions:
<Enter "disabled" or a value in the range of (75..89)> <The threshold for taking coredumps when memory utilization increases>

set system outOfMemoryCoredump numberOfProcessesToCoredump
Possible completions:
<The number of processes to take a core dump of when memory utilization is high>[2]

The active OAM fails to come up due to prolonged time taken for a policy DB upgrade.

Impact: After the upgrade to 8.1.0R0, the OAM node may fail to startup.

Root Cause: The policy DB conversion from Oracle to Postgres can take a long time during the upgrade. Due to the delay, the metavar exchange fails on standby causing the active to not complete a startup.

Steps to Replicate: To test the fix, the script has a sleep of 10 minutes, to simulate the delay observed during upgrades.

Platform/Feature: SBC

The Call Graphs are showing more calls after upgrade.

Impact: Stale calls may be found on the newly upgraded SBC when upgrading from a version older then 6.1.0 to something higher.

Root Cause: As a result of changes that were made to the call ID in 6.1 code, during LSWU any calls that existed prior to the upgrade and were then modified or terminated after the upgrade started will be left in a hung state. The only way to clean up these calls is to use the following commands:

 unhide debug
 request sbx rtm debug command “cleanup <gcid>

Steps to Replicate:

To reproduce the issue :
1. Create an audit key greater than 31 by multiple switch over on an HA system or by using instrumented code.This will create GCID values using the high bits ( bit 30-31 ) of GCID value.
2. Setup SIP calls on the system.
3. Initiate the LSWU on standby and after standby is upgraded to newer version, all the established calls set to active will be synced.
4. Start the LSWU on active.
5. At this point, standby will become active.
6. Hang up calls that are established before the standby is Active.
7. Issue the "show table global callSummaryStatus" CLI command and for all those calls, data will be unavailable.
8. These calls will consume resources.

To verify the issue.

1. Perform the same steps mentioned above.
2. After upgrading to a version with a fix, after calls are hung, the resources are released and show the "table global callSummaryStatus" command will not show any orphaned calls.

Platform/Feature: SBC

Possible Memory leak in the Sam process.

Impact: The SAM process will leak memory in the case where a De-REGISTER is received and then within less than 30 seconds, another REGISTER in the same AOR is received.

This will only happen if Multiple contacts in the AOR flag is disabled.

Root Cause: The code does not free certain memory blocks.

Steps to Replicate:

1. Multiple contacts per AOR flag will be disabled
2. Do a Register for particular AOR and do a de-register.
3. Within less than 30 secs, re-send the registration for same AOR so that SIPFE selects the same preferred slot which was used for registering the same AOR earlier. By registering multiple users with same time period, leak will be reproduced.

Platform/Feature: SBC

The ScmP may core in relation to the ARS.

Impact: The SCM process may coredump when the SIP signaling port is out of service.

Root Cause: The SCM process may coredump when the SIP signaling port is out of service, if calls are in progress and if a SIP transaction timeout occurs.

Steps of Replicate: N/A

Platform/Feature: SBC

The SBC does not drop the call when the TCP application media BW received is greater than the configured BW.

Impact: When the video bandwidth(BW) was configured, the TCP/BFCP stream was not considering the BW and the SBC was not rejecting the call.

Root Cause: There was no code to compare the received BW in an incoming message with the video BW.

Steps of Replicate:

1) Configure video BW as 100 on ingress Route PSP.
2) Send TCP/BFCP stream with b=AS:200 in the INVITE message.
3) SBC will reject the call since received BW(200) is greater than the configured BW(100).

Platform/Feature: SBC

The intermittent domain is not applied.

Impact: The includeEnumParam bool was not initialized in the constructor. Sometimes, the enum parameters were not added in the D+ response.

Root Cause: The includeEnumParam bool was not initialized in the constructor.

Steps to Replicate: Enable the includeenumparam on the IPSP and attach with the egress TG. In the ENUM response provision, the ENUM records with a few user parameters. These parameters must be passed transparently in the egress invite.

Platform/Feature: SBC

Upgrade failed from 7.1R0 to 8.1R0.

Impact: An upgrade failed between 7.1R0 to 8.1R0.

Root Cause: A mandatory node /eventLog{memusage}/servers{server1} is not created with an upgrade code.

Steps to Replicate: The steps cannot be replicated.

Platform/Feature: SBC

Portfix SBX-92251: CSAR must not create the OAM and Managed VMs with different mgmt IP metaVar. (Originated in release 8.2.0).

Impact: The MGT0 interfaces are not pingable after a VNFM orchestration.

Root Cause: The MGT is renamed and PKT interfaces on the OAM VMs, to prevent link detection problems. It only must have renamed the PKT interfaces (because they are not used on OAM VMs).

Steps to Replicate: Create a VNFM-based CSAR with these fixes, observe that the MGT0 interface on the OAM VMs is pingable.

Platform/Feature: SBC

The PRS Core generated while a BFD configuration was being deleted.

Impact: Core was being generated at the time of deletion of an BFD session.

Root Cause: The problem was in the XRM module. The XRM was trying to remove the entry from the CONTROL XRES audit/sync list that was never created for a BFD.

Steps to Replicate:

1. Create one BFD session.
2. Delete the BFD session.
3. No core will be generated.

Platform/Feature: SBC

A service instance is not sent to the intercept server from the GSX when a call is on HOLD (downstream).

Impact: When the SIP-SBX-GW-GW-GSX-ISUP call is intercepted, if hold/retrieve is received from either side, the SBC is not sending a service instance messages to the LI server.

Root Cause: The SBC is not sending the service instance messages to the LI server.

Steps to Replicate:

Setup
SIP---GW(SBX)-----GW(GSX)-------ISUP
Description:
When call HOLD comes from called (egress), GSX does not send service instance to the intercept server.

Steps to Verify:
Make the above setup
1. Start the LI server
2. initiate SIP-ISUP call with HOLD from egress
3. Check LI server logs for service instance msg for hold and retrieve.

Platform/Feature: SBC

The BFD and ACL are not being deleted, even the BFD sessions are deleted from the interfaces.

Impact: The problem was seen when BFD state was being disabled along with remote IP address modification. In this case ACL were not being deleted.

Root Cause: The code was missing to handle the issue.

Steps to Replicate:

1. Created BFD session.
2. Disable this BFD session along modification of remote IP address.
3. Enable BFD.
4. Delete BFD
5. ACL must not be there.

Platform/Feature: SBC

The ATT P-SBC DelayedRBTOnlyIf180Rxd is not working.

Impact: The ATT P-SBC DelayedRBTOnlyIf180Rxd is not working.

Root Cause: When an 183 with SDP PEM inactive is received, the SBC is going for tone play when Delayed an RBT if the 180 received is enabled.

Steps to Replicate:

Configuration:

1. Delayed an RBT if the 180 is received in tone Profile.
2. EMA is enabled and Tone Profile is enabled.
3. Tone criteria matches for delayed RBT if the 180 is received
4. The 183 Response is received with PEM inactive.
5. SBC does not go for tone play.

Platform/Feature: SBC

A slow SamP memory leak when running GW-GW calls.

Impact: Possible slow memory leak in the SAM process when running GW-GW calls.

Root Cause: GWFE is leaking a copy of incoming PDU which was queued internally.

Steps to Replicate: The steps are not reproducible.

Platform/Feature: SBC

Observed the SCM Process core dump in a weekend load.

Impact: A SCM Coredump is seen when running a Mixed call load.

Root Cause: The pstLocalTsapAddress is corrupted and is causing the issue.

Steps to Replicate: Run the Mixed call load for more time.

Platform/Feature: SBC

The SBC is dropping the second codec for text stream when the sendOnlyPreferredCodec is enabled.

Impact: The SBC was dropping the second payload for the text stream if "Send Only Preferred Codec flag" was enabled and the offer answer contains both t140 and red as payloads for this stream.

Root Cause: The "Send Only Preferred Codec" flag's logic was applied even to the text stream, which resulted in the SBC picking the first codec and dropping the other.

Steps to Replicate:

1. Bring up setup for A-B call.
2. Enable the flag t140 on both PSPs.
3. Enable the flag sendOnlyPreferredCodec on both IPSPs.
4. Send INVITE from A with both Audio & text media stream with 2 codecs for text(t140 & red).
5. Send 200 OK from B with both Audio & text media stream with 2 codecs for text(t140 & red) both of the payload is received i.e. (t140 and red) is received and no payload is dropping

Platform/Feature: SBC

The memory leaks in SIPSG.

Impact: While debugging a resolved issue for SCM crashed from segmentation fault fired from malloc, memory leaks were found in the SIPSG related to a subscription.

Root Cause: The memory leak was observed through the source code inspection.

Steps to Replicate: SIP regression tests.

Platform/Feature: SBC: SIP

Replace the cdb_get when processing the status commands.

Impact: The process cored from healthcheck timeout. An application must not call out to the CONFD when processing CLI status requests.

Root Cause: Application must not call out to CONFD when processing CLI status requests.

Steps to Replicate:

1. Configure IPSEC testbed
2. Start to run some calls
3. From CLI, issue following commands:
"show table addressContext <address context> ipsec ikeSaStatus"
"show table addressContext <address context> ipsec ikeSaStatistics"
"show table addressContext <address context> ipsec ipsecSaStatus"
"show table addressContext <address context> ipsec ipsecSaStatistics"
"show table addressContext <address context> ipsec systemStatistics"

Platform/Feature: SBC

The SBC will stop a tone play and do a RTP cut-thru upon the receipt of an Update form egress when the monitorRtpOnEgressUpdate flag is disabled.

Impact: Even when the monitorRtpOnEgressUpdate flag is disabled, the SBC will stop a tone play and cut-thru a RTP on an Update.

Root Cause: The SBC will stop a tone play and do a RTP cut-thru upon the receipt of an Update form egress when the monitorRtpOnEgressUpdate flag is disabled.

Steps to Replicate:

1) UAC sends Invite with supported codecs.
2) UAS sends 183 with sdp with AMR-WB mode-set=2 with PEM:inactive.
3) PRACK/200 OK is done.
4) UAS sends 180 without sdp.
5) PRACK/200 OK is done.
6) UAS sends UPDATE with EVRCB0 without PEM.
7) UAC answer 200 OK with AMR-WB mode-set=0,1,2.
8) UAS sends 200 OK Invite without SDP.

Platform/Feature: SBC

Unable to delete/modify any IP interfaces.

Impact: Once the BFD is created and the BFD session is established then if the interface is disabled, the user is unable to delete the interface even after the BFD is deleted.

Root Cause: In the XRM module, the UDP port may not released because the interface was not allowing the UDP port to delete. The used UDP port was decremented and was displaying a negative value.

Steps to Replicate:

1. Created BFD sessions and establish BFD sessions.
2. Disabled interface.
3. Delete all BFD sessions and static routes.
4. Try delete or modify interface.

Platform/Feature: SBC

Portfix SBX-92137: The RTP is sent to the RTCP after a monitor success indication. (Originated in release 7.2.3).

Impact: The SBC learns the RTCP port number and uses that to send RTP packets to the end point when the RTP monitoring is enabled.

Root Cause: When the RTP montoring is enabled for a call and the media stream sends an RTCP packet within the number of packets for authorization, the Network Processor (NP) learns the RTCP packet and notifies the application about the sourceIP and sourcePort.

Steps to Replicate:

1. Enable RTP monitoring for a call.
2. Send RTCP packet first and then RTP packets.
3. SBC must send to the learned RTP source port.

Platform/Feature: SBC

Portfix SBX-91019: "IP ACL Rules By Precedence" under default address context was not displayed correctly in the EMA. (Originated in release 8.2.0).

Impact: "IP ACL Rules By Precedence" under default address context displays an incorrect name and count in the EMA. The non default address was present and the ACL is displayed.

Root Cause: Netconf was sending wrong response to the SBC.

Steps to Replicate: Configure the ACL under a default address context and non-default address context from CLI, and display the same in the EMA.

Platform/Feature: SBC

BRM redundancy messages were filling up the DBG logs.

Impact: BRM redundancy messages were filling up the DBG logs

Root Cause: Those were debug messages to help debug a resource leaking issue. The BRM redundancy messages issue can be moved to lower level.

Steps to Replicate: The steps cannot be replicated. Regression test only.

Platform/Feature: SBC

Remove a LI Log appearing in the 8.1 R Build.

Impact: An LI log had started appearing in R build, which was not supposed to occur in Debug INFO mode.

Root Cause: RCA shown that as part of new feature in 8.1, a particular LI related log was introduced as part of new LI feature (may be forgotten to remove in R build) after SVT testing.

Steps to Replicate: Execute an LI call and we should not notice any LI logs.

Platform/Feature: SBC: SIP

The MS Team scenario with ICE causes the RTCP port with X when the RTP is Y and mux supported.

Impact: When the SBC sends out re-INVITE messages on a call leg supporting ICE, it can still include a=rtcp:<rtp port + 1> value in the SDP that is different to the previously agreed RTP/RTCP mux setup with the remote end.

Root Cause: The SBC was not considering the SDP answer from the peer when setting the RTCP port value.

Steps to Replicate:

SBX routes the INVITE to egress endpoint via egress TG. INVITE should have valid SDP including -
In SDP audio stream -
RTP and RTCP ICE candidates
a=rtcp-mux
a=rtcp: which has port number of audio rtp+1

2. SBX should send 180 and 200 OK to ingress endpoint and include valid SDP for audio stream

3. Valid ACK received

4. SBX routes the re-INVITE to egress endpoint via egress TG. re-INVITE should have valid SDP including -
In SDP audio stream -
RTP ICE candidates (no RTCP as egress has already agreed rtcp-mux)
a=rtcp-mux
a=rtcp: which has same port number as audio rtp (as this is not initial offer for this stream and rtcp-mux has already been agreed)

In SDP video stream -
RTP and RTCP ICE candidates (as this is initial offer for the video stream)
a=rtcp-mux
a=rtcp: which has port number of video rtp+1 (as this is initial offer for the video stream)

5. Call signaling completed and then call cleared

Platform/Feature: SBC

ipsecSaStatistics show IPs in reverse.

Impact: ipsecSaStatistics show command shows the 'localIpAddr' and 'peerIpAddr' in reverse.

Root Cause: The IKE module expects the local/remote IP addresses in network order in the received IPSEC SA Statistics data, but it was receiving addresses in host order.

Steps to Replicate: Perform IPSec configuration, establish IKE and IPSec SAs by sending call. Check ipsecSaStatistics show command output.

Platform/Feature: SBC

The SBC fails to send a reinvite/update with a valid port for a non audio stream, after getting a stop tone request when the 18X provisional response is received with an audio and non-audio stream.

Impact: This issue occurs when the SBC is configured to play tone and also when the ingress is sending non-audio stream (text) in the SDP. The SBC sends a text port as 0 to ingress in 18X message. When a change is made from tone playing to end-to-end context, the SBC is not sending valid port for text to ingress.

Root Cause: When a tone is played, the SBC sends text port as 0 to ingress in 18X message. When the tone is changed from tone playing to end-to-end context, the SBC does not see any change in the SDP and does not send valid port for text to ingress.

Steps to Replicate:

1. Configure the SBC to play tone on DSBC with MRF
2. Send 18X with text stream .
3. The SBC will forward 18X with text port 0 (As its playing tone)
4. Later on 2XX of INVITE, the SBC will update ingress with valid text port
5. After call is connected, there must not be an extra re-INVITE

Platform/Feature: SBC

The DTMF transcoding related to call disconnection.

Impact: A certain percentage of the traffic (5%) of the calls are failing due to this incorrect DTMF payload being sent by BROADSOFT.

Root Cause: The SBC was expecting that for a single HD CODEC entry in the 200 O.K ANSWER, the Peer/Endpoint must send a matching 16K DTMF payload as per RFC standard. The Broadsoft server on the Egress side is non compliant and was sending an 8K DTMF, which is causing the call disconnection.

Steps to Replicate:

UAC sends Invite with PCMU and 8k dtmf.
UAS answers with PCMU without any DTMF.
Transcode call was established and call was successful.

Platform/Feature: SBC

The SBC fails to send a a=fmtp parameter towards the UAC, when the SBC received a=fmtp parameter above a=rtpmap in answer from the UAS.

Impact: The SBC fails to send a=fmtp parameter towards UAC, when the SBC received a=fmtp parameter above a=rtpmap for Dynamic Payload in answer from the UAS.

Root Cause: When FMTP line is received prior to the RTP line for a dynamic payload, Internal Logical issue is causing the issue. When the string holding fmtp line is terminated with \0, the SBC unable to parse manually.

Steps to Replicate:

1) UAC sends Invite with AMR WB codec.
2) UAS sends 180 Ringing with AMR with following sdp:
m=audio 6084 RTP/AVP 106 100
a=fmtp:106 mode-set=0,2,5,7;max-red=0
a=rtpmap:106 AMR/8000
a=rtpmap:100 telephone-event/8000

Platform/Feature: SBC

E2E re-INVITE control is not working as expected.

Impact: In a call flow from Kandy to SBC to CUCM (Cisco Unified communications server), while processing a session refresh re-INVITE received from CUCM, the SBC was renegotiating the list of codecs in the re-INVITE it sent out even when the end to end re-invite control was enabled. The issue triggered Kandy to treat the refresh re-INVITE as a new offer and it tried to renegotiate the media with the browser and it led to the video being dropped from the call.

Root Cause: The re-fresh re-INVITE from CUCM has to be treated as a simple refresh and the SBC will not have added extra codecs to the outgoing re-fresh re-INVITE.

Steps to Replicate: Make a video call from Kandy via SBC to CUCM and leave the call up for 20 mins. The refresh logic activates after 15 mins and CUCM sends a re-INVITE to the SBC. Check that there is no impact on the video stream while the session refresh logic occurs.

Platform/Feature: SBC

The PRS process core was observed on standby on the MSBC when the RTCP is enabled.

Impact: The PRS process core was observed on standby on the MSBC when the RTCP is enabled on the REFER scenario.

Root Cause: The core dumped is due to when the BRM tried to allocate the rid for upper select, which is not correct.

Steps to Replicate: Run the REFER call flow on the DSBC with RTCP enabled.

Platform/Feature: SBC

Observing a port status incorrectly and unable to set mac for pkt in the SSBC with a X710 NIC card.

Impact: A port switchover may fail due to a failure to change the mac address on an active port.

Root Cause: The latest DPDK support changing in a mac address of a physical port is allowed through an application. This support has disturbed the functioning of a port switchover.

Steps to Replicate:

Execute a port switchover with the following steps:
1) Failing active port
2) CLI command

Platform/Feature:

The SBC is not sending the ACK towards egress when endToendACK is enabled, along with the endToendRe-INVITE and tone was being fed prior to the final 200OK(INVITE).

Impact: The SBC is not sending ACK towards egress when endToendACK is enabled, along with the endToendRe-INVITE and tone was being fed prior to the final 200OK

Root Cause: This issue can be observed only when both E2E ACK & ReINVITE flag is enabled.

When E2E ACK is enabled, the general local egress ACK is triggered first and the SBC will hold the ACK (sets ccOkayedToSendConnectAck flags) until we receive the ingress ACK due to e2eAck flag.

Steps to Replicate:

1. INVITE received with SDP (PCMU) and no "PEM: supported" from UAC.
2. UAS sends 180 without SDP.
3. UAC send PRACK and UAS sends 200 OK for PRACK.
4. UAS sends 200 OK with SDP for INVITE & UAC sends ACK.
5. Play RTP from both UAC and UAS.
6. UAC sends BYE and UAS send 200 OK for BYE.
7. Check callDetailStatus and callMediaStatus.
8. Check CDR for RTP count.

Platform/Feature: SBC

The SBC services fail to come up on the installed active CE after SWO with added delay on the HA link.

Impact: A delay on the interCE link may prevent the standby from properly communicating with the active node, and may prevent the standby from coming up.

Root Cause: The TIPC kernel module in the 4.19 kernel does not correctly handle the network delay and communication is lost.

Steps to Replicate: Introduce a network delay on the interCE link and verify that on switchover, the standby is able to startup properly.

Platform/Feature: SBC: HA, Redundancy

The VO-KVM SBC instance loses mgt0.

Impact: The large transcode systems have >28 UXPAD processes due to insufficient huge page memory.

Root Cause: Post DPDK-18.11 upgrade, the default memory management mode has been changed and demands more memory. For large transcode systems, the additional huge pages reserved on top of the reserved base memory was not enough to accommodate the memory requirement.

Steps to Replicate:

Create 36 vcpu SWe instance with standard_transcode_profile that has >28 UXPADs.
SWe_NP will fail to come up and as a result, the mgt0 interface will not be up/accessible.

Platform/Feature: SBC

Updates were sending during a call on the C-SBC 7.2.1.R2.

Impact: The C-SBC generated several UPDATEs during a call.

Root Cause: Due to race condition between multiple updates received from endpoint, an extra update was sent by the SBC.

Steps to Replicate:

1. SBC is playing tone on receipt of 180 with EVRCB with AI:rt.
2. SBC receives 183 Session Progress without SDP from CDMA.
3. PRACK for 183 is pending on Volte TG.
4. SBC receives UPDATE with hold with EVRCB.
5. PRACK/200 OK for 183 is completed on Volte.
6. SBC received 200 OK for UPDATE from Volte.
7. SBC switches tone on receipt of UPDATE.
8. SBC receives 183 without SDP from CDMA.
9. PRACK for 183 is pending on Volte.
10. SBC receives UPDATE with resume with PCMU from CDMA.
11. PRACK/200 OK for 183 is completed on Volte.
12. SBC receives 200 OK for UPDATE from Volte.
13. SBC sends additional UPDATE with EVRCB towards Volte.
14. SBC receives 200 OK Invite from CDMA.
15. SBC sends additional UPDATE with PCMU towards Volte.

Platform/Feature: SBC

A VO-Application is filtering routes based on LIFGROUP but does not display options for some of the default routes.

Impact: Default route lookup may fail for destinations going out of the media interface.

Root Cause: The CPS creates default route type of "none" instead of "unicast" with a metric 100 for management ports. When the NRS adds default route for media interface with a metric 100, the route may get added in this "none" route type despite NRS specifying "unicast".

Steps to Replicate:

1. Configure IPV6 address on all mgt ports.
2. Create default route for the media ports.
3. When you do "ip -6 route", you see "none default metric 100" and the media interface default route shows under this "none" group.

Platform/Feature: SBC

Receiving a null in the mediaStream2Codec, in callMediaStatus.

Impact: When an audio+ text media call is made, the mediaStream2Codec is being populated as null.

Root Cause: The text was being removed as per a previous fix, which has made "mediaStream2Codec" field unable to populate for text media.

Steps to Replicate:

1. Bring up the box with the latest SBC build that supports T.140 session.
2. Enable the following CLI and attach to Ingress and Egress TG's.
   -set profiles media packetServiceProfile DEFAULT flags t140Call enable
3. Send INVITE with Audio+T.140 sessions from UAC.
4. Send 200 OK with Audio+T.140 sessions from UAS.
5. Send BYE.

Platform/Feature: SBC

Observing a box reboot while the application is coming up as standby after a port-failure.

Impact: After a node switchover, the standby node may reboot while the application is coming up.

Root Cause: During a node switchover, when application comes up on standby node, the health monitoring for worker thread fails due to a wrong evaluation of CPU cycles spent by the thread.

Steps to Replicate:

Execute node switchover with the following steps:
1) Bringing down all active ports
2) CLI command
3) Fail the application on the active node

Platform/Feature: SBC

Incorrect PEM behaviour on the SBC.

Impact: If the tone playing is in progress (due to 180 without the SDP) and on, the ingress TG EMA is enabled.

Root Cause: If the 18x with SDP is rxd with the EMA state in e-yes, the SBC was not starting monitoring.

Steps to Replicate:

1. Update the SBC towards UAC.
2. Swap tone and start monitoring.

Platform/Feature: SBC

Portfix SBX-93048: The required software version is not available in configure store after the upgrade from 8.1R000 to 8.1R001. (Originated in release 8.2.0).

Impact: In a VNF deployment or upgrade without a controlled sequential procedure, the managed SBC VMs finishing to install or upgrade before the OAM VMs will not have the necessary configuration available to startup and operate properly.

Root Cause: The issue is detected, but the startup sequence is permitted to continue regardless.

Steps to Replicate:

Test 1:

1- Bring up a standalone OAM and standalone SSBC in separate stacks in 8.0R001 build.
2- Instances are up and running with active revision 1.
3- Configure OAM with: set addressContext test, and activate the configuration.
4- Configuration is successfully pushed to SSBC and both the nodes show active revision as 2.
5- Upgrade the SSBC stack first to 8.1R001 build.
6- Once the upgrade of SSBC is complete and the setup is coming up, upgrade OAM stack to 8.1R001 build.
7- Until the time OAM stack is upgraded successfully and services are up, SSBC instance shows "Starting SBC" in lca log.
8- Once the services for OAM instance are up and running, SSBC starts coming up.
9- After both the instances are up, the active revision changes to 3.
10- Configure the OAM again with - set addressContext test2 - and activate the config.
11- Config is activated successfully with both the nodes showing activeRevision as 4.

Test 2:

1- Upgrade the entire 1:1 OAMSSBC, 1:1 SSBC, 1:1 OAMMSBC, 3:1 MSBC stack using the single template from 8.0R001 to 8.1R001.
2- After upgrade, configure OAM active nodes for SSBC and MSBC.
3- Configuration is pushed successfully and all the nodes show active revision as 3.

Platform/Feature: SBC

The MSBCs switchover two nodes restarted.

Impact: On a node switchover on the D-SBC setup, the MSBC or SSBC can have SWe_NP coredump.

Root Cause: Due to this incorrect code optimization in kni thread starts taking 100% CPU on SWO due to large amount of ICM message flows.

Steps to Replicate: On the D-SBC setup, perform the switchovers on the MSBC.

Platform/Feature: SBC

An UPDATE is sent from the SBC.

Impact: The SBC started tone play on receipt of 183 with the SDP. Later, the SBC detects an RTP packets on the egress side and performs a cut-thru. Th SBC is triggering an unnecessary UPDATE towards ingress EP.

Root Cause: As part of end-to-end cut-thru, the ingress SIP stack is faking the answer for the UPDATE, causing the SBC to swap the tone that has been wrongly triggered in an 183 case.

Steps to Replicate:

1. UAC sends INVITE to SBC with codecs 97,8,0,18 [Initial Offer]
2. SBC sends INVITE + IAM to UAS with codecs 97,8,0,18
3. UAS sends 183 + ACM to SBC without SDP
4. SBC sends 183 to UAC without SDP
5. UAS sends 180 + CPG to SBC with codec 97 and OBCI in-band info set [Answer]
6. SBC sends 180 to UAC with codec 97
7. UAS sends RTP packets with codec 97
8. UAS sends 200 OK + ANM and SBC sends it to UAC
9. UAC sends ACK and SBC sends it to UAS
10. UAS sends media RTP packets
11. UAC terminates the call by sending BYE + REL

Platform/Feature: SBC

The SBC is not responding to the 483 for the PRACK with Max-Forwards=0 and rfc7332ValidateMaxForwards enabled.

Impact: If the SBC receives the PRACK request with Max-Forwards header value as zero, it was not rejecting it with a 483 error response.

Root Cause: The part of the code was missed in the code merge from 7.2 to the main branch.

Steps to Replicate:

1. Send PRACK with Max-Forwards 0
2. Verified, the SBC is rejecting it with 483 Error response

Platform/Feature: SBC

The SBC fails to play tone when the 180 is received on the SDP with PEM:inactive or 180 is received without an SDP.

Impact: The SBC fails to play tone when the 180 is received on the SDP with PEM:inactive or 180 is received without an SDP.

Root Cause: When the 180 without the SDP PEM is inactive, the SBC was not starting the immediate tone play.

Steps to Replicate:

1. UAC sends an Invite with AMR.
2. UAS sends an 180 with sdp AMR with PEM:inactive.
3. UAS sends an 200 Ok without the SDP.

Platform/Feature: SBC

The Ike Process dumped core in 3:1 MSBC setup.

Impact: The Ike Process Sys Dump's, the CDC is configured after switch over occurs for N;1.

Root Cause: This is a missing code that is required for N:1 support in IKE for CDC configuration. IkeCsvProcSubChange() needs to be updated to fix this.

Steps to Replicate:

Issue must be reproduced with the following step.
1. Create CDC config in N:1.
2. Switch over any instance.
3. Modify CDC configuration.

Platform/Feature: SBC

MS Teams put on a call flow on hold/resume then transferred causes the SCM to crash.

Impact: When music on hold is used in the deployment and a call is put on hold/resumed and then transferred causes the SBC to coredump in the SCM process.

Root Cause: The SCM process was de-referencing a null pointer.

Steps to Replicate: With music on hold is used in the deployment and a call is put on hold/resumed and then transferred.

Platform/Feature: SBC

Fix the double free scenario in a NAT and multicast scenario.

Impact: There will be random SWe_NP core when either the NAT is enabled or the LI is enabled at peak loads.

Root Cause: There was a double free of MBUF pointer, which can cause corruption.

Steps to Replicate: Run calls with LI or NAT enabled at peak load.

Platform/Feature: SBC

The SBC is sending BYE towards the UAC upon receiving a ACK when the SBC plays tone due to the 180 without a SDP and 200 with the SDP is received from UAS; the delayedRBT for 180 without the SDP is configured.

Impact: The SBC is sending BYE towards the UAC upon receiving a ACK when the SBC plays tone due to the 180 without a SDP and 200 with the SDP is received from UAS; the delayedRBT for 180 without the SDP is configured.

Root Cause: RBT Monitoring must not occur after the 200ok is received. In the problem scenario, it was observed that the SBC was going for the RTP Monitoring after the connection is received as a result there was issue in the NRMA activation, which the SBC was sending BYE

Steps to Replicate:

1) Below tone criteria must be configured on ingress TG.
180 without SDP, occurence=first, delayedRBT

2) PEM must be supported on ingress and egress TG's.

Platform/Feature: SBC

The SIP Domain missing in the FROM header after an upgrade.

Impact: The DM rule for FROM Uri is not working.

Root Cause: The issue was SBX-85711 to treat FROM Uri is specific for RewriteIdentity only.

Steps to Replicate: Configure the PSX for FROM Uri, and a SIP-SIP call. Verify the FROM header is picking up the DM rule of the FROM Uri.

Platform/Feature: SBC

Portfix SBX-93469: The DFW1-CASBC-02 Box A SCMP had a coredump. (Originated in release 7.2.3).

Impact: The DFW1-CASBC-02 box A crashed, and switched over to box B, causing a coredump.

Root Cause: Enable the SDP transparency and directMediaAllow a 18x response from peer may cause core due to access invalid address.

Steps to Replicate: Disable either the SDP transparency or the directMediaAllow.

Platform/Feature: SBC

Portfix SBX-93518: Field values of Call Estimates and SWe Processor Capacity are not getting populated in the SBC's configured with an OAM. (Originated in release 8.2.0).

Impact: This issue occurred when the SBC was connected to an OAM node, so the sweCapacityEstimate and sweProcessorCapacity fields were not showing in the CLI after consecutive reboots.

Root Cause: When the application comes up the first time, the firstEstimateDoneMarker.txt and indexMarker files get created under /opt/sonus/conf/swe/capacity estimates, so the SBC was not populating the values of sweCapacityEstimate and sweProcessorCapacity in the CLI after consecutive reboots.

Steps to Replicate:

Install an OAM connected to the SBC, and test the given cases listed below:

1. Login to CLI and check below given CLI commands:

   show table system sweCapacityEstimate
   show table system sweProcessorCapacity

2. Reboot the SBC instance and once the application comes up check again above given CLI commands.

In both the cases above, the values are populated in the CLI.

Platform/Feature: SBC

Unable to show the SSBC-Oam due to an NP issue (LCA failed due to NP crashes).

Impact: "--legacy-mem" EAL switches the mandates huge pages to be pre-reserved on all the NUMA nodes as per the requirement. If any node does not have enough huge pages and memory is being allocated from that node, it will fail.instance with the NUMA node1 on NUMA node 0.

Root Cause: The instance was spawned with NUMA node1 on NUMA node 0 with the huge pages was not allocated.

Steps to Replicate:

1.Single numa VM with 4 vCPU, tested index. index is not varying from previous index values.
2.Single numa VM with 4 vCPU, tested bring-up of instance.
3.With dual numa VM with 4 vCPU, tested index. index is not varying from previous index values.
4.Dual numa VM with 4 vCPU, tested bring-up of instance.

Platform/Feature: SBC

Portfix SBX-93219: The Plain-text passwords appear in CSAR for the VNFM. (Originated in release 8.2.0).

Impact: Plain-text passwords appear in the CSAR file. If the CSAR is unzipped, the contents can be seen in the Files/*cloud-initdata.cfg file, in lines containing "usermod".

Root Cause: When the feature was added to remove passwords from HEAT orchestrations in release 7.2, the VNFM code was under development in a side-branch, and the plain-text passwords were added as a work-around.

Steps to Replicate: Download the latest version of the createCsarVnfm.py and the template from artifactory.

Platform/Feature: SBC

The SBC Memory High alerts.

Impact: When the LRBT is configured and egress endpoint sends the 183 Session Progress with SDP followed by a 180 Ringing, the SCMP may leak memory.

Root Cause: The SCM Process does not free up the NRMA SESSION DESCRIPTOR structure.

Steps to Replicate:

1. Reproduce issue.
LRTB should be enabled by creating toneAndAnnouncementProfile profile and it should be applied on SIP TG

INVITE –--> [SBC] ---> INVITE
183 with SDP <---- <---- 183 with SDP
180 w/o SDP <---- <---- 180 w/o SDP
SBC starts LRBT.
200 with modified SDP <---- <---- 200 with modified SDP.

Run bulk calls with valgrind / check VM usage of ScmProcess.

2. Verify issue.
Same scenario as mentioned in 1.
Verify that there is no SCMP leak.

Platform/Feature: SBC

PortFix SBX-91224: The SBC is using the surrogate Registration hostPart as the target FQDN. (Originated in Release 7.2.2)

Platform/Feature: SBC

The code is modified to not over-write egress IpPeer fqdn(target route) with surrogate hostPart.

PortFix SBX-90867: Ssreq server has memory leaks, which can eat up virtual memory when there is call load via ssreq client. (Originated in Release 6.2.5)

Platform/Feature: SBC

PortFix SBX-90581: Mismatch in the response header transfer-encoding. (Originated in Release 7.2.2)

Platform/Feature: SBC

Getting the IP peer current statistics for an individual IP peer was not working.
The issue is reproduced when multiple IP peers are configured under the same zone.

Platform/Feature: SBC

PortFix SBX-88070: In case a call to sonusPeerUpload.expect is made and co-incidentally the peer goes down, there is a wait time for the SCP connection, resulting in the application healthcheck timing out after 10 seconds. This causes the application to crash.

Platform/Feature: SBC

PortFix SBX-90876: The GENcom client sends an error 481 for a call park retrieval INVITE because of an incorrect tag in the Replaces header sent by the SBC. (Originated in Release 7.2.2)

Platform/Feature: SBC

A bug in the GW Signaling code can cause a core when the GW Signaling Links are bouncing. 

Platform/Feature: SBC

PortFix SBX-90323: Subscribe relay refresh, the R-URI must be based from the last Contact received if the first route set has an lr parameter. (Originated in Release 7.2.2)

Platform/Feature: SBC

PortFix SBX-90415: Currently, all filters are not displayed for the tables such as Call Detail Status, Call Media Status, and Call Resource Detail Status. (Originated in Release 7.2.2)

Platform/Feature: SBC

PortFix SBX-85820: The CDR records are broken into multiple syslog messages. (Originated in Release 7.2.2)

Platform/Feature: SBC

PortFix SBX-90180: When the SIPT library was returning a DISCARD_MSG event to SIPSG while trying to send out a message, it resulted in the call being released if the MIME disposition was required. (Originated in Release 7.2.2)

Platform/Feature: SBC

PortFix SBX-90250: When "show status addressContext <addressContext_name> ipsec ipsecSaStatistics" "show status addressContext <addressContext_name> ipsec ipsecSaStatus" commands are run and IP Sec is configured, the IKE Process will leak memory. (Originated in Release 6.2.4)

Platform/Feature: SBC: IPSec, SIP

PortFix SBX-87342: Issue was observed where in a long load run, few 503 responses are seen from the SBC. (Originated in Release 7.2.2)

Platform/Feature: SBC

PortFix SBX-90088: NOTIFY is rejected with an error 489 Bad Event after a double switchover. (Originated in Release 7.2.2)

Platform/Feature: SBC

PortFix SBX-86486: ISBC does not span across multiple NUMA nodes and the process of spanning the NUMA nodes is handled incorrectly, causing the SWe_NP to fail when launching. (Originated in Release 7.2.1)

Platform/Feature: SBC

The SWe SBC software enforces I-SBC instances to run only with a single vNUMA node in order to achieve deterministic performance. The SWe SBC VM having > 8 vCPUs hosted on a dual-socket physical server with VMware ESXi software must follow the steps below to correct the vNUMA topology before upgrading to the latest SWe SBC software: 

1. Check ‘Number of virtual sockets’ field. It must be set to 1. 
2. Check ‘numa.nodeAffinity’ settings on the VM. It must be either 0 or 1 based on which NUMA node the PKT ports are connected to. The following command on ESXi host is used to check PKT port NUMA affinity: 
                   vsish -e get /net/pNics/<PKT port name - vmnicX>/properties | grep "NUMA" 
    If any of the settings above require modification, follow the steps below on the SWe SBC HA system: 
3. Shutdown the standby instance. 
4. Set ‘number of virtual sockets’ field under [Edit settings->Hardware->CPUs->Number of virtual sockets] to 1 if it is not already set and adjust ‘number of cores per virtual socket’ accordingly. ‘Number of cores per virtual socket’ field must be made equal to the total number of vCPUs on the VM. 
5. If ‘numa.nodeAffinity’ settings are missing, add the following rows: 
   numa.autosize.once = FALSE 
   numa.nodeAffinity’ = 0 or 1 (based on PKT port NIC affinity) 
   On ESXi 6.5 and later releases, vSphere web client is used to add the rows above under Edit settings->VM options-> configuration parameters -> add parameters; 
   On ESXi 6.0 and previous releases, it is added under Edit > Advanced->general ->configuration parameters -> add rows using the vSphere client. 
6. Power-on standby instance. 
7. Once standby instance is up and running, perform a manual switchover through the CLI and repeat the steps above to modify the ‘number of virtual sockets’ , ‘numa.nodeAffinity’ and ‘numa.autosize.once’ settings. 

The test call status was not being propagated to the SIPSG from the SIPFE for all messages. As a result, test calls were being treated as a non-test call and when trunk group was disabled, the call resulted in a failure.

Platform/Feature: SBC

PortFix SBX-88989: R-URI userpart is incorrect when the To header Transparency is on with the registration. (Originated in Release 7.2.2)

Platform/Feature: SBC

NAPT is not learning because of a delay in the media being received. NAPT is adapted for 1sec only for a re-INVITE and after that, the previously taught address is returned to NRMA (which does not work in this case. As far as the end changes, it is for the IP:PORT).

Platform/Feature: SBC

A possible memory leak occurs when the parameter rewriteIdentities is enabled on an SIP trunk group.

Platform/Feature: SBC

If the binding to the radius socket has failed, the Enm Process becomes cored.

Platform/Feature: SBC

The Hostname, which needs to be modified, is missing a length check and must directly replace with an Egress SipSigPort IP. 

Platform/Feature: SBC

The enhancement to add the XrmRedSecMonSend() Debug logs must be logged into a trace log as well.

Platform/Feature: SBC

The SBC replaces the custom EMA SSL certificate with a self-signed certificate during an upgrade.

Platform/Feature: SBC

The SNMP v3 does not work after an upgrade/restore.

Platform/Feature: SBC

DSP card present status is not updated if the card is administratively disabled. 

Platform/Feature: SBC: Platform

False positives are thrown by AIDE.

Platform/Feature: SBC: Platform

200 OK is not being sent for a call HOLD when the sdpAttributeRelay is enabled on the Trunk Group.

Platform/Feature: SBC

If a name change operation is performed to swap any two system names, CE name or peer CE name, then post-operation, the SBC application may fail to start.

Platform/Feature: SBC

Token load option not loading values into the template. No action triggered even after click on Token load.

Platform/Feature: SBC

Pathcheck process currently supports 32 DNS records whereas the DNS client supports 100. There was a mismatch and because of the mismatch of clients, the pathcheck process crash was seen when there are more than 32 records.

Platform/Feature: SBC

In the case of status commands executed from the CLI, a request is sent to both active and standby nodes. An LVM running on active and standby nodes compares the CE name configured in the LDG with a server name and returns stats only for LDGs that are configured on that CE. However, there is no similar check in the case of a PF stat. Without the check for a PF stat,the statistics displayed for LDGs configured on standby node was not correct.

Platform/Feature: SBC

On the CLI port switch over on a packet interface with random connectivity loss is observed for few seconds for other interfaces.

Platform/Feature: SBC

The SWe_NP thread hang was observed on the packet port cable pull to trigger a port switch over.

Platform/Feature: SBC

The SBC Headend cored while importing a configuration script. On the Openstack systems where the SBC is getting deployed, there cannot be any CPU over-subscription.

Platform/Feature: SBC

When an incoming INVITE message does not have the INFO in the Allow header and call flow has transcoded free transparency, the SBC sends INFO to the endpoint even when the endpoints to do not support it.

Platform/Feature: SBC

Portfix SBX-88276: The Rollover Type filter for the Type Admin List does not work on the SBC Manager when ‘Repetitive’ is selected. (Originated in release 6.2.4).

Platform/Feature: SBC

After an upgrade, the pre-upgrade shadow file copy is available in /home/admin/shadow.preUpgrade, which is not needed and must be removed.

Platform/Feature: SBC

Portfix SBX-65013: The SBC accesses an invalid address (optional array) in the cacheMsg. (Originated in release 5.1.5)

Platform/Feature: SBC

When the SBC was launched with attached cinder volume, the SBC came up failed due to a failure to mount the volume, as volume was not detected by the instance.

Platform/Feature: SBC

When there is an SMM teardown on early dialog operation, the SBC adds an SDP in a CANCEL option.

Platform/Feature: SBC

The SMM Teardown functionality does not wait for the PRACK transaction to complete, if anything is pending before tearing down the call.

Platform/Feature: SBC

The CDR connection time outs when the connection greater than 127 seconds are not honored, as the TCP sessions times out after 127 seconds.

Platform/Feature: SBC