SBC Core 07.02.05R009 Release Notes

V05.01.00F007

V07.01.00F003

V07.02.00R000

V07.02.01R003

V07.02.01R004

V07.02.01R007

V07.02.01R008

V06.01.00R007

V05.01.02F008

V06.02.01F007

V06.02.01F008

V06.02.01F009

V06.02.01F010

V06.02.01F012

V06.02.02R000

V06.02.02R001

V06.02.02F001

V06.02.02F002

V06.02.02F003

V06.02.02F004

V06.02.02F005

V06.02.02F006

V06.02.02F007

V06.02.02F008

V06.02.02F009

V06.02.02F010

V06.02.02F014

V06.02.03R000 

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

The SBC is converting two of the same rtpmaps into one line.

Impact: A duplicated media payload may cause a syntax error when the sdpSelectedAttribueRelay and transcodefree is sent to the other side.

Root Cause: A duplicated attribute line was merged into one line.

Steps to Replicate: Configure the sdpSelectedAttribeRelay and transcodefree. 

Platform/Feature: SBC

The SCMP coredumps occurred on the Server.

Impact: The SBC was reading off the end of a memory block while trying to copy the called and calling party host name.

Root Cause: The SBC code was copying the SIP hostname/username in the diameter code, but it was always copying a fixed number of characters regardless of the username size. This resulted in the SBC reading more memory than was allocated for the hostname.

If the memory block passed was right at the edge of process memory, then it is possible this might cause a memory exception and a coredump.

Steps to Replicate: A coredump analysis and code review.

Platform/Feature: SBC

The Bye URI Messages do not include the domain.

Impact: When the incoming INVITE contains a Contact header with a GR tag.

And the call flow is: SISBC1 -- GW - GW - GSX- ISUP. The SBC includes an IP address in the reqURI of a BYE message and do not have FQDN present in the Contact of Ingress INVITE.

Root Cause: In a GW-GW scenario where the egress GW is GSX, the SBC sends IP address in ReqURI field of BYE message.

Steps to Replicate:

1. Reproduce the issue.
When the incoming INVITE contains a Contact header with a GR tag:

And call flow is: SISBC1 -- GW - GW - GSX- ISUP, SBC includes an IP address in the reqURI of a BYE message and do not have FQDN ( present in Contact of Ingress INVITE )

2. Verify the issue.
After a fix, the SBC sends FQDN in BYE sent towards the Ingress endpoint.

Platform/Feature: SBC

Calls release cause 132 after a switchover.

Impact: The XRES uses the freed altMediaIpAddress unexpectedly in the standby XRM when the LIF is created.

Root Cause: When the standby XRM is notified with the LIF allocate request from NRS, it only receives the LIF's IP address. Any altMediaIpAddress will not be populated until the XRM has replied back to NRS. So when XRM is activating any XRES in the deferred activate list, the activation of XRES using altMediaIpAddress will be failed and freed.

Steps to Replicate: The SBC HA and SIPP call test setup:

1. Disable the keepAlive timer in the sipTrunkGroup.
2. Enable the debug INFO level logging.
3. Configure the altMediaIpAddress on LIF or LIFs if both ingress and egress legs have XRESs.
4. Configure the link detection on pkt port, threshold = 1 and enable it.
5. Make 5 basic SIP calls, call's mediaIpAddress = altMediaIpAddress, and call duration >= 20 mins.
6. Pull the cable from the pkt port, or ports if 2 pkt are interfaces involved, with link detection enabled.
7. Check the callCountStatus, wait for 5 min and plug in the cable on pkt port(s).
8. Check the callCountStatus again and wait for HA pair to finish syncing.
9. Perform a switchover again.

At step 6, the switchover triggered by link detection at step 7, 5 calls should be ACTIVE, check DBG log for following messages from XRM:

1. "XrmRedResAlloc: DEBUG! Context ID 0 XRES resId x on NIF y not allocated (on deferred list), LIF z not created"
2. "XrmNifMacAddrGet: Could not find LIF ifIndex z"
3. "XrmRedUdpAlloc: Context ID 0 Could not find UDP structure for LIF..."

At step 8, the calls should still be ACTIVE.
At step 9, the calls could be released during extensive audit, but not always.

Platform/Feature: SBC: CDR, Redundancy

The SBC7K core dumps again after the 6.2.1F010 update.

Impact: A rare race condition can cause the SamProcess to core with a Healthcheck failure when using the TLS.

Root Cause: The root cause of this issue is a rare race condition that allows one of the threads in the SamProcess to free memory, that is still being used by another thread in the same process.

Steps to Replicate: The steps cannot be reproduced.

Platform/Feature: SBC

The SBC services will not come up.

Impact: The standby fails to start and connect to the active, shutting down instead.

Root Cause: The address of the middleware checkpoint is lost and the checkpoint cannot be updated with the arrival of the new node, leading to it being shut back down.

Steps to Replicate: This is a one-off situation and can be easily reproduced.

Platform/Feature: SBC

The SBC IgnoreTransparency cannot be set on the EMA V6,7.2 and 8+.

Impact: The SBC IgnoreTransparency cannot be set on the EMA V6,7.2 and 8+.

Root Cause: There is no check whether the "not" is applied to complete expression or not.

Steps to Replicate:

1. Log into the EMA.
2. Navigate to
   All->profile->services->Transparency profile->SIP Header
3. Select the transparency profile.
4. Click on New Sip Header.
5. After that, the "Ignore Transparency " field will be visible.

Platform/Feature: SBC

Portfix SBX-95156: The SBC disconnects the call when it receives a 491.

Impact: A 491 received for a Re-Invite without an SDP was not being relayed to another Leg, even when the E2E Re-Invite and statusCode4xx6xx are enabled.

Root Cause: A 491 Relay logic is missing for the Re-Invite without SDP case.

Steps to Replicate:

1. Enable the E2E Re-Invite and the statusCode4xx6xx.
2. A 491 will be received for Re-Invite without a SDP sent.

Platform/Feature: SBC

Portfix SBX-95264: Calls stopped working after an upgrade to SBC5110 from V05.00.05F008 to V06.02.03F005.

Impact: In the X-dmi parameter, the "p=0.0.0.0" was changed to "p=" in 6.2.3F5 that was failing the parser.

Root Cause: The root trigger was the change in the IPUtilGetStr() since early 6.2 release checks the given ipAddr is a V4 or V6 address. In this case, the ipAddress was unspecified, so IPUtilGetStr() returns '\0'.

Steps to Replicate: The steps cannot be reproduced.

Platform/Feature: SBC

The 488 Response to the T38 Reinvite.

Impact: For a G.711-T.38 Fax call, if the SBC receives a G.711 reInvite with some change in SDP from ingress peer, then the SBC sends a G.711 reInvite to egress peer.

The customer expected the SBC to stay in a Fax call and not send any reInvite to the Egress peer.

Root Cause: For a G.711-T.38 Fax call, if the SBC receives a G.711 reInvite or any other reInvite that has some change in the SDP from ingress peer, then the SBC initiates offer-answer negotiation and sends G.711 or any relevant codec reInvite to egress peer. In this case, the SBC also initiates a transition from fax to voice.

Steps to Replicate: The steps cannot be replicated.

Platform/Feature: SBC

The code is modified so when the SBC detects a change in the SDP for a Fax call LEG, and if the codec active for that fax call LEG is G711 and there is no change in G711 LAW, then SBC stays in a Fax call and sends the 200OK with answer-SDP as per last offer-answer negotiation. Any change in DTMF, silence Suppress mode and any other SDP parameter is ignored.

Portfix SBX-96524: Getting the Pes Process coredump while running registrations.

Impact: Getting the Pes Process coredump while running registrations.

Root Cause: CallParamMatchName function is called with matchName which is of 15 byte array and strncpy is used to copy the string to the 50 byte array but with a wrong size of MATCH_NAME_SIZE which is defined as 30 byte*.*.

Passing bigger size than the actual destination string to strncpy is resulting in padding 0’s beyond the actual 15 bytes of the matchName. This was corrupting the stack and the stack pointer and causing a segmentation fault.

Steps to Replicate: The steps cannot be reproduced.

Platform/Feature: SBC

The SBC is not sending the RTCP to egress Peer for transcode only.

Impact: In the customer call flow:

With the Ingress Peer -(ISDN)> GSX ---(GW2GW)-> SBC --(SIP)-> Egress Peer, with the PSP setting as "transcode only" and RTCP enabled, the SBC does not send RTCP packets towards the egress.

Root Cause: Due to changes made for a previous feature SBX-6366, the SBC does not mark the XRES resource as duplex and marks it as receive only. As a result, the SBC does not send RTCP towards egress.

Steps to Replicate:

1. Reproduce the problem in following call flow:
   Ingress Peer -- SIP -- GSX -- GW2GW -- SBC -- SIP -- Egress Peer
   This transcode only call and RTCP is enabled.
   Result: No RTCP sent by the SBC to egress.
2. Verify the issue by applying SamP with GWFE change but not change in ScmP.
3. Use the same setup. RTCP traffic was sent from the SBC to egress.

Platform/Feature: SBC

Portfix SBX-89741: There was a CPX core during an upgrade from V05.01.05R000 to V07.02.01R001.

Impact: The LSWU CLI command returned in a failure due to a failure to create package sub-dir under the external directory, but the upgrade continued on the backend.

Root Cause: The upgrade script needs to be fixed here to stop the upgrade and exit if the CLI command returns with a sub-dir creation failure.

Steps to Replicate: Test the LSWU to the fix version and verify if the upgrade is successful.

Platform/Feature: SBC

Multiple switchovers causes non 5060 sipSigPorts to become inactive.

Impact: When a user configured >= 2 SIP Sig ports with same IP address but different port numbers, and they are using the same LIF group that contained 1 LIF, the pkt down triggered a switchover and it stayed down for extended time. After the pkt UP, a second switchover occurred, then only one Sig port went in service. The other Sig ports were stuck in OOS.

Root Cause: Since the pkt port was DOWN when the new standby node came back online, the SIP sig ports were restored while LIF was OOS. So address registrations were failed. After the SIPCM has reached a max number of retries, the LADDRs of the Sig ports, except the first one, were deleted in the NRS context.

When the pkt port came UP, the NRS brought LIF into service and registered the only one signaling address saved in the NRS context.

Steps to Replicate:

Test steps:
1. Configure 2 VLANs on the YF or BF pkt2.
2. Configure 4 SSPs on the first VLAN interface; 4 SSPs on the second VLAN interface. 4 SSPs use the udp/tcp port numbers 5060, 5160, 5260, and 5360 with the same IP address
3. Run the Sbxstop command.
4. Unplug the packet ports - YF pkt2
5. Run the Sbxstart command.
6. Display the SSPs on VLAN interfaces.

Platform/Feature: SBC

1. The code is modified to only delete LADDR before reaching the max number of retries.
2. Restore the pendingNrsReq flag properly when the address registration failed.

After the LDG triggered a switch over, the SBC is rejecting all the register message with a 500 internal error.

Impact: The SCM process may coredump when the SIP signaling port was being used during a SIP registration call flow is state disabled.

Root Cause: The SCM process core dumped when it attempted to display a debug warning message that contained the disabled SIP signaling port number (but encountered a NULL pointer).

Steps to Replicate: The steps cannot be reproduced.

Platform/Feature: SBC

The SCM fast memory increase causes a delayed switchover with an outage.

Impact: If a multilevel INVITE with Replaces is run, the memory and CPU utilization by the Scm Process increases drastically and leads to a core dump.

Root Cause: Each INVITE with Replaces is a new Callgroup. Each call group has its own segments. For each segment, there are associated segments.

When a Release call is invoked, it releases all segments and each call segment frees the associated call segments.
During the release flow for such a call CC_EV_ASG_DISC_CMD event is posted multiple times for various orig and term GCID’s.

Please note that this ultimately frees up everything although the memory and CPU utilization shoots up.

Steps to Replicate:

1. Test multilevel INVITE replaces (more than 15).
2. Crash will not occur.

Platform/Feature: SBC

Now in the CC state machine, the CC_EV_ASG_DISC_CMD event is not posted multiple times for the same original and term labels. This leads to drastically reducing the looping, while also ensuring that all call segments (and associated segments) are freed.

The SBC fails to relay the 18x/2xx towards the ingress when the SBC is configured to play tone.

Impact: The SBC Fails to relay the 18x/2xx in case of the MSRP call when tone is configured. The SBC tries to allocate tone Resources even though the Audio stream is not present.

Root Cause: The SBC is going for Tone allocation, even though audio stream is not present.

Steps to Replicate: Run a MSRP call with the tone configured.

Platform/Feature: SBC: Application

Portfix SBX-91871: The metavar was assigned to none.

Impact: When only one of the nodes detects a network glitch in the N:1 setup, usingMetavarsOf field of the other node is set to none.

Root Cause: A metavar response message is not sent from the node that did not detect the network glitch.

Steps to Replicate: Bring down the HA link for less than 5 seconds such that only one node detects the network glitch.

Platform/Feature: SBC

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 sessionKeepAlive is set and the SBC switched over, the SBC starts sending refresh INVITEs to the endpoints. Since this is a GW-GW setup, in such scenario's, the newly active GW-1 will send call processing messages to the GW-2. There was an issue in call processing at the 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 the call is stable, perform a switchover at the GW-1.
3. Calls will start failing

Platform/Feature: SBC