SBC Core 09.02.04R004 Release Notes

The SBC is sending 183 with precondition mandating without SDP.

Impact: Observed call failures when the SBC sends a precondition option tag in 183 Session Progress message when there is no SDP.

Root Cause: During precondition interworking, the SBC attempts to add precondition option tag in Require/Supported header even if there is no SDP in the outgoing 18x response.

Steps to Replicate: 

1. Simulate ingress precondition interworking scenario with preconditions set to supported under trunk group configurations.
2. Send mandatory preconditions in the SDP.
3. Send multiple 18x towards ingress and do not send SDP in subsequent 18x messages.
4. The second 18x message without SDP may contain Require preconditions.

The code is modified to clear the precondition option tag (if any) in Required/Supported header when there is no SDP in 18x.

Workaround: Remove the precondition option tag using SMM in the outgoing 18x message if there is no SDP.

PORTFIX SBX-114048: The SBC Reports a service discovery error message.

Impact: The SBC reports a service discovery error when the service discovery is not being used.

Root Cause: The LCA sends an empty ConfigureBackends request to the SDR, causing an error.

Steps to Replicate: 

1. Start the SBC.
2. Review the LCA log.

Skip the configuration process if there is nothing to configure.

Workaround: None

Portfix SBX-114771: An SCM process core dump occurs on the server.

Impact: An SCM process core dump occurs as a result of a Segmentation Fault.

Root Cause: The SIPSG code creates a segmentation fault when sending a 200OK in response to a REGISTER. The code is attempting to dereference an invalid pointer.

Steps to Replicate: Regression testing is all that is necessary. 

The code that causes the Segmentation Fault is removed.

Workaround: None

Portfix SBX-112149: The Comp_Emap Processes cored on the SBC.

Impact: In sensitive mode, an SCM Process core dumps when an Un-Hold UPDATE is received from the UAC during Tone Play.

Root Cause: When an Un-HOLD UPDATE code is received from the UAC, the SBC tries to activate end to end resources. There is no answer received from the UAS, causing a core dump.

Steps to Replicate: 

1. The  UAC sends an INVITE to the SBC.
2. The SBC sends an INVITE to the UAS.
3. The UAS sends a 180 Ringing code without a SDP.
4. The SBC starts playing a tone towards the UAC due to a delayed LRBT.
5. The UAC sends an UPDATE for HOLD.
6. The SBC stops playing the tone and sends a 200 OK for UPDATE code.
7. The UAC sends an UPDATE for un-HOLD to the SBC.
8. The SBC sends 200 OK for UPDATE code.

The code is modified to check whether an answer is received from the UAS before activating the end to end resources.

Workaround: This issue occurs when the SBC is running in sensitive mode. Configure the SBC in normal mode.

Portfix SBX-112091: The SBC is not passing an UPDATE to the Egress.

Impact: If the SBC receives two 180 responses with the same SDP (one unreliable and one reliable), then the SBC doesn't send an UPDATE to the Egress.

Root Cause: The SBC has received two 180 responses with the same SDP.  The first is unreliable and the second is reliable. If the SBC sends out an SDP using the unreliable 180, then the offer/answer state will not get updated upon receipt of the second 180.

Steps to Replicate: 

1. Set sendSdpInSubsequent18x to disable.
2. Set sendSdpInSubsequent18x to enable.
3. Change the SDP in the first unreliable 180 and the second reliable 180.
4. The SDP is queued.
5. A 180 ringing code with current SDP is sent out to Ingress and an offeranswer is completed.
6. The same SDP offeranswer in the first unreliable 180 and the second reliable 180 state is completed.

The code is modified to address the issue.

Workaround: None

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

Impact: The SMM may fail to parse a display name in a double quote string where the inside may have more than one escape character next to each other in a header.

Root Cause: A logical error in parsing that causes a parsing fail.

Steps to Replicate: 

1. Configure the rule to access a double quote string display name of URI header, or any parameter.
2. After it is input, display the name.
   Example:
   From: "PhoneLite \\\"test1\\\"test2 " <sip:[field0]@dns.com>;tag=testing

The code is modified to address the issue.

Workaround: There is no workaround.

Portfix SBX-109056: The SBC 5400 TEAMS CQ is having transfer issues.

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

Root Cause: 

1. During a Leg A to Leg B call, Leg B successfully REFERS the call to leg C.
2. Leg C attempts to REFER the call to leg D (or back to leg B).
3. The SBC plays a ringtone towards leg A while the REFER is taking place.
4. When Leg D rejects the call with a 480 "Temporarily not available" the SBC software is not correctly disabling the call context that is playing the tone and not correctly re-enabling the Leg A to Leg C call association.

Steps to Replicate: 

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

The code is modified to address the issue.

Workaround: Not available

Portfix SBX-114842: There is a Microsoft Teams Shared Line/Hold issue.

Impact: The SBC fails to send an ACK after mix of replace and refer Invites (Microsoft Teams Shared line/hold feature).

Root Cause:  The SBC fails to release a tone announcement after receiving a 200OK from the refer Invite.

Steps to Replicate: The steps can not be reproduced.

Properly release the tone resource.

Workaround: Disable the tone as an announcement.

Portfix SBX-114426: There is a standby SBC coredump 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 code responsible for adding a new configured IP Peer may write into freed memory.

Steps to Replicate: The root cause of this bug was found by code inspection. The problem could not be reproduced.

The code is modified to address the issue.

Workaround: None.

Portfix SBX-115061: Fraud Mitigation on the SBC requires a specific cause code response. 

Impact: The functionality works and a call is released with 480 Temporarily Unavailable. There is a regulatory requirement that a specific Cause Code should be released when a Fraud Call is blocked.

Root Cause: The ERE needs to have a new SEEDED script for call termination with results in the 607/608 status code being sent to the network.

Steps to Replicate: 

1. Configure the call routing profile with new scripts and run a call.
2. The ERE should send the script in policy response.
3. The SBC should play the announcement .

Two new scripts are seeded:

• RBBN_CALL_REJECT_217
• RBBN_CALL_REJECT_ANN217

Workaround: None

Portfix SBX-111620: During a T140 call there is one-way stream with a zero media port (NAPT media).

Impact: A one-way stream is observed with a zero media port when the RTCP NAPT learning is complete before the RTP NAPT learning.

Root Cause: 
When the RTCP NAPT learning is completed before the RTP NAPT learning for the T.140 stream, the RTP port is set to 0 instead of 5004. 5004 is required for the RTP NAPT learning to continue.
As the remote RTP port is set to 0, instead of 5004 for the T.140 stream, the RTP NAPT learning is disabled, resulting in one way media for the stream.

Steps to Replicate: 

1. Run a basic SIP to SIP call with multiple streams (Audio+T.140) and NAPT & RTCP enabled.
2. Send the RTCP packets from the far end before the RTP packets to ensure that the RTCP NAPT learning happens prior to the RTP NAPT learning.

In a multiple stream scenario, when the RTP Port is 0, set it to loop back port 5004.

NOTE: The issue is observed only when the NAPT is enabled on both sides.

Workaround: 

• Disable  the RTCP
  or
• Ensure endpoint sends the RTP before the RTCP.

PortFix SBX-115316: The upgrade is related to marker files that are not being removed even after a successful upgrade on the public cloud.

Impact: On a public cloud like Azure and AWS, a couple of marker files are created to indicate that a model update is needed after an upgrade. These marker files should be removed once the upgrade is completed, but are not.

Root Cause: . If a system is being upgraded to 9.x or later releases while on public cloud platforms, these marker files will still exist and can cause the system to go through a model update on every SBC application restart.

Steps to Replicate: 

1. Perform an upgrade.
2. Logs will show the model update being done on every restart.

The marker files are deleted correctly after an upgrade.

Workaround: Contact TAC through a SFDC ticket to ask for the procedure. It is not a normal activity and will require Linux shell access.

Portfix SBX-97435: During an LRBT scenario, the SBC is not processing a sendrecv in a SIP re-Invite message causing a one-way audio.

Impact: A Gateway to Gateway call scenario with a local ring back, causes a one way audio issue.

Root Cause: As part of enabling the media end to end, the SBC initiates a Re-INV with an SDP attribute as sendonly for which the UAC responds with receonly. This causes the SBC to start a new modify offer-answer cycle towards the Egress GW. 

Steps to Replicate: 

1. The UAC sends an INV to the UAS via GW1-GW2.
2. The UAS sends a 180 Ringing.
3. GW1 starts a tone play.
4. The UAS sends a 200 OK with a sendonly.
5. GW2 sends an ACK to UAS.
6. GW1 sends a 200 OK for INV.
7. The UAC sends an ACK.
8. GW sends a Re-INV with a sendonly.
9. The UAC sends a 200 OK with a recvonly.
10. The UAS sends a Re-INV with a sendrecv.

The code is modified to address the issue.

Workaround: None

Portfix SBX-115939: The SBC uses an incorrect branch parameter from the last transaction.

Impact: The SBC retransmits an ACK for 200OK with a different branch parameter from the  previous ACK.

Root Cause: Transactions occur before the retransmit ACK and overwrite the previous branch parameter transaction.

Steps to Replicate: 

1. Leg A calls leg B.
2. Leg B sends an ACK and reInvite.
3. The ACK drops the peer response 491 for reInvite.
4. The  SBC sends an ACK for 491.
5. The Peer sends a 200OK from the initial Invite.
6. The SBC sends an ACK.

Save the ACK branch parameter in a separate transaction to avoid being overwritten

Workaround: If a reInvite is due to a media lock down, then disable the media lock down, or use a reliable transport.

SBX-114393 | SBX-114801 | SBX-114802

Portfix SBX-114393: The TLS Session ID has all zeros on the new 9.2.2R3 code.

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

Root Cause: The code is removed in the latest releases.

Steps to Replicate: 

1. Execute the TLS Session Status command with active TLS calls on the SBC.
2. Session IDs will be printed with a zero instead of the valid Session IDs.

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

Workaround: None

Portfix SBX-113065: A Critical alarm is showing as Urgent under the "EMA > Monitoring > Alarm > Current Alarm."

Impact: A Critical alarm is showing as Urgent under the "EMA > Monitoring > Alarm > Current Alarm."

Root Cause: The screen text of a critical alarm appears as Urgent instead of Critical.

Steps to Replicate: 

1. Login to the EMA.  
2. Navigate to Monitoring > Alarm > Current Alarm.
3. Alarm Severity shows as  Urgent instead of Critical.

The code is modified to address the issue.

Workaround: None

Portfix SBX-116166: The SBC intermittently fails to handle a "Packet Too Big" event and sends an unfragmented packet to the gateway.

Impact: The IPv6 Path MTU Discovery does not work.

• The SBC uses the MTU of the outgoing network interface as the Path MTU.
• The SBC does not update IPv6 Path MTU properly even if a router in the path sends an "ICMPv6 Packet Too Big" message with a  smaller Path MTU value. The large IPv6 packets requiring fragmentation to fit the Path MTU from the SBC will not reach the SIP peer.

Root Cause: When performing an IPv6 route/fib lookup while updating the Path MTU from the "ICMPv6 Packet Too Big" message, it doesn't consider the ipInterfaceGroup and the  addressContext. This results in not updating the Path MTU with the proper route entry to the peer.

Steps to Replicate: 

1. The SBC sends IPv6 packets of 1500 bytes toward the SIP peer when a path to the peer has a smaller MTU (e.g. 1280 bytes).
2. A router with the smaller MTU sends an "ICMPv6 Packet Too Big" to the SBC.

The code is modified for handling "ICMPv6 Packet Too Big" messages by adding:

• ipInterfaceGroup
  and
• addressContext 

Workaround: Add subnet routes on packet interfaces to the peer.

Portfix SBX-114981: The Block Direction does not work when selecting a secondary trunk group with a SIP Parameter Based Action Profile.

Impact: The TG Block Direction feature is not applied on a newly selected Ingress TG. The new Ingress TG is selected by the SMM's storeIpTg or by using a sipParamBasedAction Profile.

Root Cause: The TG Block Direction feature is not applied on a newly selected Ingress TG due to a design issue.

Steps to Replicate: 

1. Create a SMM profile to select new a Ingress TG using sipParamBasedActionProfile.
2. Attach a SMM profile to the expected original ingress TG.
3. Enable a block direction feature on the expected new ingress TG.
4. Run a basic call, registration, or any non-invite scenario.
5. Once the new ingress TG  is selected using sipParamBasedActionProfile, The SBC should reject the INVITE or non-INVITE message with a 503.

The code is modified to address the issue.

Workaround: None.

PortFix SBX-115317: Error 0x6 Line 2932 File /sonus/p4/ws/release/sbx5000_V08.02.05R004/marlin/SIPSG/sipsgLibUtils.c

Impact: The following command does not work correctly after a switchover:

set oam accounting admin eventAcctMethods [eventRegister | eventSubscribe | eventMessage | eventPublish | eventRefer | eventOptions ] [enable | disable]

Root Cause: The accounting functionality for Out of Dialog messages uses a specific hash table that does not exist on the new active after a switchover. This hash table is not created on a Standby because it is not needed. But, it should be created when the standby becomes active.

Steps to Replicate:

1. Execute the following CLI command:
   set oam accounting admin eventAcctMethods eventOptions enable
2. Send a SIP OPTIONs message.
3. Options Ping get a 480 response.

The code is modified to create the necessary hash table after a switchover.

Workaround: Disable accounting for PUBLISH, MESSAGE, OPTIONS or NOTIFY using the command syntax below:

set oam accounting admin eventAcctMethods [eventRegister | eventSubscribe | eventMessage | eventPublish | eventRefer | eventOptions ] [enable | disable]

Portfix SBX-113280: An alarm is issued on the M-SBC. The M-SBC resets the VF after the user stops the Tshark.

Impact: The Tshark start/stop operations sporadically cause link failure events in theSWe.

Root Cause: A Link status of "link down" for DPDK API occurs if it finds the VF<>PF mailbox busy due to another activity In this case it is due to a multicast mac address programming that is triggered by the Tshark.

Steps to Replicate: 

1. Bring up a SWe port redundancy setup.
2. Configure the pkt0 and pkt1 interfaces with different VLAN's.
3. Run a script for a long duration (2 -3 days) which would start/stop the  Tshark continuously on a tagged interface.
4. Check that there is not a link down event reported.

The code is modified to address the issue.

Workaround: None.

PortFix SBX-111908: The Standby SBC has the same pkt0/pkt1 IPs as an Active SBC and is sending a response to the HFE.

Impact: In the Azure HFE, if a connection is created before implementing the routes for CUSTOM_ROUTE natvar, the HFE does not input the source IP correctly.

Root Cause: The connection tracking table in Linux caches the connection to go via the eth0 instead of what is set in the CUSTOM_ROUTE, which breaks the source NAT matching rules.

Steps to Replicate: 

1. Create an HFE2.0 set up with private endpoint in a subnet different from any of the HFE interfaces.

2. Set the CUSTOM_ROUTE natvar to route to this endpoint using eth1,e.g. 10.x.xx.x/xx_eth1.

3. During the startup, ensure that traffic is occurring between the SBC PKT1 and the private endpoint during HFE startup.

The code is modified to address the issue. 

Workaround: After starting up the HFE, run 'sudo conntrack -F conntrack', to refresh the connection tracking rules. This will need to be done after every reboot.

The RURI is populated with an INTL CC of a calling number to the egress carrier.

Impact: The country code in the RURI username is populated incorrectly. The first route fails and a second route is selected after a number translation. The second route has the Undo LNP flag checked in its IP signaling profile.

Root Cause: When a second or subsequent route is used, some of the number translation information from the first route is applied.

Steps to Replicate: 

1. The ingress SIP trunk has an enabled stiProfile assigned.
2. Make a SIP-SIP call with a PSX query.
3. The PSX does an LNP lookup to a SIP SCP which returns multiple routes.
4. The second route has the "Undo LNP" flag checked on its IP signaling profile.
5. When the SBC sends the INVITE on the first route, no response is received. This causes the second route to be selected.

The code is modified to address the issue.

Workaround: None.

The location of PAI CPC is not positioned consistently.

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

Root Cause: When a presentation is restricted, the code is checking that the "Disable 2806 compliance" configuration is enabled. It populates a CPC parameter in the PAI after the SIP hostname.

Steps to Replicate: 

1. Run a basic SBC and PSX configuration to allow SIP to SIP calls.
2. On a PSX egress IP signaling profile, the following commands need to 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 Id
   Egress IP Attributes > Privacy >Flags > Include Privacy
3. On the SBC ingress and egress TG’s, enable the cpcInterworkingForNNI, such as:
   set addressContext default zone ZONE2 sipTrunkGroup PCR5001_SBX_EXT signaling cpcInterworkingForNNI enabled
4. Send a basic INVITE from peer A to SBX ingress TG.
5. In addition to basic headers, the following should be included: 
   Privacy: id
   P-Asserted-Identity: "0363572050"<tel:+88888888888;cpc=ordinary>, "Anonymous"<sip:n363572050@username.xxxx.xx.xx>
6. Verify that the SBC sends an INVITE to egress.
7. The egress INVITE should include a PAI header with cpc=ordinary placed in the URI before the @<ip address>, such as: 
   P-Asserted-Identity: "Anonymous" <sip:363572050;cpc=ordinary@10.xx.x.xx:xxxx>, <tel:88888888888;cpc=ordinary>

The code is modified to address the issue.

Workaround: 

• If "Disable 2806 compliance" is set to "disabled", the issue is not present.
• If "Disable 2806 compliance" is enabled (as a requirement), there is no workaround.

The SBC-SOSBC-RTU license is displayed as 0 on the EMA.

Impact: The SBC-SOSBC-RTU license is applied to the SBC, but it's not displayed in the EMA/EMS License Manager.

Root Cause: A license with the feature name SBC-SOSBC-RTU is not considered.

Steps to Replicate: Not applicable

The code is modified to recognize the SBC-SOSBC-RTU license. 

Workaround: None

A TLS Session ID has all zeros on the new 9.2.2R3 code.

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

Root Cause: The code is removed in the latest releases.

Steps to Replicate: 

1. Execute a TLS Session Status command with active TLS calls on the SBC.
2. Session IDs are printed as a zero instead of as valid session IDs.

The code is modified to address the issue.

Workaround: None

Accounting Logs are not escaping the special characters in the calling name fields.

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

Root Cause: If a non-alpha numeric character is included in the calling name, the SBC is not escaping the character in the Accounting Record. This leads to an incorrect "called asserted identity" field.

Steps to Replicate: 

1. Make a simple SIP-SIP call and validate the CDR subfield 60.
2. The Called Asserted Identity displays the  name as "%XXX CUSTOMER RD%".
3. The Called Asserted Identity [sf:60] "CUSTOMER ROAD"
   NNI-Type [sf:61] <sip:+12345678912@162. xxx.yy.zzz;user=phone>.

The code is modified to address the issue.

Workaround: None

A Call fails with the NRM error "could not find a card for IP call."

Impact: Some calls start failing after a switchover and continue to fail until a manual switchover is performed.

Root Cause: No root cause found.  

The following log message is an indicator of this issue:

.SIPSG: sipsgSbyMsgProc.c (-863) 179922. UNRECOGNIZED message received on standby, message type=0x23D47, rcvIcm=0xF00E003E, txIcm=0xC0

Steps to Replicate: The steps cannot be reproduced.

The code is modified to gather more information to find a root cause and address the issue.

Workaround: This issue can be resolved by a manual switchover.

A Back to back SAM Process coredump occurs on the system.

Impact: A SAM Process coredumps while doing the OCSP queries when the SBC is under Denial-of-Service (DoS) attacks.

Root Cause: A Linux file descriptor value in an OCSP query is out of range for select() call, used by OpenSSL API, causing memory corruption.

Steps to Replicate: 

1. Modify a Sam Process source code to create several socket file descriptors to simulate a DoS condition.
2. Perform the OCSP queries for SIP-TLS sessions. 

Do not perform the OCSP query when the file descriptor value used in the OCSP is out of range for a select() call to prevent memory corruption.

Workaround: Disable the OCSP.

A User-to-User parameter is duplicated in a Refer-To header.

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

Root Cause: An interaction between the transparency of all the headers and a relay of the Refer-To header.

Steps to Replicate: 

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

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

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

A SAM Process coredump occurs on the server.

Impact: A SAM Process coredump occurs when an AOR entry is deleted.

Root Cause: When an AOR entry is deleted, the SBC starts a registration cache timer after saving an AOR in the cache. If the registration timer fails to start, an AOR cache entry is freed but the hash entry is not removed from the hash table. This results in a corrupted list in the hash table.

When a new hash entry is inserted into the hash table, the hash table logic tries to insert the new hash entry after the corrupted list. This results in a SAM coredump.

Steps to Replicate: 

1. Make a SIP-SIP with an ERE call setup.
2. Disable the "multipleContactsPerAor"
   set global signaling sipSigControls multipleContactsPerAor is disabled.
3. Disable "surrogateRegistration".
   set addressContext <addressContext_name> zone <zone_name> ipPeer <peer name> surrogateRegistration state is disabled.
4. Do a few SIP registrations and delete the entries.
5. Deletion of SIP Registration works without any issue.

The code is modified to remove the cache entry from the hash table before freeing up the complete cache RCB block.

Workaround: None

On the SBC SWe, there is a CPU Usage display error in the web page.

Impact: On the SBC SWe, the CPU Usage page on the EMA throws out an error indicating an invalid value for the row containing unused vCPUs.

Root Cause: When the number of vCPUs allocated to the SBC SWe VM are over-provisioned, some of the cores remain unused.

Since the core is unused, it's function type(oam/sig/media/xcode/thirdparty) is not defined, rendering the field with a null value. The EMA reads this information from the backend and parses the fields incorrectly.  Field values are unintentionally shifted towards the left, resulting in a corresponding field's validation error.

Steps to Replicate: 

1. reate an SBC SWe with an over-provisioned vCPU (depending on your traffic profile).
2. Navigate to Monitoring > Dashboard > CPU Usage.
   A pop-up window appears.
3. Observe the results.

In an SBC SWe with over-provisioned vCPUs, the unused vCPUs are explicitly defined as "unused" even on the EMA page's CPU usage tables.

Workaround: None.
This issue is not observed on an SBC SWe when none of the vCPUs allocated to the SBC SWe VM are left unused.

An SCM Process coredumps when accessing a null pointer.

Impact: An SCM coredump occurs when there is an attempt to dereference a NULL pointer.

Root Cause: This coredump occurs when there is an attempt to dereference a NULL pointer in code that is added. The race condition and coredump results from changes to the MOH for MS Teams after a call legPtr is accessed and the call leg is released.

Steps to Replicate: The steps cannot be reproduced. The bug is found by code inspection.

The code is modified to address the issue.

Workaround: None

A failover occurs on the SBC because of a SCM Process coredump.

Impact: An SCM coredump occurs 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, resulting in memory corruption.

Steps to Replicate: 

1. Make a call.  
2. Enter a hostName in the From header that is longer than 64 bytes.

The code is modified to address the issue.

Workaround: None

A bug is found in the CDR Viewer Sip Ladder Diagram message contents.

Impact: A Ladder diagram is not showing the full message. Different parts of a SIP message that should be shown as a single message instead multiple messages, are displayed in the ladder diagram

Root Cause: The implementation assumes that the different parts of a single message are logged in the TRC file in sequence one after the other. In some cases different parts of the SIP message are logged randomly, causing the implementation to break.

Steps to Replicate: 

1. Login to the EMA.
2. Enable the CDR Viewer and SIP Ladder.
3. Verify that all the parts of the SIP message are displayed as a single message in the ladder diagram.

The code is modified to address the issue.

Workaround: None

The Alarm History is not cleared in the EMA after clearing in the CLI.

Impact: The Alarm History is not cleared in the EMA after clearing in the CLI.

Root Cause: A cleared alarm list is deleted in the CDB and the postgres entries are not ignored, causing the UI to display the entries.

Steps to Replicate: 

1. From the SBC CLI run: show table alarms historyStatus.
2. A list of cleared alarms is displayed.
3. Clear the alarm history by using the Request Alarms Clear History.
4. In the EMA under section:  Monitoring > Dashboard > Alarms > Cleared Alarms. The list should be empty.

The code is modified to address the issue.

Workaround: None

The SRTP and the ENCRYPT "IN USE" counters leak for call flows with two transfers that use the INVITE with Replaces.

Impact: 

1. In a multiple call pick-up (multiple INVITE w/ Replaces) scenario, "IN USE" counters of the SRTP and the ENCRYPT license do not decrement after the call termination, which causes the counter to leak.
2. In a multiple call pick-up (multiple INVITE w/ Replaces) scenario, after the second call pick-up, the SBC-RTU "IN USE" counter decrements.

Root Cause: The logic for auditing the consultative refer calls does not work properly for a call pick-up. This logic creates one extra virtual leg for a second pick-up call, making a three virtual leg creation for two pick-up calls. This also results in a license adjustment. The licenseCall becomes 0 and the SBC-RTU "IN USE" decrements.
This also affects the ENCRYPT and the SRTP licenses when the "IN USE" counter does not reset after a call termination.

Steps to Replicate: 

1. Setup: Phonerlite (TLS/SRTP) - SBC - SIPp (UDP).
2. Leg A calls Leg B.
3. Leg C sends an INVITE with Replaces (Replace header contains the Call-ID, From, and To tags of Leg B) to replace Leg B. This makes the first call pick-up.
4. Once the first call pick-up completes, Leg B drops out of the call making Leg A - Leg C in the active call.
5. Leg D sends an INVITE with Replaces (the Replaces header contains the Call-ID, From, and To tags of Leg C) to replace Leg C. This makes the second call pick-up. The second pick-up call is established between Leg A - Leg D.
6. Observe that the SBC-RTU "IN USE" counter is reset to 0 after the second pickup is successful.
7. Use the licenseInfo CLI command.
8. Leg A disconnects the call by sending a SIP BYE.
9. The Call is terminated gracefully.
10. Observe that the ENCRYPT and the SRTP license "IN USE" counter does not decrement after the call termination.
11. Use the licenseInfo CLI command.

A new internal flag is introduced to identify a pick-up call. This flag is set for every pick-up call after a virtual call leg creation and license adjustment. A check for the same flag is added in the audit logic to avoid the audit logic for pick-up calls.

Workaround: None.

The SBC is intermittently stripping the last 'm=' line from the Egress Invite.

Impact: The SBC strips off the lines after the m =application line when present in the SDP of the incoming Invite, and at Egress the SBC does a DNS lookup.

Root Cause: There is a NULL termination after the m=application line, causing the SDP to truncate SDP after the m=application line.

Steps to Replicate: 

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

The code is modified to address the issue.

Workaround: Use the actual IP address in the IP peer, instead of the FQDN.

After an SBC switchover, the standby SBC is not recognized.

Impact: There is a PRS core dump in the XrmIPsecSACmdAdd() process.

Root Cause: There is a PRS core dump in the XrmIPsecSACmdAdd() process because the process is attempting to de-reference a NULL pointer. This is because the code is not handling an error condition correctly.

Steps to Replicate: The steps cannot be replicated. This is found by code inspection.

This code is modified to address the issue.

Workaround: None

There is an SBC Intermittent crash.

Impact: When multiple duplicate Diversion headers are received and the stiProfile is enabled and configured on the ingress trunk group, the SBC coredumps core.
The issue only happens if 6 or more Diversion headers are received but fewer than 5 of them are unique.

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

Steps to Replicate: 

1. Configure the stiProfile by enabling and assigning to the Ingress trunk group.
2. Send a SIP INVITE containing 6 Diversion headers, but only 2 of them are unique. 

The code is modified to address the issue.

Workaround: None.

The SBC disconnects the call when offering a LRBT using the first codec in 180 and the received Egress 200 contains a different codec set.

Impact: The SBC internally tears down the call if the Egress peer answers with a different first codec than in the 180.

Root Cause: The SBC auto answers using the first codec back to Ingress. The SBC cannot reInvite when changed by the Egress because the SBC is not ready to receive the reInvite/Update.

Steps to Replicate: 

1. Enable the LRBT with no transcode support.
2. The Ingress is 0 18.
3. The Egress is 0 18.
4. The Egress responds with a 180, and a trigger tone.
5. The Egress sends a 180 with a 0 on the Ingress.
6. The Egress then sends a 200 with a 18.
7. The Call is cleared by the SBC.

The code is modified to address the issue.

Workaround: None

Video calls are being disconnected. A call transfer is failing when using both audio and video.

Impact: Audio and Video calls are disconnected after a REFER.

Root Cause: This issue happens when:

1. Leg A is an Audio and Video Call.
2. Leg B rejects the Video by putting the media Port to "Zero."
3. Then Leg B REFERs Leg C to Leg A, without putting Leg A on Hold.
4. The SBC offers a Leg with both Audio and Video.
5. Leg C also answers back with both Audio and Video.
6. The SBC is not able to map the video legs after the Refer.

Steps to Replicate: 

1. Make  an Audio and Video Call from Leg A to Leg B.
2. Reject the Video from Leg B.
3. Send a REFER from Leg B, referring Leg C to Leg A.
4. From Leg C, answer with both Audio and Video,

The code is modified so that the SBC can now map to the correct video leg post REFER.

Workaround: None

The SBC sends the wrong payload type.

Impact: The Egress GW sends the wrong payload in a 200OK response for an incoming Re-INVITE from the Egress peer in a GW-GW scenario.

Root Cause: The issue is observed when the "Lockdown Preferred Codec" is enabled at the Ingress IPSP (at ingress GW). When this flag is enabled, the PSP is updated with selected codec containing an incorrect payload type (rx/tx as 0x00/00). This results in the Ingress SG sending a modified answer to the NRMA with an incorrect payload type

Steps to Replicate: 

1. In a GW-GW call, GW2 receives a Re-INVITE with a G711A from the Egress peer.
2. The Ingress GW auto answers.
3. "Minimize Relaying Of Media Changes From Other Call leg" and "Lockdown Preferred Codec" is enabled in the Ingress IPSP of GW1.
4. GW2 sends a 200OK response with a G711A  and correct payload type 8.

The code is modified to address the issue.

Workaround: None

The SWe has unexpected switchovers.

Impact: A SCM core dump occurs while the SIPSG is processing a "401 Unauthorized".

Root Cause: The code is attempting to dereference a NULL pointer and send an UNSUBSCRIBE while processing the "401 Unauthorized" message.

Steps to Replicate: The steps cannot be reproduced.

The code is modified to prevent an attempt to dereference a NULL pointer.

Workaround: None

A SCM core dump may occur when using the SIPREC.

Impact: A SCM core dump may occur when using the SIPREC.

Root Cause: Memory corruption is caused by a double MemFree() in the SIPREC code.

Steps to Replicate: The steps cannot be reproduced. This bug is found by code inspection.

The code is modified to address the issue.

Workaround: None.

A core dump occurs on the SBC.

Impact: During a P2P call scenario, a codec change from the PCMA to the PCMU is requested via a reInvite for Leg B. The application sends an audio modify request for both Leg A and Leg B. The DSP crashes for codecs like SILK and OPUS.

Root Cause: The merging of an audio modify request for Leg A and Leg B on the application end and the lack of a check in the DSP code for a modify request on Leg A to the same codec causes a core dump.

Steps to Replicate: 

1. Run a G711<=>OPUS call beginning the call as a PCMU.
2. Send a re-invite on the G711 leg to change the call to a PCMA.
3. This triggers a modify on both the legs, with the modifyAudioCodec flag set.

The code is modified to address the issue.

Workaround: None

No routes are displayed for the EMA configuration > System Provisioning > Routing > Routes screen function.

Impact: The function does not work in the EMA configuration > System Provisioning > Routing > Routes.

Root Cause: An old browser version does not apply the replaceAll function. and the "replaceAll is not a function" exception is activated.

Steps to Replicate: The steps cannot be replicated.

The code is modified to ensure that the replaceAll functionality is working.

Workaround: None

The SBC memory utilization goes up under the load with all the IP Redirect calls and the SMM variableScope rule.

Impact: An IP Redirect call and a SMM variableScope may result in a memory leak.

Root Cause: When the SBC redirects a call to Leg C, the SBC does not release an SMM variableScope resource that is created/stored for Leg B.

Steps to Replicate: 

1. Configure an SMM variableScope rule on an output message, Egress (Leg B and Leg C).
2. Leg A calls Leg B.
3. Leg B redirects to Leg C.
4. Memory will increase slowly over time.

The code is modified to address the issue.

Workaround: Remove the SMM rule

The DNS recovery packet count of a DSCP with a value of "0."

Impact: The DNS probe packet's are sent from the SBC with a DSCP value of 0.

Root Cause: The configured DSCP value's are not set for the DNS probe keepalive packets .

Steps to Replicate: 

1. Configure the DNS server with a DSCP value.
2. The DNS server blacklisting is enabled.
3. The DNS query is configured to the DNS server.
4. The DNS server should be down during this process.
5. The configured DNS server is blacklisted and sending a DNS probe packet towards the DNS server with a configured DSCP value.

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

Workaround: None

Syncing CallData for gcid 0x1E0E4D36 failed: Available buffer (size 27204) exhausted.

Impact: A LSWU fails when Direct Media is enabled and the SBC is processing calls that have more than four media streams.

Root Cause: A LSWU fails because an error occurred when syncing an SIP call block.

SYNC of SIPSG Call Blocks is failing because an individual Call Block does not fit in the 64K buffer that is allocated for mirroring a Call Block. When the mirrored data for a single call does not fit into the buffer, the code currently stops syncing the call blocks.

Steps to Replicate: Enable Direct Media and send a call with more than four Media Streams.

Look for these messages in the logs:

MAJOR .SIPSG: sipsgRedund.c (-2424) 2530. Ingress: Mirroring CallData for GCID 0x443B48 failed: Available buffer space (msg size=64172) exhausted?
AND
MAJOR .EVLOG: SYS ERR - Error 0x3a3c Line 2426 File /sonus/p4/ws/release/release.we.sbx5000_V08.02.03A012/marlin/SIPSG/sipsgRedund.c.

Then attempt and upgrade and look for this message in the logs:
MAJOR .SIPSG: sipsgRedund.c (-1613) 1967147514. Syncing CallData for gcid 0x1E0E4D36 failed: Available buffer (size 27204) exhausted

The code is modified so that the entire SYNC does not fail if we cannot mirror a single Call Block. Instead, the original Call Block moves onto the next available Call Block and continues the SYNC.

Workaround: Disable Direct Media.

Node A failed to take over after node B had issues with hard disk.

Impact: The trap was not generated for HardDisk fault on the SBC.

Root Cause: Although the trap was getting generated for some harddisk/FS errors, a new error with 'failed command: FLUSH CACHE EXT' was being considered when generating a trap.

Steps to Replicate: The steps cannot be reproduced. 

The code is modified to address the issue.

Workaround: None.

A LSWU through the EMA GUI is stuck at post upgrade check and did not continue upgrading to the active EMA.

Impact: If the upgrade is in progress when the daily cronjobs run, it may cause the upgrade to stop.

Root Cause: As part of the log rotation, Apache/Platform Manager logs gets rotated and apache gets signal HUP and restarts. This causes the upgrade script to terminate because the parent(apache) is restarted.

Steps to Replicate: Install and upgrade from a pre 9.2.4 to 9.2.4

The code is modified to skip apache log rotation if the upgrade is in progress and to use nohup with an upgrade and revert scripts.

Workaround: Restart the upgrade or revert and retry upgrade.

A SCM Process core dump occurred on the SBC server.

Impact: The SCM Process cored. 

Root Cause: The SCM Process has cored because of an attempt to de-reference a NULL pointer.

Steps to Replicate: The steps cannot be reproduced.

The code is modified to check the value of the pointer before accessing it.

Workaround: There is no known workaround.

The config Export is failing because of the DM/PM Rule.

Impact: The config export is failing due to a confd error occurring while reading a DM/PM Rule.

Root Cause: The subRule being exported had a subRule type of uri. However, the export reads all of data for all subRule types, and the data in the digitStringManipulation->replacement->type was 2, which is an invalid value. This value is retrieved from the postgres database table pm_rule, which stores the replace->type value from the uri subrule as the invalid value 2.

Steps to Replicate: 

1. Create a digitParameterHandling dmPmRule with a subRule type of uri.
2. Set the uriParameterManipulation->userInfoManipulation->replacement->type field to noChange.
3. Export the configuration through the EMA.

The code is modified when the digitStringManipulation container is being read, if the replacement->type value is 2, it is set to 0.

Workaround: Before exporting, change all dmPmRules with a subRule type of uri to set the uriParameterManipulation->userInfoManipulation->replacement->type field to constant and then do the export. Change the value back after the export.

An SIP.Instance parameter is missing from Contact Header for De-Registration Message generated by the SBC locally.

Impact: When the SBC generate the unregister message to registrar, the +sip.instance and reg-id parameters are missing in Contact header.

Root Cause: The root cause was missing functionality.

Steps to Replicate: 

1. Enable transparency contact header.
2. The Iad register to registrar where contact header has +sip.instance and reg-id.
3. The Iad did not send refresh in time trigger SBC to send unregister to registrar.

The code is modified to address the issue.

Workaround: None.

A restart with a Comp_SAM Process Coredump.

Impact: Memory corruption causes a SAM Process coredump when processing a GW-GW message.

Root Cause: Memory corruption causes a SAM Process coredump when processing a GW-GW message. Code doesn't allocate enough memory for an outgoing message. When the data is copied into the message, the code writes past the end of the allocated buffer because there isn't enough space in the buffer.

Steps to Replicate: The steps cannot be replicated. The root cause is found by code inspection.

The code is modified to allocate enough space for the outgoing message.

Workaround: None

The SBC is failing to come up with a "cps is not initialized:failed" message after a shut down.

Impact: The Virtual SBC fails to startup due to a missing file link for an OS binary.

Root Cause: There is a missing OS level soft link that is required for the SBC startup code. The OS level soft link may have been lost as a result of multiple reboots while the SBC is trying to startup in a virtual deployment.

Steps to Replicate: The steps cannot be replicated.

The code is modified to address the issue.

Workaround: 

1. The soft link can be manually created:
   ln -s /bin/kmod /sbin/insmod
2. Then the instance can be rebooted.

An Announcement Package Element cannot be deleted.

Impact: An element within an announcement package cannot be deleted.

Root Cause: The code for handling the announcement package element Delete command is incorrect.

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

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

The code is modified to address the issue.

Workaround: The announcement package can be deleted and then re-created without the required element.

In the EMA GUI, a Destination National is not showing "+" when it is configured in a Route through the EMA.

Impact: In the EMA GUI, a Destination National is not showing the plus symbol when it is configured in a Route through the EMA.

Root Cause: In the frontend, symbols like the "+"are replaced with a space before sending to the backend.

Steps to Replicate: None

The code is modified to address the issue.

Workaround: Replace the "+" with "%2B" using the replace function. The plus symbol will appear in the EMA GUI.

An SBC 7000 memory leak in CE_2N_Comp_ScmProcess_x processes occured.

Impact: An SCM memory leak can occur when processing the Contact Headers if the honorEmbeddedHeadersin3xx flag is enabled in the ipSignaling Profile.

"set profiles signaling ipSignalingProfile <SIP profile name> egressIpAttributes redirect flags honorEmbeddedHeadersin3xx"

This leak will not always happen when this flag is enabled. There are several other conditions that must be met in order to expose this leak.

This leak may also exposed by enabling the flag "includeEmbeddedPAIheaderInRedirectedInvite" in the ipSignalingProfile.

Root Cause: The leak is caused by a missing call to the MemFree().

Steps to Replicate: The steps cannot be replicated. The root cause is found by code inspection.

The code is modified to ensure that the internal structure is always freed.

Workaround: Disable the following flags in the IPSP:

• honorEmbeddedHeadersin3xx
• includeEmbeddedPAIheaderInRedirectedInvite

Unable to login to the HFE_PKT1 in Azure.

Impact: The HFE_AZ.sh script fails on the HFE PKT1 in Azure when a public IP address is attached on the mgmt (eth1) interface.

Root Cause: The repository fails to install the required utilities for Linux and fails to create a temporary default route through the eth1.

Steps to Replicate: 

1. Create the HFE PKT1 with a public IP on the eth1.
2. Verify that the HFE_PKT1 successfully comes up and does not have error logs in the /opt/HFE/log/HFE_conf.log.

The code is modified to add the default route through eth1.

Workaround: 

1. Create an HFE without a public address.
2. Attach a public address after the HFE instance configures.

Editing a route with DN using '@ 'and '&' characters is duplicating the same route.

Impact: Using '@' and '&' characters in the DN field is duplicating the same route.

Root Cause: A few special characters were not decoded while editing and as a result, a route has been duplicated.

Steps to Replicate: 

1. Log in to the EMA.
2. Navigate to Routing and click the Route tab.
3. Create a route with & and @ in Destination National.
4. Edit the same and change the Routing label.

The code is modified to address the issue.

Workaround: No workaround.

The data_type properties fields should not have a "dot" in the identifier.

Impact: The data_type properties fields should not have a "dot" in the identifier.

Root Cause: MongoDb uses "dot" notation to locate fields within structures. When the NVFO posts the VNFD through the VNFM API, MongoDb incorrctly uses the identifier as a field name, which causes MongoDb to throw an exception.

Steps to Replicate: Run VNFM, NFVO and HPE Orchestration, and check communication with the EMS.

The code is modified so the "dot" in the "SBC:EMSPRIVNODEPARMS.cluster_id" is replaced with "hyphen" . The new parameter is listed as  "SBC:EMSPRIVNODEPARMS-cluster_id".

Workaround: None.

Discrepancy between ‘View CLI’ from GUI and the SBC CLI output.

Impact: If you are viewing the CLI version of the content, the GUI stops displaying the CLI when it hits the ‘type sdpContent’ operation. 

Root Cause: The CLIRules.xml file were not updated with latest changes in in the CLI.

Steps to Replicate: Check CLI commands in CLI is same as commands in UI after selecting the view CLI.

The code is modified to address the issue.

Workaround: None.

There is no planned cluster switchover.

Impact: The SCM process coredumps while comparing codec information.

Root Cause: In a race condition while comparing codec information, the SCM process is dereferencing a null pointer that resulted in a coredump.

Steps to Replicate: The steps cannot be reproduced.

The code is modified to verify that the pointer is not null before dereferencing it to avoid the coredump.

Workaround: None.

PortFix SBX-115897: The SBC sends one of the SIP NOTIFY messages with Event: Dialog body back to the registrar instead of relaying it to the subscriber.

Impact: Back-to-Back NOTIFY messagesfrom the registrar with dialog event (DialogInfo data) that requires an internal query across distributed ScmProcesses may cause the SBC to send the NOTIFY relay back to the registrar.

Root Cause: While doing an off board query (distributed lookup in the SBC), the SBC received a message from IAD and relays to Registrar. After an off board query, the SBC is using the same direction from IAD to registrar for relaying the next Notify

Steps to Replicate: A subscribe to registrar, registrar sends multiple back-to-back Notify (around 50ms delay) with dialog event to A.

The code is modified to save the direction of relay before off board query, and restore after off board query reply and using that direction for relaying subsequent messages.

Workaround: There is no workaround.

PortFix SBX-111461: The SBC plays LRBT using PCMU when negotiations occurred with AMRWB in a LM call.

Impact: The tone played is with old negotiated codec instead of the codec selected by ingress endpoint in Prack. The issue is seen only when multiple codecs are sent in late media offer in 180 with sendSbcSupportedCodecsForLateMediaReinvite flag enabled.

Root Cause: The initial DSP resource allocated only has capability to play tone with G711. After AMRWB is selected as the new codec for tone play in Prack, the old DSP resource is found unusable and new DSP resource is allocated with capability to play tone with the new selected codec. However, though a new compatible DSP is allocated, the old DSP resource/XPAD is incorrectly retained in the resource chain and as a result, the tone is with the old codec.

Steps to Replicate: 

1. Enable sendSbcSupportedCodecsForLateMediaReinvite in ingress TG IPSP and with multiple codecs supported in PSP, make a late media call.
2. Prack from ingress endpoint has a codec different from the first codec in late media offer sent by the SBC with multiple codecs in 180.
3. Check tone is with the selected codec in Prack.

The code is modified so that when Prack is received with SDP in LM scenarios, SWEA events are issued from PC-FSM to play tone.

The ASG has a sequence of events like NRMA allocate reply/activate reply/deactivate reply/dealloc reply that drives these SWEA events to DSP.

Workaround: No workaround.

PortFix SBX-116164: Autonomous fail over of the SBC 5210.

Impact: There was an SCM core while processing Register request during an IMS intercept.

Root Cause: The register looks like a retransmission and the SBC has found an existing TCB for the register. While accessing the Apphandle of TCB (which points to RCB data) the SBC cored. This is due to the RCB is not being present and address is reused for something else.

Steps to Replicate: 

1. Have an IMS LI setup ready.
2. Make a complete Registration. (Reg,401,Reg,200).
3. Delete the Registration by a De-Reg from client.
4. Retransmit the same De-reg from client (we can have some pause of say 10 secs) 

Without this fix, the SCM cores when the SBC tries to access the deleted RCB.

As an additional test, alter the fourth step to, instead of De-reg, try sending the old register that received an 200 OK [branch, call-id, cseq should be exactly the same].

The code is modified so once a response is sent to a register, IMS intercepts the message. After an interception, reset the correlationTag (i.e, AppHandle) to NULL.

Workaround: None.

PortFix SBX-114151: Pre-upgrade BMC version check issues

Impact: During pre-upgrade checks, an invalid BMC version error message is displayed and reports pre-upgrade checks as failure.

Root Cause: The BMC version check is run during pre-upgrade checks, and reports a failure for an invalid BMC version.

Steps to Replicate: Run pre-upgrade checks and ensure BMC version check error is displayed as a warning and not a failure.

The code is modified to make it a warning rather than a failure for pre-upgrade checks.

Workaround: None.

PortFix SBX-113966: RCBs are not synced to the STANDBY.

Impact: Some Registrations were not being mirrored to the STANDBY SBC due to buffer not large enough for amount of info obtained from the messaging.

Root Cause: If/Then/Else statement was modified to check if certain info (Child AOR) present, which allocates a LARGE buffer all the time now.

Steps to Replicate: 

1. Bring up an HA setup.
2. Run a basic Registration.
3. Perform a switchover.

Expected Results:
After a switchover, all the RCBs should be present in new active box.

Actual Results:
Not all RCBs are not synced to the SBC box.
Log message being seen:
.SIPSG: sipsgRedund.c (7734) 1621. SipsgRedundLoadRegAgentData: insufficient Buffer Size(15972) Required Size is (20195)

The code is modified to address the issue.

Workaround: None.

PortFix SBX-113840: Reset the fields in the nrmacalleg.

Impact: Certain fields in a data structure are not reset to default values during a call tear down.

Root Cause: Due to performance reasons, one of the sub-system re-uses this memory block again for new calls. Since, the fields from previous call were not reset during tear down, these fields continue to be set even for the new call and could result in undesired behavior.

Steps to Replicate: The steps cannot be reproduced. 

The code is modified to correctly reset missing fields during call tear down.

Workaround: None.

PortFix SBX-109315: There are SBC sync issues. 

Impact: There is no event/alarm to indicate a Postgres transition failure during a switchover.

Root Cause: The Postgres Transition failed within the timeout period, but the switchover continued. Subsequently, the SSDB became active, but failed within the timeout duration (20 seconds). As a result, the SSDB became unrecognizable due to a missing replication slot.

Steps to Replicate: Return a non-zero value from WaitActive function in startPGDB.sh to simulate Postgres transition failure. Attempt a switchover. Check event logs and startPGDB.log.

The code is modified to indicate a Postgres transition failure during switchover.

Workaround: None.

PortFix SBX-115243L The Automatic AD Sync is not completing.

Impact: The Automatic AD Sync is not completing.

Root Cause: During the change from Daylight Savings Time in the Fall, the addMinsToTime routine returns a time that is greater than the passed-in time. Consequentially, the code loops calling addMinsToTime expecting the time returned by addMinsToTime to be greater than the current time.

Steps to Replicate: 

1. Configure AD sync.
2. Set the time to 1:00 AM on the day of the current year where daylight saving time ends.
3. After 2:00 AM on that day, turn on info level logging.
4. Observed in the debug logs that the message:
   DAP_CONFIG: Performing Sync Interval AD Sync Success appears.

The code is modified to return a time greater than the passed-in time when switching from Daylight Saving Time.

Workaround: None.

PortFix SBX-110756: Wrong behavior with sipAdaptiveTransparencyProfile enabled.

Impact: When the SipAdaptiveTransparencyProfile was enabled and the SBC received 200 OK with SDP, it was sending ACK without SDP in late media scenario cases.

Root Cause: The SDP was not being added in ACK in late media cases.

Steps to Replicate: The following are the test cases used in the call flow:

1. Send a 200OK for re-INVITE from EGRESS PEER without SDP.
2. Send a 200OK for re-INVITE from EGRESS PEER with SDP but changed CODEC.
3. Send a 200OK for re-INVITE from EGRESS PEER with SDP.
4. Send a 4xx (for re-INVITE) from EGRESS PEER.

The code is modified to add SDP in ACK for late media cases.

Workaround: None.

PortFix SBX-108609: The SBC failed to send telephone-event when payload type number overlaps with configured in PSP for any codec.

Impact: The SBC fails to send 16,000 2833 payload type in outgoing INVITE when the 16,000 PT value received from ingress conflicts with the configured PT value for one of the codecs in egress route PSP.

Root Cause: The SBC failed to detect and resolve the conflict between 16,000 DTMF PT and egress route codec PT which resulted in the SBC dropping the 16,000 PT in outgoing INVITE.

Steps to Replicate: 

Configuration:

1. Enable honorSdpClockRate TG flag.
2. Disable different2833palyloadtype flag.
3. Configure multiple codecs including EVRCB0(103) in Egress Route-PSP.

To re-create the issue:

1. Ingress offer received by the SBC:
   m=audio 48820 RTP/AVP 102 0 103 105 97 8
   102 AMR-WB/16000 (b/w efficient / open mode-set)
   0 PCMU/8000
   103 telephone-event/16000
   105 telephone-event/8000
   97 AMR/8000 (b/w efficient / open mode-set)
   8 PCMA/8000
2. Egress offer sent by the SBC on the egress

m=audio 5096 RTP/AVP 102 97 0 110 101 107 103 98 96 105
102 AMR-WB/16000 (b/w efficient, mode-set=0,1,2)
97 AMR/8000 (b/w efficient / open mode-set)
0 PCMU/8000
110 AMR-WB/16000 (octet-align, mode-set=0,1,2)
101 AMR/8000 b/w efficient / open mode-set)
107 EVRCB/8000
103 EVRCB0/8000
98 EVRC/8000
96 EVRC0/8000
105 telephone-event/8000

Test Result without a fix: The SBC chooses to follow egress PSP configuration, which means it drops the telephone-event/16000 payload type.

The code is modified to prefer the pass-through DTMF PT value over the route configured codec PT by extending the PT conflict resolution to all the dynamic codecs.

Workaround: As a workaround, the conflicted PT value can be modified at egress Route PSP.

Portfix SBX-11469: "Challenge-SMM" is not added in the NOTIFY to the Ingress side of the SBC.

Impact: Challenge SUBSCRIBE is not processed when it does not contain a to-tag.

Root Cause: When a challenge SUBSCRIBE comes without a to-tag, we are unable to find RelayCb, creating new RelayCb and processing as a new request.

Steps to Replicate: 

1. Send a SUBSCRIBE from the UAC.
2. Send a challenge SUBSCRIBE without a to-tag.

In DBG logs, we can see there will be two relayCbs will be creating for the same SUBSCRIBE flow.

The code is modified to address the issue. 

Workaround: Send a challenge SUBSCRIBE with the received to-tag.

PortFix SBX-114019: The DBG logs are 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 attempts to send 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 INFO level.

Workaround: None.

PortFix SBX-113524: The SBC is not forwarding the received 200 OK and fails the call.

Impact: When using a GW-GW for direct media calls between signaling-only SBCs, the 200 OK is not being passed through and the call fails.

Root Cause: The code is unable to process the outgoing 200 OK because it cannot find any local IP information.

Steps to Replicate: Make a direct media call between two signaling-only SBCs with the following control enabled.
set global signaling sigOnlyMode sigOnlyModeValue global

If the sigOnlyMode flag is set to global, copy the local IP information.

Workaround: Disable the following control:

set global signaling sigOnlyMode sigOnlyModeValue off

PortFix SBX-111357: Cleared Alarms functionality is not working properly in the EMA.

Impact: Cleared alarms are not listed in "Cleared Alarms" screen under Monitoring > Alarms in the EMA.

Root Cause: Cleared Alarms screen combines alarms from both the CDB and Postgres. However, there was a fix made for a customer issue related to an alarm in 9.2.2, resulting in ignored alarms in the CDB.

Steps to Replicate: 

1. Login to EMA. Generate an alarm by disabling PSX_LOCAL_SERVER.
2. Navigate to Monitoring > Alarms > Current Alarms. Alarm will appear in the Current Alarms screen.
3. Clear the alarm by enabling PSX_LOCAL_SERVER.
4. Navigate to Monitoring > Alarms > Cleared Alarms. Alarm cleared will appear

The code is modified to retrieve the alarms from CDB and return them to UI for display purpose.

Workaround: No workaround.

PortFix SBX-114303: Customer PSTN is incorrectly listed as Busy.

Impact: The SBC attempts to map non-E164 display Name of a p-asserted-Identity TEL to generic address for called user.

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

Steps to Replicate: 

1. Run the following configuration:
   sipTrunkGroup IAD signaling callingPalingParty enabled
   Incoming msg has:
   P-Asserted-Identity: "12345 test user " <tel:+18038830789;rn=214960>, "12345 test user" <sip:+18038830789;rn=214960@test.com>
2. Use the outgoing INVITE
   From, contact userpart is 12345

The code is modified to address the issue.

Workaround: Use the SMM to delete incoming display name in pai(tel) header. For an out going INVITE, add it back if pai is config transparency.

Portfix SBX-111984: The SBC box is not coming up with the latest ASAN build.

Impact: The SBC box is not starting up in ASAN build. The SBC code that is used to generate traps was accessing memory after it is freed while processing traps that contained an IP address parameter.

Root Cause: The IP parameter passed to confd as part of the trap information was stored in a location that was freed before the confd processed the trap API call.

Steps to Replicate: 

1. Start up the SBC with an ASAN build.
2. Ensure that the SBC comes up.
3. In non-ASAN builds, this does not prevent the SBC from starting up although it could be accessing previously freed memory.

Store the IP parameter in a location that is not freed before the call was made to send the trap.

Workaround: None.

Portfix SBX-111773: Coverity Issues in SIPSG - Cause Map CPC - SIP

Impact: In the SipSgDiscReasonMapCpcToSip, the API pointer is checked against a NULL pointer but then is dereferenced again.

Root Cause: The Pointer validation was missing for a particular flow, which led to invalid memory access.

Steps to Replicate: 

1. Make a A-B Normal call.
2. Send 200 OK from User B.
3. Send ACK towards User B.
4. Send BYE from A and terminate the call.

The code is modified to avoid unwanted flow to get executed.

Workaround: None.

PortFix SBX-114110: A call from the child AOR fails after a switchover.

Impact: A user is registered on the UDP and INVITE comes in (different port) on the TCP fails with a 403 message. Original bug was fixed in the 8.2.6 release, but the same problem is seen after a switchover. This additional fix is related to the RCB (registration control block) mirrored to the standby.

Root Cause: Once the maskportforRcb flag is enabled, a parent RCB is found but the child RCB is not. Mask port and mask IP were not considered during child creation. This additional fix mirrors the child info correctly.

Steps to Replicate: 

1. Enable the maskportforRcb Flag and on ingress side set require registration to required.
2. Send register and receive a 200 OK with p-Associated URI (To create child RCB) on UDP.
3. Send an INVITE with child user on TCP without specifying the port.
4. Verify that the RCB is found and INVITE is routed properly.

Update the child information correctly based on the masking flags, then mirror to standby.

Workaround: Not available.

PortFix SBX-115151: Addressing log4j vulnerability - CVE-2019-17571 in 10.x.

Impact: Addressing the Log4j vulnerability reported in CVE-2019-17571, CVE-2021-45105 and CVE-2021-44832.

Root Cause: CVE-2019-17571 is reported in log4j 1.2 up to 1.2.17
CVE-2021-45105 and CVE-2021-44832 are reported against log4j 2 versions 2.16 and prior.

Steps to Replicate: The steps cannot be replicated. 

The code is modified so the Log4j is 2.17.1 to resolve all the listed CVE vulnerabilities.

Workaround: None.

PortFix SBX-111077: The Power LED is OFF instead of AMBER when the BMC is ON.

Impact: The SBC 51xx/52xx front panel power LED is off, when it should be AMBER. 

Root Cause: The power LED is set to off when the host is powered off.

Steps to Replicate: Power off the host and check the power LED status.

Setting power led to amber after power off host.

Workaround: None. 

PortFix SBX-115320: Compressed CDR filename should use a readable timestamp.

Impact: The filename for compressed CDR filenames does not contain a human readable timestamp.

Root Cause: The timestamp contained in the filename is the number of seconds since the unix epoch time.

Steps to Replicate: Configure the SBC to write out compressed CDRs: 
set oam eventLog typeAdmin acct compressionSupport only

Rollover the accounting log twice
request oam eventLog typeAdmin acct rolloverLogNow
request oam eventLog typeAdmin acct rolloverLogNow

Verify that the timestamp in .ACT.gz file in the log file directory has a timestamp of the form: yyyymmddhhmmss

The code is modified so the file name form is now yyyymmddhhmmss
Ex: 20220118125936
18th January 2022 12:59:36
The hours are in 24 hour format

On a Nto1 system, the filename is of the form:

<Actual Server Name>_yyyymmddhhmmss_<SequenceNumber>.ACT.gz
The Actual Server Name can be viewed with the cli command
show table system serverAdmin <Server Name> actualCeName

Workaround: The timestamp in the logs can be converted to a human reading form with the linux command
date -d@<linux style timestamp>

PortFix SBX-112867: The SBC is monitoring for RTP inactivity when a call is on hold.

Impact: The SBC is reporting media inactivity immediately after a call un-hold. The configured timeout value is not being reported after an un-hold when media is not present.

Root Cause: With a call un-hold, the SBC NP API handling inactivity detection restart timestamp is not being updated, and it used old timestamp, reporting the inactivity notification earlier than expected.

Steps to Replicate: With inactivity detections enabled, make a call, put the call on hold for the configured threshold, and observe the results after call un-hold without sending media.

The code is modified to report the inactivity after a configured interval as expected.

Workaround: Inactivity detections can be disabled, or action can be changed from disconnecting the calls in this scenarios.

PortFix SBX-115576: Hitting restart limit during software upgrade leaves the model locked.

Impact: AMF model remains locked after an update.

Root Cause: System startup failure results in soft restart limit being hit, stopping the AMF model update process.

Steps to Replicate: Model update marker needs to be in place, and then repeatedly kill the service after startup but prior to five minutes passing. On the 6th attempt to restart, the soft restart limit will be hit and the service will not attempt restart and the model will remain unlocked.

The code is modified to prevent killing the AMF model update process.

Workaround: Fix the instability issue causing the system to repeatedly crash and restart.

PortFix SBX-112162: [ASAN]: AddressSanitizer: unknown-crash on address 0x7f0f40a9d280 at pc 0x5640ea4b71de bp 0x7f0f40a78700 sp 0x7f0f40a786f8 in SipsGetSmmProfileForDlgScopehashUpdate.

Impact: The ASAN reported "runtime error" error for an enum.

Root Cause: The load value was exceeding the defined enum value.

Steps to Replicate: Run the ANSI-88 ISUP INVITE-CANCEL SIP-I codenomicon suite.

The code is modified to add checks to ensure that we do not exceed the defined value.

Workaround: None.

PortFix SBX-115908: Dialer SBC - media forking/call recording and high memory usage

Impact: There are call failures due to a memory leak in NICE Recording scenarios.

Root Cause: The memory leak is caused by a bug in the code that handles mirrored Recorder Call Blocks on the Standby.

The Recorder Call Block isn't cleaned up on the Standby until the call goes down. If a second recorder session is started while a call is still up, some of the information about the first Recorder session will be overwritten. This prevents the first Recorder Call Block from ever being freed.

When the standby transitions to active as the result of a switchover, these leaked Recorder Call Blocks are carried over to the active because the information needed to initiate the cleanup is still missing.

Calls are rejected after surpassing the 55,000 call block per SCM process limit. This limits the number of calls that SCM can process to 55,000 minus the number of leaked call blocks.

Steps to Replicate: 

1. Establish a scenario in which NICE server starts/stops multiple recording sessions for each call.

2. Monitor memory on the Standby to see if is growing.

The code is modified to handle mirrored Recorder Call Blocks on the Standby. When a second Recorder Call Block is received on the Standby, the first Recorder Call Block is freed.

Workaround: Prevent the NICE server from starting multiple recording sessions for the same call.

PortFix SBX-114833: Extreme congestion causes blocked end points.

Impact: Extreme congestion causes end points to become blocked due to a mishap in ARS (address reachability service) handling and does not recover automatically.

Root Cause: The ARS state machine does not process some unexpected internal events which leads to it not broadcasting the correct block containing the clear status to all the SCM processes. This results in some end points being stuck in a blocked state.

Steps to Replicate: This issue is only reproducible under extreme congestion scenarios.

The code is modified to address the issue.

Workaround: Manually recover end points blocked by ARS logic using one of the following commands:

request addressContext <context name> zone <zone name> sipArsEndpointRecoveryAll

or

request addressContext <context name> zone <zone name> sipArsEndpointRecoveryByIp ipAddress <ip> port <port>

PortFix SBX-114276: The 'show status oam radiusAuthentication radiusServerStatus availableAt' command disploys the wrong value during Daylight Saving Time (DST)

Impact: The show status oam radiusAuthentication radiusServerStatus availableAt command shows the wrong value during DST.

Root Cause: Converting the unAvailableFrom time read from from confd to local time in seconds, adding the out of service duration, and converting to back to a local time struct tm did not result in a correct time.

Steps to Replicate: 

1. Configure a radius authentication server to point to a radius server that is unavailable.
2. Configure the outOfService time to be 60 minutes.
3. Run the ssh into the CLI.
4. Run a show status oam radiusAuthentication radiusServerStatus and verify that the availableAt time is one hour in the future.

The code is modified to the current seconds in GMT time and converted back to a time structure using a the localtime_r call. This results in the correct time being displayed.

Workaround: None

PortFix SBX-113893: The SBC returned an 500 Internal Server Error and many calls failed.

Impact: Observed a memory leak when the ACK sending failed towards the SIP recording server due to a DNS resolution failure.

Root Cause: Once the 200 OK received from SIP Rec server for initial INVITE/Re-INVITE, current design assumes that INVITE/re-INVITE transaction is success and it is designed to free call control block only on completing BYE transactions.
But if ACK sending failed due to DNS resolution, then the SBC does not trigger BYE during call cleanup and in this case call control block is not getting freed, causing a memory leak.

Steps to Replicate: 

Basic call with SIP Rec feature enabled.
Simulate the SIP Rec server to send FQDN in 200 OK (200 OK of INVITE) and make sure DNS resolutions fails and this causes memory leak.

The code is modified to clear call control bock when a cleanup timer expires.

Workaround: Not applicable.

PortFix SBX-112830: The pattern mismatch search pattern 'Media\ Attribute\ \(a\)\:\ maxptime\:20' was not found 1 -> INVITE

Impact: The max Ptime value was being sent in the egress INVITE's Ptime header though the preferPtime flag was enabled.

Root Cause: The datatype of the previous field doNotAnswer was incorrect and the Ptime value was overwritten as proper size was not used.

Steps to Replicate: 

1. Run a direct media call.
2. Enable the sendPtimeInSdp and preferPtimeInSdp.
3. Send ptime value of 20 in ingress INVITE.

The code is modified so the doNotAnswer field is the right value.

Workaround: None.

PortFix SBX-112597: I-SBC: "runtime error: shift exponent 48 is too large for 32-bit type 'int' " in np.log.

Impact: The ASAN builds reported an integer overflow error in calculation of standard deviation for jitter for RTP packets.

Root Cause: Integer overflow during standard deviation calculation.

Steps to Replicate: The problem can be reproduced by streaming RTP stream with high jitter.

The code is modified to prevent integer overflow during standard deviation calculation.

Workaround: No workaround is available. This metric however, is not written into CDRs. It is currently available using Ribbon Protect.

PortFix SBX-110665: Internal IP peers blacklisted after switchover despite that OPTIONS ping worked fine.

Impact: When the system experiences a Split Brain condition, the ipPeer(s) using a pathCheck may become BLACKLISTED and may not be RECOVERED.

This can result in some ipPeer(s) becoming BLACKLISTED permanently.

Root Cause: During a Split Brain, both CEs are running in ACTIVE state. In the error case, the PATHCHK sends BLACKLIST event(s) to the ARS on both systems (CEs). This can result in a PATHCHK and ARS being out-of-sync with respect to the ipPeer(s) BLACKLISTED/RECOVERED state.

Steps to Replicate: This issue is very difficult to reproduce. We have only been able to reproduce the issue by performing “kill-stop 2” on a KVM based system, that has a number of ipPeer(s) with pathCheck profile state enabled.

The code is modified so that the PATHCHK sends events to the ARS only on the system (CE) that is being executed. The PATHCHK is prevented from sending events to ARS on the other system (CE).

Workaround: If this issue occurs, the ipPeer(s) that are stuck on BLACKLISTED may be RECOVERED through the CLI by disabling the ipPeer(s) pathCheck state.
Customers can state disable and state enable the ipPeer(s) pathCheck state.

PortFix SBX-114395: OA FSM timeout - call transfer with e2eAck enabled (ACK not sent by the SBC).

Impact: After a call transfer from legB to legC, the e2e re-INVITE and ACK are not working.

Root Cause: LegC incorrectly disables the e2e ACK, while legA still enables the e2e ACK.

Steps to Replicate: This is specific to customer configurations.

1. A call B, B refer to C, with tone places and various codec setup.
2. Once the LegC received 183 with the SDP, it triggers the SBC to send UPDATE to legC.
3. LegC answer 200OK INVITE, 200OK Update.
4. LegC sends keepalive trigger a re-INVITE to legA.

The SBC is unable to sends ACK to legA.

The code is modified to address the issue.

Workaround: Disable the e2eAck.

Portfix SBX-113242: The SLB/SBC is not fetching the correct branch param from merged VIA header.

Impact: Due to merge VIA headers, the SLB/SBC was not getting the correct instance id and response messages were not being routed to backend SBCs.

Root Cause: If the SLB/SBC receives a VIA header as merge of two VIA headers, it was overwriting the first via branch param from the second VIA branch param, and due to this SLB was not getting the correct instance id.

Steps to Replicate: 

1. UAC will send an INVITE towards the SLB/SBC.
2. The SLB/SBC sends the INVITE towards UAS.
3. UAS will send 183 response messages with merged the VIA headers (including received param) after From and To header towards the SLB/SBC.
4. The 183 should be routed to the SBC and then towards UAC.

The code is modified to set the SLB/SBC read only in the first branch param, that is what we need from top VIA and ignore the rest branch param.

Workaround: None.

PortFix SBX-91194: Difference in Energy/power level is observed across the SWe and HW platform.

Impact: The power of the tone generated by SWe is 3dBm0 higher than the configured value.

Root Cause: The root cause of the issue is the configuration of tonePower/amplitude at the DSP interface.

Steps to Replicate: 

1. Configure the SBC to run LRBT (local ringback tone).
   config
   set profiles media toneAndAnnouncementProfile EXAMPLE localRingBackTone signalingTonePackageState enable
   set profiles media toneAndAnnouncementProfile EXAMPLE localRingBackTone makeInbandToneAvailable enable
   set profiles media toneAndAnnouncementProfile EXAMPLE localRingBackTone flags useThisLrbtForIngress enable
   commit.
   set addressContext default zone <IngressZone> sipTrunkGroup <IngressTG> policy media toneAndAnnouncementProfile EXAMPLE
   set profiles media toneProfile defRing generationMethod singleTone singleTone tone1Power 0 tone1Frequency 200
2. Run a G711<=>G711 call such that the Egress Leg sends a 200 OK after some delay. During this Delay, LRBT will be played using TPAD.
3. Capture the media on UAC and analyze the tone generated for its power.

The code is modified to properly configure the tone Power at DSP.

Workaround: Not applicable.

PortFix SBX-105751: There are errors in the CE_node logs.

Impact: The"ioctl: No such device" errors seen in CE_Node logs when creating VLAN interfaces on Cloud SBC or N-to-1 SBC with VLAN packet interfaces.

Root Cause: The error messages are benign, since a check is made for the VLAN existence before creating a VLAN packet interface.

Steps to Replicate: 

A. Show the issue through logs:
On Cloud SBC or N-to-1 SBC with VLAN packet interfaces, check CE_Node2.log and observe "ioctl: No such device" message for each VLAN interface.
[root@vsbcSystem-ISBC 172.16.16.39 ~]# hwinfo | grep -v "==="
Device Description : Virtual Platform
Chassis Serial : 855f41ee-68be-46c0-8e7a-9e9911a689f4
Product Name : Sonus SBC SWe
Platform : OpenStack Compute
System Memory : 10237248 kB
System Hard Disk : 80 GiB
54.7 GiB

With VLAN the interfaces configured, look for ioctl message in CE_Node logs:
[root@vsbcSystem-ISBC 172.xxx.yy.zz openclovis]# cat CE_Node2.log
Wed Sep 1 17:30:34.337 2021: Welcome to OpenClovis SAFplus Availability/Scalability Platform! Starting up version openclovis-safplus-sdk-6.0-202001031351_42f5846
This file is the standard output of all applications.
ioctl: No such device
ioctl: No such device
[root@vsbcSystem-ISBC 172.xx.xx.xx openclovis]#

B. Show the fix through logs:
CE_Node2.log does not have "ioctl: No such device". Instead DBG log file has the ioctl messages from Sma.
[root@vsbcSystem-ISBC 172.xx.yy.zz ~]# glog
[root@vsbcSystem-ISBC 172.xx.yy.zz openclovis]# cat CE_Node2.log
Wed Sep 1 20:11:19.001 2021: Welcome to OpenClovis SAFplus Availability/Scalability Platform! Starting up version openclovis-safplus-sdk-6.0-202001031351_42f5846
This file is the standard output of all applications.
[root@vsbcSystem-ISBC 172.xx.yy.zz openclovis]# grep Sma /var/log/sonus/sbx/evlog/1000016.DBG | grep ioctl
116 09012021 201307.968434:1.01.00.00115.MAJOR .SMA: *SmaIfIoctl: ioctl returned errno=19. request=35123. ret=-1.
116 09012021 201308.996176:1.01.00.00139.MAJOR .SMA: *SmaIfIoctl: ioctl returned errno=19. request=35123. ret=-1.
[root@vsbcSystem-ISBC 172.xx.yy.zz openclovis]#

The code is modified to log the benign error messages in DBG logs instead of CE_Node log.

Workaround: None.

PortFix SBX-111034: Unable to login as an admin user using keys after cleanDB.

Impact: User is unable to login into Confd CLI using 'admin' user private SSH key after running clearDBs.sh script.

Root Cause: Cloud-init fails to run as part of clearDBs.sh script and fails to restore SSH public key for 'admin' user.

Steps to Replicate: Run a clearDBs.sh script after launching the instance and then try to log into Confd CLI using 'admin' user private key.

The code is modified to skip the redundant port for mac address validation in the case of packet port redundancy.

Workaround: Do not run the clearDBs.sh script

PortFix SBX-110046: Passing a key size for unencrypted, authenticated SRTP/SRTCP to the NP.

Impact: The RTP packets drop were occurring between the DUT and SBC.

Root Cause: In the SRTP, for unencrypted, authenticated combinations, cipher key size was unable to pass to the NP and due to this session, the authentication key was incorrectly calculated.

Steps to Replicate: Test all the SRTP call flows with UNENCRYPTED_SRTP flag enabled in the SBC and UNENCRYPTED_SRTP received from UEs as part of crypto attributes.

The code is modified for the NP to calculate session authentication key.

Workaround: No workaround.

PortFix SBX-115261: The SBC is modifying the Warning header even when transparency is enabled.

Impact: When the SBC sends a SIP Warning header with IPv6 addresses, it does not including the square brackets around the IPv6 addresses.

Root Cause: The code for adding square brackets around an IPv6 address in a Warning header was missing.

Steps to Replicate: 

1. On egress ipSignalingProfile, enable transparencyFlags warningHeader and relayFlags statusCode4xx6xx:

   1. set profiles signaling ipSignalingProfile DEFAULT_SIP commonIpAttributes transparencyFlags warningHeader enable

   2. set profiles signaling ipSignalingProfile DEFAULT_SIP commonIpAttributes relayFlags statusCode4xx6xx enable

Procedure
--------------

1. Send an INVITE to the SBC that should be routed to egress endpoint.

2. On receipt of an INVITE, respond from egress endpoint with 603 Decline including the following warning header:

   Warning: 307 [2607:fxxx:c:xxxx::xx]:xxxx "Session parameter 'foo' not understood", 399 [2607:fxxx:c:xxxx::xx]:xxxx "Robocall Block pl String 1"

3. Verify that 603 Decline is forwarded to ingress side with the same warning header including the square brackets around both the IPv6 addresses

The code is modified to include square brackets around IPv6 addresses in a Warning header.

Workaround: None.

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

Impact: The status of the following fields are not desired and contains the Junk value when running a correct amount of calls (20,000 calls):

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

Root Cause: The following fields are not Reset when the call is terminated and as a result, the junk values are preserved in these deallocated spaces.

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 junk value is not populated to the fields.

Workaround: None.

PortFix SBX-115712: There are SIP message relay issues in an INVITE with a replaces call flow, where an early dialog is replaced.

Impact: EarlyDialog replaces on ingress causes the SBC to fail and to send ACK out on the Egress when the e2eAck is enabled.

Root Cause: The e2eAck flag did not turn on on Ingress yet, therefore once the ingress connected, it did not notify the Egress side to send out ACK.

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

1. Set e2eAck to enabled.
2. A calls B.
3. B answers with a 18x message.
4. C replaces A.
5. B answers with a 200 OK message.

The SBC fails to send Ack to B

Update the e2eAck flag on the ingress when the query requests a reply, so that the ingress and the egress are in sync.

Workaround: Disable the e2eAck.

PortFix SBX-113573: The Call Media Status/ACT Log was showing media count as 0 for Ingress/Egress Packet Sent.

Impact: For the egress intercepted (IMS LI/ PC2LI) call, when the RTP monitoring and delayed RBT is configured in the PSX. The Call Media Status is showing a media count as 0 for Ingress/Egress Packet Sent.

Root Cause: For the egress intercepted (IMS LI/ PC2LI) call, when the RTP monitoring and delayed RBT is configured in the PSX. The main media along with RBT is impacted, so respective statistics are shown as zero.

Steps to Replicate: 

1. Configure the PC2.0 LI/IMSLI for egress interception.
2. The delayed RBT is configured for 183 with SDP with RTP Monitoring enabled on Egress Leg.
3. An INVITE followed by a 180 without an SDP followed by 183, with an SDP followed by RTP followed by 200 OK.

When a 183 is received, the SBC plays the Delayed Ring Back Tone towards the UAC.
When a 200 OK INVITE is received, the SBC stops the Tone and does the media cut through.

The code is modified to not stop the main media along with intercepted media for the this call.

Workaround: Not applicable.

PortFix SBX-114831: 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.

Initialization code is added for the new field.

Workaround: None.

PortFix SBX-115742: Follow-up fix for SBX-114771 that was a SCM core related to refreshAfter.

Impact: There is a segmentation fault in SBX-114771 due to code added to avoid hack during fast refresh in SBX-111209. As the code is reverted, the SBC is open to registration hacks during fast refresh.

Root Cause: The SIPSG code hit a Segmentation fault while sending a 200 OK response to a REGISTER because it is attempting to dereference an invalid pointer.

Steps to Replicate: Test steps are same as SBX-111209.

The fast refresh is handled in the SIPCM for any register. So the fix for the fast refresh hack is moved to the SIPCM Module.

Workaround: No workaround.

PortFix SBX-114557: While running a suite for a previous issue on the ASAN, the Build Number: 1252 found this issue in the SCM Process.

Impact: The "AddressSanitizer:stck-use-after-scope" while accessing the structure SIPSG_CONTACT_HDR_MEMORY_STR.

Root Cause: The SBC was trying to access the structure SIPSG_CONTACT_HDR_MEMORY_STR outside the scope that is defined.

Steps to Replicate: Run ASAN call flows.

The code is modified such that SIP_ERROR_INFO_STR structure is defined at the starting of function.

Workaround: None.

PortFix SBX-114081: The SecGetTlsProfileDataByName() selects a TLS profile other than the configured one.

Impact: The SBC uses the wrong TLS profile.

Root Cause: The 'lookup by name' function returned with the wrong profile.

Steps to Replicate: 

1. Enable DBG INFO level logging.
2. Create two TLS profiles as described in the example below:
   set profiles security tlsProfile TEST_ACCESS cipherSuite1 rsa-with-aes-128-cbc-sha
   set profiles security tlsProfile TEST_ACCESS allowedRoles server
   set profiles security tlsProfile TEST_ACCESS authClient false
   set profiles security tlsProfile TEST_ACCESS v1_0 enabled
   commit
   set profiles security tlsProfile TEST cipherSuite1 rsa-with-aes-128-cbc-sha
   set profiles security tlsProfile TEST allowedRoles clientandserver
   set profiles security tlsProfile TEST authClient false
   set profiles security tlsProfile TEST v1_0 enabled
   commit
3. Assign a second profile to one of the sipSigPort.
4. Send PDU through the sipSigPort used in Step 3.
5. Check DBG log and look for error messages and compare the profile ID assigned in Step 2.

The code is modified for both TLS and DTLS profile lookup by name routines to return the requested profile.

Workaround: None.

PortFix SBX-113592: The [ASAN]: AddressSanitizer: stack-buffer-overflow on address 0x7fb9742c6270 at pc 0x555db61239fb bp 0x7fb9742c5fa0 sp 0x7fb9742c5f98 in.

Impact: There was a Stack Buffer overflow. 

Root Cause: The boundary check was missing before running a StrNCpyZ.

Steps to Replicate: Run the ANSI-00 ISUP INVITE-BYE SIP-I codenomicon suite.

The code is modified to prevent the overflow.

Workaround: Not applicable. 

PortFix SBX-111460: The SBC does not offer 16K dtmf in a LM call when SDP is present in 2xx.

Impact: The SBC is not sending 16k 2833 Payload type in initial offer towards ingress when SDP is present in 2xx during a Late media "convert" call.

Root Cause: The answer received from the egress contained both 8000 and 16000 2833 Payload type and that resulted in the SBC wrongly assigning the 8000 PT value to 16000 as well while generating offer towards ingress. As a result, the 16000 PT get dropped by SIP stack.

Steps to Replicate: 

1. The UE initiates Late media convert call.
2. The SBC sends out 200 answer with the below SDP:
   m=audio 1338 RTP/AVP 0 96 100 101
   a=rtpmap:0 PCMU/8000
   a=rtpmap:96 AMR-WB/16000
   a=fmtp:96 mode-set=0,1,2;mode-change-capability=2;max-red=0
   a=rtpmap:100 telephone-event/8000
   a=fmtp:100 0-15
   a=rtpmap:101 telephone-event/16000
   a=fmtp:101 0-15
   a=sendrecv

Test Result without Fix: The SBC drops the telephone-event/16000 payload type when generating offer towards ingress in 180.

The code is modified to prevent the same PT value getting assigned to both 8000 and 16000 DTMF in this call flow.

Workaround: None.

PortFix SBX-112092: The CallMediaStatus does not display the codec information of t38 image stream.

Impact: The SBC does not display codec as "T.38" in callMediaStatus, when the Fax/Image stream is received as a non-core stream.

Root Cause: The issue is caused because, by default, the SBC does not populate the codec information for Image streams, if an image is received as non-core stream.

Steps to Replicate: 

1. Perform an A-B call, (Audio + Fax), where Audio is core stream and Fax is non-core stream.
2. Check for callMediaStatus, once the call is stable.

For Fax/Image stream, the codec should be updated as "T.38".

The code is modified so the codec as "T.38" for Image stream received as non-core stream for a call.

Workaround: No workaround.

PortFix SBX-90156: Observed the Major logs "MAJOR .CHM: *send_notification: unknown variable name sonusAlarmNodeID".

Impact: Major logs "MAJOR .CHM: *send_notification: unknown variable name" are seen on the sbxrestart.

Root Cause: These type of logs are seen when the queued traps are flushed out but the corresponding MIBS are not loaded yet, as a result unknown variable names/faulty varbind logs are seen.

Steps to Replicate: 

1. Spawn a OAM-MSBC setup as seen in the reported case and configure an SNMP trap target.
2. Perform a sbxrestart on the MSBC standby node.
3. Verify that the reported logs are not seen.
4. Verify the timeline for enabling of northbound interface from .SYS log and the timeline for flushing of queued traps from the level log and ensure the difference between them to be >=15 seconds.

The code is modified from ConfdSnmpStartupDelay from 5 seconds to 15 seconds to introduce a buffer for the loading of the MIBS, after the Northbound interface is enabled.

Workaround: Not applicable.

PortFix SBX-109692: The EMS fails to send authentication token while pushing licenses to the SBC.

Impact: The EMS fails to send authentication token while pushing licenses to the SBC.

Root Cause: To validate the license bundles, the CDB API's are used and in race condition, one of the CDB API is returning unexpected value and as a result, this issue is seen.

Steps to Replicate: 

1. Create a OAM/SLB cluster and bring up up nodes in this cluster.
2. Navigate Administration-> License Management-> Nodes.
3. Select the node and select few licenses and click on set selected.

Expected result: The license should get associated.

Observed result: Receiving an error pop up saying "SBCRestManager - Received error code 400".

The code is modified to validate the license bundles instead of CDB API’s.

Workaround: Not applicable.

Portfix SBX-114273: The SBC is sending unexpected UPDATE towards UAS in Support Preconditions Interworking on SIP CORE scenario. (tms927936).

Impact: An additional UPDATE is seen towards the egress endpoint during egress precondition interworking scenario.

Root Cause: An internal bug fix used to mitigate the egress SIP UPDATE is not being delivered to the endpoint during precondition transparency. This created a side effect of sending additional UPDATE towards egress during egress precondition interworking scenario.

Steps to Replicate: 

1. Configure the SBC for a basic call.
2. Configure the Egress precondition interworking related settings.
3. Run an egress precondition call flow.

While releasing the UPDATE, additional conditions have been added to correctly identify the scenario which needs UPDATE to be sent to the egress endpoint

Workaround: Not applicable.

PortFix SBX-109059: The SIPSG FAX multiple streams initiated fax call fails (muted T.38 and audio)

Impact: The multi-stream fax call is failing with muted T38 and audio.

Root Cause: There is a mismatch in the media streams of the SBC offer and the peer answer. Due to this, the images media stream received from UAS is mapped incorrectly to the audio stream in the SBC offer. This is happening when advertise audio only flag is enabled.

Steps to Replicate: 

1. UAC sends an INVITE with Audio and Image.
2. The SBC sends an INVITE with Audio to UAS due to Advertizeaudio flag is enabled.
3. UAS responds 200 OK with Audio and call gets connected as audio.
4. UAS sends re-INVITE with Image.
5. The SBC sends a re-INVITE with both Audio and Image muted causing call teardown.

The code is modified so the SBC maps the media streams in offer and answer correctly when advertise audio only flag is enabled.

Workaround: None.

PortFix SBX-113096: The RTP inactivity timer kicks in during tone play.

Impact: With a short RTP inactivity timeout configuration (five seconds in the test), the SBC generated RTP peer loss trap when the ringback tone was being played during the call setup procedure (after the SBC receiving 180 and before the final 200 OK for the INVITE completed the call setup).

Root Cause: The RTP peer loss detection was enabled on the media flow in media plane while ringback tone was being played.

Steps to Replicate: Procedure:

Configure "media peer inactivity timeout" value in the "Packet Service Profile" entry in PSX to five seconds.
Configure the DLRBT.
Configure "Peer Absence Action" as "Trap and Disconnect" in the PSP.

1. Send INVITE with SDP(PCMU)from A.
2. Send from B 180 with SDP.
3. Send PRACK from A and respond with 200OK for PRACK from B.
4. Do not send any RTP from A & B.
5. Send 200 OK for INVITE from B and send ACK from A.
6. Do not send any RTP from A & B.

Observed at Step 4, when tone was being played RTP inactivity was detected and the call was torn down.

Disable the media flow RTP peer loss detection when the ringback tone is played.

Workaround: No workaround.

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-115370: The SBC is unable to generate UPDATE message towards the UAS for the 183 dialog-3, during the call forwarding scenario.

Impact:  The SBC is unable to generate the Update towards the ingress side during a Prack 200 OK delay scenario.

Root Cause: The Update is queued in a 200 OK delay Prack scenario. The queue Update is never released.

Steps to Replicate: 

1. Bring the Application up in the SBC.
2. Set up the SBC to run the Transparent precondition interworking and downstream forking scenario.
3. Run a multiple 18x scenario with a delay in the Prack 200 OK response.

The code is modified to release the queued Update in the 200 OK Prack Delay Scenario.

Workaround: None

PortFix SBX-111176: No media was seen during tone play with the LRBT when the DPM for tone is changed from inactive to sendrecv from an ingress peer with an UPDATE.

Impact: An initial INVITE is received with the c=0.0.0.0 connection media IP and datapathmode a=inactive in the SDP. With an LRBT enabled, when the client/ingress endpoint sends an Update with non-zero c=<valid IP> and datapathmode a=sendrecv, the remote media IP maintained in the ingress call leg was being overwritten with zero IP though a valid non-zero IP was received in Update.

Without a valid remote IP, tone packets will not be generated by the SBC.

Root Cause: After the UPDATE is received, the new non-zero remote IP is updated to the circuit information maintained on the ingress call leg as part of a modify request in tone context.

However, an additional allocation request was also triggered to start the tone play with the old zero remoteIp 0.0.0.0 that was overwriting the valid remoteIp and tone play was disabled.As a result, the datapathmode has changed to sendrecv and valid remoteIP is received with the latest UPDATE from a remote endpoint.

Steps to Replicate:Run the following call flow to replicate the issue:
INV(a=inactive)->
INV(a=inactive)->
<-180(no sdp)/prack/200OK
180(a=inactive)/Prack/200OK<-
<--x-no media for tone as expected
Update(a=sendrecv)
->200OK(a=sendrecv)
<-no media for tone though DPM changed to sendrecv

The code is modified to prevent an existing non-zero valid remoteIp saved in call leg circuit info from being overwritten by zero remote IP during a tone play.

Workaround: None.

PortFix SBX-114728: The SBC did not send Terminating IOI value in P-Charging-Vector header for 183, 180, BYE, and 200 OK.

Impact: The SBC was not sending the Terminating IOI value in P-Charging-Vector header for 183, 180, 200 OK, and BYE toward the ingress.

Root Cause: The SBC should add term-ioi in PCV header when the term-ioi is configured, irrespective of whether the operator Id is configured or not.

However, due to recent code changes, this functionality was broken and when the operator Id is not configured the SBC was not copying term-ioi value in PCV properly.

Steps to Replicate: Run the SBC configuration:

1. Configure the PSX scripts under the psxScriptProfile CLI command:
   Set profile signaling psxScriptProfile <pspname> scriptName1 ATT.xml scriptName2 <name2> scriptName3 <name3>
2. Associate the psxScriptProfile to the TrunkGroup
   set addressContext <acname> zone <zonename> sipTrunkGroup <tgname> signaling psxScriptProfile <pspname>
3. Configure the tonepackage having toneProfile as DefaultRingBack and DefaultDialTone.
   set profiles media tonePackage <TonePackagename> packageId <Id> toneType dialtone toneProfile defDial
   set profiles media tonePackage <TonePackagename> packageId <Id> toneType ringbacktone toneProfile defRing
4. Ensure the 100rel support is enabled
   set addressContext default zone <Ingress_Zone> sipTrunkGroup <IngressTG> signaling rel100Support enabled
5. Run the preconditionIntwkUsing183 enabled on ingressTG
   set addressContext default zone <Ingress_Zone> sipTrunkGroup <Ingress_TG> services preconditionIntwkUsing183 enabled
6. Configure term-ioi parameter in the SIP signaling service group
   set addressContext <acname> zone <zonename> sipTrunkGroup <tgname> signaling termIOI <termioiname>

Run the PSX configuration:

1. Precondition Profile PP_ACCESS associated to Ingress TrunkGroup config:-
   * Preconditions Support If Egress IPTG:disabled
   * Preconditions Strength Mandatory: Policy: enabled ; Priority: 1
   * Preconditions Strength Optional: Policy: disabled ; Priority: 1
   * Use UPDATE when Signaling Preconditions Locally Met:Policy: disabled ; Priority: 1
2. Configure the RoutingLable with the customer script for terminating the call at PsxScriptProfile

The customer script should be configured with DefaultDialTone and DefaultRingBackTone profiles.

Run the following call:

1. Make a call that matches the routinglable configured previously with offer having the precondition attributes as follows:
   a=curr:qos local none
   a=curr:qos remote none
   a=des:qos mandatory local sendrecv
   a=des:qos mandatory remote sendrecv
   INVITE should contain : P-charing vector header with orig-ioi.
2. Verify that the SBC sends p-charing vector with term-ioi in 18x response to ingress EP.

The code is modified to send term-ioi when it is configured without having dependency on the operator Id.

Workaround: None.

PortFix SBX-111609: The GCID value of '100 Trying" sent is logged with value '0xffffffff' in POST-SMM SMM L4 Trace.

Impact: The POST-SMM Level 4 trace log for 100 Trying has GCID incorrectly set to 0xffffffff.

Root Cause: Level 4 call trace is active with a configuration to match 100 Trying and a SMM rule is applied that modifies 100 Trying.

Steps to Replicate: 

1. Configure a Level 4 call trace to match all messages.
2. Configure a SMM rule to modify the 100 Trying sent by the SBC.
3. Make a SIP-SIP call.

The code is modified so that the correct GCID value is printed in both PRE and POST-SMM traces.

Workaround: None.

PortFix SBX-112363: [ASAN]: runtime error: member access within null pointer of type 'struct CC_SG_PROGRESS_UIND_MSG_STR' in CcSgProgressHndl.

Impact: Run a basic Update CallModification scenario. After the call was completed, the ASAN runtime error is observed in the system logs indicating that the code is taking the address of a field within a NULL pointer.

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

Steps to Replicate: Run an update CallModification scenario.

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

Workaround: No workaround.

PortFix SBX-113839: The customer setup is going for continuous reboot after upgrading (Stack Delete and Create) from 8.2.2R7 and 8.2.2R8 to 10.1.

Impact: The SWe_NP process exits during DPDK ACL tries to build operation causing the SBC to go for reboots.

Root Cause: postgres process is eating up significant number of huge pages from the quota allocated for SWe_NP. As a result, SWe_NP runs short of huge pages for DPDK ACL trie build operations and exits.

Steps to Replicate: 

1. Bring up a SBC instance with 10.1 release.
2. Apply the same customer configuration. (primarily having same set of ACLs)
3. Verify that the SBC is stable after the configuration.

The code is modified to restrict the postgres process from consuming huge pages.

Workaround: Increasing number of huge pages could be a possible work around.

PortFix SBX-112163: [ASAN]: AddressSanitizer: stack-use-after-scope on address 0x7f7e3d1a4510 at pc 0x55cec34efba0 bp 0x7f7e3d1948a0 sp 0x7f7e3d194898 in SipsPSFormatErrorInfoHeaderCmd.

Impact: ASAN detected "AddressSanitizer:stck-use-after-scope" while accessing the structure SIP_ERROR_INFO_STR.

Root Cause: The SBC was trying to access the structure SIP_ERROR_INFO_STR outside the scope that is defined.

Steps to Replicate: Run a call with initial INVITE having no contact header.

The code is modified such that SIP_ERROR_INFO_STR structure is defined at the starting of the SipsTSParseMsgCmd function.

Workaround: None.

PortFix SBX-114373: The S-SBC is generating an extra UPDATE towards UAC for 3rd 183 dialog during downstream forking scenario

Impact: An additional UPDATE was seen towards ingress endpoint during downstream forking with multiple dialog scenario.

Root Cause: When simultaneous 183 messages from different dialog is received, the SBC queues the second 183 message. This is released after the completion of precondition or offer-answer negotiation for current dialog. Due to a previous fix, there were changes introduced in this framework that causes the early release of 183 message, thereby inducing issues in the OA FSM.

Steps to Replicate: 

1. Run a customer call scenario.
2. Run the scenario with SIP_FW.
3. Respond to the INVITE with 183 (Dialog-1) from UAS.
4. Send an UPDATE from UAC, by updating the precondition attributes.
5. Respond to the UPDATE message with the 200 OK from UAS.
6. Send back two back-to-back 183(Dialog-2) and 183(Dialog-3) from UAS. The SBC sends an UPDATE message to UAC for the Dialog-2.
7. Once precondition done for 183 (Dialog-2), the SBC generates a UPDATE for 183 (Dialog-3).
8. Respond to the UPDATE message from UAC and complete the preconditions for 183 dialog-3 from UAC.
9. The SBC generates the UPDATE towards the UAS, Send the 200OK for that UPDATE and complete the preconditions.
10. Send 200 OK with the Dialog-2 from the UAS.

The call should be established.

The code is modified so the 183 message is released correctly before releasing the second 183 message. 

Workaround: None.

PortFix SBX-110891: The 'gzip' should run with a nice value of >15 for lesser resource consumption.

Impact: The SBC performance monitoring tools like top2 at times take a large percentage of CPU core, there by reducing the total available CPU resources for management activities on the SBC.

Root Cause: The gzip, that compress files, currently runs periodically without any Linux value configured.

Steps to Replicate: Install the fix build and ensure top2 gzip processes are running with a correct value of 15 using top2 command.

The code is modified to reduce the priority of processes compared to other management processes on the SBC.

Workaround: None.

PortFix SBX-110324: The SBC fails to set up a DTLS-SRTP call if dtlsProfile --> CertName is configured with a local-internal certificate. The call works correctly if a "local" certificate is used.

Impact: When local-internal type certificate is configured from the EMA, the certificate is updated in the SAM process correctly but not updated in the PRS process. As a result, the DTLS SRTP calls are unable to get certificate and the call fails.

Root Cause: When local-internal type certificate is configured from the EMA, the certificate is updated in the SAM process correctly but not updated in the PRS process. As a result, the DTLS SRTP calls are unable to get certificate and the call fails.

Steps to Replicate: Configure the local-Internal type certificate from EMA and make DTLS_SRTP call.

DTLS_SRTP connection will fail because of certificate not being available.

The code is modified to read the certData from DB and update x509 when pki certificate state is enabled.

Workaround: After configuring a certificate from the EMA, perform an SBC restart. This restores the certificate from DB and the DTLS_SRTP call is successful.

PortFix SBX-108416: Importing of local and remote certificates on the Cloud SBC platforms requires .der and .p12 to be placed on both the active and standby nodes. This is not the case for HW and VMware SBC platforms.

Impact: On cloud 1:1 HA, importing of TLS certificate failed on the STANDBY.

Root Cause: Importing of local and remote certificates on the Cloud SBC platforms requires .der and .p12 to be placed on both active and standby nodes. This is not the case for HW and VMWare SBC platforms.

Steps to Replicate: 

1. Bring up 1:1 on cloud.
2. Import certificates on the Active instance and configure for TLS calls.
3. Make calls to the active instance.
4. Perform a switchover.
5. Make calls to instance that become active.

Expected Result:

1. Check configuration is successful.
2. TLS calls on active and standby should be successful.

The code is modified to update the HW and VMware SBC platforms similar to H/W for cloud 1:1 HA and N:1.

Workaround: Configure the certificate on both instances.

PortFix SBX-114618: The SBC did not send Terminating IOI value in P-Charging-Vector header for BYE message and STOP CDR record (69.30 field).

Impact: The SBC did not send Terminating IOI value in P-Charging-Vector header for BYE message

Root Cause: Upon receiving a 200 OK, the SBC is not saving term-ioi, there by causing this issue.

Steps to Replicate: 

1. Bring up SBC with the 10.1 Release.
2. Configure the P-Charging-Vector related configuration.
3. Send term-ioi in the 200 OK Response.

The code is modified to save the term ioi in a 200 OK Response.

Workaround: we can try adding missing term-ioi by SMM.

PortFix SBX-110245: The AddressSanitizer: heap-use-after-free /sonus/p4/ws/jenkinsbuild/sbxAsan100/marlin/SIPSG/sipsgMsgProc.c:7097 in SipSgProcessNrmaUpdateNfy(SIPSG_CONTEXT_STR*, nrma_update_nfy_msg_str*)

Impact: The ASAN detected "AddressSanitizer: heap-use-after-free" while accessing SG_CCB_STR pointer.

Root Cause: The SBC was trying to access the SG_CCB_STR pointer that is already been freed.

Steps to Replicate: Run a basic call where ICID value of P-Chargingector header in INVITE message is NULL or absent.

The code is modified to check the pointer is null or not before accessing it.

Workaround: None.

PortFix SBX-109808: [ASAN] SBC: Scm process gave ERROR: AddressSanitizer: heap-use-after-free on address 0x6150000d6488 at pc 0x5585e065bdec bp 0x7f3900ad0e10 sp 0x7f3900ad0e08 on the SBC standby.

Impact: The ASAN error is coming on the standby SBC when the standby is going down anyway.

Root Cause: Packet collector is checking requests queue when system is shutting down.

Steps to Replicate: Run the same scenario again and check that ASAN error is not seen now on standby MRFP

The code is modified to not check the requests queue when system is going down.

Workaround: None.

PortFix SBX-114184: The SMM store/regstore/regsub SMM operations add an extra CRLF if the operation is executed against a header that contains a SIP URI.

Impact: The SMM inserted double EOL after using regex for header value operations.

Root Cause: After modifying the header value, the SMM logics did not strip off EOL. As resulted when it try to format back, additional EOL was inserted.

Steps to Replicate: An incoming message has invalid from header syntax
From: "phoneLite" <sip:1245@son.com;tag=legA
Use regsub to add missng '>' after .com.

set profiles signaling sipAdaptorProfile FIX_MISSING_GT rule 1 criterion 1 type message
set profiles signaling sipAdaptorProfile FIX_MISSING_GT rule 1 criterion 1 message messageTypes request
set profiles signaling sipAdaptorProfile FIX_MISSING_GT rule 1 criterion 1 message methodTypes invite
set profiles signaling sipAdaptorProfile FIX_MISSING_GT rule 1 criterion 1 message condition exist
set profiles signaling sipAdaptorProfile FIX_MISSING_GT rule 1 criterion 2 type header header name From condition regex-match regexp string > numMatch notmatch
set profiles signaling sipAdaptorProfile FIX_MISSING_GT rule 1 action 1 type header operation regsub
set profiles signaling sipAdaptorProfile FIX_MISSING_GT rule 1 action 1 regexp string ";tag"
set profiles signaling sipAdaptorProfile FIX_MISSING_GT rule 1 action 1 from type value value ">;tag"
set profiles signaling sipAdaptorProfile FIX_MISSING_GT rule 1 action 1 to type header value From
set profiles signaling sipAdaptorProfile FIX_MISSING_GT state enable
commit

The code is modified to address the issue. 

Workaround: No workaround.

PortFix SBX-112706: The SBC populates the NOTIFY XML body using pre-SMM INVITE PDU for outgoing messages.

Impact: The SBC was using pre-SMM outbound INVITE PDU for populating the XML body of NOTIFY for the Call Notification feature in the XML Metadata body of the SIPREC INVITE.

Root Cause: The SBC considers pre-SMM outbound INVITE PDU instead of the post-SMM PDU for SIPREC and call Notification features.

Steps to Replicate: 

1. Enable the Call Notification feature (or SIPREC recording on egress TG).
2. Configure SMM profile for outbound messages on egress TG.
3. Make a basic call.

Observation: The SBC should use post-SMM outbound INVITE PDU for populating XML body of NOTIFY for Call Notification feature (and for SIPREC INVITE).

The code is modified to consider the post-SMM outbound INVITE PDU for populating the XML body of NOTIFY for the Call Notification feature and SIPREC.

Workaround: Not applicable.

PortFix SBX-108326: The SBC sends ACK with "a=inactive" when PRACK is enabled only on ingress leg and an outgoing INVITE towards the egress leg that does not have offer, and 18x towards ingress that has offer based on the configuration flag "Sdp100relIwkForPrack" scenario.

Impact: The SBC is not triggering a re-INVITE after sending ACK with "a=inactive" on the egress side for an asymmetric PRACK interworking scenario.

Root Cause: Since the SBC creates the offer SDP internally, 18x is sent with "a=inactive" on the ingress side. The SBC sets the datapathmode as inactive on the egress side.

So even after receiving a 200 OK with "a=sendrecv". it sends ACK with "a=inactive".

Steps to Replicate: 

1. Late media pass thru call and PRACK is supported only on the ingress leg.
2. Send Invite without SDP offer from ingress side.
3. Send 18x without SDP offer from egress side.
4. After receiving 18x with SDP, respond with PRACK from ingress side.
5. Send 200 OK from egress side with SDP "a=sendrecv".
6. Respond with 200 OK with ACK on the ingress side.

The code is modified so the SBC creates offer and sends in 18x on the ingress side.

On the egress side, after receiving 200 OK with "a=sendrecv",
ACK is sent with "a=inactive".

So a fix is given to send a re-invite on egress side with "a=sendrecv".

Workaround: Not applicable.

The SBC fails to send ACK in the Re-invite call flow when E2E ACK and E2E re-Invite flags are enabled.

Impact: E2eAck not working after Invite with a replace.

Root Cause: Currently, the E2eAck configuration is applicable only on egress leg. After receiving an Invite with replace (ingress legC), legC does not support e2eAck.

Steps to Replicate:

1. A calls B, C replaces A.
2. C re-Invite to B.
3. The Ack from C fails to trigger the SBC to send Ack to B.

The code is modified to address the issue.

Workaround: Disable the e2eAck.

flexiblePolicyAdapterProfile breaks transparency in GW-GW scenarios.

Impact: A SMM with action flexiblePolicy assigned at the ingress trunk group may break SIP header transparency for SIP-GW-GW-SIP calls. SIP headers are not sent transparently to the egress SIP peer.

Root Cause: The SBC is unable to pack and send flexible routing headers to the GW-GW call leg. As a result, all SIP headers where the transparency is enabled, are not relayed.

Steps to Replicate: Enable the flexiblePolicyAdapterProfile and enable either "Unknown Header transparency" in the egress IP signaling profile or configure the egress transparencyProfile with transparency for all headers.

Make a SIP-GW-GW-SIP call and observe that the headers are not relayed.

The code is modified to ignore when packing the transparency content.

Workaround: Disable the SMM flexible routing.

Memory leak in the PES process. 

Impact: The PES Process has leaking memory.

Root Cause: In Postgres searching result object was not properly cleared for TRUNK.

Steps to Replicate: To reproduce the issue, attempt to make call loads that Trunkgroup has ZZPROFILE assigned.

To test the fix, do the same.

The code iis modified to clear the search result object.

Workaround: Use a Trunkgroup without ZZPROFILE should help.

There was a race condition when the 183 and 200 OK (INVITE) are received simultaneously. The 200OK is not relayed to the other side.

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

Root Cause: There was a race condition between internal processing of the 200 OK for an UPDATE and a received 183 Session Progress.

Steps to Replicate: Set up the 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.

After call transfer 7000 fails to send media stream to new term resulting in dead air to term end - ingress in fax mode.

Impact: If the call is in fax mode and if a Re-INV is received with new media address then the SBC is not sending RTP to the new media address. Instead, it is sending RTP to the old media address.

Root Cause: When the call is in fax mode and if the SBC receives a Re-INV from the peer, then it responds locally with 200 OK SDP to the peer. The current logic was not checking for any change in the media address received in the re-INVITE. Hence, the SBC was sending RTP to the old media address.

Steps to Replicate: 

1. Call is established between A and B with codec PCMU.
2. User A initiated a fax a re-INVITE and the call is transitioned to fax.
3. User B initiates a re-INVITE with change in IP/Port.

The code is modified so that when the call is in FAX mode and if any re-INVITE is received from the peer, then the SBC compares the media addresses. If there is any change in it, then it starts a modify offer-answer cycle to get this new media address updated.

Workaround: None.

Post 9.2.3 upgrade, the T.38 has faxing issues.

Impact: Customer experienced some fax failures after moving to 9.2 from 7.2 release.

Root Cause: Inspection of Traces from field supplied by customer shows this file has 3 DCS and TCF packet captures, and the packets are large with a payload of 176 bytes of V.29-9600.

The root cause is that T.38 stack gets stuck in generating a very long TCF instead of 1.5 seconds long, resulting in a fax failure.

Steps to Replicate: For test steps refer to unit test for this JIRA and test files loaded in the JIRA.

The code is modified to address the issue.

Workaround: Increase the Maxdatagram size to 72 instead of 176. This was tried by customer and found to work. However, this setting is on the peer T.38 device and not always available.

One way audio when a call starts as a=recvonly and RTP NAT learning completes before the call is switched to a=sendrecv. This happens with RTP coming from port number 5004 or 5006 only.

Impact: The RTP NAT learning completes while the call is in a=recvonly mode (SBC is in receive-only mode). Once the called party switches the call to a=sendrecv mode, the XRM stays in rcv-only instead of switching to duplex. This is why the SBC does not send any RTP packets towards the endpoint that is behind NAPT and the endpoint doesn't receive any audio.

Root Cause: Port 5004 is defined as LOOPBACK_IP_PORT in the SBC and being used for NAPT. When RTP is coming on port 5004, NAPT re-learning will not be completed. If NRMA is waiting for NAPT re-learning to complete before changing rtpMode to duplex, then one way audio occurs.

Steps to Replicate: Configure the SBC as:

1. The ingress endpoint is behind NAPT, media NAT learning is enabled on the ingress sipTrunkGroup.
2. The called party answers the call as "recvonly" and switches to "sendrecv" by sending a re-INVITE.
3. The ingress endpoint sends RTP packets from the UDP port number 5004.

The code is modified so that when RTP is coming on port 5004, the NAPT re-learning is completed and the rtpMode updates as expected.

Workaround:Change the endpoint configuration and/or the NAT device configuration so that the SBC receives RTP packets from the UDP port numbers other than 5004 and 5006.

The SBC is timing out when creating a route through the EMA.

Impact: The SBC is timing out when creating a route through the EMA

Root Cause: While creating route current system is fetching all the created routes. Due to this issue, the timeout issue is caused as a result.

Steps to Replicate: Getting an "Error Saving From Details, TimeoutError: timeout has occurred" while creating a route through the EMA.

The code is modified to address the issue. 

Workaround: No workaround.

There was a SCM Process core in SipSgIsEgressPrecondUpdateEnabled.

Impact: There was a SCM Process core in SipSgIsEgressPrecondUpdateEnabled. The core occurs when the SBC receives a NULL to function SipSgIsEgressPrecondUpdateEnabled().

Root Cause: The core occurs when the SBC receives a NULL to SipSgIsEgressPrecondUpdateEnabled(pvApplHandle=0x0) and inside that function, the SBC dereferences the NULL pointer.

Steps to Replicate: The steps cannot be reproduced. 

The code is modified to address the issue.

Workaround: None.

The MIME part headers do not pass over a GW-GW with body transparency.

Impact: In the GW-GW call when the PIDF MIME body parts are passed over a GW-GW with the SBC body transparency enabled, the MIME part headers other than Content-Type are not passed.

Root Cause: The code for packing unknown headers in first gateway and code for unpacking it at second gateway was absent.

Steps to Replicate: 

1. Enable transparency for PIDF body at ingress side (Gateway 1).
2. Run GW-GW call sending PIDF MIME Content with unknown content header "content -ID" from ingress.
3. Check logs at Gateway 2 to verify the unknown headers in MIME are relayed to Gateway 2.

The code is modified to address the issue.

Workaround: No workaround.

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.

The events in the NRMA logging are not printed to the TRC.

Impact: Some NRMA call trace log entries are missing.

Root Cause: The complete set of NRMA call trace log entries are only generated if the oam eventLog typeAdmin debug filterLevel is set to info or the NRMA subsystem has infoLogState enabled.

Steps to Replicate: 

1. Set debug log filterLevel to info.
2. Configure a call trace filter to match a call.
3. Make the call.
4. Set debug log filterLevel to major.
5. Make the call.
6. Compare the two traces.

The code is modified to decouple the generation of NRMA call trace logs from the filtering of debug logs.

Workaround: None.

There is a SIPSG sync failure after both nodes update to 9.2.

Impact: There is a SIPSG sync failure with this message:

MAJOR .EVLOG: SYS ERR - Error 0x3a3c Line 6304 File /sonus/p4/ws/jenkinsbuild/sbx923R0fix/marlin/SIPSG/sipsgRedund.c.

Root Cause: The SIPSG is failing to sync Registration data.

The failure is due to the fact that the buffer that is allocated for mirroring the Registration data is not large enough.

This is because the structures have grown over time and no longer fit in the allocated memory.

Steps to Replicate: Enable this configuration:
set oam accounting admin eventAcctState enabled
Include five Contact headers

Look for this message in the logs:
MAJOR .EVLOG: SYS ERR - Error 0x3a3c Line 6304 File /sonus/p4/ws/jenkinsbuild/sbx923R0fix/marlin/SIPSG/sipsgRedund.c.

Increase the amount of memory for the message that is used for mirroring the Registration data to address the issue.

Workaround: It may be possible to avoid this issue by disabling the following configuration parameter:
set oam accounting admin eventAcctState enabled

Failed to create LIF when applications are starting up.

Impact: Failed to create a LIF when an application starting up.

Root Cause: The LIF name, IPIF_pkt1b, was used in 2 different address contexts which is not allowed.

Steps to Replicate: 

1. Configure two LIFs with the same name in two different address context.
2. Start the application.
3. Check the DBG log.

The code is modified to validate LIF's name against assigned address context and log a detailed major DBG message when finding the bad configuration.

Workaround: No workaround.

No audio in STUN/ICE/DTLS calls and the SBC ignoring DTLS Client Hello requests

Impact: There is no audio in STUN/ICE/DTLS calls.

Root Cause: During the process of BIND response message, ICE FSM did not verify the remote IP address against stored nominated candidate's IP address. So when the SBC received the response message from a different remote entity other than the nominated candidate, ICE FSM overwrites RTP candidate and notified NRMA with the different remote IP and caused the issue.

Steps to Replicate: 

1. Establish STUN/ICE/DTLS call with two candidates.
2. Check the audio.

The code is modified to check the remote IP address in the response message. If the remote IP address is different from stored nominated candidate's IP address, log a debug message and drop the response.

Workaround: N/A

The CIN-5400-PJ Application is restarting every 30 minutes.

Impact: The CIN-5400-PJ Application is restarting every 30 minutes.

Root Cause: The CPX process does not respond within 180 seconds to the confd process because the CPX process received a malformed response from the TRM process on a show addressContext zone trunkGroupStatus request.

Steps to Replicate: Perform an snmpwalk on addressContext zone trunkGroupStatus
Observe that the SBC does not shutdown.

If the TRM response has a cpxIndex of 0, respond to confd immediately with an error to address the issue.

Workaround: Do not run an SNMP getnextrequest on addressContext zone trunkGroupStatus

Serial Number display issue in the EMA, Azure

Impact: In a virtual cloud HA setup, the Serial Number displayed in EMA is incorrect.

Root Cause: In a virtual cloud HA setup, the EMA was using the serial number of the standby node instead of active node and the same was displayed in the UI.

Steps to Replicate: In a virtual cloud HA setup, log in to the EMA.

The serial number should be displayed.

The code is modified to retrieve the serial number of the active instead of standby node.

Workaround: None.

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.

The SBC does not change the status of the certificate from "SUCCESS" to "FAILED" when the certificate expires.

Impact: The SBC CLI and EMA display the status of the certificate as "SUCCESS" for certificates that expired and are no longer valid.

Root Cause: The SBC did not update the certificate status to "FAILED" although the SBC detected the certificate expiry.

Steps to Replicate: 

1. Create a PKI certificate object and import a certificate that's going to expire soon.
2. Once the certificate expires, use the "show table system security pki certificate" command to check its status.

The code is modified so that the status of expired certificates is updated from "SUCCESS" to "FAILED" upon a certificate expiry.

In addition to the code changes, the "expired" status is added to the pki > certificate > status statistic in the Security table on the page Show Table System.

Workaround: No workaround.

The SBC does not add "term-ioi" to the PCV of the SIP 503 response when the SIP 503 response is caused by the TG being blocked.

Impact: The SBC does not add the "term-ioi" parameter to the PCV header of the SIP 503 response when the SIP 503 response is caused by the ingress TG being configured with "blockDirection: incoming".

Root Cause: The code that would update the term-ioi parameter in case the TG is blocked was missing.

Steps to Replicate: 

1. Make a SIP-SIP Japan call setup.
2. Configure a sipJJ9030InterworkingProfile with sipFlavor as JJ9030 along with origIoi and termIoi.
3. Attach sipJJ9030InterworkingProfile to the ingress TG.
4. Set the ingress TG's flag "blockDirection" to "incoming".
5. Make the call and check the presence of the term-ioi paramter in the PCV header of the outgoing SIP 503 response.

The code is modified to update the term-ioi in a call control block from locally configured sipJJ9030InterworkingProfile.

Workaround: No workaround.

There was a SCM process coredump in SipSgRecFormSipRecSDP.

Impact: The SCM process core in SIPREC code after a switchover.

Root Cause: The SIPREC code is attempting to dereference a NULL pointer.

Steps to Replicate: The steps cannot be reproduced. 

The code is modified to prevent the attempt to dereference a NULL pointer.

Workaround: There is currently no workaround.

The SBC SWe with larger disks get stuck at boot after reset or powercycle.

Impact: When an SBC on SWe is powered off, without soft shutdown, on reboot system goes into emergency mode and waits for user input on console.

On the VMWare, it hangs forever.
On the KVM, when user hits Enter the system boots up.

Root Cause: On reboot after unclean shutdown, the systemd-root-fsck service runs to chec root file system.

When the root file system is large (>200GB), it takes more than 90 seconds (default service start time) to start file system check and subsequent devices' file system checks mentioned in /etc/fstab fail pushing the system into emergency mode.

Steps to Replicate: 

1. Install the SBC on the SWe.
2. Wait for the system to boot and the SBC app to be up and running.
3. Reset the system. (Pull the plug)
4. Wait for the system to boot.
5. The system should boot up fine with the SBC app up and running.

The code is modified to remove the console=ttyS0 from kernel command line.

Workaround: On VMware on reboot, enter into the grub menu and remove console==ttyS0 option from the command line.

The checkDrbdMountStatus.sh was still in the crontab.

Impact: On the SBC startup or switchover, crontab is erroneously updated to contain a call to checkDrbdMountStatus.sh.

Root Cause: The legacy call to checkDrbdMountStatus.sh is no longer needed in cron.

Steps to Replicate: Start the SBC. At the linux prompt, run command crontab -l to check crontab contents.

The code is modified to no longer add checkDrbdMountStatus.sh.

Workaround: None.

Incomplete data is shown in the "DNS Entry Data Status List" in the EMA.

Impact: Incomplete data is shown in the "DNS Entry Data Status List" in the EMA.

Root Cause: The data type of key 2 needed to retrieve DNS data entry status from hash is incorrect.

Steps to Replicate: 

1. Create a DNS group , make entries and configure ipAddress, transportProtocol, priority, weight.
2. Go to unhide debug. Give following commands to make the DNS requests.
   request sbx dns debug command "dig _sip._udp.gateway-us.redmatter.com Google_DNS_Group srv"
   request sbx dns debug command "dig G01-103.redmatter.com Google_DNS_Group a"
   request sbx dns debug command "dig S02-1.redmatter.com Google_DNS_Group a"
   request sbx dns debug command "dig S01-2.redmatter.com Google_DNS_Group a".
3. Give the following command to display the populated data of DNS Entry Data Status table in the CLI.
   "show table addressContext default dnsGroup <dns_group_name> dnsEntryDataStatus".
4. Check the DNS Entry Data Status in the EMA, the DNS Entry Data Status table reflects with the data that is there in the CLI.

The code is modified to 1 byte.

Workaround: No workaround.

The SBC does not follow the Q.1912.5 spec for privacy of the display name.

Impact: When trunk group variantType is q1912, the SBC includes display name in SIP From: header, even though privacy is enforced. The display name should be set to "Anonymous" in this scenario.

Root Cause: The display name in the From: header is mapped from the P-Asserted-Identity: header, rather than being set to "Anonymous".

Steps to Replicate: 

1. Configure ingress and egress SIP trunk groups to have variantType q1912.
2. Make SIP-SIP call. In the initial INVITE, include:
   From: "Anonymous" <SIP URI>
   P-Asserted-Identity: "display name" <SIP URI>
   Privacy: user,id

The code is modified to set the display name in From: to "Anonymous" when privacy is enforced for variantType q1912. When the variantType is uk and privacy is enforced, the display name in From: is not included.

Workaround: A SMM rule may be configured to anonymize the From: header.

The SBC fails to write SMM values into the CDR when STI profile is attached.

Impact: When STI is enabled and attached, we are not writing SMM details to the CDR.
The SMM details are written when STI profile is disabled.

Root Cause: SMM fields are impacted when STI profile is enabled as part of SipSgFillStiCdrData -> SipSgSendAcctUpdateToCc -> SipSgFillInProtSpecificString -> SipSgFillSmmCdrString, in sipsgIncomingCallNfy. The SBC fails to write SMM values as ccbPtr→commonFsmCb.ccHndl, and after the fetching values of SMM, free up the SMM-CDR memory and thus we fail to update the SMM data when the normal update happens through the NrmaAllocRpy.

Steps to Replicate: Run a normal STI call with SMM rules applied.
Check for the SMM in CDR.

The code is modified to control SipSgSendAcctUpdateToCc.

Workaround: None.

FAILURES and LINK FAILURES counts increase by two from portMonitorStatus command in V09.

Impact: After a switchover, the failure counts reported in by portMonitorStatus command are doubled.

Root Cause: The portMonitorStatus was being registered twice with the CPX process.

Steps to Replicate: 

1. Set up an SBC 1to1 system.
2. Failover to the standby.
3. Take pkt0 out of service.
4. Run a show table show table system ethernetPort portMonitorStatus.
5. Ensure that the failure count for pk0 is 1, not 2.

The code is modified to detect and reject duplicate registrations.

Workaround: None.

Making IP interface OOS/disabled stops sending traffic over interface in other AC.

Impact: For the SBC SWe running on VMware platform with X710 SRIO NICs, create two IP interface groups in two different address contexts with different VLANs but with the same packet port.

As a result, this makes two different VLAN interfaces from the same packet port.

When we make an IP interface OOS/disabled in one address context, the SBC packet port was unreachable in another address context.

Root Cause: When we make an IP interface OOS/disabled in one address context, the SBC packet port was unreachable in another address context because the packet port started getting untagged (stripped VLAN) packets.

The problem is unique to VMware host X710 NIC (i40en) driver version 1.8.6 and this problem is not found in driver versions 1.10.9.0 or above.

Steps to Replicate: 

Set up: Upgrade X710 NIC driver 'i40en' version to 1.10.9.0 and firmware 7.20 on VMware host server.

Test scenario:

1. Bring up a SWe instance with the fixed build.
2. Create two IP interface groups in two different address contexts with different VLANs but with the same packet port. Which makes two different VLAN interfaces from the same packet port.
3. Disable one of the IP interface groups and run a ping test (network reachability) from the other VLAN interface.
   
   Observations: The SBC packet port was reachable in another address context.

The code is modified in the SBC NP code for compatibility with the newer host drivers, since the newer host drivers do not allow the dissimilar number of Rx and Tx queues.

NOTE: The customer first needs to upgrade the SBC software with the fix and then upgrade i40en VMWare host driver to version 1.10.9.0 or above along with compatible NIC firmware upgrades.

Workaround: Make IP interfaces OOS/disabled in all address context of the packet port and then enable the required IP interface.

No trap is generated when the Max System Call Limit is set.

Impact: No trap is generated when the Max System Call Limit is set.

Root Cause: The "Max System Call Limit Set/Clear" notifications referred to incorrect trap definitions.

Steps to Replicate: Verify the traps are generated for the following CLI commands once the max system call limit is reached.

set oam traps admin sonusSbxNodeResourcesMaxSysCallLimitSetNotification state enabled
set oam traps admin sonusSbxNodeResourcesMaxSysCallLimitSetNotification priorityLevel default

set oam traps admin sonusSbxNodeResourcesMaxSysCallLimitClearNotification state enabled
set oam traps admin sonusSbxNodeResourcesMaxSysCallLimitClearNotification priorityLevel default