SBC Core 08.02.00R001 Release Notes

V07.02.00S810

Development to allow early RTP ICE learning for the MS teams DLRBT media bypass scenarios.

Impact: In a media bypass call flow with DLRBT enabled, if the MS Teams client takes a long time to answer the call then the ICE processing does not complete. The MS Teams client never sends STUN with useCandidate = 1 because it did not receive responses to the previous stun messages in the first ten seconds for the call.

Root Cause: For an outgoing call, the SBC was not enabling ICE learning and was not responding to stuns until an answer SDP was received.

Steps to Replicate: With MS Teams media bypass and DLRBT configuration on the SBC, make a call from PSTN to MS Teams and delay answering of the call for 30 seconds.

Platform/Feature: SBC

Observed a PrsNp coredump in the ISBC when the pkt cable was unplugged from the box with a VmWare platform.

Impact: A cable pull-and -lug of packet ports results in a healthcheck failure causing the SWe to coredump, resulting in a node switchover.

Root Cause: On cable pull, the SWe detects no link on the packet port and calls the ifconfig down to make the VF administrative state down. This may take more time resulting in a healthcheck failure.

Steps to Replicate: Do multiple cable-pulls and -plugs of the packet port on host.

Platform/Feature: SBC

Unable to ping the gateway from pkt interfaces of an ISBC instance after unplug-plug of the X540 SRIOV pkt interface cable on the VMware platform.

Impact: Cable unplug-plug of packet ports with a VLAN tag on the VmWare sr-iov setup causes ping loss.

Root Cause: A cable unplug-plug causes the SWe to call an ifconfig down/up, which causes a kernel to send a VLAN del/add notification with vid 0 if the tag exists on the interface. The VMware PF does not reject this VLAN add with 0 and reconfigures the NIC's VLAN filter table resulting in ping loss.

Steps to Replicate: On the VMware sriov packet port, perform a cable unplug-plug of the packet port on a host with a VLAN tag. The ping will stop working.

Platform/Feature: SBC

Use the correct nif_id in a rx_packet_loop.

Impact: On the VMWare platforms, in distributor model, a call load can have a random signalling packet loss.

Root Cause: Incorrect calculation of the NIF id to derive the signalling or media queue from the distributor to the workers.

Steps to Replicate: On the VMWare, set up the port redundancy with distributor architecture and run the maximum load.

Platform/Feature: SBC

Portfix SBX-93103: No relay of an UPDATE with SDP when the media mode changed and the DRBT is configured.

Impact: When Downstream Forking and DLRBT are enabled, the UPDATE received from ingress are not going out to egress (UPDATE received after the media cut-thru has occurred because of the receipt of the RTP from egress).

Root Cause: SBX-67242 modified the code logic that when an 18x with SDP is received from a particular dialog, it is marked as OA_COMPLETE. If it is marked as OA_COMPLETE, the UPDATEs received are sent to the other leg if that other leg is 100rel/PRACK supported. This issue was caused due to some of the legs not being marked as OA_COMPLETE due to incomplete implementation.

Steps to Replicate: The steps cannot be reproduced.

Platform/Feature: SBC

Datora:EMA: The edit route action was taking a long time to complete.

Impact: The edit route action was taking long time or failing.

Root Cause: The use of special characters such as # in the Destination National field cause the failure of edit route action.

Steps to Replicate:

1. Create Route with a special character in Destination National.
2. Select the Route, which is created in Special Character.
3. Edit Form is load.

Platform/Feature: SBC

Portfix SBX-93262: The SBC generates the RTCP goodbye to the ingress after 200 OK.

Impact: When the Downstream forking is enabled and the Early Media Response is set to "last received SDP" - when the call gets answered, the resource chain will be re-built and the RTCP BYE will be generated.

Root Cause: The root cause is from a feature done in SBX-32482. This Jira required that if the ingress peer does not have 100 rel support, and the egress gets multiple 18x's, then force transcode even though the pass through is possible to support the codec change ( expected behaviour as a part of this feature enhancement is 2nd dialog early media should be transcoded without sending SDP in subsequent 18x to ingress peer. )

Steps to Replicate: The steps cannot be replicated.

Platform/Feature: SBC

The code is modified to address the exact scenario that was presented in the previous Jira. Specifically -
1. Downstream forking is enabled.
2. Early media behavior - non FIRST PROV RESP.
3. Only one forking dialogue.
4. No SDP sent in 2xx if 18x reliable.

Route search by Routing Label was not functional in the 8.1 EMA.

Impact: Route search by Routing Label was not functional in the 8.1 EMA.

Root Cause: Retrieving maximum of 20 labels.

Steps to Replicate:

1. Log on to EMA.
2. Click on Configuration->System Provisioning->Routing->Routes.
3. Click on Routing label scroll bar.
4. Observe the number of routing labels.

Platform/Feature: SBC

Portfix SBX-92155: The SBC was releasing the call with 504 when the DLRB and Downstream Forking are enabled.

Impact:

1. Tested with FLRBT and Downstream forking and calls passed.
2. Downstream forking enabled – calls passed correctly.
3. If DLRBT and Downstream forking was enabled, the SBC is releasing the call at the moment it receives 200ok for the INVITE and it is sending 504 to ingress and releasing the calls.

Root Cause: Race condition was not handled properly. When the SBC received the first 180 without SDP, the forking list was updated and stored the message. The second time a 18x with SDP is received, the forking list was updated and store the new 18x received. But since RTP learning occurred before, the forking list was not being updated.

Steps to Replicate: The steps cannot be replicated.

Platform/Feature: SBC

The SBC displays an error popup when the import configuration is sent to the M-SBC.

Impact: The error popup appears when the import configuration is sent to the M-SBC.

Root Cause: After sending a request from the SBC manager, a timeout was returned due to performing a start import operation. This operation calls internally configTemplate api of platform manager. Using this api, execute the importCLI.pl script with required inputs. Once this script completes, the configTemplate api returns the response to the SBC manager that takes additional time, depending on the cli file size.

Steps to Replicate:

1. Login into EMS and launch the SBC manager.
2. Go to Administration --> System Administration -->File Upload and and upload .cli file
3. Go to Administration --> System Administration --> Configuration Script and Template Import
4. Select the uploaded .cli file and click on the startImport button.

Platform/Feature: SBC

Unable to delete the User Session from the EMA.

Impact: Unable to delete the User Session from the EMA.

Root Cause: Caused by not removing the session call from the UI.

Steps to Replicate:

Step 1: Login to the EMA with "admin".
Step 2: Navigate to Administration> Users and Session Management> click New User.
Step 3: Create a new user "Test".
Step 4: From a different IP or from different browser, login with "Test" and provide the necessary password changes.
Step 5: After logging in with "Test", it will be logged in "Successfully".
Step 6: In Admin with the logged in browser, navigate to Administration> Users and Session Management
Step 7: Delete the "Test" user session. It will display "Delete successful".

Platform/Feature: SBC

Portfix SBX-95114: The SBC IgnoreTransparency cannot be set on the EMA V6,7.2 and 8+.

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

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

Steps to Replicate:

1. Log on the EMA.
2. Navigate to All->Profile->Services->Transparency profile->SIP Header
3. Select a transparency profile.
4. Click on New SIP Header.

After the previous steps, the "Ignore Transparency " field will become visible.

Platform/Feature: SBC

Portfix SBX-93546: Call transferring a call to the PSTN fails for the second time when the MOH is played in the initial call.

Impact: After multiple times on hold and resume, if the first call transfer fails due to a reject by transfer target, then the transferee and transferor are reconnected successfully. For any subsequent call transfer, the SBC is rejecting the call transfer request.

Root Cause: When the first call transfer fails, the SBC tries to reconnect the original call. As part of this, the original call is not moving to the stable state. Any call transfer request in an unstable state is being rejected by the SBC.

Steps to Replicate:

1. TEAMS to PSTN1 call.
2. TEAMS hold and resume the call.
3. TEAMS transfer call to PSTN2.
4. PSTN2 rejects the call.
5. TEAMS resume the call and transfer again to PSTN2.

Platform/Feature: SBC

A link verification through link monitoring fails, causing the link status to bounce frequently.

Impact: In the SWe with port redundancy, Link Monitors bounce on standby ports when there is lot of broadcast traffic.

Root Cause: There is a CLI configuration to allow/disallow broadcast ARP traffic on the standby ports.

admin@vsbc1% set system admin <systemName> linkDetection allowArpBroadcastProbeReply
Possible completions:
disabled enabled

This flag is disabled by default.

This feature was initially supported on the SBC 7K in 5.1 as part of previous bug (SBX-69409). In the SBC 7K, the NP was not allowing broadcast ARP traffic by default and as a result, the application did not need to explicitly set the default value of this flag. However in the SWe, the ARP broadcast traffic was allowed by default and a knob to control this traffic was provided in a hidden file even before this CLI was supported:

standby_rx_broadcast_enable in /opt/sonus/conf/swe/capacityEstimates/.miscConfigSwe.txt

When this feature was extended to the SWe, when application does not set this flag, the NP is referring to this file and enabling it by default.

Steps to Replicate: Bring up the SWe instance with port redundancy and configure the Link Monitors on all ports. Run tshark on standby ports and check if they are receiving any broadcast traffic.

Platform/Feature: SBC

Observed the NP log flood during a transcode call load in a X710 NIC card.

Impact: Intermittent flooding of the NP log with mbuf exhaustion messages when X710 NICs are used in large SWe/Cloud T-SBCs.

Root Cause: There was a reduction in count of the free mbufs available for the an NIC PMD.

Steps to Replicate: To replicate this issue, on a 32vCPU TSBC instance using X710 VFs for PKT interfaces, run the estimated call capacity using a single PKT interface (either PKT0 or PKT1).

Platform/Feature: SBC

Memory leak observed while running an overnight load of a Call Flow with 302 redirection.

Impact: Memory leak in the SWe_NP. The RSS memory of the SWe_NP process increased by 250MB for an over-night run.

Root Cause: In the configuration, the cdr-server configuration was triggering the ACL add/delete frequently. On every add/delete of ACL rule, the SWe_NP spawns a new thread and rebuilds the DPDK trie. There can be two threads running: one for ipv4 and one for ipv6. These threads are not detachable threads. As a result, the default memory allocated for a thread (ulimit -s) does not get back to OS on thread exit, which was causing regular memory leak.

Steps to Replicate:

1. Create a scenario by adding an ACL rule and deleting the same rule in regular time interval in a loop.
2. Observe the SWe_NP memory.

Platform/Feature: SBC

When signalingNapt is disabled on the ingress TG, the SBC populates the "PeerIP/Port" with the IP address and port from the Contact header of the incoming INVITE. When signalingNapt is enabled on the ingress TG, the SBC populates the "PeerIP/Port" with the IP address and port where the INVITE came from.

The expected behavior is that the PeerIP/Port would always be populated with the real IP:port where the INVITE came from.

Impact: PeerIP/Port is populated inconsistently.

Root Cause: The SBC is populating PeerIP/Port incorrectly based on whether signalingNapt is enabled or disabled.

Steps to Replicate: N/A

Platform/Feature: SBC

PortFix SBX-91567: The RX/TX PDUs/BYTEs not getting updated correctly in the SBC stats file for "SipSigPortStatisticsStats"

Impact: Statistics for the signalling port were not getting updated correctly in the .pms file.

Root Cause: Statistics were not fetched from SIPCM, which is where statistics are maintained. Instead, fields were directly updated from the SIPFE perspective and as a result, the stale counters were observed in the .pms file.

Steps to Replicate:

T1: Configured 2 signalling ports, 1 at ingress and the other at egress then made some calls and observed the .pms file without running the CLI.
T2: Configured 1024 signalling ports at ingress and 1024 signalling ports at egress then made some calls at 100th, 500th and 1000th signalling port, respectively and ensured proper update of statistics in the .pms file.

Platform/Feature: SBC

(Disable NP Policing based on feature flag) fix was not working on the D-SBC.

Impact: With the spikeAction set to Alarm, the SBC must not discard the non-confirming policer packets. However, on the D-SBC, the SBC was still discarding these packets.

Root Cause: On the D-SBC, the "spikeAction" configuration is found on the M-SBC, while the command to allocate resource comes from the S-SBC. Due to the allocated resources, the policerMode set from S-SBC is not matching with the policerMode (BYPASS) configured on the M-SBC to allow the over flow packets.

Steps to Replicate: The steps cannot be reproduced.

Platform/Feature: SBC

Incorrect String with Response Error code 500.

Impact: The SBC is replying to request with 500 error response code to the client with error string as "Internal Server Error".

Root Cause: The SBC is sending string "Internal Server Error" is not correct as per RFC3261 standards.

Steps to Replicate:

Verify the SBC responds to the request with "Server Internal Error" instead of the "Internal Server Error" for 500 response code.

Set Up:

1. Configure the SBC.
2. Make a configuration changes so that the SBC replied with 500 Response.
   Example:
   disable the Ingress sip trunk group.
3. Make a call.

Expected Result:
Verify the SBCs reply with the "Server Internal Error" string for the 500 response code.

Platform/Feature: SBC

Portfix SBX-94250: The S-SBC does not send any response after sending "100 Trying" for an incoming INVITE with a SDP that has no codecs in the PSP.

Impact: The SBC does not send any response after sending "100 Trying" for incoming INVITE with SDP that has no codecs in the PSP when precondition interworking is in progress.

Root Cause: The SBC waits on a precondition to complete from the ingress peer and as a result, does not send any response in this failure case.

Steps to Replicate:

1. Configure the SBC for ingress precondition interworking.
2. Send an INVITE with codecs not present in PSP.
3. The SBC must terminate the call.

Platform/Feature: SBC

Portfix SBX-93248: The sonusDatabaseConfigPolicyDataOutOfSync notification is raised from the S-SBC in the OAM network.

Impact: The configuration data is not stored in the policy DB for OAM and managed VM nodes. The PIPE application was used to raise the out of sync traps.

Root Cause: Existing PIPE logic was used to raise out of sync error whenever there is an out of sync condition. The logic is used between a policy DB and config DB.

Steps to Replicate:

1. There is a PIPE thread that periodically checks for consistency between the Config DB and Policy DB. The interval is configurable.
   CLI Command [set profiles dbSyncCheckProfile DEFAULT syncCheckInterval <interval duration>.
2. Through CLI as well the user can trigger to verify DB integrity.
   

   request system admin TACKS verifyDatabaseIntegrity Id all

   The command will trigger a check for the DB integrity and update the sync status and time stamp. It also raises trap if there is mismatch.

   So, a new status type "notApplicable" is added when this command is executed.

   show table system databaseIntegrity

   This command fetches the data updated by the above command and display on the console. Also, the output of this command will show the sync status as "notApplicable".

3. SBC Application restart.

Platform/Feature: SBC

The error response of PRACK must be relayed to the endpoint when the End-End PRACK is enabled and call must not be teared down.

Impact: Call is terminated whenever the error response is received for PRACK and End to End PRACK is enabled.

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

Steps to Replicate:

1. End to End PRACK is enabled.
2. PRACK responded with an error response.

Platform/Feature: SBC

Portfix SBX-91820: When the SRS does not respond to the SBCs request and if no redundant SRS is configured, the SBC sends BYE towards the SRS without XML. In case of load scenario when there are 'n' number of active calls towards a SRS and if scenario above occurs, the SBC releases entire 'n' recording calls in bulk.

Impact: When the SRS does not respond to the SBCs request and if no redundant SRS is configured, the SBC sends BYE towards the SRS without XML. In case of load scenario when there are 'n' number of active calls towards a SRS and if scenario above occurs, the SBC releases entire 'n' recording calls in bulk.

Root Cause: The API that is responsible for building XML body was not invoked when the release cause code was SIPSG_REC_REL_CLEANUP. This is designed to release the entire recording call when a recorder does not respond for a single call.

Steps to Replicate:

1. The Recording session is established with SRS server.
2. Trigger a Re-Invite scenario in the CS call.
3. The SBC triggers a separate Re-Invite towards the SRS.
4. Let SRS not reply to the Re-Invite.
5. Invite timeout at the SBC will case the above problem.

Platform/Feature: SBC

Portfix SBX-93261: The MSBCs switchover restarted two nodes.

Impact: On a node switchover on the D-SBC setup, the MSBC or SSBC can have SWe_NP coredump.

Root Cause: The issue occurred due to a code optimization in kni thread. The kni thread starts taking 100% CPU on the SWO due to large amount of ICM message flows.

Steps to Replicate: On the D-SBC setup, perform the switchovers on the MSBC

Platform/Feature: SBC

Portfix SBX-76605: The SBC must not depend on the processSgCOnfigureWhenTGOOS setting.

Impact: The SBC must not depend on the processSgCOnfigureWhenTGOOS setting.

Root Cause: The SBC is taking the precedence of the processSgCOnfigureWhenTGOOS flag over the internalSipCauseMapProfile.

Steps to Replicate:

1. Configure "TrunkGroupOutOfService" in the existing internalSipCauseMapProfile.
[set profiles signaling sipCauseCodeMapping internalSipCauseMapProfile <profile_name> causeMap
TrunkGroupOutOfService sipCause 504].
2. Attach the configured profile to the signaling zone.
[set addressContext <addressContext_name> zone <ZONE_INGRESS> signaling causeCodeMapping
sipInternalCauseMappingProfile <profile_name>]
3. Set the mode of the "ingress" trunk group as outOfService on the SBC.
[set addressContext default zone <ZONE_INGRESS> sipTrunkGroup <TG_INGRESS> mode outOfService]
4.Enable processSGConfigWhenTGOOS
set addressContext default zone <ZONE_INGRESS> sipTrunkGroup <TG_INGRESS> processSGConfigWhenTGOOS disabled
5. Make an A-B basic call.

Platform/Feature: SBC

Portfix SBX-93765: The CS04A01 lost communication with the CM04A04 and in post-recovery, other m-sbcs cannot communicate to the CM04A04.

Impact: The IPv6 address becomes unreachable in a standby port cable pull scenarios.

Root Cause: The SWe code was not saving the multicast MAC address list and re-applying it on a hardware port during a link up/down event for standby ports.

Steps to Replicate:

1. Bring down any standby port by cable pull on host.
2. Configure a new IPv6 address on the pkt port.
3. Re-insert the cable for same standby port.
4. Perform a port switchover by plugging out active physical port's cable so that standby becomes active for same port.
5. Ping the new configured IP from in step 2 from outside.

The ping will fail.

Platform/Feature: SBC

Portfix SBX-94092: The MGMT port is not reachable in the SLB.

Impact: The SWe_NP failed to come up in a large SLB cloud instance (i.e. 16 vcpu or more) with port redundancy enabled.

Root Cause: In the cloud, the default value of "DosSupportSecPktPorts" flag is set to "true", and requires an additional rx/worker thread to be spawned in case of port redundancy.

SLB and S-SBC uses standard_signaling_profile for the core partition. S-SBC only uses one worker for all vcpu configurations, where the SLB uses 2-workers for larger vcpus( > 16vcpu). If the DosSupportSecPktPorts=true, there will be additional worker threads required, so for this instance for the SLB, there will be secondary worker threads for each single worker. This case is not supported.

Steps to Replicate: Spawn a 16 vcpu SLB instance in the cloud using a Heat template. Check the MGMT port reachability.

Platform/Feature: SBC

Portfix SBX-90581: The PCAP file list (PCAP) is not displayed correctly if the file count exceeds more than 130.

Impact: When using the EMA and accessing the Call Trace/Logs/Monitors > Log Management > TShark, the screen does not list the files if there are more than 130 files in the directory.

Root Cause: Mismatch in the response header transfer-encoding.

Steps to Replicate: Create more than 130 PCAP files and try to display them under TShark screen.

Platform/Feature: SBC

Portfix SBX-93900: The IPIGs with underscores fails on a MSRP/RCS call on a decomposed P-SBC.

Impact: The MSRP call on the DBSC fails when configuring an IP interface group name greater than 7 characters.

Root Cause: Incorrect type cast was used while handling the GCID allocation response in the MSBC.

Steps to Replicate: Test a basic MSRP call with an ingress and egress interface group name set to "INTERFACE_LIG1" and "IPINTERFACE_LIG2" respectively.

Platform/Feature: SBC

Portfix SBX-91154: A call failure due to a FQDN in the request URI.

Impact: When the SBC sends a query for the SRV record to the external server and the Peer Domain in ReqURI is disabled, the SBC intermittently sends a FQDN in the reqURI of egress INVITE. The correct behavior is to the send IP and address in the reqURI of an egress INVITE. Without a fix, the SBC will send FQDN in reqURI even when Peer Domain in ReqURI is disabled.

Root Cause: The SBC does not use a formatted SIP message when the external query is made for finding a SRV record and a record is found in cache. The SBC cannot apply the setting of "Peer Domain in ReqURI" flag in an egress SIP message.

Steps to Replicate:

The following configurations on PSX Set IP PEER as FQDN abc.com instead of an IP address.

1. Enable "noPortNumber5060" on IPSP [ This is for done for NAPTR, SRV query ]
2. Disable "Peer Domain in ReqURI " on IPSP [ This is done to make sure we do not send FQDN in egress INVITE's reqURI ]
3. Use External DNS server.
4. Configure a SRV record and a record on the external DNS server with different Time To Live values. Run a high number of calls.

Platform/Feature: SBC

The SIP call never connects on the ingress intermittently. (GW-GW call).

Impact: For two-node M-SBC passthrough call, the SIP call never connects on ingress. The call hangs until the call control 5-minute timer expires.

Root Cause: An improper Node GCID setting on the second M-SBC node of a two-node M-SBC passthrough call causes an internal failure, resulting in a hung call.

Steps to Replicate: The steps cannot be replicated.

Platform/Feature: SBC: SIP

The DSBC IP and SIP SIG port IP was not reachable after the switchover.

Impact: LIF is activated on standby, even before the PRS process is cleaned up on standby in case the AMF process is terminated.

Root Cause: During the cleanup, the presence of a PRS process was not checked before sending a switchover event to peer.

Steps to Replicate: Kill the AMF process on active and ensure that LIF is not activated on standby before the PRS process is down on active.

Platform/Feature: SBC: Platform, Redundancy

Portfix SBX-93312: The SBC Memory was reading high alerts.

Impact: When the Local Ring back tone is configured on the SBC and the egress endpoint sends a 183 Session Progress with a SDP followed by a 180 Ringing, the SCMProcess does not free up memory allocated even after call is completed. Without a fix, the SCMProcess will leak memory.

Root Cause: When the Local Ring back tone is configured and the egress endpoint sends a 183 Session Progress with a SDP followed by a 180 Ringing, the SCMProcess does not free up media session descriptor structure.

Steps to Replicate:

Run a call load with Local Ring back tone configured and monitor virtual memory usage of the SCMProcess.
With a fix, the virtual memory of SCMProcess will not be high after all calls have been disconnected.

Platform/Feature: SBC

Portfix SBX-92252: The SBC was sending an INVITE out for the first user only.

Impact: Native Forking fail was sending out on the 2nd route.

Root Cause: If incoming call has a capital "CALL-ID", the SBC will fail to find the parent incoming call. As a result, forking will not occur.

Steps to Replicate: Treat the "CALL-ID" as case insensitive.

Platform/Feature: SBC

The P-Charge-Info header was not relayed by the SBC in an out-of-dialog MESSAGE request, even when the transparency setting is enabled.

Impact: The P-Charge-Info Header is not relayed transparently for OOD Message, even when the transparency profile is enabled for P-Charge-Info.

Root Cause: The P-Charge-Info Header is dropped in case of relay framework.

Steps to Replicate: Run the message OOD that has P-Charge-Info Header in the incoming Message and transparency is enabled for that header.

Platform/Feature: SBC

Portfix SBX-92580: The SIP domain was missing in the FROM header after an upgrade.

Impact: The DM rule for FROM Uri is not working.

Root Cause: It was introduced by a previous bug to treat the FROM Uri specifically for the RewriteIdentity only.

Steps to Replicate: Configure the PSX for the FROM Uri, and a simple SIP-SIP call. Verify the FROM header is picking up the DM rule of the FROM Uri.

Platform/Feature: SBC

Portfix SBX-92092: A possible memory leak in SAM process.

Impact: The SAM process will leak memory in the case where a de-REGISTER is received and then within less than 30 seconds, another REGISTER for same AOR is received.

This will only happen if Multiple contacts per AOR flag are disabled.

Root Cause: The code does not free certain memory blocks in this case.

Steps to Replicate:

1. Multiple contacts per AOR flag must be disabled.
2. Perform a Register for particular AOR and perform a de-register.
3. Within less than 30 secs, re-send the registration for same AOR so that SIPFE selects the same preferred slot that was used for registering the same AOR earlier. By registering multiple users with same time period, leak will be reproduced.

Platform/Feature: SBC

The SBC discards the inbound RTP stream.

Impact: The SBC discards media packets when a NAT is enabled, with Signaling and media IP listed the same, but the media port is translated by a NAT device.

Root Cause: In 7.2 the SBC has logic to disable a media NAT when the Peer IP and media IP are the same. The logic is causing issues when these IPs are set as true, but the Port is still being translated by a NAT device.

In this case, the peer IP and advertised media IP are 100.xx.x.xxx. The media advertised port is 1132. The actual media is being sent from port 1097. Due to the disabled media NAT, there is no access to the UDP port, resulting in policed media and no audio.

Steps to Replicate:

1. Enable the media NAT and a new flag (disableMediaNatIfSameMediaAndSigIP)
   1. Make a SIP-SIP call with the media IP and Signaling IP configured the same. Ensure the media NAT is disabled.
2. Enable the media NAT and disable a new flag (disableMediaNatIfSameMediaAndSigIP)
   1. Make a SIP-SIP call with the media IP and Signaling IP configured the same. Ensure the media NAT is enabled.

Platform/Feature: SBC

New CLI configuration is introduced as shown below:
addressContext->zone->sipTrunkGroup->Services->natTraversal-
>disableMediaNatIfSameMediaAndSigIP

CLI Syntax example:
set addressContext <name> zone <name> sipTrunkGroup <name>
service natTraversal disableMediaNatIfSameMediaAndSigIp enable

NOTE: The default value of the CLI commands is disabled.

The SBC SWe 8.01R000 is outOfSync between the CDB and PG/policyDB after Restoring the DB from V07.02.01R002 release.

Impact: The SBC SWe 8.01R000 is outOfSync between the CDB and PG/policyDB after Restoring the DB from V07.02.01R002 release.

Root Cause: The proper code was not present to display load configuration notification at the time of Platform manager login.

Steps to Replicate: The steps cannot be replicated.

Platform/Feature: SBC

The ATT P-SBC DelayedRBTOnlyIf180Rxd was not working.

Impact: The ATT P-SBC DelayedRBTOnlyIf180Rxd was not working.

Root Cause: When a 183 with the SDP PEM inactive is received, the SBC is going for tone play when Delayed RBT if a 180 received is enabled.

Steps to Replicate:

1. Delayed RBT if the 180 is received in tone Profile.
2. The EMA is enabled and THE Tone Profile is enabled.
3. The Tone criteria must match for delayed RBT if the 180 is received.
4. The 183 Response is received with the PEM inactive.
5. The SBC must not be directed to tone play.

Platform/Feature: SBC

The IngressIpPrefix data was deleted when removing the SMM from the TG.

Impact: The IngressIpPrefix data was deleted when removing the SMM from the TG.

Root Cause: When deleting a SMM Profile, the code is deleting the ipPrefix data as well.

Steps to Replicate:

admin@SBC5210b> show table metadata trunkGroupIpPrefixMeta
PREFIX
TG NAME IP ADDRESS LENGTH
------------------------------------
ASTERISK_SIP 10.158.171.6 32
GG_INGRESSTG 10.6.30.137 32
GW_TG 0.0.0.0 0

Platform/Feature: SBC

Portfix SBX-92470: The SAMP had a memory leak.

Impact: Possible slow memory leak in the SAM process when running GW-GW calls.

Root Cause: GWFE is leaking a copy of the incoming PDU, which was queued internally.

Steps to Replicate: The steps cannot be replicated.

Platform/Feature: SBC

Portfix SBX-91985: The SIP calls drop with a vertical service code *65 after a minute.

Impact: The SBC is unable to send the ACK to Egress for a call to connect.

Root Cause: There is a logical error when combining multi features (e2eAck, e2eReInvite, and DLRBT)

Steps to Replicate: Configure: e2e Ack, e2e reInvite, and DLRB

Issue 1: Egress response 183(sendrecv), 183(onhold), 180(no SDP), 200OK(sendrecv).
Peer change SDP in the 18x/2xx causing internal offer/answer.
Issue 2: Ingress peer sends reInvite rigth after ACK, causing the internal state is unable to send ACK out.

Platform/Feature: SBC

The NESSUS scan reports TLS violations against the SBC 8.0 OAM VNF.

Impact: On OAM nodes for EMA/PM, the TLS 1.0 is enabled along with TLS 1.2. By default only, the TLS 1.2 must be enabled.

Root Cause: On OAM nodes for EMA/PM, the TLS 1.0 is enabled along with TLS 1.2. By default only, the TLS 1.2 must be enabled.

Steps to Replicate:

1. Deploy an OAM node and check in /etc/apache2/sites-enabled/EMA.conf and 000-default.conf. The SSLProtocol will be set to +TLSv1.0 +TLSv1.2.
2. With fix build, it must be set to +TLSv1.2 only.

Platform/Feature: SBC

Optional fax parameters being parsed by the SBC and as a result, the 200 OK was being discarded.

Impact: There was a parser error for the unsupport t38 attributes.

Root Cause: There was a parser error for the unsupport t38 attributes.

Steps to Replicate: Perform an incoming call with unsupported t38 attributes.

Platform/Feature: SBC

Portfix SBX-92091: Call Graphs were showing more calls after an upgrade.

Impact: Stale calls may be found on a newly upgraded SBC, when upgrading from a version older then 6.1.0 to a newer release.

Root Cause: As a result of changes that were made to the call ID in 6.1 code, during LSWU any calls that existed prior to the upgrade and were then modified or terminated after the upgrade started will be left in a hung state.

To clean up the call, use the following commands:
unhide debug
request sbx rtm debug command “cleanup <gcid>

Steps to Replicate:

1. Create audit key greater than 31 by multiple switch over on HA system or by using instrumented code.
2. This will create GCID values using the high bits ( bit 30-31 ) of GCID value.
3. Setup SIP calls on the system.
4. Initiate LSWU on standby and after standby is upgraded to newer version , all the established calls on active will be synced.
5. Start LSWU on active.
6. At this point standby will become Active.
7. Hang up calls which established before standby became Active.
8. Issue "show table global callSummaryStatus" CLI command and for all those calls data will be Unavailable.
9. These calls will consume resources.

Platform/Feature: SBC

Portfix SBX-90877: There was a failover from Node-A to Node-B.

Impact: There was a healthcheck failure while switching from Node-A to Node-B

Root Cause: Functions that configure the DRBD subsystem are taking longer and causing a healthcheck timeout.

Steps to Replicate: The steps cannot be replicated.

Platform/Feature: SBC

Portfix SBX-90619: The error status of the import CLI configuration is not reflected in the GUI.

Impact: The error status of the import CLI configuration is not reflected in the GUI.

Root Cause: The session was deleted before the failure message propagated to the UI.

Steps to Replicate: The steps cannot be reproduced.

Platform/Feature: SBC

After an upgrade, the SWAP partition has the wrong UUID.

Impact: File the /etc/fstab had an incorrect UUID for the swap partition, with the timeout logs were seen on the boot-up.

Root Cause: As part of multiple upgrades going through different versions, the swap partition UUID had been changed but the same is not reflected in the fstab file.

Steps to Replicate: Install/Upgrade to fix version and ensure there is no swap entry in fstab file and that there also is no timeout logs.

Platform/Feature: SBC

Portfix SBX-90584: The EMA SMM regular expression was inconsistent.

Impact: EMA SMM regular expression inconsistency.

Root Cause: Earlier when \n\r was used in regular expression in CLI, the corresponding characters (\n,\r) were not visible in EMA.

Steps to Replicate: The steps cannot be reproduced.

Platform/Feature: SBC

The CLI stops at D2SSBC11.

Impact: The SBC web server sessions including the configuration import session were getting terminated during log rotation.

Root Cause: Process was getting killed because of the application session expiring.

Steps to Replicate: The steps cannot be replicated.

Platform/Feature: SBC

Portfix SBX-90875: The LSASBX71 switched over and as a result, both sides cored.

Impact: A bug in GW Signaling code can cause a core when the GW Signaling Links are bouncing.

Root Cause: A bug in GW Signaling code can cause a core when the GW Signaling Links are bouncing.

Steps to Replicate: The steps cannot be replicated.

Platform/Feature: SBC

Portfix SBX-90442: Dead air on the SBC terminated calls when playing announcements.

Impact: A fix correctly calculates the amount of memory that needs to be freed from the NP (say Y, which is a multiple of certain number of fixed sized buffers) to fit in a new announcement of size WavFile_X. Due to the design, Y is not equal to WavFile_X.

Root Cause: This issue was caused because the max amount of announcements cached in the system was tampered.

Steps to Replicate: Run a customer flow with customer's announcements all dumped into the system.

Platform/Feature: SBC

The trunkGroupQoeStatus shows the incorrect values.

Impact: The SBC was showing the static output as 94/93 for Qos parameters even when the trunk was running call. While checking the CDR for the call, the CDR contained invalid values (that depends in RTP packets) for QOS field.

Root Cause: For cloud platforms, the Routing state was fetched from "configContextPtr" where as the Routing state is stored under the "currentContextPtr."

Steps to Replicate:

1. Set the global qoeCallRouting signalingQosBasedRouting to disabled.
2. Set the global qoeCallRouting mediaQosBasedRouting to enabled.
3. Make a call with the Media.
4. Show the table addressContext default zone as ZONE1 trunkGroupQoeStatus. Verify the value of outbound RFactor.

Platform/Feature: SBC

Portfix SBX-90415: A bug in the EMA table views.

Impact: All filters are not displayed for the tables like Call Detail Status, Call Media Status, and Call Resource Detail Status.

Root Cause: The code changes were done to display the filters for all columns in the tables mentioned.

Steps to Replicate:

1. Login to the EMA.
2. Navigate to Monitoring > Trunks and Subscribers > Sessions > Call Detail Status screen.
3. Filter the boxes above and the column will be displayed.

Platform/Feature: SBC

The code is modified so all the attributes are marked irrelevant for the filter.

Portfix SBX-85820: The CDR records are broken into multiple syslog messages.

Impact: The CDR records are broken into multiple syslog messages.

Root Cause: There was a limit to the message size of ~1.8K and the CDR messages beyond that will be split into multiple syslog messages.

Steps to Replicate:

1. Generate CDR's(size>1800) and transfer to remote syslog server.
2. The SBC now transfers CDR's (size >4K) over to syslog server without breaking into multiple messages.

Platform/Feature: SBC

The Santa Clara SBC02B failover.

Impact: A CHM thread acquired a lock and started a long running operation. The health check timer on another thread waiting for the lock expired and the app crashed.

Root Cause: The issue was from an existing code with locks.

Steps to Replicate: Installed a fix build and ran sanity tests.

Platform/Feature: SBC

The ScmP cored while importing CLI commands from the SBC Configuration Manager.

Impact: The SIP process dumps core while importing the bulk CLI from the configuration manager.

Root Cause: Due to duplicated bug, the FXS files (CLI schema files) were copied to the directory /opt/sonus/sbx/fxs. The copied FXS files resulted in near doubling of CLI execution time, resulting and delayed responses to the health check requests. Overtime, the SIP processing module is unable to respond to the health check request and dumps core.

Steps to Replicate: Source the bulk configuration using the CLI.

Platform/Feature: SBC

The CPX may core during an upgrade from V05.01.05R000 to V07.02.01R001.

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

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

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

Platform/Feature: SBC

Portfix SBX-87527: Conflicting IP address settings in the SBC.

Impact: The SBC allowed the user to use the same IP address for route next top that caused a loss of traffic to all off-net peers across this interface.

Root Cause: A 8.2.0 original issue.

Steps to Replicate:

1. set addressContext default ipInterfaceGroup PKT1_53_PUBLIC ipInterface PKT1_53_PUBLIC altMediaIpAddresses 66.43.97.129
2. set addressContext default staticRoute 47.44.160.79 32 66.43.97.129 PKT1_53_PUBLIC PKT1_53_PUBLIC preference 100

Platform/Feature: SBC

Remove the alarm that shows that the licenses exceeds the system limit.

Impact: The sonusCpConfiguredExceedSystemLimit alarm was raised for the SWE and CLOUD instances. The session limit is depending on the HW(VCPU) being used and the alarm is only applicable for the Hardware platform.

Root Cause: There was no check completed for platform before raising this alarm.

Steps to Replicate:

1. Verify the SWE or CLOUD SBC instance does not raise the sonusCpConfiguredExceedSystemLimit alarm when the license is installed more than 64000.
2. Spawn the instance on the CLOUD or SWE
3. Install the license bundle if on nodelocked /NWDL with any number of session license(SBC-RTU).

Expected Result:
sonusCpConfiguredExceedSystemLimit alarm will not be raised.

Platform/Feature: SBC

The SIP ReInvite race condition causes a call failure for relay cases.

Impact: The SIP ReInvite race condition causes a call failure for relay cases

Root Cause: When the End To End Re-Invite is enabled and the Session Refresh is received, the SBC used to only relay it to another leg skipping Offer-Answer negotiation. This is causing the Race-Conditions and causing call failures.

Steps to Replicate: Enable the End-To-End Re-Invite and run a Session Refresh call flow.

Platform/Feature: SBC

The SMM header criteria was not matching the complete header value.

Impact: The SMM header was criteria not matching the complete header value, it was only checking for the value between <>.

Root Cause: The SMM was only checking the value enclosed between <>.

Steps to Replicate: Write a criteria on header value and the issue will be reproduced.

Platform/Feature: SBC

The Asymmetric PRACK Interworking" was not working as described.

Impact: Whenever any CodecEntry is deleted from codec list in PSP in the PSX, it re-arranges the codec list immediately. There will not be any empty codec entry on the list.

Root Cause: When any CodecEntry is deleted, it was not re-arranging the CodecEntry, which adds a NULL value in that place.

Steps to Replicate:

1. Configure CodecEntry1, CodecEntry2 all the way to CodecEntry12
2. Delete any CodecEntry.

Result: Call will succeed.

Platform/Feature: SBC: ERE

Portfix SBX-93456: The SWe_NP worker segfault was crashing.

Impact: There is an issue in the JIO (SBX-93456), where the SWe_NP was crashing multiple times due to a skb_work->skb corruption.

Root Cause: When observing the SWe, there is a point in normal media processing ( RTP and RTCP path), where there is an update with the skb_work->skb from addr_ptr that is not necessary, and it may corrupt the skb_work->skb.

The corruption occurs in the path of processing RTCP XR packets, where the addr_ptr moves ahead by few bytes, but the UPP processing expects the MBUF address to be present back at 58 bytes from the addr_ptr.

Steps to Replicate: Run JIO scenarios.

Platform/Feature: SBC