Page History

V07.02.00S810

The SBC was displaying the incorrect Routing info in the GUI and the correct info in CLI.

Impact: The GUI is displaying the incorrect routing information for the routing labels, memory usage, and the zone in the routing label.

Root Cause: Incorrect routing information for the routing labels occurs as few records are fetched for Routing labels list. The EMA application was taking the memory information in a wrong way from the free command.

Steps to Replicate: 

1. Go to the routing page and create a Routing Label and edit the label.
2. Correct the Routing label information should be shown.

Platform/Feature: SBC

The code is modified so the call to get routing labels list has no limit and gave the table option to select the Routing Label in route create/Edit form.

Workaround: N/A

Portfix SBX-100249: The PRS process core occurred on the Standby Server.

Impact: The PRS process cored due to the XRM accessing a NULL pointer inside of the XRES data structure.

Root Cause: The root problem was that the pkt2 on standby node was stuck in the DOWN state due to possible network switch issue while the pkt2 on active node was functioning as normal. All activated XRESs selected on the LIFs of pkt2 were mirrored to the standby and got inserted in the deferredXresList waiting for standby pkt2 to be UP.
Then when one of those XRESs is reused for a different call and mirror to standby node, that XRES may still stuck in the deferredXresList because the deallocate request may have not been processed yet on the standby node. Then the PRS hit the coredump caused by the XRM accessing the NULL pointer inside of the XRES data structure.

Steps to Replicate: There is an SBC HA pair, an active node has pkt ports all UP, and standby node has at least one of the pkt port DOWN, for example, the pkt1 is DOWN.

Start a fairly high call load and to ensure calls are picking LIFs of pkt1 on an active node in the example, and to ensure XRES on the pkt1 are being re-used.

Note: The standby pkt1 should stay DOWN all the time during the test.

Platform/Feature: SBC

The code is modified to properly free the XRES in deferredXresList so that it can be re-used for the new call.

Workaround: Manually keep the pkt ports sync between active and standby nodes.

Portfix SBX-99999: The SCM Process coring when surrogateRegistration userPart is configured with 125 character.

Impact: Run the Surrogate Registration scenario with UserName at 127 characters . Then do show status addressContext ADDR_CONTEXT_1 sipActiveGroupRegStatus

Root Cause: Input Buffer is less so its causing a system error

Steps to Replicate: 

1. Configure surrogate registration with just retry timer and regAuth password. Omit user part and enable the state.
2. Disable the state.
3. Configure userpart for ip peer as "SvttEsT$%&=". Enable the admin state of surrogate registration.
4. Configure userpart for ip peer as "4569$suRR_Reg-/test". Enable the admin state of surrogate registration.
5. Configure userpart for ip peer as "sip~5u6ser*.*parT%". Enable the admin state of surrogate registration.
6. Configure maximum allowed characters for userpart which is 127 qwertyuiopasdfghjklzxcvbnmMNASDFGHJKL&2345678sdfghnjmkjukl=
   45+fsadsvydus/uwybwusniwudyw8dbniwu%$wiudnowisopwqmisPQ%,wydwyndwq9h
7. Configure more than 127 characters for userpart. Enable the admin state of surrogate registration.

Platform/Feature: SBC

Input to StrnPrintf function has been calculated based on the size remaining.

Workaround: Run the system in normal mode, it will not coredump. Only coredumps in engineering lab when running in sensitive mode to indicate potential truncation of data.

Portfix SBX-99338: A SCM process core dump was observed for the challenged invite call.

Impact: A SCM process coredump occurred when running and INVITE challenge call flow.

Root Cause: The buffer is becoming zero, and that is why the system is getting a the System Error and coring in sensitive mode.

Steps to Replicate: Run a call-flow containing challenging of INVITE.

Platform/Feature: SBC

The code is modified for greater than 0 for the formatparamvalue cmd.

Workaround: Run the system in normal mode, it will not coredump. Only coredumps in engineering lab when running in sensitive mode to indicate potential truncation of data.

Portfix SBX-98991: The AddressSanitizer detected a global-buffer-overflow on address 0x55c93b015fa4.

Impact: While checking for two IPs in the same direct media NAT table the code was reading off the end of an internal buffer.

Root Cause: While trying to process the net mask for the IP addresses the code was using an index of 33 and reading of the end of the internal table with 32 entries.

Steps to Replicate: This issue is only highlighted in the development lab when testing direct media NAT call flows with an ASAN enabled build.

Platform/Feature: SBC

The code is modified to no longer read of the end of the table.

Workaround: N/A

Portfix SBX-99791: The AddressSanitizer detected a heap-use-after-free on address 0x62a000396280 at pc 0x563d8352c45c bp 0x7f03c92740b0 sp 0x7f03c92740a8.

Impact: On a D-SBC setup when disabling the signaling port used for the S-SBC to M-SBC communication and then making further configuration changes it was resulting in invalid memory read.

Root Cause: When the signaling port was disabled, the code was freeing up a list of sockets that were using the port. However it did not set the primary socket pointer to be null when the associated socket memory was freed up. This resulted in an invalid read when trying to re-enable the signaling port.

Steps to Replicate: This issue is only highlighted in the lab when using ASAN enabled images and then disabling the signaling port and making further configuration changes.

Platform/Feature: SBC

The code is modified to ensure that the internal pointer to the primary sock used for the connection is set to null when the socket memory is released.

Workaround: Do not disable the signaling ports.

Portfix SBX-100152: A core dump resulted on a basic call (softphone --> Teams) after enabling this flag "usePsxRouteforRegisteredInvite".

Impact: While testing PSTN to MS Teams call flows with surrogate registration and having the configuration flag usePsxRouteforRegistedInvite enabled it was resulting in SYS_ERR for attempt to free an ICM message which had already been freed.

Root Cause: In this particular call scenario the code was re-invoking itself multiple times and then hit a DNS failure. This caused the inner most functionality to free up and ICM message block. However as the stack unwound the initial invocation still had a pointer to the ICM message block and tried to free it.

Steps to Replicate: Make a call from PSTN to Teams without having a DNS server configured.

Platform/Feature: SBC

The code is modified to ensure the ICM message is only freed once.

Workaround: Ensure the DNS lookups do not fail as this coredump only occurs when running in sensitive mode. Only SYS_ERR will be generated when running in normal mode.

Portfix SBX-99457: The AddressSanitizer detected the heap-use-after-free on the address 0x6070001153f0 at pc 0x5588611ec65d bp 0x7fbd2d86daa0 sp 0x7fbd2d86da98.

Impact: In an M-SBC deployment when making the M-SBC out of service, the code was accessing memory after it had been freed up.

Root Cause: As part of the deactivation processing, the M-SBC memory block was getting freed up in a child function but the parent function still had access to the pointer and was reading from it on returning back up the stack.

Steps to Replicate: This issue is only highlighted in engineering lab when using ASAN images and taking the M-SBC out of service.

Platform/Feature: SBC

The code is modified to avoid reading from the memory block after it is freed.

Workaround: Do not take the M-SBC out of service.

Portfix SBX-99773: The ASAN detected an heap-buffer-overflow in Ss7LibGenerateCarrierCode while running an SIP to SIP-I call with PCV header.

Impact: For a Customer ISUP when the code was generating the carrier information transfer (CIT) parameter, it was reading off the end of an allocated memory buffer.

Root Cause: If the PSX does not provide carrier code information to include in the CIT parameter, the SBC was not allocating a large enough memory block. The memory block was used to hold the potential CIT parameter being generated. The SBC was reading of the end of the memory block at the position where the CIT parameter would have been, to decide if a carrier code had been generated.

Steps to Replicate: This issue is only reproduced when running call flows with ASAN images in the engineering lab, it was observed when running regression for ttc-charging parameter in the P-charging-vector header.

Platform/Feature: SBC: Application

The code is modified to avoid reading off the end of the memory buffer.

Workaround: N/A

Portfix SBX-98591: The SCM process cored for cases when there is an embedded header in 3xx in 7.2.4R0. 

Impact: The SCM process coredumps when there are no generic parameters present in the Embedded Header of the contact in 3xx response message.

Root Cause: The root cause is because the ParamCount being increased even before parsing the parameter.

Steps to Replicate: 

1. 'Honor embedded headers in 3xx' is enabled in IPTG.
2. 'forceRequery' is enabled in IPSP.
   
   Run a SIP-SIP Call.
   Egress INVITE is re-directed with 3xx and Contact header has DTG and embedded Route header and end point's IP.

Platform/Feature: SBC

The code is modified so a new variable RealParamCount is increased when there is a valid parameter.

Workaround: N/A

Portfix SBX-97944: The ZMQ coredumps on the SLB when changing the common interface from IPv6 to IPv4.

Impact: When the user changes the interface used by the SLB for communications with the SBC's, the SLB may sometimes generate a core dump.

Root Cause: When the interface is changed, the SLB shuts down the existing messaging interfaces and threads that interact with a third-party library called zeromq. This shutdown procedure was not working properly and led to a core dump.

Steps to Replicate: Modify the interface used by SLB to communicate with the SBC's and verify that no core dumps are seen.

Platform/Feature: SBC

The code is modified so the software shuts down the threads on an interface with zeromq so that it is done correctly. 

Workaround: Do not modify the interface used by the SLB to communicate with the SBC's, or do so in a service window to minimize the impact of a potential reboot.

Portfix SBX-99610: The SBC is coring on the SCM process 3 on a switchover SBX31337.

Impact: The SCM process coredumped while relaying the UPDATE message.

Root Cause: The SBC was dereferencing a NULL pointer and causing the coredump.

Steps to Replicate: Execute a test case where an UPDATE message needs to be relayed through the SBC.

Platform/Feature: SBC

The code is modified to verify the pointer is not NULL before using it, to avoid the problem.

Workaround: N/A

The trunk group routing does not working when SIP-I call is received.

Impact: The tgrp/trunk-context information in the R-URI and contact headers of an INVITE are not passed to the PSX/ERE as originating and destination trunk group parameters if the INVITE contains the ISUP MIME content.

Root Cause: The parameter were only being processed when there was no ISUP MIME content. There was not a prior requirement for them to be used with ISUP MIME content.

Steps to Replicate: Send an INVITE message to the SBC that contains ISUP MIME contact as well as tgrp/trunk-context parameters in the R-URI / contact header and ensure they appear in the INPUT DATA section of the policy request.

Platform/Feature: SBC

The code is modified to process the tgrp/trunk-context information in the R-URI and contact headers and pass up in the policy request to PSX/ERE.

Workaround: The SMM can be used to convert the tgrp parameters to DTG/OTG parameters that are supported with SIP-I content.

The OAM SBC had a failover/switchover.

Impact: There as a recurring random OAM switchovers have been noticed at the customer site.

Root Cause: The VNFR REST message key and/or value may be NULL. This causes the std::string type instantiation to fail and bring down the SBC application.

Steps to Replicate: The problem cannot be reproduced, the issue was fixed based on coredump and core review.

Platform/Feature: SBC

The code is modified to handle the cases where the std::string is instantiated with a NULL value.

Workaround: N/A

The SBC sends a 403 Forbidden message when receiving a Refresh SUBSCRIBE message.

Impact: Initially, the registration is done for the user. The SUBSCRIBE message came from a registered user and subscription is active
When subscription is active, the user got de-registered(or somehow the registration lost). After loss of registration, received a refresh SUBSCRIBE for existing subscription, the SBC is rejecting the refresh SUBSCRIBE saying the user should be registered.

Root Cause: The SBC rejecting refresh SUBSCRIBE when it comes with in a existing SUBSCRIPTION when registration is not available.

Steps to Replicate: 

1. Register the user.
2. Send a SUBSCRIBE from registered user.
3. Cleanup the registration.
4. Send a refresh SUBSCRIBE for the existing subscription from the same user.

Platform/Feature: SBC

The code is modified that when active subscription is available and registration is lost and then when getting the refresh SUBSCRIBE for the existing subscription, then accept the refresh SUBSCRIBE instead of rejecting it.

Workaround: SBC

A customer reported an issue in the EMA on the SBC Core 8.2.0R0.

Impact: 

Issue 1:
When creating a Routing Label, you are unable to view more than 15 IP Peers when trying to add a Routing Label Route to it.

Issue 2:
When creating a Route, the interface defaults the Call Parameter Filter Profile field to "CALL_MSG_TYPE_INFO" where as in earlier releases it was defaulting to "none".

Root Cause: By default, it is selecting the first option in the drop down.

Steps to Replicate: 

1. Log into the EMA.
2. Navigate to route and routing label screen(Configuration->System->Provisioning-> Routing).
3. We can verify the issue in the screen.

Platform/Feature: SBC

The code is modified so by default, it shows "none" on the default drop down option.

Workaround: N/A

An INVITE replaces a failure for only a G722 call.

Impact: The REFER call handling fails when only the G722 codec is selected in the packet service profile for all the required routes.

Root Cause: Originally, the SBC/GSX only supported a small subset of codecs Then additional codecs including ILBC and G722 were added in. When these new codecs were added the SBC/GSX started to pass a flag to the PSX that is supported the new codecs. This indicator bit is only being passed up when processing an INVITE and not when processing REFER message. This can result in call failures when processing REFER messages if the Packet service profiles being used for the new egress call leg only support codecs that are not in the list, because the PSX drops any other codecs if the REFER does not indicate that the newer codecs can be supported.

Steps to Replicate: Configure a call flow where the ingress and egress trunk groups only support G722 set up the A to B call and then try to do a REFER to C that should exist on either the ingress or egress trunk group.

Platform/Feature: SBC

The code is modified to pass an indicator to the PSX when processing the REFER that the SBC can support the newer codecs.

Workaround: N/A

Portfix SBX-100063: The From header was wrongly impacted by SMM.

Impact: The SMM was adding the duplicated generic parameters in header with the tel scheme.

Root Cause: After the first rule, the treat header as URI, the 2nd rule treat as generic, the SMM format the 2nd rule actions with duplicated generic parameters.

Steps to Replicate: The first rule was testing with URI parameter type. The second rule store the header value into local var and create a new header based on local a local variation.

Platform/Feature: SBC

There were logical error on the second rule when trying to reconstruct the URI header into generic header that added the duplicated generic parameters.

Workaround: Avoid using the URI parameter from the first rule. One may want to use regex instead.

The CLI input time may be delayed in the "V08.02.00R002" environment.

Impact: The SMM Profile, Rules, Criterions and Actions configuration was taking too long in the validation phase to check max limits.

Root Cause: The SMM Profile, Rules, Criterions and Actions configuration was taking too long in the validation phase to check max limits.

Steps to Replicate: Create the max SMMs allowed and test how long it takes as well to check the system Metadata entries. Delete some Profiles and check the entries present and respective Metadata.

Platform/Feature: SBC

The code is modified for the SMM rule, SMM Action and SMM criterions, which will check the cap limit.

Workaround: N/A

The pathCheck issue occurs when the TLS is in use, the SRV DNS lookup returns the port 5061 and the SBC increments it by 1 when initiating the TLS connection.

Impact: When the pathCheck is enabled on a FQDN based ipPeer, and the TLS transport is specified, the port number returned by the DNS SRV query for the TLS (_sips._tcp) is incremented by 1 causing the wrong port number to be used.

This problem only effects the transmission of the PATHCHECK OPTIONS pings when the TLS transport is specified, and the port number is obtained by DNS SRV query for TLS. There is no direct effect on SIP calls.

Root Cause: The SCM process incremented the port number passed to it by the PATHCHECK
when it should not have, in the case where the port number was obtained by a DNS SRV query for "_sips._tcp" (TLS).

Steps to Replicate: Define a pathCheck profile with the TLS as the transport preference:

• See: SBX-97947 Steps to Replicate

Platform/Feature: SBC

The code is modified so that the port numbers obtained by a DNS SRV query for "_sips._tcp" (TLS) are not incremented.

Workaround: Configure the FQDN based ipPeer's pathCheck hostPort to the appropriate port number.

The M-SBC crashed due to memory congestion with no memdump/core.

Impact: Observed the resource memory congestion level 3 is approaching the threshold 90 sample 80 at the M-SBC.

Root Cause: When the Link detection is configured, the raw sockets are created to exchange the ICMP pings on an active port and ARP probe messages on the standby port.

Whenever a port switchover is initiated, these sockets are closed and re-opened as the role of the port changes.

Due to a bug in the code, these sockets were not getting closed and new sockets were opened. This leads to a memory leak due to stale sockets under the constant port toggling condition and eventually lead to a memory congestion.

Steps to Replicate: Create a link detection group with the link monitors configured on both ports in redundancy group.

Add the ACL to drop ICMP packets from the destination configured in Link Monitor. This results in constant port switchovers.

Platform/Feature: SBC: Call Control

The code is modified to make a standard system close () instead of the ACE close() to close the socket upon a port switchover.

Workaround: N/A

After adding the second mgmt port in the 23vcpu ISBC (in RHEV platform 8.2.1 build), pkt and mgmt port messes up.

Impact: On adding the extra management port in the large instance without redundant PKT ports, SWe_NP process crashes.

Root Cause: A bug in the code polled a non-existent port id on adding the extra management port resulting in a crash.

Steps to Replicate: Make a large instance >15vCPU(default profile) without the redundant packet ports.
Add the extra management port and reboot.

Platform/Feature: SBC: Platform

The code is modified to fix the polling of extra management interface for large instances case in SWe_NP code.

Workaround: N/A

A response for the OPTION message received from TEAMS does not have a domain name in contact.

Impact: The contact header sent in the 200 OK response to out-of-dialog OPTIONS message in MS Teams Zone contains an IP address. It should contain a FQDN.

Root Cause: The Out-of-dialog OPTIONS message received in the MS Teams Zone.

Steps to Replicate: Send an Out-of-dialog OPTIONS message in the MS Teams Zone.

Platform/Feature: SBC: MS Teams

The code is modified to populate the zone domain into the contact header of a 200 OK.

Workaround: Use the example SMM at the link below to work around the issue.

• SBX-98580 SMM Example

Unable to change the username of a configured AD Domain Controller through the EMA.

Impact: When creating a domain controller from the EMA, the username validation was failing for the special characters because of being unable to create a domain controller.

The CLI was accepting the special character for the username and was able to create a domain controller.

Root Cause: The username validation was failing because the username param was not part of the netconf request and the netconf was throwing error.

Steps to Replicate: TBD

Platform/Feature: SBC

The code is modified so the EMA validates the username param based on default regex that is in the yang file.

Workaround: N/A

Portfix SBX-95679: There are no trunks data on the live monitor.

Impact: The Zone and Trunk Group based live monitor charts does not show any data if the trunk group name contains a hyphen.

Root Cause: The Elastic Search interprets a 'hyphen' as a delimiter and as a result the string is broken down into tokens for indexing.

When querying the ElasticSearch for data with trunkgroup name containing 'hyphen', no data is retrieved as the Elastic Search has stored the data not with the actual trunkgroup name but with tokens.

Steps to Replicate: 

1. Create a trunkgroup with the name containing hyphen.
2. Enable the Live Monitor.
3. Run calls and wait for sometime.
4. Verify data is shown in the Zone and Trunk Group based charts

Platform/Feature: SBC

Before querying the ElasticSearch for data, check if the trunkgroup name contains a hyphen, if it does then it is broken into tokens and the token is used to query for data.

Workaround: N/A

Portfix SBX-96953: Investigate the PATHCHK process coredump.

Impact: The Pathcheck process may coredump (due to healthcheck timeout) when the zone tracerouteSigPort is enabled, and the traceroute takes longer than 45 seconds to complete (after the endpoint becomes BLACKLISTED).

Root Cause: The Pathcheck process coredumps due to a healthcheck timeout when the traceroute to the BLACKLISTED endpoint takes longer than 45 seconds to complete.

Steps to Replicate: Enable the zone tracerouteSigPort, and configure an ipPeer in that zone that will the become BLACKLISTED, and the traceroute to that ipPeer takes minutes to complete.

Platform/Feature: SBC

The code is modified to handle slower/longer traceroute completions.

Workaround: N/A

Portfix SBX-96255: The leakSanitizer detected memory leaks in the SipDialogResizeRouteSetCmd.

Impact: Detected a memory leak in SipDialogResizeRouteSetCmd when running a Subscribe Notify call flow.

Root Cause: The SipDialogResizeRouteSetCmd will cause a memory leak in the case of an error scenario.

Steps to Replicate: This issue is only reproducible when using ASAN images in engineering lab.

Platform/Feature: SBC

The code is modified to fix the memory leak in this function.

Workaround: N/A

Portfix SBX-98319: The AddressSanitizer detected heap-use-after-free in the MrfRmCallControlBlock.

Impact: Heap after free memory use is deleted when running the MRF Regression.

Root Cause: Free the mrfrmCcb in the OANULL::ntwkDiscHndl, as we access the mrfrmccb in mrfRmCallFsm.

Steps to Replicate: This issue is only reproducible when using ASAN images in engineering lab.

Platform/Feature: SBC

The code is modified not to free the MrfRmCcb in OANULL::ntwkDiscHndl, but setting a Destoy_ccb bit.

Workaround: N/A

Portfix SBX-97576: ERROR: The LeakSanitizer detected memory leaks at the SipDialogEnablePDUTrace.

Impact: There is a leak detected when running a Video Regression.

Root Cause: The memory is being allocated without checking whether it has been allocated before or not.

Steps to Replicate: This issue is only observed when running call flows with ASAN images in the engineering lab.

Platform/Feature: SBC

The code is modified to free memory before allocating the new memory.

Workaround: N/A

Portfix SBX-99158: The CDR records for 230 and 231 subfields are not getting populated in the Video in bundle with rtcp-mux and ICE scenario.

Impact: In certain call scenarios with bundled media streams, when the additional streams are added to the existing bundle this results in the SBC media not being configured correctly, resulting in the call CDR STOP record not showing correct data for fields.

230. Media Stream Data - All the media streams data.

231. Media Stream Statistics - All the media streams statistics.

Root Cause: The policer mode for a bundle slave stream was not coded with the correct default value.

In the SBC release 8.1.0, additional validation checks were added to reject media configuration if the policer mode did not have the expected value, this resulted in media configuration failing when bundle slave stream is added.

Steps to Replicate: Testcase Procedure:

set iceSupport iceWebrtc
set sdpAttributeSelectiveRelay enabled

1. Initiate a call with Video in a bundle with rtcp-mux and ICE.
2. Response from farside accepts the offer with Video as part of the bundle.
3. Send STUNs for the master Video stream for RTP only.
4. Send a re-INVITE adding a audio stream to the bundle.
5. Response from farside accepts the stream.
6. Send a re-INVITE adding a slides stream to the bundle.
7. Response from farside accepts the stream.
8. Clear the call and check CDR stop record.

Expected Results:

Validate Bundling happens:

1. INVITE contains bundle with Video.
2. 200 OK from SBX contains Video in a bundle with rtcp-mux and ICE.
3. ICE Completes for all streams on both sides.
4. INVITE sent out with Audio and Video in a bundle with unique port and ICE information.
5. Response sent with Audio and Video with matching bundle information.
6. INVITE sent out with video+audio with matching bundle information and slides with unique port and ICE information.
7. Response sent with Video+Audio+Slides with matching information
8. CDR stop record should have sub-fields for fields 230 and 231 correctly populated.

Platform/Feature: SBC

The code is modified to set the correct default policer mode for bundled streams.

Workaround: N/A

Portfix SBX-57200: Implement the EMA Solution for the SBX-56878 issue: the CDR Viewer and Live Monitoring cannot be enabled/disabled.

Impact: Due to Red-Indices, the CDR Viewer and Live Monitoring cannot be enabled/disabled.

Root Cause: Due to Red-Indices, the CDR Viewer and Live Monitoring cannot be enabled/disabled.

Steps to Replicate: 

1. Have a Red-Indices file.
2. Try to enable/disable(Change state) of Live Monitor and CDR Viewer.
3. Wait for scheduler to execute check if red-indices file deleted.
4. Try to change the state.

Platform/Feature: SBC

The code is modified to check and delete if any Red-Indices present. Handle the class instead throwing exception, it catches.

Workaround: N/A

Portfix SBX-99951: When sending a message to the egress side, the SBC is sending a MIME-Version twice.

Impact: When the Mime Header is received along with the multipart method, the MIME header is going twice in the outgoing Message Method when the transparency is enabled.

Root Cause: The Two Headers are going to 1 because of Transparency and another one added by the SBC.

Steps to Replicate: Run a Subscribe call flow with the Multipart body and transparency enabled for Mime-Version header.

Platform/Feature: SBC

When the Multipart body is present, do not add header by transparency.

Workaround: The SMM can be used to remove duplicate header.

Portfix SBX-98678: The RE-INVITE for a 200 OK from the SBC is having two different m-lines with the sendonly for audio and sendrecv for video during a DM call.

Impact: The Re-INVITE for 200 OK from the SBC is having two different m-lines with the sendonly for audio and sendrecv for video during a DM call.

Root Cause: Due to some code in the SIPSG that blindly overwrites the video dpm to SEND RECV.

Steps to Replicate: 

Call flow:

1. The initial call flow is pass thru A↔B.
2. A transfers to C (Direct Media call from here)
3. B sends hold to C by sending a=inactive and c=0
4. B sends late media re-invite w/o SDP to C
   -> While responding locally to a late media re-INVITE, the SBC blindly copies
   DPM=SEND_RECV for video, which creates this inconsistency as audio is sent
   out by the SBC as per last SDP negotiated on that leg (that is inactive)
   but video=sendRecv always.

TEST CASES:

Enabled the latemedia passthru / e2e re-invite &e2e ACK flags(Tested both pass thru and DM calls by sending audio&video DPM as inactive/sendrecv)

case1:- SVT scenario

1. SBC responds with inactive for both audio/video in response to late media re-Invite.

case2:- SVT scenario with following changes:

1. After xfer, during HOLD, instead of inactive, B uses sendOnly with valid c-line IP to put call on HOLD.
2. Party C responds with recvOnly to this HOLD INVITE.
3. The SBC sends 2xx with recvOnly for both audio/video to Party B.
4. Party B sends late media re-Invite.
5. The SBC responds with recvOnly for both audio/video.

case3:- SVT scenario with following changes:

1. a. After xfer, not sending any HOLD INVITE. Basically call continues as SEND_RECV DM call.
2. Party B sends late media re-Invite.
3. The SBC responds with SEND_RECV for both audio/video.

Platform/Feature: SBC

The code is modified so that if the condition only if the coreaudio Dpm also SEND_RECV.
It changes video DPM to SEND RECV only if the core audio DPM also SEND RECV.

Workaround: N/A

Portfix SBX-100414: The Q.850 reason was cause a mapping issue.

Impact: When a invalid cause=parameter is received in Reason: Q.850 header, the SBC accepts an invalid cause value and converts into a valid value.

This results in incorrect cpc to the SIP causes a mapping and impact SIP messaging on other leg.

Root Cause: The SBC incorrectly validates the cause= parameter in the Q.850 reason header.

Steps to Replicate: 

1. Send 600 Busy Everywhere from egress endpoint with cause = 600:

   Reason: Q.850;cause=600;text="Busy Everywhere"

   Due to a bug, the SBC maps invalid cause value 600 to 88 ( 0x58 )
   and when mapping CPC to SIP, the SBC sends 503 to the Ingress side.
   
   

2. Verify the issue by using the same scenario.

The SBC sends 486 Busy Here to ingress as invalid Q.850 cause code is ignored.

Platform/Feature: SBC

The code is modified to ensure the SBC correctly validates cause= parameter in Reason header.

Workaround: Use the SMM to filter our Reason header with an invalid Q.850 cause parameter.

Portfix SBX-100075: The AddressSanitizer detected a heap-use-after-free on address 0x6230000e31dc at pc 0x560c37742937 bp 0x7f62795d68d0 sp 0x7f62795d68c8.

Impact: In case of a scenario where the INVITE is rejected because it received more than 10 Route Headers, then the pstCall will be freed as a result, but application will still be using that pointer.

Root Cause: The pstCall is getting freed, but the pointer is not setting to null.

Steps to Replicate: This can be reproduced in house with ASAN Build.

Platform/Feature: SBC: SIP

Set the pstcall to NULL after freeing the call.

Workaround: N/A

Portfix SBX-96567: The AddressSanitizer detected a stack-buffer-overflow on address 0x7ff4a63c0da0 at pc 0x562fdc55b9f7 bp 0x7ff4a63c0c30 sp 0x7ff4a63c0c28.

Impact: An invalid read of 1 Byte is occurring when the SBC is trying for SRTP license.

Root Cause: The freed memory is being accessed after sending memory to the stack.

Steps to Replicate: This issue is only reproducible when using ASAN images in engineering lab.

Platform/Feature: SBC

The code is modified so that freed memory is not being accessed.

Workaround: N/A

Portfix SBX-96147: The AddressSanitizer detected a heap-use-after-free on the address 0x60400047f020 at pc 0x561f45771c9f bp 0x7f4227923c60 sp 0x7f4227923c58.

Impact: The heap-After Free memory is getting used in a scenario where the INVITE is getting rejected in UasReceiveCallCmd().

Root Cause: In case of the failure in the uacReceiveCallCmd, there may be error response sent.

When an error response is sent, a To Tag needs to be sent that is allocated in pstCall, so the pstCall must not be freed before sending that response.

Steps to Replicate: This issue is only reproducible when using ASAN images in engineering lab.

Platform/Feature: SBC

The code is modified not to free a pstCall in this case until an error response is sent.

Workaround: N/A

Portfix SBX-99021: The "Tag_From" is not added in the first 2xx response for Subscribe in the Ingress side of the SBC.

Impact: The Dialog Scope Variables are not working in case of a Subscribe Crank back scenario because of the From Tag Changes.

Root Cause: The From Tag is not being Updated in the dialog scope variable.

Steps to Replicate: 

1. Create the SMM Profile 'Dialog_Variable'.
2. Attach the SMM Profile as an Input and Output Adaptor Profile to the Ingress side of the SBC.
3. SUBSCRIBE message is sent from UAC to the SBC.
4. The SBC forwards to egress UAS (first route).
5. The UAS1 sends 408 (first route).
6. The SUBSCRIBE message is crankback to 2nd route which is in another Trunk group.
7. The UAS2 will send 2xx to complete the subscription.

Platform/Feature: SBC

The code is modified to update the From Tag in the dialog scope variables.

Workaround: N/A

Portfix SBX-99761: The SBC stops running after this OBS call flow.

Impact: Run a DLRBT and Downstream forking scenario where the Update is received from the Egress after the cuttru done.

Root Cause: De-allocating the memory but not setting a pointer to NULL.

Steps to Replicate: The DLRBT is enabled, the PRACK on both legs, the Forking was enabled for a non-forked call, UPDATE with the codec change received from Egress after 180, firstRtp - SR.

EXPECTED RESULT: The call should run successfully.

ACTUAL RESULT: The SBC stops running after receiving update (the SBC automatically restarts).

Platform/Feature: SBC

The code is modified to set the TempResponse to NULL.

Workaround: N/A

Portfix SBX-98554: The AddressSanitizer detected the heap-use-after-free on address:

0x630000850478 at pc 0x5566fba3b8ef bp 0x7f920ade3b50 sp 0x7f920ade3b48 READ

of size 1 at the 0x630000850478 thread T9.

Impact: The Heap Use after freeing memory is getting used in a scenario when the Initial INVITE is getting rejected because of the validation of route headers.

Root Cause: The SBC is accessing the To Tag from the freed pstCall Memory.

Steps to Replicate: This issue is only reproducible when using ASAN images in engineering lab.

Platform/Feature: SBC

The code is modified to not free that memory until the error response is sent.

Workaround: N/A

Portfix SBX-99748: The AddressSanitizer detected a heap-buffer-overflow on address

0x6060007e96d0 at pc 0x55c8b4f2b47b bp 0x7efe153ce020 sp 0x7efe153cd7d0 READ

of size 1 at 0x6060007e96d0 thread T9.

Impact: This issue is only reproducible when using ASAN images in engineering lab. The issue occurs on the SIP-I call where we access 18x msgHandle after freeing the memory.

Root Cause: The MsgHandle being used is already free.

Steps to Replicate: Run a SIP-I call in an ASAN Build.

Platform/Feature: SBC

The code is modified so moves above the problem causing code.

Workaround: N/A

SBX-97804 / SBX-99196 

Portfix SBX-99196: There was an incorrect FQDN routing.

Impact: There was an incorrect FQDN routing occurring that caused calls to route to the wrong destination.

Root Cause: This is occurring in some cases where the retransmitted DNS transaction id of earlier transaction matches with the existing transaction. This causes records to save for the incorrect FQDN.

Steps to Replicate: This problem could only be reproduced in the engineering lab by changing the code to force the issue.

Platform/Feature: SBC

The code is modified so whenever the DNS reply is processed, the FQDN matches what is received in the DNS reply and stored in a transaction.

Workaround: N/A

Portfix SBX-99927: The SBC is adding extra characters in a display name when the ingress INV contains the display name of length more than 55 characters in a GW-GW scenario.

Impact: When an INVITE has the PAI header with display name more than 55 characters is passed transparently on  the GW-GW, the SBC appends the username to the PAI displayname on the egress.

Root Cause: While reading the PAI header out of the message, the SBC allocates size of 48 characters for displayname on a flat buffers, but copies more than 48 characters.

The username is allocates from the same memory buffers starting from offset + displayname size and overwriting the display name NULL terminator with username.

Steps to Replicate: Send an ingress INVITE with PAI header containing displayname length more than 55 characters transparently on GW-GW.

Platform/Feature: SBC

The code is modified to only copy maximum of 48 characters into the PAI displayname buffer and strip down the rest.

Workaround: N/A

Portfix SBX-100307: The ASAN detected a heap-buffer-overflow in SipFeDumpPdu (SipFeProcessSlbIncomingPdu).

Impact: The SIPFE was reading invalid memory while printing sent PDUs.

Root Cause: When the SIPFE module was printing SIP PDU content to the DBG log it was reading past the end of the PDU memory buffer.

Steps to Replicate: This problem can only be observed when using ASAN images in the development lab.

Platform/Feature: SBC

The code is modified to avoid reading past the end of the SIP PDU to avoid accessing invalid memory.

Workaround: Disable the info level logging.

Portfix SBX-65393: Calls fail after deleting an unrelated ingress IP prefix within a zone.

Impact: If the SBC is provisioned as follows, TGs within a zone are provisioned with duplicate ingressIpPrefix and one of the ingressIpPrefix has an invalid format.

When the duplicate ingressIpPrefix is deleted, calls to TGs that should have matched the ingressIPPefix fail.

Root Cause: The CLI was not rejecting an invalid ingressIpPrefix from being provisioned by the user.

Steps to Replicate: 

1. Create a TG with ingressIpPrefix 0.0.0.0/0 (Named EXT).
2. Verify ingress calls are selecting the correct ingress TG (EXT).
3. Create second TG with ingressIpPrefix 10.1.1.1/0 (Named TEST_TG).
4. Calls will still find the correct TG i.e. EXT, SBX will not use TEST_TG.
5. Delete second TG’s ingressIpPrefix of 10.1.1.1/0 (i.e. TEST_TG ingressIpPrefix).
6. Calls fail to find correct TG (EXT) now, the only TG with 0.0.0.0/0 ingressIpPrefix because the backend code does not have the 0.0.0.0/0 prefix to EXT mapping.

Platform/Feature: SBC: Call Control

The code is modified to reject invalid ingressIPPefix formats and to protect the SBC from users entering an invalid ingressIpPrefix.

Workaround: Do not add or delete invalid ingressIpPrefixs. Industry acceptable format of ingressIpPrefix needs to be entered in the CLI. 

Portfix SBX-99964: The AddressSanitizer detected a heap-use-after-free on nrmaMsgProc.c when running DSBC REFER.

Impact: While the SBC was processing resource allocation messages associated with DTMF relay handling it was allocating memory after the memory has been freed up.

Root Cause: This is a day 1 issue and not known to cause any problems in the field. While generating a DBG log message, the code was trying to print the contents of a message block immediately after the block had been freed.

Steps to Replicate: This issue can only been reproduced in the lab while running with ASAN images.

Platform/Feature: SBC

The code is modified to no longer access the message content after processing the message to avoid accessing the memory after it has been freed up.

Workaround: N/A

Portfix SBX-99647: There are XRM SBX_GoalwoPolicy coverity issues.

Impact: While processing the signaling port configuration the, the lifGroupId value was being read as a 32 bit value into a 16 bit storage location causing memory to be overwritten.

Root Cause: The code was using the wrong API to read the configuration resulting in potential memory corruption.

Steps to Replicate: This issue can only be reproduced using ASAN images in the engineering lab.

Platform/Feature: SBC

The code is modified to only read the lifGroupId as a 16 bit value.

Workaround: N/A

Portfix SBX-99814: The AddressSanitizer detected heap-buffer-overflow on the address:

0x60b0007c994a at pc 0x55758a639756 bp 0x7f1b8e3cd9a0 sp 0x7f1b8e3cd998

Impact: When the SBC is running as the T-SBC, it was reading invalid memory.

Root Cause: When the SBC is running as the T-SBC it was incorrectly reading off the end of the resource allocation message because it was reading information which is only present for the M-SBC.

Steps to Replicate: This issue is only observed when running with ASAN issues in the engineering lab.

Platform/Feature: SBC

The code is modified to verify whether the resource response message is for the M-SBC before trying to access the specific M-SBC information.

Workaround: N/A

Portfix SBX-99226: The AddressSanitizer detected an global-buffer-overflow error observed on:

SipSgRedirectedInviteHandleEmbeddedRepeatableUriHdrs

when sending embedded header in 3xx.

Impact: For a STIR/SHAKEN as a service call flow where PSX returns 3xx with embedded identity and PAI headers, the SBC was reading off the end of an internal buffer while trying to confirm of the embedded headers where "known" headers.

The issue would exist for other 3xx scenarios with embedded URI headers.

Root Cause: The name of a header was missed in one array, although the count of headers was correctly updated and this caused the code to read off the end of the names buffer.

Steps to Replicate: This issue is only highlighted in engineering lab while testing with ASAN enabled images.

1. Made a signing call using PSX as Redirector (STIRaaS).
2. The PSX sends 300 Multiple Choice.
3. 300 Multiple header has embedded parameters.
4. The SBC does a full dip to construct redirect INVITE.

Platform/Feature: SBC

The code is modified to ensure the internal buffer contains all the correct header names.

Workaround: N/A

Portfix SBX-98796: The AddressSanitizer detected a heap-buffer-overflow on the address:

0x6150043d0258 at pc 0x55c7b4ebab3c bp 0x7f6f282a51a0 sp 0x7f6f282a4950 READ

of size 432 at 0x6150043d0258 thread T8.

Impact: The HPC/GETS related call flows are resulting the code reading off the end of an internal memory block.

Root Cause: While processing HPC/GETS related calls the code was allocating an ICM message based on the size of 3 structures and then trying to copy it based on the size of 4 structures resulting in reading off the end of the memory block.

Steps to Replicate: The problem is only highlighted when running the HPC / GETS related call flows in the engineering lab with ASAN images.

Platform/Feature: SBC

The code is modified to allocate the correct amount of memory to avoid the issue.

Workaround: N/A

Portfix SBX-98464: The AddressSanitizer detected a heap-buffer-overflow on the address:

0x61100004c2a8 at pc 0x563b72b7b8cc bp 0x7f93b1edeff0 sp 0x7f93b1ede7a0 READ

of size 692 at 0x61100004c2a8 thread T9.

Impact: The SBC is reading of the end of the internal buffer when trying to pass STIR/SHAKEN information back to the ingress side of the call as part of the feature SBX-98464.

Root Cause: The code was storing the STI information that the PSX returned and did not take into an account, the scenario where the PSX returned an identity header that meant the parameter when signing was bigger then verification.

When it later tried to add the parameter into the backward messages, it was reading off the end of the memory buffer.

Steps to Replicate: This issue is only observed when using ASAN images in the engineering lab and running STIR/SHAKEN test with signing enabled and the PSX returns an identity header to include in the outgoing INVITE.

Platform/Feature: SBC

The code is modified to allocate the correct amount of memory to avoid reading off the end of the buffer.

Workaround: N/A

Portfix SBX-100068: The SLB was going down after triggering a DBL entry for the event epCacAggrReject.

Impact: The SLB was reading invalid memory.

Root Cause: When the SLB was printing SIP PDU content to the DBG log, it was reading past the end of the PDU memory buffer.

Steps to Replicate: This problem can only be observed when using ASAN images in the development lab.

Platform/Feature: SBC

The code is modified to avoid reading past the end of the SIP PDU to avoid accessing invalid memory.

Workaround: N/A

Portfix SBX-95584: The LeakSanitizer detected memory leaks at at packet handler.

Impact: While reading the configuration data, the SBC was overwriting stack memory and also leaking small amounts of memory.

Root Cause: A number of fields in the SBC configuration where defined as boolean, however confd had implemented these as integers.

When reading the contents from CDB, the local variable store defined as boolean was not large enough to hold the configuration value and resulted in memory being overwritten.

While the SBC was processing configuration data for users and groups it was not freeing up all the memory that was allocated, resulting in a leak.

Steps to Replicate: These problems can only be reproduced in the development lab while testing with ASAN image.

Platform/Feature: SBC

The code is modified to use the correct size of local variable to avoid memory being overwritten.
The code is also modified to correctly free memory to avoid leaks.

Workaround: N/A

Portfix SBX-98357: The LeakSanitizer detected memory leaks at PathchkPingSessionAddEntry.

Impact: When making configuration changes to an existing path check object, it was causing a small memory leak.

Root Cause: As part of the modify logic, the code was reallocating a memory block and it was not freeing up the memory block that was allocated when the configuration was originally created.

Steps to Replicate: This problem was highlighted in engineering lab while running with ASAN images to highlight memory leaks and then making path check configuration changes.

Platform/Feature: SBC

The code is modified to correctly free the memory block as part of the update logic.

Workaround: Delete and recreate the path check configuration rather and modifying it.

Portfix SBX-100017: While expecting an UPDATE, the SBC sending 503 to ingress side.

Impact: If the toneAsAnn is enabled, do not go for the DSP allocation for playing tones. But the SBC trying to allocate the DSP resource and fails.

Root Cause: A new flag introduced as part of other feature "end2endtonemodify" that overrides "toneAsAnn" flag.

Steps to Replicate: 

1. The SBC configured to play tone. The toneAsAnn is enabled.
2. Egress has sent 18x with the SDP, the SBC plays tone towards ingress.
3. Ingress modify update is received. Then the SBC will handle the update and send to egress.

Platform/Feature: SBC

The "toneAsAnn" flag is given higher priority than "end2endtonemodify" flag.

Workaround: SBC

Portfix SBX-96500: The SMM Testing tool does not work.

Impact: The SMM test tool is not parsing through the selected profile.

Root Cause: The profile index value was incorrect, so it was picking the wrong profile index and the message was unaltered by SMM.

Steps to Replicate: When testing the same SMM in 7.1 code for example (with the same INPUT message), the test is successful. 

(Go to Test SMM for SBX-96500 for SMM details)

Platform/Feature: SBC

The code is modified to contain the correct profile index.

Workaround: N/A

Portfix SBX-100016: The SBC does not forward 18x towards ingress leg after the egress precondition interworking is met.

Impact: In case of egress pre-condition, the UPDATE is generated even before response for PRACK is received. In such a case, where the UPDATE is triggered once response for PRACK is received, the 18x that is received from egress after preconditions is met, is not sent towards ingress.

Root Cause: The root cause is because of timing issue.

Steps to Replicate: 

1. Make a call with SDP attribute "a=sendonly" or "a=recvonly" in the INVITE from UAC.

Platform/Feature: SBC

The code is modified to handle such timing issues and send the 18x towards ingress after preconditions is met.

Workaround: N/A

Portfix SBX-94506: The Data Path mode is always 'a = sendonly'.

Impact: Whenever the SRS put SIPREC call on hold with a=inactive, the SBC always acknowledged SIP 200 OK with a=sendonly.

Root Cause: A SIPREC call hold done by the SRS was not identified in terms of Signalling properly at the SBC.

Steps to Replicate:

1. The main call is stable.
2. The SRS put the call on hold by generating SIPREC REINVITE with a=inactive.
   Expected and Observed Behavior:-
   The SBC to respond 200 OK towards SRS with a=inactive.

Platform/Feature: SBC

Identified the CALL HOLD scenario that triggered by an SRS due to generation of RE-INVITE with a=inactive through appropriate CALL Hold Flag value for SIPREC.

Workaround:

Portfix SBX-85852: "Timeout detected – Forcing the read/write access during the switchovers.

Impact: The message "Timeout detected -- Forcing read/write access" is observed during switchovers.

Root Cause: This message is logged on NBI timer expiry (after 2mins) and config changes were allowed before DBs are in sync. This would happen when standby initialization takes longer.

Steps to Replicate: Install the SBC with the fix build and perform switchover. Ensure there is no timeout message and config changes are allowed only after configuration and Policy DBs are in sync.

Platform/Feature: SBC: Platform

The code is modified to allow configuration changes only when both the CDB and oracle DB are available for READ_WRITE and sync is completed.

Workaround: N/A

Portfix SBX-94375: The IpPeer authPeer fails to delete.

Impact: When the IPPeer modified either the zone/port/ip, the old authPeer data structure is not deleted.

Root Cause: There was a memory leak.

Steps to Replicate: 

1. Create an IPPeer with port aaaa.
2. Change the IPPeer with different port bbbb.
3. Change the IPPeer back to port aaaa.
4. Call may fail.

Platform/Feature: SBC: Provisioning

The code is modified to delete the old data structure.

Workaround: Delete the ipPeer and create a new one (not modify).

Portfix SBX-94588: The LSWU will fail/stall due to upgrade out permissions.

Impact: The LSWU would fail if the upgrade out file permissions are incorrect.

Root Cause: Permission of staging files were not being properly updated during the pre-upgrade checks, and failing to execute upgrade script if the permissions are incorrect.

Steps to Replicate: Perform the LSWU to the fix build and verify that upgrade is successful.

Platform/Feature: SBC: LSWU

The code is modified to properly update permissions of staging files during pre-upgrade checks so that the upgrade script executes successfully even if initial permissions are incorrect.

Workaround: N/A

Portfix SBX-99361: The customer SBC has a memory leak.

Impact: There is a bug in the “clearTcpConnectionsforRegistration" functionality that causes a memory leak.

Root Cause: This code that handles the clearTcpConnectionsforRegistration flag is allocating memory to store Hostname and Username, but it never freeing this memory.

Steps to Replicate: Set up the customer configuration with the “clearTcpConnectionsforRegistration” flag set.
Able to reproduce the leak by running load with Registrations and de-Registrations.

Platform/Feature: SBC

The code is modified to free the memory that is allocated to store Hostname and Username.

Workaround: N/A

Portfix SBX-98200: There was a SCM process memory leak (SIPSG), not freeing pSbyRcb→pcrfInfo.

Impact: Leaking PCRF related structures on the standby when processing the Registrations, if PCRF is configured on Trunk Group.

Root Cause: Memory that was allocated for the PCRF related structures is not being freed as part of de-registration processing.

Steps to Replicate: 

1. Configure the pcrfCommitment to something other than none.
2. Set the pcrf_signallingPath to enabled.
3. Set the pcrf_provSignalingFlow to enabled.

Platform/Feature: SBC: SIP

The code is modified to free the memory that is allocated for PCRF related structures as part of de-registration processing.

Workaround: The workaround is to set pcrfCommitment to none.

Portfix SBX-97433: The bondingDevice0 port status was showing as noSignal.

Impact: The CLI highAvailabilityPort status command shows the OOS reason as “noSignal” for port bondingDevice0 even though it is up.

Root Cause: There was a code to check bond0 device status and parse the output required a fix.

Steps to Replicate: Install the fix build and run the CLI command "show table system highAvailabilityPort status" to ensure the OOS reason is displayed correctly.

Platform/Feature: SBC

The code is modified to ensure the proper display of an OOS reason in highAvailabilityPort status command.

Workaround: N/A

Portfix SBX-75563: The port number was in the DBG log.

Impact: For non-UDP calls, the peer IPs of all status messages sent from the SBC to the UAC in TRACE log will be displayed through the header's IP.

The messages themselves are sent to the right IP, that sent the request message to the SBC.

Root Cause: The original code overwrites the SipMsg's peerIp with through header. The PeerIp will be used to print in the trace log.

Steps to Replicate: 

1. Set up TCP calls, and TLS calls.
2. Make VIA header's IP different from UAC IP.
3. Make the call, collect the TRC log. DBG log could be also collected as debug tool.
4. Ensure that all out going msg are sent to right IP:Port in displayed in TRC log.

Platform/Feature: SBC: Platform/Media Services, SIP

The code is modified so for the non-UDP calls (TCP and TLS calls, SipMsg's peerIp) set to the source IP.

Workaround: N/A

Portfix SBX-99515: The X2 messages do not have the timestamp set correctly.

Impact: In Default LI, the X2 message does not have milliseconds in the time stamp captured as part BCID avp.
Without a fix, milliseconds in the time stamp field will be 000 and time stamp field will look like "Event Time: 20200429190440.000"

Root Cause: Milliseconds data was never captured in time stamp field for Default LI.

Steps to Replicate: Run a default LI call.

Platform/Feature: SBC

The code is modified to incorporate milliseconds. With the fix , the time stamp field looks like "Event Time: 20200429190440.541".

Workaround: N/A

Portfix SBX-98996: No audio on the SRTP calls.

Impact: Certain call scenarios (SRTP with ICE) intermittently start with one-way audio on encrypted leg(s) due to SRTP authentication failures.

Root Cause: Race condition in setup of encryption and decryption resource results in uninitialized ROC value being used to encrypt outgoing media packets.

Steps to Replicate: SVT ran the SRTP with ICE call load overnight and verified no authentication failures.

Platform/Feature: SBC

Eliminated race condition between encryption and decryption resource setup to ensure the encryption ROC begins at zero.

Workaround: N/A

Portfix SBX-98356: The AddressSanitizer detected SEGV on an unknown address 0x0000000000e5 (pc 0x5653a715fdde bp 0x7f84a52bfea0 sp 0x7f84a52bfe70 T9).

Impact: After a successful surrogate registration, if any configuration related to the IP Peers/TGs/Surrogate registration is deleted, the SCM process will coredump.

Root Cause: The code was dereferencing a NULL pointer as the trunk group configuration data was no longer present when the surrogate registration response came back.

Steps to Replicate: Trigger the SBC to send out surrogate registration request and delete all the associated trunk group configuration before sending back a response from the remote server.

Platform/Feature: SBC

The code is modified to check that the trunk group configuration exists before trying to read the configuration.

Workaround: Do not delete any Trunk Group's to avoid SCM cores.

Portfix SBX-100002: The JIP parameter is not being sent in PAI header.

Impact: The JIP parameter received in the 3xx was not sent in PAI header.

Root Cause: This is because of the Enhanced Local Redirection changes done in 7.2.3 R1

Steps to Replicate: 

1. Make a SIP-SIP call with JIP in jip parameter in PAI header.
2. The egress send 302 Moved Temporarily message with a different JIP value.

Platform/Feature: SBC

The code is modified to fix the issue.

Workaround: N/A

Portfix SBX-95083: The SBC was terminating all the (Transfer Target and Transferee) call legs after call transfer on the Ppenstack / AWS.

Impact: The SBC was terminating all the (Transfer Target and Transferee) call legs after call transfer on the Ppenstack / AWS.

Root Cause: The SBC signaling plane was quickly reusing the same RTCP gen media resource with this call transfer modification scenarios, and the media plane rejecting the reuse of this resource resulting in call failures.

The media plane disables the original resource only after sending last RTCP packet from media plane, then only it allows the reuse.

Steps to Replicate: Enable the NoBye RTCP Gen options, test the call transfer, and modify scenarios as shown below:

1. Make call from PSTN endpoint to Teams endpoint (simulated in SIPp).
2. Answer the call as Teams client.
3. Initiate blind transfer from Teams client to another Teams client.
4. disconnect the call at PSTN endpoint.

Platform/Feature: SBC

The code is modified to allow this reuse with NoBye RTCP Gen option. Allowing the signaling plane to reuse the same media resource for these call transfer, modifications to work.

Workaround: Disabling the RTCP Gen/term from the SBC, and using RTCP relay will not have such issues.

The OAM SBC had a failover/switchover.

Impact: There as a recurring random OAM switchovers have been noticed at the customer site.

Root Cause: The VNFR REST message key and/or value may be NULL. This causes the std::string type instantiation to fail and bring down the SBC application.

Steps to Replicate: The problem cannot be reproduced, the issue was fixed based on coredump and core review.

Platform/Feature: SBC

The code is modified to handle the cases where the std::string is instantiated with a NULL value.

Workaround: N/A

An mgt1 IP address appears on the mgt0 interface after a reboot of the SWe SBC.

Impact: After adding the second management, the interface was adding the second management IP in first management IP.

Root Cause: Not updating the /etc/network/interfaces file with second interface entry.

Steps to Replicate: Add the second management interface and ifconfig command must give proper output with separate IP for all management interfaces. 

Platform/Feature: SBC

The code is modified to update the second management IP.

Workaround: N/A

The CDR file transfer fails with the 12.00.00R version of the DSI server.

Impact: The CDR file transfer fails with the 12.00.00R version of the DSI server.

Root Cause: The newer 12.00.00R000P1 version of the DSI server no longer supports the hmac-sha1 as a mac algorithm during the ssh key exchange. The hmac-sha1 is no longer considered secure so the most recent releases of many Linux operating systems have removed support for hmac-sha1.

Steps to Replicate: 

1. Configure the CDR file transfer to a DSI server running the version 12.00.00R000P1 or later.
2. Observed that the file transfer fails.
3. In the /var/log/secure log on the DSI, note an error saying the authentication failed because hmac-sha1 is not available

Platform/Feature: SBC

The code is modified to offer the hmac-sha2-256 as the first choice for the mac algorithm. However, the hmac1-sha1 is also offered as a choice to support transfer of files to older systems that do not have hmac-sha2-256 available.

Workaround: Edit the /etc/ssh/sshd_config file on the DSI and add hmac-sha1 on the line starting with MACs

The RTP Inactivity Timer fires early upon performing a port switch-over on the M-SBC and duplicates a STOP Record as a result.

Impact: During the high call load if the SBC detects media inactivity, it generates a duplicate STOP record with the disconnect reason as Module Failure for a subset of calls.

Root Cause: When the RTP inactivity is detected for a call, the GCID of that call is added to a unsolicited call cleanup list.

When the call cleanup is invoked, if it finds that a previous call cleanup is going on then it generates STOP record for all the pending calls cleanups for which it has not received a cleanup reply. Thus causing duplicated STOP record generation for a few calls.

Steps to Replicate: 

1. Set the RTP inactivity timeout value.
2. Enable or disable the preventDuplicateEmptyStopRecOnInactivity​Detection.
3. Run a call load such that RTP inactivity timeout occurs.
4. Notice that when preventDuplicateEmptyStopRecOnInactivity​Detection is enabled there should be no duplicate STOP records for STOP records with disconnect reason as RTP inactivity.

Platform/Feature: SBC

The code is modified to configure whether the SBC generates duplicate stop record on inactivity detection or not.
Command: set oam accounting admin preventDuplicateEmptyStopRecOnInactivityDetection <enabled/disabled>

Disabled: Default: continue with existing behavior (to generate empty STOP record in case of RTP inactivity detection).
Enabled: To stop generation of empty STOP record in case of RTP inactivity detection.

Workaround: N/A

The SBC will increment the port number in the Request-URI of the outgoing INVITE, if the first non-SBC Route header of the incoming INVITE did not contain "transport" parameter and the SBC/PSX configuration determined the egress call leg transport type as TLS.

Impact: The call route in the received route and egress is the TLS, the RURI port is not increment by 1.

Root Cause: Missing the logic to increment port by 1.

Steps to Replicate: The configuration call received a route, the incoming call has route IP but no transport parameter. The SBC sends out an INVITE without increment port in the RURI.

Platform/Feature: SBC

The code is modified to increment port by 1.

Workaround: Have the SMM to increment port.

There was an issue on link failures counts on the Port Monitor Status.

Impact: There was alinkFailure count in portMonitorStatus command was not getting incremented upon the link failures.

Root Cause: The counter was not getting incremented whenever a link monitor failure notification is reported.

Steps to Replicate: Simulate link failures and check for a linkFailure counter in portMonitorStatus command output.

Platform/Feature: SBC

The code is modified to increment the counter upon getting the link monitor failure notification.

Workaround: N/A

The Egress SBC is not tearing the call down, even though the ingress SBC releases the call.

Impact: When making the GW-GW call flows between the SBC and either the SBC or GSX call flows and bulk call failures occur on one GW.

Root Cause: There was a code change in the 8.2.1R0 release that mistakenly removed processing of the GW multiple call clear message.

This message is used to send a list of multiple GCIDs that have failed on one GW, over to the other GW to clean up as a bulk. As the message is dropped, the calls will not be cleaned up until timers expire or the user hangs up the call.

Steps to Replicate: Run an SBX-GW-GW-SBX call flows with packet loss action set to trap and disconnect and do not provide any media so multiple calls are cleaned up in a single action. Check the calls are cleaned up correctly on both GWs.

Platform/Feature: SBC

The code is modified so multiple call failures are processed immediately.

Workaround: N/A

The MS Teams zone detection needs to account for GCC and DOD deployments.

Impact: MS Teams uses special FQDNs for GCC and DOD network deployments and the SBC was not using these to recognise that it was a MS Teams zone.

This meant that some of the native functionality such as generating UserAgent headers did not happen.

Root Cause: The code was not checking for the special FQDNs of sip.pstnhub.dod.teams.microsoft.us and sip.pstnhub.gov.teams.microsoft.us.

Steps to Replicate: Configure the SBC in one of these networks and check that it is automatically sending UserAgent and other headers.

Platform/Feature: SBC: MS Teams

The code is modified to check for these deployments.

Workaround: Add a pathcheck to a regular MS Teams FQDN to get native support or implement the SMM to cover the functionality that is available natively, similar to the 7.2 configuration guide.

The response for the OPTION message received from TEAMS does not have domain name in contact.

Impact: The contact header sent in the 200 OK response to the out-of-dialog OPTIONS message in the MS Teams zone contains IP address. 

Root Cause: The out-of-dialog OPTIONS message received in the MS Teams Zone.

Steps to Replicate: Send an out-of-dialog OPTIONS message in the MS Teams Zone.

Platform/Feature: SBC

The code is modified to populate the zone domain into the Contact header of 200 OK.

Workaround: N/A

The EMA /tmp has been filling the "/var/log/sonus/ema/tmp".

Impact: The EMA /tmp has been filling the "/var/log/sonus/ema/tmp"

Root Cause: Every time the SBC started up, it is not created a new tmp directory.

Steps to Replicate: 

1. Restart the EMA.
2. After connect to corresponding the SBC box.
3. Navigate to /var/log/sonus/ema.
4. Observe the newly created tmp directory.

Platform/Feature: SBC

The code is modified to fix the issue.

Workaround: N/A

The Call/Registration Data is showing the syncInProgress after upgrading the Standby MSBC in 2:1 DSBC Setup.

Impact: The Call/Registration Data sync does not complete when the Active is running in the 8.20R001 and standby is running in 9.0R000 and the call load has PCSILI stable calls during sync.

Root Cause: For PCSILI, one of the redund messages is not registered to the ObjectFactory. As a result, the ObjectFactory is unable to provide serialization/de-serilazation

Steps to Replicate: Performing the LSWU from 8.2.0R001 to 9.0R000 with PCSILI calls will cause this issue.

Platform/Feature: SBC

All required redund messages for PCSILI are registered to the ObjectFactory to provide the serialization/de-serilazation.

Workaround: This is affected only for PCSILI calls' sync. Since the customer is not going to do the regular LSWU procedure as part of their upgrade, this issue will not be seen in the customer deployment.

Also, the upgrade is successful, if there is no PCSILI stable calls during the upgrade(sync time specifically).

Portfix SBX-96472: The SLB restarted on Jan29 / SSBC3, on Feb25 / TSBC1, on Feb 26 / TSBC4 on Mar 19.

Impact: The watchdog incorrectly kicks in and kills the service resulting in a restart of the service.

Root Cause: The pidof and ps commands are sporadically returning a false negative, indicating to the watchdog that the safplus_amf process is not running when in fact it is.

Some type of race condition with processes starting/exiting is causing the getdents call to skip processing some of the /proc file system.

Steps to Replicate: 

1. Kill safplus_amf and ensure the watchdog properly detects it, kills all the components, and restarts the service.
2. There is no way to validate that we do not restart due to a false negative without an unexpected failover happening and being analyzed back to the watchdog kicking in for no apparent reason.

Platform/Feature: SBC

When the watchdog detects that safplus_amf is not running, a second call is made to pidof to confirm that the process is completely gone.

Workaround: N/A

Portfix SBX-100400: The OOM (Out Of Memory) threshold default value is not set correctly on a HA system.

Impact: In the 8.2 release, the default value of outOfMemory configuration was increased from 85% to 91% but the logic is not taking effect on freshly installed HA systems.

Root Cause: There was a bug in the code which meant the standby server was not reading the hardware details correctly and assigned the value of 85% instead of the value of 91% set on the standby server.

When the standby server then synced with the active server for the first time it resulted in the system value getting reset to 85%.

Steps to Replicate: Install a HA server and confirm that the default outOfMemory value is set to 91%.

Platform/Feature: SBC

The code is modified to correctly read the hardware details and set the outOfMemory configuration to 91% on the standby server to match with the active so that the overall system value is initialized to 91%.

Workaround: The user can manually set the outOfMemory configuration to 91%.

The call upgrade scenario failing in the DSBC (MSRP upgraded to MSRP and audio call).

Impact: The problem is that MrmModifyRpy on the MSBC is picking the SSBC GCID when it was supposed to pick the MSBC GCID and reply to the local NRMA on MSBC that leads to a call failure.

Root Cause: The root cause is that the SSBC GCID was being picked instead of the MSBC GCID to send the MrmModifyRpy.

Steps to Replicate: Run a basic MSRP call with re-invite and ensure the re-invite processing is successful, the media flows and tear down is successful.

Platform/Feature: SBC

Based on the MSBC check, pick the MSBC GCID in order to send the reply to the local NRMA on the MSBC that allows us to process the call modification/tear down smoothly.

Workaround: N/A

Portfix SBX-99748: The AddressSanitizer detected the heap-buffer-overflow on address:

0x6060007e96d0 at pc 0x55c8b4f2b47b bp 0x7efe153ce020 sp 0x7efe153cd7d0 READ

of size 1 at 0x6060007e96d0 thread T9.

Impact: This issue is only reproducible when using ASAN images in engineering lab.Issue happens on SIP-I call where accessing 18x msgHandle after freeing the memory.

Root Cause: The MsgHandle that was being used is already free.

Steps to Replicate: Run a SIP-I call in an ASAN Build.

Platform/Feature: SBC

The code is modified problem was causing code.

Workaround: N/A

Portfix SBX-100059: After observing an overnight call load run, the ping with a size more than 1453 is not reaching to the SSBC.

Impact: The SBC SWe can get into a state where it cannot receive and reassemble fragmented packets.

Root Cause: For the fragmented packets that take close to 1 second to send the complete context, network processor could decrement the incorrect interface "current number of fragments context in use" counter.

The network processor has a maximum fragment context in use limit and once it hits that limit, it will not accept new fragmented packets.

Steps to Replicate: Send the fragmented packets that take 1 second to complete to pkt0, pkt1 or mgt1 port.
This may take some time but eventually the interface stops accepting fragmented packets without the fix.

Platform/Feature: SBC

Fix race condition and decrement the correct interfaces "current number of fragment context" counter.

Workaround: Try not to send a very large fragmented packet to the SBC.

Portfix SBX-94838: The securelink access was not working for the Standby server.

Impact: From an EMA PM, once the GateKeeper Access is enabled, it is getting updated as the 'disabled' instead of 'enabled'.

Root Cause: This issue was due to missing ACLs on third and fourth management ports.

Steps to Replicate: 

1. Login to securelink.sonusnet.com
2. Generate the registration codes for the Active SBC and the standby 5400 SBC.
3. Login to the respective SBC EMA PM.
4. Navigate to Secure Link ( Administration -> System Administration -> Secure Link).
5. Provide the DNS IP address and Registration code(generated in step 2).
6. Click on 'Enable GateKeeper Access'.
   Note: Enabling Gatekeeper access is done with different registration codes in Active and standby setup.
   From EMA PM, once the GateKeeper Access is enabled, the status should show as 'enabled'.

Platform/Feature: SBC

Support for setting ACLs for third and fourth management ports is added.

Workaround: N/A

Portfix SBX-99098: The SBC does not relay 200 OK for UPDATE in a late media passthrough and reverse offer scenario.

Impact: The latemedia relay call, the SBC may not able to respond to UPDATE if the previous 18x received is not prack.

Root Cause: There was a logical error due to previous 18x did not have prack support causing the SBC to be unable to send out 200OK for an UPDATE.

Steps to Replicate: During a latemedia relay, the Egress offers an SDP in 18x with prack, egress received subsequent 18x without prack, the egress received UPDATE with SDP. The SBC is unable to answer the UPDATE.

Platform/Feature: SBC

For a latemedia call, and if the SDP offer/answer completed, the SBC is able to answer the UPDATE.

Workaround: Use the SMM to drop 18x without prack if not SDP.

Portfix SBX-98818: There was an Upgrade failure from 8.2.0R0 to 8.2.0R2.

Impact: Impact on the SWe Live Software Upgrade for the upgrades from version 8.x to 8.x.

Root Cause: There may be a Live Software Upgrade failure while upgrading from versions 8.x to 8.x if a model marker(dynamicHANewComps) is present from the previous upgrade.

Steps to Replicate: Perform a Live Software Upgrade from 6.x to 8.x and further upgrade to 9.0 and verify the upgrade to 9.0 is successful.

Platform/Feature: SBC

The code is modified to ensure the removal of the model marker dynamicHANewComps after completion of upgrade on both nodes. Also, upgrading to 9.0 or later ensures removal of marker if a leftover from previous upgrade.

Workaround: While performing the Live Software Upgrade from 8.x to 8.x, remove the following marker file on both nodes if present.
"rm -f /opt/sonus/installUpgrade/log/dynamicHANewComps"

Portfix SBX-96711: Sometimes, a call on hold is followed by REFER fails.

Impact: A call onhold before blind transfer may cause a call teardown.

Root Cause: There is a race conditions in state machine during call transfer between transfer legs might cause offer answer timeout that tear down the call.

Steps to Replicate: 

1. A calls B, B put on hold, B refer to C.
2. C answers a fast connection. The B received the Notify connect, B send bye immediately.
3. Small load may have caused call tear down due of offer answer timeout.

Platform/Feature: SBC

The code is modified so waiting for internal resources bridging is done before the notify peer transfer completed.

Workaround: If B can delay (200ms) before send bye.

Portfix SBX-99918: The contact header parameters are not passed transparently in the redirected Invite.

Impact: With the Enhanced Local Redirection flag enabled, the contact Header parameters received in 3xx are not sent as parameters in Request URI if they are not processed by the SBC.

Root Cause: When implementing the changes for this new flag in 723 R1, this flag check was missed.

Steps to Replicate: 

1. The UAC sends INVITE towards the SBC over TG1.
2. The SBC performs the D+ query and the Local Tagging is performed at PSX for the TG1 and returns the Redirector IP as part of the reply.
3. The SBC sends the Egress Invite towards the SBC towards the Redirector.
4. Redirector sends 3xx with the contact containing UAS IP and DTG info as mentioned below:

Contact: <sip:9894192190@10.34.166.40:5060;dtg=SBC2_INGRESS_TG>

Platform/Feature: SBC

The code is modified to fix the issue.

Workaround: Enable the honorEmbeddedHeadersIn3xx or includeEmbeddedPAIheaderInRedirectedInvite to fix this issue.

Portfix SBX-98147: The SSBC is not forwarding a 200 OK response of the OOD INFO to INGRESS SLB.

Impact: The INFO message response was not being sent to correct SCM and as a result, the SCM was not getting the related TCB and dropping the message there.

Root Cause: The INFO message in the "From" header Tag was not including SCM information and as a result, the SIPFE was unable to get the correct SCM to process this response.

Steps to Replicate: 

1. Enable the non-invite relay configuration in TG.
2. The UE Client Send INFO message to the SBC.
3. The SBC will add the "From" header tag and forward it to UE server.
4. The UE server will send 200 OK towards the SBC.

Platform/Feature: SBC

Added SCM information in the "From" header tag.

Workaround: This issue will not be seen in the SBC with single SCM process.

Portfix SBX-90675: The SBC inserts the port number 5060 in the Record-Route headers.

Impact: The SBC adds a default port as 5060 for transport TLS in Record Route header of 18x.

Root Cause: When the flag noPortNumber5060 in IPSP is disabled, the SBC adds the default port in the Record Route header of 18x if the INVITE does not contain a port in RR.

Steps to Replicate: Include Record Route header in INVITE as mentioned below:

Record-Route:<sip:10.54.81.110:4589;transport=tcp;lr>,<sip:10.54.81.112;transport=tcp;lr>,

<sip:HHSIP@10.54.81.110;av-asset-uid=rw-75a842d6;lr;transport=tls>

Make the call and answer the call.

The SBC sends 18x towards ingress side.

Verify the Record Route in 18x.

Record-Route: <sip:10.54.81.110:4589;transport=tcp;lr>
Record-Route: <sip:10.54.81.112:5060;transport=tcp;lr>
Record-Route: <sip:HHSIP@10.54.81.110:5061;av-asset-uid=rw-75a842d6;lr;transport=tls>

Platform/Feature: SBC

When the flag noPortNumber5060 in IPSP is disabled, the SBC adds the default port 5061 for TLS transport and 5060 for other transports in the record route headers if the corresponding request/response does not contain port in record route header.

Workaround: The flag noPortNumber5060 in IPSP will be enabled. Then the SBC will not add default port.

Portfix SBX-97461: Both the SBC CLI and EMA allows to configure an invalid regex under the sipAdaptorProfile (SMM) that causes an SCM Process coredump once the SBC performs the regex operation (regstore).

Impact: The SBC may core when config SMM with invalid regex action.

Root Cause: The invalid action did not delete from rule when detect invalid.

Steps to Replicate: Configure the regex for invalid action, incoming call with valid criteria and action taken might caused core.

Platform/Feature: SBC

Delete the invalid action from the rule.

Workaround: Avoid configuration regex with invalid action.

Portfix SBX-99882: The SBC coredumped due to a Path Check.

Impact: The Pathcheck process may coredump when the pathCheck is state disabled on a FQDN based ipPeer.

Root Cause: The Pathcheck process hit a race condition that can occur when the DNS query completes AFTER pathCheck (on the FQDN based ipPeer) was state disabled that can cause a NULL pointer access coredump.

Steps to Replicate: This is timing dependent issue, that is very difficult to reproduce.

Attempt to reproduce by defining FQDN based ipPeer(s) with pathCheck profiles state enabled.

Randomly state disable and state enable the ipPeer(s) pathCheck profiles.

Platform/Feature: SBC

The code is modified to protect against the NULL pointer access.

Workaround: N/A

Portfix SBX-98949: Observing the error prints of 504 and increase in a retransmission while running the IPSEC load with multiple IPSEC-Tunnels.

Impact: In a large SWe SBC distributed NP Model, when multiple IPSec SA tunnels are established from different peers, IPSec packets getting dropped with anti-replay errors.

Root Cause: In a large SWe SBC distributed NP Model, scope of an anti-replay local compute was not correct, caused corruption and resulted in false anti-replay drops.

Steps to Replicate: Establish multiple IPSec SA tunnels from different endpoints and send the IPSec traffic to a large SWe SBC with Rx distributed NP Model and observe SA stats.

Platform/Feature: SBC

The code is modified so the scope of per worker ipsec dec anti-replay local compute is fixed.

Workaround: N/A

Portfix SBX-99783: The SBC is sending the generic number with the Presentation restricted instead of allowed.

Impact: The generic Number parameter sent to PSX does not have a presentation set when the X-Headers are supported, the Generic Number digits are derived from P-Asserted-ID and no X-CALLING-NUM header is received.

If the call egresses on SIP-I, this results in the ISUP Generic Number having presentation restricted, rather than a presentation allowed.

Root Cause: The presentation for a Generic Number not defaulted to allowed.

Steps to Replicate: X-Headers are supported. Send INVITE with Privacy: none header, no X-CALLING-NUM header, no X-GENERIC-NUM header and P-Asserted-ID with SIP and TEL URIs.

Platform/Feature: SBC

The code is modified to default presentation if not already set.

Workaround: N/A

Portfix SBX-99137: The GSX is not complete address in IAM, which resulted in the GSX rejecting with 484.

Impact: The Generic Number was sent to the PSX is does not have presentation restricted when the Privacy: id header is received, if X-CALLING-NUM header is received with presentation allowed and Generic Number is derived from P-Asserted-ID.

Root Cause: The presentation for a Generic Number not derived from Privacy.

Steps to Replicate: X-Headers are supported. Send INVITE with Privacy: id header, X-CALLING-NUM header with presentation allowed, and P-Asserted-ID with SIP and TEL URIs.

Platform/Feature: SBC

The code is modified to derive Generic Number presentation correctly.

Workaround: N/A

Unable to change the username of a configured AD Domain Controller through the EMA.

Impact: When creating a domain controller from the EMA, the username validation was failing for special characters because of that unable to create domain controller but CLI was accepting special character to username and able to create the domain controller.

Root Cause: The username validation was failing because the username param was not part of netconf request and netconf was throwing an error.

Steps to Replicate: 

1. Login into EMA.
2. Go to All -> global->servers->domain controller.
3. Click on New Domain controller button.
4. Fill the value in all field but for username need to put special characters.
5. Click on the submit button.

Platform/Feature: SBC

The code is modified so the EMA validates the username param based on default regex that is in the yang file.

Workaround: The backened code was modified so the workaround is not possible.

Portfix SBX-99923: The HW SBC GCM SRTCP encrypted packets dropped by the SWe SBC.

Impact: The HW SBC GCM SRTCP encrypted packets dropped by the SWe SBC.

Root Cause: The HW SBC is not including an E bit along with SRTCP index in GCM SRTCP encryption, that results in the SWe SBC decryption error drops.

Steps to Replicate: Test calls between the HW SBC and SWe SBC with GCM crypto suites, and verify SRTP/SRTCP packets are decrypted, relayed fine.

Platform/Feature: SBC

The code is modified to include an E bit along with SRTCP index in the GCM SRTCP encryption.

Workaround: N/A

Portfix SBX-100160: the Serf log file is missing from the Logrotate.

Impact: One of the serf log files, serfOutputMembership.log, is missing from the Logrotate.

Root Cause: The file was missed from LogRoate configuration. Since this is not a rapidly growing logfile, risk of this log file was filling up disk is very minimal.

Steps to Replicate: Install the build on cloud/swe and check if the serfOutputMembership.log is listed in /etc/logrotate.d/serfLogRotate

Platform/Feature: SBC

The code is modified to the LogRotate configuration.

Workaround: Manually add the serfOutputMembership.log to serfLogRotate.

Unable to create SIP SIG port on SBC5400 after upgrade to 8.2.1R0.

Impact: After an upgrade, additional the sipSigPort cannot be created on SBC5400 in certain ipInterfaceGroup configuration.

These SBC5400 configuration has an ipInterfaceGroup with ipInterfaces on packet ports on:

{pkt0,pkt2}, {pkt0,pkt3}, {pkt0,pkt2,pkt3}, {pkt1,pkt2}, {pkt1,pkt3}, or {pkt1,pkt2,pkt3} sets.

Root Cause: During an upgrade, the SBC5400 did not consider the fact that packet ports pkt0,pkt1,pkt2,pkt3 were all handled by the same Network Processor (NP). Instead SBC5400 behaved like SBC5200 - pkt0,pkt1 were handled by NP#0 while pkt2,pkt3 were handled by NP#1.

Steps to Replicate: 

1. Configure an ipInterfaceGroup, LIG1, with ipInterfaces on pkt0 and pkt2 on SBC5400. Configure the sipSigPort 1 with ipInterfaceGroup LIG1.
2. Configure another ipInterfaceGroup, LIG2, with ipInterfaces on pkt1 and pkt3 on SBC5400. Configure the sipSigPort 2 with ipInterfaceGroup LIG2.
3. After an Upgrade to 8.2.2, add a new sipSigPort with ipInterfaceGroup LIG1.
4. (Optional) After an Upgrade to 8.2.2, add a new sipSigPort with ipInterfaceGroup LIG2.

Platform/Feature: SBC

The code is modified so the SBC5400 correctly sets the packet port to NP mapping table entries.

Workaround: N/A

There are extra stop records getting generated when calls are cleared due to the dryup timer expiry.

Impact: There are extra stop records getting generated when calls are cleared due to the dryup timer expiry.

Root Cause: The call cleanup was not working correctly, and the original call cleanup is done by using NRM unsolicited list, which was causing the issue.

Steps to Replicate: 

1. Make three calls.
2. Put the TG in Out of Service.
3. The dryup timer will expire and the calls will get cleared by the SBC.

After step 3, check for the stop records.

Platform/Feature: SBC

Cleanup the calls by using the takeDownCalls method instead of keeping in NRM unsolicited list to fix the issue.

Workaround: N/A

Portfix SBX-99946: The SBC is not sending the RR/RS:0 in a 200 OK during RE-INVITE answer.

Impact: The SBC is not sending the RR/RS :0/0 in a 200 OK for RE-INVITE towards the ingress.

Root Cause: The issue is due to SBX-96087 JIRA changes, which was to modify GWFE code to set RTCP send and receive bandwidth as CPC_RTCP_BW_UNKNOWN if CPC parameter is not received from the Ingress SBC or GSX.

Steps to Replicate: Test Setup:
The SBC and GSX is configured to make SBX-GSX SIP-SIP call.

Procedure:

1. Configuration:
   Egress PSP: AMR (WB) Bandwidth efficient.
   Ingress PSP: AMR (WB) Bandwidth efficient.
   Transcode conditional flag enabled on both PSP
2. The RTCP is enabled in both the Ingress and Egress PSP and the RR/RS bandwidth is configured as 100 in Ingress PSP and as 200 in Egress PSP.
3. Flag the 'Send RR/RS in SDP' is enabled in IP signaling profile for both the Ingress and Egress.
4. Initiate a SIP-SIP Audio call with Audio codec as the AMR WB with RTCP bandwidth parameters in SDP as:
   b=RR:400
   b=RS:400
5. The Egress Answers with RTCP bandwidth parameters in SDP as:
   b=RR:300
   b=RS:300
6. Ingress end point sends Re-Invite with RTCP bandwidth parameters in SDP as:
   b=RR: 0
   b=RS: 0

Platform/Feature: SBC

Revert changes made for the JIRA SBX-96087 to fix the issue.

Workaround: N/A

The RTP Inactivity Timer fires early upon performing a port switch-over on the M-SBC and generates a duplicate STOP Record as a result.

Impact: During a high call load if thenSBC detects media inactivity, it generates a duplicate STOP record with the disconnect reason as Module Failure for a subset of calls.

Root Cause: When the RTP inactivity is detected for a call, the GCID of that call is added to a unsolicited call cleanup list.

When the call cleanup is invoked, if it finds that a previous call cleanup is going on then it generates STOP record for all the pending calls cleanups that it has not received a cleanup reply for.

As a result, this causes the duplicated STOP record generation for a few calls.

Steps to Replicate: 

1. Set the RTP inactivity timeout value.
2. Enable or disable the preventDuplicateEmptyStopRecOnInactivity​Detection.
3. Run call load such that RTP inactivity timeout occurs.
4. Notice that when preventDuplicateEmptyStopRecOnInactivity​Detection is enabled, there should be no duplicate STOP records for STOP records with disconnect reason as RTP inactivity.

Platform/Feature: SBC

The code is modified to configure whether the SBC should generate duplicate stop record on an inactivity detection or not.
Command - set oam accounting admin preventDuplicateEmptyStopRecOnInactivityDetection <enabled/disabled>

disabled (default): Continue with existing behavior (generate an empty STOP record in case of an RTP inactivity detection).
enabled: Stop the generation of empty STOP record in case of an RTP inactivity detection.

Workaround: N/A

Modify the codec from the Ingress update is not sent in the RE-INVITE to egress.

Impact: The E2eupdate flag is enabled but peer does not support an update. On the ingress side, support the update. The call is put in connected state. When the ingress modify update is received on the ingress leg, the egress side SBC has to send a RE-INVITE for media change. But the SBC fails to send.

Root Cause: When the E2eupdate is enabled, the SBC tries to send update instead of a reInvite but it failed in stack layer since allowing the update is not supported on the egress leg.

Steps to Replicate: The E2eupdate flag is enabled but peer does not support the update (2xx for an invite does not have allow: update) but on the ingress side, support the update. Call is in the connected state. Send the ingress modify update on the ingress leg.

Platform/Feature: SBC

The code is modified to check the peer supports update and then sends the update or else it is needed to send a reInvite.

Workaround: N/A

After a restart, the D2SSBC21 fails to register with the EMS.

Impact: The SBC is not registering with the EMS after a reboot.

Root Cause: The cloud-init is failing while processing a obj.pkl file and not fetching the user data. The LCA fails to find 'EmsPassword' entry in the existing user data file as it was removed by the keyKeeper on every boot up.

Steps to Replicate: Reboot the SBC and test that the SBC is getting registered with the EMS after a boot up.

Platform/Feature: SBC

Avoid the cloud-init failure by removing the obj.pkl file in the LCA.

Workaround: Remove the /var/lib/cloud/instance/obj.pkl file manually and reboot the system.

The VLAN tagged interfaces on the Guest instance are not reachable.

Impact: The VLANs on the guest does not work with the X-710 NIC SR-IOV mode in VMWare Setup.

Root Cause: There was issues with the i40en driver from VmWare that was fixed in 1.8.6 version. The SBC was not configuring the VLAN from the VF to the F properly, which was fixed.

Steps to Replicate: Configure the VLAN on the guest with X710 SR-IOV on VmWare Setup and the interface should be reachable and test that the SBC is getting registered with the EMS after a boot up.

Platform/Feature: SBC

Avoid the cloud-init failure by removing the obj.pkl file in the LCAThe code is modified so the SBC configures the VLAN from the VF to the F correctly.

Workaround:  Remove the /var/lib/cloud/instance/obj.pkl file manually and reboot the system.N/A

There is a possibility of performance degradation on the 138 CPS with a high number of SMMs.

Impact: The loglevel is set to major and set the global callTrace configuration with level1, When the application invokes the debug function for the info level logging, the debug function is not filtering those logs and instead invokes the snprintf and calls eventHandler for logging. These logs are filtered at second level that has caused the performance congestion.

Root Cause: This is caused due to new changes done for the SIP_LOG_TRACE_L123 logging.

Steps to Replicate: 

1. Set the loglevel to major.
2. Set the global callTrace configuration with level1.
3. Configure a high number of SMM rules.
4. Run a load test on a basic call.

Platform/Feature: SBC

The code is modified to filter the logs with both the SIP_LOG_TRACE_DATA and SIP_LOG_TRACE_L123.

Workaround: N/A

There is a possibility of performance degradation on the 138 CPS with a high number of SMMs.

Impact: The loglevel is set to major and set the global callTrace configuration with level1, When the application invokes the debug function for the info level logging, the debug function is not filtering those logs and instead invokes the snprintf and calls eventHandler for logging. These logs are filtered at second level that has caused the performance congestion.

Root Cause: This is caused due to new changes done for the SIP_LOG_TRACE_L123 logging.

Steps to Replicate: 

1. Set the loglevel to major.
2. Set the global callTrace configuration with level1.
3. Configure a high number of SMM rules.
4. Run a load test on a basic call.

Platform/Feature: SBC

The code is modified to filter the logs with both the SIP_LOG_TRACE_DATA and SIP_LOG_TRACE_L123.

Workaround: N/A

Portfix SBX-97079: After the LDG triggered a switch over, the SBC is rejecting all the register message with 500 internal error.

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

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

Steps to Replicate: The steps cannot be reproduced.

Platform/Feature: SBC

The code is modified to prevent accessing a NULL pointer, when attempting to generate the debug log message.

Workaround: N/A

Portfix SBX-96996: The SCM Process cored.

Impact: When the pathcheck timeout and the SBC is unable to find a zone, the SBC may core as a result.

Root Cause: Attempting to access the null pointer.

Steps to Replicate: The steps cannot be reproduced.

Platform/Feature: SBC

Check for a valid zone pointer before accessing the null pointer.

Workaround: Disable the pathcheck. 

Portfix SBX-97960: Incorrect transparency functionality causes calls to fail.

Impact: The To header transparency and launching a successful ENUM query may causenan incorrect RURI format. 

Root Cause: The RURI build was based on the To header.

Steps to Replicate: Enable the To header transparency and the PSX ENUM LNP response may contain an empty “Called URI”

Platform/Feature: SBC

The code is modified so the RURI is independent of the To header.

Workaround: N/A

The SBC 5400 was displaying the wrong routing info in the GUI and correct info in the CLI.

Impact: The GUI is displaying wrong routing information for the routing labels, memory usage, and the zone in the routing label in the GUI.

Root Cause: The wrong routing information for routing labels when a few records fetched for Routing labels list the
EMA application taking the memory information in a wrong way from the free command.

Steps to Replicate: Go to the routing page, create a routing label and edit the same correct routing label information will be shown.

Platform/Feature: SBC

The code is modified to remove the limit in a call to get the routing labels list and give the table option to select Routing Label in route create/Edit form.

Workaround: N/A

A failover occurred because of a ScmP core.

Impact: The SBC may core when trying to send the 18x to Ingress, and when enabling the reason header transparency. The Egress may teardown too early, which can cause the Ingress to access an invalid pointer.

Root Cause: The SBC accesses an invalid pointer when attempting to check the transparency reason headers.

Steps to Replicate: Configure the reason header transparency, the egress answers with a 180 with SDP and the peer answers with a failure to PRACK. The SBC may require to run load as a result.

Platform/Feature: SBC

Validate the pointer before attempting to access the pointer.

Workaround: Disable the transparency reason header or the PRACK.

Portfix SBX-96087: The SBC is not sending RTCP to the egress Peer for a transcode only.

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

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

Steps to Replicate: 

1. Reproduce the problem by using the following call flow:

Ingress Peer -- SIP -- GSX -- GW2GW -- SBC -- SIP -- Egress Peer

Use a transcode only call.

Result: No RTCP is sent by the SBC to the egress. 

2. Verify the issue by applying the SamP with a GWFE change but did not change in the ScmP. (Just debugging logs

Use the same setup. The RTCP traffic was sent from the SBC to egress.

Platform/Feature: SBC

The code is modified to set the RTCP send and receive the bandwidth as CPC_RTCP_BW_UNKNOWN if the CPC parameter is not received from the Ingress SBC or GSX. This ensures the RTCP mode for the XRES resource is duplex and the SBC sends RTCP towards the egress SIP endpoint.

Workaround: Enable the RTCP termination for pass through flag on the PSP

Portfix SBX-97199: The Wall Comcast PM-SBC memory was increasing.

Impact: There is a memory leak in the PRS. There are leaking structures associated with certain interprocess messages.

Root Cause: There are leaking structures associated with certain interprocess messages because these structures were not being freed.

Steps to Replicate: Unable to reproduce the issue, the problem was identified based on coredump and code analysis.

Platform/Feature: SBC

The code is modified to free the memory for certain interprocess messages.

Workaround: N/A

Inconsistent behavior in a specific call flow when the SMM tears down the call.

Impact: If the SMM teardown functionality is being triggered on a 200ok of UPDATE, without responding to pending update method, the final response is being sent to the initial invite.

Root Cause: Update handling before the call is connected was missing in the case of the SMM Teardown functionality.

Steps to Replicate: Write a SMM Rule to be triggered when receiving a 200 ok of update with a teardown action. Send the update before the 200 ok of invite is being received from the UAC and execute the test.

Platform/Feature: SBC

The code is modified for the UPDATE received before a call is connected.

Workaround: N/A

Portfix SBX-92386: The SBC running the 721R2 release is responding with 'a=inactive' instead of 'a=sendrecv' in the 200ok SDP to late media re-invite, resulting in no audio.

Impact: It was not RFC compliant to send a=inactive to the late media re-INVITE after the peer put the SBC on hold.

Root Cause: There was a missing requirement.

Steps to Replicate: The following scenarios were tested where – on receiving a re-invite from the ingress peer on a stable PCM-U passthrough fax call, the SBC will maintain this call in fax mode and suppresses any re-invites to the egress peer.

Ingress peer removes DTMF in re-invite
Ingress peer adds DTMF in re-invite
Ingress peer adds ss:off in re-invite
Ingress peer removes ss:off in re-invite

There are some explicit scenarios where the SBC will switch the call from fax back to voice. A DEV will need to add these.

Platform/Feature: SBC

The code is modified to send a=sendrecv to make it RFC compliant.

Workaround: N/A

Portfix SBX-93311: Send a local response for a reInvite in a Fax call.

Impact: For a G.711-T.38 Fax call, if the SBC receives a G.711 reInvite with a change in SDP from ingress peer, then the SBC sends a G.711 reInvite to egress peer. Users expect the SBC to stay in a Fax call and not send any reInvite to the Egress peer.

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

Steps to Replicate: 

- Ingress PSP: PCMU, 2833, FTT=FBG711, MTT=AFTT
- Egress PSP: PCMU, 2833, FTT=FRorFBG711, AFTT enabled in p2pControl

1. A PCMU-PCMU voice passthru call is established.
2. T.38 ReInvite received from egress peer.
3. SBC sends PCMU ss:0ff reInvite to ingress peer.
4. Ingress peer answers with PCMU, 2833 (no SS:off).
5. PCMU-T.38 XCode call is established.
6. After approximately six seconds, the ingress peer sends reInvite with PCMU (removes 2833).
   

Platform/Feature: SBC

The code is modified to handle the issue so that:

• Whenever the SBC detects a change in the SDP for a fax call LEG.
• If the codec active for that fax call LEG is G711.
• There is no change in G711 LAW.

The SBC stays in the fax call and sends 200OK with an answer-SDP as per last offer-answer negotiation.

Workaround: N/A

Portfix SBX-85374: Empty the "Egress Local Signaling IP Addr" field in the CDR after an upgrade to V07.01.00R001.

Impact: "Egress Local Signaling IP Addr" field in the CDR is not populated during some race conditions.

Root Cause: When the disconnect Ind from the Egress SG is received, store the Egress Trunk Info that has the local IP signaling address.

Steps to Replicate: 

1. The Ingress INVITE is received and the egressed out.
2. The Ingress receive CANCEL and egress receive an error response at same time.
3. Race condition between CANCEL and error response from egress for INVITE must be triggered.

Platform/Feature: SBC

Store the Egress Trunk Info that has the local IP signaling address.

Workaround: N/A

Portfix SBX-96439: There is an AD sync issue when having multiple DCs / adServerlist entries configured.

Impact: When there are more then domain controllers attached to an ad profile, the sync operation fails when the application fetches data from the second server.

Root Cause: Once the sync is complete with the first server, the application was freeing the ad attribute data structure that is needed for all the subsequent servers. Since the data structure was freed, the PES used to send wrong ldap query.

Steps to Replicate: Create two domain controllers with same data. Attach both the dc servers to the ad profile. Trigger a adManualSync event. This step will reproduce the issue.

Platform/Feature: SBC

Ensure that the ad attribute structure is freed after all the servers are synced.

Workaround: N/A

Portfix SBX-95241: A ScmP core occurred on the server.

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

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

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

Steps to Replicate: Perform a coredump analysis and code review.

Platform/Feature: SBC

The code is modified to not read more characters than are present in the hostname to avoid reading off the end of the memory block.

Workaround: N/A

Portfix SBX-94610: The Bye URI Messages do not include the domain.

Impact: When an incoming INVITE contains Contact header with GR tag and call flow (
SIP-SBC1 -- GW - GW - GSX- ISUP), the SBC includes the IP address in the reqURI of BYE message and not the FQDN present in the Contact of Ingress INVITE.

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

Steps to Replicate: 

1. Reproduce the issue by using the following call flow:

When the incoming INVITE contains Contact header with GR tag
Contact: <sip:gw@gw0-1.new-york-1.pstn.jnctn.net;gr=gw0-1.new-york-1.pstn>

The call flow is listed as:
SIP-SBC1 -- GW - GW - GSX- ISUP, SBC includes IP address in reqURI of BYE message and not FQDN ( present in Contact of Ingress INVITE )

439 12202019 131244.050245:1.02.00.09411.Info .SIPCM: SipFeSocketSendMsg - msg = BYE sip:gw@10.158.70.250:5060 SIP/2.0
Via: SIP/2.0/UDP 10.158.130.58:5060;branch=z9hG4bK0cB0000efe682df85e5

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

Platform/Feature: SBC

The code is modified to ensure the SBC sends FQDN (present in Contact header of an Incoming INVITE ) in the reqURI of a BYE message.

Workaround: N/A

The output of the CDR smmfield is null after the teardown, even though the SBC writes the values to the smmfield.

Impact: When the CDR update and the SMMTeardown action is being configured as part of the same SMM Rule, the SMM CDR fields are not being populated.

Root Cause: Before the SMM CDR data is being copied from SG Active context to CCB structure, the SMM CDR data is being cleared.

Steps to Replicate: Create a rule to the SMM CDR update and the SMMTeardown action being part of the same SMM Rule. Run the call to trigger the SMMTeardown action.

Platform/Feature: SBC

When SMM Teardown action is being selected, if SMM CDR data is there in active context, copy the data to CCB structure.

Workaround: Make a SMM CDR update and SMM Teardown part of the different rules.

Portfix SBX-94736: The SBC is converting two of the same rtpmap into 1 line.

Impact: Duplicated media payload may have caused a syntax error when the sdpSelectedAttribueRelay to the other side.

Root Cause: Duplicated attribute lines are merged into one line.

Steps to Replicate: Configure the sdpSelectedAttribeRelay and transcode free. An incoming sdp with a duplicated media payload may have caused syntax error when sent to the other leg.

Platform/Feature: SBC

The code is modified to ignore the duplicated media payload and attributes lines.

Workaround: N/A

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 is no check whether the "not" is applied to complete expression or not.

Steps to Replicate: 

1. Log on the EMA.
2. Navigate to All->profile->services->Transparency profile->SIP Header
3. Select the transparency profile.
4. Click on the New Sip Header. After performing this scenario, the "Ignore Transparency " field can be observed.

Platform/Feature: SBC

Created method for checking "not" is applied to whole expression or not.

Workaround: N/A

The SBC 8.2 behavior changes with the sendSdpInSubsequent18x enabled.

Impact: A behavior change was introduced on the 8.2.0 whereby the SIP 18x response messages will not include the SDP after a reliable provisional response had been sent, even when the "Send SDP In Subsequent 18x" was selected in the IP Profile. This was done to make the behavior consistent with the RFC 6337 but some customers wish to have the non-compliant behavior so that will remain the default.

Root Cause: There is a missed requirement for some customers to retain the non RFC 6337 behavior.

Steps to Replicate: Make a SIP-SBX-SIP call with multiple 18x responses. The ingress IP profile has Send SDP In Subsequent 18x selected. 18x messages after the first reliable response do not contain SDP.

Platform/Feature: SBC

The code is modified to configure the RFC 6337 compliance:
set addressContext default zone ZONE1 sipTrunkGroup TG1 signaling onlySendSubsequent18xSdpIfUnreliable enabled

When this control is enabled, the SBC only sends the SDP in subsequent 18x responses while they are unreliable.

Workaround: N/A

Portfix SBX-91208: For the Egress Invite, the SBC will send the original dialed number in the user part and the new RN in the 'rn' parameter.

Impact: For the Egress Invite, the SBC will send the original dialed number in the user part and the new RN in the 'rn' parameter.

Root Cause: In the case of number translation, the SBC was returning the called number instead of dialed number and caused this issue.

Steps to Replicate: Enable the flag below to send the original dialed number in the Egress R-URI:

admin@TICKH% set global servers enumService TEST_0 flags sendOrigDialedNumOverEgress enable

Rerun test cases with the same configurations.

Platform/Feature: SBC: Application, Documentation

The code is modified to fix the issue. A new flag – sendOrigDialedNumOverEgress – is added to support backward compatibility. The default value of the flag sendOrigDialedNumOverEgress  is Disabled.

 
Workaround: N/A

The sonusDatabaseConfigPolicyDataSyncNotification continues to be output after reinstalling the SBC.

Impact: When the customer is using the Direct Single Mode, the system is sending an DbOutOfSync trap continuously.

Root Cause: After analyzing the code, it was found that there is a data mismatch in the PolicyDb and CDB .As a result, it is sending the tarp.

Steps to Replicate: The system being out of sync will not trigger the Direct SBC Mode.

Platform/Feature: SBC

The code is modified to restrict the DBSync check for the Direct SBC mode the same way as the OAM Mode.

Workaround: N/A

Portfix SBX-97581: The SBC adds the media IP address in the outgoing SDP, even when the call is a direct media call.

Impact: When a direct media is enabled when handling re-INVITE from ingress endpoint without SDP change, the SBC sends a 200OK answer to ingress with the SBC's own media IP address. This causes a one way audio issue.

Root Cause: When a direct media is enabled, while handling re-INVITE relay transaction, the SBC does not update the SIPStack SDP correctly.

Steps to Replicate: 

1. Reproduced the issue and checked that the 200OK to the ingress as response to re-INVITE has the SBC's media IP address.
2. Verified that a 200OK response to ingress has the egress peer's IP address and not the SBC's media IP address.

Platform/Feature: SBC

The code is modified to ensure the SBC updates SIPstack SDP for direct media scenarios.

Workaround: Use SMM to force SDP modification in re-INVITE from ingress.

Portfix SBX-97830: The ipRecMetadataProfile does not work for a request-uri in the V07.02.02.

Impact: The Invite SIPREC may not have a request-uri beta or core.

Root Cause: A logical error that has access the wrong data structure.

Steps to Replicate: Configure the metadataProfile with a request-uri and enable the SIPREC on ingress.

Platform/Feature: SBC

The code is modified to correct the logical error.

Workaround: Do not configure the request-uri in metaDataProfile.

Portfix SBX-97617: The SBC application restarted twice.

Impact: The SCM cored due to a segmentation fault.

Root Cause: The SCM hit a Segmentation fault due to an attempt to de-reference a NULL pointer.

Steps to Replicate: The steps cannot be reproduced.

Platform/Feature: SBC

The code is modified to ensure that the pointer is not NULL before de-referencing it.

Workaround: N/A

The active calls count much larger than the stable calls count.

Impact: The active calls count is much larger than stable calls count under "show table global callCountStatus" after the memory upgraded from 12 GB to 24 GB.

Root Cause: The SBC 51xx with memory upgrade caused an incorrect GCID mask resulting in an incorrect active call count.

Steps to Replicate: The steps cannot be reproduced.

Platform/Feature: SBC

The code is modified to set the correct GCID mask after a memory upgrade for the SBC 51xx.

Workaround: N/A

The SBC does not send precondition attributes in the 200 OK of UPDATE.

Impact: The SBC does not send preconditions in the 200OK of UPDATE when the UPDATE is received in the egress LEG with the SDP same as that of 18x.

Root Cause: Precondition parameters were not getting updated as the processing is returned from SIP stack since there was no change in SDP.

Steps to Replicate: 

1. Perform the egress precondition interworking scenario.
2. Send an UPDATE from egress with SDP same as the 18x.
3. Precondition attributes are incorrect in the 200OK for this UPDATE.

Platform/Feature: SBC

The code is modified to process this UPDATE in the upper layers.

Workaround: N/A

Portfix SBX-96992: The TLS Call failures observed on the ATL1-CUSBC-05 due to a port value set to 1 instead of 5061.

Impact: The SBC uses Port 1 for sending an INVITE out for TLS protocol, when the route header was received without port.

Root Cause: When the route header is received without port in it, the SIPSG was incrementing the port for TLS. Since no port was received, the port received is considered as 0. So for the TLS, increment by 1 as a result. So when the port was incremented, the port becomes 1 and this gets used for send INVITE that is resulting in failed calls.

Steps to Replicate: Send a Route Header without a port Route: <sip:10.54.80.8:;lr>. The SBC will use port 1 for sending INVITE that is causing the issue.

Platform/Feature: SBC

The code is modified to check whether the port is received in the route header or not. If port is received, then increment the port for the TLS, or do not increment and allow the SIP stack to handle it.

Workaround: Sending the Route Header with a port will avoid this issue.

Portfix SBX-96790: The SBC 8.1 was missing the HPC_CTL_TFC_EXEM value in the CallCountIntervalStats.

Impact: The HPC_CTL_TFC_EXEM value was missing in CallCountIntervalStats.pms file.

Root Cause: The HPC_CTL_TFC_EXEM field was not present in the CallCountIntervalStats.pms file.

Steps to Replicate: 

1. Enable the CallCountIntervalStats.pms file using the system fileStatisticsAdmin CLI command.
2. Wait 15 minutes.
3. Access the cd /var/log/sonus/sbx/statistics on the SBC.
4. Untar the stats file.
5. View the CallCountIntervalStats.pms.
6. Verify that the HPC_CTL_TFC_EXEM is present in that file.

Platform/Feature: SBC

The code is modified to add the HPC_CTL_TFC_EXEM value to the CallCountIntervalStats.pms file.

Workaround: N/A

Upgrading to the 8.2 failed.

Impact: When two different IpPeers with same name are configured, one in CAPS and other in small letter, the SBC is coring as a result.

Root Cause: When the SBC tries to add a second IPPeer entry. It tries to bind the name for the IP Peer. Since there is already another IPPeer with the same name NamedInsert fails, after that, the SBC tries to delete the IP Peer entry from the hash.

While deleting the IpPeer Entry, the SBC tries to delete the response code stats hash table for the peer entry
SipSgDeleteIpPeerResponseHash(peerEntry);

In the routine:
SipSgDeleteIpPeerResponseHash(SIPSG_IP_PEER_STR *peerEntry)

responseHashPtr = HashFirst(peerEntry->responseStatsHashTbl);

At this point, the peerEntry->responseStatsHashTbl is not created and is NULL so this results in a coredump.

Steps to Replicate: Configure two IPPeer with the same name, one in capital letter and other in small letter.

Platform/Feature: SBC

The code is modified to add a NULL check for responseStatsHashTbl before deleting.

Workaround: N/A

Portfix SBX-94579: After an upgrade, all CNAM Trunks are set to a Subscribe Rate of 1.

Impact: When the LSWU upgrade completes, the SIP Trunk Group CAC ingress/egress subscribeRateMax and subscribeBurstMax are over written with the registerRateMax and registerBurstMax values.

Root Cause: This is functionality that was added in the SBC V3.1 when the SIP Trunk Group CAC ingress/egress subscribeRateMax and subscribeBurstMax were first added (but their value was not set).

Steps to Replicate: 

1. Configure the SIP Trunk Group CAC ingress/egress subscribeRateMax and subscribeBurstMax.
2. Perform an LSWU upgrade.

Observe that the SIP Trunk Group CAC ingress/egress subscribeRateMax and subscribeBurstMax are now set equal to registerRateMax and registerBurstMax values.

Platform/Feature: SBC

The source code that provides this functionality is removed, because it is no longer needed.

Workaround: If possible, configure the subscribeRateMax equal to registerRateMax, and the subscribeBurstMax equal to registerBurstMax.

Portfix SBX-95470: The SBC was using the incorrect SIP signaling port for a challenged Subscribe.

Impact: When the usePortRangeFlag is enabled, the SBC may use an incorrect SIP Signaling Port when handling a SUBSCRIBE request with an Authorization header, in REGISTER - SUBSCRIBE scenarios when the initial SUBSCRIBE request is challenged.

Root Cause: When the usePortRangeFlag is enabled, the application software uses the wrong connection Id when sending the SUBSCRIBE request with Authorization header to the egress peer.

Steps to Replicate: 

1. Provision the SBC to support CUCM (Cisco Unified Connection Manager).
2. Perform a REGISTRATION.
3. Perform a challenged SUBSCRIBE.

Platform/Feature: SBC

The code is modified to use the proper connection Id, when the usePortRangeFlag is enabled, and the SUBSCRIBE request with Authorization header is sent to the egress peer.

Workaround: N/A

Portfix SBX-92582: A large increase in sonusSbxSscsRouteFailureWithoutGapNotification2 traps.

Impact: When the PSX has more than 10 routes configured and the SBC receives those routes in multiple PSX responses and if all the routes fail, the SBC still makes additional diameter query towards the PSX. This causes the PSX to send error: No Routes in Cache to SBC. The SBC logs a trap after receiving the No routes in cache error.

Root Cause: The SBC makes addition query to the PSX even after the PSX sent all the routes.

Steps to Replicate: 

1. Configure more than 10 routes on PSX Routing Label ( 11 routes for example )
2. All 10 routes fail.
3. The SBC sends another query and get more route and those fail as well.
4. The SBC still send additional query to the PSX that fails because the PSX have returned all of them.

Platform/Feature: SBC

The code is modified to ensure the SBC avoids sending additional Diameter query to the PSX when the PSX has returned all the routes.

Workaround: N/A

Portfix SBX-91057: The SBC fails to relay the 4xx-6xx responses when the IPTG authentication is enabled. All SIP causes get mapped to the CPC176 CPC_DISC_TG_AUTH_FAIL.

Impact: When the IPTG authentication is enabled, the SBC maps all the 4xx-6xx SIP codes to CPC 176. As a result, the SBC is unable to relay cause code from egress to ingress endpoint.

Root Cause: When the IPTG authentication is enabled, the SBC maps all the 4xx-6xx SIP codes to CPC 176.

Steps to Replicate: 

1. Egress sends the 183 Session Progress
2. Egress sends the 486 Busy Here.
3. The SBC does not send the 486 Busy code to Ingress.
4. Instead sends 599 that is mapping of 176 ( CPC_DISC_TG_AUTH_FAIL which is CPC code ) to Ingress.

With a fix, the SBC sends 486 buys to ingress correctly.

Platform/Feature: SBC

The code is modified to ensure the SBC upon receipt of provision response clears the authentication flag and relays cause the code from egress to ingress.

Workaround: Use the SMM Rule. 

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

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

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

Steps to Replicate: 

1. Enable Downstream Forking and the forking response as anything except the first prov response.
2. Simulate the callflow .
3. Keep PSP's setup to do transcode only ( but same issue might be observed otherwise also if initially the early media is setup as transcoded).

Platform/Feature: SBC

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

Workaround: Set Early Dialog as SIP_EARLYDIALOG_FORKING_BEHAVIOUR_FIRSTPROVRESP.

The sonusDatabaseConfigPolicyDataSyncNotification continues to be an output after reinstalling the SBC.

Impact: When customer is using Direct Single Mode, the system is sending a DbOutOfSync trap continuously.

Root Cause: After an analysis of the code, there is data mismatch in PolicyDb and CDB and is sending tarp as a result.

Steps to Replicate: Out of sync will not trigger for the Direct SBC Mode.

Platform/Feature: SBC

Confirm the customer is not using the ERE is the Direct SBC mode.  As a result, the code is modified to restrict the DBSync check for the Direct SBC mode same as OAM Mode.

Workaround: N/A

Unable to delete the User Session from the EMA.

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

Root Cause: The issue occurred due to a missing value of the remove session call from the UI.

Steps to Replicate: 

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

Platform/Feature: SBC

The code is modified to add the missing call for removal of session.

Workaround: Copy ema-ui.war into /opt/sonus/ema/sbxema/deploy/ location.

The SBC SWe (VMware/KVM) second management interface to add.

Impact: Adding a second management port to the SWe VM after the ISO and application installation results into the PRS coredump.

Root Cause: Second management port info is not loaded into the CDB after it is added to the VM running with an already installed SWe application.

Steps to Replicate: Install the SWE ISO and application and shutdown the VM. Add second management port (5th interface), power on the VM and ensure application comes up correctly.

Platform/Feature: SBC

The code is modified to create seed XML data for a second management port and add it to the CDB, even if second management port is added after the SWe application installation.

Workaround: Need to manually create the XML seed data for second management port and load it into the CDB.

Portfix SBX-91737: The external PSX became active after a switch over, though it was OOS prior to the switch over.

Impact: When changing multiple remote policy servers's mode together in one "commit", some of the server's operational stats in the standby node might not be synced.

Root Cause: When one of the remote policy servers' mode was being changed from the OOS to active, the standby node did not try to register with this server, and the iteration of all mode change servers will be stopped. This would cause the rest of the servers, whose operStats have not been changed and remain unchanged. As a result, the operStats of these servers at standby node will be out of sync with the active node.

Steps to Replicate: 

1. In a working HA, provision at least 3 working remote policy servers.
2. While keeping the admin stat enabled, only keep 1 of the servers' modes as active, and rest as out of service.
3. Change those servers' mode, commit only after all set commands are finished.
4. Display the status using the 2 commands below:
   "show table system policyServer remoteServer"
   "show table system policyServer policyServerStatus"
5. Perform a switch over
6. Repeat step 4. The operStat will be different from step 4.
7. Making call load when Node A is active, and then another call when Node B is active. When Node B is active, the policy request may still be sent to the remote server that is already OOS when Node A was active.

Platform/Feature: SBC

The code is modified in the standby node to be able to modify the operStats for all remote servers requested by the CLI users. The remote servers are unable to be registered even if the mode is being changed from OOS to active. As the result, the operStates at standby node keep synced with the active node.

Workaround: Restart the non-synced node. As a result, this will have traffic loss.

Portfix SBX-94577: The standby fails to start and connect to the active and shuts back down instead.

Impact: The standby fails to start and connect to the active and shuts back down instead.

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

Steps to Replicate: The steps cannot be reproduced.

Platform/Feature: SBC

The code is modified to recover the checkpoint address if it is unknown.

Workaround: N/A

Portfix SBX-93105: The SIP OPTIONS are not responding after a failover.

Impact: A syntax error message during a switch over was unable to respond.

Root Cause: Internal messages drops due to other subsystems not being ready to process the message. Subsequent messages have been stuck in the queue.

Steps to Replicate: Use the ping Options messages during a switch over.

Platform/Feature: SBC

The code is modified so during switchover, the message drops.

Workaround: N/A

Portfix SBX-94245: The SBC picks up the incorrect TG for incoming, non-INVITE requests and responds to non-INVITE requests.

Impact: The SBC is picking up the wrong trunk group for incoming messages. This is specific for rare configuration when there is only 1 sigport sharing multiple trunkgroups, and the same peer source address was routing traffic to different trunkgroups.

Root Cause: When the SBC processes inbound/outbound msgs, it put the TG into the cache table for processing after the response. In this case, there are 2 trunkgroups that swap back and forth for the same peer address. As a result, a subsequent request OOD may pick up the wrong TG due to the registered end point.

Steps to Replicate: Have the following conditions set up to replicate the issue:

1. Perform a configuration when there is only 1 sigport sharing multiple trunkgroups, and the same peer source address is routing traffic to different trunkgroups
2. A call B sharing the same signaling port and same peer IP.
3. A OOD to SBC and route back to A.
4. Both cases the out bound is using different TG.

Platform/Feature: SBC

The code is modified to no longer put and outbound OOD in the cache table to avoid swapping the TG. The SBC puts the outbound OOD request in a different new hash table and later received a response from the request to look at new hash table for the TG.

Workaround: N/A

In the QSBC format CDR, fields 1, 106, 106, 123 contain date and time in UTC. These fields should contain date and time in local time.

Impact: The time stamp (field numbers 1, 106, 106, and 123) prints in UTC instead of local time.

Root Cause: Design issue.

Steps to Replicate: Make a call with QSBC format CDRs enabled.

Platform/Feature: SBC

The code is modified to use the local time instead of UTC.

Workaround: N/A

The SBC DatabaseIntegrity policies were not inSync after an Upgrade.

Impact: The database integrity table on the CLI shows 'notApplicable' for the SBC 1:1 HA mode.

Root Cause: The configure mode for SBC 1:1 HA is returned as a 'CONFIG_MODE_UNKNOWN' instead of the 'CONFIG_MODE_SBC', which sets the status to 'notApplicable'

Steps to Replicate: Launch the SBC 1:1 HA and run a Confd CLI command:
'show table system databaseIntegrity'

Platform/Feature: SBC

The code is modified to return 'CONFIG_MODE_SBC' in case of the SBC 1:1 HA mode.

Workaround: N/A

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

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

Root Cause: The issue occurred when trying to retrieve maximum of 20 labels.

Steps to Replicate: 

1. Log on to the EMA.
2. Click on Configuration->System Provisioning->Routing->Routes
3. Click on the Routing label scroll bar.

Platform/Feature: SBC

The code is modified to adjust maximum limit for retrieving the routing labels.

Workaround: N/A

The logic responsible for updating zone -> callCurrentStatistics -> totalOnGoingCalls counter is flawed. The totalOnGoingCalls counter does not get decremented in some scenarios.

Impact: In certain scenarios, the zone->callCurrentStatistics->totalOnGoingCalls is not decremented and therefore it shows invalid values.

Root Cause: For early cancel scenarios, the code still considered the user was in an on-going call and displayed the incorrect totalOnGoingCall counter.

Steps to Replicate: To replicate the issue, receive the 180 ringing from UAS and then hang up before the UAS answers the call. The ongoing calls counter will get decremented.

Platform/Feature: SBC

The code is modified to correctly display the callCurrentStatistics for early cancel scenarios.

Workaround: N/A

The sysdump causes the SBC application shutdown due to a disk usage.

Impact: The sysdump causes the SBC application shutdown due to a disk usage.

Root Cause: Size of the sysdump was unknown and no check was present to verify the available space.

Steps to Replicate: Run the sysdump script in both normal and dryrun mode.

Platform/Feature: SBC

A new dryrun mode (-D) is introduced. When the script is run in dryrun mode, it calculates the approximate size of the final sysdump but not create the actual sysdump. For the ACT logs, a new option (-H) is introduced. Using this option, the user is able to give the number of hours for which the ACT logs to be collected in sysdump.

Workaround: N/A

Portfix SBX-97415: The SIP From header constructed in the SIP stack does not conform with the RFC.

Impact: The From header in ACK is not the same as shown in a previous Invite.

Root Cause: The issue is caused by SMM modifying the From header in the Invite and the SBC generating ACK based on the response.

Steps to Replicate: 

1. Using the SMM to modify the From header in Invite Request.
2. Peer answer 200OK, with the modified From header.
3. The SBC generate ACK based on the From Header received in response.

Platform/Feature: SBC

The code is modified to send the From header in ACK based on the From original request.

Workaround: Use the SMM to restored From header in 200OK.

A failover occurred because of a SAM Process core.

Impact: There were reports of a SAM Process crash stack indicating a Cavecreek QAT driver API may have caused memory segmentation, causing a switchover on the SBC7000 while verifying a TLS client's certificates during a TLS handshake.

Root Cause: Incompatible third-party QAT crypto driver with the current OpenSSL version, Linux kernel, and cipher suites was used in the current certificates.

Steps to Replicate: After an App installation or an Upgrade, ensure that the QAT engine is no longer used by the SIMCM (SAM Process) by checking DBG log.

Example: The following DBG message should be seen:
[root@BF001 ~]# grep -i engine /var/log/sonus/sbx/evlog/1000003.DBG
087 06232020 062948.762154:1.01.00.00609.MAJOR .SIPCM: *Dynamic engine not supported
[root@BF001 ~]#

Platform/Feature: SBC

Due to Cavecreek QAT and its driver being End-of-Life and improved OpenSSL performance in RSA key operations, use the OpenSSL optimization in the RSA key operations to support TLS handshake. The QAT crypto engine is no longer used by the SAM Process and IkeProcess on the SBC7000 and SBC5400.

Workaround: None.

After a restart, the SBC fails to register with EMS.

Impact: The SBC is not registering with EMS after reboot.

Root Cause: Cloud init is failing while processing a obj.pkl file and not fetching the user data. The LCA fails to find the 'EmsPassword' entry in an existing user data file as it was removed by keyKeeper on every boot up.

Steps to Replicate: Reboot the SBC and test that the SBC gets registered with EMS after boot up.

The code is modified to avoid the cloud-init failure by removing obj.pkl file in the LCA.

Workaround: N/A

The error popup appears when the import configuration to the M-SBC.

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

Root Cause: After sending a request from the SBC manager, it was getting a timeout when performing a start import operation. This operation calls the configTemplate internally for the api of the platform Manager. Using this api, execute the importCLI.pl script with required inputs. Once this script is complete, then the configTemplate api returns the response to the SBC manager that takes 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 Upload .cli file.
3. Go to Administration --> System Administration --> Configuration Script and Template Import.
4. Select uploaded .cli file and click on startImport button.

Platform/Feature: SBC

The error popup appears when importing configuration to the SBC.

Impact: The error popup appears when importing configuration to the SBC.

Root Cause: After sending request from the SBC manager, it was getting a timeout due to performing a start import operation. This operation calls for the internal configTemplate api on the platform manager. When using this api, execute importCLI.pl script with the required inputs. Once this script is complete then the configTemplate api returns the response to the SBC manager.

Steps to Replicate: 

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

Platform/Feature: SBC

The code is modified to provide an immediate response and get the Status api to read the current status of the running importCLI in every 5 seconds to know about the process status.

Workaround: N/A

The SCM coredumps after PRACK.

Impact: TheSCM coredumps because of the double free of Dialog Scope Variable Data.

Root Cause: Double free of Dialog scope variable data is happening when both the SipAdapter profile and Flexible Adapter profile is configured on the same TG.

Steps to Replicate: Please have a SMM Rule to store a dialog scope variable for all messages, with the flexible Adapter Profile with advanced SMM enabled and dialog scope variable rules for messages. Attach to the ingress TG both of them.

And run the 18x/Prack call flow. A coredump will occur.

Platform/Feature: SBC

Added a check for the flexible adapter profile not to use the dialog scope variable data.

Workaround: Do not enable the Advanced SMM on Flexible Adapter Profile.

Portfix SBX-95912: The postgres was logging additional housekeeping.

Impact: An unlimited amount of postgresql log files are being created, which may lead to a disk space issue.

Root Cause: Each postgresql log file is written with a timestamp.

Steps to Replicate: Ensure the postgresql logs are re-rotated properly.

Platform/Feature: SBC

Remove the timestamp from the postgres log file and let the logrotate utility to rotate files weekly or once the files reach a 10M size.

Workaround: Edit the postgresql.conf file to remove timestamp and size restriction. Add a size restriction to logrotate configuration file for postgresql.

Portfix SBX-96937: Running the sysDump.pl command on Openstack restarts the SBC.

Impact: Running the sysDump.pl command on 8.2.0R0 on the SBC Openstack cloud platforms causes the SBC application to restart.

Root Cause: The Openclovis is monitoring some files as markers, using the notify and taking it down when the file open operations are done.

Steps to Replicate: Once the SBC is up and running, run the sysDump.pl command and enter the default inputs.

The SBC application will not go down.

Platform/Feature: SBC: Platform

As part of sysdump, backing up the /opt/sonus/sbx/openclovis/var/run/notify directory is excluded.

Workaround: N/A

The PRACK rejected with a 405 error message.

Impact: When the E2Eprack is enabled and the ingress/egress 100relsupport is disabled, then the SBC was rejecting PRACK with a 405 bad request obtained from the ingress side.

Root Cause: "Enabling of PRACK support did not check on the EndToEnd Prack " was leading to the PRACK support to be disabled.

Steps to Replicate: To replicate the issue, make basic call configuration, and then disable 100relsupport on both ingress and egress side and enable endtoendprack. Run the scenario so the ingress invite has supported:100rel, and incoming 18x has required:100rel. As a result, the outgoing 18x will also have a required:100rel and PRACK will be end to end.

Platform/Feature: SBC

Add the EndToEnd PRACK to enable PRACK support.

Workaround: N/A

Portfix SBX-95741: The output of the CDR smmfield is null after the teardown, even though the SBC writes the values to the SMMField.

Impact: When the CDR update and SMMTeardown action are being configured as part of the same SMM Rule, the SMM CDR fields are not being populated.

Root Cause: Before the SMM CDR data is being copied from SG Active context to CCB structure, the SMM CDR data is being cleared.

Steps to Replicate: Create a rule to SMM CDR update and SMMTeardown action being part of the same SMM Rule. Run the call to trigger the SMMTeardown action.

Platform/Feature: SBC

When SMM Teardown action is being selected, if SMM CDR data is there in active context, copy the same to CCB structure.

Workaround:

Portfix SBX-96740: The "maxPduSizeValue: pdusize6kb" must be 6,000 bytes.

Impact: The MaxSipPDU size for "pdusize6kb" has to be 6,000 bytes.

Root Cause: TheMaxSipPDU size for "pdusize6kb" is currently considered as 5998 bytes. The PDU received in the SBC with 6000 bytes will fail.

Steps to Replicate: Send a SIP message of size 6000 bytes. The call will not fail.

Platform/Feature: SBC

The MaxSipPDU size for the "pdusize6kb" is updated to 6000 bytes.

Workaround:

Portfix SBX-96631: The dialog variable was not available after SMM Reject.

Impact: Run a Call where the Update is rejected with a 488 error message by the SMM, The Dialog Scope Variable is not available after that.

Root Cause: TheDialog Scope Variables are getting deleted after a Reject Operation.

Steps to Replicate: When the SBC rejects an early UPDATE with the SMM Reject, it clears the dialog variable info and cannot use the dialog variable after the SMM Reject. 

Platform/Feature: SBC

If there is an indialog message, do not delete the Dialog Scope variable for the Reject Operation.

Workaround:

Improper neutralization of input during a web page generation.

Impact: There was a improper neutralization of input during a web page generation. ('Cross-site Scripting')

Root Cause: There was a missing content-type header in the HTTP Response.

Steps to Replicate: Load the URL with the invalid operation name.

Platform/Feature: SBC

The code is modified to send an appropriate content type and character set information for the requested resource.

Workaround:

Improper input validation may expose the server.

Impact: Improper Input Validation: HTML forms with disabled validation can potentially expose the server to numerous types of attacks. Unchecked input is the root cause of vulnerabilities like cross-site scripting and SQL injection.

Root Cause: Novalidate was explicitly used in the login form.

Steps to Replicate:

1. Login to EMA
2. Go to Browser debug (F12) and to Sources: click on the main.bundle.js and verify if the novalidate is present.

Platform/Feature: SBC

For the Angular 2.x, it is required to manually add this novalidate attribute to ensure all validations are performed by Angular. With Angular 4+, the novalidate is automatically added behind the scenes.
Remove the novalidate attribute now, however Angular adds it internally.

Note: The login form is never used in app, so removed the login component.

Workaround:

Portfix SBX-95149: Direct dial to the call queue and then transfer agent becomes disconnected automatically after 20 sec as TEAMS releases the call.

Impact: A disconnection occurs because the SBC does not acknowledge a message on the egress side.

Root Cause: This is due to some states stuck in the SBC call control.

Steps to Replicate:

1. The PSTN dials the CallQ number. TEAMS1 is configured in call queue.
2. TEAMS1 transfers the call to TEAMS2.

Platform/Feature: SBC

The code is modified so the state transition occurs correctly in the SBC and the message is acknowledged.

Workaround:

Portfix SBX-94662: The SBC was unable to handle emergency calls (E911) when ICE is enable.

Impact: When the call limit for ordinary calls is already consumed on a trunk group, a new 911 emergency call on that trunk group does not complete using the emergency call bandwidth if ICE is also configured on the trunk group.

Root Cause: The issue in the software was not processing ICE data correctly when the call was transitioning from using ordinary bandwidth to using emergency bandwidth.

Steps to Replicate: With the SBC trunk group configured with ordinary call limit and additional emergency call limit and ICE enabled,

1. Establish as many calls as required, routed through the trunk group to consume the ordinary call limit on that trunk group.
2. While the previous calls are active, initiate a new 911 emergency call to be routed through the trunk group and verify if the call succeeds.

Platform/Feature: SBC: Media, SIP

The code is modified to process the ICE data correctly when call is transitioning to using emergency bandwidth.

Workaround:

ICE not getting completed when the simultaneous ringing enabled.

Impact: When simultaneous ringing is enabled to multiple MS teams endpoints, in certain cases where ICE stun request are received by SBC before an SDP is received in signaling messages, ICE is not getting completed for the endpoint that answers the call resulting in media to and from that endpoint not flowing via the SBC.

Root Cause: SBC answers first stun message with use candidate and completes ICE learning for that endpoint, subsequent stun messages from other endpoints with use candidate were answered but ignored for ICE learning.

Steps to Replicate: With simultaneous ringing enabled to two MS teams endpoints, initiate call through SBC to MS teams and verify that irrespective of which endpoint answers the call voice media can flow via the SBC. Test should be repeated around 10 times and call answered from different end point each time.

Platform/Feature: SBC

Software has been updated such that after receiving SDP with ICE ufrag in signaling message the SBC will only complete ICE learning against stun requests that have the same remote ufrag as that received in the SDP.

Workaround:

Portfix SBX-95711: SMM rule failed to be applied at the outgoing 200 OK on the ingress leg.

Impact: When 18x and 200 OK is received Simultaneously from egress, 200 OK will be queued on ingress side until 18x Prack Transaction is completed. So in this scenario 200 OK message Scope variable is being lost

Root Cause: Message Scope Variable Header is lost when 200 OK is queued on the ingress Side

Steps to Replicate: The ingress call leg supports 100rel while the egress call leg does not. The terminating party returned a 180 and then 200 OK after it received INVITE. After the ingress call leg completed the 100rel procedure (received PRACK and returned 200 OK for the PRACK), it failed to apply SMM rule to the outbound 200 OK for the INVITE.

Platform/Feature: SBC

Message Scope Variable Header is stored in the Prack Entry and retrieved when we de-queue again

Workaround:

Portfix SBX-96170: When SBC executes "Teardown" to UPDATE request by SMM, To header and From header of response are malformed.

Impact: Write an SMM Rule to do teardown on Update Request and Error Response has Malformed headers

Root Cause: When we save the server request of Update request we are not saving the optional headers

Steps to Replicate: Write a SMM rule to tear down update request with 415 and issue will be reproduced

Platform/Feature: SBC

The code is modified to save the headers when saving Update message as a server request

Workaround:

Portfix SBX-96723: Zone SMM Profile not working when we do sbxrestart/reboot.

Impact: Attach a Zone Profile with fixed order, and run a call, Zone SMM profile will be applied, do sbxrestart and run the call, Zone SMM is not getting applied

Root Cause: Zone SMM profile is not being restore during sbxrestart

Steps to Replicate: Attach a Zone Profile with fixed order, and run a call, Zone SMM profile will be applied, do sbxrestart and run the call, Zone SMM is not getting applied

Platform/Feature: SBC

The code is modified modified to restore Zone SMM Profile during sbxrestart.

Workaround:

Portfix SBX-91570: Call from MS Teams, and audio loss for 30 seconds and switchover.

Impact: MS Teams to PSTN call flow with DLRBT enabled on a software SBC. If there is an SBC switch-over after the call is established there can be a delay (e.g. 30 seconds) in re-established the media from PSTN to MS Teams direction.

Root Cause: The stored SSN value doesn't get updated before the SBC switch-over occurs, and it cause the SSN jump backwards after switch-over, which cause the one way audio issue for sometime until the SSN value increments past the previously sent value.

Steps to Replicate: MS Teams to PSTN call flow with DLRBT enabled on a software SBC. Perform a switch-over after the LRBT is played and check there is no one way audio issue.

Platform/Feature: SBC

After the LRBT is played the latest SSN value is sent to the standby SBC so it can correct jump the SSN forward on switch-over and media flow continues without delay post switch-over.

Workaround:

Portfix SBX-95993: Generating unexpected re-INVITE request on SBC.

Impact: Extra/Unexpected Re-Invite going out towards INGRESS

Root Cause:

Before Receiving PRACK on INGRESS side, 200OK INVITE received on Egress and processed. Because of it, queuing of SDP is happening.
Just after receiving ACK from Ingress, SIPS will check for any pending local SDP(queued) to send out. If SDP in 200OK sent and Queued are same, it will ignore it. When E2E Update enabled, because of internal logical issue; it is bypassing all other stuff and triggering queued SDP as offer Out.

Steps to Replicate:

Ingress PRACK supported and Egress Not
Enable E2E Update
Before receiving PRACK on Ingress, Trigger 200OK for INVITE on Egress.

Platform/Feature: SBC

Adding check for identifying UPDATE actually received from other leg or it is generated internal while UPDATE processing will solve this issue. As this will have control while sending queued SDP forcefully because of End-To-End Update flag because this has to happen only when UPDATE is received from other Leg and not for internally generated offer.

Workaround:

Portfix SBX-95673: SBC adding bandwidth parameter RR & RS while sending INVITE out.

Impact: SBC adds RR:0 & RS:0 parameters in SDP if there are more than 1 media line.

Root Cause: SIPSG was setting RR & RS to default values only for the first media line and for other media lines it was initialized to 0. Since 0 being a valid value, SIPSG sends RR & RS in the outgoing SDP.

Steps to Replicate: Test with multiple media lines in the SDP as mentioned in the JIRA, the issue will get reproduced.

Platform/Feature: SBC

The fix is set RR & RS to default values for all media lines. If RR & RS is set to default values SBC will not send the RR & RS parameters in the outgoing message.

Workaround: N/A

Portfix SBX-92386: SBC running 721R2 is responding with 'a=inactive' instead of 'a=sendrecv' in 200ok SDP to late media re-invite causing no audio.

Impact: It was not RFC compliant to send a=inactive to the late media re-INVITE after peer put SBC on hold.

Root Cause: Missed requirement.

Steps to Replicate:

Step 1: Generate sipp scripts for the above call flow
Step 2: Setup 7.2.1 system without fix.
Step 3: Run the call flow to see that the problem is observed.

To Verify:
Step 4: Change ScmProcess with release having the fix.
Step 5: Make call to observe that SBX is sending a=sendrecv in 200 OK.

Platform/Feature: SBC

The code is modified to send a=sendrecv to make it RFC compliant.

Workaround: N/A

Portfix SBX-94252: Memory usage exceeds 90%.

Impact:

CLI issue-
Create a new overload profile and attach it to levelMC2 and make the congestion levelMC2 inService. This will throw a CLI error Invalid values: overlapping ranges are not allowed. This is because the values for memory thresholds are zero in a default overload profile and this is lesser than the defaultMc1 profile thresholds which is against the congestion mechanism.
Alarm issue -
Machine congestion alarm was being raised by NRM for breaching memory thresholds. This should not be the case because memory is not part of congestion control.

Root Cause:

CLI issue -
Memory threshold validations are still in place and that should not be done since they are no part of the congestion profile anymore.
Alarm issue -
Memory not being part of adaptive congestion control this should have been removed from the parameters being checked to raise the machine congestion alarm

Steps to Replicate:

CLI tests:
Create a new overload profile and attach it to levelMC2 and make the congestion levelMC2 inService. This will throw a CLI error Invalid values: overlapping ranges are not allowed. This is because the user defined over load profile has memory parameters set zero while the other two default levels have some default values set which are greater than zero. With the fix this issue is not seen since validation in CPX for memory thresholds have been removed.
Alarm test - As we breach each congestion level memory congestion we see two alarms Node Machine Congestion(by NRM) and Resource congestion(by FM). Machine congestion alarm should not be raised because memory is not part of congestion control. As part of this code change the change in memory congestion levels has been ignored which will in turn fail to trigger this alarm. Only Resource congestion alarm will be triggered by FM.
- Behavior for defaultMC level settings
Resource congestion for memory is reported only when SBC crosses 90% of memory utilization.
124 01162020 041539.958425:1.01.00.00288.CRITICAL.FM: Resource mem congestion level 3 is approaching threshold 90 sample 89
102 01162020 041543.961601:1.01.00.00289.MAJOR .FM: Node Resource congestion, resource mem level 2.
157 01162020 041544.099152:1.01.00.00290.CRITICAL.FM: .FM .PsAmfHandler: reporting component error, reason: Memory Utilization 91% exceeded threshold of 90%
082 01162020 041548.808371:1.01.00.00291.MAJOR .NRS: Got AMF deactivate command

Platform/Feature: SBC

Validation in CPX for memory thresholds have been removed.
Alarm issue -
Memory congestion levels have been ignored which will in turn fail to trigger this alarm in NRM. Only Resource congestion alarm will be triggered by FM when the memory breaches 90%.

Workaround: N/A

Portfix SBX-94732: SBX must send FQDN in contact header for MS Teams.

Impact: MS Teams calls should have FQDN in Contact header but in messages sent in response to reINVITE, IP address is used, even when "Use Zone Level Domain Name In Contract" is set in IP Profile.

Root Cause: IP Profile "Use Zone Level Domain Name In Contract" not applied after reINVITE.

Steps to Replicate: Make a SIP - SIP call. Send reINVITE in an MS Teams zone for one of the call legs. The reINVITE succeeds but Contact header in response messages, e.g. 200OK, has IP address, rather than FQDN.

Platform/Feature: SBC

Changed processing so that for MS Teams calls, all responses to a reINVITE have FQDN in Contact.

Workaround: N/A

Portfix SBX-96265: Differential treatment depending on status code of re-INVITE response.

Impact: When 404 Response is received for Re-Invite SBC is Tearing down the call

Root Cause: When 404 Response is received for Re-invite, SBC is sending Internal Error Event rather than Ans-Rej

Steps to Replicate: Run a Re-Invite Scenario and send 404 Response for that

Platform/Feature: SBC

The code is modified to send Ans_Rej Event for Re-invite 404 Response.

Workaround: N/A

Portfix SBX-96391: Session refresh UPDATE should terminate with "E2E UPDATE" flag enabled.

Impact: Run a Call flow where Session Refresh Update is received from Ingress side, and E2E Update flag is enabled, This Update is locally answered and not being relayed

Root Cause: SIP_SERVICE_TYPE_RELAY_UPDATE_WO_SDP bit is not being set on ingress when E2E Update flag is enabled

Steps to Replicate: Run a Call flow where Session Refresh Update is received from Ingress side, and E2E Update flag is enabled.

Platform/Feature: SBC

The code is modified to set SIP_SERVICE_TYPE_RELAY_UPDATE_WO_SDP bit when E2E Update flag is enabled.

Workaround: N/A

Portfix SBX-93360: SBC sending INVITE with SRTP instead of RTP.

Impact: SBC is sending SRTP instead of RTP

Root Cause: The intersection of working psp and peer psp doesnt take place for Stream absent. Hence,SRTP values are never updated.

Steps to Replicate:

1. Create a UAC with RTP
2. Create two UAS with SRTP param
3. Send port =0 for hold response
4. Check if SBC is misbheaving while sending invite to release hold from far end

Platform/Feature: SBC

The updation for SRTP values for stream absent case has been taken care.

Workaround: N/A

Portfix SBX-96323: MIME-Version header is removed on SBC even though the transparency enabled.

Impact: Run a OOD message call flow with Mime Header and Transparency is enabled for Mime Header , Mime Header is not going in the egress message

Root Cause: MIME header is ignored by SIP Parser

Steps to Replicate: Run a OOD Message call-flow with Mime header

Platform/Feature: SBC

Made Parser changes to add MIME header as Transparent header.

Workaround: N/A

Portfix SBX-96896: Upgrading to 8.2 failed.

Impact: When Two Diff IpPeer with same name is configured one in CAPS and other in small letter SBC is coring

Root Cause:

When SBC tries to add second IPPeer entry ,It tries to bind the name for IP Peer,Since there is already another IPPeer with the same name
NamedInsert fails .After that SBC tries to delete the IP Peer entry from the hash.
While deleting IpPeer Entry
SBC tries to delete the response code stats hash table for the peer entry
SipSgDeleteIpPeerResponseHash(peerEntry);

In the routine
SipSgDeleteIpPeerResponseHash(SIPSG_IP_PEER_STR *peerEntry)

responseHashPtr = HashFirst(peerEntry->responseStatsHashTbl);

At this point peerEntry->responseStatsHashTbl is not created and is NULL so this result to coredump

Steps to Replicate: Configure Two Ippeer with the same nam .one in capital letetr and other in small letter

Platform/Feature: SBC

 So the solution is to add a NULL check for responseStatsHashTbl before deleting.

Workaround: N/A

TLS call failures were observed due to a port value set to 1 instead of 5061.

Impact: The SBC uses Port 1 for sending an INVITE out for the TLS protocol when the route header was received without a port.

Root Cause: The issue is because when the route header is received without a port in it, the SIPSG was incrementing the port for the TLS. Since the port was not received, the port received is considered as 0. For the TLS, increment by 1. When incremented, the port becomes 1 and this gets used for send an INVITE that is resulting in calls failing.

Steps to Replicate: Send the Route Header without port Route: <sip:ipaddr:;lr>. The SBC will use port 1 for sending an INVITE that is causing the issue.

Platform/Feature: SBC

The code is modified to check when the port is received in route header or not.
If port is received, then increment the port for the TLS. If it is not received, then increment and allow the SIP stack to handle it.

Workaround: N/A

Portfix SBX-94539: Calls disconnected with 132 after switchover.

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

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

Steps to Replicate: refer to /sonus/sw/Specs/TSBX-94539.txt

Platform/Feature: SBC: CDR, Redundancy

The code is modified skip the XRESs using altMediaIpAddress when LIF is created in standby XRM. And walk through the deferred activate list one more time when altMediaIpAddress is added in standby XRM.

Workaround: N/A

Portfix SBX-97388: After an upgrade to the V08.02.00F001 Inbound calls hold/off-hold and auto attendant call queue failure.

Impact: In certain circumstances, an A to B call gets referred by the B to C. Once the refer is completed, a re-invite from C can result in the SBC generating a re-Invite to A. This re-Invite for the particular scenario and configuration was not being generated in the pre 8.2 SBC releases.

Root Cause: A fix for another scenario where a re-Invite to A was necessary when switching a call out of playing ring back tones, in combination with an additional media stream having been added to the call had a knock on effect of generating the re-invite for other scenarios as well.

Steps to Replicate: Created a required SBC configuration and run following signaling sequence:

1. Setup call from A to B.
2. B refers call to C and all signaling to C completes.
3. C sends re-INVITE to SBC.

Verify that after a fix, the SBC is not sending a re-Invite to A as a result of step 3.

Platform/Feature: SBC

The code is modified to check that number of media streams is changing before instigating checks on the session parameters to decide if a re-Invite is generated.

Workaround: N/A

The Max Forward Header Support feature is not working for requests from the terminating side.

Impact: The Max Forward Header Support feature is not working for requests from the terminating side. The SBC does not subtract 1 in the Max-Forwards header despite if the rfc7332ValidateMaxForwards is set to enabled.

Root Cause: This issue is caused when a BYE request comes from the terminating side. Any other requests from the originating side are decreased correctly including a BYE request. Handling a Bye from the terminating was not taken care of.

Steps to Replicate:  Enable fc7332ValidateMaxForwards on both TG.

1. Initiate a call from A to B. The B sends a 200ok to connect the call.
2. The B send the Bye request. The SBC sends the Bye request to A. Max forward header in the Bye is set to 70.
3. Check the Max forward, the SBC sends to A. Max forward header must be decremented by one.

Platform/Feature: SBC

When the rfc7332ValidateMaxForwards is enabled and when the Bye is received from the terminating side, decrease the max forward header by one.

Workaround: N/A

The SCM coredumps after a PRACK.

Impact: The SCM coredumps because of a double free of Dialog Scope Variable Data.

Root Cause: There was a double free of Dialog scope variable data is occurring when both the SipAdapter profile and Flexible Adapter profile is configured on the same TG.

Steps to Replicate: Please have an SMM Rule to store a dialog scope variable for all messages, the flexible Adapter Profile with advanced SMM was enabled and for the dialog scope variable rules for messages. Attach to the ingress TG both of them and run 18x/Prack call flow. A core will occur as a result. 

Platform/Feature: SBC

The code is modified to not access the dialog scope variable data.

Workaround: Do not enable the Advanced SMM on Flexible Adapter Profile.

There is a "Media Type" length restriction for the SBX-73083.

Impact: Before the fix, the fmt parameter was restricted to only 8 Characters. The customer requested the support for fmt parameters to be up to 255 characters.

Root Cause: This is a new requirement from customers to support the 255 characters for fmt parameter in the media line.

Steps to Replicate: Test by sending a "m=application 16980 TCP xyz121y432i23i4" to the SBC. The SBC will send the fmt parameter "xyz121y432i23i4" as it is to egress leg.

Platform/Feature: SBC

The code is modified to support 255 characters for fmt line.

Workaround: If the fmt parameter is less than 8 characters, there will not be any issue.

The E2E Prack and the 100rel interworking. The PRACK rejected with 405.

Impact: When the E2Eprack is enabled and ingress/egress 100relsupport is disabled, then the SBC was rejecting the PRACK with 405 bad request obtained from the ingress side.

Root Cause: "Enabling of PRACK support did not check on the EndToEnd Prack " was leading to the PRACK support to be disabled.

Steps to Replicate: To replicate the issue:

1. Make basic call configuration, and then disable 100relsupport on both ingress and egress side.
2. Enable the endtoendprack.
3. Run the scenario where the ingress invite has supported:100rel.
4. The incoming 18x has required:100rel.
5. As a result, the outgoing 18x must also have required:100rel and prack should be end to end.

Platform/Feature: SBC

Check that the EndToEnd Prack added to enable PRACK support.

Workaround: N/A

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

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: TheSBC is replying to request with 500 error response code to the client with error string as "Internal Server Error".

Root Cause: TheSBC 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: TheSBC 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: TheSBC 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: Theissue 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: TheSBC must not depend on the processSgCOnfigureWhenTGOOS setting.

Root Cause: TheSBC 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: TheIPv6 address becomes unreachable in a standby port cable pull scenarios.

Root Cause: TheSWe 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: TheSWe_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: TheMSRP 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: TheSBC 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: TheP-Charge-Info Header is not relayed transparently for OOD Message, even when the transparency profile is enabled for P-Charge-Info.

Root Cause: TheP-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: TheDM 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: TheSAM 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: TheSBC 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.65.1.210. 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: