SBC Core 07.02.05R003 Release Notes

Portfix SBX-105961: The SBC reinvite with sendonly causing one-way audio.

Impact: The SBC unexpectedly send out reInvite sendonly when relay DPM is disabled.

Root Cause: There was an internal logical error to queue the sdp on ingress when egress send 18x (sendonly)

Steps to Replicate: 

1. Enable minimize and disable relay DPM on ingress.
2. A call B, B answer 183 (sendrecv), 183 (sendonly), 183 (sendrecv)...200 (sendrecv).

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

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

The call drops when being placed on hold - IPV6.

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

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

Steps to Replicate: 

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

Check for "anonymous.invalid" and if the phrase is present, consider it as call hold and avoid going for DNS resolution to address the issue.

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

The SCM process core dumped on the SIGABRT.

Impact: The SCM has cored due to a memory corruption issue.

Root Cause: The SCM core is the result of a memory corruption caused by a function that is overwriting the end of the buffer that it allocated.
The root cause is that a bad pointer is being passed into this function. This pointer points to memory that had been previously freed without clearing the field that points to it.

Steps to Replicate: This issue is not reproducible because there is a race condition that contributes to it.

In order for this issue to cause a core, the memory that had been freed would also have to have been immediately re-allocated by the function that is copying past the end of it's buffer. We cannot predict when this memory will be re-allocated and therefore this issue is not reproducible.

The code is modified so there is no memory freed and then leaves around a pointer to this free memory.

This prevents us from passing a bad pointer into a function that would have attempted to copy from this invalid address.

Workaround: This issue will only happen when the customer is running calls that require registration. The registration must have at least one uri parameter (ex: transport) in both to and from header.
But, even in this scenario, most customer will probably not hit this core.

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

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

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

The SBC pick up the wrong leg.

Steps to Replicate: 

1. A to B call
2. B to C call
3. B attempted to bridge A and C together, the SBC is configured to relay the REFER with Replaces. The SBC modified the Replaces with the correct Call-ID and tags
4. The proxy looped the REFER back to the SBC and the SBC relayed it. This time, the SBC modified the Replaces parameter with a wrong dialog ID.

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

Workaround: None.

There were various display issues related to media port range modifications.

Impact: Issue 1,2,3: The CLI display of mediaPortRangeUnassigned to TGs was not regulated by the system media port range setting, causing the mediaPortRangeUnassigned CLI command displaying the wrong ports.

Issue 4: If the basePorts for different TGs are the same in a same zone, their maxPorts will be added up in CLI display of mediaPortRangeAssigned. tcpPortRangeAssigned has the same problem.

Root Cause: Issue 1,2,3: The root cause was that the SBC had not considered the system media port range setting as restriction when calculating unassigned ports.

Issue 4: The root cause was that assigned media port range map had not been indexed by TG, but by basePort had been a mistake.

Steps to Replicate: While working on the SBC CLI

1. Show configuration details system media mediaPortRange
2. Show table addressContext addressContextName ipInterfaceGroup IG_name mediaPortRangeUnassigned
3. Modify configuration details system media mediaPortRange to much smaller range.
4. Repeat step 2, to make sure that mediaPortRangeUnassigned gives ports always within the range of "show configuration details system media mediaPortRange"
5. Create multiple TGs in each zone. Assign mediaPortRanges to these TGs. Some range with the same basePort in the same zone. Some with different basePorts in the same zone.
6. Repeat step 2 to make sure that mediaPortRangeUnassigned gives ports always within the range of "show configuration details system media mediaPortRange"
7. Show table addressContext addressContextName ipInterfaceGroup IG_name mediaPortRangeByTGNameAssigned / mediaPortRangeUnassigned. Ensure that the outputs are correct.
8. Repeat steps 2-7 with tcpPortRangeByTGNameAssigned / tcpPortRangeUnassigned
9. Repeat the display steps above in EMA.

The code is modified for the following issues:

1. Added system wide media port range into SBC SIPSG cache, so that the restriction will be checked before display of mediaPortRangeUnassigned.
2. Changed the map of the assigned mediaPortRange to indexed by TG name, not basePort any more.
   Therefore, the CLI/EMA syntax becomes mediaPortRangeByTGNameAssigned/ tcpPortRangeByTGNameAssigned, instead of mediaPortRangeAssigned / tcpPortRangeAssigned.

Workaround: It is a display issue, does not impact call.

The MCF was sent back to the ingress as MPS.

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

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

Steps to Replicate: This can only be reproduced with a customer data.

The code is modified to accommodate such larger bursts.

Workaround: None.

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

Impact: Standby is not allowed to join cluster and fails to start

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

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

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

Workaround: A complete outage is required in order to restart the active server.

Portfix SBX-98177: Issue with the SBC 7000 TCP window size. 

Impact: Add the CLI support to set kernel parameter net.ipv4.tcp_window_scaling.

Root Cause: In certain SBC deployment scenarios (a large number of devices running SIP-TLS), tcp_window_scaling caused small TCP window size.

In such cases, the operator had to use a command to disable tcp_window_scaling on each SBC node.

Steps to Replicate: 

(1). Show initial setting for tcp_window_scaling on both active and standby 
# cat /proc/sys/net/ipv4/tcp_window_scaling
1
# cat /proc/sys/net/ipv4/tcp_window_scaling
1

(2). Use CLI to change the kernel param value and display the changed value on both active and standby.
set system admin SBCSWE01 kernelParams tcpWindowScaling disable commit
Commit complete.

# cat /proc/sys/net/ipv4/tcp_window_scaling
0

# cat /proc/sys/net/ipv4/tcp_window_scaling
0

The code is modified to fix the issue and the Linux command is no longer needed with the modified code.

Workaround: Use the Linux command to set the kernel parameter on both active and standby.

# sysctl net.ipv4.tcp_window_scaling
1
# sysctl -w net.ipv4.tcp_window_scaling=0
# sysctl net.ipv4.tcp_window_scaling
1
# sysctl -w net.ipv4.tcp_window_scaling=0

To be persistent across the SBC restart and system reboot, use the Linux the following shell command on both active and standby.
# echo "net.ipv4.tcp_window_scaling=0" >> /etc/sysctl.conf
# echo "net.ipv4.tcp_window_scaling=0" >> /etc/sysctl.conf

The code is modified to disable the Path MTU Discovery by setting kernel parameter net.ipv4.ip_no_pmtu_disc to 2. When set to 2, the DF bit is set to 0 for the transmitted packets on every created socket. The configuration parameter is "systerm admin <name of system> kernelParams ipNoPmtuDisc".

Workaround: The workaround is a hack. It can be used as a one time test only. The hack will not survive Linux reboots.
1. Make changes on the current Standby (assuming SBC1 is currently active, and SBC2 is currently standby)
[root@SBC2 ~]# date; cat /proc/sys/net/ipv4/ip_no_pmtu_disc
[root@SBC2 ~]# date; echo “2” > cat /proc/sys/net/ipv4/ip_no_pmtu_disc
[root@SBC2 ~]# date; sbxrestart
2. Wait until the SBC is up and synched. Ensure the p_no_pmtu_disc is set to 2.
[root@SBC2 ~]# date; sbxstatus | tail -4
[root@SBC2 ~]# cat /proc/sys/net/ipv4/ip_no_pmtu_disc
2
[root@SBC2 ~]#
3. Make changes on the current Active.
[root@SBC1 ~]# date; cat /proc/sys/net/ipv4/ip_no_pmtu_disc
[root@SBC1 ~]# date; echo “2” > cat /proc/sys/net/ipv4/ip_no_pmtu_disc
[root@SBC1 ~]# date; sbxrestart
4. Wait until the SBC is up and synched. Ensure the p_no_pmtu_disc is set to 2.
[root@SBC1 ~]# date; sbxstatus | tail -4
[root@SBC1 ~]# cat /proc/sys/net/ipv4/ip_no_pmtu_disc
2
[root@SBC1 ~]#
5. May perform a switchover to make the SBC to be active.
6. Run customer tests.

Portfix SBX-102837: The SipSignalingPorts was listed as OutOfService after a switchover.

Impact: The SIP sigPorts were stuck in OOS after a switchover.

Root Cause: The operator had a network/pkt port issue, on one of their HA nodes, that caused pkt port(s) to bounce randomly, that is, the pkt port went DOWN and came back UP within 2 to 3 seconds. The operator has been keeping that node as a standby node. They also have link detection enabled for pkt port(s) and have around 100 LIFs per pkt port, one per SIP SIGPORT. When the pkt port went down, the NRS delays the port down event processing for 2 seconds to allow link failure detection to be ready and also to avoid the race condition between NRS and LVM. When the 2 second delay timer is up, the NRS starts to take down affected LIFs and notifies local SIPCM and SIPFE so the operator can take down affected SIP SIGPORTs.

In SIPCM, all the sockets on the affected sigPort are put in a delete pending table and starts a 1 tick timer. Then the socket(s) is being deleted after 1 tick timer is up.

When pkt port came back up, NRS processes the event with no delay and notifies SIPCM and SIPFE as well. Since there are around 100 LIFs, there were many messages exchanges between NRS/XRM/SIPCM/SIPFE. NRS LIF FSM has the mechanism in place to handle the timing issue and LIFs were all back in service. But SIPCM failed to activate some SIP SIGPORT(s) while binding the socket(s). These error messages indicated that SIPCM tried to activate the SIGPORT while it was still pending delete. Therefore SIGPORT got stuck in OOS(broken state) in both SIPCM and SIPFE on standby node. If there was a switchover happened later, user would then noticed one or more SIGPORTs were OOS. They have to manually bounce those SIGPORTs to bring them back in service.

Steps to Replicate: The nature of the problem was the timing caused race condition. There is no proper way to re-create/verify the fixes. 

The code is modified:

1. To introduce a new 1 tick timer in SIPCM_DATA_STR, activateRetryTimerId.
2. So if sigPort is found in the table, then start the 1 tick timer. When the timer is up, SipCmActivateCallSigPort() is invoked again. Once the sigPort is activated successfully, the SIPCM notifies the SIPFE as usual.

Workaround: N/A

The DSP Threshold setting is not generating a trap on SBC5400.

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

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

Steps to Replicate: 

1. Provision the threshold levels:
   set oam traps dspAdmin dspAvailabilityTrap g729Threshold 40
   set oam traps dspAdmin dspAvailabilityTrap g726Threshold 60
   set oam traps dspAdmin dspAvailabilityTrap g711PacketThreshold 80
   commit set oam traps admin sonusSbxDspAvailG729OnSetCrossThresholdNotification state enabled
   commit
   set oam traps admin sonusSbxDspAvailG729AbateCrossThresholdNotification state enabled
   commit
   set oam traps admin sonusSbxDspAvailG726AbateCrossThresholdNotification state enabled
   commit
   set oam traps admin sonusSbxDspAvailG726OnSetCrossThresholdNotification state enabled
   commit
   set oam traps admin sonusSbxDspAvailG711OnSetCrossThresholdNotification state enabled
   commit
   set oam traps admin sonusSbxDspAvailG711PacketAbateCrossThresholdNotification state enabled
   commit
2. Configure the trap target: set oam snmp trapTarget EMS160 ipAddress 10.xxx.xx.xxx port 162 trapType v2 state enabled commit
3. Limit the compression resources to make the issue readily occur: set system mediaProfile tone 98 compression 2 commit
4. Perform transcoded (e.g. G711 to G729) calls that exceed threshold limits, and verify that onset traps are sent to the trap target.
5. Clear the transcoded calls, and see abate traps are sent to the trap target.

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

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

Workaround: N/A

The RE-REGISTAR was shorter than 3600 secs due to a child AoR. 

Impact: When the 200 OK response to REGISTER request contains a P-Associated-URI
header, the SBC creates a child AOR and forwards all REGISTER refresh requests to the registrar (effectively disabling the SBC fast refresh response).

Root Cause: The creation of child AORs cause all REGISTER refresh requests to be sent to the registrar (effectively disabling the SBC fast refresh response).

Steps to Replicate: 

1. Configure the SBC to perform registration.
2. The 200 OK response to REGISTER request contains a P-ASSOCIATED-URI header.
3. In the error case, the refresh REGISTER requests are all forwarded to the registrar.

Removed the child AOR check from SipRaRegisterRequestCompletedAorNfy(), permitting the SBC to send fast refresh responses.

Workaround: N/A

SM Process core on the Server.

Impact: The SM Process crashed while executing the "show table system syncStatus" command.

Root Cause: The shell script used to get the Oracle sync status - PolicyDBSyncStatus.sh - did not return within 10 seconds, causing a healthcheck timeout that caused the coredump.

Steps to Replicate: This problem is not reproducible.

Disable heathchecks while fetching the syncStatus to address the issue.

Workaround: None.

Portfix SBX-103273: Dual NUMA support in the SWe SBC.

Impact: Multiple NUMA were not allowed in general (except few cases).

Root Cause: A restriction was imposed not to allow multiple NUMA in HostCheck.

Steps to Replicate: 

1. Configure a KVM instance with dual NUMA and install in Non-Gold/Non-GPU setup.
2. Let it come in default traffic profile.
3. Verify that the SBC would come up fine without any HostCheck errors.

The code is modified to allow multiple NUMA in general, irrespective of personality and profile.

Workaround: No workaround. Need to use correct build.

Portfix SBX-96649: Failover due to a SAM Process core.

Impact: There were reports of a SAM Process crash stack indicating a Cave Creek QAT driver API may have caused memory segmentation, causing a switchover on the SBC7000 while verifying a TLS client's certificates during a TLS handshake.

Root Cause: Incompatible third-party QAT crypto driver with the current OpenSSL version, Linux kernel, and cipher suites was used in the current certificates.

Steps to Replicate: After an App installation or an Upgrade, ensure that the QAT engine is no longer used by the SIMCM (SAM Process) by checking DBG log.

Example: The following DBG message should be seen:
087 06232020 062948.762154:1.01.00.00609.MAJOR .SIPCM: *Dynamic engine not supported

Due to Cave Creek QAT and its driver being End-of-Life and improved OpenSSL performance in RSA key operations, use the OpenSSL optimization in the RSA key operations to support TLS handshake. The QAT crypto engine is no longer used by the SAM Process and IkeProcess on the SBC7000 and SBC5400.

Workaround: None.

Portfix SBX-103763: The upgradeSBX.properties causes the EMA to report a presistent upgrade in progress.

Impact: The upgrade is completed but the Platform Manager Install/Upgrade screen gets stuck on the previous upgrade and cannot perform the new upgrade operation.

Root Cause: The issue is being faced due to the SBC upgrade steps as part of SBX-56893 Jira in 6.1.0. Whenever the SBC is upgraded from 6.0.x to 8.2.x, Design will see the issue because there are different steps in 6.0.x and 8.2.x that is causing the issue. When upgading the SBC using 6.0.x code that has the old upgrade steps, once the pre install check step is executed, the PM API updates the upgradeSBX.properties file with next step(INSTALL_DB), the SBC goes for reboot and platform manager code gets replaced with upgraded version, which is 8.2.x.

Currently, the PM API reads upgradeSBX.properties file to read the steps value that is in INSTALL_DB and match the check but in 8.2.x PM code. There is no INSTALL_DB check in the PM code and because of that, we are unable to update the upgradeSBX.properties file with next steps. Once the upgrade gets complete and PM code updates upgradeSBX.properties file with finished as steps, we move the upgradeSBX.properties file into upgradeSBX.properties.1, which is not occurring, and the Platform Manager UI is unable to mark as complete, getting stuck on install/upgrade screen with the previous upgrade.

Steps to Replicate: 

1. The ISO/app installs the SBC 6.0.0F6 on a HW box. It was installed as a standby SBC on a SBC5110.
2. Go to EMA Administration > System Administration > Software Install/Upgrade and start an offline upgrade. Leave the browser alone, do not click anywhere in the EMA GUI once the upgrade has started.

The code is modified to handle the INSTALL_DB step check to mark the upgrade as complete from the Platform Manager UI.

Workaround: To perform the upgrade operation again, Ribbon must delete the upgradeSBX.properties file from the SBC.

The SBC SWe 8.2.0F1 duplicates audio from call B to call A.

Impact: If the CN is not negotiated for G711 codec and remote peer still sends the CN packets that match default CN payload type (13), then the user on other end may hear cross talk audio of completely unrelated channel or may hear their own audio.

Root Cause: When a g711 side does not negotiate CN in signaling, the DSP does not initialize Comfort Noise Generation object. However, if a remote peer still sends CN packet that matches the g711 SID payload type configured in PSP (default 13), DSP accepts the packet. It processes that CN packet incorrectly and as a result uses stale voice buffer which happens to be of another channel. This continues until the next voice packet for that channel arrives. As a result, cross talk audio is observed from other calls during a silence period. In some cases, the user may hear their own audio also and that is different manifestation of the same problem. This issue is specific to the SWe.

Steps to Replicate: 

1. Run a CN that is not negotiated for G711 codec.
2. Send a default remote peer CN packets that matches the default CN payload type (13).
3. The user on other end may hear cross talk audio of completely unrelated channel and hear the user's own audio.

The code is modified to initialize the comfort noise object even though the CN is not negotiated and processes the CN packets correctly.

Workaround: 

1.Change the default payload type of comfort noise from 13 to something else (say 15) in PSP of peer that is sending CN packets. This will make DSP drop CN packets because payload type will not match.

PSP configuration:
show configuration profiles media packetServiceProfile G711_NONE_NONE_NONE
..
silenceInsertionDescriptor {
g711SidRtpPayloadType 13;
heartbeat enable;
}

2. Enable silence suppression on PSP of peer that is sending CN packets and keep CN payload type that matches with CN payload type.

The DBG logs in the 7.2.4R0 SBCs filling up with the T38 logs.

Impact: When the call trace is enabled, the T38 messages are logged in a .DBG file. However, even after a call trace is disabled, T38 log messages continue to appear in .DBG file.

Root Cause: A gevelobal variable to set t38 log messages was set for call traces but never reset.

Steps to Replicate: 

1. Enable call tracing and make a T38 fax call.
   See that .DBG file has T38 log messages.
2. Disable call tracing and make a T38 fax call.
   T38 log messages do not appear in .DBG file.

The code is modified so after the call tracing is disabled, T38 log messages will not appear in .DBG file.

Workaround: Use 'unhide debug' command to disable T38 log message after call tracing is no longer needed.
> request sbx drm debug command "dspdebugt38 state disable"

Portfix SBX-103561 (Originated in Release 8.2.4) The tgrp parameter was not passing transparently when the SIP in the core is enabled.

Impact: SipCore calls are passing the wrong tgrp parameter value.

Root Cause: There was missing logic to support SipCore.

Steps to Replicate: 

1. Configure the SipCore feature. Both IPSP core and egress leg have "originating Trunk Group Options" set to "Include tgrp with IP address"
2. Make an SipCore call.

The code is modified to support the SipCore feature.

Workaround: N/A

The code is modified for the Allow message body QSIG Content-Type: multipart/mixed, Resource/Lists across GW-GW to address the issue.

Workaround: N/A

Portfix SBX-102470 (Originated in Release 9.1.0) Observed a SAM Process memory leak while running the TLS/SRTP load on an OpenStack 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 a SAM Process.
2. Run another 100,000 SIP-TLS sessions with Client Authentication, and observe the memory used by a SAM Process.
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: N/A

Portfix SBX-103939 (Originated in Release 9.2.0) The NAPT timer was not armed properly in MoH.

Impact: The NAPT timer did not start as NRMA requested.

Root Cause: The RTP flow mode was xmt-only. Then NRMA requested flow change to enable NAPT timer expiry because we have already learned source address. But the XRM did not start NAPT timer because it was a learning next request.

Steps to Replicate: The steps cannot be reproduced.

The code is modified to start NAPT timer for learning next if NRMA has set XRM_NAPT_MEDIA_NAPT_TIMER_ACT_ENAB.

Workaround: N/A

There was an incorrect license usage count for Encrypt license.

Impact: An incorrect Encrypt license was consuming for IPSEC/TLS calls.

Root Cause: For IPSEC, the SPD is configured with an IP prefix for localIpAddr and remoteIpAddr. But while comparing an IP address, the prefix length/subnet mask was not taken in to account. As a result, the IP comparison was failing, and in turn the license was not consuming for IPSEC calls.

For the TLS, the issue is observed in TEAMS calls only, When calls come, a specific internal flag was not setting, which the license was consuming.

Steps to Replicate: 

1. Run a PSTN to TEAMS call.
2. PSTN disconnects the call while TEAMS ringing.
   >>Encrypt counter got incremented as below each time when call is disconnected.

The code is modified to check the IP address prefix validation so that the IP address within the prefix is considered as an IPsec call and updates the internal flag, so that the request method is updated properly.

Workaround: N/A

Portfix SBX-102795 (Originated in Release 9.1.0) In the Asymmetric PRACK interworking, the configuration flag "Sdp100relIwkForPrack" behavior is not proper.

Impact: In a latemedia passthrough call, the SBC is not sending ACK for 200 OK when the Asymmetric PRACK Interworking features is used.

Root Cause: The SBC fails to relay 200 OK for an UPDATE in late media passthrough and reverse offer scenario. This issue is fixed but the given fix breaks the Asymmetric PRACK feature functionality.

Steps to Replicate: 

Configuration:
Set the flag lateMediaSupport to passthru on the ingress TG.
Enable 100rel Support on the ingress TG.
Enable the flag Sdp100relIwkForPrack on the egress TG.

set addressContext default zone <ZoneName> sipTrunkGroup <ING_TG_Name> media lateMediaSupport passthru
set addressContext default zone <ZoneName> sipTrunkGroup <ING_TG_Name> signaling rel100Support enabled.
set addressContext default zone <ZONEName> sipTrunkGroup <EGR_TG_Name> signaling Sdp100relIwkForPrack enabled.

Procedure:

1. UAC sends the Initial INTIVE request to the SBC without SDP and has 100rel in Require header.
2. UAS sends the 180 towards the SBC with no SDP after receiving offer less Invite.
3. UAC sends PRACK with SDP answer after receiving 180 with SDP offer.
4. UAS sends the 200 OK towards the SBC with the SDP offer.
5. UAC sends ACK after receiving 200 OK.

Expected Result:
The SBC should send ACK with SDP answer on the egress side.
After a re-negotiation, the media communication should be done as per final offer answer communication.

The code is modified to cover both scenarios. 

Workaround: N/A

Portfix SBX-103237 (Originated in Release 7.2.5) The peer is failing to choose proper leader/leadership algorithm while recovering from a splitbrain.

Impact: A restart of the primary node during a split-brain can cause the nodes to choose different leaders when the split-brain is resolved.

Root Cause: A restart during the split-brain may cause the node to revert to the default algorithm rather than using the enhanced leadership algorithm when coming out of split-brain.

Steps to Replicate: Execute the following scenario:
AA-SS >> AA & SA >> cause split-brain >> restarting AA >> recover split-brain >> AS-SA

The code is modified to properly maintain the agreed upon leadership algorithm so that the correct algorithm is utilized, even after a restart.

Workaround: N/A

Portfix SBX-98336 (Originated in Release 9.0.0) Memory changes for the PAI header userinfo modification for a transparency case.

Impact: When the PAI header userinfo is modified using DM/PM rule and also when transparency is enabled, the SBC is copying the userinfo from DM/PM rules into out-of-memory, if the DM/PM userinfo is longer than the ingress INVITE PAI userinfo.

Root Cause: The transparency buffer for PAI header is only allocated for the size of the ingress PAI userinfo. When the PSX returns DM/PM rule with larger number of characters in the userinfo, the SBC while copying it to the egress PAI transparency buffer, scribbles over the memory.

Steps to Replicate: 

1. Configure STI profile on the SBX and PSX.
2. Send an INVITE with PAI header and perform the STIR/SHAKEN signing/tagging.
3. Enable Privacy->Transparency configuration.
4. Configure DM/PM rule to change the PAI userinfo with a longer number of characters.

The code is modified by allocating a new memory block for the PAI userinfo and updating the PAI header pointer.

Workaround: N/A

The Out of Memory caused an SBC switchover.

Impact: Memory leaks when 3xx relay and reject 3xx on egress IPSP

Root Cause: Contact Headers in 3xx memory did not free properly.

Steps to Replicate: 

1. Enable 3xx relay and reject 3xx, trigger the SBC sends 503 to ingress.
2. A call B, B response 3xx with contact headers.
3. Or Enable 3xx relay and configure ingress "do not send 3xx", trigger SBC sends 503.
   

Ensure the memory of contact headers in 3xx are properly free when config to reject 3xx.

Workaround: Customer may using SMM to change the status 3xx to 503 instead.

Portfix SBX-103175 (Originated in Release 8.2.4) A large microflow profile was not getting enabled in the Custom Traffic Profile.

Impact: 

1. For a default profile, the max subs was always set to 256K.
2. For custom and standard traffic profiles, the micro flow count in NP resource was not proper.
3. There is limited support of 2M micro flows for standard profiles

Root Cause: 

1. The large micro flow support was not there for custom traffic profiles.
2. For standard and default traffic profiles, there was restricted/incomplete support of large micro flow that is made generic as part of this JIRA.

Steps to Replicate: 

1. Create a instance with 10GB memory and 16vpcu with default traffic profile. Check microflow limits using "/opt/sonus/bin/cpsi -d summary" command.
2. Increase the memory to 50GB memory and check microflow limits using "/opt/sonus/bin/cpsi -d summary" command.
3. Create a instance with 20GB memory and 16vpcu. Create and activate a custom traffic profile with access enabled in call mix. Check microflow limits using "/opt/sonus/bin/cpsi -d summary" command.

The code is modified to:

1. Introduce a new estimation parameter maxSubs where the micro flow count is decided and the NP hugepages is reserved.
2. Enable a large micro flow support for all standard/default profiles where mem > 48GB and vcpu_count >10.

Workaround: N/A

The "request sbx xrm debug command sec -stat gcid <gcid>" was not showing the enc and dec details on the SBC SWe.

Impact: This debug command in unhide section is not showing all the required fields populated in the SBC SWe.

Root Cause: The NP response is not framed in expected order to application layer.

Steps to Replicate: Run a SRTP call and the issue this debug command. The debug command does not show all the populated fields.

The code is modified so the NP Response is correctly framed in expected order to application layer.

Workaround: This debug command is to see SSN field value with RoC, all other details can be seen from show call mediastatus.

The SBC relays STUN packets in RTP streams on pass-thru calls (no transcoding); on RTP to SRTP calls, the relayed STUN packet causes the ROC to reset back to 0 and the remote peer discards the encrypted media packets.

Impact: When Non_RTP packets mixed/relayed in SRTP stream are sent out from the SBC, it was resulting in one way audio at the endpoints in longer duration calls.

Root Cause: These non-RTP packets relayed eg. STUN packet causes resetting of encryption ROC back to 0 on the SRTP stream sent out. This issue results in the remote peer discarding the encrypted media packet in long duration calls from the SBC, where ROC is expected to be non-zero.

Steps to Replicate: Run a SRTP passthrough call with media for more than 15 mins, with 10 uptime audio. Then send a non-RTP packet (STUN, UDP TL t.38) in that stream for pass-thru relay, and observe the media in that call.

The code is modified for Non-RTP packets to not mix with SRTP encryption/decryption processing, SRTP media stream ROC does not reset with these packets mixed, and endpoint will not have media issues in longer duration calls.

Workaround: If longer duration calls are expected to relay STUN messages as well, disabling the SRTP will solve media issue. But for secure reasons, if SRTP has to be enabled, there is no workaround for this.

Portfix SBX-85808 (Originated in Release 8.0.0) The SBC is not sending a DTMF telephonic event to SIPREC server when the CS is negotiated on a telephonic event.

Impact: The DTMF tones are not being sent to the SIPREC server.

Root Cause: The SBC was sending only one preferred codec and not the telephone event towards the SIPREC server. As a result, the telephone event are not being negotiated and not being sent to SIPREC server.

Steps to Replicate: Enable the SIPREC on the SBC, make a CS call with a telephone event and send the DTMF tones.

The code is modified to send all the negotiated codec towards the SRS server that also includes the DTMF.

Workaround: N/A

Portfix SBX-95919 (originated in Release 7.2): The Max Forward Header Support feature is not working for requests from terminating side.

Impact: The Max Forward Header Support feature is not working for requests from the terminating side. The SBC does not subtract 1 in the Max-Forwards header despite the rfc7332ValidateMaxForwards is set to enable.

Root Cause: This issue is caused when a BYE request that comes from the terminating side. Any other requests from the originating side are decreased correctly including the BYE request.
Handling the BYE from terminating side was not taken care of.

Steps to Replicate: Enable fc7332ValidateMaxForwards on both TG.

1. Initiate a call from A to B, B sends a 200 OK to connect the call.
2. B sends the Bye request. The SBC sends the Bye request to A.
   The Max forward header in the Bye is set to 70.
3. Check the Max forward SBC sends to A. The Max forward header should be decremented by one.

The code is modified so when BYE is received from the terminating side, decrease the max forward header by one.

Workaround: N/A

Portfix SBX-94762 (originated in Release 8.2.0): The basic Relay-Relay of RTCP for T140 is not working in the latest build.

Impact: The RTCP NAPT PORT learning alone is not working in the SWe.

Root Cause: RTCP NAPT PORT learning flags ports definitions endian mismatch in the SWeNP was not triggering the learning and causing drops.

Steps to Replicate: Run calls with RTCP NAPT port learning alone call flows and ensure the RTCP packets are learnt and relayed accordingly.

The code is modified in the SWeNP media flow processing to fix the issue.

Workaround: N/A

Portfix SBX-96484 (originated in Release 8.1.0): The MRFRM SIPSG standby CCB hash had multiple insert failures.

Impact: When there is hash insert failure, the case is not being handled properly.

Root Cause: There are a few major logs that came as part of load run that relates to the gcid hash insert failures in the MRFRM.

Steps to Replicate: Run a SBC call flow with 12 codecs with the GW signaling and configure the system in Sensitive mode.

The code is modified to perform a hash swap when there is hash collision.

Workaround: Run an MRF load and issue may be reproduced.

The DBG file was filling up with messages "SIPCM: *ThreadPool: messageSequence "

Impact: The DBG logs can be overrun with "SIPCM: *ThreadPool: messageSequence" messages.

Root Cause: The DBG logs can be overrun with "SIPCM: *ThreadPool: messageSequence" messages, when the double CRLF "pings" are received by the SBC over a UDP transport.

Steps to Replicate: Send double CRLF "pings" over UDP to the SBC.

The code is modified to properly dispose of double CRLF "pings" received by the SBC over the UDP.

Workaround: Inhibit the transmission (or reception) of Double CRLF "pings" over the UDP.

Portfix SBX-96323 (originated in Release 8.1.0): The version header is removed on the SBC even though the transparency was enabled.

Impact: When running an OOD message call flow with MIME Header and Transparency is enabled for MIME Header, the MIME Header is not going in the egress message.

Root Cause: The MIME header is ignored by the SIP Parser.

Steps to Replicate: Run an OOD Message call-flow with Mime header.

The code is modified to add MIME header as a Transparent header.

Workaround: Use the SMM Message Scope Variables to store and add it in the outgoing message.

Portfix SBX-98367 (originated in Release 8.1.0): The SBC lost connections to other SBCs.

Impact: The X710 SR-IOV PKT0 interface on the M-SBC stops receiving packets, resulting in connectivity loss with the SBC and other M-SBCs.

Root Cause: The default TX Free threshold setting for the DPDK X710 PMD holds up a larger number of packet buffers leading to buffer starvation and thereby stopping of packet rx on pkt0 port. The issue is particularly aggravated when the majority of calls have both legs on PKT0 and few calls have one leg on PKT1 and another on PKT0.

Steps to Replicate: 

1. Run calls with both media legs on the pkt0.
2. Run 100-200 calls with one media leg on pkt0 and another on pkt1.
3. Re-run calls with both legs on the pkt0.

The code is modified to prevent retaining a large number of packet buffers in the TX done queues.

Workaround: There is no guaranteed workaround, but enabling the LDG may help in reducing the chances of the reoccurrence of this issue.

Portfix SBX-100331 (originated in Release 8.2.1): After adding the second mgmt port in the 23vcpu I-SBC (in RHEV platform 8.2.1 build), pkt and the mgmt port messes up.

Impact: On adding extra management port in large instance without redundant PKT ports, the SWe_NP process crashes.

Root Cause: There was a bug in the code that pulled non-existent port id on adding extra management port resulting in crash.

Steps to Replicate:

1. Make a large instance >15vCPU(default profile) without redundant packet ports.
2. Add extra management port and reboot.

The code is modified so the polling of extra management interface properly manages large instances in the SWe_NP code.

Workaround: N/A

The From header wrongly impacted by the SMM.

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

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

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

There were logical error on the 2nd rule when try to reconstruct the uri header into generic header that adding duplicated generic parameters.

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

Portfix SBX-99321 (originated in Release 7.2.0S400): There is node resource congestion alarms after upgrading to 7.2S400.

Impact: Performing a time zone change from CLI can cause node resource congestion alarms in 7.2S400.

Root Cause: The problem was found to be caused due to a system daemon(cron) running in signaling group and exhausting signaling resources.

Details:
Whenever there is a timezone change, cron is restarted and when it is restarted from a process running in the SIG core(SM), cron gets scheduled in the SIG core. SIG cores are monitored for resource usage periodically and due to cron taking more resources while running cron jobs, the resource congestion alarms were getting raised by the SBC.

Steps to Replicate: 

1. Perform a timezone change from the CLI on SWE.
2. Note the pid of cron and check which cgroup it is apart of by running the following scripts:
   cat /cpusets/sig/tasks | grep `pidof cron`
   cat /cpusets/system/tasks | grep `pidof cron`

The code is modified so the scripts responsible for the timeZone change and cron restart are moved to the system cgroup.

Workaround:

1. Reboot the SBC after a timezone change, (or) 
2. Run below command to move cron to system cgroup:
   /usr/bin/cset proc -m -p `pidof cron` -t system --thread

A PRS process core occurred on the Standby Server.

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

Root Cause: The root problem was that the pkt2 on standby node was stuck in DOWN state due to possible network switch issue, while the pkt2 on active node was functioning as normal. All the activated XRESs selected on LIFs of the pkt2 were mirrored to standby and got inserted in the deferredXresList waiting for the standby pkt2 to be UP.

Then when one of those XRESs is reused for a different call and mirror to the standby node, that XRES may be stuck in the deferred XRESList because the deallocate request may have not been processed yet on the standby node. As a result, the PRS hit coredump was caused by the XRM accessing the NULL pointer inside of the XRES data structure.

Steps to Replicate: The SBC HA pair, active node has pkt ports all UP, and standby node has at least one of the pkt port DOWN.

Start with a fairly high call load, and ensure calls are picking LIFs of pkt1 on the active node. Also ensure XRES on pkt1 are being re-used.

Note: The standby pkt1 should stay DOWN all the time during the test.

The code is modified to correctly free the XRES in deferred XresList so that it can be re-used for the new call.

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

The SBC was adding an extra application/ISUP ACM content.

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

Root Cause: When the e2e Bye is enabled, 200 OK has duplicated the ISUP body.

Steps to Replicate:

1. Configure the isupMimeBodyRelay and e2e bye.
2. Run a sipi-sipi call, and the SBC sends 200 OK bye has duplicated isup body.

The code is modified so the SBC does not create an isup body internally for the e2e Bye and isupMimeBodyRelay.

Workaround: Disable the e2e Bye.

Both applications (iceSupport and SMM storeIPTG) coredumped.

Impact: The SMM drops an incoming call.

Root Cause: After a response failure to an invalid call, the SBC still tries to initiate a setup call. As a result, it accesses an invalid address.

Steps to Replicate: Configure the iceSupport, SMM storeIPTG, and an incoming call with the invalid candidate (no UDP).

The code is modified to add a address validation and not try to initiate a setup call if the call fails.

Workaround: N/A

Portfix SBX-99874 (originated in Release 7.2.2): A second INVITE with a REPLACES collects the wrong PSX route.

Impact: A second INVITE with REPLACES collects the wrong PSX route.

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

Steps to Replicate: 

1. A and B are connected.
2. C sends INVITE with REPLACES to replace A.
3. D sends INVITE with REPLACES to replace C.
4. D sends Re-INVITE with a=inactive.

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

Workaround: N/A

There was a back-to-back coredump on the Server.

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

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

This can happen 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 the parseError trace logging and then sending a INVITE that includes a badly formatted CallId, which is the maximum allowed size for a CallId:
"set global callTrace errorFilter errorType parseError"

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

Workaround: Disable the parseError tracing.

Portfix SBX-96001 (originated in Release 6.2.1): The SBC 7000 has the wrong value for call duration.

Impact: The call service duration (CDR field numbers 10 and 14) has wrong values causing a 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 such that the "callServiceEstTime" does not get overwritten once its recorded initially during the initial offer-answer.

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

There was a switchover with the PRS process coredumping.

Impact: The PRS process coredumped due to memory corruption.

Root Cause: Customer encountered a PRS process core due to the memory corruption that happened earlier in processing. The core is the after effect of earlier corruption.

Steps to Replicate: None.

The code is modified to avoid the core, and to collect more diagnostic data if a core happens again.

Workaround: N/A

Intermittently, the SBC SWe accesses the sipSigPort for sending the SIP messages to the core side.

Impact: The relay options with registration may route to the wrong Sip Signaling Port and causing call fails from AS to IAD.

Root Cause: When the IAD sends a registration arrive from the SSP1 and relay options from an other SSP2. Since the options from the SSP2 do not match with RCB from SSP1, the SBC treat the options from the AS and triggering invalid routing to the wrong destination.

Steps to Replicate: Configure the SSP1 and SSP2, and enable maskRcbPort. The registration from SSP1 succeeds. Options from the SSP2 will trigger a relay back to the IAD (not AS). Subsequent calls from AS may fail or refresh registration.

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

Workaround: Disable the maskRCBPort. Or use the SMM to make the SBC response to Options (not relay).

The dual system SCM process cores and causes a complete outage.

Impact: The SCM process may coredump during two stag SRTP calls.

Root Cause: The NULL pointer access caused the SCM process to coredump.

Steps to Replicate: The steps cannot be reproduced.

The code is modified to include additional NULL pointer protection to the SRTP licensing code.

Workaround: Disable the SRTP.

The eSBC  crashed.

Impact: The root cause has an incorrect initialization in the third party T.38 stack.

Root Cause: The issue occurs when Version 3 T.38 fax is enabled. In such a case, in case a CED 2100 Hz is sent by the SBC to G711 leg while it gets T.38 ANSAM packets from T.38 side, the DSP hardware stack can crash.

Steps to Replicate: The test setup to recreate this problem involves special SIPP scenarios and the SBC configuration.

The SBC is configured for the ingress as G711 and egress G711 with T.38 for Version 3.
Also configure the ingress PSP as transcode only and ensure that the codecs allowed for transcoding for ingress has G711 and egress has both G711 and T.38.

The code is modified by getting a third-party stack that has proper initializations and protection code to avoid a crash.

Workaround: N/A

An SCM process coredump occurred on the SBC in sensitive mode, while running a call flow with 12 codecs over a GW signaling call flow.

Impact:The SCM process experienced a coredump.

Root Cause: In the SgCondenseAudioWildcard, scenarios may occur where the audioEnd and audio1 have the same IP address.

Steps to Replicate: Run an SBC call flow with 12 codecs with the GW signaling and configure the system in sensitive mode.

The code is modified to remove the equal condition between audioEnd and audio1.

Workaround: Configure the SBC in normal mode.

Observed DSP coredumps and MAJOR logs on 7000 Platform while running ICM Scaling suite.

Impact: The DSP coredumps were observed during the switchover tests.

Root Cause: Certain variables used in the interrupt context were not protected while being modified outside the interrupt. This impacted the inter-core health-check logic at DSP and incorrectly led to error being reported, eventually leading to core-dump.

Steps to Replicate: HA Pair of fully loaded SBC-5100/5200/5110/5210/5400/7000

1. Run a transcode load.
2. Initiate a switchover.

The code is modified so the variables are protected from interruption.

Workaround: N/A

Portfix SBX-99020 (originated in Release 9.0.0): Observed Major logs with the error prints of 488 on the SBC 5210 platform while running direct media.

Impact: Calls stop working as the LIF bandwidth is not freed.

Root Cause: In case of a multi-stream direct media call with the last media stream as non-RTP stream, the SBC does not release the session bandwidth even when the call is released. This leads to a leakage in the interface bandwidth resulting in call failures after some time.

Steps to Replicate: Run direct media calls with multiple streams with last media stream as a non-RTP stream (BFCP, MSRP).

The code is modified to release the session bandwidth even when the last media stream is non RTP stream in a direct media call.

Workaround: N/A

A BYE message was sent to the wrong port.

Impact: The SBC does not update remote connection address when refresh INVITE is received from different port.

Root Cause: When the endpoint is registered over TLS initiating a call and after the call is established, the endpoint sends a refresh register from a modified port. When a refresh INVITE is sent with no SDP change, the SBC does not send BYE to a modified port when the call disconnects.

Steps to Replicate: 

1. Register endpoint over TLS.
2. Endpoint initiates a call, call gets connected.
3. Endpoint sends refresh register from modified port.
4. Endpoint sends refresh re-INVITE from modified port.
5. Called party disconnects the call.
6. Verify that the SBC sends BYE to modified port towards caller.

The code is modified to ensure the SBC updates the remote address when a refresh INVITE is received from a modified port.

Workaround: N/A

Portfix SBX-99791 (originated in Release 9.0.0): The AddressSanitizer detected a heap-use-after-free on the address 0x62a000396280 at pc 0x563d8352c45c bp 0x7f03c92740b0 sp 0x7f03c92740a8.

Impact: On the D-SBC setup, when disabling the signaling port used for the SBC to the M-SBC communication and then making further configuration changes it was resulting in an invalid memory read.

Root Cause: When the signaling port was disabled, the code was freeing up a list of sockets that were using the port. However, it did not set the primary socket pointer to be NULL when the associated socket memory was freed up. This resulted in an invalid read when trying to re-enable the signaling port.

Steps to Replicate: This issue is only highlighted in the lab when using ASAN enabled images and then disabling the signaling port and making further configuration changes.

The code is modified to ensure that the internal pointer to the primary socket used for the connection is set to NULL when the socket memory is released.

Workaround: Do not disable the signaling ports.

Portfix SBX-100650 (originated in Release 8.2.2): The INVITE with replaces failure for the G722 only call.

Impact: Originally, the SBC/GSX only supported a small subset of codecs, such as G711, G711_SILENCE_SUPPRESS, G723, G729A, G729AB, FAX_RELAY, G723A, G726. Then, additional codecs including ILBC/G722 were added in. When these new codecs were added, the SBC/GSX started to pass a flag to the PSX that is supporting the new codecs. This indicator bit is only being passed up when processing an INVITE and not when processing a REFER message. This can result in call failures when processing REFER messages if the Packet service profiles used for the new egress call leg only support codecs that are not in the list above because the PSX drops any other codecs since the REFER does not indicate the newer codecs are supported.

Root Cause: The REFER call handling fails when only G722 codec is selected in the packet service profile for all the required routes.

Steps to Replicate: Configure a call flow where the ingress and egress trunk groups only support G722 set up the A to B call and then try to do a REFER to C that should exist on either the ingress or egress trunk group.

The code is modified to pass the indicator to the PSX when processing the REFER that the SBC supports in newer codecs.

Workaround: N/A

Portfix SBX-99773 (originated in Release 9.0.0): The ASAN detected a heap-buffer-overflow in the Ss7LibGenerateCarrierCode while running a SIP to SIP-I call with PCV header.

Impact: For the Customer ISUP when the code was generating the carrier information transfer (CIT) parameter, it was reading off the end of an allocated memory buffer.

Root Cause: If the PSX does not provide the carrier code information to include in the CIT parameter, the SBC was not allocating a large enough memory block. The memory block was used to hold the potential CIT parameter being generated. The SBC was reading of the end of the memory block at the position where the CIT parameter would have been, to decide if a carrier code had been generated.

Steps to Replicate: This issue is only reproduced when running call flows with ASAN images in the engineering lab, it was observed when running regression for ttc-charging parameter in the P-charging-vector header.

The code is modified to avoid reading off the end of the memory buffer.

Workaround: N/A

Portfix SBX-99457 (originated in Release 9.0.0): The AddressSanitizer detected a heap-use-after-free on address 0x6070001153f0 at pc 0x5588611ec65d bp 0x7fbd2d86daa0 sp 0x7fbd2d86da98.

Impact: In an M-SBC deployment when making the M-SBC out of service (such as 'set global system action force mode outOfService'), the code was accessing free memory.

Root Cause: As part of the deactivation process, the M-SBC memory block was getting freed up in a child function. The parent function still had access to the pointer, and was reading from it on returning back up the stack.

Steps to Replicate: This issue is only highlighted in engineering lab when using ASAN images and taking the M-SBC out of service.

The code is modified to avoid reading from the memory block after it is free.

Workaround: Do not take M-SBC out of service.

Portfix SBX-100624 (originated in Release 8.2.0): The trunk group routing was not working when a SIP-I call is received.

Impact: The tgrp/trunk-context information in the R-URI and contact headers of an INVITE are not passed to the PSX/ERE as the originating and destination trunk group parameters if the INVITE contains ISUP MIME content.

Root Cause: The parameter were only being processed when there was no ISUP MIME content. There was not prior requirement for them to be used with ISUP MIME content.

Steps to Replicate: Send an INVITE message to the SBC that contains ISUP MIME contact as well as tgrp/trunk-context parameters in the R-URI | contact header and ensure they appear in the INPUT DATA section of the policy request.

The code is modified to process the tgrp/trunk-context information in the R-URI and contact headers and pass up in the policy request to PSX/ERE.

Workaround: The SMM can be used to convert the tgrp parameters to DTG/OTG parameters that are supported with SIP-I content.

Portfix SBX-101547 (originated in Release 8.2.2): On a switchover, a coredump occurred after a call was 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. But 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.

Portfix SBX-98991 (originated in Release 9.0.0): The AddressSanitizer detected a global-buffer-overflow on the address 0x55c93b015fa4.

Impact: While checking for two IPs in the same direct media NAT table, the code was reading off the end of an internal buffer.

Root Cause: While trying to process the net mask for the IP addresses, the code was using an index of 33 and reading of the end of the internal table with 32 entries.

Steps to Replicate: This issue is only highlighted in the development lab when testing direct media NAT call flows with an ASAN enabled build. 

The code is modified to no longer read of the end of the table.

Workaround: N/A

The SBC failed to send ACK to the right IP.

Impact: After a call was 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: A rexmit of 200OK, accidentally deletes the previous RR.

Steps to Replicate:

1. A calls B.
2. B responds with a 200OK with RR.
3. A reInvite triggers the SBC reInvite to B.
4. B responds with 2xx and rexmit 2xx.
5. The SBC sends ACK to the wrong destination (based on contact not from previous RR received).

The code is modified so the SBC ignores updating the data of the dialog.

Workaround: N/A

The SIPFE lookup returned the rcb pointing to wrong SCM post-upgrade.

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

Root Cause: The packing redundancy data structure that was sent to the standby were incorrect due to word alignment issue (using sizeof() to pack the data).

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

The code is modified to re-implement the packing logic and avoid using sizeof() to calc the size of data structure.

Workaround: N/A

Portfix SBX-100223 (originated in Release 7.2.2, 7.2.4): The SMM for changing the ISUP message inside a SIP-I does not work properly.

Impact: When a message is received with the mime content having single msgbody. After the SMM application on the message body, the SBC reformats it as a normal msgbody instead on mime content.

Root Cause: When a message is received with the mime content having single msgbody. After the SMM application on the message body, the SBC reformats it as a normal msgbody instead on mime content. The reformatting is not handled properly.

Steps to Replicate: Add the SMM rules that applies to the message body. Send a message with mime content having single msgbody in it.

The code is modified so that the SBC reformats mime body after the SMM application is formatted correctly.

Workaround: N/A

The P-Early-Media header with sendrecv was sent back to the ingress before the SDP was established.

Impact: When the makeInBandToneAvailable is disabled, on Tone And Announcement profile, the SBC sends the 180 Ringing with the PEM header as sendRecv even when the egress 180 has no SDP. This causes ring back issues on the ingress endpoints.

Root Cause: When the makeInBandToneAvailable is disabled, the SBC does not include SDP in the 180 message sent to the ingress but still sends a PEM header as sendRecv.

Steps to Replicate: With a fix, the SBC is sending PEM header as inactive when the makeInBandToneAvailable is disabled and the egress 180 Ringing has no SDP.

The code is modified to ensure the SBC sends PEM header as inactive when the makeInBandToneAvailable is disabled and egress 180 Ringing has no SDP.

Workaround: Enable the makeInBandToneAvailable on Tone And Announcement Profile.

Portfix SBX-101145 (originated in Release 8.2.1): The SBC is not sending the 183 (Dialog-2) to the ingress when the Downstream Forking and Loopback TG is configured.

Impact: The SBC is not sending the 183 (Dialog-2) to the ingress when preconditions and  Downstream Forking and Loopback TG is configured.

Root Cause: The preconditions are not handled in the ccE8S4 state when cc receives proc_msg.

Steps to Replicate: Configure preconditions, downstream forking and loopback TG. The egress leg receives a 183 for second dialog from UAS.

The code is modified to send the 18x message towards the ingress.

Workaround: N/A

The code is modified by getting a 3rd party stack that has the proper initialization and protection code to avoid a crash.

Workaround: N/A

Portfix SBX-99982 (originated in Release 9.0): Observed the SCM process core on OpenStack T-SBC while running load.

Impact: Observed the SCM process core on OpenStack T-SBC while running load.

Root Cause: Missing the NULL check for the epRes before invoking IS_RES_AUDIOLESS,

Steps to Replicate: The steps cannot be reproduced.

The code is modified to add the missing NULL checks in all the places in NRMA for epRes before invoking the IS_RES_AUDIOLESS.

Workaround: N/A

Portfix SBX-93697 (originated in Release 8.2.0): The PRS process cored on the M-SBC

Impact: The SCM coredump occurred when running the following test suite SBX-56559/Interwork P-Early-Media with a network that does not support the P-Early-Media and Relay.

Root Cause: The length of the string is not enough for logging and is causing the issue.

Steps to Replicate: Configure the system in sensitive mode and run the following test suite 56559/Interwork P-Early-Media with network that does not support P-Early-Media and Relay.

The code is modified to fit the required size and fix the issue.

Workaround: Configure the system in normal mode.

The SBC does not relay the 200 OK for UPDATE in the late media passthrough and reverse offer scenario.

Impact: In the latemedia relay call, the SBC may not be able to respond to an UPDATE if the previous 18x received is not PRACK.

Root Cause: A logical error due to the previous 18x did not have PRACK support, causing the SBC to be unable to send out the 200OK for an UPDATE.

Steps to Replicate: Latemedia relay, Egress offer SDP in 18x with PRACK, egress received subsequent 18x without PRACK, egress received an UPDATE with SDP. The SBC is unable to answer the UPDATE.

The code is modified so during a latemedia call if the SDP offer/answer is completed, the SBC is able to answer the UPDATE.

Workaround: Use the SMM to drop the 18x without PRACK if the SDP is not available.

Portfix SBX-97006: The rows are not being deleted from the sipRegCountDomainCurStats on the timer registration's timer expiration.

Impact: The RCB count was being decremented without considering the associated URIs for a registered address-of-record (P-Associated-URI header), and as a result, the rows were not getting deleted from sipRegCountDomainCurStats (and also from sipRegCountDomainStats) on registration timer expiry.

Root Cause: This issue is present since the 'sipRegCountDomainStats' CLI was introduced in version 7.1.

Steps to Replicate: 

1. Run a registration call.
2. Wait till the timer expires and the row is deleted from sipActiveGroupRegStatus table.
3. The same rows are still present in sipRegCountDomainCurStats table.
4. All row(s) were deleted. 

The code is modified so the RCB decrements where all other statistics' counters are decremented, by considering the associated URIs.

Workaround: N/A

Portfix SBX-93689: The SBC is not considering a silence period during monitoring the RTP restart.

Impact: Silent period configuration is not working as the NRMA is not sending the silent period value to the XRM. This is because the SIPSG is not passing NRMA_FLAG_APPLY_SILENT_PERIOD to NRMA.

Root Cause: This was implemented as part of SBX-70226 but it was not a customer requirement.

Steps to Replicate: 

1. Run a 180 with SDP and no PEM is received, play the delayed RBT on failure and monitor the RTP.
2. Subsequently, run a 183 without SDP and no PEM is received, continue monitoring and feed tone.
3. Authorized RTP is received and then stop tone and cut-thru.
4. Subsequently, run a 180 without the SDP and restart monitoring due to delayed RBT.

The code is modified so using the NRMA_FLAG_USE_MONITOR_PROFILE_PARAMS in NRMA for applies a silent period.

Workaround: N/A

The IpPeer authPeer fails to delete.

Impact: When the IPPeer modified either zone/port/ip, the old authPeer data structure is not delete.

Root Cause: There was a memory leak.

Steps to Replicate: 

1. Create an IPPeer with port aaaa.
2. Change the IPPeer with different port bbbb.
3. Change the IPPeer back to port aaaa.
4. The call may fail.

The code is modified to delete the old data structure.

Workaround: Delete the ipPeer and create a new one (not modify).

Portfix SBX-99515: Default LI: The X2 message does not have the timestamp set correctly.

Impact: In the default LI, the X2 message does not have milliseconds in the time stamp captured as part of the BCID avp.

Without this fix, the milliseconds in the time stamp field will be 000 and time stamp field will look like "Event Time: 20200429190440.000".

Root Cause: The Milliseconds data was never captured in time stamp field for the Default LI.

Steps to Replicate: Run a default LI call.

The code is modified to incorporate milliseconds. With this fix, the time stamp field looks like "Event Time: 20200429190440.541"

Workaround: N/A

Portfix SBX-88088: The SBC is not intercepting any media packets of C leg(post REFER) when PCSI LI is received in 18x.

Impact: The SBC is not intercepting any media packets of C leg(post REFER) when the PCSI LI is received in the 18x.

Root Cause: The SS8 LI information was not exported from new call Leg to the master call post refer. Hence interception of the new party coming into call does not get intercepted even though it contains P.Com.Session-Info header and is a valid target.

Steps to Replicate: The REFER call flow with new party coming into call has P.Com.Session-info Header and is a valid target.

The code is modified so the SS8 LI information gets exported from new call Leg to the master call post refer. The interception starts on new party and continues on old party if it was getting intercepted before REFER.

Workaround: N/A

The SIP FROM header constructed in SIP stack does not conform with the RFC.

Impact: The FROM header in the ACK is not the same as in the previous INVITE.

Root Cause: The issue, due to SMM, modified the FROM header in the INVITE and the SBC generate ACK based on the response.

Steps to Replicate: 

1. Using SMM to modify FROM header in Invite Request
2. Peer answer 200OK, with modified FROM header.
3. The SBC generate ACK based on the From Header received in response.

The code is modified to send the FROM header in the ACK based on from original request.

Workaround: Use the SMM to restore the FROM header in 200OK.

Portfix SBX-94506: Data Path mode is always 'a = sendonly'.

Impact: Whenever the SRS put the SIPREC call on hold with an a=inactive, the SBC always acknowledged SIP 200 OK with a=sendonly.

Root Cause: The SIPREC call hold was done by the SRS was not identified in terms of Signaling properly at the SBC.

Steps to Replicate: 

1. The main call is stable.
2. The SRS put the call on hold by generating SIPREC REINVITE with a=inactive.
   Expected and Observed Behaviour:-
   The SBC to respond 200 OK towards SRS with a=inactive.

The code is modified so the generation of RE-INVITE with a=inactive through appropriate CALL Hold Flag value for SIPREC.

Workaround: N/A

Portfix SBX-94948: The SBC uses the incorrect DNS group to resolve the FQDN associated with diameter peer.

Impact: The SBC was using the incorrect DNS group to resolve the FQDN associated with diameter peer.

Root Cause: On attaching the dnsGroup to the zone, the SBC failed link dnsGroup Id with all the TGs of corresponding zone.

Steps to Replicate: Test case specific configuration:

1. Create two DNS Groups D1 and D2.

2. Create two ZONE's ZONE_ACCESS1 and ZONE_ACCESS2 and associate D1 and D2 DNS groups on respective ZONEs.
ZONE_ACCESS1 => D1
ZONE_ACCESS2 => D2

3. Create two TG's TG_ACCESS1 and TG_ACCESS2 under respective Zones.
ZONE_ACCESS1 => D1 and TG_ACCESS1
ZONE_ACCESS2 => D2 and TG_ACCESS2

4. On TG_ACCESS2, Enable rx.
* sipTrunkGroup -> media -> pcrf -> pcrfRealm = realm.nnnn.com
* sipTrunkGroup -> media -> pcrf -> pcrfCommitment = required

Procedure:
1. Enable diameter Peer state.
set addressContext default diamNode <Node_Name> peer pcrf1 state enabled

The code is modified to update/link dnsGRoup Id in all the TGs of zone whenever new dnsGroup attached to the zone.

Workaround: 

1. After the dnsGroup configuration, perform a manual switchover (so during application restart and all configuration restored properly).
2. The dnsGroup has to be attached to zone before creating TGs under this zone. When a new TG created under zone, it will read configured dnsGroup id.

Portfix SBX-99904: ASAN stack-buffer-overflow in CommandLineParser::isBindProcess.

Impact: Stack_Buffer_Overflow in CommandLineParser::isBindProcess which cause PIPE Process get killed

Root Cause: We are creating a commandLineParser on the stack, and given the address of it to PIPE_PROCESS.
When the function then exits, at which point the stack variable goes out of scope.
but PIPE_PROCESS has a pointer to it and it uses it, although the variable doesn't exist anymore.

Steps to Replicate:

To Fix this , now used global object which has created in heap, so that variable will not go out of scope.

Workaround: N/A

Portfix SBX-93916: The RC zero handling case applied for both SR/RR packets to fix garbage values reported in relay monitoring.

Impact: Remote RTCP packets had metrics corrupted when the received RR has no reception reports.

Root Cause: The reception report count zero case is handled for the SR, but not for RR packets, resulting in parsing the subsequent unrelated RTCP packet fields as reception report fields.

Steps to Replicate: Run calls with RTCP relay monitoring features, Test with RTCP Reception report present and absent SR, RR packets, verify the Remote RTCP monitored values.

The code is modified to fix the garbage values reported in the relay monitoring.

Workaround: N/A

The SBC coredumped due to a pathcheck issue.

Impact: The pathcheck process may coredump when the pathcheck is state disabled on a FQDN based ipPeer.

Root Cause: The pathcheck process hit a race condition that can occur when the
DNS query completes after the pathCheck (on the FQDN based ipPeer) was state disabled, which can cause a NULL pointer access to coredump.

Steps to Replicate: This is a timing dependent issue, that is very difficult to reproduce.

Attempt to reproduce by defining the FQDN based ipPeer(s) with the pathcheck profiles state enabled.

Randomly state disable and state enable on the ipPeer(s) pathCheck profiles.

The code is modified to protect against the NULL pointer access.

Workaround: N/A

The SCM Process has a memory leak (SIPSG) that was not freeing pSbyRcb→pcrfInfo.

Impact: Leaking the PCRF related structures on the standby when processing the registrations if the PCRF is configured on Trunk Group.

Root Cause: Memory that was allocated for the PCRF related structures is not being freed as part of de-registration processing.

Steps to Replicate: 

1. Configure pcrfCommitment to something other than none.
2. Set pcrf_signallingPath to enabled.
3. Set pcrf_provSignalingFlow to enabled.

The code is modified to free the memory that is allocated for PCRF related structures as part of the de-registration processing.

Workaround: Workaround is to set pcrfCommitment to none.

Portfix SBX-94588: The LSWU will fail/stall due to the upgrade.out permissions.

Impact: The LSWU would fail if the upgrade.out file permissions are incorrect.

Root Cause: Permission of staging files were not being properly updated during pre-upgrade checks, thereby failing to execute upgrade script if the permissions are incorrect.

Steps to Replicate: Perform the LSWU to the fix build and verify that upgrade is successful.

The code is modified to correctly update permissions of staging files during the pre-upgrade checks so that upgrade script executes successfully even if initial permissions are incorrect.

Workaround: N/A

Portfix SBX-98091: The pattern 'rtpmap\:8\ PCMA\/8000' was not found in the 3 -> 183 SESSION PROGRESS.

Impact: In the forked call when the SBC receives multiple 18x from the Egress with a different To Tag, the SBC is not sending SDP in 18x toward the Ingress.

Root Cause: The SBC is not sending SDP toward ingress in 18x toward UAC when downstream forking is enabled.

Due to a bug in the matching, the common codec logic NRMA was unable find the common codec between previous 18x codec list and the current 18x codec. As a result, the SIPSG was not sending the SDP toward ingress due to common codec failure.

Steps to Replicate: 

1. The 100rel is enabled on the Ingress side.
2. Downstream Forking is enabled on the Egress side(lastProvResponse).
3. Dialog ID Transparency is enabled on both the Ingress and Egress side set addressContext <addressContext Name> zone <zone Name> dialogTransparency <enabled>
4. A sends the INVITE to B with 8.
5. The SBC receives the following 18x on egress side:
   1. 18x:: codec: 0, TO tag: A
   2. 18x::codec: 8, TO tag: B
   3. 18x:: codec: 18, TO tag: C

Previously, the SBC was not sending SDP in 3rd 18x,with the fix SBC should be able to send in 3rd 18x toward ingress

The code is modified to select the common codec when the call scenario is specific to the updated answer feature.

Workaround: N/A

Both the SBC CLI and EMA allows an invalid regex under the sipAdaptorProfile (SMM) to be configured that causes a SCM Process coredump once the SBC performs the regex operation (regstore).

Impact: The SBC may core when configuring the SMM with an invalid regex action.

Root Cause: The invalid action did not delete from rule when detect invalid.

Steps to Replicate: Configure the regex for invalid action, run an incoming call with valid criteria and the action taken may cause core.

Delete the invalid action from the rule to address the issue.

Workaround: Avoid configuring the regex with invalid action.

The active calls count was much larger than the stable calls count.

Impact: The active calls count is much larger than the stable calls count under "show table global callCountStatus" after the memory is upgraded from 12 GB to 24 GB.

Root Cause: The SBC 51xx with the memory upgrade caused an incorrect GCID mask resulting in a incorrect active call count.

Steps to Replicate: The issue was not reproducible in the lab. The code has been fixed on the basis of coredump and code review.

The code is modified to set the correct GCID mask after a memory upgrade for SBC 51xx.

Workaround: N/A

Portfix SBX-99013: A different JIP parameter is being sent by the SBC in 3xx scenarios.

Impact: The JIP parameter sent by the SBC in the P-DCS-Billing-Info in the redirected INVITE is not same as the JIP parameter present in 302 received.

Root Cause: The SBC was not saving the JIP Parameter present in the redirected INVITE properly into the message Info, and as a result, the information was lost and the wrong JIP parameter was sent in the redirected INVITE.

Steps to Replicate: 

PSX setup
==========

1. Enable the 'Determine JIP' in feature control profile on ingress trunk group.
2. 'Send' flag for JIP in Signaling Profile on egress trunk group.
3. Configure 'Include Privacy' for P-DCS-Billing-Info header.
4. Use JIP from 3xx in IP Signaling Profile.
5. Configure globalized flag for JIP.
6. Enable transparency for PDCS header on the first IP TG.
7. Configure a standard route entry for the redirection number sent in contact in 302, so that the call is routed to a different IP trunk group. Configure this IP trunk group same as the first IP trunk group.

Test Procedure
===============

1. Make a SIP-SIP call with JIP in the JIP parameter in P-DCS-Billing-Info header.
2. Egress sends a 302 Moved Temporarily with a different JIP value and contact points to the SBC ip.

The code is modified so the SBC saves the JIP parameter in the message info so that while forming a redirected INVITE, the SBC picks the correct JIP parameter.

Workaround: N/A

Portfix SBX-95601: The SIP-T IAM does not contain a generic number although the JJ9030 trunk contains a generic number in the initial INVITE.

Impact: On call from SIP to SIP-T, if the egress isup signaling profile has a Japan revision, if the Calling Party Number parameter in ISUP begins with digit '0', the Generic Number parameter of type Additional Calling Party Number is never included.

Root Cause: An error in porting GSX code to the SBC.

Steps to Replicate: Make a call from SIP to SIP-T, with egress isup signaling profile has a Japan revision. In the inbound INVITE, include P-Asserted-ID such that tel URI begins with '0' and tel DISPLAYNAME contains a different number. In such cases, Generic Number is expected in the IAM containing the tel DISPLAYNAME, but it is missing.

The code is modified so that the Generic Number parameter type Additional Calling Party Number may be included even when the Calling Party Number parameter begins with digit '0'.

Workaround: N/A

There was an issue on the port number in the DBG log.

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

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

Steps to Replicate: 

1. Set up TCP calls, and TLS calls.
2. Make the 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. Ensure that all out going messages are sent to right IP:Port in displayed in TRC log.

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

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

Portfix SBX-95083: The SBC was terminating all the (Transfer Target and Transferee) call legs after call transfer in OpenStack | AWS.

Impact: The SBC was terminating all the (Transfer Target and Transferee) call legs after call transfer in OpenStack | AWS.

Root Cause: The SBC signaling plane was quickly reusing the same RTCP gen media resource with this call transfer modification scenarios, and the media plane rejecting the reuse of this resource, resulting in call failures. The media plane disables the original resource only after sending last RTCP packet from media plane, then only it allows the reuse.

Steps to Replicate: Enable the NoBye RTCP Gen options, and test the call transfer, modify scenarios as follows:

1. Make call from PSTN endpoint to Teams endpoint (simulated in SIPp).
2. Answer the call as Teams client.
3. Initiate blind transfer from Teams client to another Teams client.
4. Disconnect the call at PSTN endpoint.

The code is modified to allow this reuse with NoBye RTCP Gen option. Allowing the signaling plane to reuse the same media resource for these call transfer, modifications to work.

Workaround: Disabling the RTCP Gen/term from the SBC, and using RTCP relay will not have such issues.

Portfix SBX-95126: The SCM Process had a coredump after PRACK.

Impact: The SCM Process coredumps because when memory is double freeing the Dialog Scope Variable Data.

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

Steps to Replicate: The  SMM Rule to store a dialog scope variable for all message, flexible Adapter Profile with advanced SMM enabled and dialog scope variable rules for messages. Attach to the ingress TG both of them.

And run 18x/Prack call flow. A coredump will occur.

The code is modified to not to perform a dialog scope variable data.

Workaround: Disable the Advanced SMM in the FlexiblePolicyProfile.

Portfix SBX-94659: The EMA is disabled on Ingress. The SBC fails to send an UPDATE immediately towards Ingress when the SBC is feeding tone and 183 is received with an different SDP with PEM:sendrecv.

Impact: The EMA is disabled on Ingress. The SBC fails to send an UPDATE immediately towards Ingress when the SBC is feeding tone and 183 is received with an different SDP with PEM:sendrecv.

Root Cause: When the SBC was playing the tone and the PEM sendrcev is received, the SBC was not stopping tone and the update was not sent as a result.

Steps to Replicate: 

1. The TMO sends an INVITE with SDP pcmu, PCMA with PEM:supported.
2. The VoLTE sends 180 without SDP without PEM.
3. PRACK /200 Ok is done.
4. The VoLTE sends 183 with SDP PCMA with PEM:sendrecv.
5. PRACK/200 OK is done.
6. The VoLTE feeds the RTP.
7. The VoLTE sends 200 OK INVITE.
8. The TMO sends BYE.

When the condition is satisfied EMA is disabled and the SBC is playing tone, the PEM rcvd with the Sendrcev SBC stops the tone.

Workaround: N/A

The show table address Context default command output is failing. As a result, the following error is seen Error: addressContext default ipsec ipsecSaStatistics: Get Request Timeout.

Impact: The CLI show command timed out when retrieving the IPSEC stats.

Root Cause: The problem was that default address context was only being added into IKE icb's acList, if the user has configured at least LIF group for the default address context.

Steps to Replicate: 

1. Ensure no LIF group for default address context.
2. Issue the CLI command "show status addressContext default".

The code is modified to add the default address context into the acList at initialization.

Workaround: Configure a LIF group on the default address context.

There was a customer SBC memory leak.

Impact: There is a bug in the “clearTcpConnectionsforRegistration" functionality that causes a memory leak.

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

Steps to Replicate: Design set up the customer's configuration with the “clearTcpConnectionsforRegistration” flag set.
Design was able to reproduce the leak by running load with Registrations and de-Registrations.

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

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

Some calls on hold are followed by REFER fails.

Impact: Calls on hold before the blind transfer may cause a call teardown.

Root Cause: There is a race conditions in state machine during call transfer between transfer legs might cause offer answer timeout that tear down the call.

Case 1: After A or B transfer to C, if B or A sends Bye immediately (after received Notify(connect), and the SBC received reInvite from C (after received ACK). The internal resources bridging logic might not complete yet and caused the internal state error that trigger offer answer timeout.

Case 2: Similar to case 1, A or B put onhold before transferring to C. After received 200OK from C, there is an internal offer/answer off hold, and received BYE immediately will cause an offer/answer timeout.

In other words, during bridging connection, if there is additional offer/answer, the SBC might hit the race condition.

Steps to Replicate: 

1. The A call B, B put on hold, B refer to C.
2. C answers the fast connection. B received Notify connect, B send bye immediately.
3. Small load may caused call tear down due of offer answer timeout or C sends reInvite immediately to the SBC after received Ack.

The code is modified to wait for the internal resources bridging to be done before sending the Notify(connect) to A or B. So that the race condition offer/answer avoids when receiving Bye from A or B.

Workaround: Have A or B delay (200ms) before sending BYE.

Portfix SBX-91570: A call from MS Teams had an audio loss for 30 seconds and switchover.

Impact: The MS Teams to PSTN call flow with the DLRBT enabled on a software SBC. If there is an SBC switchover after the call is established, there can be a delay (e.g. 30 seconds) in the 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 jump backwards after switchover, which causes the one way audio issue for sometime until the SSN value increments past the previously sent value.

Steps to Replicate: Run theMS Teams to PSTN call flow with DLRBT enabled on a software SBC. Perform a switch-over after the LRBT is played and check there is no one way audio issue.

The code is modified so after the LRBT is played the latest SSN value is sent to the standby SBC so it can correct jump, the SSN forward on a switchover and media flow continues without delay post switch-over.

Workaround: N/A

Portfix SBX-96255: The LeakSanitizer detected memory leaks at SipDialogResizeRouteSetCmd.

Impact: Detected a memory leak in the SipDialogResizeRouteSetCmd when running a Subscribe Notify Call flow.

Root Cause: The SipDialogResizeRouteSetCmd will cause a memory leak in case of error scenario.

Steps to Replicate: This issue is only reproducible when using ASAN images in engineering lab.

The code is modified to fix the memory leak in this function.

Workaround: N/A

The Q.850 reason causes a mapping issue.

Impact: When an invalid cause=parameter is received in the Reason: Q.850 header, the SBC accepts invalid cause value and converts into valid value.

This would result in an incorrect CPC to the SIP cause mapping and impact SIP messaging on other leg. Reason: Q.850;cause=600;text="Busy Everywhere"

Root Cause: The SBC incorrectly validates the cause= parameter in Q.850 reason header.

Steps to Replicate: 

1. Send 600 Busy Everywhere from egress endpoint with cause = 600: Reason: Q.850;cause=600;text="Busy Everywhere"
2. Verify the issue.

Due to a bug, the SBC maps invalid cause value 600 to 88 (0x58) and when the mapping CPC to SIP, theSBC sends 503 to Ingress side.

Perform the same scenario.

The SBC sends 486 Busy Here to ingress as invalid Q.850 cause code is ignored.

The code is modified to ensure the SBC correctly validates the cause= parameter in Reason header.

Workaround: Use SMM to filter our Reason header with invalid Q.850 cause parameter.

Portfix SBX-99659: The call route was received by route and egress is TLS, the RURI port is not incrementing by 1.

Impact: The call route was received by route and egress is the TLS, the RURI port is not incrementing by 1.

Root Cause: There was missing logic to increment port by 1.

Steps to Replicate: Configure the call received route, the incoming call has route IP but no transport parameter. The SBC sends out an INVITE without an increment port in the RURI.

The code is modified to increment the port by 1.

Workaround: Use the SMM to increment port.

Portfix SBX-97575: The stack-buffer-overflow on address 0x7f06eb2d3028 at the pc 0x55f5f05c7d56 bp 0x7f06eb2d2a80 sp 0x7f06eb2d2230.

Impact: The stack-buffer-overflow on address 0x7f06eb2d3028 at the pc 0x55f5f05c7d56 bp 0x7f06eb2d2a80 sp 0x7f06eb2d2230

Root Cause: String was getting copied using the strcpy where source size was bigger than destination size. So it was causing stack buffer overflow issue.

Steps to Replicate: Rerun the testcase/scenario to verify.

The code is modified to run the StrNCpyZ and passed the destination size as third argument to resolve this buffer overflow issue.

Workaround: N/A

Portfix SBX-99951: On sending message to egress side, the SBC is sending MIME-Version twice.

Impact: When the MIME Header is received along with multipart method, the MIME header is going twice in the outgoing Message Method when transparency is enabled.

Root Cause: The two Headers are going one because of transparency and another one added by the SBC.

Steps to Replicate: 

1. Configure SBC for Basic 3xx SIP to SIP call.
2. Register the User and send MESSAGE from the Registered user.
3. Send Content-Type: multipart/mixed in MESSAGE.
4. Check for Content-Type: multipart/mixed transparency in MESSAGE after 3xx redirect.

The code is modified so when the multipart body is present do not add header by transparency.

Workaround: N/A

Portfix SBX-97576: The LeakSanitizer detected memory leaks at the SipDialogEnablePDUTrace.

Impact: This issue is only reproducible when using the ASAN images in engineering lab. There is a leak detected when running Video Regression.

Root Cause: Memory is being allocated without checking whether it is been allocated before or not

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

The code is modified to free memory before allocating the new memory.

Workaround: N/A

Portfix SBX-98319: The AddressSanitizer detects a heap-use-after-free in MrfRmCallControlBlock.

Impact: The heap after free memory use is deleted when running the MRF Call flow, where the call is connected on the MRF side and receive a error response from MRF.

Root Cause: We are freeing mrfrmCcb in OANULL::ntwkDiscHndl, but we still access the mrfrmccb in the caller function that leads to access of heap after free memory.

Steps to Replicate: This issue is only reproducible when using ASAN images in engineering lab.

The code is modified to not to free MrfRmCcb in OANULL::ntwkDiscHndl, but setting a Destoy_ccb bit and it will be freed in the caller function

Workaround: N/A

Portfix SBX-100075: The AddressSanitizer detected the heap-use-after-free on address 0x6230000e31dc at pc 0x560c37742937 bp 0x7f62795d68d0 sp 0x7f62795d68c8.

Impact: In case of a scenario where the INVITE is rejected because it received more than 10 Route Headers, then the pstCall is getting freed, but application is still using that pointer.

Root Cause: The pstCall is getting freed, but the pointer is not setting NULL.

Steps to Replicate: 

1. Register an end user with a registrar through the SBC.
2. Run a call by sending an INVITE with 21 Record-Route headers.
3. An RCB must be created for the end user.
4. The SBC should reject the INVITE with a 500 response. 

The code is modified so the pstcall is set to NULL after freeing that.

Workaround: N/A

Portfix SBX-100002: The JIP parameter is not being sent in the PAI header.

Impact: The JIP parameter received in 3xx was not sent in PAI header.

Root Cause: This is because of the Enhanced Local Redirection changes done in 7.2.3 R1.

Steps to Replicate: 

1. Make a SIP-SIP call with JIP in the JIP parameter in PAI header.
2. Egress send 302 Moved Temporarily with different JIP value.

The code is modified to fix this issue.

Workaround: N/A

The SBC inserts the port number 5060 in the Record-Route headers.

Impact: The SBC adds a default port as 5060 for transport TLS in Record Route header of 18x.

Root Cause: When the flag noPortNumber5060 in IPSP is disabled, the SBC adds the default port in the Record Route header of 18x if the INVITE does not contain a port in RR.

Steps to Replicate: 

Include Record Route header in an INVITE as mentioned below.

Record-Route:<sip:10.xx.xx.xxx:4589;transport=tcp;lr>,
<sip:10.xx.xx.xxx;transport=tcp;lr>,
sip:HHSIP@10.xx.xx.xxx;av-asset-uid=rw-75a842d6;lr;transport=tls>

Make the call and answer the call.
The SBC sends 18x towards ingress side.

Verify the Record Route in 18x.
Record-Route: <sip:10.xx.xx.xxx:4589;transport=tcp;lr>
Record-Route: <sip:10.xx.xx.xxx:5060;transport=tcp;lr>
Record-Route: <sip:HHSIP@10.xx.xx.xxx:5061;av-asset-uid=rw-75a842d6;lr;transport=tls>

The code is modified so when the flag noPortNumber5060 in IPSP is disabled, the SBC adds the default port 5061 for TLS transport and 5060 for other transports in the record route headers, if the corresponding request/response does not contain port in record route header.

Workaround: The flag noPortNumber5060 in the IPSP is enabled. Then the SBC does not add default port.

Portfix SBX-96147: The AddressSanitizer detected a heap-use-after-free on the address 0x60400047f020 at pc 0x561f45771c9f bp 0x7f4227923c60 sp 0x7f4227923c58.

Impact: The Heap-After Free memory is getting used in an scenario where the INVITE is getting rejected in the UasReceiveCallCmd().

Root Cause: In case of the failure in uacReceiveCallCmd, there is a chance in sending an error response, and when an error response is sent, a To Tag needs to be sent that is allocated in pstCall, so the pstCall must not be freed before sending that response.

Steps to Replicate: This issue is only reproducible when using ASAN images in engineering lab.

The code is modified to not free the pstCall in this case until an error response is sent.

Workaround: N/A

The Customer AWS SBC A-side inaccessible and the B-side did not take over.

Impact: Interface connectivity loss can occur(on mgt0, pkt0,pkt1) when the MTU set on the interface is more than 1500 and jumbo frames are transmitted out of interface.

Root Cause: In the DPDK kni module, jumbo frames are not handled properly resulting in slow leak of buffers.

Steps to Replicate: Set the MTU on an interface as 9000. Ping the large packets from the SBC to gateway.

The code is modified to prevent setting the MTU more than 1500 on interface.

Workaround: Set the MTU on interface as 1500 or less.

The SBC was routing calls to the wrong port number when targets were defined by the SRV records, and one or more targets get blacklisted.

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

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

Steps to Replicate: 

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

Verify the fix:
Ensure the SBC sends all calls to correct IP and port combination.

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

Workaround: N/A

Portfix SBX-98147: The SBC is not forwarding a 200 OK response of the OOD INFO to INGRESS SLB.

Impact: The INFO message response was not being sent to correct SCM and as a result, the SCM was not getting the related TCB and dropping the message there.

Root Cause: The INFO message in the "From" header Tag was not including SCM information and as a result, the SIPFE was unable to get the correct SCM to process this response.

Steps to Replicate: 

1. Enable the non-invite relay configuration in TG.
2. The UE Client Send INFO message to the SBC.
3. The SBC will add the "From" header tag and forward it to UE server.
4. The UE server will send 200 OK towards the SBC.

Platform/Feature: SBC

The code is modified to include the SCM information in the "From" header tag.

Workaround: This issue will not be seen in the SBC with single SCM process.

Portfix SBX-94838: From the EMA PM, once the GateKeeper Access is enabled, it is getting updated as 'disabled' instead of 'enabled'.

Impact: From the EMA PM, once the GateKeeper Access is enabled, it is getting updated as 'disabled' instead of 'enabled'.

Root Cause: This issue was due to missing ACLs on the third and fourth management ports.

Steps to Replicate: 

1. Login to securelink.sonusnet.com.
2. Generate the registration codes for Active 5400 SBC and Standby 5400 SBC.
3. Login to respective SBC EMA PM.
4. Navigate to Secure Link ( Administration -> System Administration -> Secure Link).
5. Provide DNS IP address and Registration code(generated in step 2).
6. Click on 'Enable GateKeeper Access'.

Note: Enabling the Gatekeeper access is done with different registration codes in Active and standby setup. From the EMA PM, once the GateKeeper Access is enabled, the status should show as 'enabled'.

The code is modified to support the ACLs for the third and fourth management ports..

Workaround: N/A

Portfix SBX-100557: The SBC fails to send a NOTIFY with 200 OK in the message body in the Attended Call Transfer.

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

Root Cause: The SBC fails to communicate the call transfer complete notification across its two call processing modules, which 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 the replaced information 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. The A - C call continues.

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

Workaround: N/A

Portfix SBX-97804: There was incorrect FQDN routing.

Impact: There was incorrect FDQN routing occurring that causes calls to route to the wrong destination.

Root Cause: This is occurring in some cases where the retransmitted DNS transaction ID of the earlier transaction matches with the existing transaction. This causes the records to save for the incorrect FQDN.

Steps to Replicate: No known steps to reproduce the problem.

The code is modified so whenever the DNS reply is processed that the FQDN matches what is received in DNS reply and stored in the transaction.

Workaround: N/A

The Standby SBC memory at 94% seems the SCM Process was leaking.

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

Root Cause: The SCM process on standby is leaking a SIP structure related to the path headers that are included in the Registration messages.

Steps to Replicate: Design should reproduce this issue by running Registration load which includes path headers in egress Registration messages.

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

Workaround: N/A

Updated the PATHCHECK and SCM processes so that port numbers obtained by a DNS SRV query for "_sips._tcp" (TLS) are not incremented.

Workaround: Configure the FQDN based ipPeer's pathCheck hostPort to the appropriate port number.

Portfix SBX-99748: The AddressSanitizer detected a heap-buffer-overflow on the address 0x6060007e96d0 at pc 0x55c8b4f2b47b bp 0x7efe153ce020 sp 0x7efe153cd7d0 READ of size 1 at 0x6060007e96d0 thread T9.

Impact: The issue occurs on a SIP-I call when accessing the 18x msgHandle after freeing the memory.

Root Cause: The MsgHandle being used is already freed and does not need to be freed, which caused the issue.

Steps to Replicate: Run a SIP-I call in an ASAN Build.

The code is modified to address the issue.

Workaround: N/A

The RCB state is not changed to challenged when the REGISTER refresh has multiple contacts.

Impact: The SCM process fails to properly handle RCB state transition to SIPRA_RCB_STATE_UPDATING, when a 401/407 challenged REGISTER refresh occurs. The RCB state shows completed verses challenged.

The SipRaRegisterProgressFailureNfy() fails to handle the REGISTER refresh (containing multiple contacts) in SIPRA_RCB_STATE_UPDATING.

Root Cause: A call to SipRaAnyNewBindings() always returns TRUE, when REGISTER contains multiple contacts, which results in transition to SIPRA_RCB_STATE_UPDATING (verses SIPRA_RCB_STATE_REFRESHING).

Steps to Replicate: 

Provision the SBC to handle 401/407 challenged REGISTER refresh scenario.

REGISTER -->
<-- 401/407 { Verify register state challenged }
REGISTER -->
<-- 200 { Verify register state completed }

REGISTER --> { Register Refresh }
<-- 401/407 { Verify register state challenged }
REGISTER -->
<-- 200 { Verify register state completed }

The code is modified to handle the REGISTER refresh (containing multiple contacts) in the SIPRA_RCB_STATE_UPDATING.

Workaround: N/A

Portfix SBX-100059: After observing an overnight call load run, ping with size more than 1453 is not reaching to the SBC.

Impact: The SBC SWe can get into a state where it cannot receive and reassemble fragmented packets.

Root Cause: For the fragmented packets that take close to 1 second to send the complete context, the network processor could decrement the incorrect interface "current number of fragments context in use" counter.

The network processor has a maximum fragment context in use limit and once it hits that limit, it will not accept new fragmented packets.

Steps to Replicate: Send fragmented packets that take 1 second to complete to pkt0, pkt1 or mgt1 port.

This may take some time but eventually the interface stops accepting fragmented packets without the fix.

The code is modified to decrement the correct interfaces "current number of fragment context" counter.

Workaround: No workaround available. Try not to send a very large fragmented packet to the SBC.

The SCM process coredumps SipSgHashLookup on the OOD OPTIONS/Subscribe.

Impact: The SCM process may coredump while doing a SipSgHashLookup on a OOD OPTIONS/Subscribe message.

Root Cause: The sipsgRelayCbHashTbl was corrupted where a list head is corrupted and there is not additional information to state what caused the corruption. The issue may have been caused by an entry added to the hash table twice (maybe with different keys).

Steps to Replicate: Not reproducible in the lab. Ran an OOD Subscribe and Options load and found no crash.

The code is modified to ensure the hash table entry is explicitly removed from the hash table, even if the hashlookup fails and also avoids adding a duplicate entry.

Workaround: N/A

Portfix SBX-100481: Observed the jitter more than 5ms in the passthrough call load.

Impact: More than 5ms jitter and relatively high packet loss was observed in the passthrough calls observed in some cases.

Root Cause: Segregation of media and non-media processes at initialization time may fail occasionally, leading to the non-media processes landing on vcpus meant for media processing.

This leads to a higher jitter and possibly higher packet loss.

Steps to Replicate: Issuing the following command shows only the  yield kernel threads and SWe_NP processes:

cset proc -l root

The code is modified to handle the function reliably.

Workaround: Reboot the instance.

The flag 'statusUpdateSupport' is not working.

Impact: The SBC includes the Accept and Allow headers while generating OPTIONS ping requests 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: The customer can use the SMM rule to remove the Allow and Accept headers from the OPTIONS ping.

Observed an after overnight call load run, ping with the size more than 1453 is not reaching to the SBC.

Impact: The SBC SWe can get into a state where it cannot receive and reassemble fragmented packets.

Root Cause: For the fragmented packets that take close to 1 second to send the complete context, the network processor could decrement the incorrect interface "current number of fragments context in use" counter.

The network processor has a maximum fragment context in a use limit and once it hits that limit, it will not accept new fragmented packets.

Steps to Replicate: Send the fragmented packets that take 1 second to complete to pkt0, pkt1 or mgt1 port.

This may take some time but eventually the interface stops accepting fragmented packets without the fix.

The code is modified to correct the interfaces "current number of fragment context" counter.

Workaround: No workaround available. Try not to send a very large fragmented packet to the SBC.

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

Workaround: None.

The SYS is filling up the "mcsEncodeCPC_MSG_INFO_STR: CPC_OP_STR parameter length mismatch".

Impact: The following log message is filling up the SYS log when the 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 the SAM that is checking for an internal inconsistency and logging this message when it detects an internal inconsistency.

In this specific 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 for in this very specific scenario.

Note: This specific message (for parameter:397) does not indicate any impact on customer functionality.

Workaround: There is no workaround. 

There was an issue in the call load during switchovers and when provisioning coredumps.

Impact: The Ipsec data is stored for all signaling ports. The Ipsec state array size was different from the signaling ports array. As a result, the ipsec state array was being overwritten.

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

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

Load testing at 500 cps for 15 hrs.
Switchover testing.
Physical port redundancy testing during load.
Customer configuration testing during load.

The crash should not occur.

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

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

Portfix SBX-99358: The basic C2C-Call is not getting cleared in the Call DetailedStatus and MediaStatus after terminating through the CallTermination Feature(OOD REFER).

Impact: Upon getting the DISC_CFM in VIRT_ESCR_DREQ, the CC informs ASG by calling the CcReportEventToMultipartyScript.

Then on the CC_EV_ASG_SCRIPT_COMPLETE_NFY, the event CC terminates the CCB.

But since the CC_VIRT_ESCR_NULL was not changed, the CC_EV_ASG_SCRIPT_COMPLETE_NFY event was ignored and the CC was stuck in VIRT_ESCR_DREQ state.

Root Cause: The CC was stuck in the VIRT_ESCR_DREQ state.

Steps to Replicate: 

1. Make A to B call.
2. Transfer A to C.
3. Terminate the call using CLI:  Request global terminateCall GCID.
4. Both legs should get cleared.

The coso that on event CC_EV_ASG_SCRIPT_COMPLETE_NFY, CC clear the CCB.

Workaround: N/A

Portfix SBX-90505: The ACK is not sent from the SBC after a call transfer when the Announcement Based Tone is configured.

Impact: The A call B, B refer to C, and then play the Tone with announcement. The SBC fails to send abort tone and send the ACK to C.

Root Cause: When the cutthru occurs, the SBC fails to abort tone due to media in use.

Steps to Replicate: Enable the tone as announcement, A call B, B refer to C. C responds with 180(play tone announcement), and then responds with 200OK.

The SBC fails to abort tone and send the ACK to C.

Reset the media in used, and abort tone when the cutthru occur.

Workaround: Switch to the tone using the DSP.

Portfix SBX-98678: The CUCM initiated a Call Transfer: the Re-INVITE for 200 OK from the SBC is having two different m-lines with the sendonly for audio and sendrecv for video during a DM call.

Impact: The Re-INVITE for 200 OK from the SBC is having two different m-lines with sendonly for audio and sendrecv for video during a DM call.

Root Cause: Because of some code in SIPSG which blindly overwrites video dpm to SEND RECV.

Steps to Replicate: 

1. The initial call flow is pass thru A<->B.
2. A transfers to C (Direct Media call from here).
3. B sends hold to C by sending a=inactive and c=0.
4. B sends late media re-invite without SDP to C.
   -> While responding locally to a late media re-Invite, the SBC blindly copies DPM=SEND_RECV for video, which creates this inconsistency as audio is sent out by the SBC as per last SDP negotiated on that leg (which is inactive) but video=sendRecv always.

The code is modified for condition only if the coreaudio Dpm also SEND_RECV.

Workaround: N/A

Portfix SBX-100980: Unable to create a SIP SIG port on the SBC5400 after an upgrade to 8.2.1R0.

Impact: After an upgrade, an additional sipSigPort cannot be created on the SBC5400 in certain ipInterfaceGroup configuration. These SBC5400 configuration has an ipInterfaceGroup with ipInterfaces on packet ports on {pkt0,pkt2}, {pkt0,pkt3}, {pkt0,pkt2,pkt3}, {pkt1,pkt2}, {pkt1,pkt3}, or {pkt1,pkt2,pkt3} sets.

Root Cause: During an upgrade, the SBC5400 did not consider the fact that packet ports pkt0,pkt1,pkt2,pkt3 were all handled by the same Network Processor (NP). Instead, the SBC5400 behaved like the SBC5200. The pkt0,pkt1 were handled by NP#0 while pkt2,pkt3 were handled by NP#1.

Steps to Replicate: 

1. Configure an ipInterfaceGroup, LIG1, with ipInterfaces on pkt0 and pkt2 on SBC5400. Configure sipSigPort 1 with ipInterfaceGroup LIG1.
2. Configure another ipInterfaceGroup, LIG2, with ipInterfaces on pkt1 and pkt3 on
   SBC5400. Configure sipSigPort 2 with ipInterfaceGroup LIG2.
3. After an upgrade to 7.2.5, add a new sipSigPort with ipInterfaceGroup LIG1.
4. (Optional) After Upgrade to 7.2.5, add a new sipSigPort with ipInterfaceGroup LIG2.

After another upgrade, the SBC5400 correctly sets the packet port to the NP mapping table entries.

Workaround: N/A

Portfix SBX-93747: When the transfer call to PSTN is rejected around 9-10 times, the initial call with TEAMS gets disconnected.

Impact: The call segment created after REFER-INVITE is not cleared, even on the non-2xx response. Instead, move to the segment to the deleted state.

Root Cause: The call segment created after REFER-INVITE is not cleared, even on the non-2xx response. Instead, move to the segment to the deleted state, but do not clear it by design (Below is the reason mentioned)

Note: The associated leg cannot be deleted, because some event originated from this legId  may be dispatched and if the associated leg is removed now, there is no way of finding the "scrLegId" (which is required to report to ASG) for the associated leg. 

Steps to Replicate: 

1. Make call from A to B.
2. Transfer from B to C.
3. Reject the transferred call at C.
4. Repeat that for 10 times.
5. The initial call should not fail.

The code is modified to check for available segments to CcProcessSipReferRequest (when processing the defer). If the associated segments array is exhausted, the CcCgMake is not called. Instead, fail to transfer with the NOTIFY (503 service unavailable).

Workaround: N/A

Portfix SBX-95149: During a direct dial to call queue, the transfer to agent gets disconnected automatically after 20 seconds as TEAMS releases the call.

Impact: These are the steps to replicate the issue as a result of which call gets disconnected.

1. PSTN dials CallQ number. TEAMS1 is configured in call queue.
2. TEAMS1 transfers call to TEAMS2.
   The call disconnects because the SBC does not acknowledge a message on the egress side.

Root Cause: This is due to some stuck states in the SBC call control.

Steps to Replicate: 

1. The PSTN dials CallQ number. TEAMS1 is configured in call queue.
2. TEAMS1 transfers call to TEAMS2.

The code is modified so the state transition occurs correctly in the SBC and the message is acknowledged.

Workaround: N/A

The SCM process coredumped.

Impact: The SCM process may coredump during the 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 an external PSX.
2. Configure the transparencyProfile on both ingress and egress trunk groups enabling sipMessageBody all.
3. Configure the direct media and SDP transparency on both ingress and egress trunk groups.
4. Preform SIP gateway to gateway call flow: INVITE, 183 with SDP, PRACK, 200 (prack), 180 with SDP, PRACK, 200 (prack), 200 with SDP, ACK, BYE, 200.

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

Workaround: The sdpTransparency is not supported over the gateway to gateway, disable the signaling sdpTransparency sdpTransparencyState.

Portfix SBX-101571: The AddressSanitizer detects a heap-use-after-free on the 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 same name, IP Address and IP Port to reproduce this issue.

The code is modified to fix this issue.

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

Portfix SBX-101229: The AddressSanitizer detects the stack-buffer-overflow in SipsGetSmmProfileForDlgScopehashUpdate.

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

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

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

The code is modified to populate the right memory in the hSipMsgHandle→pstlocalTsap.

Workaround: N/A

Portfix SBX-96391: The session refresh UPDATE should terminate with an "E2E UPDATE" flag enabled.

Impact: Run a call flow where the Session Refresh Update is received from the Ingress side, and the E2E UPDATE flag is enabled. This update is locally answered and not being relayed.

Root Cause: The SIP_SERVICE_TYPE_RELAY_UPDATE_WO_SDP bit is not being set on the ingress when the E2E UPDATE flag is enabled.

Steps to Replicate: Run a call flow where the Session Refresh Update is received from the Ingress side, and the E2E UPDATE flag is enabled.

The code is modified to set the SIP_SERVICE_TYPE_RELAY_UPDATE_WO_SDP bit when the E2E UPDATE flag is enabled.

Workaround: N/A

Portfix SBX-101401: The call disconnected when 10 PSX routes returned.

Impact: Run an INVITE Call Flow with the customer configuration where the PSX returns 10 Routes in the call, the SBC is disconnecting the call.

Root Cause: The 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 a customer config where the PSX returns 10 Routes per call.

The code is modified so the maximum size increased to ICM_REQUEST_MAX_14.

Workaround: N/A

Portfix SBX-101830: The SBC services are going down while running the CLI to create the toneCodecEntry.

Impact: The stack buffer overflowed while executing the toneCodecEntry for the AMR files.

Root Cause: This day-1 issue was caused by the SBC using the USHORT data type instead of ULONG for the coding rate variable.

Steps to Replicate: Execute the toneCodecEntry CLI for AMR codec.

The code is modified the usCodingRate(USHORT) to ulCodingRate(ULONG).

Workaround: N/A

Portfix SBX-95280: The LeakSanitizer detected memory leaks.

Impact: The antiTromboneData is getting allocated memory without freeing the already allocated memory.

Root Cause: There was a memory leak in cases of Direct Media Antitrombone scenarios.

Steps to Replicate: This issue is only reproducible when using ASAN images in engineering lab.

The code is modified to use the existing memory rather then re-allocating again.

Workaround: N/A

Portfix SBX-95525: The AddressSanitizer detected a heap-buffer-overflow on address 0x60400067d4b4 at

pc 0x55a19896b50c bp 0x7fb148263c10 sp 0x7fb1482633c0.

Impact: The Heap Buffer overflow is occurring on the Register Relay call flow where the username is not received in the called party.

Root Cause: The SBC is creating a string copy on username, even though that string is NULL.

Steps to Replicate: This issue is only reproducible when using ASAN images in engineering lab.

The code is modified to fix the issue.

Workaround: N/A

The ASAN detects a heap-use-after-free in the CcProcCallFsmMsg. There was an SBC ASAN build failure when testing epcac DBL with SLB.

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

Root Cause: The call control logic maintained a queue of call control blocks with outstanding events to process. 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 (i.e. bulk call releases due to a failure), it was possible that the same call control block got added to the queue twice. Then, when the call control instance was released, it removed one instance from the queue, but subsequent processing code identified a remaining call control block in the queue, and attempted 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 the call control blocks are removed from the pending queue when all outstanding events are processing to avoid accessing memory after it frees memory.

Workaround: N/A

Portfix SBX-98796: The AddressSanitizer detected a heap-buffer-overflow on address 0x6150043d0258 at pc 0x55c7b4ebab3c bp 0x7f6f282a51a0 sp 0x7f6f282a4950 READ of size 432 at 0x6150043d0258 thread T8.

Impact: The HPC/GETS-related call flows are resulting in the code reading off the end of an internal memory block.

Root Cause: While processing the HPC/GETS-related calls, the code was allocating an ICM message based on the size of three structures and then trying to copy it based on the size of four structures, resulting in reading off the end of the memory block.

Steps to Replicate: The problem is only highlighted when running the HPC/GETS-related call flows in the engineering lab with ASAN images.

The code is modified to allocate the correct amount of memory to avoid the issue.

Workaround: N/A

Portfix SBX-98357: The LeakSanitizer detected memory leaks at the PathchkPingSessionAddEntry.

Impact: When making configuration changes to an existing path check object, a small memory leak occurred.

Root Cause: As part of the modify logic, the code was reallocating a memory block and it was not freeing up the memory block that was allocated when the configuration was originally created.

Steps to Replicate: This problem was highlighted in engineering lab while running with ASAN images to highlight memory leaks and then making path check configuration changes.

The code is modified to correctly free the memory block.

Workaround: Delete and recreate the path check configuration rather than modifying it.

Portfix SBX-99964: The AddressSanitizer detected a heap-use-after-free on nrmaMsgProc.c when running the D-SBC REFER.

Impact: While the SBC was processing resource allocation messages associated with DTMF relay handling, it was allocating memory after the memory was freed up.

Root Cause: This is a day 1 issue and not known to cause any problems in the field. While generating a DBG log message, the code was trying to print the contents of a message block immediately after the block had been freed.

Steps to Replicate: This issue can only been reproduced in the lab while running with ASAN images.

The code is modified to no longer access the message content after processing the message to avoid accessing the memory after it is free.

Workaround: N/A

Portfix SBX-99647: The XRM SBX_GoalwoPolicy has 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 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 an 16-bit value.

Workaround: N/A

Portfix SBX-100068: The SLB was going down after triggering the DBL entry for the event epCacAggrReject.

Impact: The SLB was reading invalid memory.

Root Cause: When the SLB was printing SIP PDU content to the DBG log, it was reading past the end of the PDU memory buffer.

Steps to Replicate: This problem is only observable when using ASAN images in the development lab.

The code is modified to avoid reading past the end of the SIP PDU to avoid accessing invalid memory.

Workaround: N/A

Portfix SBX-95584: The LeakSanitizer detected memory leaks at the packet handler.

Impact: While reading the configuration data, the SBC was overwriting the stack memory and also leaking small amounts of memory.

Root Cause: A number of fields in the SBC configuration where defined as boolean. However, the 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, which resulting in a leak.

Steps to Replicate: These problems can only be reproduced in the development lab while testing with ASAN image.

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

Workaround: N/A

Portfix SBX-98646: The AddressSanitizer detected an heap-buffer-overflow on the address 0x607000326fe4 at pc 0x563429a99aac bp 0x7f371d414210 sp 0x7f371d4139c0.

Impact: When the END2END 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: The problem is due to the GSX using the wrong enumeration range for an internal CPC parameter type. The associated parameter it creates does not contain any data. As a result, the SBC interprets this as a completely different parameter, and expects it to contain mandatory parameter data.. It reads the data which results in it reading off the end of the message block. This is more of an impact statement. Please append it to the other text under "Impact".

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.

Portfix SBX-65393: The calls fail after deleting the unrelated ingress IP prefix within a zone.

Impact: If the SBC is provisioned as follows, the TGs within a zone are provisioned with duplicate ingressIpPrefix and one of the ingressIpPrefix has an invalid format. When the duplicate ingressIpPrefix is deleted, the calls to TGs that should have matched the ingressIPPefix fail.

Root Cause: The CLI was not rejecting an invalid ingressIpPrefix from being provisioned by the user.

Steps to Replicate: 

1. Create a TG with ingressIpPrefix 0.0.0.0/0 (Named EXT).
2. Verify the ingress calls are selecting the correct ingress TG (EXT).
3. Create second TG with ingressIpPrefix 10.1.1.1/0 (Named TEST_TG).
4. Calls will still find the correct TG.
5. Delete second TG’s ingressIpPrefix of 10.1.1.1/0.
6. Calls fail to find correct TG (EXT) now, the only TG with 0.0.0.0/0 ingressIpPrefix because the backend code does not have the 0.0.0.0/0 prefix to EXT mapping.

The code is modified to reject the invalid ingressIPPefix formats.

Workaround: Do not add or delete invalid ingressIpPrefixs. Industry acceptable format of ingressIpPrefix needs to be entered in the CLI. 

Portfix SBX-97448: The DBG flooded with the line *XrmMediaStatsGet: resId 13750 has never been activated, and cannot retrieve statistics.

Impact: Receiving the MAJOR logs for the XrmMediaStatsGet failure during a mixed load scenario.

Root Cause: During a mixed load, the perflogger constantly pulls the XrmMediaStats. Some resources might not be activated at a given time when the CLI command was executed.

This results in the XrmMediaStatsGet failure.

Recreate the issue with tiny pause between 100 Trying and 18x.
Also, confirmed from SVT that there is no other issue observed apart from these logs.

Also, confirmed there is no binding error, resulting in this error.

Steps to Replicate: The steps cannot be reproduced.

The code is modified to change the logging from ERROR to INFO, as it is only a stats get failure.

Workaround: N/A

There was a 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 occurring 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: There is no exact call flow that would trigger this leak.

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

Workaround: N/A

Portfix SBX-96786: The SBC is queuing a 200 OK of UPDATE with the downstreamForkingSupport enabled and UPDATE received on egress.

Impact: The SBC is queuing a 200 OK of UPDATE with the downstreamForkingSupport enabled and  UPDATE received on egress.

Root Cause: In case of the downstream forking queuing mechanism, there could be chance that the TYPE_STATUS can fall-through to the CASE_OTHER. So when calling the generic CMD callDirection ,msgtype and msgStatus are not being sent.

Steps to Replicate: 

1. Configure the SBC for A to B call.
2. Enable the flag downstreamForkingSupport on Egress TG.
3. Make an A to B call.
4. Once the call is stable, send UPDATE from B.
5. Send a 200 OK of UPDATE from A.

The code is modified to send callDirection,msgtype and msgStatus in this case.

Workaround: Disable the DownStream Forking.

The LRBT had an unexpected UPDATE with the AMR-WB codec sent.

Impact: The SBC is not playing the tone using the same codec as negotiated, when the 183 with SDP is received and the same is indicated to ingress with UPDATE.

Root Cause:  It is a race condition exposed under the following conditions:

1. A calls B and B sends a 180 without SDP causing the tone to be played to A.
2. Subsequently B sends 183 with SDP so that the SBC needs to send UPDATE out to A for changing the codec.
3. Soon after the 183 with SDP from ingress is received, a 180 without SDP causes the tone play to start.
4. The race condition can be visualized as the UPDATE's 200 OK with SDP trying to modify the system for CUT-THRU, but instead interferes with resource management subsystem's attempt to play tone.
5. As a result, the resource management subsystem picks the incorrect PSP's to play tone.

Steps to Replicate: This steps cannot be reproduced.

Platform/Feature: SBC

The code is modified to enforce selecting the latest PSP while choosing PSPs to modify when TONE is on.

Workaround: Configure transcoding for WB-NB calls.

Portfix SBX-94286: The SBC must relay the error response of Prack to the endpoint when End-End Prack is enabled, and the call must not be torn down.

Impact: The call is terminated when an error response is received for the Prack and End-to-End Prack is enabled.

Root Cause: The SBC terminates the call whenever an error response is received for Prack.

Steps to Replicate: 

1. Enable End-End Prack is enabled.
2. The Prack is responded with error response

The code is modified so the SBC does not terminate the call when an error response is received for the Prack and End-End Prack.

Workaround: N/A

Portfix SBX-99115: Observed the MAJOR log "XrmMflowCmdSnoopBld: the log cannot find the Snoop Id 0" while running the SIPREC with 4 recorders on a KVM-20vcpu setup.

Impact: Observed the MAJOR log "XrmMflowCmdSnoopBld: the log cannot find the Snoop Id 0" while running the SIPREC with 4 recorders on a KVM-20vcpu setup.

Root Cause: When running the Modify, the snoopId is not checked if enabled before invoking results in the ERROR log.

When running the Activate, the snoopId is checked if it is enabled.

Steps to Replicate: The issue was observed with load testing with the SIPREC enabled.

The code is modified to check if the snoopId is enabled for Modify flows.

Workaround: N/A

Portfix SBX-102081: During the RTP-VTP 10 CPS, the 100 CHT G729 Passthrough load found the CPU Congestion and CPU Spike multiple times.

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

Root Cause: In case there are two vcpu, 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: Two vcpu pass over night in the passthrough load.

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

Workaround: N/A

Portfix SBX-95711: The SBC failed to apply the SMM rule on the outgoing 200 OK of the ingress leg.

Impact: When the 18x and 200 OK is received simultaneously from the egress, the 200 OK is queued on the ingress side until the 18x Prack Transaction completes. So in this scenario, the 200 OK message Scope variable is being lost.

Root Cause: The Message Scope Variable Header is lost when the 200 OK is queued on the ingress Side

Steps to Replicate: 

1. Set the ingress call leg to support 100rel, and the egress call leg to not support it.
2. The terminating party returns a 180, and then a 200 OK response, after it receives an INVITE.
3. After the ingress call leg completes the 100rel procedure (receives PRACK and returns a 200 OK for the PRACK), it fails to apply the SMM rule to the outbound 200 OK for the INVITE.

The code is modified so the Message Scope Variable Header is stored in the Prack Entry and retrieved when de-queueing again.

Workaround: N/A

An SBC Memory Leak occurred.

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

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

Steps to Replicate: 

1. Change the mode of the ingress TG to out-of-service.

   
   

2. Send a high number of calls (10000+) to the ingress TG with 1 cps.
   All calls are rejected.

   
   

3. Verify the issue: Check the memory of ScmP. Memory has leaked.

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

Workaround: Run the fix configuration which is causing early attempt failure.

The SBC does not generate the sonusSbxNodeResEmerCallNoRouteNotification.

Impact: The SBC does not generate the sonusSbxNodeResEmerCallNoRouteNotification alarm when the PSX returns no route for 911 based call (sip code 404, cause code 150).

Root Cause: The code to generate the sonusSbxNodeResEmerCallNoRouteNotification was not present in the scenario where the PSX returns no routes for the 911 based call.

Steps to Replicate: 

1. Make a basic SIP call using the PSX with no routes set for number starting with '911' on the PSX.
2. Configure the SBC:
   
   set profiles services emergencyCallProfile EmergencyCalls prefix 911
   
   set addressContext ADDR_CONTEXT_1 zone ZONE2 sipTrunkGroup SBXSUS12_LABSIP1 services emergencyCallProfile EmergencyCalls

The SBC does not generate the sonusSbxNodeResEmerCallNoRouteNotification alarm.

The code is modified to generate a sonusSbxNodeResEmerCallNoRouteNotification alarm when the PSX returns a "Not Route" for emergency based call on matching URI prefix.

Workaround: N/A

The SM process cored on the SBC.

Impact: The SM process crashed while executing the show table system syncStatus command.

Root Cause: The shell script used to get the oracle sync status did not return within 10 seconds, causing a healthcheck timeout that caused the coredump.

Steps to Replicate: The steps are not reproducible in the lab.

The code is modified so the shell script used to get the oracle sync status now times out after 5 seconds.

Workaround: N/A

Portfix SBX-99996: Major Logs existed in the DBG logs while running SIPREC on the SBC Core 5400 and 7000 systems

Impact: Observing the MAJOR logs listed below when running the SIPREC load on the HA setup.

100 00000000 152048.782437:1.01.00.09099.MAJOR .XRM:

*NpMediaPnpsNpCmdSend: Cmd 0x29 failed, error code 0xffffffff

100 00000000 152048.782532:1.01.00.09100.MAJOR .XRM:

*NpMediaFlowModify: Failed status 0xffffffff

Root Cause: To handle scenarios where the mirrored snoopId context is transitioning from disabled to enabled, modify the snoopId even though the snoopId is disabled.

By directly setting the NP_MEDIA_FLOW_MOD_RTP_SNOOP_FLAG | NP_MEDIA_FLOW_MOD_RTCP_SNOOP_FLAG when invoking Modify for snoop flows.

Even though there is a check to modify snoop only when snoopId is no disabled, the modflags are still sent as it is to PNPS, resulting in PNPS errors for modifying the invalid snoopId.

Steps to Replicate: Issue was found during load testing with SIPREC enabled.

1. Do not set snoop modFlags if snoopId is disabled.
2. Reset the NP Snoop modFlags it snoopId is disabled.

Workaround: N/A

Observed an SCM Process memory leak.

Impact: Existing memory is not freed before copying new info to the endPointAor by using SipRaCopyAOR.

Root Cause: The memory leak is observed when there are multiple calls to the function SipRaCopyAOR in the same call, and the same issue is observed during the call.

Steps to Replicate: This issue was observed during the registration and call load scenario. Run some registrations and make a call to registered users and run some load.

Freed the existing memory of the buffer before copying the information into the sipEndPointAor structure to address the issue.

Workaround: N/A

Portfix SBX-101154: Transcode the percentage required to load DSPs in the sweTrafficProfile.

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

Root Cause: This issue occurred due to an incorrect check that considers only the transcode percentage to allocate the DSP resource in the custom profile activation script.(partition_util.py).

Steps to Replicate: 

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

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

Workaround: Allocate some transcodePercent in the custom profile.

The callCurrentStatistics continue to increment unexpectedly.

Impact: The "activeRegs" counter, provided by the CLI zone callCurrentStatistics | callIntervalStatistics command, can continuously increase.

Root Cause: The incorrectly-formed SIP REGISTER messages received by the SBC increments, but never decrements, the "activeRegs" counter.

Steps to Replicate: Send one or more bad SIP REGISTER messages to the SBC, and observe that the
"activeRegs" counter provided by the CLI zone callCurrentStatistics | callIntervalStatistics command increases (and does not decrease).

The code is modified to decrement the "activeRegs" counter when the SIP REGISTER message fails the SIP parser.

Workaround: N/A

The SIPFE crashed causing corruption on the msgObject.

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

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

Steps to Replicate: Using snmptool to walk through 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 freeing memory twice.

Workaround: Ensure the valid zone/ippeer is entered when querying

A network issue occurred after an automatic restart of the M-SBC due to memory leak

Impact: The M-SBC loses network connectivity. This same issue occurred against SBX-93765, which is fixed in 7.2.3.

Additional minor np.log flood issues were experienced.

Root Cause: The SWe_NP logged an error when it received a small announcement packet (<32 bytes) from an application to send out of the interface. This is valid case and error should not be logged.

Steps to Replicate: Configure the SBC to play the announcement from pre-encoded tones using a codec with a small-sized packet.

The code is modified to remove the misleading logs.

Workaround: N/A

Portfix SBX-87415: The ASAN detected the heap-use-after-free in the UasProcessMsgCmd.

Impact: The heap-use-after-free in the UasProcessMsgCmd

Root Cause: This was an error case scenario where the memory was deallocated when the refcount is "0". The refcount was decremented to "0", with an attempt by the SBC to access the freed memory.

Steps to Replicate: None.

The code is modified to remove the memory as there is no reason to call SipDialogReleaseCmd that decerements the refcount here.

Workaround: N/A

Portfix SBX-95769: The AddressSanitizer detected a heap-use-after-free on the address 0x61d0005519b4 at pc 0x5609cd97443c bp 0x7f532d12e310 sp 0x7f532d12dac0.

Impact: One of the pointers related to the security information was not copied to the new structure when saving a request that needs to be processed after a asynchronous DNS response. This was leading to a bad read.

Root Cause: This issue is present since the feature related to SECURITY param was introduced in a nrma alloc and modify request.

Steps to Replicate: Run a MSRP B2BUA call with FQDN in the a=path attribute such that an asynchronous DNS response is received (meaning DNS results not cached in the SBC and the request actually reaches the DNS server and fetches results from there). This might require configuring the SRTP security profile; however, this is not used for the MSRP call.

The code is modified so the missing pointer value is copied from the original structure.

Workaround: N/A

Portfix SBX-99904: The ASAN detected the stack-buffer-overflow in the CommandLineParser::isBindProcess.

Impact: The Stack_Buffer_Overflow in CommandLineParser::isBindProcess, resulting in killing the PIPE Process.

Root Cause: Creating a commandLineParser on the stack, and given the address to the PIPE_PROCESS.
When the function exits, the point in the stack variable goes out of scope, but the PIPE_PROCESS has a pointer to it and it uses it, although the variable does not exist anymore.

Steps to Replicate: The steps cannot be reproduced.

The code is modified to use a global object that is created in a heap, so that variable does not go out of scope.

Workaround: N/A

The contact header parameters are not passed transparently in the redirected Invite.

Impact: With the Enhanced Local Redirection flag enabled, the contact header parameters received in the 3xx are not sent as parameters in Request URI if they are not processed by the SBC.

Root Cause: When implementing the changes for this new flag in 723 R1, this flag check was missed.

Steps to Replicate: 

1. The UAC sends INVITE towards SBC over TG1.
2. The SBC performs the D+ query and the Local Tagging is performed at PSX for the TG1 and returns the Redirector IP as part of the reply.
3. The SBC sends the Egress Invite towards the SBC towards the Redirector.
4. Redirector sends 3xx with the contact containing UAS IP and DTG info as mentioned below:

Contact: <sip:0xxxxxxxx@10.xx.xxx.xx:5060;dtg=SBC2_INGRESS_TG>

The code is modified to fix the issue.

Workaround: N/A

Portfix SBX-99761: The SBC stops running after this OBS call flow.

Impact: Run a DLRBT and Downstream forking scenario where the UPDATE is received from the Egress after the cuttru is done.

Root Cause: De-allocating the memory, but not setting pointer to NULL.

Steps to Replicate: 

1. Enable DLRBT.
2. Set PRACK on both legs.
3. Enable Forking for a non-forked call.
4. Set UPDATE with the codec change received from the Egress after 180.
5. Set firstRtp - SR.

The code is modified to set the hTempResponse to NULL to resolve the issue.

Workaround: N/A

Portfix SBX-99946: The SBC is not sending a RR/RS:0 in 200 OK during RE-INVITE answer.

Impact: The SBC is not sending RR/RS :0/0 in 200 OK for RE-INVITE towards ingress.

Root Cause: The issue is due to the SBX-96087 JIRA changes.

Steps to Replicate: Configure the SBC and GSX to make an SBC-GSX SIP-SIP call.

Procedure:

1. Perform the correct configuration:
   Egress PSP: AMR (WB) Bandwidth efficient.
   Ingress PSP: AMR (WB) Bandwidth efficient.
   The transcode conditional flag enabled on both PSP.
2. Enable RTCP in Both ingress and egress PSP; and configure RR/RS bandwidth as 100 in Ingress PSP, and as 200 in Egress PSP.
3. Enable flag 'Send RR/RS in SDP' in IP Signaling Profile for both Ingress and Egress.
4. Initiate a SIP-SIP Audio call with Audio codec as AMR WB with RTCP bandwidth parameters in SDP as:
   b=RR:400
   b=RS:400
5. Egress Answers with RTCP bandwidth parameters in SDP as
   b=RR:300
   b=RS:300
6. Ingress end point sends Re-Invite with RTCP bandwidth parameters in SDP as:
   b=RR: 0
   b=RS: 0

Reverted changes made for the SBX-96087 Jira to fix the issue.

Workaround: N/A

The code is modified so if the mediaAssocGcid from the SBC is NULL, then reset it on the callLegPtr structure on the M-SBC as well.

Workaround: N/A

A SCM leak on the Standby.

Impact: The SCM may leak memory in calls with a SIP Relay and FQDN. The memory used to store the Domain information may be leaked.

Root Cause: There is an edge case where the memory used to store the Domain information for a SIP Relay call is not being freed.

Steps to Replicate: This issue has been found by a code inspection and the steps to reproduce this case have not been identified.

Platform/Feature: SBC

Portfix SBX-94512: The RTCP packets count is not getting populated consistently in the callMediaStatus.

Impact: With the RTCP relay monitoring feature, sometimes the RTCP packets are not relayed or discarded.

Root Cause: In the SWe NP, due to endian alignment code issue, the RTCP mode configuration flags were not set as per the call flows enable/modifications.

Steps to Replicate: This is sporadic, when multiple times RTCP REL MON call flows, modifications tried it might occur.

Platform/Feature: SBC

The SipSgProcessRelayRequestPrimitive: relay an INVITE without the cpcOrigMsgInfoPtr.

Impact: A increase in the DBG logs filling up with SipSgProcessRelayRequestPrimitive messages.

Root Cause: In case of an End2End Re-INVITE, the log message does not have any impact.

Steps to Replicate: The log level changed on the basis of code analysis and description.

Platform/Feature: SBC

A large increase in sonusSbxSscsRouteFailureWithoutGapNotification2 traps.

Impact: When the PSX has more than 10 routes configured and the SBC receives those routes in multiple PSX responses and if all the routes fail, the SBC still makes additional diameter query towards the PSX. This causes the PSX to send an error: No Routes in Cache to the SBC. The SBC logs a trap after receiving No routes in the cache error.

Root Cause: The SBC makes an additional query to the PSX even after the PSX sent all the routes.

Steps to Replicate:

1. Configure more than 10 routes on the PSX Routing Label (11 routes for example).
2. All 10 routes fail.
3. The SBC sends another query to get more route and those fail as well.
4. The SBC still send additional query to the PSX which fails because the PSX have returned all the

Platform/Feature: SBC

Portfix SBX-93967: Direct dial to a call queue, and then transfer to agent fails.

Impact: For the PSTN to Teams calls, when Teams was triggering an INVITE with replaces, perform a subsequent REFER. The SBC was not relaying the REFER-TO information from the REFER message to the subsequent INVITE. This was resulting in the wrong information being sent back to MS Teams and the call failed.

Root Cause: The SBC was not relaying the REFER-TO information from the REFER message to the subsequent INVITE.

Steps to Replicate: In a MS Teams setup run a call Q and transfer scenario where the call originates from the PSTN side.

Platform/Feature: SBC

External PSX became active after a switch over, though it was the OOS prior to the switch over.

Impact: When changing the multiple remote policy servers' mode together in one "commit", some of the server's operational stats in the standby node might not be synced.

Root Cause: When one of the remote policy servers' mode was being changed from the OOS to active, the standby node will not try to register with this server, and the iteration of all mode change servers will be stopped. This causes the rest of the servers, whose operStats have not been changed and remain unchanged. Therefore, the operStats of these servers at standby node will be out of sync with the active node.

Steps to Replicate:

1. In a working HA, provision at least 3 working remote policy servers.
2. While keeping the admin stat at enabled, only keep 1 of the servers mode as active, and rest are out of service.
3. Change those servers' mode, commit only after all the set commands finished.
4. Display the status using the 2 commands below:
   "show table system policyServer remoteServer"
   "show table system policyServer policyServerStatus"
5. Perform a switchover.
6. Repeat step 4. The operStat will be different from step 4.
7. Making call load, may be a load call rate, when the Node A is active, and then when the Node B is active. When the Node B is active, the policy request may still be sent to the remote server that you have already made the OOS when the Node A was active.

Platform/Feature: SBC

Calculated the size of a buffer as too small and error logs were being generated post upgrade.

Impact: Removes this incorrect log message:

SipsRedGetCallControlSizeCmd()
Minor .SIPSG: *SipsRedMirrorCallControlCmd: Potential for buffer
format ERROR. Available:16076 Calculated:383 Packed:277

Root Cause: This message is logged incorrectly when the code is calculating the size for a Redundancy message.

Steps to Replicate: The steps cannot be replicated.

Platform/Feature: SBC

The code is modified to remove this incorrect log message:

SipsRedGetCallControlSizeCmd()
Minor .SIPSG: *SipsRedMirrorCallControlCmd: Potential for buffer
format ERROR. Available:16076 Calculated:383 Packed:277

Portfix SBX-93456: The SWe NP worker has a segfault.

Impact: There is an issue in the SBX-93456, where the SWe_NP was crashing multiple times due to the skb_work->skb corruption.

Root Cause: There is a point in normal media processing ( RTP and RTCP path), where an update to skb_work->skb from addr_ptr that is not necessary, may corrupt the skb_work->skb.

The corruption occurs in the path of processing RTCP XR packets, where the addr_ptr moves ahead by a few bytes, but the UPP processing expects the mbuf address to be present back at the 58 bytes from addr_ptr.

Steps to Replicate: Run JIO scenarios.

Platform/Feature: SBC

The RTP Inactivity Timer fires early upon performing a port switch-over on the M-SBC.

Impact: If a call starts out with no RTP packet at all, the RTP Inactivity Notification is triggered earlier than the configured threshold. This is only observed on the SWe SBC.

Root Cause: The timestamp used for inactivity detection is not set when the media resource is enabled in the network processor code.

Steps to Replicate: Run a test that establishes a call where the ingress peer does not send RTP. There are no switchovers or other events and the calls are disconnected before the timer expires. The timer is set to 30 seconds.

Call service Duration with a disconnect 145.

Platform/Feature: SBC

The SBC fails to route in advance to the 13th route.

Impact: When the PSX has more than 10 routes configured and all routes in the first policy response fail due to an internal cause, the call fails because the SBC cannot handle more routes correctly.

Root Cause: When the PSX has more than 10 routes configured and all routes in the first policy response fail due to an internal cause, the SBC's NRMA subsytem returns with an allocation failure.

Steps to Replicate:

1. Configure more than 10 routes on the PSX.
2. Force a failure on the first 10 routes due to an internal error.
3. Verify the call gets established on the routes in second policy response.

Platform/Feature: SBC

Portfix SBX-91398: The ASAN heap-use-after-free on the address DnsClientQueryServerCmd.

Impact: The DNS client running in the SBC while trying to query the DNS server, tries to identify the transport protocol used. If the query fails on the first server, it accesses the first DNS server's data structure to get the type of transport protocol.

Root Cause: This issue was reported as part of the ASAN Testing on the DNS regression suite in the SBC lab.

Steps to Replicate: This issue was found while running the DNS regression test suites.

Platform/Feature: SBC

The SBC fails to relay the 4xx-6xx responses when the IPTG authentication is enabled - all SIP causes are mapped to the CPC176 CPC_DISC_TG_AUTH_FAIL.

Impact: When the IPTG authentication is enabled, the SBC maps all the 4xx-6xx SIP codes to the CPC 176. The SBC is unable to relay the cause code from the egress to ingress endpoint.

Root Cause: When the IPTG authentication is enabled, the SBC maps all the 4xx-6xx SIP codes to the CPC 176.

Steps to Replicate:

1. Egress sends the 183 Session Progress.
2. Egress sends the 486 Busy Here.
3. The SBC does not send the 486 Busy code to Ingress.
4. Instead, sends the 599 that is mapping of 176 ( CPC_DISC_TG_AUTH_FAIL, which is CPC code) to Ingress.

With a fix, the SBC sends the 486 buys to the ingress correctly.

Platform/Feature: SBC

The SAM Process cores when the SNMP walk commands are executed during the TLS load.

Impact: When the getTlsSessionStatus command is executed when the TLS load is running, it will result in a SAM Process core.

Root Cause: The issue is because the SIPCM expects the SSL_get1_session() to increment the reference count of the SSL socketPtr. After the SIPCM returns from the SSL_get1_session() tries to decrement, the reference count during the time the socketPtr was deleted by another thread, which results in a double free.

Steps to Replicate: The steps cannot be reproduced.

Platform/Feature: SBC

The SIP OPTIONS was not responding after a failover.

Impact: A syntax error message during a switch over is unable to respond.

Root Cause: Internal messages drop due to other subsystems not being ready to process the message. Subsequent messages are stuck in the queue.

Steps to Replicate: Simple ping Options messages during a switchover.

Platform/Feature: SBC

The IPv4 Path MTU Discovery (RFC1191) was not working.

Impact: The IPv4 Path MTU Discovery (RFC1191) does not work.

The SBC uses the MTU of the outgoing network interface as the Path MTU.
Without the fix, the SBC does not update the Path MTU properly even if a router in the path sends "ICMP Destination Unreachable Fragmentation Needed" message with a smaller Path MTU value. The large packets requiring fragmentation to fit the Path MTU from the SBC will not reach the SIP peer.

Root Cause: In performing a route/fib, lookup in the updating Path MTU from "ICMP Destination Unreachable Fragmentation Needed" message did not consider the ipInterfaceGroup and addressContext. This resulted in not updating Path MTU of the proper route entry to the peer.

Steps to Replicate: The SBC sends IP packets of a length 1500 bytes toward the SIP peer when a path to the peer has a smaller MTU (e.g. 1400 bytes). A router with the smaller MTU sends "ICMP Destination Unreachable Fragmentation Needed" to the SBC. The SBC, with the fix, adjusts the Path MTU, performs the fragmentation and sends fragments to the SIP peer.

Platform/Feature: SBC

The lwresd process on the active node is killed when a reboot is issued.

Impact: When a reboot is issued at the command prompt on the active node, the slwresd process is killed prior to it being properly shutdown. This causes a delay in reboot processing as the system goes through a fault recovery processes rather than an expedited shutdown.

Root Cause: The reboot wrapper that kills a non-SBC processes and using the drbd mount point was inadvertently killing the swlresd process.

Steps to Replicate: On the active CE, issue a reboot at a command prompt.

Platform/Feature: SBC

A large number of TLS error messages were in DBG log.

Impact: The following log message was filling logs due to being incorrectly logged at the MINOR level (when it should have been at INFO level):

Minor .SIPSG: sipsgUtils.c (-27373) 27050. SipSgLogLevel4: missing callId need to parse

Root Cause: The following log message was incorrectly being logged at the MINOR level (when it should have been at INFO level):

Minor .SIPSG: sipsgUtils.c (-27373) 27050. SipSgLogLevel4: missing callId need to parse

Steps to Replicate: The only change was to change a log message from MINOR to INFO - there was no testing necessary.

Platform/Feature: SBC

The code is modified to change the following log message from MINOR to INFO:
Minor .SIPSG: sipsgUtils.c (-27373) 27050. SipSgLogLevel4: missing callId need to parse

Portfix SBX-89018: The ASAN heap-buffer-overflow in the CpcOptionalParameterSave from the SipSgCopySipUrlToCpc

Impact: When an INVITE arrived to start a new call, the SIP service group control "callRouting useRouteSet" is set to the value of "received" to try and route the call based on the routeset in the INVITE. While processing the URI information in the header and trying to map it into internal structures, the code was reading off the end of a memory block. This setup can cause a crash if the memory block is at the end of the heap.

Root Cause: The code was trying to apply a 4 byte alignment to the internal parameter length after the memory had already been allocated. This meant that sometimes, the parameter length got set to a larger value than the memory block size.

Steps to Replicate: This problem was identified while running ASAN testing in the Ribbon lab and cannot be reproduced using normal images.

Platform/Feature: SBC

A backup/restore file cannot be downloaded from the EMA if the file name contains a dot (.).

Impact: A backup/restore file cannot be downloaded from the EMA if the file name contains a dot (.).

Root Cause: In the downloadSavedConfig block, making an API call both the time (Running on the SBC or running on the EMS).

Steps to Replicate:

1. Login into EMA.
2. Navigate to
   Administration -> System Administration -> Backup/Restore
3. Download the Backup file.

Platform/Feature: SBC: EMA

Portfix SBX-72499: The PesP cored on the active node.

Impact: The PesP cored on the active node.

Root Cause: The Ref count is getting incremented and once it reached the max value, it is becoming zero and destroying the object in one thread. At the same time, the other thread is accessing the object and crashing.

Steps to Replicate: Keep running calls for a longer time by using only one IpSignalingProfile.

Platform/Feature: SBC: Application, ERE

Portfix SBX-95097: The SBC is sending incorrect RACK in the PRACK for a Late Media Call.

Impact: The SBC is sending incorrect RACK in the PRACK for a Late Media Call.

Root Cause: Whenever the PRACK with SDP comes as an answer, the PRACK entry holding RSEQ details is not getting removed from the list while being sent out, because of any subsequent 18x/PRACK without SDP coming out at the same time; the SBC is adding old RSEQ in RACK.

Steps to Replicate: Late Media call with first 18x and PRACK with SDP followed by an 18x and PRACK without SDP.

Platform/Feature: SBC

Missing the Egress Response Code in the Field 59.19.

Impact: Egress error response code is not updated for the SIP response “487 Request Cancelled” in the field number 59.19 in ATTEMPT CDR record.

Root Cause: In the “487 Request Cancelled” case, because there is no CANCEL sent for the INVITE, the correct function is not called that is responsible for adding field number 59.19 in the ATTEMPT CDR record.

Steps to Replicate: Set up the SBC to make a simple call flow as below, and check the CDR for field 45.19/20 and 59.19/20:

UAC.xml SBX UAS.xml
| | |
| INVITE | |
|=======>| |
| 100 | |
|<=======| |
| | INVITE |
| |=====>|
| | 487 |
| |<=====|
| | ACK |
| |=====>|
| | |
|480 | |
|<=======| |
| ACK | |
|=======>| |

Platform/Feature: SBC

Portfix SBX-95749: The SBC is not adding the Contact header in the 200 OK of UPDATE for a session refresh UPDATE.

Impact: The contact header is missing in the 200OK sent by the SBC for a session refresh UPDATE (an UPDATE without SDP or an UPDATE with the same SDP as last SDP).

Root Cause: The contact header is missing in the 200OK sent by the SBC for a session refresh UPDATE (an UPDATE without SDP or an UPDATE with the same SDP as last SDP).

Steps to Replicate:

1. Enable the E2E Update.
2. Trigger an UPDATE without SDP or an UPDATE with same SDP as last SDP.

Platform/Feature: SBC

The SBC was using the incorrect SIP signaling port for the challenged SUBSCRIBE.

Impact: When the usePortRangeFlag is enabled, the SBC may use an incorrect SIP Signaling Port when handling a SUBSCRIBE request with an Authorization header, in the REGISTER - SUBSCRIBE scenarios when the initial SUBSCRIBE request is challenged.

Root Cause: When the usePortRangeFlag is enabled, the SBC may use an incorrect SIP Signaling Port when handling a SUBSCRIBE request with an Authorization header to the egress peer.

Steps to Replicate:

Provision the SBC to support CUCM (Cisco Unified Connection Manager) .
Ingress zone | sipTrunkGroup:
set addressContext default zone ZONE2 sipTrunkGroup SBXSUS4_LABSIP1 signaling registration requireRegistration required
set addressContext default zone ZONE2 sipTrunkGroup SBXSUS4_LABSIP1 signaling usePortRangeFlag disabled
set addressContext default zone ZONE2 sipTrunkGroup SBXSUS4_LABSIP1 signaling psxRouteForSubscribe enabled
commit

Egress zone | sipTrunkGroup:
set addressContext default zone ZONE4 sipTrunkGroup SBXSUS4_LABSIP2 signaling registration requireRegistration none
set addressContext default zone ZONE4 sipTrunkGroup SBXSUS4_LABSIP2 signaling usePortRangeFlag enabled
set addressContext default zone ZONE4 sipTrunkGroup SBXSUS4_LABSIP2 signaling psxRouteForSubscribe disabled
commit

set profiles signaling ipSignalingProfile DEFAULT_SIP commonIpAttributes relayFlags dialogEventPackage enable
commit

Perform REGISTRATION.

Perform a challenged SUBSCRIBE.

Platform/Feature: SBC

Co-existence of 4xx-6xx IPSP flag and Subscribe crankback is not working.

Impact: Out of dialog message fails to crankback when the relay 4xx-6xx is enabled.

Root Cause: The relay flag must not take precedent.

Steps to Replicate: Configure the crankback and enable relay 4xx-6xx flag. The subscribe response with failure must be able to crankback.

Platform/Feature: SBC: SIP

Portfix SBX-95941: An unknown header transparency flag interaction with Tagging.

Impact: STIR-SHAKEN related headers are duplicated when the STI service type is tagging and transparency is enabled.

Root Cause: This scenario was not handled when STIR-SHAKEN was supported in 7.2.0.

Steps to Replicate: STI Profile is assigned on Ingress and Egress TG, on Ingress STI Profile “Override P-Headers with configured values”  flag is enabled.

In egress IPSP (IPTG section) “Unknown header” transparency flag is enabled.

Platform/Feature: SBC

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

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

Root Cause: When the 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:

Test Configuration:
==============

1. The SBC must be configured to handle the AMR passthru call.
2. The transcoding must be set as conditional.

Test Procedure:
=============

1. The UAC sends Invite with AMR WB codec.
2. The 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

Portfix SBX-93360: The SBC was sending an INVITE with the SRTP instead of RTP.

Impact: The SBC is sending the SRTP instead of RTP.

Root Cause: The intersection of working PSP and peer PSP does not take place in the stream absent case. The SRTP values are never updated.

Steps to Replicate:

1. Create a UAC with RTP.
2. Create two UAS with SRTP param.
3. Send a port =0 for hold response.
4. Check if the SBC is misbehaving while sending an INVITE to release hold from the far end.

Platform/Feature: SBC

Portfix SBX-71623: The SMM header criteria not matching complete header value.

Impact: The SMM header criteria was not matching complete header value, it is only checking for the value between <>.

Root Cause: The SMM value being checked is enclosed between <>.

Steps to Replicate: Write a criteria on the header value and the issue will be displayed.

Platform/Feature: SBC: Application

Portfix SBX-85852: The "Timeout detected -- Forcing read/write access" occurred during switchovers.

Impact: The message "Timeout detected -- Forcing read/write access" is observed during switchovers.

Root Cause: This message is logged on the NBI timer expiry (after 2mins) and configuration changes were allowed before the DBs are in sync. This occurs when standby initialization takes longer.

Steps to Replicate: Install the SBC with the fix build and perform a switchover. Ensure there is no timeout message and that configuration changes are allowed only after the DBs are in sync.

Platform/Feature: SBC

Disable media lockdown does not suppress the media lockdown re-INVITE when the SRTP is enabled.

Impact: If the SBC offers crypto, and peer does not reply with crypto in the answer, a re-INVITE is sent to lockdown the crypto attribute (no crypto). If NAT is enabled, there is one second media drop while re-learning for the new re-INVITE is happening. For non-NAT cases, nothing will be observable except for signaling change.

Root Cause: This issue was SBC's original behavior.

Steps to Replicate:

1. Setup the SBC so that it sends a crypto in offer.
2. In the answer from the peer - do not send any crypto attribute.

Without a fix, the SBC will send another re-INVITE if the fallback to unencrypted is allowed. With a fix, this extra re-INVITE will be suppressed.

Platform/Feature: SBC

The R-URI in NOTIFY messages was not using the correct port number in case of TLS.

Impact: The SIP NOTIFY messages relayed through the TLS, may contain a R-URI that uses the SIP signaling port number verses the TLS port number.

Root Cause: The relay software used the SIP signaling port number instead of using the TLS port number.

Steps to Replicate: The steps cannot be reproduced.

Platform/Feature: SBC: Call Control

When the SBC receives route header with a port and TLS, it increments the port number.

Impact: When the SBC receives route header with a port and TLS, it increments the port number.

Root Cause: The SipSgPopulateAndSendToEgress() incorrectly increments the TLS signaling port number, when an out-of-dialog SIP OPTIONS message being relayed contains a "transport=TLS" parameter in the top most ROUTE header, and TLS transport is used.

Steps to Replicate: When the SBC receives OPTIONS with the Route header, the SBC relays that OPTIONS to a Port+1.

Platform/Feature: SBC: SIP

The PrsP cored on the standby SBC node.

Impact: The standby PRS process core was triggered from the XRM, when processing the XRM_DEALLOCATE_CMD_MSG from the standby SIPFE before the XRM has received the RTM_SYNC_TO_ACT_START_NFY_MSG.

Root Cause: There were many registration bind timeouts reported on the active SIPFE that triggered deallocation of the registration blocks and closing of port range connections. An active SIPFE mirrored the port range connection close requests to the standby SIPFE that triggered XRM_DEALLOCATE_CMD_MSG being sent to the standby XRM. The bug was that active SIPFE used regular ICM alloc/send mechanism to send the redundancy requests while standby node was in the middle of sync to active node.

Steps to Replicate:

1. HA pair, SIP registration load test, with high number of registrations.
2. Cause registration binding timeouts.
3. Restart the standby node.

Platform/Feature: SBC

The 4 SCMs cored after switchover.

Impact: The SCMs have cored after a switchover.

Root Cause: There is a bug that allows the RTM to attempt to process the Call Audit fault while still in the STANDBY mode. Since the Call Audit fault must only be processed while in the Active Mode - this causes a core.

Steps to Replicate: The steps cannot be reproduced.

Platform/Feature: SBC

Portfix SBX-74922: Modem calls failing when the DSP engaged in the ingress SBC.

Impact: The Bell 103 Modems in a G711-G711 transcoded call does not succeed.

Root Cause: The SBC G711-G711 transcoded calls perform a DTMF detection and the removal operation that can falsely remove some short signals, which is fine for speech perception but can affect modem signals that have similar characteristics of some modem signals. The SBC has signal detector for more modern modem that send a 2100 Hz tone to precede actual modem transmission. Once that is detected, the DSP media handling disables the DTMF removal. The SBC, however, does not detect older modems that sends a 2225 Hz signal in the beginning.

Steps to Replicate: 

1. Make a G711-G711 forced transcoded call. Ensure that both legs have the DTMF remove enabled (dspchanstat).
2. Use modem2225g711.pcap that has the modem signal captured from the customer in the ingress.
3. Collect the media capture for the call and inspect the dspchanstat, as well as the output signal from egress.
4. The dspchanstat and faxconfirmed field show 0x0. Signal output shows drops in the FSK modem signal between 18.72 and 19.65.

Platform/Feature: SBC

Port the fix for SBX-86420 to 6.2 and 7.2 code branch.

Impact: Whenever the TLS transport is selected, the SBC is trying to increment FQDN port by 1. In this case, even when FQDNPort is Zero in SIPSG/SIPS, the port is incremented by 1. So the FQDN port is set 1 because of this SRV query is not sent to the DNS server.

Root Cause: Whenever the TLS transport is selected, the SBC is trying to increment FQDN port by 1. In this case, even when FQDNPort is Zero in SIPSG/SIPS, the port is incremented by 1. So the FQDN port is set 1 because of this SRV query is not sent to the DNS server.

Steps to Replicate:

1. Send an INVITE with the TGRP parameters in R-URI.
2. The SBC sends the TGRP information to the PSX.
3. The PSX does TGRP based routing and sends route.
4. The SBC must send the SRV query to the DNS to resolve port and IP details when egress peer is FQDN.

Platform/Feature: SBC

Portfix SBX-96170: When the SBC executes a "Teardown" to UPDATE request by the SMM, the To header and From header of response are malformed.

Impact: Write an SMM Rule to do a teardown on an UPDATE Request and Error Response has Malformed headers.

Root Cause: When a server request of UPDATE request is saved, optional headers are not being saved.

Steps to Replicate: Write a SMM rule to tear down update request with the 415 and the issue will be reproduced.

Platform/Feature: SBC

The direct media (release) not working, no x-dmi to BSFT in the 200 OK while the 18x has it.

Impact: The 200OK behindNapt and direct Media support is unable to treat as direct media.

Root Cause: The issue is due to an internal offer/answer update after the first 18x, the previous flags for behind NAPT was lost.

Steps to Replicate:

1. Ingress configuration behind Napt and direct Media support.
2. Egress sends the SRTP Invite and peer response 18x with non-secure RTP. Subsequent 18x/2xx sent to ingress is missing x-dmi line.

Platform/Feature: SBC: Media, Platform, SIP

To TAG broken when dialogTransp enabled and downStreamForking enabled.

Impact: When the dialog transparency, downstream forking and end to end PRACK is enabled, the SBC intermittently sends incorrect tagging in outgoing PRACK towards the egress.

Root Cause: A previous fix (SBX-63508) tries to address the scenario where downstream forking is enabled, dialog transparency is enabled and the 183 for the second dialog comes before PRACK when the first dialog is sent. But the pstCall structure was pointing to memory that may have been freed and re-used for storing some other SIP Message. So the To Tag sent from the SBC in an ACK message was incorrect.

Steps to Replicate:

1. Enable Downstream forking, dialog transparency and E2E PRACK.
2. Outgoing ACK from the SBC to egress has incorrect to Tag.

Platform/Feature: SBC: SIP

Portfix SBX-96448: ICE not getting completed when the simultaneous ringing is enabled.

Impact: When simultaneous ringing is enabled to multiple MS teams endpoints, in certain cases where the ICE STUN requests are received by the SBC before an SDP is received in signaling messages, ICE is not getting completed for the endpoint that answers the call resulting in media to and from that endpoint not flowing through the SBC.

Root Cause: The SBC answers the first STUN message with a use candidate and completes ICE learning for that endpoint. Subsequent stun messages from other endpoints with use candidate were answered but ignored for ICE learning.

Steps to Replicate: With simultaneous ringing enabled to two MS teams endpoints, initiate call through the SBC to MS teams and verify that irrespective of when the endpoint answers the call voice media can flow through the SBC. Test must be repeated around 10 times and call answered from a different end point each time.

Platform/Feature: SBC

Portfix SBX-95170: To allow early RTP ICE learning for the MS teams DLRBT media bypass scenarios.

Impact: In a media bypass call flow with the DLRBT enabled, if the MS Teams client takes a long time to answer the call, then the ICE processing does not complete. The MS Teams client never sends STUN with a useCandidate = 1 because it did not get responses to the previous STUN messages in the first ten seconds for the call.

Root Cause: For an outgoing call, the SBC was not enabling ICE learning and not responding to STUNs until an answer SDP is received.

Steps to Replicate: With MS Teams media bypass and DLRBT configuration on the SBC, make a call from PSTN to MS Teams and delay answering of the call for 30 seconds.

Platform/Feature: SBC

Upgrade set all the CNAM Trunks to a Subscribe Rate of 1.

Impact: When the LSWU upgrade is completed, the SIP Trunk Group CAC ingress/egress subscribeRateMax and subscribeBurstMax are over written with the registerRateMax and registerBurstMax values.

Root Cause: This is functionality that was added in the SBC V3.1 when the SIP Trunk Group CAC ingress/egress subscribeRateMax and subscribeBurstMax were first added (but the values were not set).

Steps to Replicate:

Configure SIP Trunk Group CAC ingress/egress subscribeRateMax and subscribeBurstMax, for example:
% set addressContext default zone ZONE sipTrunkGroup SIPTRUNK cac ingress callRateMax 1 callBurstMax 1 registerRateMax 1 registerBurstMax 1 callLimit 0 emergencyOversubscription 0 extendedEmergencyIpLimit 0 subscribeRateMax 10 subscribeBurstMax 20 otherReqRateMax unlimited otherReqBurstMax unlimited hpcOversubscription 0
% commit
% set addressContext default zone ZONE sipTrunkGroup SIPTRUNK cac egress callRateMax 1 callBurstMax 1 registerRateMax 1 registerBurstMax 1 callLimit 0 emergencyOversubscription 0 extendedEmergencyIpLimit 0 subscribeRateMax 10 subscribeBurstMax 20 otherReqRateMax unlimited otherReqBurstMax unlimited hpcOversubscription 0

Perform an LSWU upgrade.

See that the SIP Trunk Group CAC ingress/egress subscribeRateMax and subscribeBurstMax are now set equal to registerRateMax and registerBurstMax values.

Platform/Feature: SBC

After an upgrade, the SWAP partition has a wrong UUID.

Impact: The file /etc/fstab had an incorrect UUID for SWAP partition due to the timeout logs were seen on the boot-up.

Root Cause: As part of multiple upgrades going through different versions, the SWAP partition UUID has somehow been changed but the same is not reflected in fstab file.

Steps to Replicate: Install/upgrade to fix version and ensure there is no swap entry in fstab file and also there is no timeout logs.

Platform/Feature: SBC

The SMM writeCdr was failing to write to ATTEMPT CDR when acting upon 300 Multiple Choice.

Impact: The SBC is failing to write the SMM fields in the ATTEMPT CDR when acting upon the 300 Multiple Choice.

Root Cause: The code was missing to handle the SMM information for a Redirect Scenario in the CDR.

Steps to Replicate: Test Redirect cases, and ensure SMM CDR write operation is successful in ATTEMPT record.

Platform/Feature: SBC

Portfix SBX-94662: The SBC is unable to handle emergency calls (E911) when ICE is enabled.

Impact: When the call limit for ordinary calls is already consumed on a trunk group, a new 911 emergency call on that trunk group does not complete using the emergency call bandwidth if ICE is also configured on the trunk group.

Root Cause: An issue in software was not processing ICE data correctly when the call was transitioning from using ordinary bandwidth to using emergency bandwidth.

Steps to Replicate: With the SBC trunk group configured with ordinary call limit and additional emergency call limit and ICE enabled:

1. Establish as many calls as required routed via the trunk group to consume the ordinary call limit on that trunk group.
2. While the previous calls are active, initiate a new 911 emergency call to be routed via the trunk group and verify the call succeeds.

Platform/Feature: SBC: Media, SIP

Portfix SBX-96723: The Zone SMM Profile was not working when performing a sbxrestart/reboot.

Impact: The Zone SMM is not getting applied when performing a SBC restart.

Root Cause: The Zone SMM profile is not being restored during an SBC restart.

Steps to Replicate: Attach a Zone Profile with the fixed order, and run a call. The Zone SMM profile will be applied, and when performing a  SBC restart and running the call, the Zone SMM is not getting applied.

Platform/Feature: SBC

Portfix SBX-96937: Running the sysDump.pl on OpenStack restarts the SBC.

Impact: Running the sysDump.pl on the 8.2.0R0 release on the SBC OpenStack cloud platforms causes the SBC application to restart.

Root Cause: The openclovis is monitoring some files as markers, using notify and taking it down when the file open operations are done.

Steps to Replicate: Once the SBC application is up and running:

1. Run sysDump.pl and enter the default inputs.
2. The SBC application will not go down.

Platform/Feature: SBC

Portfix SBX-96939: The ImPr cored when the SBC was running a call load.

Impact: The SBC ImProcess cored when the LI server became unavailable.

Root Cause: When the LI server becomes unavailable and a large number of packets are queued up for that server, the ImProcess takes more than 10 seconds to clean up all those packets, and the process coredumps.

Steps to Replicate:

1. Establish a large number of LI calls.
2. Bring the LI server down.
3. Ensure that the ImProcess does not coredump.

Platform/Feature: SBC

7k DSP falsely detecting fax tone on music.

Impact: SBC falsely detects a modem tone (2100 Hz with phase reversals) for certain type of music.

Root Cause: Algorithm for modem tone detection first looks for 2100 Hz tone for 630 ms and a non-zero number of phase reversals. In certain type of rich harmonic tones, this results in large number of phase reversals. Typically for modem tones we expect no more than 2 phase reversals in 630 ms.

Steps to Replicate: Make g729 to g711 calls and stream the pcmu_stream1_withsilence3.pcap from the g711 leg.
Before a fix, a modem is detected on this signal as indicated in the dspchanstat.
tone2100PhaseRevCnt: 1.

Platform/Feature: SBC: DSP

The SBC does not send invite to subsequent routes in native forking when the SBC receives Invite with call-ID as "i".

Impact: An incoming short callId header "i" fails to send subsequent Invite for multi routes.

Root Cause: There was missing logic to look for callId header with a short name.

Steps to Replicate: Configure the native forking call and have incoming call with short name "i' for callId header.

Platform/Feature: SBC

TLS call failures were observed due to a port value set to 1 instead of 5061.

Impact: The SBC uses Port 1 for sending an INVITE out for the TLS protocol when the route header was received without a port.

Root Cause: The issue is because when the route header is received without a port in it, the SIPSG was incrementing the port for the TLS. Since the port was not received, the port received is considered as 0. For the TLS, increment by 1. When incremented, the port becomes 1 and this gets used for sending an INVITE that is resulting in calls failing.

Steps to Replicate: Send the Route Header without port Route: <sip:ipaddr:;lr>. The SBC will use port 1 for sending an INVITE that is causing the issue.

Platform/Feature: SBC

The code is modified to check when the port is received in route header or not.
If port is received, then increment the port for the TLS. If it is not received, then increment and allow the SIP stack to handle it.

Asymmetric PRACK Interworking was not working as described.

Impact: Whenever any codec entry is deleted from codec list in the PSP and in the PSX, it rearranges the codec list immediately. There will not be any empty codec entry in the list.

The same issue is in the ERE, so it can be treated as a bug in the ERE.

Root Cause: When any CodecEntry is deleted, it is not rearranging the CodecEntry, which causes a NULL value in that place.

Steps to Replicate:

1. Configure the CodecEntry1 ,CodecEntry2 to CodecEntry12
2. Delete any CodecEntry.

Result: The call will be successful.

Platform/Feature: SBC: ERE

Update scripts in the common/debian/install/sbx-install and orca/install.

Impact: Monit paths needed to be updated with the new definitions.

Root Cause: New definitions were introduced for monit paths.

Steps to Replicate: The steps cannot be replicated.

Platform/Feature: SBC

The LCA errors seen when the SBC is spawned.

Impact: A sbcDiagnostic.sh flags error in the LCA, because it greps for ERROR.

Root Cause: The keyKeeper.py prints in the lca.log ERROR whenever it is unable to delete a file that contains a pswd. The file may already be deleted or not even created, this may also throw error.

Steps to Replicate: Run the sbcDiagonostic.sh and check no errors are present from keyKeeper.py.

Platform/Feature: SBC

Portfix SBX-96471: While trying to become active on a switchover, the systrem rebooted since the DRBD could not be switched to the primary.

Impact: While trying to become active on a switchover, the systrem rebooted since the DRBD could not be switched to the primary.

Root Cause: The DRBD is configured so that whenever a low level error occurs, the DRBD will be detached and the dstate will become "diskless". This scenario was leading the standby for reboot.

Steps to Replicate:

1. Run "drbdadm detach mirror" on standby.
2. Perform a switchover.
3. The switchover will be successful.

Platform/Feature: SBC

Portfix SBX-70059: Support the HOLD/RESUME INVITE from the SIPREC SRS to pause and start pumping media towards the SRS.

Impact: With a second SIPREC server call hold, the RTP recording is not paused/stopped towards recording server.

Root Cause: With the RTCP snoop enabled, the NP API handler has an issue in handling the media snoop configuration update with a SIPREC hold.

Steps to Replicate: Test the SIPREC hold features with the RTCP snoop enabled.

Platform/Feature: SBC

Portfix SBX-90855: The ASAN has a new-delete-type-mismatch on the SrchCriteriaIb.

Impact: The ASAN has a new-delete-type-mismatch on the SrchCriteriaIb.

Root Cause: The srchCriteriaIbArray is a dynamically allocated array in the GUISERVER, but it was not released using delete, so it is reported by ASAN.

Steps to Replicate: Re-run the testcase in the ASAN build and verify that the issue is not reported again.

Platform/Feature: SBC

The IPACL causes a PRS deadlock.

Impact: The PRS process may coredump after the state disabling and enabling ACL rule(s), performing a switchover by powering the CE off immediately, and state disabling and enabling ACL rule(s).

Root Cause: The PRS used stale socket connections after the power off immediate switchover.

Steps to Replicate: Reproduce the PRS coredump issue by performing the following:

1. Create the ACL rule using the installed role active CE when the HA system is synchronized (full redundancy protection).
2. Perform a switchover to the installed roll standby CE.
3. Wait until the HA becomes synchronized (full redundancy protection).
4. Using EMA to installed roll standby CE:
   Disable the ACL rule
   Enable the ACL rule
   Disable the ACL rule
   Enable the ACL rule
5. Verify that the system is synchronized.
6. Power off the installed roll standby CE "Power Off Server - Immediate" using the BMC.
7. Using EMA to installed roll active CE:
   Disable the ACL rule
   Enable the ACL rule <--- PRS CORED

Platform/Feature: SBC

The SBC was not releasing the other leg when a call is disconnected during hold( MOH enabled).

Impact: The SBC was not releasing the other leg when a call is disconnected during hold( MOH enabled).

Root Cause: This is a race condition in the CC where the handler for the event ASG_DISC_CMD is not present, and for the CC state CC_VIRT_ESCR_VDREQ due the call being hung.

Steps to Replicate:

1. Make a TEAMS to PSTN call.
2. TEAMS holds the call (MOH).
3. TEAMS disconnects the call during MOH.

Platform/Feature: SBC

Portfix SBX-94562: The ASAN has a heap-buffer-overflow in the SipSgACDMNaptQualTblAddEntry.

Impact: There was a Heap Buffer Overflow in the function SipSgACDMNaptQualTblAddEntry().

Root Cause: The Memcpy is being used instead of StrnCpyZ().

Steps to Replicate: Run the PCR 5637 regression on an ASAN Build.

Platform/Feature: SBC

Portfix SBX-94402: The SBC was not throwing a parse error in TLS if the content-length is not sent in a PRACK message.

Impact: The SBC is not throwing a parse error when the content-length Header is not sent in PRACK request using the TLS transport.

Root Cause: Similar code is present in the TCP Transport but not in the TLS-TCP transport.

Steps to Replicate: 

1. Make a TLS call with the 100rel enabled.
2. Send PRACK without content-length header for 18x.

Platform/Feature: SBC

Portfix SBX-94403: Unable to establish the same number of sessions after the switchover.

Impact: Calls were getting cleared under load conditions after a switchover in the first gateway in a GW-GW setup.

Root Cause: When the sessionKeepAlive is set and when the SBC switched over, the SBC starts sending refresh INVITEs to the endpoints. Since this is a GW-GW setup, a newly active GW-1 will send call processing messages to the GW-2. There was an issue in call processing at GW-2 that resulted in call failures.

Steps to Replicate:

1. Create a SBC GW-GW setup and enable the sessionKeepAlive,
2. Establish a call load of more than 25K and once call is stable, perform a switchover at the GW-1.
3. Calls now start failing.

Platform/Feature: SBC

Portfix SBX-94389: When call transferring to the PSTN, the SBC was sending RTP/AVP instead of RTP/SAVP towards Teams in the ReINVITE.

Impact: The SBC was sending a Re-INVITE towards Teams with m= line protocol as RTP/AVP instead of RTP/SAVP. Because of this, Teams is sending a 488 call was failed.

Root Cause: After an abort_ann_tone event, the CC was not moving to cutthru mode.

Steps to Replicate:

1. The 'Announcement based tones' flag is enabled.
2. Make a call from the PSTN - Teams n/w.
3. After a call connect, a Teams user transfers the call to another Teams user, and the call will succeed.

Platform/Feature: SBC

The Scm Process coredumps when there is NO ROUTE from the PSX = 0.

Impact: The Scm process coredumps when there is a call clearing with "no route found" from the PSX/ERE.

Root Cause: There was a bug in the call disconnect handler that resulted in the Scm crash for a non-configured number.

Steps to Replicate: Run a basic SIP call with a non-configured number and the Scm Process must not crash while handling the disconnect.

Platform/Feature: SBC: Application

The early media PEM has a behavior issue if there is no PEM in 18x.

Impact: When the egress TG early media method is P Early Media and the P Early Media header is not received, the SBC does not send media to the ingress caller.

Root Cause: The audio data path mode is set to inactive for the PEM structure.

Steps to Replicate: 

1. PEM Header transparency is enabled and the egress TG configuration is listed below:

set addressContext default zone IPX_SIGNALING_VOLTE sipTrunkGroup 1009074301 media earlyMedia method pEarlyMedia
set addressContext default zone IPX_SIGNALING_VOLTE sipTrunkGroup 1009074301 media earlyMedia egressSupport enabled
set addressContext default zone IPX_SIGNALING_VOLTE sipTrunkGroup 1009074301 media earlyMedia defaultGatingMethod sendrecv
set addressContext default zone IPX_SIGNALING_VOLTE sipTrunkGroup 1009074301 media earlyMedia forkingBehaviour firstProvResponse

Call Flow: The 183 Session Progress from the egress contains SDP and no PEM header.
Issue: The SBC does not send media from egress to ingress and the caller receives dead air.

Platform/Feature: SBC

Portfix SBX-94324: In the SBC to GW to SBC scenario, the first SBC coredumps when the ingress invite contains four identity headers.

Impact: Making a GW-GW call that contains multiple identity headers will cause a crash.

Root Cause: There was a validation code to check that the internal CPC structures that carries the identity header information was correctly padded to a 4 byte alignment. This validation code was correct for one identity header but failed when more than one was present and as a result, triggered the system to crash.

Steps to Replicate: Send in an INVITE that contains two identity headers of type SHAKEN and route the call over a GW-GW connection to a second SBC.

Platform/Feature: SBC

Portfix SBX-98356: There was a SEGV on an unknown address 0x0000000000e5 (pc 0x5653a715fdde bp 0x7f84a52bfea0 sp 0x7f84a52bfe70 T9).

Impact: After a successful surrogate registration, if any configuration related to the IP Peers/TGs/Surrogate registration is deleted, the Scm Process will coredump.

Root Cause: The code was dereferencing a null pointer when the trunk group configuration data was no longer present and the surrogate registration response came back.

Steps to Replicate: Trigger the SBC to send out surrogate registration request and delete all the associated trunk group configurations before sending back a response from the remote server.

Platform/Feature: SBC

The trunks data cannot be displayed on the live monitor.

Impact: The Zone and Trunk Group based live monitor charts does not show any data if the trunk group name contains hyphen.

Root Cause: The Elastic Search interprets 'hypen' as a delimiter and as a result, the string is broken down into tokens for indexing. When a query is put in the ElasticSearch for data with trunkgroup name containing 'hyphen', no data is retrieved as the Elastic Search has stored the data not with the actual trunkgroup name but with tokens

Steps to Replicate: 

1. Create a trunkgroup with name containing hyphen.
2. Enable the Live Monitor.
3. Run Calls and wait for sometime.
4. Verify data is shown in Zone and Trunk Group based charts.

Platform/Feature: SBC

The ipRecMetadataProfile does not work for the request-uri in the V07.02.02.

Impact: INVITE SIPREC or SIPREC INVITE may not have a request-uri beta or core.

Root Cause: The logical error that access the wrong data structure.

Steps to Replicate: Configure the metadataProfile with a request-uri and enable the SIPREC on ingress.

Platform/Feature: SBC

The MAINTAIN ONLY CDR .ACT file extension during atomic write process was not utilizing the .TMP.

Impact: When the CDR files are copied to the remote server, the file is copied with a temporary extension .TMP. For some installations, the software running on the remote server moves those files with the .TMP extension before the SBC software renames them with an .ACT extension.

Root Cause: A temporary extension is used during the time files are copied to the remote server.

Steps to Replicate: Perform the following step:

1. Unhide debug
2. Set OAM accounting cdrServer admin primary useFilePostfix disable
3. Transfer a large file.

Note that the file that is being uploaded to the remote server has an ACT extension while it is being transferred.

Platform/Feature: SBC

A new option is added to fix the issue:

1. Unhide debug
2. Set oam accounting cdrServer admin primary useFilePostfix disable

By default, the useFilePostfix is set to enabled.

When set to disable, a temporary extension is not used when copying the file to the remote server.

The SBC application restarted twice.

Impact: The SCM cored due to a segmentation fault.

Root Cause: The SCM hit a segmentation fault due to an attempt to dereference a NULL pointer.

Steps to Replicate: The steps cannot be reproduced.

Platform/Feature: SBC

The PrsP cored on both the active and standby nodes at the same time.

Impact: The PRS process cored due to accessing a non accessible memory location while processing the MONSEC response from NP.

Root Cause: Based on the core analysis, the core dump was caused by an invalid MONSEC response from NP. There were many read media stats commands sent to NP at the same time with the MONSEC request. The response that was processing appeared like a valid PNPS_NP_RSP_RD_MEDIA_FLOW_STR response.Due to this observation, there may be some timing issue that sent media flow stat response to MONSEC.

Steps to Replicate: The steps cannot be reproduced.

Platform/Feature: SBC

The SBC adds a media IP address in the outgoing SDP although the call is a direct media call.

Impact: When a direct media is enabled when handling the re-INVITE from ingress endpoint without a SDP change, the SBC sends a 200OK answer to ingress with the SBC's own media IP address. This causes a one way audio issue.

Root Cause: When the direct media is enabled, while handling a re-INVITE relay transaction, the SBC does not update the SIPStack SDP correctly.

Steps to Replicate: 

Configure for Direct media and enable the e2e Re-Invite.

1. Send an Invite from A to B.

   
   

2. B sends a re-Invite to A.

   
   

3. A sends a re-Invite to B with SDP of 200 OK that is sent for previous re-Invite

Platform/Feature: SBC

All call registrations were failing on the SJ SBC7K.

Impact: RFC-5626 PING/PONG traffic may cause severe CPU utilization issues in the SBC.

Root Cause: RFC-5626 PING/PONG traffic was sent from the SAM process to the SCM process and back.

Steps to Replicate: Send a lot of RFC-5626 PING/PONG traffic.

Platform/Feature: SBC: Call Control

Investigate a PATHCHECK Process coredump.

Impact: The Pathcheck process may coredump (due to healthcheck timeout) when the zone tracerouteSigPort is enabled, and when the traceroute takes longer than 45 seconds to complete (after the endpoint becomes BLACKLISTED).

Root Cause: The Pathcheck process coredumps due to a healthcheck timeout when the traceroute to the BLACkLISTED endpoint takes longer that 45 seconds to complete.

Steps to Replicate: Enable the zone tracerouteSigPort, and configure an ipPeer in that zone that will become BLACKLISTED, and the traceroute to that ipPeer takes minutes to complete.

Platform/Feature: SBC

A double SCM core resulted in an outage.

Impact: A double SCM core resulted in an outage.

Root Cause: While building the outgoing IAD message, there might be a case where the null values for a request message result in incomplete From and To headers, and cause a crash as a result.

Steps to Replicate: The steps cannot be reproduced.

Platform/Feature: SBC

The STI and Privacy interactions are incorrect.

Impact: When the STIR/SHAKEN is enabled, a default privacy behavior was not given preference when the Privacy header is present in the ingress INVITE as follows:

1. The STIR/SHAKEN is generating PAI/Privacy:id headers for all services when the PSX IPSP, SIP HTP, or PrivacyProfile->passThruPrivacyInfo is not configured to send the PAI header out. “Add verstat to PAI” flag is set, the SBC was generating the PAI/Privacy: id to add the verstat to PAI when no PSX IPSP, SIP HTP, or PrivacyProfile->passThruPrivacyInfo is configured to send the PAI header out.
2. The PrivacyParamRestricted configuration must have preference over STI service. The PrivacyParamRestricted->default must anonymize the From and Contact headers when Privacy: user,id,header,or uri is present in the ingress INVITE even when STI is enabled.
3. The PrivacyProfile configuration should be given preference over STI, when a privacy profile is configured to “applyPrivacyId/supportPrivacyId” and STI should not generate PAI/Privacy: id for any service.
4. The STIR/SHAKEN is removing the “Privacy: User” header from the egress signal after anonymizing From and Contact header, when the IPSP Privacy->Transparency is enabled and Privacy: User header is present in the ingress INVITE.
5. Anonymization format should be based on Privacy->Privacy Information and variantType.

Root Cause: 

1. After the verification service, the verstat should either be added to the PAI or the From header. The “Add verstat to PAI” needs enhancement to enable adding the verstat to From if the PAI is not present in the egress signal.
2. The PrivacyParamRestricted->default behavior anonymizes the From and Contact headers when Privacy: user, id, header, or uri is present in the ingress INVITE. The STI was not giving preference to PrivacyParamRestricted->default anonymization behavior for the privacy: id.
3. The PrivacyProfile configuration was not given preference when the “applyPrivacyId/supportPrivacyId” is enabled, and the STI was generating PAI/Privacy: id headers.
4. The SBC will not remove privacy: user after just anonymizing the From and Contact header and let the downstream switch(es) perform further anonymization.
5. A preference was not given to Privacy information and variantType while determining the anonymization format.

Steps to Replicate: Configuration:

1. Configure the STI profile on the SBC and attach the profile on to both the ingress and egress TG.
2. Configure the STI profile for Signing/Tagging/Verification service on the PSX.

Observations:

1. When no PSX IPSP->Privacy, SIP HTP, or PrivacyProfile->passThruPrivacyInfo configuration is enabled and the From is anonymized in the egress INVITE, PAI/Privacy header is generated.
2. The Ingress TG->Signaling->PrivacyParamRestricted->default is configured. Observed that “From” and contact headers are not anonymized, if the privacy: id is present in the ingress INVITE.
3. When no PSX IPSP->Privacy, SIP HTP, or PrivacyProfile->passThruPrivacyInfo configuration is enabled and privacyProfile configuration is:
   • The PrivacyProfile is configured with the “applyPrivacyId” flag enabled. The PAI/Privacy header is generated when the Privacy: id is present in the ingress INVITE.
   • The PrivacyProfile is configured with the “supportPrivacyId” flag enabled. The PAI/Privacy header is generated.
   (Note: The PrivacyProfile behaviour without any STIR/SHAKEN interactions. When PrivacyProfile is configured to “applyPrivacyId” and attached to the ingress TG or when the “supportPrivacyId” is configured in egress TG, the SBC will remove PAI headers from egress INVITE when the Privacy:id header is received in the invite. When the privacyProfile with the “supportPrivacyId” is configured in the egress TG, the SBC will remove PAI headers from egress INVITE, irrespective of the Privacy header.)
4. The “Privacy: User” header is not present in the egress signal, when the IPSP Privacy->Transparency, SIP HTP or PrivacyProfile->passThruPrivacyInfo is enabled and the Privacy: User header is present in the ingress INVITE.
5. The From and contact headers has “Anonymous@Anonymous.invalid” as opposed to "Anonymous” <sip:Restricted>. If the privacy: user header is present in the INVITE and when IPSP->Privacy->Privacy Information is P-Preferred-Id or Remote-Info Party.

Platform/Feature: SBC

1. The STIR/SHAKEN does not generate the PAI/Privacy: id headers for any services when no control is set to send the PAI headers out(no PSX IPSP, SIP HTP or PrivacyProfile->passThruPrivacyInfo configured), one of the mentioned control must be set for the PAI header to go out. The “Add verstat to PAI” Flag is changed to the “Prefer PAI”, to enable sending verstat in From if PAI is not present in the egress INVITE.
2. The PrivacyParamRestricted->default anonymizes the From and Contact headers when the Privacy: user,id,header,or uri is present in the ingress INVITE. The PrivacyParamRestricted->default anonymization behaviour for privacy: id is retained even when the STI is enabled.
3. The PrivacyProfile is given preference over the STI service.
4. The SBC is not removing the “Privacy: User” header after anonymizing the From and Contact header as part of STIR/SHAKEN service, when the IPSP Privacy->Transparency is enabled and Privacy: User header is present in the ingress INVITE. This enables the downstream switch(es) to perform further anonymization.
5. The format of anonymized From and Contact headers when IPSP->Privacy->Privacy Information is P-Preferred-Id or Remote-Party-ID is retained even when the STI profile is enabled. The example below is for variantType,

Portfix SBX-94513: The Antitrombone will not have a kickstart but undesired pattern "PCR7400 Direct Media Antitrombone Call" is found in the dbg.

Impact: For a direct media call using X-dmi, the SBC is not preferring X-dmi over anti trombone direct media. This could cause one way or two way audio issue.

Root Cause: The SBC selects the Antitrombone direct media instead of X-dmi.

Steps to Replicate: 

1. Run a basic XDMI DM call
2. Run a basic DM with NAT call with XDMI
3. Run a basic Antitrombone call with XDMI enabled

Platform/Feature: SBC

Portfix SBX-96951: Unable to write to the CDR in the ATTEMPT record due to 3xx.

Impact: Run a redirect scenario and write a SMM CDR operation on the 302 message. The CDR information is not populated in the attempt record.

Root Cause: The CDR information is not being updated to CC in this scenario.

Steps to Replicate: 

1. Run a Redirect Scenario.
2. Write a SMM CDR operation on the 302 message.

Platform/Feature: SBC