SBC Core 09.02.03R003 Release Notes

Portfix SBX-112374: The SBC is intermittently stripping the last 'm=' line from an egress INVITE.

Impact: When "m=application" line is present in the SDP present in an incoming INVITE, and at the egress, the SBC does a DNS lookup. As a result, the SBC strips off the lines after m =application line.

Root Cause: As part of the fix introduced by a bug in 8.2.1, the NULL termination was added after the m=application line. This is causing the SDP to be truncated after the m=application line.

Steps to Replicate: 

1. In the offer SDP present in ingress Invite, add m=application line along with audio m-line.
2. At egress, the SBC should do a DNS lookup (the cache should be cleared before so that the SBC queries DNS.)

The code is modified to address the issue.

Workaround: Use an actual IP address in IP peer instead of a FQDN.

PortFix SBX-113238: An incorrect PAI CPC position.

Impact: When the SBC sends an egress INVITE with a PAI header, and presentation is allowed, the PAI CPC is put between the username and hostname of SIP URI. However, when presentation is restricted, it is present after the hostname in the SIP URI.

Root Cause: When a presentation is restricted, the code is checking the "Disable 2806 compliance" configuration and if that was enabled, it is populating the CPC parameter in PAI after the SIP hostname.

Steps to Replicate: 

1. Run a basic SBC and PSX configuration for a SIP to SIP calls to test the scenario.
2. On a PSX egress IP signaling profile, the following commands must be enabled:
   Egress IP Attributes->SIP Headers and Parameters->Flags->include CPC information
   Egress IP Attributes->SIP Headers and Parameters->CPC Mapping Flags->Map CPC when Presentation is Restricted
   Egress IP Attributes->SIP Headers and Parameters->CPC Mapping Flags->Send CPC Param In→PAI
   Egress IP Attributes->Flags->Disable 2806 compliance
   Egress IP Attributes->Flags->TTC ISUP Mapping
   Egress IP Attributes->Privacy->Privacy Information->P Assert IdEgress IP Attributes->Privacy->Flags->Include Privacy
3. On the SBC ingress and egress TGs, enable the cpcInterworkingForNNI, such as:
   set addressContext default zone ZONE2 sipTrunkGroup PCR5001_SBX_EXT signaling cpcInterworkingForNNI enabled
4. Send basic INVITE from peer A to the SBC ingress TG, in addition to basic headers, the following should be included:
   Privacy: id
   P-Asserted-Identity: "0xxxxxxxxx"<tel:+8xxxxxxxxx;cpc=ordinary>, "Anonymous"<sip:n3xxxxxxxxx@username.xxxx.xx.xx>
5. Verify that the SBC sends an INVITE to egress. The egress INVITE should include PAI header with cpc=ordinary placed in the URI before the @<ip address>, such as:
   P-Asserted-Identity: "Anonymous" <sip:3xxxxxxxx;cpc=ordinary@10.xx.x.xx:xxxx>, <tel:8xxxxxxxxxx;cpc=ordinary>

The code is modified so that if the cpcInterworkingForNNI is enabled on the trunk group, the CPC parameter is populated between the username and hostname of SIP URI in PAI header, irrespective of the "Disable 2806 compliance" setting.

Workaround: If "Disable 2806 compliance" is set to disabled, the issue is not present. However, if "Disable 2806 compliance" is required to be enabled, there is no workaround.

PortFix SBX-113702: Accounting Logs are not escaping special characters in calling name fields.

Impact: Accounting Logs not escaping special characters in calling name fields.

Root Cause: The SBC did not escape the non-alpha numeric character in the calling name, leading to incorrect "called asserted identity" field.

Steps to Replicate: 

Make a simple SIP-SIP call and validate the CDR subfield 60 - Called Asserted Identity display name comes as "%22NORTH SHORE RD%2CLLC%the 22".

Called Asserted Identity [sf:60] "NORTH SHORE RD, LLC"
NNI-Type [sf:61] <sip:+1xxxxxxxxxx@xxx.xxx.xx.xxx;user=phone>

The code is modified to escape non-alpha numeric characters in the calling name.

Workaround: None.

PortFix SBX-113986: The User-to-User parameter is duplicated in the Refer-To header.

Impact: When a REFER message is relayed, if transparency for all headers is active, URI parameters appear twice in the Refer-To header.

Root Cause: Interaction between transparency of all headers and relay of Refer-To header.

Steps to Replicate: 

1. Perform a relay of REFER message enabled in the IP signaling profile.
2. Run a SIP transparency profile with an "all" entry assigned to the SIP trunk groups.
3. Make a SIP to SIP call. From the UAS, send REFER to perform blind transfer. The REFER contains Refer-To header with URI User-To-User parameter, e.g.:
   Refer-To: <sip:+1xxxxxxx@john.smith.com?User-to-User=0059a390f3d2b7310023a2%3Bencoding%3Dhex>

The code is modified so that URI parameters only appear once.

Workaround: An SMM rule workaround is possible, if the Refer-To is relayed transparently.

PortFix SBX-114393: The TLS Session ID is listed as all zeros on the new 9.2.2R3 code.

Impact: The TLS Session IDs were not printed in the TLS Session Status command output.

Root Cause: The code was commented out in latest releases.

Steps to Replicate: Execute the TLS Session Status command with active TLS calls on the SBC. When the command is executed, the session Ids are printed as zero instead of valid session Ids.

The code is modified to print Session IDs in the TLS Session Status command output.

Workaround: None.

PortFix SBX-114426: There was a Standby SBC core dump on the CE_2N_Comp_SamP.

Impact: Memory corruption may occur in the SAM process if an IP Peer is deleted and then added back into a different zone.

Root Cause: The root cause is that the code that handles adding a new configured IP Peer may write into memory that has already been freed.

Steps to Replicate: The root cause of this bug was found by code inspection. There is a race condition that must occur for this bug to be exposed.

To attempt to reproduce:

1. Add four IP Peers.
2. Delete all four IP Peers.
3. Add the IP Peers back, but in a different zone.

The code is modified to prevent writing into an IP Peer structure which is freed.

Workaround: Avoid deleting an IP Peer and adding the exact same IP Peer back in a different zone.

No fallback to G711 for a fax call flow upon receipt of a 488 response.

Impact: The SBC is not sending fax fallback re-INVITE upon receiving 488 error response (for T38 re-INVITE) from UAS.

Root Cause: New code had been introduced in 8.02 of the SBC to address a few customer requirements related to the flag - bIsOlineSame flag.  None of those customer scenarios had any use cases involving Gw-Gw scenarios. There is a miss in the test coverage as a result. This new code has a missing initialization of one field that was being used for Gw-Gw scenarios, which is causing this issue.

Steps to Replicate: 

1. Establish a call over Gw-Gw with codec negotiated as G711.
2. Send T38 re-INVITE from UAC to SBC1.
3. The SBC2 sends out this T38 re-INVITE to UAS.
4. UAS responds back with 488 Not Acceptable.
5. The SBC2 sends ACK to UAS.

The SBC2 is failing to send a fax fall back re-INVITE to UAS.

The code is modified to address the issue.

Workaround: None.

Microsoft Teams has a Shared Line/Hold issue.

Impact: The SBC fails to send ACK after the mix of INVITE replaces and refer (Microsoft Teams Shared line/hold) feature.

Root Cause: After receiving a 200OK from the refer INVITE, the SBC fails to release tone announcement.

Steps to Replicate: The steps cannot be reproduced. 

The code is modified to correctly release the tone resource.

Workaround: Disable the tone as an announcement.

PortFix SBX-114367: Unable to delete an Announcement Package Element.

Impact: Deleting an element within an announcement package does not work.

Root Cause: The code for handling the announcement package element delete command was incorrect.

Steps to Replicate: Perform following configuration changes through the CLI:

1. Create announcementPackage test_pkg_1 with element test_element_1 .
   set profiles media announcementPackage test_pkg_1 packageId 101 element test_element_1 segmentId 11111
2. Show announcementPackage to verify it is created correctly.
   show profiles media announcementPackage test_pkg_1
   should display
   packageId 101;
   element test_element_1 {
   segmentId 11111;
   }
3. Delete test_element_1 from the package. 
   delete profiles media announcementPackage test_pkg_1 element test_element_1
4. Show announcementPackage to verify test_element_1 is removed.
   show profiles media announcementPackage test_pkg_1
   should display (without any elements)
   packageId 101;
5. Delete the package and verify it is successfully deleted.
   delete profiles media announcementPackage test_pkg_1

The code is modified to handle delete command for announcement package element correctly.

Workaround: Delete the announcement package, and then re-create it without the required element.

PortFix SBX-114303: Call to landline number was incorrectly listed as busy.

Impact: The SBCs try to map the non-E164 display name of p-asserted-Identity TEL to generic address for called user.

Root Cause: When the SBCs received both pai (tel) and pai (sip) headers, it attempts to treat as a Japan ttc even though the display name in pai(tel) is not E164 format.

Steps to Replicate: Run the following command string to replicate the issue:

config
sipTrunkGroup IAD signaling callingPalingParty enabled
Incoming msg has:
P-Asserted-Identity: "12345 test user " <tel:+1xxxxxxxxxx;rn=214960>, "12345 test user" <sip:+1xxxxxxxxxx;rn=214960@test.com>

outgoing INVITE
From, contact userpart is 12345

Validate if the display name is E164 format, then try to map display name as generic address for called user to address the issue.

Workaround: Use the SMM to delete incoming display name in pai(tel) header.

For an outgoing message, add it back if pai is config transparency.

PortFix SBX-110918: The SBC 7000 is showing DSP insertion with the reason DTMF, but the DTMF should not be displayed.

Impact: The following fields contain incorrect values when running a correct amount of calls (20,000 calls)

1. Ingress DSP reason.
2. Egress DSP reason.

Root Cause: These two fields are not Reset when the call is terminated and as a result, the values are preserved in this memory location from previous use.

Steps to Replicate: 

1. Run 20k A---B Transcoded call with ingress DSP reason as DTMF.
2. Change the configuration to pass-through.
3. Check the logs to see Ingress DSP reason is populated as "No DSP inserted" for a pass-through call.

The code is modified so that the value is not populated to the fields.

Workaround: None.

PortFix SBX-114020: A core dump occurred on a Standby SBC 5210 after a healthcheck failure - ENM Deadlock - while attempting register with the EMS.

Impact: Running multiple registers and deregisters of a high availability SBC pair, in a rare case can cause the standby SBC to core dump and restart.

Root Cause: The code on the standby SBC for processing the delete of an SNMP trap target can potentially cause a core dump.

Steps to Replicate: Internal code debugging mechanisms were used to verify that create and delete of SNMP trap target processing code is bypassed on the standby SBC.

The code is modified to bypass the processing on a standby SBC.

Workaround: None.

PortFix SBX-112252: The Verstat parameter is coming before the CPC in PAI header that is not in lexicographical order.

Impact: In the SIP P-Asserted-Identity header, in the TEL URI, the verstat parameter appears prior to the CPC parameter.

Root Cause: Order of parameters in P-Asserted-Identity header was not in lexicographical order.

Steps to Replicate: 

Make a SIP-SIP call.

Egress SIP trunk is configured with JJ9030 interworking profile flavor jj9030.

IP Signaling profile for egress trunk has "Include CPC Information" checked.

IP Signaling profile for egress trunk has "Include Privacy" checked.

The code is modified so the CPC appears first.

Workaround: None. 

PortFix SBX-113305: DNS recovery packet count of DSCP as "0".

Impact: The DNS probe packets are sent from the SBC with a DSCP value of "0".

Root Cause: The configured DSCP values were not set for DNS probe keepalive packets.

Steps to Replicate: 

1. Configure DNS server with a DSCP value.
2. Ensure the DNS server blacklisting is enabled.
3. Ensure the DNS query is configured DNS server.
4. Shut down the DNS server during this process.

Result: Observe that the configured DNS server is blacklisted and sending DNS probe packet towards a DNS server with configured DSCP value.

The code is modified to set a configured DSCP value for packets, including DNS probe packets.

Workaround: None.

PortFix SBX-114012: The SMM is not working when the From contains an escape character.

Impact: The SMM may fail to parse a display name in double quote string when the string has more than one escape characters next to each other of a header.

Root Cause: Logical error in parsing logic that causes a parsing failure.

Steps to Replicate: Configure a rule to access double quote string display name of uri header, or any parameter.

Ensure there is an input display name, such as From: "PhoneLite \\\"test1\\\"test2 " <sip:[field0]@dns.com>;tag=testing

The code is modified to address the issue.

Workaround: None.

PortFix SBX-109056: The SBC 5400 MS Teams CQ has transfers issues.

Impact: When a call with DLRBT enabled undergoes more than one transfer with REFER signaling and the final transferee does not accept the call, the SBC does not correctly reconnect the call back to the transferor.

Root Cause: For an A-to-B call, if B, for example, successfully REFERS the call to C, and then C attempts to REFER the call to D (or back to B), the SBC plays a ringtone towards A while the REFER is taking place.

However, when D rejects the call with a 480 "Temporarily not available" message, the SBC does not correctly disable the call context that is playing the tone, nor does it correctly re-enable the A-to-C call association.

Steps to Replicate: 

1. With DLRBT configured on ingress and egress of SBC. Establish an A-to-B call through the SBC.
2. Send a REFER from B to refer the call to C and complete the refer related signaling. This results in an A-to-C call.
3. Send a REFER from C to refer the call to D. Do not answer the call at D but reject it with a 480 "Temporarily not available" message.
4. Verify that the SBC stops playing tone towards A and re-establishes the A-to-C call again and media can correctly flow between A and C.

The code is modified to disable the tone playing towards A when a 480 is received and then correctly re-enable the call association back to the transferor.

Workaround: None.

PortFix SBX-114315: An SBC failover occurred because of an SCM Process core.

Impact: An SCM core can occur if the hostName in the From Header is longer than 64 bytes.

Root Cause: The code is copying the host name into an array that is not long enough to hold it. This results in memory corruption.

Steps to Replicate: Make a call where the hostName in the From Header is longer than 64 bytes.

The code is modified to use the correct size when copying the host name.

Workaround: None.

PortFix SBX-112547: The SBC routes call to 2nd DNS record if 503 is received after 18x.

Impact: The SBC routes an INVITE to next DNS record if 503 is received after 18x.

Also, even when the dnsCrankback flag is disabled, on getting 503/INVITE timeout case, the SBC reroutes an INVITE to next DNS record.

Root Cause: Due to a design defect, the SBC tries the next DNS record even if an error response is received after an 18x.

Also, retrying the next DNS record during a 503/timeout when dnsCrankback flag is disabled is legacy behavior. This behaviour is changed to retry the next DNS record only when the dnsCrankback flag is enabled.

Steps to Replicate: 

1. Configure the DNS server with two routes for the FQDN route.
2. Make an A-to-B call.
3. The SBC sends an INVITE to first DNS record of and B sends 18x and the 503.

The code is modified to not apply the DNS crankback procedure if an error response is received after a 18x. Additionally, the default behavior of handling timeout/503 when the dnsCrankback is disabled is updated as part of this fix.

With this fix, the SBC retries for the next DNS record only when dnsCrankback is enabled to ensure the error responses match the reasons configured in the crankback profile.

Workaround: None.

PortFix SBX-113053: Race Condition when 183 and 200 OK (INVITE) are received simultaneously. 200 OK is not relayed to other side.

Impact: Race condition between internal processing of the 200 OK for an UPDATE and a received 183 Session Progress.

Root Cause: After a 200 OK (UPDATE) is received, followed immediately by receipt of 183 Session progress, a subsequent 200 OK (INVITE) containing P-Early-Media header is queued indefinitely at egress when downstreamForking is enabled and earlyMedia forkingBehaviour is pemPriority.

Steps to Replicate: Egress SIP trunk group has downstreamForking is enabled and earlyMedia forkingBehaviour is pemPriority.

Make a call so that egress signaling is as follows:
--> INVITE (with SDP and P-Early-Media: supported)
<-- 100 Trying
<-- 183 Session Progress (with SDP and no P-Early-Media)
--> PRACK
<-- 200 OK (for PRACK)
--> UPDATE (with SDP)
<-- 200 OK (for UPDATE with SDP)
<-- 183 Session Progress (no SDP but P-Early-Media: sendrecv)
--> PRACK
<-- 200 OK (for PRACK)
<-- 200 OK (for INVITE) (This message gets queued forever).

The code is modified to eliminate the race condition.

Workaround: None.

PortFix SBX-113614: The ActiveRegCount is greater on the INGRESS side.

Impact: When registration(s) take longer than 90 seconds to complete, the ingress zone’s activeRegs count can increment, but not decrement, when the registration terminates. This may cause the ingress zone’s activeRegs count to grow incorrectly, and never reach ZERO (even after all registrations are terminated).

Root Cause: The SIPFE and SIPSG RCB allocation/deallocation become out of sync, indirectly causing the ingress zone's activeRegs count to increment and not decrement.

Steps to Replicate: Perform the endless REGISTER/403, or REGISTER/503, or REGISTER/603 sequence.

The code is modified to handle registration(s) that take longer then 90 seconds to complete. In this case, the SIPFE restarts the registration bind timer and avoids "prematurely" deallocating the RCB so that the FE and SG RCB(s) stay "in-sync".

Workaround: None.

PortFix GSX-54479: The isup-oli parameter is sending a single digit OLI value in isup-oli parameter for values 0-9.

Impact: The SBC sends all OLI digits as a single digit.

Root Cause: This functionality is not within spec.

Steps to Replicate: Make a call that uses OLI parameter.

The code is modified to add a leading 0 for OLI digits 0-9.

Workaround: None.

PortFix SBX-104348: STUN was received on the SBC and the SBC considers these packets are arriving on another IP. And as a result, the STUN wasn't processed. 

Impact: The SBC passes the STUN packets to wrong IP address when it received them on the alternate IP.

Root Cause: The SBC always uses the primary IP address of LIF to send out the packet, even when it receives the STUN packets on the alternate LIF IP.

Steps to Replicate: STUN received on alternate IP of LIF and the SBC does not respond correctly, which appears as the SBC not processing it.

The code is modified so the XRM traverses the IP address list to match the address where it received the packet, instead of directly using the primary IP to send the packets.

Workaround: None.

PortFix SBX-113853: The SBC experienced an intermittent crash.

Impact: When multiple duplicate Diversion headers are received and stiProfile is enabled and configured on the ingress trunk group, the SBC dumps core.

The issue only occurs if six or more Diversion headers are received but fewer than five of them are unique.

Root Cause: Removing duplicated Diversion headers from information sent to the PSX causes crash.

Steps to Replicate: 

1. Configure the stiProfile, enable, and assign to ingress trunk group.
2. Send an SIP INVITE containing six Diversion headers but only two of them are unique. In other words, send in two Diversion headers repeated three times.

The code is modified to remove the duplicate Diversion headers from information sent to the PSX.

Workaround: None.

The DBG logs was rolling rapidly with UacSendUpdate messages.

Impact: The SBC DBG logs were filling up quickly with the following log message.

114 10192021 114119.823662:1.01.03.16703.MAJOR .SIPSG: UacSendUpdate - local answer for UPDATE: LegSide=Ingress

Root Cause: The code was mistakenly printing logs at the MAJOR level.

Steps to Replicate: The log is generated during a call where the SBC tries to send an UPDATE out to ingress leg while the PRACK is pending for previous 18x sent.

The following control also needs to be disabled on the trunk group the messages are being sent on.
set addressContext default zone <zone name> sipTrunkGroup <TG name> signaling doNotAutoAnswer <enable/disable>.

The code is modified to only print the logs at an INFO level.

Workaround: None.

PortFix SBX-112996: There was a SCM core dump.

Impact: A rare race condition triggers a bug that caused SCM to core.

Root Cause: A bug in the code causes an attempt to access freed memory. This Gateway-to-Gateway bug has has existed for a very long time, but was not encountered until now.

The bug is triggered by a rare race condition.

Steps to Replicate: This bug was found through code inspection.

The bug is triggered by a rare race condition that is not reproducible.

The code is modified to avoid accessing freed memory.

Workaround: There is no workaround.

PortFix SBX-112366: A customer's redundancy had an unexpected switchover.

Impact: The SBC is coring in the IPsec/IKE code when a call is using an IKE Protection Profile that was configured without any algorithms.

Root Cause: The SBC coredumped in the IPsec/IKE code due to an attempt to de-reference a NULL pointer. The pointer is NULL because the IKE Protection Profile being used was configured without any algorithms.

Steps to Replicate: 

1. Configure an IKE Protection Profile without any algorithms.
2. Run a call that will use this profile.

The code is modified to check for a NULL pointer and take the correct error path when the pointer is NULL.

Workaround: When configuring the IKE Protection Profiles, ensure that an algorithm is configured for this profile.

PortFix SBX-112349: The SBC releases a 132 Release code (MODULE FAILURE) message when running an audit call.

Impact: An Async CMD Error reported by XRM that triggered call being torn down with release code 132 when running a  call audit.

Root Cause: Ribbon lacks the necessary level of detail to conclusively determine the root cause.

Steps to Replicate: Since we do not know the exact condition and what types of resources were involved, we cannot provide detailed test steps for this case.

Suggest running regular regression tests to attempt to reproduce the issue.

The code is modified for LE2MCAST, LE2MCAST_RTCP, LE2SPLITTER. The changes provided are based on source code inspection.

Workaround: N/A

PortFix SBX-112677: The SCMP cored in Late media passthrough calls over a GW-GW.

Impact: There was a coredump for a late media passthrough case.

Root Cause: Dereferences a NULL Pointer.

Steps to Replicate: For the SBC GW-GW setup.

Enable the LM passthrough flag.

Run the following procedure:

1. Ingress sends LM Invite.
2. Egress sends 18x with SDP.
3. Ingress sends SDP in Prack.
4. Once call is established, send LM re-Invite request from Egress.
5. Ingress responds with 200 Ok and receives ACK with SDP.
6. Ingress sends LM re-Invite request towards egress.

The code is modified to stop the coredump.

Workaround: None.

PortFix SBX-107747: Cyclic switchover tests - Observed a PRS Process core dump on the M-SBC1.

Impact: If an M-SBC instance transitions to active shortly after the instance comes up as standby, when certain performance stats are collected, the PRS process will crash.

Root Cause: When the instance comes up as a standby, the active instances send their metavariable information to the new standby instance. This information is sent twice for each active instances. The first metavariable information for each active instance is not received by the PRS process because the PRS process is not ready to receive it. If the instance switches to active before the second set of metavariable information is received, then the new active will not have metavariable information from the former active, which causes the PRS crash.

Steps to Replicate: 

1. Bring up an MSBC 4-1 cluster.
2. Restart the standby instance.
3. Immediately after the standby instance is fully up, restart one of the active instances.
4. After the standby instance is fully up as the active instance, in the CLI run the following command:

unhide debug
show table global icmpGeneralGroupCurrentStatistics

The code is modified so the CHM process queues the first set of metavariable information until the PRS process is ready to receive it, and then sends the information to the PRS process.

Workaround: None.

PortFix SBX-112445: Conference calls fail when taking a recorded (SIPREC) path, but they work when SIPREC settings are not enabled.

Impact: The SBC cleanup call during hold retrieval for the transferred call. This issue is observed only when the SIP Rec is enabled.

Root Cause: Invalid operation on media resource during call hold/unhold for the transferred call leads call to cleanup. This issue is observed only when the SIP Rec is enabled.

Steps to Replicate: 

1. Enable the SIP Rec.
2. Make a blind/attended call transfer and after successful transfer, perform a call hold and unhold.

The code is modified to not perform any invalid operation on media resources during call hold/unhold for the transferred call.

Workaround: NA.

PortFix SBX-112561: Regexp string was not exported by “user-config-export”

Impact: In the Regex, the SMM is lost while exporting a configuration using the user-config-export CLI command.

Root Cause: The XML formatting is trimming empty node values.

Steps to Replicate: 

1. Create the SMM Profile using the following command strings:
   
   set profiles signaling sipAdaptorProfile ESMM state disabled
   set profiles signaling sipAdaptorProfile ESMM advancedSMM disabled
   set profiles signaling sipAdaptorProfile ESMM profileType messageManipulation
   set profiles signaling sipAdaptorProfile ESMM rule 1 applyMatchHeader one
   set profiles signaling sipAdaptorProfile ESMM rule 1 criterion 1 type message
   set profiles signaling sipAdaptorProfile ESMM rule 1 criterion 1 message
   set profiles signaling sipAdaptorProfile ESMM rule 1 criterion 1 message messageTypes requestAll
   set profiles signaling sipAdaptorProfile ESMM rule 1 criterion 2 type header
   set profiles signaling sipAdaptorProfile ESMM rule 1 criterion 2 header
   set profiles signaling sipAdaptorProfile ESMM rule 1 criterion 2 header name WWW-Authenticate
   set profiles signaling sipAdaptorProfile ESMM rule 1 criterion 2 header condition exist
   set profiles signaling sipAdaptorProfile ESMM rule 1 criterion 2 header numberOfInstances number 1
   set profiles signaling sipAdaptorProfile ESMM rule 1 criterion 2 header numberOfInstances qualifier equal
   set profiles signaling sipAdaptorProfile ESMM rule 1 criterion 3 type parameter
   set profiles signaling sipAdaptorProfile ESMM rule 1 criterion 3 parameter
   set profiles signaling sipAdaptorProfile ESMM rule 1 criterion 3 parameter condition exist
   set profiles signaling sipAdaptorProfile ESMM rule 1 criterion 3 parameter paramType generic
   set profiles signaling sipAdaptorProfile ESMM rule 1 criterion 3 parameter name realm
   set profiles signaling sipAdaptorProfile ESMM rule 1 action 1 type header
   set profiles signaling sipAdaptorProfile ESMM rule 1 action 1 operation regsub
   set profiles signaling sipAdaptorProfile ESMM rule 1 action 1 headerInfo headerValue
   set profiles signaling sipAdaptorProfile ESMM rule 1 action 1 from
   set profiles signaling sipAdaptorProfile ESMM rule 1 action 1 from type value
   set profiles signaling sipAdaptorProfile ESMM rule 1 action 1 from value 172.xx.xx.xxx
   set profiles signaling sipAdaptorProfile ESMM rule 1 action 1 to
   set profiles signaling sipAdaptorProfile ESMM rule 1 action 1 to type header
   set profiles signaling sipAdaptorProfile ESMM rule 1 action 1 to value WWW-Authenticate
   set profiles signaling sipAdaptorProfile ESMM rule 1 action 1 regexp
   set profiles signaling sipAdaptorProfile ESMM rule 1 action 1 regexp string "
   "
   set profiles signaling sipAdaptorProfile ESMM rule 1 action 1 regexp matchInstance all
   commit
2. Run the following CLI command to export the configuration:
   user-config-export test.xml /profiles/signaling/sipAdaptorProfile
3. Delete the exported profile from the CLI with the following command:
   delete profiles signaling sipAdaptorProfile ESMM
   commit
   user-config-import test.xml
4. Run the following command:
   show configuration profiles signaling sipAdaptorProfile | display set | match string
5. Check if the Regex string field, and restore the original value.

The code is modified to use the external tool "xmllint" to format the XML.

Workaround: Manually edit the field in the XML file after an export and before an import to correct the issue.

PortFix SBX-111126: In the case of delayed offer, the SBC changes the attribute “a=sendonly” into “a=recvonly” before relaying the 200 OK INVITE.

Impact: The direction attribute in 200OK sent in response to late media reinvite is set to an incorrect value when the direction attribute received in 200OK from other side is a value other than a=sendrecv.

Root Cause: The datapathmode on the side receiving the late media invite is incorrectly copied from the SBC local datapathmode from the answer leg PSP receiving 200OK when sendSbcSupportedCodecsInLateMediaReinvite flag is enabled.

Steps to Replicate: 

1. Enable the sendSbcSupportedCodecsInLateMediaReinvite on the TG towards UAC.
2. Send a direction attribute a=sendonly/recvonly/inactive from the UAS.
3. Send the 200OK to UAC should have direction attribute as expected (a=sendonly/recvonly/inactive respectively) and media is as per expectation.
   UAC---------------------------------SBC------------------------------------------------UAS
   INV(no sdp)->
   INV(a=sendrecv)->
   <-200OK(a=sendonly/recvonly/inactive)
   <-200OK(a=sendonly/recvonly/inactive)
   ACK(sdp)->
   ACK(no sdp)->

The code is modified so the datapathmode in the active PSP on late media offer side is recomputed when the sendSbcSupportedCodecsInLateMediaReinvite flag is enabled.

Workaround: Disable the sendSbcSupportedCodecsInLateMediaReinvite IPSP flag on TG receiving late media reinvite.

The SBC is unable to recognize a PRACK message, when call hunts to a secondary route.

Impact: The PRACK was rejected with a 481 when the end-to-end PRACK is active if a call is cranked-back following a successful end-to-end PRACK on the earlier route.

Root Cause: If end-to-end PRACK is performed on the first route and then a late crank-back occurs, subsequent PRACK is rejected because stale information is present from the first route.

Steps to Replicate: 

1. Ensure the end-to-end PRACK is supported.
2. Make a SIP-SIP call that routes and 18x is received on the first route. As a result, the PRACK procedure is successful.
3. Have the call fail on the first route, e.g. with 404, and the SBC configured to crank-back to a second route.

The 18x is received on the second route. When the calling party responds with PRACK, the call has a  481 in response.

The code is modified so that end-to-end PRACK information is started fresh for each route.

Workaround: None.

A customer's SBC 7000 SIPREC metadata did not contain an ‘AOR’ parameter value.

Impact: In the SIPREC, the metadata sender and receiver's AOR fields for the tel URI were not populated properly.

Root Cause: Due to defect in the design, these fields were populated incorrectly.

Steps to Replicate: 

1. Configure the SBC with SIP Rec server.
2. Run a basic call with "tel" URI in From and To header.

The code is modified to populate as per requirements/standard.

Workaround: Not Applicable.

The call established prior to a switchover fails when put on hold after a switchover.

Impact: The call established prior to a switchover with a dynamic payload type fails when put on hold after switchover.

Root Cause: After a switchover, while processing the hold request, it was unable to locate the codec due to an issue in reconstruction of some flags in PSP data.

Steps to Replicate: 

1. Have a HA setup.
2. In IPSP, enable "Minimize relay of media changes from other call leg" flag and "lockdown preferred codec" is enabled.
3. Establish a call with dynamic codec like AMR.
4. Perform a switchover, once standby becomes active send a call hold request.
5. After a short period of time, send an call-un-hold request.

result: Call hold invite should be successful with 200 ok for that and call un-hold should also be successful.

The code is modified so that necessary flag for dynamic payloads in PSP data are reconstructed properly.

Workaround: Disable“Lock Down Preferred Codec” and enable “Relay Data Path Mode Changes".

The SBC Ladder diagram (.TRC file) shows a response from the wrong IP for a 400 Bad Request.

Impact: When an INVITE (with malformed syntax) is sent to a leg1 (pkt1) SIP signaling IP for the SBC, the SBC responds with a 400 Bad request. In the TRC log, for a 400 Bad request PDU, the Local IP/port is printed with a leg 0 (pkt0) SIP Signaling IP Address instead of leg 1 SIP Signaling IP Address. This occurs only when the SBC sends error response message.

Root Cause: During formatting of Error message, the code is incorrectly using the pkt0 SIP Signaling IP Address instead of a pkt1 SIP Signaling IP Address resulting in the incorrect value being printed in the TRC log.

Steps to Replicate: 

1. Set up a SIP-SBC-SIP.
2. Enable trace logging with level4 and key "peerIpAddress"
3. Run a SIP-SIP call, send INVITE with malformed syntax to pkt1 SIP signaling IP address such that the SBC sends a 400 Bad Request.
4. Verify that in the TRC log, for 400 Bad request PDU, the local IP value is pkt 1 SIP signaling IP address, same source IP where the INVITE message lands.

The code is modified to correctly read the SIP Signaling IP Address of the leg where the call lands.

Workaround: None.

The SBC 7000 is sending a re-INVITE before receiving an ACK to the 200 OK - multi-stream call.

Impact: The SBC removes transcodable codecs when the application media m-line is present with port as 0. This results in the SBC sending a re-INVITE without SDP.

Root Cause: By default, the SBC does not support transcoding on multi-stream calls. The problem here was that the code incorrectly identified that there was an application stream present even when the port was set to 0. This made it appear as a multi-stream call and resulted in the transcodable codecs being removed.

Steps to Replicate: Test Case 1: GW-GW Scenario

1. Make a G711-G711 GW-GW call.
   The SBC will send BYE to peers. The call will fail.
   Test Case 2: Non GW-GW Scenario
2. Configure below PSPs on ingress and Egress legs
   Ingress PSP:
   G729, G711U, G711A
   This Leg – G711U, G711A, EFR, EVRC,
   Other Leg – G711U, G711A,
   Enable Transcode if different pktsize, dtmf, silence suppression and honor preference.
   
   Egress PSP:
   G711SS
   This Leg – G711U, G711A,
   Other Leg – G711U, G711A,
   Enable Transcode if different pktsize, silence suppression
3. Make a G711-G711 call.

The user observes logs in TRC file and the SBC will send BYE to peers. The call will fail.

The code is modified so that the stream with a port 0 is effectively ignored when processing transcodable codecs.

Workaround: Enabling "AllowAudioTranscodeForMultiStreamCalls" flag on both ingress and egress PSPs will solve the issue.

The password policy is not recognized by the SBC.

Impact: The password policy not recognized by the SBC. By default, the admin rules were taken.

Root Cause: Password policy was assigned based on roles of the user.

Steps to Replicate: Go to Administration/Application Management. In Configure Password Rules tab, check by enable or disable "Use Separate Password Rules for Administrators" where you are able to change the password policy or not in change password model.

The code is modified to use the state variable in PasswordRule class

Workaround: Add new variable named "state" to PasswordRule Class as a workaround.

The SBC block list IP with the wrong port.

Impact: The ARS block lists port 0, when an INVITE contains a Route header without a port number, and 503 response contains a Retry-After header.

Root Cause: The code did not support a case where no port number is provided.

Steps to Replicate: 

1. Configure ARS Retry-After profile.
2. Enable callRouting useRouteSet received in ingress and egress trunk groups.
3. Use the UAC to send an INVITE containing Route without port number:
   Route: <sip:172.xx.xxx.xx;lr;dtg=SBX_EXAMPLE>

The UAS responds with 503 Service Unavailable with Retry-After header use CLI to check egress zone sipArsStatus.

The code is modified so when no port number is set, we now retrieve the port number from the transaction control block.

Workaround: Define an SMM rule that adds the port number (5060) if the Route header in the initial INVITE does not contain a port number.

Multiple SBC core dumps were detected.

Impact: There was forking hashtable corrupted memory.

Root Cause: Possibility of forking control fails to remove from hashtable when the resource is cleaned up.

Steps to Replicate: Unable to reproduce. Run high load with a NAPT, upstream forking and registration and taking a SIP signaling port down/up.

The code is modified to ensure the forking call is removed from hashtable when free.

Workaround: None.

The SBC cored when the subscribe crankback failure.

Impact: When a relay Subscribe tried to crank back for the second route and if the SBC does not find trunk group, the SBC may core.

Root Cause: The SBC cores due to duplicated memory freed.

Steps to Replicate: Configure two routes for the relay Subscribe. The second route is invalid.

After the first route exhausted, the SBC try to cranked back for the second route. The SBC fails to find trunk group for the second route.

The code is modified to prevent duplicated memory to be freed.

Workaround: Correct the second route.

PortFix SBX-107753: After the LSWU, the apache2 not coming up, resulting in an EMA or PM access issue.

Impact: After an upgrade, the Apache did not start.

Root Cause: Apache did not start due to a timeout while requesting a password. The Apache would need to be restarted manually especially in case of a failed upgrade.

Steps to Replicate: 

1. Perform an upgrade (LSWU/standalone).
2. If upgrade has failed, verify that the apache has come up properly with default keys and cert.
3. If upgrade has succeeded, verify that first Apache came up properly with default keys, then after app start, the installed keys and certs are being used by the Apache.

The code is modified to find any occurrence of the one-time-issue of server key getting corrupted in the future.

Workaround: In case of a failed upgrade or apache startup failure restart apache or apply the workaround mentioned in an issue relating to the apache2 failing after an LSWU. 

PortFix SBX-112447: The SIPRec recording failed for an EGRESS call with GCID 291515755.

Impact: The SIPREC sessions fail with the following "MAJOR" logs when a CS call is going for call a modification with re-INVITE and a corresponding re-INIVTE is triggered for this towards the SRS while a previous SRS SIP transaction is pending.

159 08192021 154751.374314:1.02.00.26912.MAJOR .SIPSG: sipsgRec.c (-5062) 529606794. [SipSgSendSRSMetadataUpdateCmd] SipSgSendSdpCmd Failed with status 491
185 08192021 154751.375973:1.02.00.26913.Minor .SIPSG: SIPRec Recording failed for EGRESS call with GCID 291518377 for Recorder 10.xx.xxx.xx:xxxx. Trunkgroup of Recorder: NICE_PRI_TG

Root Cause: The SBC always attempted to send another offer towards SRS even when a offer-answer was pending and this resulted in SRS session failure.

Steps to Replicate: Use the following set up to reproduce the issue.

1. Main Call (CS) session established.
2. SIPREC session (RS) is established.
3. CS call goes for modification with re-INVITE (Hold/Codec change).
   A SIPREC re-INVITE is triggered (based on CS re-INVITE).
4. The SRS does not respond for SIPREC re-INVITE.
5. Before the SRS answers the re-INVITE, a CS call triggers yet another modification with re-INVITE (unhold/codec change).
6. The SBC attempts to trigger SIPREC RE-INVITE again even when the previous transaction is pending and results in SRS session failure.

When a SIP Offer-Answer towards SRS is in progress, SBC shall not attempt to send another offer and instead shall queue the latest event until the current offer-answer is complete.

Workaround: None.

A SCM Process coreump occurred on the SIGABRT.

Impact: When the INVITE message contains trunk group/trunk context parameter information and the context is an FQDN, then the SBC can use this information to formulate the IP Peer information if there is none supplied from the PSX. This can result in an SCM process coredump, if multiple routes are returned from the PSX.

Root Cause: The internal processing code did not account for multiple routes and it was always freeing memory that was possibly assigned to the first route. However, when processing the second or subsequent routes in a crankback scenario, the memory on the first route freed once when routing the call on the second route and then again when the call was actually released. This second freed memory was invalid and results in a coredump.

Steps to Replicate: 

1. Pass in the trunk group and trunk context parameters that use FQDN information.
2. Ensure the PSX returns 3 routes and no IP Peer IP or FQDN information.
3. Return a crankback status code in response to the INVITEs sent on route 1 and route 2.
4. Release the call.
   

The code is modified to correctly manage the memory on the route being used for the call. The code change frees and allocates memory consistently for a route to avoid freeing the memory twice.

Workaround: Remove the trunk group/context using the SMM from the received INVITE.

Ensure the PSX only returns one route when processing trunk group/context information.

PortFix SBX-112857: Increase the VNFM response timeout.

Impact: By default, the VNFR logic had a 5 second timeout to get responses from VNFM for the REST requests that it sent, but it has been observed that in certain networks this timeout value is not enough. This leads to the VNFR timing out while the VNFM was still trying to send back a response and the VNFR never reported ready state in the VNFM.

Root Cause: A delay of 5 seconds was originally thought to be long enough but across multiple networks, this was insufficient.

Steps to Replicate: Try a relocation operation with VNFM across multiple sites and ensure the VNFR status returns to ready.

The code is modified so the timeout is now increased to 20 seconds.

Workaround: None.

PortFix SBX-112487: The LI connection to media server was not connected on a switchover.

Impact: When using a PCSILI (P-com-session-info flavour of LI) in an N:1 M-SBC setup and running the SBC release 8.2 or later, if there is a switchover, the connection to the LI server might not be re-established.

Root Cause: The standby instance was trying to maintain information about the operational status of the interface used for LI processing. But this was only happening correctly for the first instance. The status of the other instances was being misinterpreted and lost. So during the transition to active the LI code thought the interface was not available and did not try to establish the connection to the LI server.

Steps to Replicate: In an N:1 setup perform switchovers from each active instance to the standby and check that the connection to the LI server is restored.

The code is modified to collect the status of the interface after the instance is transitioned from standby to active, so that accurate interface information is available for LI processing.

Workaround: Bouncing the interface (e.g. ifup/ifdown that is used for LI connection), will help to recover the connection.

PortFix SBX-109006: The DSP DHC had a Failure and failed to coredump.

Impact: The FPGA based DSP Health Check (DHC) fails and as a result, no DSP coredump is collected. 

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

Steps to Replicate: Instrument the code to replicate the issue.

Reboot the node instead of running an application restart to address the issue.

Note: This is not a fix for the original issue, but just a proposed workaround to prevent or reduce further failures.

Workaround: None.

PortFix SBX-112971: The diameter process cored continuously when creating the diamNode entry.

Impact: The diameter process acts as a client and server. When it acts as server, on accepting TCP connection from the remote diameter client, the diameter process crashes due to an invalid operation.

Note: There is no use case where the diam process accept connection from remote diameter client, so this scenario not covered in our earlier testing. This issue observed during misconfiguration.

Root Cause: On accepting TCP connection from the remote diameter client, the diameter process tries to perform an invalid operation (null pointer access) and due to this, the diameter process crashes.

Steps to Replicate: Configure the diameter node in the SBC and simulate TCP client application that connects the diameter server (on port 3868).

The code is modified so the diameter process does not perform any invalid operation.

Workaround: Do not configure same IP address for the peer and for diameter node.

PortFix SBX-113413: The call failure with an extra INVITE is sending.

Impact: If A calls B over the SBC, the SBC sends INV with sendrecv to B. B sends 180/200 with recvonly. After call is established, the SBC sends a re-INVITE to B with data path mode as sendonly.

Root Cause: As part of a previous issue, a behavior change was introduced so that the SBC sends a hold re-INVITE (received from the network) to the other end. This was only for the cases where call is already on hold but data path mode is changed.

Steps to Replicate: 

1. Send an INVITE from A to B. The SBC sends sendrev to egress.
2. From B, send a 180 with recvonly.
3. From B, send a 200 Ok with recvonly.

A to B is connected.

When call is connected, there should not be an re-INV towards egress leg (with recvonly).

The code is modified so in the case when the SBC receives a re-INVITE from network and data path mode is changed, it triggers a new re-INVITE to the other leg.

In other cases, it would be same behavior (prior to SBX-111611).

Workaround: None.

PortFix SBX-107396: Error "SYS ERR - Error 0x3b Line 666" was being printed frequently.

Impact: SYS ERR repeatedly logged in SYS logs.

Root Cause: The SYS ERR seems to only occur for audio encoding type 0x3b, which is SPEEX_8. But we don't have enough information to determine the call flow that triggered it.

Steps to Replicate: The steps cannot be reproduced. 

The code is modified to replace the SYS ERR with a major level debug message with the GCID and audio encoding type to help future debugging.

Workaround: None.

PortFix SBX-110592: There was a misleading TRC message when issuing the callTrace action command start command.

Impact: The misleading TRC message when issuing a "callTrace action command start command".

Root Cause: There was no alarm/log message indicating a global call trace start action command.

Steps to Replicate: Issue the callTrace action command and observe the Trace log.

admin@vsbxsus2> request global callTrace action command start

Sonus Networks, Inc.0000000001600000000000000000000128V08.02.06A002 0000000000000000000000000000TRC2021082014593700000000000000
072 08202021 145941.298910:1.01.00.00002.Info .NRM: Call Trace Reset

The code is modified to display correct message indicating call trace being reset.

Workaround: None.

Portfix SBX-110755: The ACL rules configured with ipInterface are disabled on every SBC start/restart in SBC5400/10GB pkt configuration.

Impact: The IPACL rules created with ipInterface defined are not getting installed on the SBC 5400 systems when there is no license present, or after a license is added.

Root Cause: The NP will not install an IPACL rule with an ipInterface defined if that interface is not UP and active. The SBC will retry to install failed rules when it sees the port come up. In this scenario the timing is off, however, it tries too soon as the physical port is up but the associated ipInterface is not yet up.

Steps to Replicate: The test involves a SBC 5400 without a license for its 10G packet port. The IPACL rules with ipInterface defined on that packet port will then fail to install. Once the license is successfully added, the IPACL rules should be installed.

The code is modified to add an additional delay before attempting to reinstall the failed IPACL rules when the port comes up and to look for an additional failure that starts a timer and try again.

Workaround: Do not use IPACL rules with ipInterface defined.

PortFix SBX-110490: The IMS preconditions are failing due to UPDATE message race condition.

Impact: An UPDATE from the calling party is queued by the SBC because the SBC is waiting for 200 OK for the previous update sent to called party, and when the 200 OK is received, the SBC did not forward the queued Update.

Root Cause: Precondition parameters received as part of UPDATE from ingress endpoint is not updated in the egress CCB.

Steps to Replicate: 

1. Configure preconditions to transparent on both legs.
2. Configure transmitpreconditions to supported on both legs.
3. Run the script so that there is difference in precondition parameters in an INVITE and UPDATE messages from ingress.
   
   invite: a=des:qos mandatory local sendrecv
   a=curr:qos local none
   a=des:qos optional remote sendrecv
   a=curr:qos remote none
   
   (AS script)183 in Progress: a=curr:qos local sendrecv
   a=curr:qos remote none
   a=des:qos optional local sendrecv
   a=des:qos mandatory remote sendrecv
   a=conf:qos local sendrecv
   
   (IAD script)update : a=curr:qos local sendrecv
   a=curr:qos remote sendrecv
   a=des:qos mandatory local sendrecv
   a=des:qos optional remote sendrecv
4. Send the update from the Ingress when the SBC is waiting for 200 of the previous update it sent to egress.

Verify that the SBC sends the queued update, once it receives the 200 ok for the 1st update.

The code is modified so the precondition level of support was set to transparent on both legs in configuration.

When the SBC receives precondition parameters as part of an UPDATE and preconditions are transparent, then the SBC saves the precondition parameters into the egress CCB. When the queued update message is being processed there is check for preconditions flag and comparison of precondition variables is done to send the update to called party.

Workaround: Enable the "Disable media lockdown" flag in IPSP for egress leg so that the SBC does not send the first update.

PortFix SBX-109364: The SBC ERE was unable to handle "sonusdomain.IP" as a keepalive response from DNS.

Impact: The SBC ERE was unable to handle "sonusdomain.IP" as a keepalive response from DNS.

Root Cause: A format Error (dns_rcode_formerr) return code of a DNS server was unable to whitelist a server that was block listed.

The DNS server is not getting whitelisted from a block list since the Format Error (dns_rcode_formerr) return code is not handled in the code.

Steps to Replicate: 

1. Configure the ARS profile.
2. Make a DNS server query with invalid format.
3. Verify the alarm to check that the server is on a block list.
4. Check after sending an ICMP message,the  server is on a permit list.

The code is modified to fix the issue.

Workaround: None.

Portfix SBX-112429: The NrmGetCallCount was returning max global callcount, instead of the current stable calls.

Impact: The I-SBC sends the total (cumulative) number of stable calls instead of current stable calls to the SLB in its utilization message. This could result in the SLB dropping messages if it thinks the I-SBC has reached 100% utilization.

Root Cause: The I-SBC was providing the wrong number of stable calls to the SLB.

Steps to Replicate: 

1. Bring up the SLB-ISBC setup.
2. Run a call load.
3. Check in the SLB about current utilization of the I-SBC.

The code is modified to provide the current number of stable calls in the utilization message to the SLB.

Workaround: None.

Portfix SBX-11174: The SBC takes 72 seconds to send BYE to transferor after call termination.

Impact: The SBC is taking 72 seconds to send BYE to the transferor when the transferee disconnects before a transfer target accepts the call.

Root Cause: One of the disconnect events towards transfer target is getting ignored in the call control state machine. As a result, a release timer of 70 seconds is getting triggered later and the SBC is sending BYE towards transferor.

Steps to Replicate: 

1. A and B call is connected.
2. B sends a REFER to the SBC.
3. The SBC sends a new INV to transfer target C.
4. C sends 180 Ringing to the SBC.
5. A sends BYE to the SBC before C answers the call.

The code is modified so that the SBC sends a disconnect immediately towards the transferor.

Workaround: None.

PortFix SBX-98627: The Min-SE header is getting added to the ingress metaDataProfile even though it is not in the initial INVITE.

Impact: For the SIPREC, the Min-SE and Session-Expires headers are added to the metaDataProfile even though it is not received in the initial INVITE.

Root Cause: When receiving an INVITE, the SBC was incorrectly inserted Min-SE and Session-Expires headers as part of an incoming INVITE.

Steps to Replicate: 

1. Configure the SIPREC set up and Min-SE and Session-Expires in sipRecMetadataProfile.
2. Receive an incoming INVITE without the support timer and no Min-SE, no Session-Expires.

The code is modified so if an incoming INVITE is missing support for a Timer, the SBC resets the value of the Min-SE and Session-Expires only if it is received.

Workaround: Use the SMM to delete the Metadata in the SIPREC INVITE.

Portfix SBX-105688: The TAP ID of an ingress target was not getting embedded in the CCID for IMSLI (both leg interception).

Impact: When a call has matched the ingress and egress LI criteria/target for a SIP Out of Dialog message and if each of the criteria was configure with different TAP IDs over the X1 interface, only one of the TAP IDs was processed by the SBC.
This resulted in an incorrect TAP ID being sent out for one of the intercepted leg in the Correlation-ID (CCID) and in the TAP ID AVP field (202) of the X2 messages.

Root Cause: The SBC always stored only one TAP ID, the TAP ID present in the 0th index of the LI criteria table that is returned by the PSX and it did not store the TAP IDs corresponding to ingress and egress criteria separately.

As a result, whenever both legs are intercepted for OOD messages, one of leg would have the incorrect TAP ID in the CCID for X2 messages.

Steps to Replicate: 

1. Configure the SBC with the PSX and EMS for IMSLI Lawful interception.
2. Configure the IMSLI for both Leg and set targets using EMS with different TAP ID.
3. Make a subscribe request with the same targets configured.
4. Verify that TAP ID received for both legs are correct.

The code is modified to store and process the TAP ID for both the ingress and egress target criteria.

Workaround: None.

PortFix SBX-109103: There was an incorrect UDP port used in the Record-Route and Contact on the core side.

Impact: The SBC populates an invalid port in the Contact/Record-Route header towards the IMS Core side in call progress (180/200) responses.

Root Cause: The signaling engine in the SBC, during a call, progress command modifies the ports without validating the direction of message flow and causes the SBC to populate an invalid port in the SIP responses.

Steps to Replicate: 

1. Send an IMS-AKA registration request from a UE device.
2. Ensure the IMS-AKA registration is successful.
3. Let the registered user receive call from IMS network.
4. When UE accepts the call, we can observe in the call progress response sent from the SBC towards the IMS Core will have the invalid port in contact/Record-Route headers.
   
   Flow: IMS Core --(SIP UDP)-> SBC ---(SIP IPSec TCP)--> Peer (UE)

The code is modified to identify the direction before changing ports, change only when the flow is towards the UE.

Workaround: Use the SMM to change the ports in Contact and Record-Route headers.

PortFix SBX-101255: The OAM should not configure the same IP for two different pkt interfaces.

Impact: The OAM is allowing the same IP and alternate IP to be configured under the same address context.

Root Cause: During an address context, the interface creation OAM was allowing the configure of the same IP address (IpV4/IpV6) and alternate IP address for different interfaces.

Steps to Replicate: The meta table is added for ipVarV4/ipVarV6/altIpVars value. When creating the ipInterface table, we  should also observe ipInterfaceIpVarVMeta(hidden)

The meta table is created for ipVarV4/ipVarV6/altIpVars. For all test cases, the following table can be observed:

Case 1: Create ipInterfaceGroup,ipInterface and assign ipVarV4
Create 2nd ipInterfaceGroup,ipInterface and assign same ipVarV4 value, confd should throw an error for unique value in a address context.

Case 2: Create ipInterfaceGroup,ipInterface assign ipVarV4 and altIpVars same as the one in ipVarV4
should throw an error for unique value.

Case 3: Create ipInterfaceGroup,ipInterface assign ipVarV4 and altIpVars
Create 2nd ipInterfaceGroup,ipInterface assign ipVarV4 and same altIpVars value as previous
confd should throw error for unique value.

Case 4: Create ipInterfaceGroup,ipInterface assign ipVarV4 and altIpVars
Delete ipInterfaceGroup,ipInterface ipVarV4
Delete ipInterfaceGroup,ipInterface altIpVars
Delete ipInterfaceGroup,ipInterface
All combination of delete should work

Case 5: The same test to be done for ipVarV6.

Any other tests are related to ipVarV4/ipVarV6/altIpVars creation/deletion

The code is modified to have a unique IP address (IpV4/IpV6) and alternate IP address for an address context. New meta data is created for validating uniqueness efficiently.

Workaround: Do not configure the ipVarV4/ipVarV6/altIpVars

PortFix SBX-111019: The SBC should not allow to configure the same IP for two different pkt interfaces.

Impact: The SBC should not allow to configure same IP for two different pkt interfaces.

Root Cause: After a playback file pushed to the SC nodes, the dummy validate is invoked before creation of the addresscontext table, ipInterfaceIpMetaVar table to be moved out of addresscontext yang.

Steps to Replicate: The meta table is added for ipVarV4/ipVarV6/altIpVars value. When creating the ipInterface table, we  should also observe ipInterfaceIpVarVMeta(hidden)

The meta table is created for ipVarV4/ipVarV6/altIpVars. For all test cases, the following table can be observed:

Case 1: Create ipInterfaceGroup,ipInterface and assign ipVarV4
Create 2nd ipInterfaceGroup,ipInterface and assign same ipVarV4 value, confd should throw an error for unique value in a address context.

Case 2: Create ipInterfaceGroup,ipInterface assign ipVarV4 and altIpVars same as the one in ipVarV4
should throw an error for unique value.

Case 3: Create ipInterfaceGroup,ipInterface assign ipVarV4 and altIpVars
Create 2nd ipInterfaceGroup,ipInterface assign ipVarV4 and same altIpVars value as previous
confd should through error for unique value.

Case 4: Create ipInterfaceGroup,ipInterface assign ipVarV4 and altIpVars
Delete ipInterfaceGroup,ipInterface ipVarV4
Delete ipInterfaceGroup,ipInterface altIpVars
Delete ipInterfaceGroup,ipInterface
All combination of delete should work

Case 5: The same test to be done for ipVarV6.
Once saveAndActivate is called data should reflect in SBC as well.

Case 6: Upgrade testing to be performed like from 9.x to 10.x.
case 7: error case for upgrade testing, configure ipVarV4/ipVarV6/altIpVars and use same values for different ipInterface within an address context and post upgrade should get an error log for contacting sonus customer service to make the values unique.

Run any tests related to ipVarV4/ipVarV6/altIpVars creation/deletion

The code is modified to move ipInterfaceIpMetaVar out of addresscontext yang.

Workaround: None.

PortFix SBX-111956: An early media case in SIPREC re-INVITE is not triggered with latest values for metaDataSource=fromLatest.

Impact: Call modification events like codec change/hold/un-hold on the CS that occur before the RS Session is established is not propagated to the RS Call (SIPREC Session).

Root Cause: The SBC does not attempts to trigger SIPREC re-INVITE with updated session characteristics when initial SIPREC INVITE transaction itself is pending with SRS and Main Call received a re-INVITE.

Steps to Replicate: Run the following procedure to recreate the scenario:

• Main Call (CS) session established.
• SIPREC INVITE (RS) is sent towards SRS.
• SRS does not respond for SIPREC INVITE. (SBC - SRS INVITE transaction is pending).
• CS call goes for modification with RE-INVITE. (Hold/Codec change).
• SRS answers the initial SIPREC INVITE after Main CS Call RE-INVITE.

The code is modified to queue the SIPREC RE-INVITE event when an initial SIRPEC INVITE transaction is pending.

When the initial SIPREC INVITE transaction is completed, the queued SIPREC RE-INVITE is sent towards the SRS (This contains the latest session characteristics).

Workaround: None.

PortFix SBX-110985: If the VM name in the upper right corner of the "Configuration Manager" EMA/EMS SBC Manager is clicked, the browser freezes.

Impact: If the VM name in the upper right corner of the "Configuration Manager" EMA/EMS SBC Manager is clicked, the browser freezes.

Root Cause: The issue occurred because the peer setup was unreachable and to get the peer system info, the curl command that is executed was taking default timeout to get a connection timeout.

Steps to Replicate: 

1. Log into EMS.
2. Launch the SBC Node.
3. Click on Monitoring -> System and Software info tab.

The code is modified to address the issue.

Workaround: Refresh the UI page.

Portfix SBX-112082: There was an runtime error: member access within null pointer of type 'struct CC_SG_ALERTING_UIND_MSG_STR in CcSgAlertHndl.

Impact: Run a basic G711U pass-thru call. After the call got completed, ASAN runtime error is observed in the system logs indicating that the code is taking the address of a field within a null pointer. This could potentially lead to coredumps if using the SIP recording capabilities other than SIPREC.

Root Cause: When a call Progress/Alerting message is received from the network, the code was taking the address of a field within the pointer.

Steps to Replicate: Run a basic call.

The code is modified to validate that the pointer is not null taking the address of a field within the pointer.

Workaround: None.

PortFix SBX-113278: Need a configurable item added to indicate a legacy meshed network on GW link to lower MAX_ICM value

Impact: A call sent from an SBC running 9.0 or above to a older GSX may cause the GSX to core.

Root Cause: In 9.0, the PDUs sent from the originating GW to the destination GW in a GW-GW call has increased in size.
When the destination GW is an older GSX, the PDU may be larger than the buffer allocated on the GSX for receiving this PDU.

In this case, the GSX does not expect a PDU this large and this will result in the GSX overwriting the allocated buffer causing memory corruption that eventually leads to a core.

Steps to Replicate: 

Send an SBC-GW-GW-GSX call involving text (T140) streams.

As a result, the GSX may crash.

To test the fix:

1. Load the new code.
2. Enable oldGsxSupport
   "set global signaling oldGsxSupport"
3. Send an SBC-GW-GW-GSX call involving text (T140) streams (this is just 1 way to cause the large PDU to be sent).

The GSX should not crash.

The code is modified so the new configuration parameter is enabled if there are any older GSXs in the network:

set global signaling oldGsxSupport

When this parameter is enabled, the SBC reduces the max size of the PDUs that can be sent over a GW-GW connection to older GSXs and older SBCs.

Workaround: There is no workaround.

PortFix SBX-112708: The NOTIFY XML body for 200 OK for INVITE does not contain new values that were updated between 180 and 200.

Impact: The SBC was not sending latest received P-Asserted-Identity in the call NOTIFY XML body.

Root Cause: The SBC was not considering the latest received P-Asserted-Identity and was always sending the first received message in call NOTIFY XML body.

Steps to Replicate: Steps:

1. Enable the call Notification feature both legs.
2. Send different PAI headers in the 18x and 200 OK.

Expected Result:

The SBC sends ringing NOTIFY with the XML body contains PAI element that received in 18x and while sending a connected NOTIFY should consider PAI received in 200 OK.

The code is modified to consider the latest received P-Asserted-Identity identity for populating a call NOTIFY XML body.

Workaround: None.

PortFix SBX-110997: There are media problems due to same SSRC after hold/MOH/resume and a previous fix's flag was not helping.

Impact: The SBC is not changing local SSRC during a HOLD/RESUME of a Transcoded call.

Root Cause: During a HOLD/RESUME of a Transcoded call, the NP was not updated with the new SSRC generated by the SBC, and this resulting in the old SSRC being used in media packets.

Steps to Replicate: 

1. Run a basic Basic transcoded HOLD/RESUME SRTP call with the flag enabled.
2. Ensure that during a HOLD, only data-path-mode is changed to sendonly and recvonly respectively to trigger modify scenario and rest of the media attributes remains same.
3. Validate the media packets for change in the SSRC.

The code is modified to update NP with the latest SSRC generated during mid-call modification due to HOLD/RESUME of Transcoded calls.

Workaround: If possible, switch to pass-through calls since this issue is specific to transcoded calls only.

PortFix SBX-113048: Edited the External IP Interface group name disappearing in Visual First Call View as a diagramSetup. page

Impact: Edited the External IP Interface group name disappearing in Visual First Call View as a diagramSetup page.

Root Cause: The existing  system did not handle save functionality when an external "IP Interface Group" was not empty.

Steps to Replicate: 

1. Login to EMA as an admin user.
2. Go to Configuration->Configuration Wizards->Visual First Call Setup.
3. Configure the fields in Carrier and save.
4. Make changes to IP Interface Group and Save.
5. Navigate to All →Admin and then navigate back to Configuration->Configuration Wizards->Visual First Call Setup

After navigating back to Visual First Call Setup, the changes were saved i.e. Carrier type and IP Interface Group should be visible.

The code is modified for the External "IP Interface Group" for both empty and non-empty cases.

Workaround: None.

PortFix SBX-111721: The EVS encoder picks up the initialCodecMode as the bitrate after switch to Compact Format.

Impact: The EVS encoder picks up the initialCodecMode as the current bitrate if a change in packet format from Header Full to Compact is triggered.

Root Cause: The root cause is the re-initialization of EVS encoder with bitrate as the initialCodecMode on change in packet format.

Steps to Replicate: 

1. Run a EVS<=>AMRWB call.
   br=5.9-24.4; bw=nb-wb
2. Stream a WB pcap with 13.2Kbps packets with CMR byte for 13.2 CA mode for the first 10s. After, the pcap has 24.4 Kbps packets without the CMR.

Results:
The mode of operation changes from 24.4Kbps to 13.2 Kbps with CA enabled on receiving the CMR. Once the Endpoint starts sending 24.4 Kbps packets without CMR, the SBC switches to Compact Mode while maintaining its bitrate as 13.2 Kbps with CA enabled.

Prior to the fix, when switching to the Compact mode, the SBC would use 24.4Kbps (initialCodecMode) as the bitrate.

The code is modified to the re-initialize the EVS encoder with bitrate as the localCodecMode rather than the initialCodecMode.

Workaround: None.

PortFix SBX-111896: Automatic daily updates in HFE script for Azure/GCE were causing the network to reset.

Impact: Networking on the HFE can be reset by automatic updates.

Root Cause: Ubuntu, by default, has an automatic package updater. Some package upgrades can cause the networking to be reset on the HFE node.

Steps to Replicate: Check if the following timers are enabled:

• sudo systemctl status apt-daily.timer
• sudo systemctl status apt-daily-upgrade.timer

The code is modified to disable the timer that triggers the automatic updates. Package upgrades should only occur out of hours.

Workaround: Run the following commands to disable the the updates:

• sudo systemctl stop apt-daily.service
• sudo systemctl stop apt-daily.timer
• sudo systemctl stop apt-daily-upgrade.timer
• sudo systemctl stop apt-daily-upgrade.service
• sudo systemctl disable apt-daily.service
• sudo systemctl disable apt-daily.timer
• sudo systemctl disable apt-daily-upgrade.timer
• sudo systemctl disable apt-daily-upgrade.service

Portfix SBX-110291: AddressSanitizer: The ASAN detected a heap-buffer-overflow-SipSgIncomingCallNfy (unsigned int, sip_addr_str*, sip_msgbody_str*, sip_options_str*, unsigned int, unsigned int, bool) /sonus/p4/ws/jenkinsbuild/sbxAsan100/marlin/.

Impact: The ASAN detected "AddressSanitizer: heap-buffer-overflow" while copying the contents of the SIP-I base version string internally.

Root Cause: The SIP code was always copying a fixed amount of memory when reading the SIP-I base and version strings to internal memory.

Steps to Replicate: Run a SIP-I call flow with INVITE and CANCEL messages.

The code is modified to copy exactly string length size of the SIP-I base and version content to avoid reading past the end of memory buffers as this can cause coredumps.

Workaround: None

During a sRTP and fax call, the sRTP context is removed for G711 fax pass-thru.

Impact: The sRTP context is removed on the leg that has a G711 fax when there is a t38 to g711 fax call.

Root Cause: The sRTP context is not updated for G711-fax.

Steps to Replicate: 

1. Run an A(SRTP)-B(RTP) CALL.
2. Run a leg A is G711 fax and B is T38. B sends a re-INVITE with t38 fax.
3. Check the re-INVITE that goes out with SRTP to endpoint A.
4. A party sends 200 ok with SRTP.
5. End the call.

The code is modified so the the SRTP context is updated only if the calleg has G711 fax.

Workaround: None.

The SBC was answering on-hold call with the sendrecv then re-inviting.

Impact: On an incoming INVITE onhold, the SBC responds to the 18x offhold and later the re-INVITE onhold.

Root Cause: There was a logical error that converts from an inactive to sendrecv when the first 18x is sent out.
This issue was introduced a previous fix listed in the 9.2.1 release.

Steps to Replicate: 

On the ingress, configure the Minimize flag, and uncheck relay data path mode.

Incoming Invite onhold, egress response 18x.

The SBC send 18x to ingress with sendrecv.

The code is modified to apply for subsequent 18x only.

Workaround: Enable the relay data path mode.

The SBC was sending Empty Packets when playing an Announcement.

Impact: Announcement packets are empty for two stage calls if the NAPT enabled on the ingress.

Root Cause: The ARM was not getting indication to start the announcement once NAPT learning was complete.

Steps to Replicate: Set up a two stage call and enable the NAT on ingress.

The code is modified to send an indication to start the announcement once NAPT learning was complete

Workaround: Disable the NAT.

An SBC 7000 dual crash within 1 minute (old Active side - Fm, new Active - Scm).

Impact: The application on both active and standby switched over and the application reset in a short order of each other. Core files are created on both sides of the HA pair.

Root Cause: The issue occured during multiparty call processing where the SBC tries to determine a whether message was sent for the ingress or egress call segment. The code was accessing the pointer to the multi party call resource after it was freed up and set to NULL.

Steps to Replicate: This issue is not reproducible. Potentially due to a race condition in the code.

The code is modified so the multi party call pointer is not NULL before reading from it to avoid the coredump.

Workaround: There is no known workaround for this issue.

The SRTP license counter did not incremented when the called side omits an SIP 18x response.

Impact: The license count for the SRTP license was not updated on a call from SRTP to RTP, if no 18x response message is received.

Root Cause: The SRTP license usage is not updated at the ingress when response to an INVITE is only 200 OK message. Therefore, if the egress is not using a SRTP, the call does not consume a license.

Steps to Replicate: Make an SIP-SIP call where the ingress leg uses SRTP and egress leg uses RTP.
The called side does not sent any 18x response.

The code is modified to correctly update the license count at ingress, even when no 18x is sent.

Workaround: None.

No INFO Logging Warning is provided when enabling the info debug/sys.

Impact: The SBC CLI/EMA does not provide any warning when enabling INFO logging, indicating impact to system performance and call processing.

Root Cause: There was no code to provide the warning to user.

Steps to Replicate: Run the following script to reproduce the issue:

admin@sbxsus12% set system admin sbxsus12 cliSetWarningOnEnablingInfoLevelLogging
[disabled,enabled] (disabled): enabled
[ok][2021-08-19 17:12:13]

[edit]
admin@sbxsus12% com
Commit complete.


admin@sbxsus12% set oam eventLog typeAdmin debug filterLevel info
[ok][2021-08-19 17:14:51]

[edit]
admin@sbxsus12% com
The following warnings were generated:
'oam eventLog typeAdmin': Enabling INFO level logging can be service impacting. Do you want to continue?
Proceed? [yes,no] no
Aborted: by user
[ok][2021-08-19 17:15:41]

[edit]
admin@sbxsus12% com
The following warnings were generated:
'oam eventLog typeAdmin': Enabling INFO level logging can be service impacting. Do you want to continue?
Proceed? [yes,no] yes
Commit complete.
[ok][2021-08-19 17:15:46]

admin@sbxsus12% set oam eventLog typeAdmin system filterLevel info
[ok][2021-08-19 17:16:37]

[edit]
admin@sbxsus12% com
The following warnings were generated:
'oam eventLog typeAdmin': Enabling INFO level logging can be service impacting. Do you want to continue?
Proceed? [yes,no] yes
Commit complete.
[ok][2021-08-19 17:16:40]

The code is modified to provide a warning to the user when enabling INFO level logging for system or debug logs. To maintain backward compatibility and not break any customer scripts, a user needs to enable this extra prompt.

Workaround: None.

STIR/SHAKEN services were failing in the second dip in 2-stage call (SIP-SIP).

Impact: The SBC was not sending STIR/SHAKEN parameters, such as identity headers, to the PSX in the trigger request portion of a two-stage call or processing the STIR/SHAKEN parameters in the response.

Root Cause: The SBC was missing code to handle the interaction between two-stage calls and STIR/SHAKEN logic.

Steps to Replicate: Make a two-stage call where the INVITE contains identity headers and check they are sent to the PSX in both the policy request and trigger request.

The code is modified to send STIR/SHAKEN parameters such as identity headers to the PSX in the trigger request portion of a two-stage call and process the STIR/SHAKEN parameters in the response.

Workaround: None.

The SIP ACK was missing in TRC, although the SBC sent one.

Impact: The 200 OK for the INVITE received on the egress call leg contains a Record-Route header with an FQDN. The SBC resolves the Record-Route FQDN through the DNS and routes the ACK to the resolved target. The SIP ACK PDU that the SBC sent to the egress call leg is missing in the TRC log.

Root Cause: The root cause is in SipsDnsLookupRspForTCB() when the DNS response comes back.
SIP_CALL_STR *pstCall is set as NULL when SipsTXNDownstreamMsgToFsm is called. Due to the NULL check of pstCall in later functions, the SipSgTraceDumpSipPdu() is not called to log ACK PDU in TRC log.

Steps to Replicate: 

1. Set up: SIP-SBX-SIP.
2. Create a dnsgroup and configure the external DNS IP Address. Attach dnsgroup with egress zone.
3. Create a global calltrace filter with "level1" and key "calling".
4. Start the global calltrace and roll trace log event.
5. Run SIP-SIP call. 200 OK for the INVITE received on the egress call leg contains Record-Route with an FQDN.
6. Verify that egress ACK PDU is logged in TRC log.

The code is modified so in the function SipsDnsLookupRspForTCB, SIP_CALL_STR* pstCall is fetched and use in SipsTXNDownstreamMsgToFsm.

Workaround: None.

There were  Error logs in DBG file after upgrade on 9.2.1

Impact: The SIPFE was reporting two kinds of major level error messages in the DBG logs:

1. port range id not found from SipFePortRangeCnxSendDataReq()
   e.g. SipFePortRangeCnxSendDataReq 366] PORT_RANGE: id not found 412765
2. port range id not found from SipFeRedundMirrorHashSync()
   e.g. SipFeRedundMirrorHashSync 1372] PORT_RANGE: failed to find Connection id in HAsh[4194719]

Root Cause: Port Range Support was added in a previous feature that involves four subsystems, SIPSG, SIPFE, SIPCM and XRM, among 3 processes. There were several message exchanges between the four subsystems before a port range connection is fully established.

Under certain circumstances, it is possible to hit some race conditions and find major DBG messages in DBG logs.

Steps to Replicate: The steps cannot be replicated.

The code is modified to print extra call related data in the current major level debug messages to help triage more if the problem occurs in the future.

When the issue occurs again, the call ID, signaling port Id, etc., is collected to help identify the call. The SipFeRedundMirrorHashSync() log is reduced from MAJOR level as well.

Workaround: N/A

Reloading previous configuration fails when the LDAP delayedSync is enabled.

Impact: The delayed sync leaf used to accept only a future time if a configuration export and import is performed and if the system time is greater than the delayed sync time during import than import fails.

Root Cause: The delayed sync leaf used to accept only a future time if a configuration export and import is performed and if the system time is greater than the delayed sync time during import then import fails. It fails due to the check on the delayed sync leaf value that should be greater than the current system time.

Steps to Replicate: Use the following configuration:

1. Add a profile with a future time value on the delayed sync leaf. Export the configuration.
2. Clear the db.
3. Import the configuration when the system time is greater than the configured delayed sync time.
4. Import would fail without this fix.

Remove the restriction on the delayed sync leaf to be greater than the current system time to address the issue.

Workaround: Modify the delayed sync time in the export CLI.

Correct the 92x serialization code for a registration control block.

Impact: When the registration control block is made redundant and the active/standby instances are running different software releases e.g. during upgrade, the redundancy logic might not work correctly if the registration control block contains a P-Charging-Vector (PCV) and/or P-Charging-Function-Addresses (PCFA) information. The redundancy logic will work correctly post upgrade when serialization of the redundancy data is not required.

Root Cause: The parameter lengths of the PCV and PCFA redundant parameters was not calculated correctly. This can lead to the redundancy code being unable to process all the redundancy information correctly.

Steps to Replicate: Run registration related tests with PCV and PCFA header parameters in an older release and then upgrade to 922R2 or later.

The code is modified to correctly set the length of these parameters to avoid problems with redundancy.

Workaround: None.

The SBC is not decrypting the IPsec packet when a large PDU was sent over IPv6 from Strongswan.

Impact: The SBC is not decrypting the IPsec packet when a large PDU was sent from Strongswan IPSec endpoint.

Root Cause: The SBC SWe NP has a issue in last fragment data length processing w.r.t. This StrongSwan fragmented first and encrypted the next combination IPSec packets handling, which caused an ESP trailer offset being incorrect and resulted in call failures.

Steps to Replicate: Make large SIP PDU calls with the StrongSwan IPSec endpoint.

The code is modified to work for all combinations.

Workaround: Racoon/Navtel/SBC IPsec endpoints can be used if possible as a workaround.

Policy server transactions were failing while running a load (3xx redirection with light dip) with 75K Number Translation criteria.

Impact: The postgres db is utilizing more CPU when a dmpm translation is executed at the service layer and as a result, impacting the performance.

Root Cause: Using a dmpm rule, either the calling or the called number can be modified at the prerouter layer. The PES previously analyzed the called and calling number completely even though it was exclusive to the called number or the calling. During an analysis of the call, the  PES used to perform direct DB fetch operations and this caused the postgres process to use more CPU.

Steps to Replicate: Create a dmpm rule service to modify the calling number. And then perform performance testing. The postgres process will utilize more CPU.

The code is modified so that, the PES analyzes either only the called number or only the calling number based on the rule type.

Workaround: none.

A PES Process coredumps when deleting an adProfile entry.

Impact: The PES Process dumps core when the AD profile is deleted.

Root Cause: While synchronizing the data from remote domain controller, the PES fetches the AD profile once from the cache and uses the object for various decision making. So, if the AD profile is deleted, the object reference becomes NULL, and it dumps core.

Steps to Replicate: To create an AD profile, create its dependent profiles.

1. Create An AD Attribute Profile.
set profiles adAttributeMapProfile DEFAULT_AD_ATTRIBUTE_PROFILE adAttributeList adAttribute1 adAttributeName cn
set profiles adAttributeMapProfile DEFAULT_AD_ATTRIBUTE_PROFILE adAttributeList adAttribute2 adAttributeName displayName
commit

2. Create a domain controller profile
set global servers domainController dc0 userName DcUsername password DcPassword primaryAddress DcIpAddress searchScope base=engineering,dc=some,dc=com ldapQueryCriteria cn=*
commit

3. Create an AD profile:

set profiles adProfile DEFAULT_AD_PROFILE delayedSync 2021-09-29T14:00:00 syncInterval 1440 sync enable adServerList 1 dcServer dc0
commit

After 1-2 minutes of creating the AD profile, delete it.

The code is modified so the AD profile is not deleted. If, for some reason, the synchronization needs to be stopped, the sync opotion can be disabled on the AD profile. 

Workaround: If the AD profile is no more required, do not delete the AD Profile but disable the sync option on it. It will stop all the future auto sync operations.

SBX-107111: Configured the DM/PM Rule not getting executed when the system is loaded with 75,000 number Translation criteria.

Impact: When there are more than 3,000 number translation criteria (NTC) objects are created, the PES cache goes for rebuild of the entire cache. The cache rebuild was not caching the NTC objects correctly.

Root Cause: During a rebuild of the NTC cache, a static variable was not reinitialized to zero. Since the static variable was not initialized to zero during a cache rebuild, it was using the last modified value, and this was causing the cache to not rebuild with the all the NTC objects.

Steps to Replicate: Create more than 3,000 NTC objects and make a call to match the NTC key. It will fail to find a match in the cache.

The code is modified to initialize the static variable to zero, when a fresh cache rebuild is triggered.

Workaround: None.

The SBC is sending an unexpected INVITE towards the UAS.

Impact: In an SBX-GW-GW-SBX call flow (as described in the test setup), the SBC was sending unexpected re-INVITE to the network. The re-INVITE was internally generated in order to handle the change in SDP parameters triggered by the SMM rules.

Root Cause: This was a side effect of for a previous fix in the 9.2.1 release.

Steps to Replicate: 

1. Create a GW-GW set up.
2. From UAS send 183 with a=sendonly along with image and text lines with sendrecv.
3. SBC sends 183 with audio line as a=sendonly (That is removed by the SMM).
4. Send a 180 from the UAS that the SBC sends to UAC.
5. Send a 200 from UAS without the sdp.
6. The SBC sends a re-INVITE to ingress with audio m line sendonly along with image and text port as 0 (SMM changes the audio line to sendrecv).
7. The SBC gets 200 for re-INVITE from UAC with audio line sendrecv.

After step 7, we should not see a re-INVITE towards the UAS.

The code is modified to take care of the case when holding a re-INVITE is actually received from a network or if it was locally generated. Only in a case where it was from network, we propagate the re-INVITE to the other end.

Workaround: None.

An unexpected 504 response was received, after a crankback to "500".

Impact: When the SIP trunk group control UseNonDefaultCauseCodeForARSBlacklist is enabled and the outgoing message cannot be sent due to address unreachable status, the crankback to the next end point was not occurring.

Root Cause: The code was incorrectly updated during 9.2.2 to try and map from SIP to CPC using internal 7xx status codes which are generated by the stack for events such as timeouts. This lead to the disconnect reason code being mapped to 0 that did not exist in the crankback profile instead of 168 which was expected. So the crankback did not occur and the call was released with 504.

Steps to Replicate: 

1. Run a test case with multiple trunk groups.
2. Send in a subscribe message that is routed through the SBC and respond back with 500.

The message should be attempted to the next end point, but if that end point is blocklisted due to pathcheck configuration the message should be sent to the next again end point.

The code is modified to only consider the standard SIP status codes when trying to map from SIP to the CPC so that the correct disconnect reason code of 168 is used to trigger a crankback.

Workaround: None.

The SCM process crash was observed when trying to show the ARS blocklisted entries.

Impact: When too many peers are in ARS blocklisted table(more than 90 entries) and the "show status addressContext default zone <ZONE_NAME> sipArsStatus" command was issued, the SCM process crashed.

Root Cause: The code was incorrectly indexing to a negative location in an array that led to an invalid memory access and a coredump.

Steps to Replicate: Block list multiple peers and then run the status command. This was only seen once in lab testing.

The code is modified to avoid accessing the negative array location to avoid the coredump.

Workaround: None.

EMA CDR Viewer: SIP Ladder diagram tool presenting incomplete packets

The SBC CDR Viewer is enhanced to overcome SIP Ladder diagram size limitations to ensure large messages display. 

Impact: Incomplete packets display in the SIP Ladder diagram tool because the EMA did not know to append the next block to the previous PDU in the tool, and dropped the secondary packet block.

Root Cause: Due to size limitations, large packets are getting split into two blocks, causing the second block to get prepended with information about the filter when it is written to the TRC log.

Steps to Replicate: Use call trace filter to capture some large messages i.e. more than 2K in size and check that they are displayed correctly in the SIP ladder diagram.

The code is modified to ensure large messages display in the SIP Ladder diagram.

Workaround: None.

The SBC is enhanced with a configurable parameter to indicate a legacy meshed network exists on the GW-GW links.  This will ensure the MAX_ICM value used to pack a message to send to older GSXs is the same size.

Impact: A call sent from an SBC running software between 9.1.0 and 9.2.2R4 to any GSX (without the fix GSX-61814) may cause the GSX to core. The max buffer to send to the GSX was changed from 15K bytes to 10K bytes.

Root Cause: PDUs sent from the originating SBC to the destination GSX in a GW-GW network are bigger than the buffer on the remote GSX.

When the destination GW is a GSX, the PDU may be larger than the buffer allocated on the GSX. When the GSX encounters oversized PDUs, it overwrites the allocated buffer, causing memory corruption and ultimately a coredump may occur.

Steps to Replicate: 

Send an SBC-GW-GW-GSX call involving text (T140) streams. The GSX may crash. 

To test the fix: 

1. Load the new code.
2. Enable the oldGsxSupport flag:
   set global signaling oldGsxSupport enable
   
3. Send an SBC-GW-GW-GSX call involving text (T140) streams (this is just one way to send a large PDU).

The GSX should not crash.

The code is modified to add a new global signaling parameter that you must enable if there are any GSXs in the network without the fix for GSX-61814.

set global signaling oldGsxSupport <disable | enable>

When this parameter is enabled, the SBC reduces the maximum size of the PDUs that can be sent over a GW-GW connection to GSXs to prevent sending a PDU larger than the buffer size allocated on the GSX, which can cause memory corruption. Once the GSX has fix for GSX-61814, it will send its maximum buffer size supported in the GW OPEN ACK (at which time you can disable this flag).  

Any SBC running 9.1 or higher software supports this new AVP, and subsequently knows what to send to another SBC over the GW link.   Calls will fail before getting cleared by the GSX with a 503,  and will now fail on the ingress side with a 500 and advance to the next route.

Workaround: There is no known workaround for this issue.

PortFix SBX-107747: During Cyclic switchover tests, a PRS Process coredump was observed on the MSBC1.

Impact: The application on both active and standby switched over and application reset in short order of each other. Core files were created on both sides of the HA pair.

Root Cause: The issue occurs during multiparty call processing, when the SBC tries to determine whether a message was destined for an ingress or egress call segment. As a result of running multiparty call processing, the code was accessing the pointer to the multi party call resource after it was freed up and set to NULL.

Steps to Replicate: This issue is not reproducible. Potentially due to a race condition in the code.

Check the multi party call pointer is not NULL before reading from it to avoid the coredump.

Workaround: There is no known workaround for this issue.

PortFix SBX-112561: The regexp string "\r\n" was not exported by “user-config-export”.

Impact: The \r\n in regex is lost while exporting a configuration using the user-config-export CLI command.

Root Cause: XML formatting trims empty node values.

Steps to Replicate:

1. Create an SMM Profile using the following commands:
   set profiles signaling sipAdaptorProfile ESMM state disabled
   set profiles signaling sipAdaptorProfile ESMM advancedSMM disabled
   set profiles signaling sipAdaptorProfile ESMM profileType messageManipulation
   set profiles signaling sipAdaptorProfile ESMM rule 1 applyMatchHeader one
   set profiles signaling sipAdaptorProfile ESMM rule 1 criterion 1 type message
   set profiles signaling sipAdaptorProfile ESMM rule 1 criterion 1 message
   set profiles signaling sipAdaptorProfile ESMM rule 1 criterion 1 message messageTypes requestAll
   set profiles signaling sipAdaptorProfile ESMM rule 1 criterion 2 type header
   set profiles signaling sipAdaptorProfile ESMM rule 1 criterion 2 header
   set profiles signaling sipAdaptorProfile ESMM rule 1 criterion 2 header name WWW-Authenticate
   set profiles signaling sipAdaptorProfile ESMM rule 1 criterion 2 header condition exist
   set profiles signaling sipAdaptorProfile ESMM rule 1 criterion 2 header numberOfInstances number 1
   set profiles signaling sipAdaptorProfile ESMM rule 1 criterion 2 header numberOfInstances qualifier equal
   set profiles signaling sipAdaptorProfile ESMM rule 1 criterion 3 type parameter
   set profiles signaling sipAdaptorProfile ESMM rule 1 criterion 3 parameter
   set profiles signaling sipAdaptorProfile ESMM rule 1 criterion 3 parameter condition exist
   set profiles signaling sipAdaptorProfile ESMM rule 1 criterion 3 parameter paramType generic
   set profiles signaling sipAdaptorProfile ESMM rule 1 criterion 3 parameter name realm
   set profiles signaling sipAdaptorProfile ESMM rule 1 action 1 type header
   set profiles signaling sipAdaptorProfile ESMM rule 1 action 1 operation regsub
   set profiles signaling sipAdaptorProfile ESMM rule 1 action 1 headerInfo headerValue
   set profiles signaling sipAdaptorProfile ESMM rule 1 action 1 from
   set profiles signaling sipAdaptorProfile ESMM rule 1 action 1 from type value
   set profiles signaling sipAdaptorProfile ESMM rule 1 action 1 from value 172.12.34.567
   set profiles signaling sipAdaptorProfile ESMM rule 1 action 1 to
   set profiles signaling sipAdaptorProfile ESMM rule 1 action 1 to type header
   set profiles signaling sipAdaptorProfile ESMM rule 1 action 1 to value WWW-Authenticate
   set profiles signaling sipAdaptorProfile ESMM rule 1 action 1 regexp
   set profiles signaling sipAdaptorProfile ESMM rule 1 action 1 regexp string "\r\n"
   set profiles signaling sipAdaptorProfile ESMM rule 1 action 1 regexp matchInstance all
   commit
2. Run the CLI command to the export configuration:
   user-config-export test.xml /profiles/signaling/sipAdaptorProfile
3. Delete the exported profile from CLI with the command:
   delete profiles signaling sipAdaptorProfile ESMM
   commit
   user-config-import test.xml
4. Run the following command:
   show configuration profiles signaling sipAdaptorProfile | display set | match string
5. Check if the regex string field, restores the original value.

Use the external XML tool called xmllint. 

Workaround: Manually edit the field in xml file after export.

Details on "LAST RESTART REASON" under command "show table system serverStatus" are incorrect.

Impact: The LAST RESTART REASON is not updated with a correct reason of last restart.

Root Cause: Reading LAST TESTART REASON function is called twice and in second call, it is set to default.

Steps to Replicate: Check the LAST RESTART REASON from CLI show table system serverStatus
and call a different type of restart and verify LAST RESTART REASON set properly or not.

The code is modified to set the reading LAST TESTART REASON function to call only once.

Workaround: None.

PortFix SBX-111349: The SBC 7000 has a dual crash within 1 minute (old Active side - Fm, new Active - Scm).

Impact: The application on both active and standby are switched over and application reset in short order of each other. Core files are created on both sides of the HA pair.

Root Cause: Accessing a NULL pointer that leads to a coredump.

Steps to Replicate: Test switchover scenarios to replicate the issue.

The code is modified to address the issue. 
The ccbPtr->ccMultiCallMsgStrPtr is checked for not being NULL.

Workaround: None.

The VNFM response is timing out due to the timeout value length.

Impact: By default the VNFR logic had a 5-second timeout to get responses from VNFM for the REST requests that it sent, but it has been observed that in certain networks this timeout value is not enough. This lead to the VNFR timing out while the VNFM was still trying to send back a response and the VNFR never reported ready state in the VNFM.

Root Cause: A 5-second delay was originally considered adequate, but after taking multiple networks into account, the delay proved to be insufficient.

Steps to Replicate: Try a relocation operation with VNFM across multiple sites and ensure the VNFR status returns to ready.

The code is modified so the timeout is increased to 20 seconds.

Workaround: None.

PortFix SBX-112493: The SBC is not decrypting IPsec packet when large PDU sent over IPv6 from Strongswan.

Impact: The SBC is not decrypting IPsec packet when large PDU sent from Strongswan IPsec endpoint.

Root Cause: The SBC SWe NP has an issue in the last fragment data length processing. This StrongSwan was fragmented first and encrypted the next combination IPsec packets handling, which caused ESP trailer offset being wrong and call failures.

Steps to Replicate: Make large SIP PDU calls with the StrongSwan IPSec endpoint.

The code is modified on the last segment length to work for all combinations.

Workaround: The customer and the SBC IPsec endpoints can be used if possible.

PortFix SBX-112153: An investigation found commits are not saved/activated on many SBCs.

Impact: Warnings displayed about inactive configurations on the managed VM.

Root Cause: The managed VM was checking the status on the OAM shared drive and reporting the inactive configuration warnings.

Steps to Replicate: Test on OAM and manage the VM.

The code is modified to only display the warning on OAM nodes.

Workaround: None.

There is a Wall LRA ISBC switchover after the applying ACLs.

Impact: Configuring certain combination of ACLs may exceed the hugepage requirement than available in the system. This will cause the ACL configuration to fail and SWe_NP to exit.

Root Cause: The code did not account for available hugepages during an ACL configuration.

Steps to Replicate: Bring up setup in ISBC profile. Apply the ACL configuration used by customer.

The code is modified to limit the hugepage memory use during an ACL build and ensure it is within the allocated limit.

Workaround: Use more than 64G RAM.

The Active Register per TG shows more than the total stable registration.

Impact: Under some condition(s), the ingress zone’s activeRegs count can be incremented and not decremented when the registration terminates.

The causes the ingress zone’s activeRegs count to grow incorrectly, and never reach ZERO (even after all registrations are terminated).

Root Cause: The SIPFE and SIPSG RCB allocation/deallocation become out of sync, indirectly causing the ingress zone's activeRegs count to increment and not decrement.

Steps to Replicate: Perform REGISTER/401 - REGISTER/403 until the ingress zone activeRegs count issue is detected.

The code is modified to correctly handle the SIPFE's registration bind timer expiration. 

Workaround: None.

PortFix SBX-111688: The Request-URI and TO fields in a SIP INVITE are incorrect and overwritten.

Impact: When the Diversion header presented in an Ingress INVITE and had no RN in Request-URI, the egress RURI would use the RN in username field, after a PSX LNP dip.

Root Cause: The fix for a previous issue broke the previous RURI username setting.

Steps to Replicate: 

1. Set up the SBC with an external PSX to make LNP calls.
2. Pay attention to the disableRn flag in egress IPSP in PSX and flag UseGAPwhenRnisDisabled in the SBC's egress TG. Test different combination of < disableRn, UseGAPwhenRnisDisabled >
3. Ingress INVITE needs to contain Diversion header and no RN in the Request-URI.

Sample message could be found in the reproduced DBG logs and finalFix DBG logs.

The code is modified to ensure the RURI always contains the correct username.

Note: When the egress IPSP has "SIP TO Header Mapping" set to "Called Number", the TO header's username is the ingress TO URI. The number will not be globalized. If the customer would like it to be globalized, the globalization profile of the egress TG could be modified to globalize TO URI. Another way is using SMM to modify it.

Workaround: Use the SMM and use the Warning-21-00029918

Portfix SBX-111223: Memory leak since upgrading to 8.2.5R0.

Impact: High memory utilization.

Root Cause: Two leaks of the same structure exist:

1. A memory leak is seen when a relayed SUSCRIBE message is cranked back and an Alternate Server cannot be found.
2. The code that handles relayed messages may cause a leak in certain error scenarios.

Warning-21-00029922 pertains to this issue.

Steps to Replicate: This is a memory leak that may be triggered if a relayed SUBSCRIBE is cranked back and then an alternate route is not found.

1. This memory leak that may get triggered if a relayed SUBSCRIBE is cranked back and then an Alternate Server is not found.
2. We were unable to reproduce this error scenario which causes a leak of the Relay Control Block.

1. The code is modified to take the correct path when an Alternate Server cannot be found while handling a relayed message that has been cranked back.
2. Code has been added to start a timer when we begin processing a relayed messsage. In error cases, the Relay Control Block will be free when the timer expires - preventing the structure from leaking.

Workaround: None.

Once the memory utilization reaches 91%, an automatic switchover occurs. To avoid an automatic switchover, Ribbon recommends performing a manual switchover during a low traffic period. 

An LSWU on SWe (VMware/KVM) through the Platform Manager fails with the additional reboot of the standby.

Impact: An LSWU from 09.02.02R001 to any higher release 1:1 HA SWe (KVM/VMware) through the Platform manager fails because the standby instance undergoes an additional reboot during the upgrade procedure.

Root Cause: The Index Marker file was missing on the standby instance prior to the LSWU procedure.

The Index Marker file was missing on the standby instance due to when the application comes up with the standby role, the Index Marker is created only when there is a mismatch in the calculated and DB populated indices.

Steps to Replicate: 

1. Create 1:1 HA SWe on KVM/VMware.
2. After the HA application comes in sync, run clearDB on the standby.
3. Perform an LSWU on the 1:1 HA SWe.

The code is modified so the Index Marker file is created on the standby instance irrespective of processor index mismatch in the calculated and DB populated indices.

Workaround: Before initiating the upgrade procedure (from PM or CLI), the user needs to run the following command as a root user from the linux shell of the active and standby instance.

touch /opt/sonus/conf/swe/capacityEstimates/.indexMarker

The term-ioi is not be set in the STOP record for a customer call flow.

Impact: When running a JJ90.30 to JJ90.30 call flow, the term-ioi value from the PCV header is not being stored in the ingress protocol variant string when the transitPCV control in the JJ90.30 interworking profile is enabled.

Root Cause: The original development work was only storing the term-ioi value in the egress protocol variant string.

Steps to Replicate: 

Make JJ90.30 to JJ90.30 call.
transitPcv is set to enabled in the customer's Interworking Profile.

Call 1:

INVITE --> (PCV with icid-value and orig-ioi)
<--- 180 (PCV with icid-value, orig-ioi, term-ioi)
<-- 200 OK (PCV with icid-value, orig-ioi, term-ioi)
--> BYE

Call 2:

INVITE --> (PCV with icid-value and orig-ioi)
<--- 180 (PCV with icid-value, orig-ioi, term-ioi)
<-- 200 OK (PCV with icid-value, orig-ioi, term-ioi)
<-- BYE

After a call, verify the CDR records. In both START and STOP records, the term-ioi is filled in ingress PVSD.

The code is modified to ensure the term-ioi value is stored in the ingress protocol variant string.

Workaround: None.

PortFix SBX-112381: The SBC had a Crash-Application in the rebooting loop.

Impact: A PRS Process core is occurring when the code is processing an ICE STUN packet and there are more than 20 Teams clients ringing. This could potentially happen in a simultaneous call group pickup scenario.

Root Cause: The root cause of the core is a bug in the code that handles the incoming STUN packet. This code is overwriting the end of array by writing too many entries into the array. This results in memory corruption and eventually a core.

Steps to Replicate: Run a call group pickup scenario with more than 20 users all having their Teams clients ringing at the same time.

The code is modified to prevent it from writing too many entries into the array.

Workaround: Disable media-bypass or reduce the number of users in the call group.

The SCM Process is coredumping.

Impact: The SBC is relaying multiple reason header instances in the amount of the quantity squared.

Root Cause: Logical error when multiple instances of a reason header on the same line. The SBC is relaying in the amount of quantity squared. 

Steps to Replicate: 

1. Configure the transparency Reason header.
2. Make a SIP-SIP call, Ingress sends BYE with multiples Reason header instances on the same line. The SBC sends instances in an amount of the quantity squared to the Reason header on Egress.

Note: If the ingress sends a large number of instances on the same line.

• For old (pre 8xx), the SBC may core.
• For 8xx and above, the SBC may be unable to send BYE on Egress.

The code is modified to address the issue.

Workaround: Disable the transparency of a reason header.

A restore on revision 1 failed in the standby OAM node.

Impact: A restore on revision 1 failed on the standby intermittently.

Root Cause: When the restore revision is requested, both OAM nodes restart. In a corner case, there is possibility of both starting as active and later one of the nodes will go down and not come up as standby.

Steps to Replicate: 

1. Create a scenario with 1:1 OAM for the SSBC/MSBC/MRFP.
2. In automation, keep the cleanStart as 1 so that the automation will trigger restore revision 1.

Both OAM should come up.

The code is modified to handle the corner case.

Workaround: Manually reboot the standby.

Uploaded onfig backup file is not available at gconfig.

Impact: The uploaded config backup file is not available on the gconfig.

Root Cause: The uploaded file was not moved in the config directory because the system name was not correct.

Steps to Replicate: 

1. Log in to the EMA.
2. Go to Administration -> System Administration -> File Upload.
3. Upload the file.

The code is modified to read the correct system name.

Workaround: None.

The SFTP transfer is not working to CDR server that only supports AES128_CTR.

Impact: One customer has a CDR server that offers AES128_CTR for the server-to-client encryption. When the SBC offers AES256_CTR as the preferred option, the SBC encodes the packets with AES256_CTR, and receives the packets with AES128_CTR encryption. This scenario causes a decoding issue on the SBC that results in the termination of the connection.

Root Cause: An invalid encrypted data length is received from the CDR server.

Steps to Replicate: 

1. Rollover the accounting file.
2. Verify that the CDR transfer is successful.

The code is modified to offer up the AES128_CTR as the preferred encryption option, so both sides are using AES128_CTR.

Workaround: Disable the AES256 on the CDR server.

PortFix SBX-112267: The correct 92x serialization results in test failures.

Impact: When the registration control block is made redundant and the active/standby instances are running different software releases, the redundancy logic might not work correctly if the registration control block contains P-Charging-Vector (PCV) and/or P-Charging-Function-Addresses (PCFA) information. The redundancy logic will work correctly post upgrade when the serialization of the redundancy data is not required.

Root Cause: The parameter lengths of the PCV and PCFA redundant parameters was not calculated correctly. This can lead to the redundancy code being unable to process all the redundancy information correctly.

Steps to Replicate: Run registration related tests with PCV and PCFA header parameters in an older release and then upgrade to 922R2 or later.

The code is modified to correctly set the length of these parameters to avoid problems with redundancy.

Workaround: None.

PortFix SBX-111659: The intercept is not working when P-Com.Session-Info is received in INVITE and tones are enabled.

Impact: When the lawful intercept target is specified in the P-com-session-info header of the INVITE message, the intercept does not occur if an announcement resource is applied to the call and then freed up. There is no issue if the P-com-session-info header is received in the backward direction.

Root Cause: This occurs when using P-early-media with tone profile and media monitoring profile applied to the call flow and the B-party sends P-early-media with a=inactive to start the media monitoring and does not provide RTP or does not send 200 OK prior to the monitoring timer expiring which results in the SBC playing RBT via an announcement resource. When the media path is later cut through and the announcement resource is released the intercept information was mistakenly freed up and the intercept did not occur.

Steps to Replicate: 

1. Run a lawful intercept call flow using P-com-session-info header in the INVITE to indicate the target intercept point. The call should be configured with P-Early-Media, tone profile and monitoring profile to check for RTP packets received.
2. In response to the egress INVITE, send back an P-early-media header with a=inactive and no RTP packets prior to the monitoring timer expiring so the SBC plays RBT.
3. Answer the call and check that media is being sent to the intercept server.
   

The code is modified to ensure the intercept information is not freed up when freeing the announcement resource.

Workaround: None.

The LI connection to media server was not connected on a switchover.

Impact: When using the PCSILI (P-com-session-info flavour of LI) in an N:1 M-SBC setup and running the SBC release 8.2 or later if there is a switchover, the connection to the LI server might not be re-established.

Root Cause: The standby instance was trying to maintain information about the operational status of the interface used for LI processing. But this was only happening correctly for the first instance. The status of the other instances was being misinterpreted and lost. So during the transition to active, the LI code thought the interface was not available and did not try to establish the connection to the LI server.

Steps to Replicate: In an N:1 setup perform switchovers from each active instance to the standby and check that the connection to the LI server is restored.

The code is modified to collect the status of the interface after the instance transitions from standby to active so that the accurate interface information is available for LI processing.

Workaround: Bounce the interface e.g. ifup/ifdown that is used for LI connection would help to recover the connection.

PortFix SBX-108317: The SBC switchover and isolation of node/SVWSBCD.

Impact: The PRS core was truncated because a second ABRT was sent to the process.

Root Cause: The PRS core was truncated because a second ABRT was sent to the process while it was in the process of writing the core.

Steps to Replicate: This issue is not reproducible.

The code is modified to prevent two ABRT signals from being sent to the same process.

Workaround: There is no workaround.

PortFix SBX-111050: There was a coredump during a reboot on a customer SBC. 

Impact: A misconfiguration of GW Signaling Ports, in which there is a Secondary GW Signaling Port configured but no Primary GW Sig Port configured, and can lead to a core and switchover.

Root Cause: When there is no Primary GW Signaling Port configured but there is a Secondary Signaling Port configured, we enter a code path that attempts to dereference a NULL pointer (pointer to Primary Sig Port) when it is attempting to get the dscp value to use for the socket.

Steps to Replicate: An SVT engineer should:

1. Configure an SBC with a Secondary GW Signaling Port without configuring a Primary GW Signaling Port.
   i.e. gwSigPort of SBC1 should be in primary mode and SBC2 should be in secondary mode

2. Send a GW-GW call from a remote GW through this SBC using the address of the Secondary GW Signaling Port on an SBC.

   Without the fix, this should cause a core.
   With the fix, there should be no issue.

The code is modified to prevent it from attempting to dereference a NULL pointer (pointer to Primary Sig Port) when it is looking up the dscp value to use for the socket.

Workaround: The workaround is to avoid configuring a Secondary GW Signaling Port without configuring a Primary GW Signaling Port.

PortFix SBX-110199: There was dbg log flooding with MAJOR .VNFR: *(VAgent) message

Impact: Event Logs are flooded with error message, when one of the OAM node or Managed VM goes down.

Log Message:.MAJOR .VNFR: *(VAgent): send error. rc=-1, error=Resource temporarily unavailable

Root Cause: The health check message send fails, when an instance is down.

Steps to Replicate: Run an LSWU from VNFM on an ISBC SWE instance in 1 to 1 HA mode.

The code is modified so the messages are only logged on the first error in health check. It is reset, when a message send succeeds.

Workaround: The error message stops automatically once the node is recovered and starts to respond to the health check messages.

PortFix SBX-110884: The logs are getting printed in openclovis.

Impact: If condition present, SCM is filling openclovis logs with this error message:
nprintf buffer too small. Need 306 Have 300 File: /sonus/p4/ws/release/sbx5000_V08.02.02R001/marlin/SIPSG/sipsgRegAgent.c Line: 2527

Root Cause: The error message is being logged because the code is attempting to write a debug log into a local buffer that is not big enough.

Steps to Replicate: No testing is required. This is no risk with/without fix.

The code is modified to increase the size of the local buffer.

Workaround: There is no workaround.

PortFix SBX-109243: The SBC sending 481 for CANCEL in dialog transparency.

Impact: When the dialog transparency is enabled and call loops back to the SBC, the SBC does not handle a CANCEL sent from ingress endpoint.

Root Cause: The SBC expects a CANCEL to have callinfo header.

Steps to Replicate: 

1. Reproduce the issue.
   Dialog Transparency is enabled and the Call Loops back In.
   After adding PRACK, Ingress sends CANCEL without callinfo header.
   The SBC sends a 481.
2. With a fix, the SBC sends 200OK for CANCEL and relays to egress leg.

The code is modified to ensure the SBC finds the correct SG to handle the CANCEL even when the CANCEL does not have callinfo

Workaround: None.

Host check validation failing - Required GB RAM 6 but found 0.03125.

Impact: The few host machines in the AWS data center use different units for RAM, HostCheck script assumes that available memory is given in MB. The HostCheck script is fixed to calculate available memory based on unit of memory.

Root Cause: The HostCheck script does not have code to consider memory unit.

Steps to Replicate: Create VM with >=32 GB RAM, application should come up without complaining about memory in VM.

The code is modified to calculate available resources based on units.

Workaround: Create instance/VM that has < 32 GB RAM.

Portfix SBX-107133: Max FD limit is reached in SLB beyond 7,04,000 TLS connections (Access Registrations) tried.

Impact: Max FD limit is reached in the SLB beyond 7,04,000 TLS connections (Access Registrations) tried.

Root Cause: Observing the FD congestion at high load due to FD limits reached.

Steps to Replicate: Check the updated FD limits in /etc/security/limits.conf.

The code is modified for the max FD for the KVM and SLB.

Workaround: None.

The SBC is forming invalid packet where it is adding 00 in around all headers and parameters.

Impact: The SBC puts a NULL termination in every parameter and header of the message. In this case, there was a parser error on a parameter when the DNS translation was required.

Root Cause: During the parsing of the message after a DNS query, if a parser error occurs, then incorrect termination is put/left in the message when sent on the wire.

Steps to Replicate: 

1. An incoming INVITE had a known syntax error related to alert_info, configuration was to parse through the filterProfile and not transparently forward alert_info. This resulted in parse error and bad formatting when DNS was executed.
2. Configure the alertInfo to transparently pass on egress, and DNS function doing fqd/IP swap executes correctly and egress message is sent with good formatting.

The code is modified to:

1. Log parse an error line number and pdu message.
2. Apply the filterProfile when parsing the message. The customer needed to add filterProfile to transparently forward the parameter failing parsing on egress to avoid parse error and avoid incorrect parameter termination.

Workaround: On the Ingress, apply an SMM to rename alert_info to an unknown (x-alert_info), and rename back on the egress.

The file upload is not working in the Platform Manager.

Impact: The file upload is not working in the PM.

Root Cause: The request URL length was too high as per-server configuration because that requested call was failed.

Steps to Replicate: 

1. Log in to the Platform Manager.
2. Go to Administration -> System Administration -> File Upload.
3. Upload a file and save it.

The code is modified to make a request call successful.

Workaround: We can apply the same changes in a customer setup also and restart the apache server.

Getting badRidCb errors during LSWU from 7.2.4R0 to 9.2.2A003

Impact: An upgrade from an older version to 9.2.0R0 and newer, the NP reported badRidCb error continuously: MAJOR .IPM: *NP 0 error counter badRidCb incremented: cnt 2310 last error 0x10002.

Root Cause: In version 9.2.0R0, Ribbon Protect streaming support was added. During an LSWU, new fields related to Ribbon Protect streaming were all initialized to zero in internal data structures, including the rbbnType. But in NP, rbbnType = 0 triggered NP to send RTCP_APP related statistics to Protect server, which caused the errors.

Steps to Replicate: Run an LSWU from any older version to 9.2.2 with call loads.

The code is modified to initialize the rbbnType to 'BRM_RBBN_PROTECT_STREAM_DISABLE' so that NP does not generate RTCP_APP to Protect server.

Workaround: No workaround.

PortFix SBX-111211 to 9.2.x - Get "violates foreign key constraint" error when assigning timeRangeProfile to a Route in EMA

Impact: Route creation fails when the name of time range profile contains numerals.

Root Cause: During the route creation, validation of time range profile was failing as it was containing numerals.

Steps to Replicate: 

1. Create a time range profile with a name containing number ex test_1
2. Create a route with test_1 as time range profile.
3. Route creation should be successful.

The code is modified to consider numerals as valid a character.

Workaround: Create a Route from the CLI.

PortFix SBX-108616: Fora  Late Media Call, the SBC is not sending a second UPDATE towards ingress when the DLRBT is enabled.

Impact: In a late media convert call scenario, when the DLRBT is enabled, the SBC is not sending UPDATE towards the ingress with the list of codecs received from UAS.

Root Cause: The minimizing of media changes from other call leg functionality is suppressing the triggering of the UPDATE towards UAC.

Steps to Replicate: 

1. The UAC sends INV without SDP to the SBC.
2. The SBC sends INV with PCMA PCMU G729 101.
3. The UAS sends 180 with PCMA G729.
4. The SBC sends 180 with PCMA G729.
5. The UAC sends PRACK with G729.
6. The SBC starts playing tone with G729 towards ingress EP.
7. The UAS sends 200 OK (for INV) without SDP.

The code is modified to identify this particular call scenario, such that, the SBC sends an UPDATE towards the UAC if the tone codec is different from the end to end negotiated codec.

Workaround: None.

Portfix SBX-111502: Metavar exchange continues even after the allocation is failed in the SBC.

Impact: The CHM processes the metavar request/response messages even when the application is going down, which results in failure messages.

Root Cause: The CHM does not check if the application is going down while processing the messages from the other nodes.

Steps to Replicate: Bring up the SBC in N:1 mode and then shutdown the application on one of the nodes while another node is starting the metavar exchange in CHM activation.

The code is modified to ensure that application is not going down before processing the metavar messages from other nodes.

Workaround: None.

Portfix SBX-111469: There are some problem causing MRFPs cannot recover from a restart

Impact: The standby SBC gets the already allocated metavars of an active node while coming up in an 'active' role.

Root Cause: The standby SBC is not checking for the condition to see if its the only node running in the redundancy group before allocating the last exchanged metavars of active node.

Steps to Replicate: Bring up the N:1, trigger a switchover so that assigned standby becomes active and while assigned active node is coming up in 'standby' role. Restart assigned standby and ensure the proper metavars are allocated to assigned standby node while its coming up in 'active' role.

The code is modified to check for the already allocated metavars before allocating the metavars to self node while coming up in the 'active' role.

Workaround: Restart assigned standby node if already allocated metavars are allotted to this node.

Portfix SBX-111310: Standby OAM is rebooting after orchestration.

Impact: The Standby OAM is restarting after a launch.

Root Cause: The Standby OAM is sending the serf event for 'startingStandby' with an older timestamp (which is fetched even before standby OAM is ready to come up) that results in discarding of the serf event by the active OAM node as its prior to member-join event for standby OAM node.

Steps to Replicate: Bring up both the active and standby OAM at the same time and then while standby OAM is coming up, disconnect and connect the HA port on active OAM to trigger member-failed and member-join events.

While sending the 'startingStandby' serf event, get the current timestamp so that its not discarded by the active OAM node.

Workaround: Restart the standby OAM application so that the startingStandby event is generated again with a current timestamp.

PortFix SBX-109811: The SBC uses port number RTP+1 for RTCP instead of the learned RTCP port number if the RTCP NAT learning completes before RTP NAT learning.

Impact: The SBC sends the RTCP packets to a destination port number RTP+1 for the RTCP instead of the learned RTCP port number if the RTCP NAT learning completes before RTP NAT learning.

Root Cause: The SBC overwrites the learned RTCP port number with the RTP+1 port number if the RTCP is learned before RTP.

Steps to Replicate: Send RTCP packets first then RTP packets to the SBC. After call is connected, verify the RTCP port number, if RTCP is learned before RTP.

The code is modified to use correct RTCP learned port when RTCP learning occurs before RTP, instead of comparing the RTP and RTCP addresses from callLeg structure.

Workaround: No workaround.

PortFix SBX-89177: A call is torn down upon a Hold (OA expiry).

Impact: A call flow involving an early media, tone and late Crankback results in a call tear down by the SBC while processing the HOLD INVITE.

Root Cause: While processing a 200 OK for INVITE, one of the call processing module ends up setting wrong App-Context-Id as active. Later, while processing a HOLD INVITE, this causes a failure since this module is not working on the latest App-Context-Id.

Steps to Replicate: Call Scenario:

1. Party A calls Party B through the SBC.
2. Party B sends 183 with SDP resulting in media cut-through at the SBC.
3. Later B sends 480.
4. The SBC is configured for the Crankback and as a result sends INVITE to Party C.
5. Party C sends 183 with SDP.
6. Party C sends 180 without SDP resulting in tone.
7. Party C sends 2xx with SDP for INVITE.
8. Party C sends HOLD INVITE.

Expected behavior: The SBC successfully process the HOLD INVITE.

Actual Behavior (without a fix): The SBC tears down the call while processing HOLD INVITE.

The code is modified to have the correct app Context Id as active while processing 200 OK for INVITE.

Workaround: Disable the Tones at the SBC.

PortFix SBX-110948: Load configuration overwrites the local processor index values.

Impact: When we perform a load config operation on a 1:1 HA pair (SWe/Cloud), it ends up overwriting the local processor index estimates with the ones that are present in the config dump.

This leads to two issues:

1. An incorrect index estimates being populated in the DB.
2. There are discrepancy in estimations between active and standby instances.

Root Cause: The load config operation results in overriding the local processor index estimates with the ones that are present in the config dump. This results in standby consuming incorrect indices present in the DB thereby causing the discrepancy in estimates of the active and standby instances.

The DB should always reflect the estimated processor indices calculated by the active instance in 1:1 HA pair.

Steps to Replicate: On 1:1 HA SWe/Cloud instances, perform the following steps:

1. Run the following command as root user on the active and standby instances. The following command should give same output on the active and standby instances.
   cat /opt/sonus/conf/swe/capacityEstimates/.index.txt
2. Perform the load config operation.
3. Run the following command as root user on the active and standby instances. The following command will give different output on the active and standby instances.
   cat /opt/sonus/conf/swe/capacityEstimates/.index.txt
   
   With the fix, this issue will not be observed.

The code is modified to ensure that the DB reflects the estimated processor indices calculated by the active instance in 1:1 HA pair.

If the processor indices values stored in the DB does not match with the indices calculated by the standby, then the standby goes for a reboot. From the next boot on-wards, the standby uses the indices stored in the DB for the session estimations.

The previously mentioned procedure ensures that the indices and sessions estimates are same on the active and standby instances.

Workaround: Run the following commands as root user on the active and standby instances.

1. The rm -f /opt/sonus/conf/swe/capacityEstimates/.indexMarker
2. Run a reboot

The SBC VNF cannot get to Ready after a VNFM Migration.

Impact: The VNF does not get ready after a migration to the new VNFM.

Root Cause: When the new VNFM is trying to send the curl request to the VNF, the request is getting rejected. When the VNF gets deployed, it contains the VNFM data in its user data and it makes one VNFM IPs allowed list. This allowed list is not getting updated for the new VNFMs. So, when VNF migrates to the new VNFM, new VNFM IP is not present in the allowed list.

Steps to Replicate: 

1. Launch VNFM with https.
2. Deploy a VNF and scale out the VNFM. Migrate the VNF to the new VNFM.
3. The VNF state should be read and available.

The code is modified so whenever the new VNFM sends a request to VNF, it is accepted.

Workaround: 

1. 1. Reboot the setup.
2. 2. Add new VNFM IP in the /opt/sonus/conf/instanceLca.json before the application comes up.
3. 3. Check the state of the VNF on VNFM.

SBX-99253: Customer ECGI to CA Mapping Enhancement.

Impact: The SMM Switch operation is not working after an SBC reboot.

Root Cause: The switchIndex is not being set properly during a config restore.

Steps to Replicate: 

1. Configure SMM Rule consisting of switch operation.
2. Run the Call.
3. Perform an SBC reboot.
4. Run the call (SMM will not be executed).

The code is modified to set correct the SwitchIndex during a config restore.

Workaround: After a reboot, we can delete the SMM profile and configure again.

CDR Viewer Download all button not working

Impact: The CDR Viewer download all button was not working.

Root Cause: An issue was caused when we changed the CSP. Due to that change, the content was made more strict and blob type were not allowed in Firefox and IE, resulting in a download failure.

Steps to Replicate: 

1. Log in to the EMA.
2. Navigate to CDR Viewer.
3. Select the Sip Ladder and click Download All.
4. Download is successful in Firefox/IE/Chrome.

The code is modified to allow the same to further processing.

Workaround: No workaround.

PortFix SBX-110956: Introduced the Upsampler for EVS in a EVS(wb)<=> NB codec scenario.

Impact: The WB will not be used for EVS encoding and as a result, the channel aware mode cannot be enabled in an IDP NB scenario though negotiated through the SDP.

Root Cause: There is an absence of an Upsampler in the Upstream path for EVS when WB is negotiated in an IDP NB scenario.

Steps to Replicate: Run a EVS<=>G711 call with bw=wb; ch-aw-recv-5;br=5.9-13.2.

In this case, the EVS encoder produces WB packets with channel aware mode enabled.

The code is modified for the EVS when the WB is negotiated in an IDP NB scenario.

Workaround: None

PortFix SBX-109300: The SBC should not accept cmr byte from discarded packets.

Impact: The SBC was accepting the CMR from discarded packets.

Root Cause: The CMR was being processed before Packet Validation.

Steps to Replicate: Run and EVS<=>EVS call. Let the peer send 32Kbps packets having CMR for 24.4Kbps.

In this case, the 32Kbps packets are discarded as we do not support transcoding beyond 24.4Kbps for EVS. Also since the packets are discarded CMR for 24,4Kbps is also not honored.

The code is modified to validate the packet first followed by the CMR processing.

Workaround: None.

PortFix SBX-109304: The 13.2 wb cmr is not accepted when the SBC is operating in channel aware mode.

Impact: The channel aware mode once enabled will always be enabled when the EVS encoder operates at 13.2Kbps and bandwidth WB. The only way to disable channel aware mode is to use a bitrate other than 13.2Kbps.

Root Cause: The code to disable the channel aware mode if enabled on receiving on 13.2 WB CMR was absent.

Steps to Replicate: Run a EVS to G711 call with br=13.2, ch-aw-recv-5; bw=wb.
Stream a pcap having CMR for 13.2 WB from the peer.

The call starts with 13.2 Kbps with Channel Aware mode being enabled. On receiving the CMR, the channel aware mode will be disabled while the bitrate is still 13.2.

The code is modified to address the issue.

Workaround: None.

PortFix SBX-110439: The DSP rejects CMR requesting channel-aware if localCodecMode is set to a value other than 13.2.

Impact: The SBC was rejecting a Channel Aware Mode CMR when the current mode of operation of EVS encoder was not 13.2Kbps WB.

Root Cause: A conditional check of the current Bandwidth and current Bitrate to honor a Channel Aware Mode CMR.

Steps to Replicate: Run a EVS to AMRWB call with the following SDP:

br=13.2-24.4; bw= nb-wb; ch-aw-recv=0

End point sends a CMR for Channel Aware Mode.

In this case, the call starts with EVS encoder encoding packets as 24.4Kbps and on receiving the CMR, the rate changes to 13.2Kbps with Channel Aware mode enabled.

The code is modified to check if 13.2Kbps is a part of the activeCodecSet and whether WB is present in the bandwidth range negotiated to honor a Channel Aware Mode CMR.

Workaround: None.

PortFix SBX-110299 to 9.2 - MRFP does not active EVS partial redundancy mode during the call when the remote offers "ch-aw-recv=0"

Impact: When the ch-aw-recv=0 is negotiated through the SDP, a CMR request for the Channel Aware mode with offset 2 and the priority HIGH was not being processed.

Root Cause: The root cause of this issue was a wrong initialization of the channel aware mode offset and priority in the code.

Steps to Replicate: 

1. Run a EVS to G711 call with br=13.2; bw=wb;ch-aw-recv=0
2. Stream a pcap with CA CMR for priority HI and offset 2.

Prior to the fix the CMR is not processed. With the fix, the CMR is processed and also honored.

The code is modified to address the issue.

Workaround: None.

The CDR record for DSP insertion/rejection reason field in 9.2.2R000 test execution has marked the call as “Transcoding” instead of “Transcoding due to DTMF”.

Impact: The CDR DSP insertion reason is showing as trancoded instead of the DTMF for transcoded call with difference in DTMF parameters on the ingress and egress leg.

Root Cause: The wrong code is present and overwrites the DSP insertion reason as transcoded.

Steps to Replicate: Make a successful transcoded call with AMR codec on both sides and the
DTMF parameter must be different in both ingress and egress.

The code is modified to set the DSP insertion reason based on the answered call leg.

Workaround: None.

The system level baseUdpPort is allowed to set higher than the range set at the IPTG level from the CLI.

Impact: It is possible to set the system media mediaPortRange baseUdpPort value to a greater value than the value assigned to all the associated trunk groups, which is invalid.

Example: set addressContext <name> zone <name> sipTrunkGroup <name> media
mediaIpInterfaceGroupName <IPIG name>media mediaPortRange baseUdpPort 1030

set system media mediaPortRange baseUdpPort 1050

Root Cause: With the introduction of the SBC and realms, the validation code was incorrectly looking for realm data to validate the system level baseUdpPort against rather than the zone/address context/trunk group information that is used in SBC configurations.

Steps to Replicate: Try to run the configuration below and check that an error report is now generated.

commit Aborted: 'system media mediaPortRange': System base UDP port cannot be greater than mediaPortRange configured at a trunk group

The code is modified to correctly use the zone/address context/trunk group information to validate the baseUdpPort information on the SBC configuration.

Workaround: Manually check the values on the trunk group before assigning the system level value.

Invalid value for "45.20 Reason Header value Q850" in the ACT record.

Impact: The invalid values populated in the CDR sub field 20 in ATTEMPT record.

Root Cause: In the Signaling Application, during Call Failure the value passed to CAM module to populate in the CDR for the sub field bit 20 was out of Q850 range. This is due to not mapping the internal CPC cause code to the corresponding Q850 standard values.

Steps to Replicate: Disable the Reason Header Q850 flag, and make a call. Reject the call with 607, where SIPTOCPC profile mapped as 607-216 post call release check the CDR Sub field - 20.

The code is modified to take care of mapping to right Q850 values.

Workaround: None.

The SBC inccorectly interprets RTCP packets as RTP when using DLRBT.

Impact: The RBT (ring back tone) can be terminated early when the DLRBT (dynamic local ring back tone) is enabled and RTCP packets arrive with the B-party.

Root Cause: When the DLRBT functionality was initiated it was not informed that RTCP could be received. This resulted in RTCP packets being treated as RTP and caused the SBC to think RTP was learned. As soon as SDP was received in 183, the SBC triggered cut through and the RBT was stopped even though the call was not answered. This left the A-party with silence until the call was answered.

Steps to Replicate: Make a PSTN to MS Teams call with DLRBT enabled. Leave the call in ringing state with MS Teams for a long time and check that the ring tone is continually generated.

The code is modified to correctly identify RTCP packets and not use this as an indication to media being learned so that the ring tone continues to be played until real RTP packets arrive.

Workaround: If RTCP is not required on the egress leg then disable it. If RTCP is required there is no work around.

Export/import of the syslog configuration fails.

Impact: The user-config-import command fails if the customer has configured the SBC to send the Linux level logs to a remote syslog server through the platformRsyslog configuration.

Root Cause: The child configuration objects under the platformRsyslog configuration were not being applied in the correct order during the import, which led to the configuration validation logic thinking there was no syslog server configuration and failing.

Steps to Replicate: Apply syslog configuration under the platformRsyslog and check that it can be exported and imported without errors.

The code is modified to correctly define the configuration order for platformRsyslog configuration so there are no errors during the import.

Workaround: If you edit the syslogState line in the xml file and change it from enabled to disabled, the import will complete correctly. Then manually apply the CLI command to enable the syslogState once the rest of the configuration is imported.

<platformRsyslog>
<syslogState>disabled</syslogState>
<linuxLogs>
<platformAuditLog>enabled</platformAuditLog>
<consoleLog>enabled</consoleLog>
<sftpLog>enabled</sftpLog>
<kernLog>enabled</kernLog>
<userLog>enabled</userLog>
<daemonLog>enabled</daemonLog>
<authLog>enabled</authLog>
<syslogLog>enabled</syslogLog>
<ntpLog>enabled</ntpLog>
<cronLog>enabled</cronLog>
</linuxLogs>
<servers>
<serverNo>server1</serverNo>
<remoteHost>2607:f160:10:4043:ce:ff0:0:35</remoteHost>
<protocolType>udp</protocolType>
</servers>
</platformRsyslog>

PortFix SBX-110984: The EVS CMR not honored when in dtx period.

Impact: If the SBC receives a CMR request when it is operating in DTX mode, the CMR was not being processed.

Root Cause: The rate or bandwidth change received through a CMR was not put into effect after coming out of the no transmission period.

Steps to Replicate: Run an EVS<=>EVS call with dtx enabled. On the Ingress leg, send a valid CMR while there is no media being sent on the Egress Leg. Send a CMR on the ingress leg when it is in the "no transmission period"

Once the Ingress Leg comes out of the no tx period, the bitrate or the bandwidth as requested by the CMR should be put into effect

The code is modified to address the issue.

Workaround: None.

Customer Physical Server had a reboot failure.

Impact: In a SBC Redundancy Group if an instance contains an SM core that did not cause service outage, the instance can go down when a switchover occurs between two other instances of same RG.

Root Cause: The coreHandler/FacHandler process gets called to dump the core during a coredump on SBC if FAC feature is enabled. This process registered itself in sysIdList that is unintended and causes SM to crash while handling instance down event for other instances of same RG.

Steps to Replicate: Create a RG, run it for few days and wait for an SM core due to the NTP, which does not cause the SBC to go down. Perform a switchover in same RG between two other nodes. The current node should not go down with fix build.

The code is modified to ensure the FacHandler does not register in sysIdList.

Workaround: None.

PortFix SBX-110850: Alter CPU Affinity of Processes in 2vcpu Scenario

Impact: There are intermittent crashes of SWe_NP/SWe_UXPAD processes in 2 vcpu deployments.

Root Cause: The SWe_NP and SWe_UXPAD DPDK processes running on the same core caused memory corruption in mempools.

Steps to Replicate: 

1. Bring up a 2 vcpu VM.
2. Run a heavy transcode call load for long duration.

The code is modified to launch the SWe_NP and SWe_UXPAD processes on different cores.

Workaround: There is no workaround for this issue.

The SCM Process cores on the customer PSBCs PS40, PS41, and PS42.

Impact: A SCM Process coredump was observed because of Segmentation fault when a call was intercepted with PCSILI and media monitoring enabled.

Root Cause: The SCM Process dumped core while pushing request for splitter resources and media monitoring was enabled.

Steps to Replicate: 

1. Configure the SBC and PSX for basic audio call.
2. Configure the customer CLI on Egress Leg for basic call.
3. Enable Media Monitoring on Egress leg for basic call.
4. Enable the Tones on Ingress Leg.
5. Perform an Interception based on PCSI_LI.

The code is modified to avoid the coredump.

Workaround: None.

PortFix SBX-109211: There was a design gap for AMR around dynamic codec transcoding.

Impact: The SBC is configured with restricted AMR/AMR-WB codec in Egress Route PSP along with Transcode "If Different DTMF PT" enabled then consider Egress endpoint selects the first pass thru restricted AMR/AMRWB payload in Offer in its 200 O.K answer. In such a case, if the DTMF attribute of the payload doesn't match then the SBC will try to match the Answered AMR/AMR-WB codec with the transcode-able AMR/AMR-WB codec. In such a case the DTMF attribute will match but the mode-set match fails that causes a call failure.

Root Cause:The SBC is configured with restricted AMR/AMR-WB codec in Egress Route PSP along with Transcode "If Different DTMF PT" enabled then consider Egress endpoint selects the first pass thru restricted AMR/AMRWB payload in Offer in its 200 O.K answer. In such a case, if the DTMF attribute of the payload doesn't match then the SBC will try to match the Answered AMR/AMR-WB codec with the transcode-able AMR/AMR-WB codec. In such a case the DTMF attribute will match but the mode-set match fails that causes a call failure.

The partial matching of AMR/AMR-WB codec in a Offer Answer cycle was allowed early, and that was what caused the issue.

Steps to Replicate: The SBC receives an INVITE with (AMR PT=96 and mode-set=1 and 2833 DTMF PT=101).
Egress route is configured with AMR mode-set=0, 1, 2, 3, AMR PT=126 and DTMF PT=110
Egress route is configured to transcode for Difference in 2833 PT
This causes the SBC to send out INVITE to UAS as follows:
96 (AMR mode-set=1)
126 (AMR mode-set=0,1,2,3)
110 (DTMF PT)

The code is modified so if the SBC transcodes the call due to Different DTMF, the transcoding is allowed and first offered payload type is used.

Workaround: None.

PortFix SBX-110009: The values in callsEstimate.txt differ between the Active and Standby SWe.

Impact: The session capacity estimate values differ in active and standby VMs upon an LSWU upgrade of 1:1 the SWe HA pair.

Root Cause: The following sequence of events resulted in the issue:

1. The processor indices are re-calculated upon LSWU upgrade, which differs from the processor indices calculated by the SBC VM in the earlier version.
2. The session estimates are calculated based on these new processor indices.
3. Post upgrade, once the application comes up, the processor indices that are stored in DB(from the older version VM), are restored back to the /opt/sonus/conf/swe/capacityEstimates/.index.txt file.

As a result, the Active and Standby VMs obtained different session estimates upon upgrade.

Steps to Replicate: After subjecting the 1:1 SWe HA to LSWU upgrade, content of the following file in Active and Standby VMs would differ:
/opt/sonus/conf/swe/capacityEstimates/.callsEstimate.txt

The code is modified to retain the processor indices during the LSWU procedure.

Workaround: After completing the LSWU upgrade, once the active(VM-A) and standby(VM-B) VMs are in sync, following a set of operations would make sure that session capacity estimates are identical in Active(VM-A) and Standby(VM-B) VMs:

1. Reboot the Standby (VM-B) VM.
2. The standby (VM-B) VM comes up with correct session estimates. Wait for the completion of application sync.
3. Now, reboot the Active(VM-A) VM. This results in application failover. Application running on the Standby(VM-B) VM takes over the active role.
4. Active(VM-A) VM comes up with the correct session estimates and comes in sync with the application running on the Standby(VM-B) VM.

PortFix SBX-105890: On a disk failure, the correct failover is not triggered.

Impact: On an SBC that was running 6.2 code, the disks on the SBC got into a bad state and would not process read or write operations. Automatic attempts to reboot the SBC from the application code failed and manual intervention was required to recover.

Root Cause: Later software releases already had better handling for this sort of issue but the code was printing multiple logs as part of the automatic reboot process and it was suspected that these could have gotten hung and the system could not get to the reboot command.

Steps to Replicate: The issue was not reproducible.

The code is modified to remove the logs to avoid the potential or not getting to actual reboot command in the code.

Workaround: The SBC needs to be manually power cycled to recover.

Portfix SBX-109591: Reject the 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.

PortFix SBX-108410: [ASAN]: sanitizer.CE_2N_Comp_ScmProcess_3.8866:==CE_2N_Comp_ScmProcess_3==8866==ERROR: AddressSanitizer: heap-use-after-free on address 0x6190001c77dd at pc 0x558bcc9ff877 bp 0x7fea305f4e00 sp 0x7fea305f45b0

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

Root Cause: 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: Run the codenomicon subscribe-notify suite.

The code is modified so the SBC now logs a parser error If the SBC receives NULL character in a quoted string.

Workaround: None.

The one way audio when forked leg is MS Teams without ICE/NAT.

Impact: For an incoming call that is forked to multiple destinations and DLRBT is enabled, there is a possibility of audio flowing only in one direction when the call gets established.

Root Cause: When a 180 ringing is first received from one of the forked destinations, this triggering the SBC to play ringback tone, but if the call subsequently receives 18x messages and RTP media (for media cut through) from a different destination, the SBC fails to activate the RTP media flow resources correctly at the ingress leg of the call because these resources are already activated for playing the ringback tone for the other fork.

Steps to Replicate: Set up
---------
The SBC configured with call forking such that call from ingress (A) to be forked to egress (B) and egress (C).
The DLRBT should be enabled on ingress and egress trunk toneAndAnnouncementProfiles.

Procedure
--------------

1. Initiate the call with an INVITE from A that should be forked to B and C.
2. From the egress endpoint B respond with 180 and then from egress endpoint C respond with 180.
3. From egress endpoint C respond with 183 with SDP.
4. Send the RTP media packets back from C to cause media CUTTHRU.
5. From egress endpoint C respond with 200 OK to connect the call.

Expected Results
-----------------------
1. The INVITE sent to B and C.
2/3. The SBC sends back 180 towards A and starts to play ringback tone towards A.
4/5. The call is established, the SBC sends CANCEL towards B, ringback tone should stop and media should flow in both directions between A and C.

Before the fix, media was not flowing from A to C.

The code is modified to re-activate the media resources after the call is answered on one of the forks and the remaining forks have been cleared.

Workaround: Not available, but the issue does not occur if the DLRBT is not enabled.

PortFix SBX-105609: Add a check for /boot parition free space in pre-checks.

Impact: There was an upgrade failure due to insufficient disk space on /boot partition.

Root Cause: There was an 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 as part of pre-checks to ensure a minimum of 40MB free disk space is available on /boot partition.

Workaround: None.

PortFix SBX-110292: A Registration structure update is needed to prevent hijacking/hacking of the user after being rejected with a 403 Forbidden error.

Impact: After a hack, the registers rejected with 403 Calls were not working.

Root Cause: Both a normal and hacker user had very similar Register messages, except that the hacker's Auth header did not include the correct username. Due to this username mismatch, the SBC rejected the hacker with a 403 message, set the Register into 'challenged' state and later deleted the message.

Steps to Replicate: There are 8 combinations of test cases. The major difference is in the username field Auth header.

Test1:

1. Proper registration: Reg->401→Reg (with Auth)→200
2. Hacker registration: Reg->401→Reg (with hacker Auth)→403
3. Proper user refresh
4. Hacker registration: Reg->401→Reg (with hacker Auth)→403

Check for all fields and expiration timer.

Test2:

1. Proper registration: Reg->401→Reg (with Auth)→200
2. Hacker registration: Reg->401→Reg (with hacker Auth)→403
3. Proper user refresh
4. Hacker registration: Reg (with hacker Auth)→403

Test3:

1. Proper registration: Reg->401→Reg (with Auth)→200
2. Hacker registration: Reg (with hacker Auth)→403
3. Proper user refresh
4. Hacker registration: Reg->401→Reg (with hacker Auth)→403

Test4:

1. Proper registration: Reg->401→Reg (with Auth)→200
2. Hacker registration: Reg (with hacker Auth)→403
3. Proper user refresh
4. Hacker registration: Reg (with hacker Auth)→403

Test5:

1. Proper registration: Reg (with Auth)→200
2. Hacker registration: Reg->401→Reg (with hacker Auth)→403
3. Proper user refresh
4. Hacker registration: Reg->401→Reg (with hacker Auth)→403

Check for all fields and expiration timer.

Test 6:

1. Proper registration: Reg (with Auth)→200
2. Hacker registration: Reg->401→Reg (with hacker Auth)→403
3. Proper user refresh
4. Hacker registration: Reg (with hacker Auth)→403

Test 7:

1. Proper registration: Reg (with Auth)→200
2. Hacker registration: Reg (with hacker Auth)→403
3. Proper user refresh
4. Hacker registration: Reg->401->Reg(with hacker Auth)→403

Test 8:

1. Proper registration: Reg (with Auth)→200
2. Hacker registration: Reg (with hacker Auth)→403
3. Proper user refresh
4. Hacker registration: Reg (with hacker Auth)→403

The code is modified so when the SBC rejects the hack because of a username mismatch in the Auth header, it reverts back to previous details and state (that is complete).

Workaround: None.

PortFix SBX-103963: Both SBCs restarted at the same time and both mounted drbd0.

Impact: Both 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 the standby. And while the standby is coming up, run a switchover from active CLI. The switchover should be successful.

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

Workaround: None.

PortFix SBX-110842: A switchover on the SBC 5000.

Impact: The SAM process core dumped when the SIP code was attempting to lookup a internal SIP Registration Control Block.

Root Cause: The core was the result of SIP code attempting to using a invalid index when accessing an array element for the purposes of finding a internal SIP Registration Control Block.

Steps to Replicate: We have been unable to reproduce this issue. The root cause was found by code inspection and has been corrected.

The code is modified to prevent the use of an invalid index when accessing an array element.

Workaround: There is no known workaround.

There are call trace logging issues while all Call Trace filters are disabled.

Impact: Messages traced at level 4 for sageTracing may erroneously have FILTER=<name> in the trace header. For the sageTracing, the filter name should be blank.

With the sageTracing enabled, 70% of the received INVITES are traced at the level 4 and 0.5% of calls have all their messages traced at level 4. The sageTracing is tracing collected for the Strategic Analysis Gap Execution.

Root Cause: The filter name messages traced for sageTracing should be blank but instead uses the 64th entry in the filter names table.

Steps to Replicate: 

1. The sageTracing is enabled.
2. Create at least 64 call trace filters and enable them.
3. Delete the trace filters.
4. Send INVITE messages.

The code is modified to filter the name blank.

Workaround: None.

Portfix SBX-106871: The SBC application times out while checking a callDetailStatus.

Impact: The CLI 'show table global callCountStatus' timed out after a call setup failure due to the codec license not being available.

Root Cause: The call setup failure in early stage caused an internal out of sync of the call resource, that triggers a handler of 'show table global callCountStatus' timeout when accessing the call resource.

Steps to Replicate: Create a call in the SBC with no available codec license of the call.

The code is modified to clear the call resources in all related internal modules upon call failure in early stage to address the issue.

Workaround: None.

Portfix SBX-100881: The SBC sends a release to the H323 side.

Impact: The SBC is sending a call release to the H323 side.

Root Cause: During the codec selection on H323 side, the SBC ran into some offer-answer collision due to ACK SDP from SIP side. As a result, the SBC is terminating the call.

Steps to Replicate: 

1. Make a call from SIP to H323 and the call gets connected.
2. Send a late media Re-INV from SIP EP to the SBC.
3. The SBC sends 200 OK with SDP to SIP EP.
4. SIP EP sends ACK with SDP to the SBC.
5. The SBC sends a FACILITY to H323 EP.
6. The SBC terminates the call.

The code is modified so that the codec selection on the H323 side occurs independently during a modify offer-answer is in progress.

Workaround: None

PortFix SBX-105657: The Customer SBC Upgrade failed.

Impact: The LSWU upgrade failed from 7.2.2R0 to 8.2.3R0.

Root Cause: The /tmp partition was running out of disk space and the restoration failed during an upgrade.

Steps to Replicate: Run a LSWU upgrade from 7.2.2R0 to 9.2.2.

The code is modified to ensure there is enough space available.

Workaround: Free up some space in /tmp directory and re-run the upgrade.

PortFix SBX-110247: The "sonusSbxNodePolicerMinorAlarmNotification" alarm is generated by the SBC.

Impact: Packets arriving on a unallocated port do not get marked as rogue media.

Root Cause: The issue occurs only on ports that was used and disabled. Packets arriving on this port get marked as grace-media packets. This is because a very high value of grace period is being incorrectly programmed for the udp port instead of the default 4 seconds. The high value is because of endianness.

Steps to Replicate: 

1. Reboot the VM.
2. Make a single normal call and wait for the call to end. Note down RTP UDP port of the SBC used in the call.
3. After the call has ended, stream UDP packets to the same RTP UDP port previously used in the SBC call. We will not see any unallocated port rogue media entry for the stream.
4. Stream the UDP packets to a UDP port that has not been previously used in the SBC call. We will see rogue media entry for the stream.

The code is modified to perform the appropriate endianness translation on the affected fields to arrive at the correct value.

Workaround: No workaround. This does not affect normal media processing, or associated statistics.

PortFix SBX-110323: A SWe media Issue occurred after an active reboot

Impact: Media issue after switchover.

Root Cause: Before a switchover, the loopback call was set up with 2:xx:xx:x:x:x (vbsc1's pkt port mac address) for both src and dst MAC address. After switchover, from packet capture, we found that the SRC MAC address= 2:xx:xx:x:x:xx (vsbc2's pkt port mac address). As a result, using the srcMac and dstMac caused a media issue.

Steps to Replicate: Use the following configurations to test:

• Set up loopback and normal calls for both SBC HW and SWe platforms.
• Do port and SBC switchovers.
• Use single and alternate media IP addresses on the loopback ports.

The code is modified to use loopback flag mirrored to standby BRM, and overwrite both srcMac and dstMac if loopback flag is set to true. This is done only on SWe when enabling or modifying the RID.

Workaround: No workaround.

PortFix SBX-109200: Missing the CDR for Teams call transfer scenario.

Impact: For an MS Teams blind transfer scenario with tonesAsAnnouncements enabled, where the MS Teams user A establishes a call to PSTN user B, then MS Teams user A establishes a call to user C and then invokes a blind transfer to establish the call between B and C. When the call is subsequently cleared one of the CDR STOP records for the call is not generated.

Root Cause: When the tonesAsAnnouncements are enabled, after a blind transfer is initiated from user A, the subsequent call clearing logic is not correctly deactivating the internal announcement resources causing the call to not fully clear internally which results in STOP record not being generated.

Steps to Replicate: With the SBC configured for MS Teams having DLRBT with announcementBasedTones enabled.

Procedure
--------------

1. Establish a call from MS Teams User A to PSTN user B.
2. Establish a call from MS Teams user A to PSTN user C.
3. Initiate a blind transfer from MS Team user A, between user B and user C.
4. Clear the call and check CDR records.

Expected Results
-----------------------
Calls, transfers, and announcements should be successful.

The SBC should generate START and STOP CDR records for A-B and A-C call.

The code is modified to correctly deallocate announcement resources for this call scenario so subsequent call clear can complete successfully and generate the correct CDR stop records.

Workaround: If tonesAsAnnouncements are disabled the call scenario works as expected.

Portfix SBX-107976: Disable the FAC feature in M-SBC, and SLB.

Impact: Non-SIP SBC personalities should not have FAC feature enabled.

Root Cause: Earlier, the SBC did not have personality check when setting core pattern.

Steps to Replicate: Verify the user defined core pattern is not set in /proc/sys/kernel/core_pattern when instances are spawned with the personalities msbc,slb,mrfp irrespective of facState.
%set system faultAvalancheControl facState <enabled/disabled>

User Defined Pattern:

cat /proc/sys/kernel/core_pattern
|/opt/sonus/sbx/bin/CoreHandler -f /var/log/sonus/sbx/coredump/core.1.%e_%p.%t -t %i -p %p

Default Core Pattern:
cat /proc/sys/kernel/core_pattern
/var/log/sonus/sbx/coredump/core.1.%e_%p.%t

The code is modified to not enable the user defined core pattern for personality type M-SBC, and SLB.

Workaround: Disable the FAC Feature.
%set system faultAvalancheControl facState disabled

PortFix SBX-107583: There is one way audio on hairpinned calls.

Impact: A one way audio problem is seen in a AMR-AMR transcoded call with DTMF interworking when "Different2833PTType" is enabled. This problem is visible for all HD codecs (AMR, AMR-WB, EVS, SILK) that uses dynamic payload in SDP offer.

Root Cause: A one way audio problem is seen in a AMR-AMR transcoded call with DTMF interworking when "Different2833PTType" is enabled. This occurs because SBC incorrectly configures the DSP channel with an incorrect payload type, not the payload type which was negotiated during the Offer Answer exchange on the Egress leg.

Steps to Replicate: 

1. Enable "Different2833PTType" and TransCode conditional in PSP and set Preferred DTMF payload to 102 on both the PSP.
2. Send AMR payload 96,AMR-WB with DTMF 110 (8k) from Ingress.
3. Ensure Egress answer sends AMR 96 and DTMF 102 in answer.
4. Ensure that the call is transcoded and there is no way audio problem.

The code is modified so the SBC configures the DSP with pass thru payload type.

Workaround: A code fix has been made.

Portfix SBX-107954: The SBC CPXA coredump after EVS+T140 MRFP call.

Impact: Occasionally, when the show global callDetailStatus command is executed in the CLI, the CPX process coredumps.

Root Cause: If information is not available for a particular call, the data returned did not have a valid type for the Ip addresses returned. This caused a timeout out in confd because the CPX did not return information for the global callDetailStatus.

Steps to Replicate: The steps cannot be reproduced.

1. The code is modified to return valid information for a call when information is not available.
2. The code is also modified to send a response to the CPX process when the application does not return proper data so that the CPX process will not crash.

Workaround: Do not run the global callDetailStatus command.

PortFix SBX-108557: The SBC continuously core dumps for SCM process since the upgrade to V09.02.01R000.

Impact: ScmProcess may coredump due to memory corruption.

Root Cause: There is code that is using an invalid pointer when writing to a buffer. This code was only added recently in 9.2.1R0.

Steps to Replicate: This problem is triggered by the receipt of an invalid PDU and/or an SMM rule to reject the incoming Invite and an early ATTEMPT record was attempted to be written. The issue is random and depends on what info is NOT available when trying to write the accounting record, therefore the issue may not reproduce all the time.

The code that uses in invalid buffer pointer (which was added recently) has been removed.

Workaround: If there is SMM rule (ignore/reject the Invite), then the SMM rule needs to be disabled until patch is applied.

PortFix SBX-108126: Observed a SAM Process crash in another active node during SIPFE crash testing.

Impact: The SAM Process coredumps due to a buffer overflow.

Root Cause: The key:value length of incoming Message is max 255 bytes. But in the yang spec, the buffer length was defined as 23 bytes. As a result of this issue, the display was truncated and also crashing due to buffer overflow.

Steps to Replicate:

1. Configure the testbed for the fault avalanche testing.

2. Trigger the crash by sending fac-sipfe-0 in the From header, where From(calling Party) is larger than 23 bytes.

Expectation:

1. The current active should crash the SAM Process.
2. Standby will take over as active and blocks the SIP message that triggered crash.

The code is modified to handle 255 bytes string, so the buffer overflow does not happen and display is not truncated.

Workaround: None.

PortFix SBX-108388: The SBC set "user=phone" on Dummy History-Info header.

Impact: When interworking between diversion header and history info header if the diversion count is more than 2 then the SBC generates dummy history info headers. These dummy history info headers contain user=phone which some end points reject.

Example of a dummy history info header.

History-Info: sip:unknown@unknown.invalid;cause=302;user=phone;index=1.1;mp=1

Root Cause: The code was mistakenly adding the user=phone attribute even when no phone number was present in the dummy history info header.

Steps to Replicate: Configure the SBC to support interworking from diversion header with a count of 5 to history info headers and check that the dummy history info headers do not include user=phone.

The code is modified not to include user=phone in the dummy history info headers.

Workaround: Use SMM to remove the user=phone attribute from the dummy history info headers.

PortFix SBX-109464: Using a leadership algorithm workaround for an old openclovis issue can cause a core dump.

Impact: Thesafplus_gms process crashes when coming out of split brain.

Root Cause: There was incorrect/inconsistent data results in the code asserting.

Steps to Replicate: This problem is not easily reproducible and is caused by HA link instability/flapping.

The code is modified so that the data is consistent.

Workaround: The HA link stability.

Portfix SBX-109224: AWS: The upgrade is failing with an error message " instance is not reachable " even though the upgrade status is "success :true"

Impact: The AWS upgrade was failing due to instance non-reachability. In actuality, the VNFC was up and running but the VNFR showed VNFC status non-reachable.

Root Cause: The VNFR-VNFC communicates using a ZMQ and VNFR updates the VNFC health check using the same ZMQ thread mechanism. There is a Zmqclient and ZmqServer. After an undetermined point in time, the VNFC(ZmqClient) is waiting for an infinite time to get a response from the VNFR(ZmqServer). This is leading to blocking state.

Steps to Replicate: Run an upgrade/revert operations on 9.2.2/10.0.0.

The code is modified so the ZMQ communicates in non-blocking mode.

Workaround: For the workaround, the user needs to run the pre check command from vnfr_intf before upgrade/revert operations and needs to take action provided as a part of output table.

Portfix SBX-109922: The buffer used while printing PSP's was running out. As a result, this is an error.

Impact: The buffer used while printing PSP's was running out because of large PSP. As a result, this is an error.

Root Cause: The buffer used while printing PSP's was running out. As a result, this is an error.

Steps to Replicate: 

1. Run the suite with the RTCP Interworking Enhancements.
2. The warning above in the Opensaf logs should not come.

The code is modified to accommodate bigger strings.

Workaround: None.

Portfix SBX-109336: The SBC 5110: BIOS not updated to 2.07 post-upgrade as indicated in Release Notes.

Impact: The BIOS is not upgrading part of the SBC application upgrade.

Root Cause: The flashroom utility is using /dev and /proc file system to upgrade BIOS. these file systems are un-mounted part of grub2 config upgrade.

Steps to Replicate: Upgrade the SBC app from 7.x (BIOS=2.6) to >= 8.1.x.(BIOS = 2.7). The BIOS should upgrade part of an application upgrade.

Mount /dev and /proc file system before calling BIOS upgrade

Workaround: 

1. Stop SBC App
   1. #sbxstop
2. Go to /opt/sonus/bios-update/
   1. #cd /opt/sonus/bios-update/
3. Run the script to update BIOS.
   1. # ./updateBIOS.sh bios5X00_v2.7.0-R0.rom

This scripts will take few minutes to update BIOS, after its done reboot host. In next boot it will boot up with new BIOS.

Portfix SBX-108127: 9.1r3 to 10.0 LSWU failed with the reason "Failed_to_install_or_configure_database"

Impact: The LSWU failed with the reason "Failed_to_install_or_configure_database".

Root Cause: Ownership for the files in /var/log/postgresql is getting changed at the time of the upgrade.

Steps to Replicate: Perform an upgrade from any version to 9.x

The code is modified to restore ownership of the log files in /var/log/postgresql to postgress.

Workaround: None.

PortFix SBX-108237: Performance: Observed SAM and SCM process coredump for FAC enabled execution on SBC 5400

Impact: The SCM experiences a core dump when the Invite gets a transaction timeout and the 200 Ok for Invite is received at the same time.

Root Cause: In the problem scenario, the SBC is trying to send ACK for the 200 OK, the SCM cores when creating a SIP Transaction for ACK Message.

Steps to Replicate: 

1. Run a Basic Invite call flow.
2. Do not answer for Invite on the UAS side.
3. After 32 seconds send 200 OK for Invite from the UAC side.

A race condition might occur and result in coredump.

The code is modified not to send ACK in this scenario as the CseqType and CseNumber are unknown and 0 respectively.

Workaround: Not Applicable.

PortFix SBX-107690: There are SBC call failures observed on T140 load with various MAJOR logs in DBG.

Impact: A call fails due to RID Enable errors. (where RID = receiver ID and is mapped to an allocated resource).
ThenDBG log shows many BrmAsnycnCmdErrHdlr logs with cmd 0x30 (RID Enable):
MAJOR .BRM: *BrmAsyncCmdErrHdlr: ERROR NpMediaIntf cmd 0x30 gcid 0x2128915e

Root Cause: When the RTCP Generation is disabled, the RTCP RID for the call is expected to be disabled by Network Processor (NP).

With the introduction of SBX-86241 "Streaming RTCP packets to Protect Server", we now have a case where RTCP Generation is enabled to stream RTCP packets to Protect Server but RTCP packets are not generated for the call and RTCP RID for the call is not enabled.

When the RTCP Generation is disabled, the NP uses rtcpMode=RTCP Terminate to indicate that the RTCP RID needs to be disabled.

This is incorrect since rtcpMode=RTCP Relay Monitor also has the RTCP RID enabled and NP is expected to disable the RTCP RID.

If a call has the rtcpMode=RTCP Relay Monitor and RTCP Generation is disabled, we leak this particular RTCP RID resource.

The next time, we try to allocate this particular RTCP RID, NP returns an error indicating RTCP RID is already allocated.

Steps to Replicate: 

1. Enable Packet Service Profile //Resources/profiles/media/packetServiceProfile/rtcpOptions/generateRtcpForT140IfNotReceivedFromOtherLeg.
2. On SBC, set //System/media/mediaRtcpControl/t140RtcpMonitorInterval to 20 seconds.
3. Start T140 call but do not send RTCP packet. Terminate call in 10 seconds.
4. If you keep making this type of call, you will eventually see the Enable RID error. DBG log will have the BrmAsynCmdErrHdlr entry.

The code is modified so the Bus Resource Manager (BRM) knows whether RTCP RID is allocated and needs to be disabled by NP.
The code is also modified so that BRM indicates RTCP RID needs to be disabled or not.

When NP receives the command, it uses this new parameter to decide if RTCP RID should be disabled or not.

Workaround: Disable RTCP and disable RTCP termination.

Portfix SBX-109384: The 8.2.4F001 SBC 5400 Global level SMM stopped to work.

Impact: The Global SMM function stopped working post upgrade and similar issue was observed after multiple switchovers.

Root Cause: The Global SMM configurations were not being restored.

Steps to Replicate: 

1. Attach an SMM at global level (for 200ok of pathcheck options).
2. Perform multiple switchovers or LSWU to another build.
3. Check if the SMM is being applied.

Restore the Global SMM configurations during multiple switchovers to address the issue.

Workaround: Delete the profile set at global level and configure it again.

PortFix SBX-107430: URI parameter setting order of R-URI does not meet RFC 3966 requirements.

Impact: In the request URI, the isub parameter was after the NPDI parameter, which does not meet the RFC 3966 requirement. (ie. npdi;isub=1111)

Root Cause: In the code (sipsgCallProcEngine.c), the isub parameter was getting populated after NPDI and other user parameter.

Steps to Replicate: SipSgMapIsdnSubAddrToSipParam this function is responsible for populating isub parameter to request uri, this moved prior to all other parameter populating functions.

The code is modified so the isub parameter populating function is moved before all other parameter populating functions.

Workaround: NA

PortFix SBX-108270: The S-SBC sends a DNS SRV before completing all NAPTR query.

Impact: The S-SBC sends DNS SRV before completing all NAPTR query.

Root Cause: A DNS agent request timeout occurs after 10 seconds. Because the DNS agent sends the DNS lookup (NAPTR) request to DNS Client process, the DNS client process then queries to an external DNS server for NAPTR records. The DNS agent waits until 10 seconds then timeout's for each DNS lookup. As a result, the DNS request is failed with the first DNS server and query is still in process for a second DNS server.

Steps to Replicate: Configure 2 DNS server's

1. Configure DNS global configuration to:
   admin@SBX136% show global servers DNS global
   retransmissionCount 14;
   retransmissionTimer 500;
   set addressContext default dnsGroup DNSGrp1 negativeDnsCacheSupport disabled
2. Configure dnslookupTimeoutTimer to 10 sec.
3. Stop the DNS server.
4. Make a call.

Observation:

1. DNS should retransmit DNS NAPTR query to DNS server1 and after should move to DNS server2.
2. After 10 sec, NAPTR query shall stop.
3. The SBC should send SRV/A query to DNS Server2.

The code is modified to:

1. Add new configuration timer flag "dnslookupTimeoutTimer" for DNS lookup.
2. Once the lookup timer expires, the DNS client will stop sending same query to DNS server (Ex: if NAPTR query is re-transmitted towards the DNS server, after timer expire. NAPTR query will be stopped).

Workaround: None.

PortFix SBX-107517: Import configuration results in two different final status depending where you look at it.

Impact: The postgres DB restore fails that leads to provisioning issues such as:
The "show configuration" does not display a complete configuration related to policy entities like sipTrunkGroup, IpPeer etc.
The "delete" operation fails for sipTrunkGroup and other policy related entities. The exportConfig does not contain policy related entitles.

Root Cause: The PostgressDB restore is failing due to restricted permission.

Steps to Replicate: Set up required: 1to1 S-SBC virtual platform and register it within Direct-Single type of cluster on EMS.

1. Configure 2 TG and saveAndActivate revision (e.g. revision 2).
2. Configure couple of more CLIs and save AndActivate (e.g revision 3).
3. Restore revision 2 either from CLI or EMS.
4. After restore is successful. try to delete a TG. Observed Application failure.

After implementing the fix, use the 4 steps and as a result, the delete was successful.

The code is modified to permit an appropriate permission to postgres user while restoring the pg_policy dump.

Workaround: Use the following steps:
#cd /opt/sonus/sbx/scripts

Update the oam-config.sh on active and standby the SBC as following:

replace
$CHMOD -R 660 $extractDir/

with

$CHMOD -R 665 $extractDir/
accessRights=`$STAT -c %a $SONUS_TMP_DIR`
$CHMOD 775 $SONUS_TMP_DIR

find $RM -rf $extractDir and add following line below this

$CHMOD $accessRights $SONUS_TMP_DIR

Restore a revision that has pg_policy_xx.dump with correct Trunkgroup, ipPeer etc. entries.

Portfix SBX-110354: After upgrading from V08.02 or V09.02 to 10.00.00R000 successfully, a REVERT from 10.00.00R000 to V08.02.04R000 is failing.

Impact: Reverting from the higher software version to lower software version fails.

Root Cause: The OAM does not upload restored revision against lower software version (ie. restore of config tar ball that was created on lower software version before upgrade). After following the MOP for downgrade when OAM comes up, it downloads the last revision uploaded on EMS (in this case config revision for higher software version). As a result, it fails to start the service because of a version mismatch.

Steps to Replicate: 

1. Spawn OAM + S-SBC on V08.02.04R000.
2. Create multiple revision (e.g revision 1, 2, 3, 4).
3. Upgrade to software version V10.00.00R000.
   The revision 5 gets created from revision 4,
   Create revision 6, 7, 8.
4. Restore to revision 4 -> revision 9 will get created and uploaded to EMS.
5. Downgrade to revision V08.02.04R000.

Expected O/P:

The OAM should come up with revision 10 created from revision 9.

The code is modified to upload a configuration when a revision that is created on a lower software version is restored. And after a  downgrade, it picks the revision with software version where the downgrade is done.

Workaround: None.

Portfix SBX-106475: The Cloud SBC instances are not coming up after a fresh installation or rebuild and the MGMT I Pis unreachable in BLR-PC3.

Impact: The SBC instances are not coming up after a fresh installation or rebuild and the mgmt ip is unreachable when using the X710 sriov vfs for pkt interfaces.

Root Cause: The X710 driver reset has been known to experience a delay in completing, thus causing a cloud-init service failure. For example, after the OS boot (as part of renaming the interfaces by sonusdev), the X710 driver is restarted. When the X710 does not immediately reset, the next cloud-init service fails, and the system is not in proper state.

Steps to Replicate: The SBC instances should come up properly after fresh installation or rebuild and mgmt ip should be reachable with all supported sriov vfs for pkt interfaces.

The code is modified so after the renaming is done and the network driver is restarted, wait for some seconds to check if all the nic ports are up and running in sonusdev itself, before exiting the service. This blocks all other dependent service from starting. Once the nic port are up, proceed with the system bring up. With these code changes, the nic does not come up then, we log it as critical log and expect the user to check on it.

Workaround: None.

Portfix SBX-109597: Observed SCM process crash on the newly active S-SBC during SWO testing.

Impact: While the SBC is running in sensitive mode, observed the SCM Process core during a switchover testing under the 1000 cps call load.

Root Cause: As part of switchover, all the connected calls are rebuilt on a newly active SBC. But, there may be a chance that the SBC can hold few stale entries related to active calls in the system, which will be cleaned up after some time. If any of these stale entries receive an unexpected events, that leads to a core dump.

Steps to Replicate: 

1. Run 1000 cps load with 120 CHT.
2. Perform a switchover by killing the PRS Process.

The code is modified to identify these events for the stale entries and ignore them to avoid a coredump when the SBC running in the sensitive mode.

Workaround: None.

PortFix SBX-108225: Observed core files on fresh installed VMware SWe.

Impact: The SSREG and SLWRESD processes a coredump on VMware SWe due to the time being set in past.

Root Cause: When the SBC is installed using ISO and then app is installed, the ntp sync is occurring while the application is running and in case the time is set in the past, it causes SSREQ and SLWRESD processes to core dump.

Steps to Replicate: Launch with the NTP IP other than a default IP, check if a coredump occurs due to time being set in the past.

The code is modified to update the /etc/ntp.conf before the SBC comes up so the runntpdate can access the NTP server IP.

Workaround: No workaround.

Portfix SBX-108219: Observed a SAM Process coredump in SLB for 1000 cps Peering Call load.

Impact: In a load run, there was a core being observed in the SLBDEBUG call when it hits the default states as part of the SBC message processing.

Root Cause: In the SLB debug call, there was new line () being passed as part of a string.

Steps to Replicate: Not reproducible. The issue seen once when running.
Run 1000 cps INVITE call load with PRACK enabled.

The code is modified so the new line () is not part of the debug string.

Workaround: There is no workaround identified for this issue.

PortFix SBX-110642: A coredump occurs after a blind transfer call.

Impact: The DNS process is coring when TEAMS blind transfer call is made.

Root Cause: The NULLError check was missing before accessing DNS Group pointer in DNS module. This occurs when DNS Group is not attach to Zone. So get function for the DNS group pointer returns NULL.

Steps to Replicate: PSTN to TEAMS

TEAMS blind transfer to PSTN2

Expected Result:
There should not be a coredump during the BT.

The code is modified so now the DNS group is fetched after setting the current DNS group to default DNS group, this is case when the DNS group IP not provided.

Workaround: No workaround.

Portfix SBX-108612: An SCM Process core dump occurred when INVITE with message size of 31700 bytes is sent

Impact: Receipt of SIP messages with Content-Type: multipart/mixed and more than 10 content entries cause coredump, if a message manipulation rule is active with criterion on message body.

Root Cause: Missing handling for unexpected message received.

Steps to Replicate: 

1. Configure and apply a message manipulation rule with criterion messageBody.
2. Send in INVITE with Content-Type: multipart/mixed and more than 10 content entries.

The code is modified so that if more than 10 content entries are present, the message is not considered for SMM rule actions with criterion on message body.

Workaround: None.

Portfix SBX-109327: Some CDR Events in ACT files have timestamps that are not current.

Impact: Duration Field (+24 Duration of SIP Registration/Subscription Context) is not displayed for some register transaction.

Root Cause: Duration Field (+24 Duration of SIP Registration/Subscription Context) is only updated in case of de-register for Successful transaction.

Steps to Replicate: 

1. Configure SBC for Registration/Subscription.
2. Perform following Registration.
   A ------REGISTRATION----->SBC-----REGISTRATION---->B
   A<--------404--------------------SBC<-----------404---------------B
   A ------REGISTRATION----->SBC-----REGISTRATION---->B
   A<--------200OK--------------------SBC<-----------200OK---------------B
3. Check CDR for "Duration Field" ( +24 Duration of SIP Registration/Subscription Context)

The code is modified to display the duration of SIP Registration/Subscription context for every CDR event.

Workaround: None.

PortFix SBX-106760: Performance: While running IMS AKA Registrations on SWe KVM, cannot achieve 1000 subscribers with 30 RPS properly.

Impact: The SBC was not able to achieve the IMS AKA registrations even at a lower rate (30 registrations per second).

Root Cause: For one of the IPsec features, the XRM code was modified to perform route lookup and next hop destination MAC resolution during IPsec SA setup. This was causing a delay in setting up IPsec SAs during load causing timeouts during the IMS AKA registration.

Steps to Replicate: Run the IMS AKA Registration load at 30rps.

The code is modified to not invoke the route loopup and destination MAC resolution code that is causing delay in setting up IPsec SA, which addresses the issue.

Workaround: None.

Portfix SBX-110066: Observed a SAM Process core dump in SLB while testing Performance with SLB (TLS Peering Calls) - One time Occurrence.

Impact: A SAM Process core was observed on a shutdown.

Root Cause: A race condition in the process shutdown code occurred allowing access to an invalid pointer, and causing a core dump during the shutdown of the SAM Process.

Steps to Replicate: Restart the SBC and look for a SAM Process core.

The code is modified to avoid the race condition that led to the core.

Workaround: No workaround, but since this core is during shutdown, there is no impact to normal operations of the SBX.

PortFix SBX-109953: Performance: Observed NP_WRK0 Core on Active Instance on OpenStack while using VIRTIO.

Impact: The SWe_NP can crash during a sbxrestart or sbxstop in the extra small memory profile.

Root Cause: There is corruption due to incorrect use of global variable in an extra small memory profile.

Steps to Replicate: 

1. Bring up the SBC in extra small memory profile.
2. Run a sbxrestart or sbxstop.

The code is modified to address the issue.

Workaround: None.

PortFix SBX-108310: Various link monitor issues on the SBC SWEs with port redundancy enabled.

Impact: On the VMware platform with Intel 82599 SR-IOV packet port VFs, the link does not get restored upon toggling the underlying physical link.

Root Cause: Because of VMware PF driver shortcoming, DPDK ixgbevf PMD code does not get link up indication from link speed status register for SR-IOV VFs from Intel 82599 card.

Steps to Replicate: 

1. Bring up port redundancy setup on VMware with SR-IOV 82599 VFs packet port.
2. Toggle the carrier link state on the NIC by cable pull or interface link toggle on host through the IP commands.
3. Observe the link status is not restored.

The code is modified to detect the physical link loss from the NACK status set on the hardware mailbox register, specifically for the VMware platform.

Workaround: No workaround. Only reboot clears the link state.

Portfix SBX-106858: The SBC clears a call on receipt of 200OK answer - CFNA call.

Impact: The SBC clears call on receipt of answer for a MRF transcoded call involving egress UPDATE followed by tone play.

Root Cause: During tone play, the SBC detaches the MRF resource from the call since tone is played by SBC. However, the media endpoint resource facing MRF stays with the call that results in failure later while assigning MRF resource back to the call during answer processing.

Steps to Replicate: The following events lead to failure in this call flow:

1. 183 with SDP from egress leads to cut-thru (MRF transcoded call).
2. Then, egress peer sends SIP UPDATE to the SBC.
3. Followed by 180 from egress which arms RTP monitoring at the SBC.
4. Followed by RTP failure notification after 2 seconds which starts Tone.
5. Followed by answer which results in failure.

Detach the media endpoint resource facing MRF from the call during tone play to address the issue.

Workaround: None.