SBC Core 10.00.00R000 Release Notes

08.02.00R001

PortFix SBX-107164: Teams: The SBC should handle MOH version 2.

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

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

Steps to Replicate: Tests will require MOHv2 enabled on MS Teams client:

Test 1.
--------

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

Test 2.
--------

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

Test 3.
--------

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

Test 4.
--------

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

The above tests were also repeated in a spoke/hub setup.

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

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

Customer FTTH Stat for TG-A and TG-C Stat was not matching.

Impact: Not decrement active register count on ingress TG when refresh REGISTER is incorrect due to this there is difference in count of total stable registrations across zones.

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

Steps to Replicate: 

1. First make one active Registration.
2. After active registration send one bad refresh REGISTER.

Actual Result:

After a bad refresh REGISTER, the SBC sends 400 Bad to Refresh REGISTER and also reduces the activeRegCount on the ingress side, but it will not reduce count on egress side.

Expected Result:

The SBC should not do any count changes when refresh register fails.

Remove the check of userNPhoneCOntextKey. The check is not needed, there might be some load cases where we do not get username.

Workaround: None.

The LM (MoH) re-INVITE replied 200 OK (video inactive).

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

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

Steps to Replicate: To re-create the issue:

A<->B Direct Media call.

Configure the Latemedia support as Convert at the SBC.

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

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

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

Workaround: None.

The SBC DRBD mount was not visible on the active SBC. 

Impact: The SBC DRBD mount was not visible on the active SBC.

Root Cause: When the sbxrestart is issued from platform manager, the DRBD gets mounted on apache's mountspace.

Steps to Replicate: 

1. Bring up both the nodes.
2. Run the SBC restart from pm on active.
3. The new active must have the DRBD mounted.

The code is modified to address the issue.

Workaround: None.

The AWS IPs remain assigned to the standby SBC. Unnecessary dual restarts.

Impact: If communication between the active and standby is broken (over ha0 interface), both assume active roles (split brain). When this happens, standby node that becomes active calls AWS APIs to move IP address to self. Once the ha0 link is restored machine which becomes active does not call AWS API to move IP addresses, this might cause issue when node which has IP doesn't come up as active, in this case IPs are assigned on standby and another node becomes active.

Root Cause: Root cause of this issue is not calling AWS switchover API (move IPs) during split brain recovery.

Steps to Replicate: Do a split brain test and recovery of the SBC HA, and verify that API query is send by the active SBC after a recovery.

The code is modified to call AWS APIs to move IP to current active machine during split brain recovery path.

Workaround: Manually move all secondary IPs to current active machine to restore calls.

The Active SBC gets into 'syncInProgress' state even after recovering from network glitch.

Impact: The Active SBC gets into 'syncInProgress' state even after recovering from network glitch.

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

Steps to Replicate: 

Simulate a network glitch such that only the active SBC detects it and recovers from it.

For this, we can try this command with different sleep values between 5 and 6:
ifconfig ha0 down; sleep 5; ifconfig ha0 up.

The code is modified so the standby SBC checkfs or the sync state of the active SBC and based on that, it initiates the sync process with the active SBC.

Workaround: No workaround.

The SBC use disabled the user for a configuration import in the Profile Import/Export.

Impact: When importing the configuration using configuration import feature, a random Administrator group user is getting used.

Root Cause: The user was randomly picked regardless of the one who initiated the action in import configuration.

Steps to Replicate: 

1. Import configuration.
2. Verify audit logs to see if the configuration is imported by the same user.

The code is modified so the import is done using the same user who initiated import.

Workaround: None.

The FS errors verification can be incorrect in a pre-install or pre-upgrade scenarios.

Impact: Pre-install checks can fail to find FS errors.

Root Cause: The FS errors in the kernel log may be unable to be read if non-ascii exist or if it has been rolled.

Steps to Replicate: Write the message 'EXT3-fs error' to /dev/kmsg. Attempt to upgrade the system.

Look for FS errors from a file of errors from dmesg instead to address the issue. 

Workaround: Do not upgrade the system if the sonusCpSystemFaultyHardDiskNotify trap is triggered and is not resolved.

A T140 call - one-way stream - zero media port (NAPT media).

Impact: The call ends up in one-way audio after the called party puts the call on hold and off hold twice.

Root Cause: As a result of call-modify a couple of times, the RTCP NAPT learning completes before RTP NAPT learning.

This results in RTCP Remote Address being updated, which has remote RTCP Port.

Due to incorrect code in RTCP modify flow, remote RTCP port, gets assigned to RTP port. This results in one-way media.

Steps to Replicate: 

1. Run basic SIP to SIP call with NAPT & RTCP enabled.
2. Hold/Unhold the call a few times to check for proper 2-way audio.

Set the correct RTP Port as part of RTCP modify flow.

Workaround: Since the issue is caused to RTCP NAPT learning completed before RTP during multiple hold/unhold scenario, a workaround could be:

1. Disable RTCP or
2. Disable NAPT.

Openclovis split-brain recovery data was not always correct.

Impact: On recovery from a split brain, a leader may not be properly chosen and both machines could stay running for multiple minutes.

Root Cause: The data passed to the leader election algorithm does not properly indicate both nodes are leaders.

Steps to Replicate: Repeatedly break and reconnect the HA connection checking that the nodes realize they are coming out of split brain (via logs) and one node properly restarts to again become standby.

The code is modified so that the isLeader field is properly set and the leader election algorithm can properly detect when coming out of split brain.

Workaround: None.

Add check for /boot partition free space in the pre-checks.

Impact: Upgrade failure due to insufficient disk space on /boot partition.

Root Cause: Upgrade failed due to failure to copy the new boot images as part of upgrade due to insufficient disk space in /boot partition.

Steps to Replicate: Upgrade to the fix build and ensure upgrade is successful.

The code is modified to ensure a minimum of 40MB free disk space is available on /boot partition.

Workaround: None.

Enabling the DisableZoneLevelLoopDetection not working on ZONE level.

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

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

Steps to Replicate: 

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

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

Workaround: None.

The call ends up in one-way audio after the called party puts the call on and off hold twice.

Impact: The call ends up in one-way audio after the called party puts the call on hold and off hold twice.

Root Cause: As a result of call-modify a couple of times, the RTCP NAPT learning completes before RTP NAPT learning.

This results in RTCP Remote Address being updated, which has remote RTCP Port.

Due to incorrect code in RTCP modify flow, remote RTCP port, gets assigned to RTP port. This results in one-way media.

Steps to Replicate: 

1. Run basic SIP to SIP call with NAPT & RTCP enabled.
2. Hold/Unhold the call a few times to check for proper 2-way audio.

Set the correct RTP Port as part of RTCP modify flow.

Workaround: Since the issue is caused to RTCP NAPT learning completed before RTP during multiple hold/unhold scenario, a workaround could be:

1. Disable RTCP or
2. Disable NAPT.

The SBC Stripping SS Attribute causing the call to drop.

Impact: The SBC is not relaying the "a=silenceSupp:Off" attribute received in the answer from the UAS when the initial offer from UAC does not contain the silence suppression attribute.

Root Cause: When the answer is received from UAS with silence suppression:Off attribute present in the SDP, the egress SIPSG is able to decode the codec from the SDP as G711 only. But, while feeding this answer to NRMA, the OA-FSM is changing it to G711S causing NRMA to send the same codec information to the ingress SIPSG. Due to this, the SBC is not sending the attribute in the answer towards the UAC.

The logic in OA-FSM is such that, if the SBC offers a single codec(which is G711S) towards UAS and if it receives a single codec in the answer(G711), then it feeds the NRMA with the offered codec as an answer to NRMA. In this case, the egress OA-FSM is sending G711S as an answer when 200 OK is received from UAS instead of G711.

Steps to Replicate: 

1. Enable "Include SS Attribute in the initial invite" in the IPSP.
2. Include “a=silenceSupp:off” in the SDP of 200 OK.
3. Run a basic call with G711SS codec.

The code is modified to match and feed the right codec that is received from the Peer towards NRMA

Workaround: None.

The diameter RX inputted the wrong data in media-component AVP post T.38-488.

Impact: On detecting the fax tone, the SBC sends a T38 re-INVITE towards end point and at that time it triggers preliminary AAR with T38 Codec-Data AVP. When receiving a 488 for T38 Re-INVITE, a fallback occurs and the SBC triggers the G711 re-INVITE from SIPSG. And when receiving a 200 OK for re-INVITE, the SBC should send the final AAR with offer and answer the codec-data AVP having G711 (last negotiated). Instead of sending the final AAR offer, the SBC was sending g711 in answer codec-data AVP and T38 in offer codec-data AVP, which is wrong.

Root Cause: On getting 488 for T.38 Re-INVITE, a fallback to the G711 occurs at SIPSG itself and on getting 200 OK for G711 re-INVITE.

Steps to Replicate: 

1. Configure PSPs for faxfallback and enable Rx feature.
2. Run transcode call (A(PCMA) and B(PCMU)).
3. B sends fax tone, on detecting fax tone SBC sends T.38 Re-INVITE towards A and A rejects with 488.
4. A fallback occurs, the SBC sends G711 re-INVITE towards A and gets 200 OK. On getting a 200 OK. The SBC sends final AAR that should contain last negotiated SDP information.

The code is modified so the SBC sends the last negotiated SDP information in offer and answer codec-data AVPs of final AAR, so added fix for this.

Workaround: Not applicable.

The SBC is not passing URI parameter while History to Diversion interworking.

Impact: The SBC is not passing URI parameter user=phone while History to Diversion interworking, though the parameter is present in History Info

Root Cause: There was no support for the requested functionality was present until date. Most likely, it was a miss due to lack of requirements.

Steps to Replicate: 

1. On the ingress leg, enable the acceptHistoryInfo.
2. On the egress leg, enable the diversionHistoryInfoInterworking.

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

Workaround: None.

There was an SCM process coredump for the healthcheck.

Impact: The SCM Process cored when too many set operations executed in a single commit.

Root Cause: The SIPSG task takes longer than 10 sec when subscribing the changes made to TrunkGroup.

Steps to Replicate: Configured 12 TG. Modify 11 TG in a single commit CLI will throw following error:

Aborted: 'addressContext default zone ZONE_IAD sipTrunkGroup': Too many set operations between commits. Revert the session and retry(max set operations 10).

Again modify 10 TG in single commit.
O/P: commit complete

The code is modified to 10. Previously, it was 50.

Workaround: It is recommended to perform a commit after each single commit.

Move the dmesg monitoring from the SM to a platform cronjob.

Impact: Move the dmesg monitoring from the SM to a platform cronjob.

Root Cause: On the long running, the SBCs since dmseg can be big and can take longer to dump logs, the function can take longer and can cause the SM healthcheck.

Steps to Replicate: Check for "/var/log/sonus/tmp/dmesgErrorMarker.tmp" after manually running the script.

Developed a new script to run every minute as a cron job to find i/o and filesystem errors in dmesg. If error is found, it creates a marker file in tmp that can be later used by other script to check sanity of the system.

Workaround: None.

The time zone is defaulting to EST/EDT on the SBC instances while using image based instantiation.

Impact: The time zone is defaulting to EST/EDT on the SBC instances while using image based instantiation.

Root Cause: The timezone value in sbx.conf is not being picked up and used to update ntp xml and /etc/timezone.

Steps to Replicate: Launch instance with timezone other than default timezone. It should show the appropriate timezone.

Update timezone value from sbx.conf in ntp xml and set /etc/timezone.

Workaround: None.

The incorrect appVersion is getting displayed after upgrading the SBC Cluster from V08.02.04R000 to V10.00.00A008.

Impact: The incorrect app version is showing on the rgstatus in case of split brain.

Root Cause: The older serf event is processed and used for updating the join time.

Steps to Replicate: Upgrade to 10x from 8.2 so in case split brain occurs, the rgstatus should not show incorrect version.

The code is modified to not process serf events until 5 seconds delay after member join event is processed.

Workaround: None.

The call flow does not work when using six streams (5 video + 1 audio).

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

Root Cause: Memory allocated for this SDP was not enough during the inter process communication resulted in the failure.

Steps to Replicate: Test requires ingress TG in Zone1, egress TG in Zone2 and AS TG on the SBC, with call to be routed as follows:

UE1 -> ingress TG -> AS TG -> AS peer (sipp) -> AS TG - egress TG -> UE2
Enable Direct Media on the ingress and egress TGs (but not on AS TG):
TG - media directMediaAllowed enable
PSP for all TG's should have DM flag enabled
PSP - flags useDirectMedia enable
Enable ICE (webrtc) on the ingress and egress TGs:
TG - services natTraversal iceSupport iceWebrtc
Enable DTLS on the ingress and egress. TGs and PSPs
TG - media dtlsProfileName defaultDtlsProfile
PSP - dtlsCryptoSuiteProfile DEFAULT enableDtlsSrtp enable
Set the directMediaGroupId on ingress and egress TGs to be same e.g. 200 and AS to be different e.g. 400
e.g. TG - media directMediaGroupId 200
Enable Direct Media Anti Trombone on AS TG:
TG - media directMediaAntiTrombone enable

Steps:

1. From UE1 send an INVITE with ICE and DTLS in the SDP with 5 video and 1 audio stream to ingress TG and route towards the AS TG.
2. From the AS send back an INVITE to AS TG of the SBC, the C line of the sent SDP must match the C line of the received SDP.
3. From UE2, send 180 with no SDP followed by 200 OK with ICE and DTLS in the SDP (UE2-sdp 1 audio and 5 video).
4. From the AS send the 180 followed by 200 OK back towards the SBC.

Expected Result: The call succeeds.

Actual Result: The call fails.

The code is modified to accommodate six streams.

Workaround: None.

The SBC sends re-INVITE while the media is played on ingress side in GW-GW early media call.

Impact: In a GW-GW call scenario, while the media is played on ingress Gateway, the egress SBC is sending a Re-INV to UAS.

Root Cause: Before the ingress GW completes its end to end activation, it received a MODIFY OFFER request from egress GW due to the change in SDP received in 200 OK for lockdown INV. This caused the ingress GW to process modify offer first and then end to end activation later that triggered a Re-INV towards UAS.

Steps to Replicate: 

1. Send INV from UAC to GW1.
2. GW2 sends INV to UAS.
3. UAS sends 180 SDP.
4. GW1 sends 180 SDP to UAC and starts play tone.
5. UAS sends 200 OK with out SDP.
6. GW1 sends 200 OK to UAC.
7. GW2 sends ACK and triggers a lock down INV.
8. UAS sends 200 OK with change in SDP.

The code is modified so while the modify offer-answer is handled properly during end to end activation.

Workaround: None.

The term side had a disconnect issue.

Impact: For redirection scenario, re-INVITE is sent out by the SBC to redirected server under following condition:

1. Enhanced Local Redirection flag is enabled.
2. Number of routes set are more than one.
3. BYE is received by the UAS side.

Root Cause: When the Enhanced local redirection flag is enabled, re-INVITE was generated to redirected endpoint even after call is cleared (i.e. discReason set to CPC_DISC_NORMAL_CALL_CLEARING).

Steps to Replicate: Procedure:

1. Configure the SBC for basic call.
2. Configure more then one numRoutes.
3. Enable the Enhanced Local Redirection flag at Ingress IPSP.
   set profiles signaling ipSignalingProfile DEFAULT_SIP egressIpAttributes redirect flags enhancedLocalRedirection enable
4. Make a redirect call.
5. Send Bye from UAS side.

The code is modified to fix the issue by adding discReason check of CPC_DISC_WITH_NEW_DESTINATION in addition to Enhanced Local Redirection flag check.

Workaround: None.

While expecting the 200 OK, the SBC is sending 503 Service Unavailable.

Impact: In a late media convert call scenario with LRBT enabled, the SBC is sending 503 service unavailable when connect is received from egress EP.

Root Cause: The SBC was trying to initiate an UPDATE without checking whether it has received SDP in the PRACK from the ingress Peer that is resulting in the call failure.

Steps to Replicate: The LRBT is enabled on the ingress Trunk.

1. UAC sent LM INV to the SBC.
2. The SBC sent INV with PCMU, PCMA, G729 to UAS.
3. UAS sent 180 with PCMU to UAC.
4. UAC sent PRACK without SDP.
5. UAS sent 200 OK with same SDP as that of last 180.

The code is modified to check whether the SBC is received any SDP from the peer, so that, the call establishment occurs successfully.

Workaround: None.

The SBC Product name is incorrect for the SBC on AWS in release 10.0.

Impact: The sbcDiagnostic incorrectly prints product name as "ConnexIP5000" instead of "AWS".

Root Cause: Platform type is determined by querying platform data using dmidecode command, due a bug in the query platform type is returned as unknown. As a result of this bug, the sbcDaignostic shows generic product name ("ConnexIP5000").

Steps to Replicate: Run sbcDiagnostic command from Linux shell of the SBC. It shows the following:

************SBC Information *********
.......
.....
SBC Product Name: ConnexIP5000

After fix it prints:

************SBC Information *********
.......
.....
The SBC Product Name: AWS

The code is modified to return correct platform type.

Workaround: No workaround.

The SBC SmProcess leak on OAM active for MRFP SWO

Impact: While carrying out operations like a config upload to EMS, memory is leaked.

Root Cause: The Python/C APIs cause a memory leak while using functions to the upload/download configuration from the EMS.

Steps to Replicate: Create a direct single instance (ASAN build) registered with the EMS, carry out operations saveAndActivate/restoreRevision and change glog/sanitizer_SmProcess* and verify there no leaks due to the operation above.

Change the implementation from using Python/C APIs to libcurl.

Workaround: NA

The CE_2N_Comp_CpxAppProc leak during disable and enable of pkt port

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

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

Steps to Replicate: Create an MRFP instance where metavars are used to define the IP value for the H248 signaling port.

The code is modified to correctly free the memory block at the end of processing the signaling port creation.

Workaround: None.

The IPv6 SBC traps are not received to the EMS.

Impact: For trapTargets, certain IPv6 addresses are sent to the incorrect IPv6 address.

Root Cause: If the IPv6 address, converted to the form of 16 decimal octets was separated by periods have a length greater than 47 digits, the address will be truncated.
Example:
fd:0:0:10:6b:50:61:b0:61:b0:61:b0:0:0:61:b0
will be converted to
253.0.0.16.107.80.97.176.97.176.97.176.0.0.97.176
Which will be truncated to 47 characters
253.0.0.16.107.80.97.176.97.176.97.176.0.0.97.1

Steps to Replicate: Provision an OAM SNMP trapTarget with an address of 253.0.0.16.107.80.97.176.97.176.97.176.0.0.97.176
Observer in the tailf snmp.log that the actual address sent to is:
253.0.0.16.107.80.97.176.97.176.97.176.0.0.97.1

The code is modified so the IPv6 string is stored in a buffer of 64 characters that accommodates any IPv6 address.

Workaround: None.

LeakSanitizer:SCMP_3 gave memory leaks at MemAlloc2 and the same gave Heap overflow issue, both from the same caseID.

Impact: The Heap use after free detected in the ASAN for a downstream forking call flow.
Accessing memory after it has been freed can cause unexpected behavior and in the worst case, potentially cause coredumps.

Root Cause: When copying multiple contacts from a different downstream forking response, the username of the contact header was not updated from the call block to sip message handle. The SIP Message handle was holding an address that was already freed.

Steps to Replicate: Run Downstream Forking Call Scenario as shown below:

1. UE sends Initial INVITE towards UAS through the SBC.
2. The SBC receives multiple 18x with different to tag and different username in the Contact header.
3. The SBC receives 200 OK for any of the downstream forking dialog.

The code is modified with the correct username from the call block for every downstream forking response.

Workaround: None.

SBC: Observed MAJOR logs for BRM "BrmAsyncCmdErrHdlr" on T140 load.

Impact: Occasionally enable the RID errors in NP when the system is subjected to large number of call flows that employ RTCP termination.

Root Cause: The message drops in internal queues due to momentary congestion.

Steps to Replicate: Run an SBC AMRWB<>T140 full load with the RTCP enabled.

Ensure the control messages experience a larger queue depth while traversing internal queues.

Workaround: No workaround.

SBC: Deleting VMG and adding it again with same IP and Port from OAM node throws an error "Signaling Ip and Port must be Unique"

Impact: Deleting the VMG and adding it again with the same IP and Port from OAM node throws an error "Signaling Ip and Port must be Unique".

This was happening because the check for uniqueness for an IP port was not being executed as metavar support for delete operation code was not done.

Root Cause:This is a day 1 issue. Since the metavar was introduced, the delete operation for h248sigport was not taken care of (meaning code was not there). This support was given in 9.2 onwards.

Steps to Replicate: Use metaVar for adding ip+port h248sigport for VMG -> adds to h248SigPortAddrMeta

Delete the added entries --> deleted from h248SigPortAddrMeta

Add the same IP+PORT combination again --> this operation should let the user to add the entries again because the earlier entry is deleted from the "h248SigPortAddrMeta". As a result, there is no duplicate, and uniqueness is maintained.

This should not throw any error.

When the h248sigport is added (or deleted), it is usually done as a IP+PORT combination.(both being mandatory fields).

So while adding h248sigport for VMG, the IP+PORT is added to a metatable named "h248SigPortAddrMeta". This table is used to maintain the uniqueness of the IP+PORT added. So, whenever any h248sigport is added, the IP+PORT combination is stored in "h248SigPortAddrMeta". And when deleted from the CLI, the corresponding entry is deleted from the table as well. This is done to maintain the uniqueness, so that user does not to add the same h248sigport with same IP and port.

The code is modified as the input was not taken care of, hence the validation from "h248SigPortAddrMeta" was also not occurring. As a result, the error "Signaling Ip and Port must be Unique" was encountered.

Workaround: There is no workaround. This is a straightforward test of adding and deleted the h248sigport for VMG using metaVar

The dual hold "Music on hold" inter lab failed when both user logins were on secure PCC.

Impact: The "Music on hold" failed when both the user login on a secure PCC with "error opening media".

Root Cause: The SBC was sending all the crypto choices in the response instead of only common crypto if a request was coming from the egress side.

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

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

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

The code is modified to send only one single common crypto in the SDP instead of sending all crypto.

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

The CpxUpgradePersistentMacAddressStatus: will move 0 entries to new table macAddress2Status.

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

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

Steps to Replicate: Run the LSWU calls.

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

Workaround: None

SBC: Switchover to the standby was not successful when the active node dumped core and went for deadlock.

Impact: A switchover does not get triggered in the case of an abnormal termination of the CPX and PRS process.

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

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

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

Workaround: No workaround.

The AddressSanitizer: detected a heap-use-after-free on address 0x60f000047d38 at pc 0x562fcd2973a5 bp 0x7f3963983f40 sp 0x7f3963983f38 READ of size 20 at 0x60f000047d38 thread T7

Impact: ASAN reported an issue trying access a structure pointer, which is freed already.

Root Cause: The SBC is trying to access structure pointer to get socket address, but that structure pointer is already freed in other function.

Steps to Replicate: Use ASAN build for testing:

1. Send an INVITE from UserA, respond from DNS1 with RCODE error 4 for A query and respond from DNS2 with RCODE 0 with proper DNS answer for A query and check dnsServerStatistics.
2. Run a show command to check the dnsFallback flag and ednsFailures stats
   show addressContext <addressContext_Name> dnsGroup <dnsGroup_Name> dnsFallback
   "show table addressContext default dnsGroup <dnsGroup_Name> dnsServerStatistics"

The code is modified so now a user gets the socket address from pstSrcAddr structure.

Workaround: None

AWS: Observing that metaVariable table is getting modified on loading the backup config file of one instance in other instance.

Impact: When loading the backup configuration from one SBC instance to another, the metavar table is getting populated with the list of metavars from both instances. This by itself does not cause any issues so long as the metavars are unique, its just confusing to see the metavars for another instance in the table.

Root Cause: The code was not removing the existing metavars prior to loading the configuration of another instance. This meant the metavar table had both sets of information.

Steps to Replicate: 

1. Create a backup configuration of one cloud instance (instance1).
2. Loaded the backup config file into a new cloud instance (instance2).
3. Check the metaVariables table and see if it contains the metavars from both instances.

The code is modified to flush the metavars for the existing instance prior to loading the configuration from another instance.

Workaround: None.

There was an EMA display error when the SMM was deleted through the CLI.

Impact: There was an EMA display error when the SMM was deleted through the CLI.

Root Cause: In the EMA, we are checking the ordering of the rules. If the Order is not continuous, then we are throwing the error.

Steps to Replicate: 

1. Log on to the EMA.
2. Navigate to Profiles > Signaling > SIP Adaptor Profile.
3. Select one SMM rule and try to edit it.
4. There we do not find the error if the rules are not continuous.

Removed that code to correct the issue.

Workaround: NA.

The LeakSanitizer: detected memory leaks Direct leak of 883820 byte(s) in 413 object(s)

Impact: The SBC was not freeing memory in one of the failure cases.

Root Cause: The SBC was not freeing memory in few cases where incoming INVITE handling fails.

Steps to Replicate: 

1. Send an INVITE with Replaces having call id, to in the Replaces header that does not match to any existing leg.
2. After the call ends, the ASAN should not show memory leak.

The code is modified to free up memory allocated, in all cases when the INVITE handling fails.

Workaround: NA

The Serf event processor is unable to restart because the restart check marker file is not getting removed.

Impact: The Serf event processor is unable to restart because the restart check marker file is not getting removed.

Root Cause: The restart check marker was only being removed if serfeventProcessor starts successfully, so if it fails to start, any attempts to restart it would be prevented because the marker is not removed.

Steps to Replicate: 

1. Make the serf event processor fail at some point.
2. It should try to restart upto 5 times if it keeps failing to come up.

The code is modified to allow time for the serfEventProcessor to start so that the user can attempt a restart.

Workaround: None.

[ASAN]: sanitizer.CE_2N_Comp_ScmProcess_2.30828:==CE_2N_Comp_ScmProcess_2==30828==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61b00008dc88 at pc 0x5621c53c6946 bp 0x7f9854100bc0 sp 0x7f9854100bb8

Impact: While running a INVITE CANCEL Proxy Call, the UAS observed a Address Sanitizer leak in SCM process and the SBC services stopped.

Root Cause: Issue in parsing string when string is blank and very large that lead to a heap buffer overflow.

i.e Via: SIP/2.0/UDP 10.54.48.31:7009;sigcomp-id=" LWS "

When the token length becomes large (i.e. a LWS length of 100) and the token length point is outside the PDU, we will see this issue.

Steps to Replicate: Send INVITE with a VIA header as the last header.

The code is modified to use temptokLen instead of the tokLen. As a result, the tokLen does not reach outside the PDU.

Workaround: The VIA header should not be last header, and the empty token string should be small.

Portfix SBX-105261: The Media Stats are not correct when a DLRBT profile is removed from TGs and ICE is enabled.

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

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

Steps to Replicate: On an SBC configured as MS Teams LMO centralized mode with ICE on MS Teams TG, run the following steps to reproduce the issue:

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

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

Workaround: The DLRBT should be enabled.

The SbcSftp throws an error as "Failed to add ACL".

Impact: The sbcsftp application does not remove the ACL created correctly.

Root Cause: The permissions to delete the ACL gets lost while lowering permissions to ensure the sbcsftp can only access the current user's files.

Steps to Replicate: 

1. Run SbcSftp as linuxadmin. Verify no 'Failed setting permissions' error messages appear.
2. Verify Cleanup Script:
   1. Run SbcSftp but kill the the process before it completes.
   2. As root, get the name of the ACL.
   3. Wait 15 minutes.
   4. Verify ACL removed.

The code is modified so that we can raise the permissions again once SFTP is complete.

Workaround: None.

A runtime error: signed integer overflow: 2002002002 * 10 cannot be represented in type 'int'

Impact: A runtime error is seen in the SAM process. When an INVITE is sent out and response code received is very large, we will see the issue: Runtime error: signed integer overflow: cannot be represented in type 'int'.

Root Cause: When the SIP Response code is very large, there is a signed integer overflow during the processing of the SIP PDU.

Steps to Replicate: An INVITE is sent out to the egress.
If the response code received is very large, the issue is seen.

The code is modified so if the SIP response is greater than or equal to max response code, the SBC throws an error.

Workaround: None

SBC cored while running UAS Notify Request.

Impact: The SBC coredumps while processing the UAS Notify Request with the XML body.

Root Cause: In API SipsCheckForAnyBody(), the loop that the string pointer pch is incremented each time was being accessed before validating for the boundary condition that caused the crash.

Steps to Replicate: Send a NOTIFY with XML body from UAC towards the SBC.

The code is modified to add a check before accessing the pointer value.

Workaround: None.

The AddressSanitizer: detected SEGV on unknown address 0x000000000028 (pc 0x55810d4c1823 bp 0x7f6227387c30 sp 0x7f62273873c0 T9)

Impact: During Preparsing the Messagebody, the SEGV on an unknown address is observed in SipsPreParseMsgBody().

Root Cause: When the Content-Type is NULL during a strcaseCmp, there is no NULL check for a HeaderField value and as a result, this issue is seen during strcasecmp(pstGenericVal->pchHdrFieldValue, "multipart/mixed").

Steps to Replicate:

1. Make an A to B call.
2. Send a re-INVITE with the MessageBody Content-Type as empty.

The code is modified to address the issue.

Workaround: None.

The runtime error: index 20 out of bounds for type 'sip_nameval_str [20]'.

Impact: When the Publish message is received with 20 params in the Contact Header, the SBC throws a runtime error: index 20 out of bounds for type 'sip_nameval_str.

Root Cause: The param check for boundary condition was missing while parsing the contact header. While it was checking, the number of params should be less than 20, but the condition to handle number of params is not specified.

Steps to Replicate: The steps cannot be reproduced.

The code is modified so if the number of params is 20, the SBC should throw a parse error.

Workaround: None.

The TapId of ingress target was not getting embedded in CCID for IMSLI (both leg interception).

Impact: When both leg interception is enabled for Out Of Dialog messages for IMSLI flavor, the X2 messages corresponding to the ingress leg that are sent towards Mediation server have TapId of Egress as a target instead of TapId of Ingress Target embedded in the Correlation-ID (CCID) and in the TAP ID AVP field (202).

Root Cause: The SBC always stored only one tapId, the TapId present in 0th index of the LI criteria table that is returned by PSX as part of policy OUTPUT.

When both legs are intercepted, 0th index in the above said criteria table will have Egress target information. As a result, whenever both legs are intercepted for OOD messages, the TapId of Egress target is always embedded in CCID for X2 messages corresponding to ingress leg.

Steps to Replicate: Procedure:

1. Configure the SBC with the PSX and EMA for basic call.
2. Configure the IMSLI for both Leg and set targets using EMA with different tapId.
3. Make a subscribe request with the same targets configured.
4. Verify that TapId received for both legs are correct.

The code is modified to store and process the TapId of the second target criteria (Ingress Leg).

Workaround: None.

Security, Audit and other logs are modifiable (including deletion)

Impact: The admin can delete and modify evlog files.

Root Cause: Users belonging to upload group(like admin) had write access on the evlog dir, which allows them to delete/modify log files.

Steps to Replicate: Log into the sftp into evlog dir using admin and try modifying/deleting log files.

The code is modified that prevents the admin from having writing access on the files owned by other users.

Workaround: None.

The SBC incorrectly formatting the rport in a VIA header.

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

Root Cause: The code does not check if a rport has some valid port number or not. If a rport is the last parameter in VIA header, it appends "=<source port>".

Steps to Replicate: 

1. Setup: Run a SIPp - SBC- SIPp.
2. Send a Register message with "rport=1111" in a VIA header from client SIPp script with to the SBC. "rport" is at the end of VIA header.
3. Run the client script with -p 30333.
4. Verify that the SBC replaces rport port number (1111) with its own rport (30333) in a VIA header of 200 OK response.
   
   
   

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

Workaround: The following SMM can be used as a work around:

set profiles signaling sipAdaptorProfile HeaderModifications rule 1 applyMatchHeader one

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

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

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

set profiles signaling sipAdaptorProfile HeaderModifications rule 1 action 1 headerInfo headerValue

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

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

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

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

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

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

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

set profiles signaling sipAdaptorProfile HeaderModifications rule 1 action 3 operation modify

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

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

CPU resources are allocated without complete utilization of GPU resources

Impact: The CPU DSPs are getting utilized for GPU supported codecs without complete utilization of GPU resources.

Root Cause: Changes introduced to change the behavior of the NRMA to request the DRM to allocate the first codec in the egress PSP. If the egress peer responds with a different codec, the NRMA checks if the existing allocation supports the new codec. If it does, then the same DSP resource is reused for the call.

The side effect of the case above for hybrid transcoding is the following:

If the first codec in the PSP is a CPU based codec, then the DSP resource will be taken from a CPU UXPAD. If the response from the egress peer is for a different codec, the same CPU UXPAD resource will be reused since CPU UXPADs support all codecs. Because of this, CPU UXPADs can potentially be used for GPU codecs.

Steps to Replicate: 

1. If system has support for GPU DSP, have 1st codec entry in Egress PSP as ILBC (cpu codec) so that DSP is allocated for ILBC. The Egress Peer answers with a GPU codec like G729. Ensure that the CPU XPAD allocated for ILBC does not get reused for G729. A GPU DSP for G729 must be allocated and ILBC CPU Dsp must be freed.
2. If the system supports only CPU DSP and 1st codec entry in Egress PSP is ILBC (cpu codec), the DSP allocated on egress leg will be for ILBC. If egress peer answers with a GPU supported codec like G729, the previously allocated DSP for ILBC must get reused as it supports G729 also.

The code is modified so if the system is detected to be in gpuMode (has support for GPU DSP), then for CPU codecs also the DSP is allocated with support for only requested codec and G711/SS as it is done in case of a GPU codec. In this case, when the egress peer replies with a GPU codec a new GPU DSP needs to be allocated as the previously allocated CPU channel cannot support the new codec

Workaround: None.

CDR issues for non-INVITE messages when blacklisting is involved.

Impact: In case of handling of failure responses for non-INVITE messages, before writing the CDR for current failure cause code, the SBC was finding out next route and sending a message on network.

This worked fine in normal cases as after sending out a request, the response was processed later, after writing a CDR for current failure response.

However in a backlisted entry case, no actual message is sent out, so the blacklisted entry CDR was written before the previous CDR response code.

Root Cause: Whenever a blacklisted entry was involved, the CDR entries were messed up for this blacklisted entry and the previous entry.

Steps to Replicate: Configure Routes for non-INVITE as follows:

R1
R2 - > Blacklisted
R3
R4 -> Blacklisted

The CDR's should be printed in order R1, R2, R3, R4 after a fix.

The code is modified to write the CDR for the current failure response code, and later find next route and send a request on the new route.

Workaround: NA

The SBC adding RR and RS attributes twice in the egress INVITE when multiple m lines present in SDP

Impact: The SBC was adding RR and RS attributes twice in the egress INVITE when multiple m lines present in a SDP.

Root Cause: The SBC is not setting the default value of M lines present in SDP when number of lines is greater than 1 and as a result, the SIPS value is getting added.

Steps to Replicate: Configure these:

set profiles media packetServiceProfile DEFAULT rtcpOptions rtcp enable

set profiles signaling ipSignalingProfile DEFAULT_SIP commonIpAttributes flags sendRTCPBandwidthInfo enable
set profiles signaling ipSignalingProfile DEFAULT_SIP commonIpAttributes flags sendRtcpPortInSdp enable
comm

set addressContext default zone ZONE_EGRESS sipTrunkGroup TG__EGRESS media multipleAudioStreamsSupport enabled
set addressContext default zone ZONE_INGRESS sipTrunkGroup TG_INGRESS media multipleAudioStreamsSupport enabled
comm

An incoming INVITE has multiple Audio line with:
b=RS:250
b=RR:250

The code is modified so that if value is set to default and it is not getting modified, the SIP does not send the RR and RS value twice.

Workaround: Enable sdpAttributesSelectiveRelay to prevent the SBC from sending RR and RS twice.

Set the FAC as enabled by default.

Impact: The FAC was enabled by default in 9.2, but was disabled in release 9.2.1. FAC is reverted back to being enabled by default in future releases of 9.2.x and 10.0.

Root Cause: The FAC was temporarily disabled by default until performance issues were fixed.

Steps to Replicate: Run the FAC impacts performance on high cps, and perform load test.

The code is modified so the shared memory is used instead of memory mapped files.

Workaround: Keep the FAC disabled if using high cps until you upgrade the SBC to a fixed version.

Resize the log volume on every boot.

Impact: The log volume is not being resized on every boot.

Root Cause: Currently, we build the filesystem on cinder volume only on the first boot.

Steps to Replicate: 

1. Create and attached a cinder volume of 50 GB.
2. Bring down the SBC, resized cinder volume to 100GB.
3. Launch the SBC with the cinder volume attached.

Check if the cinder volume is resized to 100GB.

The code is modified to check if file system is already built. If the file system is not built, the volume is resized.

Workaround: None.

A revision not present in the OAM or EMS, upon doing restore error should be thrown.

Impact: Not showing the proper failed message when failing to download from the EMS.

Root Cause: The confd was not waiting for the EMS download error as the EMS download was done in a different thread context.

Steps to Replicate: Case 1:

1. Create 3 revisions on the EMS.
2. Delete the second revision on the OAM and EMS.
3. Request the system admin vsbcSystem restoreRevision revision 2.
   o/p
   admin@Rahul-OAM1-192.168.20.13% request system admin vsbcSystem restoreRevision revision 2.
   This command will restart all nodes unless the target revision is for a previous version of software. Do you want to continue [yes,no] yes
   result failure reason bundle not found locally or on EMS, unable to view changes for this revision
4. See the above failure message and no restart of nodes.

Case 2:

1. Create 3 revisions on the EMS.
2. Delete the second revision on the OAM.
3. Request the system admin vsbcSystem restoreRevision revision 2.
4. Will observe a restart in all nodes.

Case 3:

1. Create 3 revisions on the EMS.
2. Delete the second revision on the EMS.
3. Request the system admin vsbcSystem restoreRevision revision 2.
4. Will observe a restart in all nodes.

The code is modified to run the restoreRevision procedure on the same thread context and help to display proper error in case of a failure.

Workaround: None.

Wrong warning message on a Direct-SBC while doing a restore.

Impact: The wrong warning message played during a restoreRevision.

Root Cause: Rewording of the text message required when restorerevision was invoked.

Steps to Replicate: 

1. A new image was created after changes.
2. With new csar file was loaded to VNF Manager.
3. Created 2 revision on the EMS.
4. Run the command "request system admin vsbcSystem restoreRevision revision 1".
   test output
   admin@Rah-OAM1-192.xxx.xx.x% request system admin vsbcSystem restoreRevision revision 1
   This command will restart all nodes unless the target revision is for a previous version of software. Do you want to continue [yes,no]

The code is modified to reword the text messages.

Workaround: None.

There were customer coverity issues part2.

Impact: While processing SUBSCRIBE messages, the coverity tool has highlighted that the code could dereference a pointer that is potentially NULL. Although no bad behavior has been observed during testing, there is a small chance that it could result in coredumps if the pointer really was NULL.

Root Cause: Based on other validation in the code, the coverity highlighted that some legs of code could result in accessing a pointer that might be NULL. Derefencing NULL pointers can cause unexpected behavior and in the worst case coredumps.

Steps to Replicate: Run various SUBSCRIBE related test cases.

The code is modified to validate that the pointer is not NULL before using it to avoid any potential issues/coredumps.

Workaround: None.

The CDR field is not populated even though the SBC writes the value to CDR field for '200 Ok of BYE' received/sent.

Impact: After SMM manipulation, the SBC writes the value to CDR field as seen in the DBG but the CDR field ‘STOP’ record is empty.

Root Cause: The logic to write the ACT file for the incoming 200 OK of Bye was absent.

Steps to Replicate: 

1. Attach the SMM profile to modify the 200OK of BYE on Egress TG as input Adaptor profile and output Adaptor Profile.
2. Enable endToEndBye flag under ipSignalingProfile.
3. Run a basic A-B call.

The code is modified to fill the stop record for the incoming 200OK of BYE for the SMM CDR fields.

Workaround: Attach the SMM to BYE instead of the 200OK of BYE.

An error is thrown on EMA while configuring the SMM Profile having messageBody criteria with regex.

Impact: An error is thrown on the EMA while configuring the SMM Profile having messageBody criteria with a regex.

Root Cause: The EMA assumes that the Num Match was a mandatory field but it is an optional field (user may enter that value or he may not).

Steps to Replicate: 

1. Log into the EMA.
2. Navigate profile -> signaling -> sip adaptor profile.
3. Create the profile that should have a num match value and after that delete num Match value from the CLI.
4. Now you cannot see the issue.

The code is modified to make the Num Match field optional.

Workaround: None.

Reject Invite with 100Rel when TG flag rel100Support is disabled and E2E Prack is disable on that leg after PSX DIP

Impact: The SBC does not tear down the call if the INVITE contains a Require: 100rel and the rel100Support flag is disabled on the ingress sipTrunkGroup, as per RFC3262.

Root Cause: When the rel100Support flag is disabled and INVITE contains Require: 100rel, the SBC was not rejecting the Invite with 420 Bad extension. This scenario was not handled.

Steps to Replicate: Set this flag:
set addressContext default zone ZONE_IAD sipTrunkGroup TG_IAD signaling rel100Support disabled

When the INVITE is received with Require: 100rel and endToEndPrack is disabled, the SBC should reject the call with a 420 Bad extension and the SBC should send header Unsupported :100rel toward the ingress.

The code is modified so that when rel100Support flag is disabled and endToEndPrack is disabled.

If the INVITE contains a Require: 100rel, the SBC will reject the INVITE with 420 Bad extension and the SBC will send header Unsupported :100rel toward the ingress.

Workaround: None.

The AddressSanitizer: detected a heap-use-after-free on the address 0x6200000373c8 at pc 0x560aae46bf67 bp 0x7fc9bc717850 sp 0x7fc9bc717848.

Impact: The ASAN detected "AddressSanitizer: heap-use-after-free" when accessing a To tag from the message handle.

Root Cause: Accessed a ToTag from the message handle after it is freed.

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

The code is modified to access the To tag before freeing it.

Workaround: Not Applicable.

The AMRWB encoder produces a corrupted output when channel is reused by lower mode.

Impact: Audio is degraded in the AMRWB stream when the AMRWB (GPU) call load is running, particularly when each call uses a different bitrate.

Root Cause: The problem occurs when the same codec context is reused and the previous used was for a higher bitrate. The root cause was identified due to reinitialization logic for an internal buffer.

Steps to Replicate: 

1. Set sweActiveProfile to use GPU and sweCodecMixProfile to use AMRWB.
2. Make the AMRWB to G711U call load using multiple AMRWB clients, each client using different mode.

RESULT:
Some of the calls may have degraded audio in AMRWB stream.

The code is modified to appropriately reinitialize the internal buffer.

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

PortFix SBX-104619: The FM process cored.

Impact: The FM Process crashed and wrote a coredump.

Root Cause: The FM Process tried to read the /proc/meminfo file, which should always exist, but it got a file not found error.

Steps to Replicate: It is not known how to reproduce this issue, and the defensive code added to prevent a NULL read/write.

The code is modified to return the last good value read instead of a NULL to prevent the crash.

Workaround: None.

PortFix SBX-106815: The PES Process was leaking memory.

Impact: In certain circumstance with high enough call rate, the SBC may experience PES memory leak.

Root Cause: The newly ported Postgres code mishandled Postgres DATABASE cursor and counter.

Steps to Replicate: The memory leak was not reproduced in house. This problem had been found and reproduced in customer lab, when they were testing call load. A private fix has been tested in customer lab as well.

The code is modified in cursor and counter area.

Workaround: There was a lower call rate should lower the risk.

PortFix SBX-105598: The Native Forking and DLRBT were not working.

Impact: With Native Forking enabled, if the call is answered by Teams endpoint, the call gets released by the SBC.

Root Cause: Two Reasons for Forking and DLRBT calls to fail for TEAMS endpoint.

1. With ICE Learning enabled, binding resource modification was failing which resulted in call teardown.
2. For a Forking call, the SBC allocates multiple (depending on number of forked INVITES sent out on egress) media resources (XRES) on ingress using same media resource key (localIP+Port+LIG), and with DLRBT enabled, if one of the media resource is activated, we cannot activate any other media resource that is bound to the same key combination (localIP+Port+LIG). This results in an Activation failure.

Steps to Replicate: 

1. Configure native forking and DLRBT and Ice learning.
2. Ensure call is forked to PSTN and TEAMS endpoints.
3. Ensure call answered from TEAMS or PSTN endpoint is successful.

1. The code is modified to not return a failure for DUMMY resource modification.

2. The code is modified to not return a failure for the activation command.

Workaround: Disable the DLRBT and ICE learning for forked calls.

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

Impact: The Security Mechanism of Registration is set to TLS in RCB with two different scenarios. The scenarios are of basic registration that  does not have any security profile.

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

Steps to Replicate: Test requires a HA setup.

Scenario 1:

1. In Active Node make a successful registration. Send a Fake registration such that it gets rejected with 403 error from server side.
2. Now, perform a switchover and when standby node becomes active make another fake registration which gets rejected by 403 again.
3. Verify the Security Mechanism in CLI using "show status addressContext default sipActiveRegisterNameStatus" and also try to make a call.

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

1. Make sure to take logs
2. In Active node make a successful registration with response code other than 200 ex: 202 Accepted. [send 202 instead of 200 in server script]
3. Now Send a refresh register, it will be internally rejected with 403 from the SBC. In the logs, you will see these statements "invalid state auth-rcvd" and "Refresh register did not meet security requirements". If you verify the security mechanism, it should show TLS.
   
   Note: step 2 and 3 cannot be reproduced in 824R1 build, so try with older build like 8.2.2 etc.
   
   
4. Upgrade the Standby node to 824R2 build. Make a switchover and send a refresh register now verify the CLI for security mechanism if set to NONE. Try making a call or send a refresh register again both should be successful.
   
   Note: If you would like to see the issue, In Step4 instead of 824R2 upgrade with 824R1.

The code is modified to set security back to NONE when deleting a Digest structure.

Workaround: Try performing switchover twice.

PortFix SBX-109083: The SCM Process coredumps during the SipSgAORHashRemove.

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

Root Cause: Below is likely cause of the core as per core dump and SYS error logs.

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

Steps to Replicate: 

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

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

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

Workaround: None.

PortFix SBX-107944: SBC - High Memory.

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

Root Cause: The upgrade of the debian kernel (from 3.16 to 4.19) has triggered a leak of XRM_IPSEC_SA_STRs.

Steps to Replicate: The unit testing was not necessary because this fix has been tested in other branches.

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

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

PortFix SBX-103616: The search function in the EMA does not work.

Impact: When a custom perspective is created, the search function does not work.

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

Steps to Replicate: 

1. Create a Custom Perspective with "URI Parameter Manipulation" and all its children.
2. Perform a Search.

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

Workaround: Delete Custom Perspective and restart the SBC.

PortFix SBX-109993: The PRS Process is coring with pkt SWO with loopback call.

Impact: The PRS cored when testing a pkt port switchover.

Root Cause: In a previous fix, the statement to log the debug message was missing a string parameter. 

Steps to Replicate: 

1. Configured one basic call and one loopback call with port redundant set-up.
2. Performed pkt SWO with loopback call running.
3. Observed a PRS Process core immediately after pkt SWO command (request system ethernetPort packetAdmin vsbc1 pkt0 switchover).

The code is modified to address the issue.

Workaround: No workaround.

PortFix SBX-105901: Detected a heap-buffer-overflow in ASAN build for SIPS module.

Impact: Observing heap buffer overflow in SCM process for info level log while decrypting the ROUTE header. Reading memory beyond the end of the allocated buffer can result in memory access faults and coredumps.

Root Cause: There was a heap overflow is because debug statement is trying to print from a string variable that is not null terminated.

Steps to Replicate: Execute a test case where INVITE message contains encrypted route-header and verify that there are no failures.

The code is modified to create a local variable of type character array that gets dynamically created and is always null terminated. This variable will be used in the info log.

Workaround: Not Applicable.

PortFix SBX-110290: Observed a CpxApp coredump on an Active SBC while running a weekend load.

Impact: The CPX coredumped due to a health check failure.

Root Cause: Unhide the debug command that was being run as part of a test did not return for more than 10 secs resulting in health check fail.

Steps to Replicate: Run similar tests that frequently call "unhide debug", verify that the CPX does not coredump similarly.

The code is modified to override the healthcheck for unhide debug command.

Workaround: None.

PortFix PSX-36804: The systems appear to be adding rtcp-mux parameter to SDP in invites.

Impact: If the "Media Packet COS" value is 4-7 in the Packet Service Profile, the flag "RTCP-MUX" is always set even though this flag is not selected from the PSP profile. Furthermore, if "Media Packet COS" value is 1, 5 and 7, the flag "Force Route PSP Order" of PSP is always set even though this flag is not selected.

Root Cause: In the PES module, it assigned the "left shift of 7 bits" of "Media Packet COS" value to both Options2 and Options3 fields when sending the Diameter message to SBC. The COS value is only associated with Options2 field. This assignment of Options3 corrupted the bits 8-10 of actual options3 value defined in the Diameter interface:

#define DIAMETER_PKT_PROFILE_OPTIONS3_FORCE_ROUTE_PSP_ORDER 0x0080
//0x100 is reserved in CPC diameter structure
#define DIAMETER_PKT_PROFILE_OPTIONS3_RTCP_MUX 0x00200

Steps to Replicate: Assigned different values of COS field, combined with enabling/disabling flag "RTCP-MUX" and "Force Route PSP Order" for the Packet Service Profile and Preferred Packet Service Profile. Verify the value of Options2 and Options3 fields are set properly when sending the message to the SBC.

The code is modified to address the issue.

Workaround: None.

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

Impact: 

1. When the register is sent to registrar the SBC creates a RCB for that particular User. When a fake/hijacked register is rejected with 403 some of the parameters in RCB are being modified and users were not able to make a call due to security mechanism being set to TLS.
2. If there is any timeout on the RCB which leads to it moving to terminated state and a refresh register arrives subsequent calls are rejected.

Root Cause: 

1. In 8.2x build when a Register request is rejected with 403 it moves to terminated state. Also whenever we receive a register we modify the RCB details irrespective of the response we might receive from the registrar.
   Note: A register is considered fake when we receive a 403 response for that.
2. When the RCB was moved to terminated state the code was partially deleting internal memory that led to the RCB mechanism being reported as TLS and none TLS calls where then rejected.

Steps to Replicate: Make a configuration and use a configuration file for reference:

1. After running the configuration, make a successful registration, later make a register so that it gets rejected with 403 error.
2. Verify the parameters in RCB using this command:
   
   show status addressContext default sipActiveRegisterNameStatus
3. Check for all the displayed parameters and also check for sipSigPort and other essential parameters in Debug logs.

The code is modified for the following:

1. Remain in previous state with the previous information. The RCB contents are backed up so they can be restored on failure.
2. Remove the security mechanism of TLS when the RCB is in terminated state.

Workaround: None.

PortFix SBX-109105: The OOD PUBLISH vs. OOD INFO different NRM triggers/congestion profiling.

Impact: The OOD PUBLISH vs. OOD INFO different NRM triggers/congestion profiling.

Root Cause: Some of the OOD message types were not being checked for triggering NRM congestion.

Steps to Replicate: Please run OOD PUBLISH messages which should trigger NRM congestion and calculate CPS resource.

The code is modified to trigger the NRM congestion to include all OOD messages.

Workaround: There is no workaround.

PortFix SBX-109286: The IP Interface Group will cause issues when there are the same names with different upper or lower cases.

Impact: The IP Interface Group will cause issues when there are the same names with different upper or lower cases.

Root Cause: The code reads the attribute value (ignoring case) and selecting the options. As a result, both values are marked selected and last selected option will be shown as selected in GUI.

Steps to Replicate: Create an AC, Zone and Trunkgroup
Create IP Interface Group with same names different case and assign one to media then save.

Select the Trunkgroup -> Media
The assigned IP Interface group is selected (whichever case selected).

The code is modified the exact match the value to select based on case sensitive.

Workaround: No workaround.

PortFix SBX-95106: The SIP over SCTP calls are failing for approximately 25-30 seconds after enabling a new SIP signaling port.

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

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

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

With the fix, the SIP-SCTP connections continue to use packet interfaces for SIP-SCTP packets.

The code is modified to copy the ipInterfaceGroup information from application-created socket to internally/kernel created socket.

Workaround: None.

The SSH access was not re-enabled on SBC 5400 for linuxadmin after upgrade.

Impact: SSH is enabled for root user in SBC 5400 after a LSWU or PM upgrade.

Root Cause: The getVirtualType function in sonusUtils.sh is set virtual type wrongly on SBC 5400.

Steps to Replicate: Enable SSH and run a LSWU, the SSH should not enable for the root user.

The code is modified to address the issue.

Workaround: None.

Passphrases are included in the configuration export.

Impact: The following entries are being displayed in the configuration backup:

sipTrunkGroup->signaling->authentication->authPassword
ipPeer->BadPeer->surrogateRegistration->regAuthPassword
profiles->services->surrogateRegistrationProfile->aorAuthPassword

Root Cause: The exportConfig does not filter any specific paths while exporting the configuration backup.

Steps to Replicate: Configuration:
2 TG with signaling->authentication->authPassword
2 ipPeers with surrogateRegistration->regAuthPassword
2 surrogateRegistrationProfile with aorAuthPassword

Export the configuration, check if it contains the mentioned entities in XML and CLI.
Clear the DB and import back the configuration.

The code is modified to address the issue.

Workaround: No workaround.

Both the SBCs restarted at the same time and both mounted the DRBD0.

Impact: Both the SBCs restarted at the same time and both mounted DRBD0.

Root Cause: The PRS Process was not updating the syncStatus flag value due to which the the standby was also rebooting thinking the sync is not complete yet.

Steps to Replicate: When both the the nodes are up and running, restart standby. And while the standby is coming up, run switchover from active CLI. The switchover should be successful.

The code is modified to use the SMA API to check syncStatus instead of PRS and CHM local syncStatus flags

Workaround: None.

The confd connections are not cleaned up correctly.

Impact: If the standby experiences a power hit, the confd connections will not be properly torn down.

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

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

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

Workaround: None.

There was a DSP DHC failure and failed to coredump.

Impact: The FPGA based a DSP Health Check (DHC) fails and no DSP core-dump is collected,

Root Cause: Root cause for the DHC failure is not known. However, subsequent coredumps failed due to DSP BOOTP packets not responding, which causes a hard failure. It is speculated that both issues are related.

Steps to Replicate: The code has been instrumented.

The code is modified so on a DHC failure and subsequent coredump failure due to not receiving DSP BOOTP packets, node is rebooted instead of the application being restarted.

Workaround: None

The AddressSanitizer: detected a heap-use-after-free on address 0x6190001c77dd at pc 0x558bcc9ff877 bp 0x7fea305f4e00 sp 0x7fea305f45b0.

Impact: The ASAN reported "AddressSanitizer: heap-use-after-free" error when a Subscribe request was having a NULL character in quoted string.
Ex: From: "00 test"<sip:user1@host>

Root Cause: An invalid access of the freed memory occurred. Accessing memory after it is freed can cause unexpected behavior that may result in coredumps.

Steps to Replicate: Use the codenomicon subscribe-notify suite.

The code is modified to send a parser error when ever the SBC received a NULL character in the quoted string.

Workaround: None.

There was a crash observed in a four GPU Codec Scenario.

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

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

Steps to Replicate: 

1. Set the SWeActiveProfile to use GPU and sweCodecMixProfile to use G729.
2. Make G729AB to G711U call and do not send the media.

RESULT: The SWe_UXPAD may crash and the SBC application will restart.

NOTE: The issue may not always be reproduced.

The code is modified to initialize the stack variable appropriately.

Workaround: No workaround.

The AddressSanitizer: detected an SEGV on an unknown address 0x000000000000.

Impact: The SBC was performing a write operation on one of the un-allocated memory spaces while restoring NTP server configuration, causing an SEGV on unknown address.

Root Cause: This issue was caused because a flag variable was not initialized. As a result, the if condition was evaluated true instead of false and write operation was performed.

Steps to Replicate: Configuring NTP server and restoring the configuration by switchover or restart this error should not come up.

The code is modified to address the issue.

Workaround: None.

The IAC code needs to modified to bring up the 2vCPU instance.

Impact: To support small SWe setups in the AWS, changes are required to RAF.

Root Cause: In the AWS, 2vCPU instance types only allow up to 3 interfaces. Therefore, the SBC will only have (Mgt0, HA and PKT0) interfaces.

Steps to Replicate: Attempt to create a AWS SBC standalone setup using RAF, while making the following changes to the terraform.tfvars:

1. Remove the fourth element from the following lists:
   - sbc_subnet_names
   - subnet_cidr_blocks
   - map_public_ip_on_launch
   - sbc_private_ips_count_list
   - sbc_route_table_names
   - sbc_security_group_names
2. Set sbc_pkt1_public_ips_count to 0.
3. Set rnat_pkt1 to false.
4. Set pkt1 to false in attach_rules_to_existing_security_groups_map.
5. Set pkt1_security_group_rule_list to [].

The terraform will fail.

The code is modified to support creating an AWS SBC with no PKT1.

Workaround: Create a setup using small SWe CFN templates.

The sonusSbxCertificateExpireSoonWarningNotification trap does not show for all certificates in current and for the history of alarms.

Impact: The sonusSbxCertificateExpireSoonWarningNotification trap does not show individual alarms for separate certificates on the alarm status screen.

Root Cause: The SBC alarm for sonusSbxCertificateExpireSoonWarningNotification was just using trap ID as key identifier.

Steps to Replicate: Add multiple certificates to a 1:1 HA system that will expire and configure certificate expiry date. Confirm:

• Only one trap is triggered per certificate.
• One alarm exists for certificate.

The code is modified so the SBC alarms now use certificate name as well as trap ID as key identifiers to show alarm.

Workaround: None.

The CHM Process coredumps on the standby OAM after a reboot.

Impact: The CHM process coredumps on the standby OAM after a reboot due to the gluster coredump.

Root Cause: The SBC application continues to come up even when the zapAsp is called from a sbxCleanup. The CHM tries to access ceNum, which is not properly set due to failure in sbxCleanup.sh and causes coredump.

Steps to Replicate: Fail the sbxCleanup, and the SBC should not be coming up.

The code is modified to avoid the SBC bringup if any errors are reported in the sbxCleanup.

Workaround: No workaround.

In the N:1 mode, the SBC switches over for the different node than the one, which the switchover request is honored.

Impact: In N:1 during few scenarios, the SBC performs a switchover to node that was not request honored. When the issue occurred, the switchover will be processed to the other node instead of processing to request honored node.

Root Cause: During a switchover process, the SBC was not checking the node that was requested honored. It was switching over to node that comes first/was available while processing.

Steps to Replicate:

1. Bring up 2:1 the SBC.
2. Try to reboot the both active server.
3. While the switchover process delay the up of request honored node and allow the another node to come up first.

The code is modified to check the service ID of the request honored node before a switchover.

Workaround: None

The CA CMR with the offset 2 and priority LOW is not being processed or rejected.

Impact: When a Channel Aware Mode CMR for priority LOW and offset 2 is the first CA. The CMR received in a call, the CMR was not processed.

Root Cause: The present default value of curFecIndOffset in the code was set to 0, which corresponds to offset 2 and priority LOW.
Due to this, the default value when a CMR for offset 2 and priority LOW is received as the first CA CMR, it is not getting processed.

Steps to Replicate: Test 1:

1. Enable IR9.2cmr in the SBC.
2. Send ADD request with A1 profile having ch-aw-recv=-1 parameter in T1 termination.
3. Pump pcap with 13.2br with cmr byte of CA-L-O2 followed by CA-H-07.

Expected Result:

1. The SBC should accept the ADD request.
2. The SBC should not accept the cmr request. The invalidCMRCount should be incremented.

Actual Result:

1. The call is successful.
2. The invalidCMRCount gets incremented as per the number of invalid CMRs received.

Test 2:

1. Enable IR9.2cmr in the SBC.
2. Send an ADD request with A1 profile having ch-aw-recv=0 parameter in T1 termination.
3. Pump the pcap with 13.2br with cmr byte of CA-L-O2 followed by CA-L-03.

Expected Result:

1. The SBC should accept the ADD request.
2. The SBC should accept the cmr requests. The codecModeChangeRxCnt should be incremented to 2.

The code is modified so that it does not match any of the valid curFecIndOffset which is 0-7.

Workaround: None.

The dpf_core.c "runtime error: shift exponent 432 is too large for 64-bit type 'long long unsigned int'" in np.log.

Impact: In the ASAN build, a runtime warning is observed in SWe_NP while running AMR-EVS audio call and insert T140 to both the streams through a RE-INVITE.

Root Cause: Incorrect use of bitmask operation to extract dscp field from packet.

Steps to Replicate: In an ASAN build, make a AMR-EVS audio call and insert T140 to both the streams through a RE-INVITE. AMR+T140-> EVS+T140. Observe ASAN warning in the np.log.

The code is modified to address the issue.

Workaround: None.

The AddressSanitizer: detected heap-use-after-free on address 0x61900412bbce.

Impact: The ASAN reported "AddressSanitizer: heap-use-after-free" error for a subscribe message received with Proxy-Authorization header having auts parameter.
Ex: Proxy-Authorization: Digest auts*="0x01P+20"

Root Cause: An invalid access of the freed memory occurred in this case. Accessing memory after it is freed can cause unexpected behavior that may result in coredumps.

Steps to Replicate: Send SUBSCRIBE message received with Proxy-Authorization header having auts parameter.

The code is modified to address the issue.

Workaround: None.

Observed the DRM congestion for G711 to G711 transcode calls load with only 70% of the dsp capacity.

Impact: There was DRM congestion observed for G711 to G711 transcode calls load with only 70% of the dsp capacity.

Root Cause: More MIPS being consumed when the RFC2833 detection is enabled on either one/both the legs.

Steps to Replicate: Run a 90% G711A<=>G711U load on an MRFP set-up with RFC2833 enabled on both the legs.

The load should run without any DRM congestion.

The code is modified to make the cache aligned and G711A and G711U Encoder is made into a look-up table.

Workaround: None.

There was a runtime error: the NULL pointer passed as argument 2, which is declared to never be NULL.

Impact: The NULL pointer access during the codenomicon test with an ASAN SBC build.

Root Cause: Codec Attribute has been accessed in the SDP without proper NULL check.

Steps to Replicate: 

1. Install ASAN build on the SBC.
2. Run Codenomicon INVITE response with outgoing Bye suite.

The code is modified to add the defensive NULL check.

Workaround: Not Applicable.

A runtime error: load of value 24752, which is not a valid value for type 'SIP_MSG_TYPE'.

Impact: While processing an in dialog NOTIFY message, the check for message type was not done using proper data type.

Root Cause: Message type check for NOTIFY message was not correct.

Steps to Replicate: 

1. Make a call on an SBC installed with ASAN build.
2. Send an in dialog notify.
3. The error above should not be displayed in ASAN logs.

The code is modified to address the issue.

Workaround: None.

The SBC sends a 420 Bad Extension response when the INVITE with both supported and the required 100rel is sent.

Impact: The SBC sends a 420 Bad extension when the require:100Rel is received in the initial INVITE and e2e Prack flag is enabled.

Root Cause: The wrong code has been added to reject an INVITE with Require:100Rel when rel100Support flag is disabled and e2e prack flag is enabled.

Steps to Replicate: 

1. The rel100Support needs to be disabled.
2. The e2e Prack is enabled.
3. An INVITE is received with the Require:100Rel Header.

The code is modified for the rejection in require:100rel Scenarios.

Workaround: The SMM can be used to remove the Require:100Rel Header.

The ASAN runtime flatbuffer serialization unit test fails with asan=1.

Impact: The ASAN build is failing due to automated test failures related to serialization.

Root Cause: Automated unit test is failing because of uninitialized variables.

Steps to Replicate: Create an ASAN build and it should be successful.

The code is modified to initialize the variables that were causing the Unit tests to fail.

Workaround: None.

Allocated bandwidth for the opus call is 1032kb and 1028kb for a single call.

Impact: If "transcoderFreeTransparency(TFT)" is enabled at the Route PSP, then extra bandwidth is allocated for an opus call in case the maxaveragebitrate attribute is not received in the SDP from the endpoints.

Root Cause: If the maxaveragebitrate is not received in the SDP, then the SBC was using the max value of 510kbps as the default value (which was not as per RFC). Later, this bitrate value gets intersected with Route PSP configured value. However, for TFT calls, this intersection with route PSP does not happen. As a result, the SBC continues to maintain this value as 510kpbs which results in extra bandwidth allocation.

Steps to Replicate: Configuration:

1. set profiles media packetServiceProfile DEFAULT packetToPacketControl transcode transcoderFreeTransparency.
2. set profiles media packetServiceProfile DEFAULT secureRtpRtcp flags enableSrtp enable allowFallback enable (Ingress).

To re-create the issue:

1. The UAC sends INVITE with OPUS codec and SDP does not contain "maxaveragebitrate" attribute.
2. Since "maxaveragebitrate" is not received from UAC, the SBC defaults to max value of 510kbps and sends the same to UAS.
3. UAS responds with a 200OK with OPUS codec and the SDP does not contain "maxaveragebitrate".
4. The SBC sends out 200OK with maxaveragebitrate=510kbps to UAC.

Test Result without a fix: Since the maxaveragebitrate defaults to 510kbs, the SBC ends up allocating more bandwidth than expected.

The code is modified so if "maxaveragebitrate" is not received in SDP, then it derives the default value according to RFC using "maxPlayBackRate" and mode(mono/stereo).

Workaround: None.

The CE_Node2.log:snprintf buffer too small. Needs a 327 with a 128 File: /localstore/ws/jenkinsbuild/sbxmainasan/marlin/SIPSG/sipsgLibUtils.c Line: 2524

Impact: The length of the destination buffer was smaller than the source buffer, while using the the snprintf function, and as a result the buffer was too small to be seen.

Root Cause: The destination buffer size was smaller than the source buffer while calling the snprintf.

Steps to Replicate: 

1. Run the publish requestion codenomicon test suite.
2. This error should not come.

The code is modified to increase the character array size to upper limit of source buffer size.

Workaround: None.

The buffer was too small. Needs a 256 with a 256 File: /sonus/p4/ws/jenkinsbuild/sbxAsan100/marlin/SIPS/sipsParse.c.

Impact: During the snprintf function call, the destination buffer was not big enough to copy the source string.

Root Cause: The size of the destination buffer was smaller than the source buffer. The destination buffer length check was not present.

Steps to Replicate: When the callId length was more then the defined max callId length, this error was seen.

Run a call with callId length greater than 256 bytes. This error should not appear.

The code is modified for the string smaller callId buffer.

Workaround: None.

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

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

Root Cause: If working the PSP already contains 8k dtmf PT intially, then the SBC skipped over this PT value without accumulating, and as a result 16k dmtf also takes the same value as 8k dtmf PT.

Steps to Replicate: Configuration:

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

To re-create the issue:

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

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

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

Workaround: None.

The PRS Process gave a heap use after free on address on latest 10.0 build.

Impact: The PRS Process gave a "heap use after free on address" error while running HA suite on ASAN build.

Root Cause: The interface number was being returned after typecasting the main structure to packet LIF structure, and not management LIF structure.

Steps to Replicate: Run the SBX_504_HA suite on ASAN build.

The code is modified to correct the typecasting.

Workaround: None.

The monitor.c "runtime error: signed integer overflow: 0 - -9223372036854775808 cannot be represented in type 'long int'" error in np.log.

Impact: Internal ASAN builds report a runtime signed integer overflow error in SWe for standard deviation metric for jitter meant for consumption by Ribbon Protect.

Root Cause: Existing algorithm of standard deviation metric did not handle integer overflow issues.

Steps to Replicate: Stream the custom RTP packet where expected standard deviation and verify through the Ribbon Protect metric that computed standard deviation values are in range.

The code is modified to handle the overflow.

Workaround: No workaround. 

Various runtime errors found in the np.log.

Impact: Internal ASAN builds report runtime errors on the SWe platform related to left shift of signed integers.

Root Cause: Appropriate integer casts were missing in code, which caused ASAN runtime warnings related to bit shift.

Steps to Replicate: Bring up ASAN build on SWe platform and observe if np.log contains ASAN runtime warnings related to bit shifts.

The code is modified to fix the runtime warnings in ASAN builds.

Workaround: No workaround.

SBC:~50ms delay introduced for the LDG port switchover.

Impact: A media glitch of more than 200ms is observed in port switchover.

Root Cause: The Linux netdevice callback thread had a higher sleep duration, leading to increased latency for processing of netdevice operations that occur during port switchover.

Steps to Replicate: 

1. Create an SBC 3:1 setup.
2. Configure BFD on the SBC.
3. Establish a call to the SBC.
4. Bring down the virtual interface on the host down for any pkt port.
5. Verify port switchover is triggered with expected packet loss.

Linux netdevice callback thread sleep duration was reduced.

Workaround: There is no workaround for this issue.

MicroFlows are failing in the REGISTER Performance of 2400 RPS (256000 REGISTRATIONS) with Error code 0xf9.

Impact: Unable to support 256k concurrent subscriber registrations in Default memory profile for the SBC SWe.

Root Cause: Existing logic for determining the flow hash causes increased number of hash collisions leading to increased depth of hash buckets, leading to buffer starvation.

Steps to Replicate: 

1. Create a SWe SBC instance. (of default memory configuration profile).
2. Test the 256K registrations.

The code is modified to minimize hash collisions.

Workaround: There is no workaround for this.

There were MFG Intermittent test failures.

Impact: Xaui link is not always coming back up after enabling/disabling the internal loopback mode.

Root Cause: Xaui link is not always coming back up after enabling/disabling the internal loopback mode.

Steps to Replicate: Run the ESS test mode for days.

The code is modified to the enable/disable loopback code.

Workaround: None.

The CDR pattern was missing in "42.71", "42.72" fields for START and "52.71" ,"52.72" fields for STOP.

Impact: By the introduction of new STI service, the type will corresponds to generic profile execution. The CDR values need to be update to NULL, if any of the STI services are not executing.

Current Behavior:
42.71 STI Service Type : 0
42.72 STI Service Status : 0
42.73 STI Reason Code : 0

Behavior after changes:
42.71 STI Service Type :
42.72 STI Service Status :
42.73 STI Reason Code :

Root Cause: The root cause occurred due to the additionof the new STI service type at PSX.

Steps to Replicate: Run a normal call and check for CDR's and it will be populated with NULL values.

The code is modified in case the STI service state is disabled.

Workaround: None.

The callTracing does not work after reverting a switchover.

Impact: The callTrace can not be enabled on calls after a switchover under the following circumstances: When maximum calltrace count is reached before the switchover, all these calls with calltrace enabled are terminated after the switchover.

Root Cause: The internal calltrace state was not properly synchronized to the standby node that caused no new calls with calltrace ON request can be enabled.

Steps to Replicate: 

1. On a 1+1 (active/standby) MRFP setup, set the calltrace count to 10.
2. Create 10 calls with calltrace enabled.
3. Perform a switchover.
4. Terminate the 10 calls after a switchover.
5. Perform a switchover.
6. Make new calls with calltrace ON requested in the ADD termination command.

These new calls should have calltrace enabled.

The code is modified so the calltrace works after a switchover.

Workaround: Reboot both the SBC nodes.

The SBC does not send a notify for successful trace activation.

Impact: The SBC does not send calltrace notify to C3 in a call setup with calltrace ON request for the ADD commands of both first termination and second termination of the call, but the ADD command failed for the second termination.

Root Cause: The SBC code logic was to send calltrace NOTIFY after the ADD commands of both termination have been processed, but this results in calltrace NOTIFY not being sent for the first termination failure and the ADD second termination.

Steps to Replicate: 

1. Enable calltrace in the SBC.
2. Send ADD request with CALLTRACE/TRACEACTIVITYREQUEST=ON on both the terminations. The codec should be PCMU on the first termination and G726 on the second termination, such that ADD of second termination will fail (not supported codec).

Expect Result:

1. The call should fail.
2. The SBC should send calltrace NOTIFY with RES=success for the first termination.

The code is modified to send calltrace NOTIFY for successfully ADDed termination.

Workaround: None.

The URL version is incorrect after restoring an older version.

Impact: There was the wrong version in URL after a restoring an older version.

Root Cause: The URL is picked from CDB from path "/system/objectStoreParameters/url", which is independent of software version of revision.

Steps to Replicate: 

1. Create a OAM act and standby and one SBC with V10.00.00A008.
2. Create multiple revision, such as revision 1, 2, etc. 
3. Upgrade cluster to V10.00.00A009.
   
   [root@VSBCSYSTEM-2-vsbc2 172.xx.xx.xx evlog]# cat /mnt/gfsvol1/config-versions.txt
   5,V10.00.00A008,oam_config_20210510T042937.tar.gz,0,2021-05-10T04:29:37,,downloaded_from_ems
   6,V10.00.00A009,oam_config_20210510T043100.tar.gz,1,2021-05-10T04:31:00,REBOOT_REQ,auto_save_after_software_change
   [root@VSBCSYSTEM-2-vsbc2 172.xx.xx.xx evlog]#
   
   
4. Manually reboot and replace the SM Process with a fix.
5. Restore revision 3.
   
   7,V10.00.00A008,oam_config_20210510T045034.tar.gz,6,2021-05-10T04:50:34,RESTORE,restored_from_3
   8,V10.00.00A009,oam_config_20210510T045311.tar.gz,6,2021-05-10T04:53:11,REBOOT_REQ,auto_save_after_software_change
   
   Obervation: Revision 7 uploaded with correct URL.
   
   
6. Remove revision 7 from the /mnt/gfsvol1 and restore revision 7.
   Revision successful and newly created reviosion uploaded on EMS with correct URL
   11,V10.00.00A008,oam_config_20210510T055545.tar.gz,20,2021-05-10T05:55:45,RESTORE,restored_from_9
   12,V10.00.00A009,oam_config_20210510T055745.tar.gz,20,2021-05-10T05:57:45,REBOOT_REQ,auto_save_after_software_change

The code is modified to update the URL with the software version for the revision being restored.

Workaround: None.

The SBC Node branch information is inconsistent after a Cleanstart/Restore Revision is performed in the OAM's.

Impact: The SBC Node branch information is inconsistent after a Cleanstart/Restore revision is performed for the OAMs.

Root Cause: Managed VMs registration failed with the active and standby OAMs as OAMs were not up. The VMs did not try to re-register again.

Steps to Replicate: After the issue is fixed, create a setup OAM + S/M/T SBC.

1. Log in to the CLI as admin and execute the following configuration:
   show configuration node
   o/p: All nodes should be listed.
   
   
2. Configure the SBC (create AddressContext, zone, TG) saveAndActivate Revision
   o/p: new configRevision should be propagated to all managed VMs.

The code is modified to keep retrying to register with active and standby OAMs.

Workaround: None.

There are coverity issues in the nrsPktLifCsv.c

Impact: There was a coverity issue during the validation process.

Root Cause: A previous fix was added for a coverity error.

Steps to Replicate: The steps cannot be replicated.

The code is modified to address the issue.

Workaround: None.

The MS TEAMS call is failing when the DLRBT profile removed from TGs and ICE is enabled.

Impact: The MS TEAMS call is failing when DLRBT profile removed from TGs and ICE is enabled

Root Cause: Two Reasons for Forking+DLRBT calls to fail for a TEAMS endpoint.

1. With ICE Learning enabled, binding resource modification was failing that resulted in call teardown.
2. For the forking call, the SBC allocates multiple (depending on number of forked INVITES sent out on egress) media resource (XRES) on ingress using same media resource key (localIP+Port+LIG), and with DLRBT enabled. If one of the media resource is activated, we cannot activate any other media resource that is bound to the same key combination (localIP+Port+LIG). This results in Activation failure.

Steps to Replicate: 

1. The SBC is configured to handle MS Teams call with ERE.
2. Remove DLRBT profile from PSTN side TG and TEAMS TG.
3. ICE is enabled towards TEAMS.

Test Step:

1. Make the PSTN to TEAMS call.

1. The code is modified to not return failure for DUMMY resource modification.
2. The code is modified to not return failure for such activation command.

Workaround: Disable the DLRBT and ICE learning for forked calls.

The SBC does not answer SDP correctly when remote SDP contains both session and media port state attributes

Impact: The SBC sets the incorrect media port state in SDP in reply of a MODIFY command, when the media port state is present in both session level and media level.

Root Cause: The SBC parsed the media port state incorrectly when it is present in both session level and media level, and put them both at media level in the reply SDP.

Steps to Replicate: Create a 3pcc call, then send a re-invite that triggers C3 sending a MODIFY with media port state present in both session level and media level. The SBC should keep them the same session level and media level in the SDP in the reply.

The code is modified so when parsing media port state attribute when it is in both session level and media level.

Workaround: None.

The default bitrate for the G722 codec should be 64kpbs in MRFP but it is 48 kbps.

Impact: The SBC is using 48kbps bit rate for G722 codec instead of 64kpbs when setting up G722 calls.

Root Cause: The 48kbps bitrate is wrongly chosen for G722 codec, resulted in the media packets being generated with 48kbps bitrate.

Steps to Replicate: Make one g722 to g711 transcode call and observing the RTP stream for g722 codec.

The code is modified to change the bitrate to 64kpbs when setup G722 calls.

Workaround: None.

The SBC auto-registration in the EMS is not working with the EmsFqdn.

Impact: The SBC auto-registration in the EMS is not working when using the EMS FQDN.

Root Cause: The service discovery is unable to resolve EMS FQDN using system DNS because there is no ACL rule to allow DNS query to go through.

Steps to Replicate: 

1. Configure the SBC with EMS FQDN.
2. Ensure it is registering to EMS successfully.

The code is modified to allow the DNS query to go to the configured nameserver.

Workaround: None.

The SBC includes the "text port = 0" in its response for the re-INVITE to insert a text at the mid call.

Impact: The SBC rejects the t140 stream in handling a MODIFY command that changes the audio codec from PCMU to AMR-WB and a t140 stream, with "adaptive codec" enabled.

Root Cause: The SBC delays the process of MODIFY command when "adaptive codec change" is enabled, as a result the MODIFY reply is sent back to C3 without t140 stream media resource allocation (IP and RTP port, etc).

Steps to Replicate: With the adaptive codec change enabled on a VMG, create a 3pcc call from EVS + t140 — PCMU + t140. Then modify the T2 side to AMR-WB + t140 and the SBC should reply with a valid port number for t140 stream.

The code is modified so that the normal handling of the MODIFY command with audio codec change with t140 stream is carried out and t140 media resource is allocated and valid port is replied back to C3.

Workaround: None.

The DSP fails to modify ptime.

Impact: When the SBC receives a re-INVITE with change in the ptime for EVS, the DSP Modify command fails.

Root Cause: The handling of the DSP Modify command for a ptime change EVS was not present.

Steps to Replicate: Run a EVS to G711 call, send a re-INVITE on the EVS leg with change in ptime. The change in ptime should be put into effect through a DSP Modify.

The code is modified for allowable ptime changes that include 20, 40, 60, 80 and 100ms.

Workaround: None.

Observed MAJOR logs with MegacoSendAmmsResp failure after a switchover during a EVS + T140 -> Mulaw Load

Impact: There was a MegacoSendAmmsResp: MegacoSendAmmsResp: Failure while encoding a response. Error code = 197 Major logs was observed after a switchover for the SBC during a load run of a call setup with an audio and text stream.

Root Cause: The text stream is not properly synchronized to the standby node and triggers the H.248 message encoding error in reply to a H.248 MODIFY command.

Steps to Replicate: Perform a failover during call load run with EVS +ToIP on the ingress side and a G711U+Baudot on egress side.

The code is modified to address the issue.

Workaround: None.

After an upgrade from 9.2.1R00 To 10.0.0, the extra SNMP trapTargets are created.

Impact: When upgrading an SBC running an SBC release of 9.1 or greater, extra trap targets are created in the OAM SNMP trapTarget table.

Root Cause: In the 9.1x and above releases, when a trap is created in the oam snmp trapTarget table, the corresponding trap that is added in the OAM snmpAgent snmpTargetMib snmpTargetAddrTable has a -0 appended to the end of its name (Example: emaTarget-0). During the upgrade, the upgrade code was looking for an oam snmp trapTarget with a name that has a -0 at the end (Example: emaTarget-0) and since it did not exist, created the extra entry.

Steps to Replicate: 

1. Install an 9.2.x release.
2. Upgrade to 10.0.
3. Verify that there is not an OAM SNMP trapTarget entry with the name emaTarget-0.

The code is modified so the -0 suffix is removed before the corresponding trap in the oam snmp trapTarget is searched. 

Workaround: Delete the extra entries in the OAM SNMP trapTarget table.

The LeakSanitizer detected memory leaks.

Impact: A memory leak occurs when a logical management interface is added or modified.

Root Cause: A confd cursor element was not closed when exiting the routine that validates the logical management interface being added or changed and this resulted in a memory leak.

Steps to Replicate: Make changes to the logical management interfaces and check for memory increasing in the CPX process.

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

Workaround: None.

Observed the MAJOR logs for SIPFE "/localstore/ws/jenkinsbuild/sbxMain/marlin/SIPFE/sipFeSigPortCsv.c, SipFeGetSipSigPortStatisticsGetNextReqMsg, 1111] Another Query in process" on T140 load.

Impact: MAJOR logs.

Root Cause: The addressContext zone sipSigPortStatistics table is not supported on the SBC, so the code used to return the information was sometimes not returning, causing the MAJOR logs.

Steps to Replicate: 

1. Run the following command:
   snmpwalk -c admin -v2c <mgmt address of sbx> 1.3.6.1.4.1.2879.2.10.2.121
2. Repeat this command four times.
3. Verify the error:
   "/localstore/ws/jenkinsbuild/sbxMain/marlin/SIPFE/sipFeSigPortCsv.c, SipFeGetSipSigPortStatisticsGetNextReqMsg, 1111] Another Query in process" on T140 load
4. This issue does not occur in the DBG log.

The code is modified so the SipFeGetSipSigPortStatistics routines return immediately.

Workaround: Do not query that table.

Observed major logs flooding for "MAJOR .SIPSG: sipsgMsgProc.c (-19034) 49487. SipSgRemoveDblTrackingEntry, Hash entry not found"

Impact: Under a Register load, the major logs related to DBL were flooding the SBC.

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

Steps to Replicate: 

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

The code is modified to prevent sending unnecessary messages.

Workaround: Not applicable.

The CPX App Process coredumps on the standby OAM.

Impact: The CPS process coredumps occasionally when the SBC is stopped.

Root Cause: The Replication Engine thread is not stopped when the CPX process receives a deactivate request.

Steps to Replicate: It is rarely reproducible.

The code is modified so the Replication Engine is now stopped when the CPX deactivates.

Workaround: None.

There was a activeRevision failure when the state for even type audit is set to on/off.

Impact: The configuration playback on the managed VMs fails on the command:

set oam eventLog filterAdmin vsbc1 audit audit level major state off

Root Cause: Playback engine does not use the user context.

Steps to Replicate: 

1. Run command on the OAM:
   set oam eventLog filterAdmin vsbc1 audit audit level major state off
commit
2. Run a saveAndActivate

The code is modified to exclude the Playback engine commit of log level from the user validation.

Workaround: Reboot on managed VMs to get the configuration at startup.

Error while logging in to admin mode: "Your last successful login was from p¢/H."

Impact: The buffer that was holding the v6 address was not big enough to store a large IPv6 address. When a large expanded format IPv6 address is stored in the buffer it overflowed and as a result, CLI output was unusable.

Root Cause: The buffer that was holding the IPv6 address was not large enough to store large V6 address.

Steps to Replicate: Log in to the admin session with a large v6 address. Repeat the same test that was done to find this issue.

The code is modified increased the buffer size.

Workaround: No workaround.

There are issues in the Ova\QCow2 installation.

Impact: Differing prompts and root passwords are created for the SBC SWe installed through the ISO, and the SBC SWe created through the image launch method, 

Root Cause: While installing through the image launch method, the SBC SWe was configured with the Cloud SBC method of creating the root password and prompt.

Steps to Replicate: 

1. Install the SBC SWe using ISO. Check the root password and CLI prompt.
2. Instantiate the SBC SWe using Image launch. Check the root password and CLI prompt.

Results from step 1 and 2 should be same.

The code is modified to ensure both image launch method and ISO install method of the SBC SWe has no root password and the same CLI prompt.

Workaround: A user can manually remove root password on ISO installed SWEs using the command below:
usermod root -p '*'

Re-INVITE when a 200 OK with crypto line is listed other than 1.

Impact: When the SBC offers a multiple crypto suite in an INVITE (offer) and the egress sends answer with crypto suite that is other than the top priority crypto offered by the SBC, the SBC sends an unnecessary re-INVITE to egress when minimizeRelayingOfMediaChangesFromOtherCallLegAll flag is enabled.

Root Cause: The SBC does not update the media subsystem structures correctly.

Steps to Replicate: Configuration:
minimizeRelayingOfMediaChangesFromOtherCallLegAll flag is enabled on ingress and egress TG.
Multiple crypto suites are configured on the PSP.

The SBC sends INVITE to egress with multiple crypto and egress endpoint answers with crypto that is other than top priority crypto that the SBC sent.

Without a fix, the SBC sends a re-INVITE to egress.
With a fix, the SBC suppresses re-INVITE to egress.

The code is modified to ensure the SBC suppresses the re-INVITE when the egress answer has crypto, which is not the top priority crypto as per the Packet Service Profile configuration.

Workaround: None.

Low MOS score for UNENCRYPTED_SRTP calls.

Impact: In the SRTP for unencrypted, authenticated case, the SRTP packets were being discarded at NP due to an authentication key mismatch.

Root Cause: In the SRTP for unencrypted, authenticated combinations, the key size is required in NP to derive the session authentication keys. Since a cipher key size was not being passed to the NP, the session authentication key was incorrectly calculated.

Steps to Replicate: 

After receiving a SDP offer with crypto attributes, if 'enable SRTP' is configured in packet service profile, a common crypto suite is found in the received crypto attribute in the offer and in the packet service profile, and session parameters (if included) are allowed, the offer will be accepted. In the answer, the SBC will include the same tag used in the offer.

Test Setup on the SBC:

1. Endpoint1 is configured with a SRTP profile ( SRTP/SHA-1-80). Disable all Session Parameters in the packet service profile. Allow the Fallback to be enabled.
2. Endpoint2 is configured with a SRTP profie (SRTP/SHA-1-80). Enable the Session Parameters UNENCRYPTED_SRTP in packet service profile. Allow the Fallback to be enabled.

Procedure:

Endpoint1 sends an offer SDP with crypto attribute SRTP/SHA-1-80 and with Session Parameters UNENCRYPTED_SRTP

Endpoint2 replies with crypto attribute SRTP/SHA-1-80 and with Session Parameters UNENCRYPTED_SRTP

The code is modified so the SBC application is passing the cipher key size also to the NP to calculate session authentication keys.

Workaround: The workaround is to not send unencrypted SRTP. Use cases with encrypted SRTP and authentication show no issues.

The SBC will not work when the require header comes in 18x without 100Rel.

Impact: The 18x message is not relayed when the 100rel is not present in the Require Header.

Root Cause: The functionality is not present to handle the use case for proxy behavior when 100rel is not present in the Require header.

Steps to Replicate: Run the scenario below:

1. Enable e2ePrack and proxyBehaviourFor18x flags.
2. Run a call flow with 18x having Require header without 100rel options tag.

The code is modified to consider this case when the 100rel is not present in the Require header.

Workaround: Not Applicable.

There are CDR issues for REGISTER.

Impact: There were issues while writing the CDR's for REGISTER method.

Root Cause: Below issues were present w.r.t REGISTER CDR's:

1. CDR's were not generated for REGISTER in case of crankback scenarios.
2. TG name was not updated properly for REGISTER CDR's.
3. Disconnect reason was not updated properly for REGISTER CDR's.

Steps to Replicate: 

1. REGISTER an endpoint through the SBC with/without crankback.
2. Check the CDR's. Entries should be correct.

The code is modified to address the following:

1. Generate EVENT records for REGISTER in case of crankback scenarios.
2. Correct the egress TG name in EVENT CDR for REGISTER.
3. Correct disconnect reason in EVENT CDR for REGISTER.

Workaround: None.

The M-SBC should not check the UDP checksum value with "m=application".

Impact: The M-SBC drops ESP packets with "0" checksum of the UDP header over "m=application" on IPv6.

Root Cause: The M-SBC always validates for the checksum in the UDP packet received, if the checksum value is 0 then it drops the packet causing failures.

Steps to Replicate: 

1. Set the service to "m=application UDP".
2. For the encrypt connection, include a key exchange for IPSEC and it completes.
3. Set the "checksum" of UDP header of ESP packet to "0000".

The code is modified so the M-SBC accepts zero checksum and sends a  valid checksum.

Workaround: None.

Conflicted design between two features “sdpRelayAttribute” and “Send RTCP Bandwidth Info”.

Impact: The SBC sends duplicate b=RR and b=RS values when “sdpRelayAttribute” and “Send RTCP Bandwidth Info” are enabled together.

Root Cause: The SBC was not honoring "sendRTCPBandwidthInfo" only when “sdpRelayAttribute” was enabled with TFT. Due to this, the duplicate of b=RR and b=RS was seen, when “sdpRelayAttribute” was enabled without TFT.

Steps to Replicate: Configuration:

1. Enable sdpAttributesSelectiveRelay flag under TG.
   set addressContext default zone ZONE_V6 sipTrunkGroup TRUNK_V6 media sdpAttributesSelectiveRelay enabled
   set addressContext default zone ZONE_V4 sipTrunkGroup TRUNK_V4 media sdpAttributesSelectiveRelay enabled
2. Enable the RTCP with below settings.
   set profiles media packetServiceProfile DEFAULT rtcpOptions rtcp enable rrBandwidth 500 rsBandwidth 150

Procedure:

1. Make a basic call so that the bandwitdth parameters are received from the endpoint as b=RR:1125, b=RS:775.

Expected Result:

1. The SBC should transparently send the b=RR & b=RS parameters in SDP and should not honor the bandwidth configured in the PSP.

Also, the SBC should not add duplicate b=RR and b=RS parameters in the SDP honoring the configured bandwidth values in the PSP.

The code is modified so if “sdpRelayAttribute” is enabled separately without TFT, and "sendRTCPBandwidthInfo" is enabled, then the SBC does not honor "sendRTCPBandwidthInfo" and does not send a duplicate value of b=RR and b=RS.

Workaround: None

The SBC is not rejecting the SRTP call when the disallowSrtpStream is enabled.

Impact: The SBC is not rejecting the SRTP call when disallowSrtpStream is enabled in ingress PSP and an INVITE is received with only a SRTP stream.

Root Cause: This is specific call flow when the disallowSrtpStream is enabled and a INVITE is received with only a SRTP stream.
This scenario was not handled and the SBC was not rejecting call.

Steps to Replicate: Procedure:

1. Enable flag "multipleAudioStreamsSupport" under trunk group media for both the ingress and egress.
2. Enable the disallowSrtpStream flag under trunk group on the ingress side.
3. Make a call with two SRTP streams.

The code is modified so that when the disallowSrtpStream is enabled and an INVITE is received with only SRTP stream, the call is rejected with a 488.

Workaround: None.

The SCM Process coredumps for the register with a timeout from the application server with no response.

Impact: When the REGISTER message is sent to the redirect server and if there is no response to REGISTER message, the SBC is dumping core.

Root Cause: The coredump is caused due to a missing NULL check.

Steps to Replicate: 

1. From UE send a REGISTER, the SBC forwards REGISTER to the AS.
2. The AS responds with 3XX.
3. The SBC tries REGISTER to the contact in 3XX response.
4. Do not send any response from the redirect server.

After step 4, the SBC coredumps.

The code is modified to avoid the core dump.

Workaround: None.

SBX-108232

There was an ERROR: AddressSanitizer: heap-use-after-free on address 0x61800000a5a8 at pc 0x559e8989c4ac bp 0x7f4411fde290 sp 0x7f4411fde288 READ of size 8 at 0x61800000a5a8 thread T9.

Impact: While the SBC node is shutting down it can access memory after its been freed, this could result in unexpected behavior and in the worst case a coredump. But this would have limited impact as it only happens when shutting down.

Root Cause: During sbxstop/sbxrestart or switchover because of race-condition, when the SBC is in deactivation the oamNodeRegisterRetry can access an already deallocated resource leading to a core dump.

Steps to Replicate: 

1. Set up a build with the HA SBC using the OAM.
2. Perform a sbxrestart/switchover of an active instance.

The code is modified to handle this race condition.

Workaround: None.

SBC: There was a CpxAppProc memory leak.

Impact: During the SBC startup processing, there is a small memory leak.

Root Cause: During the startup processing, the SBC is allocating memory while reading configuration information and it is not being freed up correctly at the end of the provisioning steps.

Steps to Replicate: This issue was only observed while running with ASAN images in the engineering lab as the amount of memory leaked is small and cannot be checked.

The code is modified to correctly free the memory allocated while processing the configuration data.

Workaround: None.

SBX-109453

The SBC is closing the socket for a DNS query over the TCP frequently.

Impact: The SBC is closing the socket for DNS query over the TCP frequently.

Root Cause: Whenever the TCP connection is closed FIN packet is sent towards the SBC from DNS server. But, the application was not closing connection by sending a FIN and Even after connection is closed by DNS server, the Application is still holding socket information. These details were used in future queries has cause TCP connection to reset.

Steps to Replicate: 

1. Have a v6 cloud SBC with the build below.
   
   SBC: V10.00.00-A006.
2. Configure the DNS server to send queries using TCP connection.
3. Make a call.
4. Wait for some time and Run one more call here.

Actual behavior:

In step 3, the SBC will query DNS server to resolve NAPTR records over TCP connection.

In step 4, the SBC will try to send NAPTR query and then immediately close tcp connection.

Expected result:

The NAPTR query should be successful in step 4.

The code is modified to close the TCP connection (Sending FIN to close connection). Also, the connection information in application is freed.

Workaround: None.

There was a question about DSP insertion.

Impact: Customer was seeing the "DSP insertion/rejection reason" CDR fields set to "Rejected codec unlicensed" and wanted to know why.

Root Cause: The documentation did not provide any guidance as to when this value could appear.

Steps to Replicate: The customer call scenario is unknown.

The code is modified to provide guidance on when it could happen as per below.
These are the cases when DSP Rejection reason can be set to "Rejected codec unlicensed"

1. The SBC does not have a DSP.
2. The SBC has DSP but codec licenses absent.
3. The SBC has DSP and codec licenses but transcoding not enabled for the codecs.

In any of the above cases if passthru is possible and if the call is successful then DSP Rejection reason will be updated after successful offer answer.

Its also possible this value might appear in the case where the offer/answer exchange did not complete.

As the customer was unable to provide details on the specific call flow additional info level logging and call trace logs have been added to provide more details for the future.

Workaround: None.

Portfix SBX-105188: The SBC does not use Replacement field in NAPTR response for SRV query.

Impact: The SBC does not use a Replacement field in NAPTR response for SRV query.

Root Cause: The SBC is not accepting replaceHost value's recieved in NAPTR response, when transportPreference or transport type1 are configured and dnsNaptrAlways flag is enabled.

Steps to Replicate: 

show addressContext default zone ZONE_AS_1 sipTrunkGroup SIP_EXT_TG services dnsNaptrAlways

dnsNaptrAlways enabled

1. Use the configuration below along with a DNS server.
   set addressContext addr_2 zone ZONE_AS sipTrunkGroup EGRESS_TG signaling transportPreference preference1 udp
   or
   set profiles signaling ipSignalingProfile IPSP_EGR egressIpAttributes transport type1 udp
2. Make call and the SBC will go for DNS lookup for NAPTR query.

Expected result: The SBC should parse host part of NAPTR response and use it in future SRV query.

The code is modified to accept the replaceHost value's, even when the transportPreference or transport type1 are configured and the dnsNaptrAlways flag is enabled.

Workaround: 

1. Do not set transportPreference and transport type1 value's (set it to "none").
2. The dnsNaptrAlways should be disabled and transportPreference, transport type to be set to "none".

SBX-108457 | SBX-107142

Portfix SBX-107142: The SBC VM was unable to power on post-poweroff procedure.

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

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

Steps to Replicate: 

1. Set the sweActiveProfile to use the GPU.
2. Reboot the instance after the SBC application is up.

RESULT: The instance should come up and the GPU should be visible in the instance.

The code is modified by using the NVIDIA Persistence Daemon.

Workaround: None.

Portfix SBX-109496: The SBC is not registered in EMS using Ansible playbook.

Impact: The SBC is not registered in EMS using the Ansible playbook.

Root Cause: In case of an iso based installation where the lca module is not installed, the location for the getAndUpdatePasswords.py file is different.

Steps to Replicate: 

1. Bring up a standalone SBC.
2. Fill the details of the SBC and EMS in the Ansible inventory file.
3. Trigger the playbook.

The code is modified to verify the file location.

Workaround: None.