SBC Core 09.02.05R002 Release Notes

Verify system and databases are fully in sync prior to Live Software Upgrade (LSWU). Applies to all SBC platforms (HW, SWe, Cloud) except the SBCs deployed in a Distributed SBC (D-SBC) architecture.

The SBC application is not coming up

Impact: Synchronization of the SIP REC call data may fail due to deficiencies in the synchronization algorithm.

Root Cause: The algorithm used to the synchronize of SIP REC call data to the standby system suffered from deficiencies, making the algorithm unreliable.

Steps to Replicate:

1. Provision the SBC to perform a SIP REC.
2. Run SIP REC calls.
3. Bring up the SBC's Standby system and/or perform an LSWU upgrade.

The code is modified to correct the algorithm's reliability issues.

Workaround: Disable (inhibit) SIP REC calls before bringing up the Standby system or performing LSWU upgrade.

The SBC 5400 failover occurred on server

Impact: The SCM cores due to memory corruption.

Root Cause: The memory corruption is caused by a bug where the length field of a structure wrapped around the size of the USHORT that it is stored in is causing an incorrect length value.

We use this length to calculate the address where we’re going to copy data into. Therefore, when the length is incorrect the incorrect location data is copied, causing memory corruption.

Steps to Replicate: The steps are not reproducible. 

The code is modified to prevent the length field from wrapping when it becomes very large.

Workaround: None.

SWE Traffic Profile sync problem in HA

Impact: The traffic profile fails to get applied on 1-to-1 SBC 9.2.3R0 Openstack VM registered with V13.02.06R000 EMS when the SBC VM is spawned with the large memory config Profile.

Root Cause: 1-to-1 mode SBC registered with EMS fails to apply the large config profile as part of init operations on an active SBC. This results in the creation of a marker file (skipRebootMarker). The presence of this marker file causes the application to reject the traffic profile activation from CLI/EMS on an active SBC.

Steps to Replicate:

1. Launch 1:1 Openstack SBC with V09.02.03-R0 Build, registered with EMS V13.02.06R000.
2. Log into Active SBC and change sweConfiguration profile to large (both SBCs go for a reboot).
3. Run saveAndactivate from the SBC CLI -- EMS gets synced with the SBC's configuration.
4. Log into Openstack console, and rebuild both Active and Standby SBC instances with same V09.02.03-R0 build image.
5. Log in to the active SBC and check sweConfiguration profile – the profile will be shown as small, rather than large.
6. Try activating the standard_passthrough Profile – none of the SBCs go for reboot for activation of traffic profile.
7. Reboot both active and standby SBC instances manually - only the old active will come up with the activated traffic profile from the previous step.

The code is modified to update the logic for introducing the marker file. The marker file was introduced incorrectly as part of the large config profile activation.

Workaround:

1. Log in to SBCs as root user and remove the marker file from both active and standby instances:
   rm -f /opt/sonus/conf/swe/capacityEstimates/.skipRebootMarker
2. Re-activate the large sweConfigProfile from the active SBCs CLI console by running the following command:
   set system sweConfigProfileSelection name large

Incoming SIP SUBSCRIBE requests from registered endpoints were incorrectly rejected with a SIP 403 Forbidden response 

Impact: The SBC incorrectly rejects incoming SIP SUBSCRIBE requests from registered endpoints with a SIP 403 Forbidden response.

Root Cause: The logic that was added for SBX-119915 to check an endpoint's registration status while processing the incoming SIP SUBSCRIBE request should only apply when the usePortRangeFlag feature is enabled.

Steps to Replicate:

1. Establish a new SIP registration, followed by a new SIP subscription for an event of your choice.
2. Verify that the SBC relays the SIP SUBSCRIBE to the registrar and that the SBC doesn't reject the SIP SUBSCRIBE with a SIP 403 Forbidden response.

Reverted the SBX-119915 code change.

Workaround: None.

Ingress T.38 Fax fails when the Egress is SIP or TDM (SBX-12043) / T.4 data size exceeds expected size based on fax speed (SBX-106015)

Impact:

• SBX-106015 (Sev. 2): The UDP packets for the 14.4 rate are 84 bytes instead of 72 bytes corresponding to a 40 ms payload. This is not a bug, but is considered an unnecessary change that was introduced as a part of T.38 3.35 (This is getting rolled back to the original 72-byte packet size).
• SBX-120493 (Sev. 3): Certain T.38 endpoints send TCF much earlier relative to DCS packets (e.g. fax server, as indicated by 'SIP User-Agent: VFAXSUA/IPFAX-9.0.7806.611'). The current stack handles it by dropping TCF while its still modulating the DCS signal. This results in a shorter modulated TCF, which causes the receiving fax machines to indicate a failure via an FTT message.

Root Cause:

• SBX-106015: The T.38 stack upgrade to 3.35 induced an unnecessary change. While this is not a bug, the best approach is to avoid unnecessary changes.
• SBX-120493: Incorrect DCS message lengths and TCF message timings (TCF messages arrive while the stack is still modulating DCS) are sent from some T.38 endpoints.

Steps to Replicate:

SBX-106015:

1. Establish a. 14.4 rate T.38-G711 fax call so that the SBC stack G.711 leg is Ingress.
   The SBC stack then generates TCF UDPTL packets.
2. Using wireshark, inspect the media packets payload size.
   1. Without the fix, the payload size for media packets is 82 bytes.
   2. With the fix, the payload size is 72 bytes.

SBX-120493:

• If a failure occurs with VFAXSUA/IPFAX type device, and the TCF packets arrive before modulating an earlier DCS, than the generated TCF tends to be shorter than the standard 1.5 seconds.
• With this fix, the TCF duration matches the actual received TCF duration payload.

To overcome when T.38 peers send TCFs earlier than expected, the stack code is modified to delay TCF generation until the DCS is modulated.

Additionally, the T.38 stack code changes are rolled back to produce 72-byte packets for 14.4. TCF.

Workaround:

• SBX-106015: N/A
• SBX-120493: No workaround

PortFix SBX-112437: The SCM Process and SAM Process core observed for Enhanced Local Redirection

Impact: SCM cores when processing a SIP message that contained 10 Contact Headers and Multiple Identity headers.

Root Cause: The length of the data became too large to be stored in a length field that is a USHORT. The contents of the length field wrapped around the size of the USHORT that it is stored in, causing an incorrect length value.

This length is used to calculate the address where it is going to copy data into. Therefore, when the length is incorrect it copies into an incorrect location causing memory corruption.

Steps to Replicate: Run a test where a SIP message that contained 10 Contact Headers and Multiple Identity headers is sent to the SBC. This message is processed correctly and there was no core.

The code is modified to add defensive code to prevent the length field from wrapping when it becomes very large.

Workaround: None.

PortFix SBX-114422: SBC 7000 Trunk Group Stats contain Parent CAC trunk group (a.k.a Shared CAC-Limits Pool) stats with strings "key not found in" instead of Zone name and AC name

Impact: SBC 7000 Trunk Group Stats contain Parent CAC trunk group (Shared CAC-Limits Pool) stats with strings "key not found in" instead of Zone name and AC name

Root Cause: The Trunk Group Stats considers sharedCacLimitsPool as a TG and since sharedCacLimitsPool is not linked to address context or zone, those fields are populated with 000, and later while trying to fetch value for the TrunkGroupStatusStats file it is updated as "key not found in."

Steps to Replicate:

1. Set up basic SIP-SIP call.
2. Configure sharedCacLimitsPool.
3. Attach the sharedCacLimitsPool to an Ingress Trunk Group.
   TrunkGroupStatusStats does not contain an Entry for sharedCacLimitsPool.

The code is modified to skip the TrunkGroupStatusStats entry for sharedCacLimitsPool.

Workaround: None.

Back-to-back cores occurring on the SBC

Impact: The SBC experiences back-to-back cores while applying disconnect treatment to calls.

Root Cause: The disconnect treatment action is invoked twice for the same call while a new control block is created. This second control block includes updated pointers to for the disconnect treatment resources. The pointers in the first block are now invalid. Consequently, a core results if the first block is used.

Steps to Replicate:

Configure calls behind NAT with a disconnect treatment applied.

(You may need to run a simulated load to reproduce the issue)

Expected result:

A call fails due to the busy trigger invoking the disconnect treatment.

A core may not occur because the failure condition is timing-related.

The code is modified to avoid allocating a second control block and will now log a message.

Workaround: Remove the Disconnect Treatment Profile.

SBC3 SBC 7000 switchover and ScmP process crashes

Impact: ScmProcess cores after receiving a re-Invite without SDP.

Root Cause: The SIP code is attempting to reference a NULL pointer because the initial Invite does not include SDP details. Since the SBC does not have anything in the sessPtr of the pActiveSgPspStr, updates to these elements results in reading a null pointer.

Steps to Replicate: This issue was found by code inspection.

The code is modified to prevent referencing a NULL pointer.

Workaround: None.

SIP to SIP call - no response sent for PRACK

Impact: While the call is playing disconnect treatment, the SBC receives an SDP offer in the PRACK, but was not able to respond.

Root Cause: The application is already in a disconnecting state and is not able to accept a new SDP offer.

Steps to Replicate:

1. Configure call disconnected treatment
2. A (prack support) call B, B answer 486.
3. The SBC sends 18x with sdp to A for disconnected treatment.
4. A send new offer in PRACK.

The code is modified so that SIPS answers the 200OK for PRACK using the same SDP send out(18x) for disconnect treatment.

Workaround: Disaple PRACK on ingress or disconnected treatment.

Transcoding of DTMF stopped working after upgrade to 9.2.5R0

Impact: Transcoding of DTMF stopped working after upgrade to 9.2.5R0

Root Cause: A code change was made involving the NP to do a payload type substitution because the PT2833 field is set to the received value, and is told to substitute it with a new value. Since the DSP expects the original value, it drops the new value.

Steps to Replicate:

1. Make a transcoded call with a different DTMF PT on the ingress and egress legs.
2. Send DTMF digit events in each direction and verify the DTMF PTs are correctly modified.
3. Make a pass-through call with different DTMF PTs on the ingress and egress legs
4. Send DTMF digit events in each direction and verify the DTMF PTs are correctly modified.

The code is modified to add a check for transcoded calls when setting dtmfPTSubEnable flag. So that dtmfPTSubEnable = FALSE will be sent to XRM when activating XRES.. NP is not supposed to do PT sub for transcoded calls because the DSP will effectively do it.

This is the fix for WBA Number = Warning-22-00036730

Workaround: None.

The Service Instance X2 message does not specify which party put a call on hold in a multi-party call

Impact: If an intercepted (legacy LI) call is put on hold, the Service instance message is sent to the mediation server. But the call hold direction is not specified in Service instance message.

Root Cause: Currently, the SBC sends a service instance message for CALL_HOLD if any leg is intercepted. Also as per packet cable specification, there is no call direction parameter in the Service instance message.

Steps to Replicate: Provision the SBC for LI on the ingress leg where a calling party number is the target.

Test-1:

1. Make an A-to-B call.
   Since A is the target, signaling Interception starts.
2. Send a re-invite from B (egress) side for a call hold.
   The SBC sends a service instance message with service name "Call_Hold" and called party number.
3. Send a re-invite from B (egress) side for call retrieve.
   The SBC sends a service instance message with service name "Call_Retrieve" and called party number.

Test-2:

1. Make an A-to-B call.
   Since A is the target, signaling Interception starts.
2. Send a re-invite from A (ingress) side for call hold.
   The SBC sends a service instance message with only service name "Call_Hold".
3. Send a re-invite from B(ingress) side for call retrieve.
   The SBC sends a service instance message with only service name "Call_Retrieve".

The code is modified such that currently only the "Service name" parameter is populated by the In Service instance message for call hold/retrieve. After the fix, if the call hold/retrieve is received from egress side, the "called party number" parameter is also added to the Service instance message. If the Call hold/retrieve is received from ingress side, the called party number is not added to the Service instance message.

Workaround: None.

Portfix SBX-120979: Standby SLB not coming up after upgrading the SBC due to API changes in Azure cloud.

Impact: The SBC application fails to come up after running an upgrade.

Root Cause: The generated cloudinit configuration is incorrect for the swapped disk due to cloudinit script API changes.

Steps to Replicate: Perform an upgrade on the SBC using the IaC package.

The code is modified to remove the incorrectly generated cloudinit config and link to the correct config.

Workaround: None.

PortFix SBX-114422: The SBC 7000 Trunk Group Stats contain the Parent CAC trunk group (a.k.a Shared CAC-Limits Pool) stats with strings "key not found in" instead of Zone name and AC name.

Impact: The SBC 7000 Trunk Group Stats contain the Parent CAC trunk group (a.k.a Shared CAC-Limits Pool) stats with strings "key not found in" instead of Zone name and AC name.

Root Cause: The Trunk Group Stats considers sharedCacLimitsPool as a TG and since sharedCacLimitsPool is not linked to address context or zone, those fields are populated with 000. While trying to fetch value for the TrunkGroupStatusStats file, the TG is updated as "key not found in".

Steps to Replicate: 

1. Set up a basic SIP-SIP call.
2. Configure sharedCacLimitsPool.
3. Attach the sharedCacLimitsPool to Ingress Trunk Group.

TrunkGroupStatusStats does not contain an Entry for sharedCacLimitsPool.

The code is modified to skip the TrunkGroupStatusStats entry for sharedCacLimitsPool. 

Workaround: None.

200OK for re-INVITE contains telephone-event although the previous offer/answer does not have it

Impact: The SBC sends telephone-event in 200OK for re-INVITE/UPDATE though previous offer/answer does not have it.

Root Cause: This issue is observed mainly when auto answering happens on the opposite call leg. While auto answering, the SBC is not checking whether the modify offer contains DTMF set or not. Due to this, if the Peer contains DTMF already, then SBC is sending response with DTMF set.

Steps to Replicate: None.

The code is modified to alter the auto answering logic, such that the SBC explicitly checks whether offer contains any DTMF or not and responds accordingly.

Workaround: None.

Portfix SBX-120560: RunTime errors and leaks observed during SBX_4948 suite execution.

Impact: RunTime errors and leaks observed during running calls with PAreaInfo header.

Root Cause: Missing null checks in the clone function for PAreaInfo header.

Steps to Replicate: Run Invite callflow containing PAreaInfo header in ASAN build.

The code is modified to add null checks in the clone function for PAreaInfo header.

Workaround: None.

AWS SBC application went down

Impact: The SBC applicaton hit a deadlock due to the SbcSftp executable crashing while it still had access to a lock for updating the ACL table.

Root Cause: This appears to be due to the command being called from a cronjob and used in conjunction with expect script to provide password. The SbcSftp command was terminated while it still had access to the SBC lock to update the ACL table and the SBC timed out while waiting for the lock to become available.

Steps to Replicate: The problem could not be reproduced.

The code is modified to allow the SbcSftp utility to be extended with a new option to supply the key file with -I option. The new usage will look like below:

Usage: SbcSftp <<IP>> <<port>> <<username>> <<upload/download>> <<local SBC path>> <<remote Server path>> [<<-I certificate file with path>>]

The certificate option is in the end just to keep the same order for existing options.

This should avoid the need to expect script to provide password input. It is also recommended to run the SbcSftp command via "nohup" to make it completes even if the linux ssh session terminates e.g.:

nohup SbcSftp

Workaround: Use "nohup" command in conjunction with SbcSftp so it completes successfully and releases resources. Avoid running the command from a cronjob.

PortFix SBX-120895: Clicking Noise on calls transcoded between PCMU+CN to AMR-WB

Impact: Clicking sound observed on AMRWB leg in G711U to AMRWB call.

Root Cause: Some packets in the G711U stream contained a G711 payload which was not in multiple of 10ms or 80 bytes. The Playout Buffer at DSP does not handle G711 payload which are not in multiples of 10ms.

Steps to Replicate:

1. Make a G711 to GPU AMRWB call.
2. Configure G711 MULAW with Silence Suppression enabled (CN with PT 13) in SDP.
3. Stream the attached PKT file (MULAW_p20_SBX102895.pkt) on G711 leg. This file corresponds to field capture srcPort45200.pcap which is attached in the JIRA.
4. Capture the output on AMRWB leg.

The code is modified so that the G711 payload is made to be a multiple of 10ms by appending silence to the payload while copying it into Playout Buffer if the G711 payload is not in multiples of 10ms.

Workaround: None.

SBC fails to reset ROC to 0 on the DTLS/SRTP call leg upon INVITE w/ Replaces on the RTP leg when the RTP peer started using a new SSRC

Impact: The SBC fails to reset ROC to 0 on the DTLS/SRTP call leg upon INVITE w/ Replaces on the RTP leg when the RTP peer started using a new SSRC

Root Cause: The call modification caused by the re-INVITE causes the NP media RID resource to be disabled and a new RID enabled for the same call leg.

The logic in the NP is such that if LAST_SSRC is 0, it does learning and latches the SSRC of the first packet and does not reset the ROC.

If the ssrcRandomizeForSrtp flag were enabled, XRM would apply a new randomly-generated initial LAST_SSRC value to the NP RID and instruct NP to reset SSN and ROC when enabling the new RID.
But as per initial impementation, ssrcRandomizeForSrtp does not apply to DTLS/SRTP.

Steps to Replicate:

1. Enable ssrcRandomizeForSrtp in packet service profile.
2. Make a long duration RTP(AS side) to DTLS/SRTP passthrough call.
3. After 27 mins, trigger AS switchover to sent an INVITE w/ Replaces to the SBC.
4. Check for one way audio.

The code is modified to add dtlsSrtpAdminState in NRMA while enabling ssrcRandomizeForSrtp for non dtlsSrtpRelay/dtlsSctpRelay cases. As well, in XRM, check is added for SSRC change when encId has changed.

Workaround: None.

Portfix SBX-119468:2833 DTMF PT is default instead of negotiated on call leg

Impact: During mid-call modification, the SBC uses the configured 2833 PT rather than the previously negotiated DTMF PT if either of the endpoints chooses to remove DTMF PT in subsequent mid-call modifications.

Root Cause: If either of the endpoints removes the DTMF during mid-call modifications, the SBC is picking the configured 2833 PT while generating offer towards the other endpoint rather than the previously negotiated PT.

Steps to Replicate: 

1. Enable "Difference in DTMF" flag under p2p control.
2. Setup a pass-through call with DTMF PT=110.
3. Send a late media re-invite from UAS.
4. The SBC sends offer to UAS with 2833 PT.
5. UAS sends answer SDP in ACK but without 2833 PT.
6. The SBC generates offer towards UAC with configured DTMF PT (instead of 110). However, after this fix, SBC continues to uses the negotiated PT (110) on ingress leg.

The code is modified to use the already negotiated DTMF PT during mid-call modifications.

Workaround: None.

PortFix SBX-118073: SBC did not use the protected port in some of the headers

Impact: When IPSEC connection is created the port allocated for the connection is known as protected port, this is different to the standard 5060/5061 port used for signaling. The SBC was not sending the protected port information correctly in all the via/record-route headers.

• When the SBC sends INVITE/UPDATE to UE, the port in Via and Record-Route headers are protected port.
• When the SBC sends NOTIFY to UE, the port in via is protected port, but port in record-route is 5060.
• When the SBC sends 180/183/200 to UE, the port in via is protected port, but port in record-route is 5060.
• When the SBC sends BYE to UE, the port in via is 5060, the SBC was not.
  
  

Per test result and observation:

• When the SBC sends INVITE/UPDATE to UE, the port in Via and Record-Route headers are protected port.
• When the SBC sends NOTIFY to UE, the port in via is protected port, but port in record-route is 5060.
• When the SBC sends 180/183/200 to UE, the port in via is protected port, but port in record-route is 5060.
• When the SBC sends BYE to UE, the port in via is 5060.
  
  

Currently, SMM is used to store the port-s in variable, then:

• If via port is 5060 for request sending by SBC to UE, then uses SMM to change the port in via to protected port.
• If record-route is 5060 in 18x~200 for response sending from SBC to UE, then use SMM to replace it with protected port.

Root Cause: The SBC was using the wrong port information due to an interaction with contact header transparency logic.

Steps to Replicate:

1. Setup IPSEC config on ingress interface(LIG1).
2. Enable passCompleteContactHeader transparency flag.
3. Setup basic SIP-SIP call.
   
   Check that the IPSEC port is used correctly in via and record-route headers.

The code is modified to remove the logic related to contact header transparency while selecting the correct protected port information to include the SIP headers.

Workaround: Disable "passCompleteContactHeader" flag under IPSP.

Portfix SBX-120971: Standby services not starting after upgrade with FIPS enabled.

Impact: Services not starting up after upgrade due to CRITICAL FIPS-140-3 error.

Root Cause: Integrity check was failing due to missing /home/oracle/product/oracleDB.sha256sums.

Steps to Replicate: 

1. Enable FIPS mode.
2. Perform upgrade.
3. Verify if services are up.
4. Verify if FIPS mode is enabled.

The code is modified so /home/oracle/product/oracleDB.sha256sums is now present in /home/oracle/oracleDB.sha256sums. Updated file paths in checkFipsSoftwareIntegrity.sh to check in correct locations.

Workaround: None.

Unexpected switchover on the SBC SWe pair.

Impact: The SCM process coredumps after processing a Dialog Event.

Root Cause: The cause of the coredump is the code accessing a structure where elements are freed.

As a result, the code de-references pointers in this structure that is set to NULL.

Steps to Replicate: This issue is not reproducible.

The code is modified to free the Dialog structure only after freeing the elements it points to. This fix prevents dereferencing pointers in this structure that are set to NULL. Multiple stack traces show the same routine in the code as being deficient - this is where additional checking logic is added. 

Workaround: There is no workaround.

SBC Switchover processAbnormalTermination with core

Impact: Subscribe relay with multiple crank back failures may cause the SBC to core.

Root Cause: When retransition eventually times out and multiple application crank back failures take place for Subscribe Relay, there may be a core observed due to a stack recursion. This results in a duplicate free of the relay control block.

Steps to Replicate: Not able to reproduce due to specific customer configuration.

The code is modified to process the freeing of the relay control block in a separate thread.

Workaround: Avoid crank back.

SBX-118299

Load Testing - Packet Loss

Impact: SWe_NP was not able to handle traffic burst, and observed packet loss.

Root Cause: Due to high wakeup latencies in SWe_NP caused by scheduling and CPU idle time management, the packets accumulated in the hardware queue are not drained by SWe_NP in time.
The hardware queue is quickly filled up when there is traffic burst, and due the latencies caused by scheduling, SWe_NP could not read the packets in time, and the previous packets were overwritten in the hardware queue.

Steps to Replicate: The reproduction of this test requires simulating the traffic burst.
One way is to use multiple call generators.

The code is modified to change the scheduling policy of SWe_NP to Realtime (SCHED_FIFO) and change the idle behavior of the CPU to poll, instead of halt.

Workaround: Reduce the number of calls and number of call generators.

Running a sysdump on a SBC 5400 triggers packet port down/up condition

Impact: Port link failure observed while running sysdump on the SBC 5400. This could cause an SBC switchover.

Root Cause: Enhancements made to collect more Network Processor (NP) memory area caused interference for the interface driver reading the port link status. This interference caused the driver to falsely report link down. The link status is obtained from the NP processor's (Octeon) register.

Steps to Replicate: Run np_mem_dump.pl while the SBC application is running while the mgt/pkt interfaces are in a link up state.

Sample command line to run 100x:
[root@yf04a np]# x=1; while [ $x -le 100 ]; do echo $x; date; ./np_mem_dump.pl/var/log/sonus/np/npMem0_d$x.log >& npdump.log ; date; $(( x++ )); done

Note: This command creates npMem0_d[1..100].log files and could fill up the disk.

The code is modified to allow the utility function to collect NP memory and NP registers in order to access the Octeon register through the driver instead of directly accessing the register. This avoids concurrent access of the register which caused the false link failure.

Workaround: Do not run sysdump or /opt/sonus/bin/np/np_mem_dump.pl while the SBC is running.

You can obtain an updated /opt/sonus/bin/np/oct-remote-memory and /opt/sonus/bin/np/oct-remote-csr binary to avoid the link bounce while running sysdump.

The SBC performed switchover with processAbnormalTermination error code

Impact: The SCM process cored due to a Healthcheck timeout.

Root Cause: An infinite loop is encountered when mirroring Subscription CBs.

Steps to Replicate: The steps are not reproducible.

The code is modified to prevent the SBC from spinning in this particular loop.

Workaround: None.

After a 491 response due to re-INVITE contention, the SBC continues the call even though the SDP is unmatched.

Impact: After 491 response, the SBC sends re-INVITEs with invalid application media format.

Root Cause: When the application processes the queued request internally, it loses the other leg application media format that it used for the remote to send out.

Steps to Replicate:

1. Enable e2e re-INVITE.
2. Run multimedia SDP applications.
   After the call connects with both media, both ends try to re-INVITE with one media active that will trigger the SBC to send 491 and re-INVITE.

The code is modified to properly store the other leg application media format in SIPS, so that it can send out correctly when it processes the queued message.

Workaround: None.

The SCM Process cores and causes a switchover.

Impact: The SCM Process cores when attempting to allocate memory.

Root Cause: The SCM Process cores when attempting to allocate memory because the memory management code has detected memory corruption.
The memory corruption occurred because the code was written into a memory block after it had been freed. This appears to have occurred when the SRS gets blacklisted during setup and the call needs to route advance to the next SRS.

Steps to Replicate: The steps are not reproducible.

The code is modified to prevent writing into this memory block after it is freed.

Workaround: None.

The SBC Core has a switchover twice during the day.

Impact: SCM cores in SIP code when using SIP Refer Relay.

Root Cause: The core is due to an attempt to dereference a NULL pointer while processing a message related to SIP Refer Relay.

Steps to Replicate: The root cause was found by code inspection.
The exact call flow that will causes the pointer to be NULL when entering the affected code is unknown.
(With this fix, the code will not core in the future if the pointer is NULL.)

The code is modified to make sure the pointer is valid before attempting to dereference it.

Workaround: Disable the SIP Refer Relay.

SIPSG code cores due to accessing pktCcb pointer that has been set to NULL

Impact: SIPSG code cores due to accessing the pktCcb pointer that has been set to NULL.
This issue can show up with a number of different stack traces (depending on the call flow).

Root Cause: The fix in the past included a change that sets fsmCcb->pktCcb to NULL after clearing out the contents of the pktCcb.

The reason for setting fsmCcb->pktCcb to NULL after clearing out the contents of the pktCcb was to prevent executing the code in SgOaClearPktCcb() more than once.

The previous fix was unnecessary because SgOaClearPktCcb() already checks every field for NULL before attempting to free it.

This change causes new cores because there is code that is accessing pktCcb pointer after it was set to NULL (in the past it was safe to assume that pktCcb pointer would not be NULL).

This bug was introduced in the 9.2.4R3 release.

Steps to Replicate: The steps are not reproducible

The code is modified to remove the change that sets fsmCcb->pktCcb to NULL.

Workaround: None.

Congestion Memory issue.

Impact: The SCM process leaks memory when "sendSBCSupportedCodecsForLateMediaReInvite" is enabled in the IP Signaling Profile.

Root Cause: The SCM process may not free internally allocated structure when "sendSBCSupportedCodecsForLateMediaReInvite" is enabled in IP Signaling Profile.

Steps to Replicate: Run load with “sendSBCSupportedCodecsForLateMediaReInvite” enabled in the IP Signaling Profile and confirm the leak.

NOTE: The call flow must result with sending a "NRMA Modify" internally.

The code is modified to ensure that these structures are freed when "sendSBCSupportedCodecsForLateMediaReInvite" is enabled in IP Signaling Profile.

Workaround: Disabling "sendSBCSupportedCodecsForLateMediaReInvite" may prevent this issue.

However, there may be other code paths or scenarios which may trigger this leak.

A switchover occurs on the SBC due to a deadlock issue.

Impact: A switchover occurs on the SBC due to a deadlock issue.
The CPX process deadlocks while calling CpxTrunkGroupMediaIpSecondaryInterfaceGroupNameValidate to validate the SecondaryInterfaceGroupName while the customer was making lots of calls to get the authPassword, for example:

show table addressContext <context> zone <zone> sipTrunkGroup <trunkgroup> signaling authentication authPassword

Root Cause: When the the authPassword is being fetched multiple times a second, that call was occuring at the exact same time as the CpxTrunkGroupMediaIpSecondaryInterfaceGroupNameValidate was called. Both routines use the same global maapiSocket to do maapi calls to read the confd database. Since the same global socket was being used, the maapi_exists call is hung.

Steps to Replicate: In one CLI session, make a lot of calls to get the authPassword:
show table addressContext <context> zone <zone> sipTrunkGroup <trunkgroup> signaling authentication authPassword

In another CLI session, do a:
set addressContext <context> zone <zone> sipTrunkGroup <trunk group> media mediaIpSecondaryInterfaceGroupName <groupname>

Observe that the CPX does not crash.

The code is modified so that the CpxTrunkGroupPassGetElem function performs a 'cdb get' action to get the authPassword, so there is no contention for the global maapiSocket.

Workaround: Do not get the authPassword at the same time as setting the mediaIpSecondaryInterfaceGroupName.

After an SBC 9.2.3 SW upgrade, the ACLs are blocking traffic when enabled.

Impact: The IPACL rule is incorrectly installed in the NP.

Root Cause: You can configure the IPACL rules with or without an ipInterface. If an IPACL rule is configured with an ipInterface, it is not installed in the NP until the associated ipInterface is created and enabled in the NP. The IPACL task tries to re-add those rules that are waiting on the ipInterface for it to receive a 'port up' notification from the NRS.

When mixing a set of IPACL rules, some rules that are not defined with the ipInterface are installed in the NP during the startup of the applications, while other rules that are defined with the ipInterface may get delayed while waiting for the associated ipInterfaces to become ready. All of the IPACL rules are ordered by precedence in the CPS context and will be programed in the NP in the same order.

When the IPACL task tries to re-add the rules that are waiting on ipInterface, the order of the rules is changed. The new rules are inserted at the proper location in the CPS context, based on their precedence. But there is no corresponding shuffling at the NP layer which causes some newly-added rules to randomly overwrite some existing rules.

Steps to Replicate:

1. Configure the following three IPACL rules:
   rule 1: Define the LIF and the ipInterfaceGroup that contains this LIF, and assign the smallest precedence value among three rules.
   rule 2: Use the same ipInterfaceGroup as rule1, protocol = ICMP, assign precedence value > rule1, do not define as ipInterface.
   rule 3: Same as rule 2, except assign the precedence value > rule2.
2. Take the LIF OOS and disable.
3. Restart the application.
4. Enable and in-service LIF.
5. Ping the next hop address through pkt port of the LIF.
6. Check the stats using the following command:
   "show table addressContext ADDR_CONTEXT_1 ipAccessControlList ipAclRulesByPrecedence"

This should result in rule 3 showing match counts instead of rule 2.

The code is modified to add all the rules in the NP, including the ones already added on the IPACL retry.

Workaround: None.

The SBC application restarts.

Impact: A SAM process encounters a core due to a Healthcheck timeout when the SIPCM attempts to open a TLS connection. The security certificate named in the tlsProfile is expired.

Root Cause: Two threads are hung while attempting to write a security certificate update () to the DB using the same socket. The purpose of the update is to change the state of the certificate to EXPIRED.

Steps to Replicate: 

1. Run a TLS load that will attempt to use an expired PKI security certificate (tlsProfile includes the name of the security certificate).
2. Look for the following messages in the DBG logs:

100000B.DBG:076 05262022 000010.545176:1.02.00.18170.MAJOR .SEC: *Certificate expired

The code is modified to add a lock preventing two threads from writing to the DB using the same socket.

Workaround: Renew PKI Security Certificates before they expire.

SBC Ethernet Port Packet Port Statistics have peak value equal zero.

Impact: SBC Ethernet Port Packet Port Statistics have incorrect peak value equal to zero.

Root Cause: The SBC has reset the bandwidth peak value after statistics collection.

Steps to Replicate: Execute a call load for hours and collect ethernet port packet stat.

The code is modified allowing the SBC to reset the bandwidth counter before it collects the real data.

Workaround: None.

Node B unexpectedly restarts when Node A is in SyncInProgress for a long time.

Impact: The Call/Registration Data on the SBC shows syncInProgress for an extended period of time.

Root Cause: A redundancy message buffer is not large enough to hold the data and causes the sync to be incomplete. This results in the Call/Registration Data to remain in a syncInProgress state.

Steps to Replicate: Run multiple Registration/Calls on the SBC.

The code is modified to address the issue. 

Workaround: None

Application restarted due to processAbnormalTermination

Impact: SSREq process coredumped while receiving message with length =0.

Root Cause: When the message length is =0, the third party software, Xalan, crashes when allocating memory.

Steps to Replicate: Perform SSREq request to ERE when configured for external PSX.

The code is modified to add a check to not process messages with length=0.

Workaround: Stop the SSREq process.

The SBC resets SRTP encryption sequence number after a re-INVITE; the anti-replay protection at the far end (on another SBC) discards the incoming SRTP packets until the sequence number approaches the highest recorded sequence number.

Impact: Intermittent one-way audio with a duration of more than 10 seconds may occur during call transfers when the remote connection media IP address changed on the secure RTP (SRTP) call leg. The RTP sequence number (SSN) of the outgoing SRTP stream encrypted by the SBC may roll back to a lower value that causes the SRTP packets being discarded by SRTP anti-replay protection at the receiver's end. Once the SSN of the SRTP stream reached the highest recorded value, the audio was back and both parties could hear each other.

Root Cause: After the call transfer, the remote connection media IP address on the SRTP call leg was modified without deactivating the media resource chain. This caused the delay in applying the security configuration to the media resource chain, which in turn caused the first one of several SRTP packets being sent with a high SSN number and the roll back of the SSN to a lower value. The remote end discarded the SRTP packets with a lower SSN than the highest recorded SSN.

Steps to Replicate: 

1. Make a SRTP-to-RTP call between A and B through the SBC under test.
2. A puts B on hold and calls C through a different SBC/device.
3. A bridges B and C together and uses a late-media re-INVITE towards B to modify the original connection media IP address with the C's media IP address.
4. The SBC sends a re-INVITE with a SDP offer to B.
5. Once the SBC receives a 200 OK with a SDP answer from B, it starts sending the SRTP packets to C's connection media IP address.
6. The first SRTP packet sent to C has a SSN of around 1000 and the second SRTP packet has a SSN of less than 256. C discards all received SRTP packets until the SSN reaches the highest recorded SSN, which is 1000.

The code is modified so in a modify offer or answer for a SRTP call, if the remote connection media IP address is modified on the SRTP call leg, the new IP and security configuration are applied at the same time, without a delay.

Workaround: None.

SBC delay in processing Late Media re-INVITE

Impact: The SBC is not able to relay/responds to the late media re-INVITE after call is connected.

Root Cause: There is a race condition where ingress connects first before egress. The SBC received reInvite and forwards to egress. Egress internally responds 491 because egress is not in the connected state yet. However, internally the CC subsystem is ignoring to relay the 491 and responds due to the wrong state.

Steps to Replicate: Configure the passthru latemedia:

1. Late media call
2. Ingress sends latemedia re-INVITE immediately after sending ACK for the first Invite.

The code is modified to correct the CC logic to relay the 491 responds to ingress.

Workaround: Disable passthru latemedia.

Transcoding is failing for T.38 involving SRTP

Impact: The SBC is not sending SRTP attributes in an outgoing offer for the G711 fax call.

Root Cause: This issue is specific to a call flow where the initial audio call is a pass-through with non-G711 codec and later transitions to fax using G711. In this call flow, the SBC fails to offer SRTP crypto attributes during the fax call.

Steps to Replicate: Configuration:

Ingress Route PSP -
Fax Tone Treatment: FAX_TONE_TREATMENT_FALLBACK_G711

Egress Route PSP -
Fax Tone Treatment: FAX_TONE_TREATMENT_IGNORE_DETECT_ALLOW_FAX_RELAY

PSP -> Enable flag "Apply Fax Tone Treatment"

1. Setup G.722 pass-through call with SRTP on ingress leg.
2. Once audio call is stable, send T.38 re-invite from UAS.
3. The SBC sends G711 fax re-Invite towards ingress leg.
   
   

Without fix: The re-Invite at step 3 is sent with out SRTP.

With fix: The re-Invite at step 3 is sent with SRTP.

The code is modified to offer crypto attributes even when the initial audio call is using a non-G711 codec.

Workaround: None.

SIP to SIP call had no response to PRACK.

Impact: The SBC is unable to respond to PRACK with new SDP offer while the call is in terminating state.

Root Cause: Call is in terminating state.

Steps to Replicate: The Ingress configuration disconnected the treatment.

1. A (PRACK support) call B, B answer failure response (ex: 486)
2. SBC sends 183 to play disconnected treatment.
3. Peer sends PRACK with SDP new offer.

The code is modified so the SBC rejects a 500 error response to a PRACK request with an SDP offer.

Workaround: Disable PRACK or disable disconnected treatment.

Video call disconnects abruptly due to ACK not getting propagated

Impact: The SBC is unable to answer ACK for re-INVITE on ingress leg.

Root Cause: The Egress leg is resetting the end-to-end ACK feature after receiving 200OK offer for latemedia call. As a result, this causes the ACK to not send on Ingress for re-INVITE.

Steps to Replicate:

1. Configure the latemedia passthrough, enable e2e ACK, and e2e re-INVITE
2. Run a late media call
3. Egress sends a re-INVITE to Ingress
4. Ingress answer 200OK
5. Egress answer ACK

The code is modified to turn on the e2e ACK feature back after the ACK send out for latemedia call.

Workaround: Disable e2e re-INVITE or e2e ACK.

SAM Process coredumps are causing a switchover if FAC enabled and call Id is longer than 24 characters.

Impact: While reporting statistics for a Fault Avalanche Control (FAC), the SAM process may core if reporting on a call with a callId larger than 24 characters.

Root Cause: While reporting statistics for FAC, an incorrect "maximum size" is used when copying a callId - resulting in the code writing past the end of an allocated buffer and corrupting memory.

Steps to Replicate: Run some calls with FAC while collecting FAC statistics.

The callids for these calls should be longer than 24 characters.

The code is modified to use the correct "maximum size" when copying the callId.

Workaround: Disable FAC.

The FAC feature blocks SIP messages of certain key elements that caused multiple coredumps in the past. Disabling FAC will block them from getting processed again

An SCM Process core occurred on both servers.

Impact: The SIPCM process cores.

Root Cause: The SIPCM process cores because it was accessing a Packet CCB that had already been freed.

Steps to Replicate: The steps are not reproducible.

The code is modified to add defensive code to prevent SIPSG from accessing a Packet CCB that is already freed.

Workaround: None.

The SBC cores along with disk errors seen (2ndcore)

Impact: The SCM cores while attempting to update SIP protocol specific fields in the accounting record.

Root Cause: The code is using the wrong function to get a pointer to the URL header structure.

Therefore, the SBC is using an invalid pointer and operating on invalid data.. This resulted in an attempt to dereference a NULL pointer, which caused a Segmentation Fault.

This code path is executed when writing SIP protocol specific fields into accounting record.

Steps to Replicate: This issue is not reproducible. The code has been the same since prior to the 7.2 release and this issue hasn't been seen before. Low risk of reoccurrence.

The code is modified to use the correct function to get the pointer to the header.

Workaround: Disable CDRs.

sanitizer.CE_2N_Comp_CpxAppProc & CE_2N_Comp_DiamProcess

Impact: A small amount of memory leaks while configuring diameter peer IP addresses

Root Cause: The configuration validation routines were allocating memory while cross-checking the new CDB configuration and this memory was not freed at the end of the validation.

Steps to Replicate: Create diameter peer IPs and check for no memory leaks in an ASAN enabled build.

The code is modified to update the validation routines to make sure the memory is freed so there is no leak.

Workaround: None.

LeakSanitizer in CE_2N_Comp_CpxAppProc, CE_2N_Comp_ScmProcess0,1,2,3

Impact: While sending a SIP SUBSCRIBE message, the code was leaking memory if there were PATH headers in the associated subscribed registration data.

Root Cause: The code was creating copies of the PATH header information to map into the P-Asserted-ID header and not freeing up all the associated information once the subscription processing completed.

Steps to Replicate: Run various SUBSCIRBE for REGISTER event test cases and check there are no memory leaks.

The code is modified to make sure all P-Asserted-ID header memory is correctly freed up.

Workaround: None.

PortFix SBX-115152: Unknown header is not relayed with re-INVITE call flow in PSX.

Impact: Unknown Header Transparency for BYE message do not work in call scenario where SBC receives a re-INVITE from Egress peer and BYE is received from Ingress Peer. Issue is observed only when Re-INVITE is auto-answered by SBC

Root Cause: SIP request data for Re-INVITE is not cleared from SIP call control block after Re-INVITE offer-answer completion. This results in duplicate entries for SIP request data in the SIP call control block when the SBC receives the BYE message. During handling of the BYE message at Egress leg, request data pointer is retrieved from call control block to set transparency mask for unknown header, request data pointer of Re-INVITE is picked always instead of BYE message. This results in unknown header transparency issues for BYE.

Steps to Replicate: 

1. Make SIP-SIP call setup with G711 U law.
2. Enable "Minimize Relaying Of Media Changes From Other Call Leg" flag in Ingress IPSP.
3. Enable "Unknown Header" transparency in IPSPs.
4. After session establishment, send Re-INVITE from Egress peer with G711U law for call hold ( a=sendonly).
5. Send BYE from Ingress peer with Unknown Header.
6. Verify if unknown header in BYE message is sent transparently to other leg.

The code is modified so that SIP request data is cleared properly for Re-INVITE.

Workaround: None.

PortFix SBX-120128: The SBC 5400 switchovers occur after an upgrade to v09.02.04R003.

Impact: The SCM process may core while attempting to set the original peer SDP address when either NAPT for Media is enabled and the SDP is received, or if ICE is enabled and ICE is in the SDP.

Root Cause: In the above two scenarios, the software did not protect against using a NULL packet SG control block address.

Steps to Replicate: The steps are not reproducible.

The code is modified to prevent the NULL packet SG control block address from causing the SCM process to core.

Workaround: None.

PortFix SBX-115304: The SBC replies with a 481 message for INVITE with occasional replaces.

Impact: The SBC replies a 481 message for INVITE with occasional replaces.

Root Cause: In early dialogue, the state to-tag is not updated in the Hashtable but the from-tag is updated. This issue is why when we tried to look up using only the call ID. As a result, it fails to fetch original call as the original INVITE and the INVITE with replaces had the same call ID.

Steps to Replicate: 

1. Prepare a SIP-to-SIP call setup with INVITE with replaces from the client side having the same call ID for original INVITE and INVITE with replaces.
2. Check if the INVITE with replaces is replacing the original call and if the lookup is successful or not.

The code is modified to look up both the call ID and from-tag for the ingress leg.

Workaround: None.

PortFix SBX-118049 - The SRTP decryption and encryption fail after an upgrade to 9.2.4R0/10.1.0R2.

Impact: The SBC fails to decrypt the incoming SRTP packets, causing a static noise instead of audio on the SRTP calls. 

Root Cause: Since 9.2.0x, one flag is used in the XRM. XRM_SRTP_SESS_UNENCRYPTED is used for both the unencrypted SRTP and unencrypted SRTCP. When this flag is set, the XRM sends cipherType = NP_CIPHER_TYPE_sRTP_NULL to the NP. The SBC does not to decrypt the incoming SRTP packets.

Steps to Replicate: 

1. Enable the UNENCRYPTED_SRTCP in the cryptoSuiteProfile.
2. Enable the INFO level DBG logging and make calls.
3. Check the DBG log for NpMediaRidEnable and NpMediaFlowEnable messages
4. Ensure that:
   • RTCP = cipher/size 0x8000000/0x40000
   • RTP = cipher/size 0x6000000/0x40000

A new flag is added, for unencrypted SRTCP: XRM_SRTCP_SESS_UNENCRYPTED

The modified NRMA and XRM adopt the new flag for SRTCP.

Workaround: Disable the UNENCRYPTED_SRTCP in the cryptoSuiteProfile

PortFix SBX-115231: Possible stack overflow vulnerability in the RTCP processing.

Impact: Potential stack overflow vulnerability was identified through the internal code review in the RTCP generation subsystem of SWe NP module.

Root Cause: The root cause of the problem was identified to the use of variables of an incorrect storage size.

Steps to Replicate: The steps cannot be reproduced. 

The code is modified to address the vulnerabilities.

Workaround: No workaround.

PortFix SBX-114456: The AMRWB is transcoded although negotiated end-to-end.

Impact: The Transcode option for "different2833PayloadType" feature considers only the 8,000 DTMF payload and the 16,000 DTMF payload is not compared with the opposite leg Peer PSP DTMF, unlike the 8,000 DTMF in earlier releases. This leads to unnecessary transcoding when the same 16,000 DTMF is present in both Ingress Offer and Egress Answer.

Root Cause: The SBC does not compare the 16,000 DTMF payload type of Ingress and Egress Leg when "different2833PayloadType:" is enabled, unlike 8,000 DTMF. The SBC should only transcode the call only when the 16,000 DTMF payload is different for both Ingress and Egress; otherwise, the SBC should treat the call for pass-through (PT).

Steps to Replicate: 

TC1:

1. Set preferred DTMF to 101 and enable different2833PayloadType flag.
2. From Ingress Peer send PCMU and AMRWB with 8,000 PT 101 and dtmf PT 16,000 102.
3. Egress Peer send AMR-WB 102 in answer.
4. The call should be pass-through with DTMF 102.

TC2:

1. Set preferred DTMF to 101 and enable different2833PayloadType flag.
2. From Ingress Peer send PCMU and AMRWB with DTMF 8,000 PT- 104 and DTMF16K PT - 102.
3. Egress Peer send AMR-WB 102 in answer.
4. The call should be pass-through with DTMF 102.

TC3:

1. Set preferred DTMF to 101 and enable different2833PayloadType flag.
2. From Ingress Peer send PCMU and AMRWB with DTMF 8,000 PT- 104 and DTMF16K PT - 105.
3. Egress Peer send AMR-WB 102 in answer.
4. The call should be transcoded for difference in DTMF - 102 in Egress and 105 in Ingress.

The code is modified to check both the 8,000 and 16,000 DTMF for a difference in payload type with the corresponding answered DTMF payload types, sent by Egress Peer in Offer Answer function to determine whether the call should be transcode or pas-through. If the DTMF payload types are same, the call is passed through and transcoded if the DTMF payload types are different. These checks are done when "different2833PayloadType" feature flag is enabled.

Workaround: None.

PortFix SBX-115616: Routing label settings could not be changed in the EMA if created by the CLI.

Impact: Unable to change Routing label settings from the EMA UI if they were created using special characters  in the CLI.

Root Cause: CLI was allowing _ + - . : @ characters in the Routing Label name. The EMA, however, was only allowing  _ character in Routing Label name. As a result, attempts to update the Routing Label from the EMA failed.

Steps to Replicate: 

1. Log in to CLI.
2. Created Routing Label with following special characters (+:.@-) from CLI.
3. Log in to the EMA.
4. Navigate to Routing and select the Routing Label and edit the same.
5. Edit is successful.

The code is modified to allow special characters + - . : @ in the EMA.

Workaround: No workaround.

PortFix SBX-117637: The SCM Process generates a core and a switchover occurs due to null pointer in a forked call.

Impact: The SCM is coring when trying to free memory that has already been freed.

Root Cause: The SCM process cores when trying to free memory because of a non-reproducible edge case scenario which causes the memory to be freed before returning from a subroutine. The calling function doesn't handle this correctly.

NOTE: This scenario only happens if a downstreamForkingSupport is enabled on the SIP Trunk Group.

Steps to Replicate: The steps cannot be reproduced. 

The code is modified to prevent the scenario.

Workaround:  None.

PortFix SBX-115262: Unexpected UPDATE from the SBC after UPDATE with media inactive.

Impact: Delayed RBT with the monitor profile in early dialog with DylRBT, there is an update from the caller to set the media to inactive. That triggers an UPDATE towards the called with media inactive. Just after that, the SBC sends a new UPDATE with the media direction "sendrcv" to the caller.

Root Cause: Since in this case tone is playing and dlrbt is enabled, Update from ingress with DPM inactive is processed by the SBC and sent to egress. Egress responds with 200 OK with Media as inactive which is passed to ingress.

The SIPSG sends notification to CC to STOP tone. Tone stops and cut-thru is set in CC. CC sends activate to NRMA and NRMA swaps tone context with cut-through context that has a DPM of sendrecv. NRMA sends update notify ingress with DPM of sendrecv, which is sent to ingress peer as an Update.

Steps to Replicate: 

1. Run the Customer configuration.
2. Run the Customer Scenario DelayedRBT enable with Tone continuation and Monitoring profile is enable.
3. Run an additional update to stop after an UPDATE with media = inactive.

The code is modified to address the issue. 

Workaround: No workaround.

PortFix SBX-114764: The G711 codec is used incorrectly during a G729 UPDATE.

Impact: The SBC plays the incorrect media towards Ingress End Point after a call is established.

Root Cause: Issue 1: Port is not updated after an UPDATE during tone play.

After the SBC receives an UPDATE from Ingress End Point during tone play, the SBC updates the codecs and port information. But after a 200 OK for UPDATE is sent out, the SBC overwrites the new information with old information.

Issue 2: The wrong codec is used after the call is established.

After an UPDATE is received during a tone play, the SBC tends to suppress sending UPDATE/re-INVITE towards ingress during cut-thru (after tone play) by re-using the last tone codec on ingress leg.

However, it does not preserve/re-use the transcoding resources which results in wrong media being played towards Ingress EP.

Steps to Replicate: 

1. Configure the SBC with Basic call configuration.
2. Attach TONE_GENERATION_CRITERIA to Tone and Announcement Profile.
3. Configure earlyMedia in Egress TG.

Procedure:

1. The SBC receives INVITE with 0,8,18 from Ingress EP.
2. The SBC receives 180 Ringing with 0 from Egress EP.
3. The SBC receives UPDATE from Ingress EP with 18 and with new media port.
4. The SBC receives 200 OK for INVITE without SDP from egress EP.

Expected Results:

1. The SBC will forward the INVITE to Egress EP.
2. Once the SBC receives 180 with SDP, it will forward to Ingress EP.
   The SBC starts monitoring RTP from Egress. Once timeout happens, the SBC will start generating tone towards Ingress EP.
3. Once an UPDATE is received, the SBC will change the codec to 18 and port to new media port.
4. The SBC receives 200 OK for an INVITE.
   The SBC will use the same codec combination used during tone play.
   A call gets established successfully as G729-PCMU.

The code is modified for the following issues: 

Issue 1: The SBC now changes the port towards Ingress EP.

Issue 2: The correct media is played at the tone play Ingress EP, based on whether or not the call needs transcoding resources..

Workaround: None.

PortFix SBX-118191: An upgrade is successful but revert operation failed - V10.1.0R2 to V11.0.

Impact: The SBC application does not come up after revert on cloud 1:1 mode.

Root Cause: The SBC application gets stuck due to Openclovis model update cache on old active disk.

Steps to Replicate: 

1. Perform an upgrade on an SBC HA 1:1 on public cloud (such as AWS) from a pre-9.2 to a 9.2 release.
2. Revert the SBC HA 1:1 to a pre-9.2 release.

The code is modified to indicate this model update cache and perform a model update on standby after revert to remove any component that is not needed.

Workaround: 

1. Bring up SBC HA application with a pre-9.2 release on public cloud, such as AWS.
2. Upgrade both active and standby SBC to this release using the recommended upgrade method.
3. Revert the SBC application to pre 9.2 release.
4. After revert operation, check to see if application is coming up fine on both active or standby.
5. If the application is stuck and not able to get the assigned role, stop SBC application on both active and standby nodes using ‘sbxstop’ command.
6. Remove the following file/directories from both active and standby SBC if existing:
   1. rm -rf /home/cnxipmadmin/peerDynamicHANewComps
   2. rm -rf /opt/sonus/sbx/openclovis/var
7. Start the SBC application on both active and standby nodes using ‘sbxstart’ command.
8. Check to ensure that application is coming up fine on both nodes.

PortFix SBX-111832: PRS Process and ENM Process coredumps observed in SLB during REGISTER Performance run

Impact: The PRS and CHM processes were allowing switchover even when the sync was in progress, causing failures in restoring context in XRM.

Root Cause: The sync completion check was incorrect and incomplete, thereby allowing a switchover to occur even when the sync is in progress.

Steps to Replicate: Trigger the switchover while the sync is still in progress to check if standby either takes over, or if it restarts to prevent the switchover.

The code is modified to add a thorough sync completion check to the PRS and CHM processes to prevent a switchover when a sync is in progress.

Workaround: None.

PortFix SBX-118118: Both of the SBC units went down after an unregister from the EMS.

Impact: Both of the SBC units went down after an unregister from the EMS

Root Cause: The code in the ENM process notifies the deletion of the SnmpAgent snmpTargetMib snmpTargetAddrTable snmpTargetAddrEntry. The ENM process code spawns a thread to delete the corresponding trap from the oam snmp trapTarget table that shares a CDB socket with the SonusSnmpTrapTarget::ProcSubDelete.

Steps to Replicate: 

1. Register an SBC instance with an EMS.
2. Unregister the same SBC instance with the EMS.
3. Observe that the ENM process does not crash.

The SonusSnmpTrapTarget::DeleteTrapTargetThread routine is modified to use its own CDB socket to prevent contention from two threads for the same socket.

Workaround: None

PortFix SBX-114778: The STOP RECORD is missing from CDR VIEWER after a switchover.

Impact: STOP RECORD IS MISSING from CDR VIEWER after a switchover.

Root Cause: With the current Logstash configuration, the logstash reads the TRC and ACT files only from the time when the logstash was started, which means older data is not read by logstash. When a switchover occurs, by the time logstash is started all the calls would have completed thereby updates to TRC and ACT would have stopped.

Logstash does not read the TRC and ACT files until they are updated again. When the updates start, logstash does read from the point where the new data is written and not the old data. This is the reason why stop record of the calls are not shown after the switchover

Steps to Replicate: 

1. Log in to the EMA of an active SBC and Enable CDR Viewer.
2. Run a call with a duration (about 50 seconds) such that it gets stopped before EMA is started in the standby SBC after the switchover.
3. Initiate a switchover.
4. Log in to EMA of a standby SBC (which is the active now).
5. Navigate to CDR viewer screen.

The STOP record should display.

The code is modified to read the older data and not just the new data.

Workaround: None.

PortFix SBX-110857: The RTP stream with unknown port (5004) with Delayed RBT after 180.

Impact: RTP packets being sent to port 5004 after 180.

Root Cause: The RTP packet was the silence packet generated from DSP. Before RTP monitoring was enabled, the call had already been cut through. When RTP monitoring was enabled, NRMA sent a flow change to XRM to change the remote port to 5004. As a result, the DSP-generated silence packet got sent out to remote peer on port 5004.

Steps to Replicate: 

1. Enabled INFO debug logging.
2. Establish a simple transcode call with RTP monitoring enabled on egress side.
3. Check the DBG log for the port number in message "NpMediaFlowModify: Src RTP port modified port 5004 enSrcVal 0x1"

The code is modified so the XRM ignores the remote RTP port change. So the RTP packets are sent to resolved remote IP and port.

Workaround: None.

PortFix SBX-105749: The RTP monitoring failed when the iteration is set to 1 or 2.

Impact: The RTP Monitoring is not working as expected when the iteration is set to 1 or 2

Root Cause: When the monitoring period is over, it sends FIRST expiry and FINAL expiry together. As a result, this is not being handled properly leading to non-playing of LRBT.

Steps to Replicate: Configure monitoring cycle to 1 and make calls. Ensure that LRBT is heard when monitoring cycle gets over.

The code is modified to play the tone.

Workaround: Use n=3 or more.

PortFix SBX-120264: The SCM Process continually cores on two SBC 7000s - possibly PCV IOI related.

Impact: The SCM Process coredumped due to NULL pointer access for a (GSX) ISUP-GW-GW-SIP call after enabling Generate or Replace PCV feature.

Root Cause: The code was trying to read a CPC parameter from the ingress side of the call and the parameter is NULL when the ingress side is ISUP.

Steps to Replicate: 

1. Set up a GW-GW call from GSX using ISUP as ingress
2. Enable Signaling > Generate or Replace PCV

Expected result: The SCM Process cores.

The code is modified to ensure the CPC parameter is not NULL before accessing it.

Workaround: Disable Signaling > Generate or Replace PCV and apply the fix.

PortFix SBX-118822: The HA SBC fails to start on version 09.02.04R001 when the Direct IO Passthrough is used.

Impact: The SBC application fails to start on a 44 vCPU instance.

Root Cause: The maximum number of vCPUs supported is set to 40 in the SM module. This leads to corruption and a subsequent core-dump on instances with a size greater than 40 vCPUs.

Steps to Replicate: 

1. Install the SBC application on an instance with a vCPU size greater than 40.
2. Make sure the application starts and there are no core dumps observed.

The code is modified and now set to be in sync with other modules.

Workaround: None

PortFix SBX-118367: Missing CDR sub fields from Column: Ingress Protocol Variant Specific Data.

Impact: Missing CDR sub fields from Column: Ingress Protocol Variant Specific Data.

Root Cause: The CDR fields were not updated in SipSgFillProtocolSpecData function from where CDR was getting populated.

Steps to Replicate: 

1. Replicate the issue by running a basic SIP-to-SIP call and removing any mandatory header field.
2. Check if all of the 86 sub fields are getting populated in CDR of 45th field (Ingress Protocol Variant Spec Data).

Updated SipSgFillProtocolSpecData function with the CDR field that were missing to address the issue.

Workaround: None.

PortFix SBX-119525: Observed the SCM Process core while running callflow sanity on the SBC 7000

Impact: Application gets crashed while running call flow sanity on the SBC 7000.

Root Cause: During Call Progress when a timeout is hit and CANCEL is triggered towards endpoint then due to invalid/null pointer access core dump is observed.

Steps to Replicate: Run a call flow sanity on an SBC 7000.

The code is modified to ensure the pointer is validated for NULL before accessing it.

Workaround: None.

PortFix SBX-114415: The SBC 7000 standby CE stopped functioning with file corruption and "read only" mode.

Impact: When the file system turned to Read Only mode the server did not go for reboot.

Root Cause: The SBC became stuck during the read only file system checking but the root cause cannot be determined.

Steps to Replicate: The steps cannot be reproduced.

The code is modified to use different commands to check for read only status to try and ensure the SBC automatically reboots to recover.

Workaround: An operator needs to manually reboot the SBC in order to recover it.

PortFix SBX-113060: The SBC needs to open both protected TCP and UDP port in AKA mode.

Impact: The SBC drops messages coming on the TCP when some phone does initial registration over UDP but later sends message over TCP in IMS AKA scenario.

Root Cause: When initial REGISTER comes on UDP in IMS AKA scenario, the SBC does not open protected ports on TCP. This will cause problem with some phones, which do initial registration over UDP, but later may send some messages over TCP during call.

Steps to Replicate: 

1. Run an IMS AKA registration over UDP.
2. Check netstat on the SBC to see if the negotiated protected ports are opened on both UDP and TCP.

The code is modified so that the SBC opens protected ports on both TCP and UDP when the initial registration is over UDP.

Workaround: None.

PortFix SBX-118988: The sysDump saved with an owner as root even though sbcDiagnostic 2 is run with linuxadmin as user.

Impact: In the Cloud SBC when sysdumps are generated using sbcDiagnostic command as linuxadmin user, linuxadmin is unable to copy the sysdumps due to restricted permissions.

Root Cause: sbcDiagnostic was generating sysdumps with root ownership, which did not allow linuxadmin to copy them.

Steps to Replicate: 

1. Run sbcDiagnostic 2 command as linuxadmin user in the cloud SBC.
2. Try copying generated sysdumps from /opt/sonus/external/ location.

With a fix, linuxadmin should be able to copy sysdumps.

The code is modified to allow copying.

Workaround: None.

PortFix SBX-118635: Observed the IpSockAddr (0.0.0.0) and Port (0) for Egress leg in GW1 and Ingress leg in GW2 for GW-GW HPC call scenario.

Impact: The IpSockAddr and Port fields are 0 in the global callDetailStatus status command in a GW-GW HPC call scenario.

Root Cause: In 9.2.4R001, the code is added to not send CPC_OP structures unknown to the GW-GW encoder layer over the GW-GW link to reduce the size of the GW-GW message sent to older SBCs and the GSX. However, it was found that at least one of these unknown CPC_OP Structures, CPC_OP_SIP_ZONE_AC_NAME_STR was used to transfer information used in the global callDetailStatus status command.

Steps to Replicate: 

1. Set up two SBCs that communicate over the GW-GW.
2. Place a GW-GW HPC call scenario call.
3. Observe that the IpSockAddr and Port fields are not 0 after running the global callDetailStatus status command.

The code is modified to send the CPC_OP structures unknown to the GW-GW encoder layer over the GW-GW link.

Workaround: None.

PortFix SBX-116340: Customer reported DNS failures on 3 different occasions that appears to be related to "time to live" and negative cache functionality.

Impact: DNS records (requests) can become stuck in RESOLVING state within the Agent, which causes the FQDN to become unreachable forever.

Root Cause: A DNS request (or it's response), sent between the Agent (e.g., ScmProcess) and the Client (DNS Process), becomes lost. This causes the DNS record to become stuck in RESOLVING state, and the FQDN to become unreachable.

Steps to Replicate: The steps cannot be reproduced.

The code is modified to:

• Add a default value of 60 seconds for the DNS record when the DNS request is sent by the Agent to the Client.
• In the error case, delete the DNS record when the timer expires in order to recover.
• In the working case, reset the expiration time to the TTL received in the DNS data.

Workaround: Manually clear the DNS cache or manually query the "stuck" FQDN.

PortFix SBX-117469: Azure: Upgrade is failing from 9.2.3R4 build to 11.0.0 on standalone.

Impact: Upgrades are failing in Azure using Ribbon IaC package.

Root Cause: Newer versions of the Azure CLI change the way it authenticates, meaning it no longer works with the Ribbon IaC package.

Steps to Replicate: 

1. Log in to the Azure CLI.
2. Attempt to upgrade the Azure SBC using Ribbon IaC.
3. The upgrade fails due to lack of credentials.

The code is modified to install Azure CLI version 2.24.0

Workaround: 

1. Uninstall the current Azure CLI version.
2. Install the Azure CLI version 2.24.0 using the system package manager.

PortFix SBX-118683: The active T-SBC switches over to the standby T-SBC with a health check failure.

Impact: The SWe UXPAD core-dumps due to an arithmetic exception.

Root Cause: 

1. The arithmetic exception is the result of a denominator of a divide operation with a zero value.
2. The denominator is a sum of two energy values, both of which are expected to be positive. The issue occurs when one of the energy values is negative.
3. The negative energy value is attributed to the incorrect handling of overflow when computing the energy value. The incorrect handling of the overflow makes a large positive number appear to have a negative value.

Steps to Replicate: The issue is not reproducible.

The code is modified by setting the energy value to the maximum positive value if an overflow occurs.

Workaround: None.

PortFix SBX-117762: If there is only one m-line in the SDP of UPDATE with port ZERO, the SBC is having different behavior for Audio, Video and Application call flows

Impact:
Ingress is sending UPDATE and setting Media Port to ZERO.

1> For m-line application
The SBC is rejecting this UPDATE with 488.

2> For m-line Audio
The SBC is passing this UPDATE to other side with valid port and c-line is present.

3> For m-line Video
The SBC is passing UPDATE to other side but removing C-line

The SBC must pass an update for m-line application and also c-line should be present in all the cases.

Root Cause: The code was written to reject update when media is application and port is zero.

Steps to Replicate: Send update with m-line application, video and audio with port as zero. The update should pass to the other side and C-line should be present in all the cases and port should be zero.

The code is modified to allow the call flow to function accordingly after the fix:

1> For m-line application
The SBC is passing this UPDATE to the other side with valid c-line.

2> For m-line Audio
The SBC is passing this UPDATE to other side and c-line is present.

3> For m-line Video
The SBC is passing this UPDATE to other side without removing C-line.

In all the above scenarios if UPDATE is sent from ingress side with port zero, it is received on the other side with port zero.

Workaround: The call flow after the fix:

1> For m-line application
The SBC is passing this UPDATE to the other side with valid c-line.

2> For m-line Audio
The SBC is passing this UPDATE to other side and c-line is present.

3> For m-line Video
The SBC is passing this UPDATE to other side without removing C-line.

In all the above scenarios if UPDATE is sent from ingress side with port zero, it is received on the other side with port zero.

PortFix SBX-118425: The SBC as a TLS server fails a TLS handshake attempt if an ECDHE cipher is used and the TLS client specifies an elliptic curve other than secp256r1 (prime256v1)

Impact: The SBC as a TLS server fails a TLS handshake attempt if an ECDHE cipher is used and the TLS client specifies an elliptic curve name other than secp256r1 (prime256v1).

Root Cause: The SBC uses the default elliptic curve name secp256r1 (prime256v1) when acting as a TLS server.

Steps to Replicate: Use "openssl s_client" to trigger TLS handshake with ECDHE ciphers with curve names secp384r1 and secp521r1.

The following commands assume the SBC's SIP-TLS address/port number is 10.x.yy.zz:5061:
$ openssl s_client -showcerts -connect 10.x.yy.zz:5061 -cipher 'ECDHE-RSA-AES128-GCM-SHA256' -curves secp384r1 | egrep "i:\s:"
$ openssl s_client -showcerts -connect 10.x.yy.zz:5061 -cipher 'ECDHE-RSA-AES128-GCM-SHA256' -curves secp521r1 | egrep "i:\s:"

A. Failed case shows the the SBC TLS server fails to find matching cipher suite and curve name:
$ openssl s_client -showcerts -connect 10.x.yy.zz:5061 -cipher 'ECDHE-RSA-AES128-GCM-SHA256' -curves secp384r1 | egrep "i:\s:"
140485529323328:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:ssl/record/rec_layer_s3.c:1544:SSL alert number 40
...
Packet capture will not show Server Hello Message.

B. Successful case displays the SBC TLS server's certificate chain after TLS server properly selects cipher suite and curve name.
$ openssl s_client -showcerts -connect 10.x.yy.zz:5061 -cipher 'ECDHE-RSA-AES128-GCM-SHA256' -curves secp521r1 | egrep "i:\s:"
depth=2 C = US, O = Sonus, OU = SonusProductPKI, CN = SonusProductRootCA
...
The packet capture will show Server Hello after the SBC TLS server selects the matching cipher suite and curve name.

The code is modified to allow the SBC TLS server to select the Elliptic curve name automatically.

Workaround: Do not specify the curve name, or use curve name prime256v1 (openssl 1.0's default on TLS server) when using a tls_ecdhe* cipher suite.

PortFix SBX-116997: Late media pass-through calls fail after an upgrade from 8.2.2R0 to 8.2.6R0.

Impact: Late media pass-through calls with "RTCP termination for passthrough" flag enabled failed.

Root Cause: There are two receiver IDs in the RTCP termination Bus RESource definition. If one of the RIDs was not enabled during the BRES activation because the ingress XRES (ethernet resource) had not learned the destination MAC address yet, then the RTCP Gen was left enabled according to the design.

When that BRES gets deactivated, we skip sending RID disable command to NP for that not enabled RID, and also missed issuing RTCP Gen disable command to NP.

So when that BRES gets re-activated, the logic detected that RTCP Gen has already been enabled and failed the activation process, which then fails the call.

Steps to Replicate: Establish a late media pass-through call with "RTCP termination for pass-through" flag enabled.

The SBC sends a SIP BYE once it receives the SDP answer in the SIP ACK SDP.

The code is modified to send the RTCP Gen disable command to NP even when RID is not enabled.

Workaround: Turn off the "RTCP termination for pass-through" flag.

PortFix SBX-113233: Getting bulk alarms of "sonusSbxNodeResourcesNoPacketsReceivedNotification"

Impact: The patch includes additional stats from SWe_NP, which can help in triaging false reporting of RTP inactivity issues better.

In addition to this, the patch also includes fixes to prevent false reporting of RTP inactivity when policer mode is set to “Bypass” (from release 9.2.3), and preventing false RTP inactivity reporting in “call hold and unhold scenario” (from release 10.1.2R0).

Root Cause: There is no root cause identified.

Steps to Replicate: The steps are not reproducible. 

The code is modified to add additional NP stats to help in triaging false reporting of RTP inactivity, and also backported some known false detection fixes.

Workaround: None.

Portfix SBX-118331: EMS re-Synchronization feature not working fine with SBC7K

Impact: EMS trap resync logic does not work for standard SNMP traps e.g linkUp, linkDown.

Root Cause: The EMA was not aware of the mapping from the standard OID traps to trap name and as a result it was unable to resync trap information to EMS.

Steps to Replicate: 

1. Bring down mgt1 interface on the SBC side, critical alarm raised on the SBC and same has been reached to EMS.
   ip l set mgt1 down
2. Teardown the connectivity between EMS & SBC by creating the static route at SBX side (no trap will be reached to EMS).
3. Bring the mgt1 interface up on SBX side. (Clear trap generated on SBC but not reached to EMS because link between EMS & SBC is down so which is expected).
4. Bring the connectivity between EMS & SBC up (trap re-sync should work and EMS should clear the critical alarm raised on Step 1).

The code is modified so that the EMA now understands the OID values for the standard SNMP traps and can resync the info to the EMS.

Workaround: None.

Portfix SBX-114533: CPX not handling the notification correctly from SDR

Impact: SNMP traps destinations set by FQDN are not resolved correctly to IP

Root Cause: ConfD CDB API return inconsistent data when reading from CDB_RUNNING.

Steps to Replicate:

1. Deploy the SBC.
2. Add DNS records for SNMP trap target.
3. Configure DNS nameserver in the SBC.
4. Configure SNMP trap target fqdn.
5. Validate that the SBC resolve the fqdn and add the corresponding IP address and port.

The code is modified so that the Management Agent API (MAAPI) is now being used to read the SNMP trap target information instead of the CDB API.

Workaround: Restart the SBC.

PortFix SBX-116895: A SWe SBC switchover occurred because of an ENM Process core.

Impact: The ENM Process crashed when an accounting file rolled over.

Root Cause: If the fileCount for the accounting files is reduced substantially (ex. 2048 to 1024), and a rollover occurs, then a shell script is run for each file that needs to be deleted to reduce the file count to the new file count configured. This shell script deletes any hash files in the eventLogValidation directory associated with the deleted accounting file.

Steps to Replicate: 

1. Set the fileCount for accounting files to 2048.
2. Enable eventLogValidation for account files.
3. Rollover the log repeated to created 2028 accounting files.
4. Set the fileCount for accounting files to 32.
5. Rollover the account log.
6. Ensure the SBC has not crashed.

The code is modified so that instead of calling a shell script to delete the hash files, the EvmFileDeleteLogfiles routine has been changed to get a list of all the hash files of accounting files in the eventLogValidation, and deletes the associated hash file when an accounting file is deleted. This reduces the time to delete ~2000 files to less than a second.

Workaround: Do not reduce that fileCount for the accounting log files more than 300 files at a time. Rollover the accounting file each time the count is reduced.

PortFix SBX-118755: The S-SBC drops calls with 404 (Reason: Q.850;cause=3) with disconnected initiator is internal.

Impact: If there is a connection issue with one of the TSBC, the SSBC fails calls often trying to send allocation requests.

Root Cause: This event had 8 T-SBCs:

• If an allocation failed to one T-SBC because of a connection issue, the S-SBC removes the node from the cache but when cache expires for this LIF, fetch the same node again in bad state and once again try to send more requests

Steps to Replicate: Configure the S-SBC with 8 T-SBC's. Add an ACL in one of the T-SBC for the port from the S-SBC and then make a few calls and monitor if the calls are not failing.

When attempting to se4nd the request, the RRM:

• checks if the remote IP Address is mandated by NRM and if so tries to send the request out if it is connected. Otherwise, the RRM rejects it.
• checks if the remote IP Address is provided and preferred, if the remote node is connected then the request is sent out.
• checks if the remote IP address is provided and preferred but not connected then it tries to fetch a Connected Node with matching LIF group; or if finds a node which is in connecting state with matching LIF and queues the request and starts timer; or if the cache for the LIF group is not existent and is initial request, request Leader Node for the Cache.

On receiving GW indication, the possible following scenarios can occur: 

• If it is connected, fetch the queued messages and sends the request.
• If it is disconnected, fetch the queue and rejects the messages so that NRMA can retry.
• If the GW Connection timer expires, fetch the queue and rejects the messages so that NRMA can retry.

Workaround: None.

PortFix SBX-105137: The SBC is not able to parse MSRP media packet 200

Impact: When the SBC received "200" as an MSRP response, it did not forward the same to the other end as it considers 200 as a invalid response in absence of "OK" string in 200.

Root Cause: The SBC was strictly parsing "200 OK" for MSRP success response. Due to that, if it received "200" as a response, it did not forward the same to other end.

Steps to Replicate: 

Test 1

1. Configure SBC for MSRP-B2BUA support.
2. Complete the INVITE signaling message for MSRP
3. Send MSRP request message from UAC to SBC, SBC Should forward this to UAS.
4. From UAS send "MSRP <transaction-id> 200" response message to SBC.
5. SBC should successfully send it to UAC.

Test 2

1. Configure SBC for MSRP-B2BUA support.
2. Complete the INVITE signaling message for MSRP
3. Send MSRP request message from UAC to SBC, SBC Should forward this to UAS.
4. From UAS send "MSRP <transaction-id> 200 OK" response message to SBC.
5. SBC should successfully send it to UAC.

The code is modified to update the parsing logic to consider 200 as valid MSRP response.

Workaround: UAC/UAS needs to send MSRP response as "MSRP <transaction-id> 200 OK" to avoid this issue.

SBX-114818

18x/200 Contact header sent by the SBC contains port number different than 5061

Impact: The SBC includes an incorrect port number in the Contact header of the outgoing SIP messages towards registered endpoints when the endpoints use TLS as a transport protocol and a Call Data Channel (CDC; a lawful intercept component) is enabled on the SBC. This behavior results in call failures since the endpoints send SIP requests to unused TCP port numbers. As an example, the SBC includes port numbers 5062, 5063 and others while the configured port number is 5061 (and SBC listens on that port number).

Root Cause: A Lawful Intercept related subroutine changes the port numbers in the signaling port table which should always be the configured signaling port.

Steps to Replicate: To reproduce the problem, create a basic SIP access scenario where an endpoint registers over TLS (REGISTER – 401 – REGISTER – 200). Then, as calea user, provision the following (the assumption is that you already created an IP interface group named LIG with at least 1 IP interface in it):

set addressContext default intercept nodeNumber 10001
comm
set addressContext default intercept callDataChannel LigCDC interceptStandard etsi ipInterfaceGroupName LIG
set addressContext default intercept callDataChannel LigCDC mediaIpInterfaceGroupName LIG
comm
set addressContext default intercept callDataChannel LigCDC vendorId utimaco
set addressContext default intercept callDataChannel LigCDC dsrProtocolVersion 1
comm
set addressContext default intercept callDataChannel LigCDC mediationServer dfxa media udp
set addressContext default intercept callDataChannel LigCDC mediationServer dfxa media udp ipAddress 11.22.33.44
set addressContext default intercept callDataChannel LigCDC mediationServer dfxa media udp portNumber 37373
set addressContext default intercept callDataChannel LigCDC mediationServer dfxa media udp dscpValue 16
comm
set addressContext default intercept callDataChannel LigCDC mediationServer dfxa media udp mode inService
set addressContext default intercept callDataChannel LigCDC mediationServer dfxa media udp state ena
comm
set addressContext default intercept callDataChannel LigCDC mediationServer imsa signaling
set addressContext default intercept callDataChannel LigCDC mediationServer imsa signaling ipAddress 11.22.33.44
set addressContext default intercept callDataChannel LigCDC mediationServer imsa signaling portNumber 38154
set addressContext default intercept callDataChannel LigCDC mediationServer imsa signaling dscpValue 16
set addressContext default intercept callDataChannel LigCDC mediationServer imsa signaling protocolType tcp
comm
set addressContext default intercept callDataChannel LigCDC mediationServer imsa signaling mode inService
set addressContext default intercept callDataChannel LigCDC mediationServer imsa signaling state ena
commit

Once the CDC is configured, register the endpoint. The symptoms of the issue is that the SBC includes an incorrect port number (5062, 5063 and similar) in the Contact header of all messages sent to the endpoint. You don’t need to make calls though: the presence of port number 5061 in the event which is printed after the SBC received the REGISTER w/ Auth header is a sufficient proof that the issue is present:

195 03022022 092259.154049:1.01.07.12989.Info .SIPSG: sipsgCallProcCommonUtils.c (-6170) 3777. SipSgSelectTransportAndSigPort: Selected address 10.0.1.9:5060 for Sig port:1107 AddrType 1
195 03022022 092259.284953:1.01.07.14012.Info .SIPSG: sipsgCallProcCommonUtils.c (-6170) 4022. SipSgSelectTransportAndSigPort: Selected address 10.0.1.9:5061 for Sig port:1107 AddrType 1

The code is modified so that the configured signaling port table is not changed.

Workaround: This problem happens only when the CDC is configured and a SIP endpoint uses TLS as a transport protocol. If one of the conditions is not met, the problem will not happen.

PortFix SBX-116184: Call is getting failed with 500 error while running call to Verify the Signalling latency in CNF cluster

Impact: SLB was not able to determine the SBC instance name when dialogue transparency was enabled.

Root Cause: With the ‘dialogTransparency’ flag enabled on both the ingress and egress zones of ISBC and SLB, the instance-ID tag is not stored correctly in an internal hash for the Dialogue data.

Steps to Replicate: The fix has been verified for the following scenarios:

1. With the ‘dialogTransparency’ flag enabled on both the ingress and egress zones of ISBC and SLB.
2. With the ‘dialogTransparency’’ and ‘generateCallIdWithDialogTransparency’ flags enabled on both the ingress and egress zones of ISBC and SLB, both for a basic call flow and call flow with PRACK, UPDATE, Re-INV.

The code is modified to extract the the instance ID from Call Info from request Message in case of dialog transparency call flow.

Workaround: None.

PortFix SBX-115994: Configuring the last trunk as incoming/outgoing direction wise is causing the SBC to remove DTG info on receipt of 3xx

Impact: Configuring last trunk as incoming/outgoing direction wise is causing the SBC to remove DTG info on receipt of 3xx

Root Cause: During a TRM lookup for DTG information in TrmProcessIpLookupCmd() in case TRM_IP_LOOKUP_EGRESS_TYPE_DTGNAME_ONLY, the SBC iterates through all the Contact headers and saves DTG information (such as TG name, blocking status and Trunk Type ) in CPC_OP_TRM_IP_TRUNKGROUP_LOOKUP_DATA_STR *entry.

The same CPC structure is used in SipSgFillDestTgrpToCpcMsgInfo() to copy DTG information of all TGs in CPC_MSG. This DTG information is then used to route the call where TRM lookup is done through DTG name.

But in the TrmProcessIpLookupCmd(), TG blocking status "status" and TRM_IPTG_CB_STR *ipTgCbPtr of last Contact header is used to send TRM reply. Since, the DTG of Last Contact is blocked, the TRM reply fails and causes the DTG to lose information.

Steps to Replicate: 

1. Make SIP-SIP call configuration using the PSX.
2. At Egress zone, in addition with Egress TG, create three more TGs.
3. On the SBC, configure the "ingressIpPrefix" of all three TGs (TG1, TG2, TG3) with different server IPs address (IP1, IP2, IP3).
4. Send 3xx with three Contact headers.
5. Configure same ingressIpPrefix address in Contact Headers of 3xx message so that the first Contact header is set to IP1, the second Contact Header is set to IP2 and the third Contact Header is set to IP3.
6. Set "blockDirection" of TG3 to outgoing.
7. On PSX, Enable "Force Re-query for Redirection" flag in IPSP of Egress Trunkgroup.
   For example:
   Contact: <sip:14135;tgrp=<trunk_group>;trunk-context=meta1001-1002.<domain_name>@IP1>;q=1
   Contact: <sip:14135;tgrp=<trunk_group>;trunk-context=10.xxx.yyy.zz@IP2>;q=0.9
   Contact: <sip:14135;tgrp=<trunk_group>;trunk-context=meta3001-3002.<domain_name>@IP3>;q=0.8
8. Make an SIP-SIP call, send 3xx from Egress peer with these 3 Contact headers.
9. The SBC sends INVITE to first Contact header through TG1.
10. If the first Contact is not reachable, the SBC tries with the second Contact using TG2 and so on.
11. Verify that after receipt of 3xx with multiple contact headers, the TRM debugs are logged in DBG with trunk group names of all 3 Contact headers and there is no TRM failure message.

Two new local variables TRM_IPTG_CB_STR *ipTgCbPtrTemp and UCHAR statusTemp are created in caseTRM_IP_LOOKUP_EGRESS_TYPE_DTGNAME_ONLY.

After each iteration, when the status is != FOUND_BLOCKING, these new local variables are populated and then used in TrmIpSendLookupRpyNfy() for TRM reply.

Then while the loop has to iterate for each contact header, the user must populate CPC_OP_TRM_IP_TRUNKGROUP_LOOKUP_DATA_STR.

Because we are passing good values of status and ipTgCbPtr in TrmIpSendLookupRpyNfy(), the TRM reply does not fail.

Workaround: None.

SBX-120784

The SBC call fail: Extra +1 added to globalized INV R-URI and To header (+1+1)

Impact: The SBC sends "+1+1..." in user part of To and Ruri.

Root Cause: When the flag related to "Use Called URI as R-URI" is enabled, the SBC duplicates globalization of the user part.

Steps to Replicate: 

1. Enable "Used Called URI as R-URI".
2. Incoming call with userpart of To header and RURI have "+1...".
3. Outgoing call will have "+1+1..." in userpart of To and Ruri.

The code is modified so that there is no need to perform globalization if the flag is enabled.

Workaround: Disable "Used Called URI as R-URI".

SBX-120494

The S-SBC is dropping few calls after the S-SBC restart operation.

Impact: The SBC was releasing more than one standby call instance when the active call instance was released due to the call cleanup procedure:

Root Cause: The standby instance was deleting call instances based on the lowest 24 bits of the GCID while processing the call clean up scenario and check for the same value in all standby contexts. The bottom 24 bits of the GCID are not unique across all standby contexts which resulted in other standby call instances being removed. The code has now been updated to check for the full GCID value while removing instances as part of the call clean up procedure.

This was not a problem when the call was released normally on the active instance because it was only removed from the specific context on the standby instance.

Steps to Replicate: 

1. Make 8 calls on a cloud S-SBC 1:1 setup to to 8 different T-SBCs.
2. While the calls are stable and redundant apply an ACL to block the traffic to one of the T-SBCs. This will trigger a call cleanup to release the call on both the active and standby SBCs.
3. Perform a switchover and check the 7 other calls are preserved over the switchover.

The code is modified so that the standby process code verifies the full GCID value between the standby instance and the call cleanup message so that only the unique call is deleted from the standby.

Workaround: None.

SBX-120758

I-SBC is not framing the "P-Charging-Vector" header correctly in UPDATE message

Impact: The SBC was incorrectly sending a truncated P-charging-vector header in a SIP UPDATE message, resulting in the UPDATE message causing a parsing error at the next SBC and the call being released.

Received:
P-Charging-Vector: icid-value="PCSF:1-UHN3kli1asbc0000cfed-0-3-000000005f7d96fc-0000000000000581";orig-ioi=domainname.org

Sent:
P-Charging-Vector: icid-value="PCSF:1-UHN3kli1asbc0000cfed-0-3-000000005f7d96fc-0000000000000;orig-ioi=domainname.org

Root Cause: The functionality introduced in 9.2.3 supports a maximum of 63 characters when processing each of the fields in the P-charging-vector header. Functionality was always passing the PCV information over from the ingress side of the call to the egress side of the call and using it even if the feature was not enabled.

Steps to Replicate:

1. Send an INVITE to the SBC that contains a PCV header and check that the PCV header is sent out of the egress side without the PCV header being added.
2. Respond with 183 to complete the offer/answer processing and then send forward an UPDATE message to change the SDP content with SDP and PCV.
3. Check that the egress UPDATE message should not include the PCV header.

The code is modified to only use the internal data associated with SBX-107845 at the egress side when the configuration is enabled so it is no longer being used for PCV header creation at egress unless it's enabled. This avoids the SBC sending the PCV header in the UPDATE message.

Workaround: None.

PortFix SBX-117592: An end-to-end re-INVITE is not working after a 491.

Impact: After the SBC responds with an 491 and sends out a re-INVITE, some transparency headers were missing.

Root Cause: A logical error that did not check the state of the call correctly. As result, the SBC treats this re-INVITE as an internal re-INVITE (not e2e).

Steps to Replicate:

1. Run an e2e re-INVITE enable, A call B.
2. Both A and B send re-INVITE at the same time. SBC answer 491 on egress and send a re-INVITE on Egress. At the same time, answer 200 OK to the ingress.

As a result, the transparent headers may missing.

The code is modified to address the issue.

Workaround: None.

PortFix SBX-117302: PRS Process and the SMC Process are crashing. 

Impact: The PRS process was crashing while processing an MRSP message due to the first header line not being present:

"MSRP 0100543f85f SEND
"
"To-Path: msrp://17000000000.example.com:10000/%s;tcp
"
"From-Path: msrp://11.2.3.44:37001/1789102;tcp
"
"Message-ID: 016f28000567
"
"Byte-Range: 1-25/25
"
"Success-Report: yes
"
"Failure-Report: no
"
"Content-Type: text/plain
"


"Caller sent this message.
"
"-------0100543f85f$
"

Root Cause: If the SBC does not receive the MSRP header, line it was coring while processing the transaction id later.

Steps to Replicate: Verified with MSRP message without header line.

The code is modified to add a NULL check for transaction ID before processing.

Workaround: None.

CDR jitter value incorrectly calculated if DTMF 2833 packets in the stream

Impact: The SBC media jitter stats as reported in the CDRs are calculated incorrectly for received media flow containing DTMF digit events that span multiple DTMF digit packets.

Root Cause: For DTMF digit events that span multiple packets, all of the DTMF packets for that event contain the same RTP timestamp (corresponding to the beginning of the event), despite being sent over an interval that could span multiple seconds (for long digit events). The SBC previously included all DTMF digit packets in the media flow's jitter calculations, which in this case would be much larger than the actual jitter.

Steps to Replicate: Validate media jitter stats when the DTMF digit events spanning multiple DTMF packets are injected into a media flow received by the SBC.

The code is modified so that the SBC now omits DTMF digit packets (identified by their DTMF payload type) from media jitter stats calculations.

Workaround: None.

Call forking - XRM has at least two XRESs referencing same media resource

Impact: The NP reports 0xF0 error for set grace command(0x2C) because the associated media flow has already been enabled. The call works, but this error in turn triggers unsolicited call cleanup.

Root Cause: For ATCF or SIP Forking calls, XRM allocates a single IP address/UDP with multiple XRES resources (w/ different GCIDs) all referencing the same Media Resource structure. The XRM process uses a reference count in the XRM_MEDIA_RES_STR.

The media flow is enabled when the parent XRES is activated. Then when allocating child XRES, XRM sends a set grace command to NP for the same media flow after it has been enabled in NP.

Steps to Replicate: Watch for "Unsolicited Call Cleanup" log messages to be written in DBG upon activation of resource chain involving forked calls.

The code is modified to add a check for media flow reference count, and only sends the 'set grace' command to the NP when the reference count equals "1".

Workaround: None.

*NP 0 error counter macError, mgt0 static route missing and the rx_errors are increasing

Impact: Customer upgraded the SBC 5400 from 7.2.x to 9.2.3R4 and the management ports went from 100Mbps to 1Gbps due to feature located in the SBC 8.0.0 release. On some occasions, the management port become inaccessible and CRC errors are reported in the port statistics [ethtool -S mgt0].

Root Cause: The problem is specific to the SBC 5400.

When the NRS (Network Resource Service) thread issues an interface stop, followed immediately by an interface start request for all management (mgt) ports, resulting in the following behavior:

• When a port stop request is received, the mgt port driver puts the PHY in "super-isolate" mode where the receive and transmit (rx/tx) are stopped. This causes the remote link to go down.
• When a port start request is received, the mgt port driver takes the PHY out of "super-isolate" mode and the rx/tx are started. This results in the remote link to go up.

However, if the rx/tx are stopped and started in a short time (< 10 milliseconds), the remote link ignores the notification and does not renegotiate the clock/speed/duplex. This leads to the data becoming out of sync with the remote end, which causes CRC errors on the packets received.

Steps to Replicate: Run the sbxrestart command multiple times. When the SBC application is running, issue "ethtool -S mgt0" and ensure rx_crc_errors is still 0.

The code is modified to power down the PHY to a low power state when the port stop request is received. Thus, when the port start request is issued, the PHY is powered up to a normal power state. This forces the remote end to detect a link down and then a link up.

Workaround: If rx_crc_errors is increasing, disable and enable the mgt port.

Use the following Linux commands:

ifconfig mgt0 down

ifconfig mgt0 up

(Replace mgt0 with the mgt port name where rx_crc_errors is increasing.)

The DTLS client Hello was being ignored.

Impact: The SBC may ignore DTLS Client Hello message and cause no audio in STUN/ICE/DTLS calls when the endpoint performs STUN checks for two candidates and the two checks overlap.

Root Cause: The SBC is storing remote IP/port in the nominated candidate list, even if BREQ/BREQ_UC messages are already sent.

Then when resending the BREQ message, the SBC uses the remote IP/port from the stored nominated candidate array and that is causing confusion.

Steps to Replicate: Establish a STUN/ICE/DTLS call and have the endpoint initiate STUN connection checks with two candidates. The STUN checks should overlap in the following manner:

• A Binding Request from candidate 1 (C1) received at the SBC, the SBC replies with a Binding Success Response to C1 and initiates a Binding Request to C1.
• A Binding Request from candidate 2 (C2) received at the SBC, the SBC overwrites the stored candidate with C2, sends a Binding Success Response to C2 and initiates a Binding Request to C2.
• The SBC receives a Binding Success Response from C2 and sends a new Binding Request with the USE-CANDIDATE attribute to C2.
• At this moment, the SBC receives a Binding Success Response from C1.

The code is modified to:

1. Avoid updating the nominated candidate list if we already sent out BREQ or BREQ_UC.
2. Not to send BREQ during the window where the SBC has switched from sending BREQ to BREQ_UC.
3. Wait for timer to be fired before resending BREQ.

Workaround: None.

The Azure-SWe SLB reboots as a result of memory corruption.

Impact: The Azure-SWe SLB reboots as a result of memory corruption.

Root Cause: A memory corruption issue produces a memcpy into a buffer that isn't large enough. This memcpy is in code related to the SLB function.

Steps to Replicate: The steps cannot be reproduced.

The code is modified to verify the buffer size before the memcpy.

Workaround: None.

A potential SRTP encryption issue that may lead to one-way audio in media NAT scenarios

Impact: While debugging SRTP call logs collected from a customer's network, a potential risk is noticed that random values read from RID's memory block can be used as new SRTP sequence number and roll-over counter (SSN/ROC) when RID is enabled. If it happens, customers may experience one-way audio due to remote peer's anti-replay protection discarding SRTP packets or the remote peer's inability to decrypt SRTP packets.

Root Cause: The problem is triggered by NAPT timer expiry and the XRM notification to NRMA with previously learned remote IP address and port number.

Steps to Replicate: There are no exact steps to test this.
It is suggested to:

1. Run SRTP regression tests.
2. Perform SIP registrar switchover while running SRTP calls.

The code is modified to clear out previous saved remote IP address in XRES's SRTP/SRTCP encryption/decryption configuration to set correct SSN/ROC values in RID enable command.

Workaround: None.

The SBC is adding phone-context=private for a globalized number in the RURI and To Header.

Impact: The SBC adds phone-context=private in the RURI for a globalized number when it is modified using a DM rule.

Root Cause: Using a DM rule to add '+' in called number does not result in number being treated as globalized.

Steps to Replicate: Configure the DM rule to add a '+' sign. Run SIP-SIP call. The SBC sends a INVITE with globalization in RURI and has phone-context=private.

Do not add phone-context=private in the RURI when the RURI is already in globalized format, including when the userpart of globalization number has a '+' sign.

Workaround: Disable DM rule or use SMM to delete the phone-context parameter.

The SBC fails to recognize the Prack in a multi-dialog (different TO tags) if an 18X and 200(Inv) are received simultaneously.

Impact: For a dialog transparency and forked call, the SBC may reject the Prack request due to race condition of back to back 18x and 200OK messages.

Root Cause: After receiving a 200OK message, the SBC finalizes the active remote tag and queues up the send packet to the ingress due to a pending Prack. When the Prack is received, the SBC rejects it because the compare for the Prack comes from a different remote tag than the one already stored in the 200OK message.

Steps to Replicate: 

1. Configure the dialog transparency, forking, and E2E Prack to enable.
2. Leg A calls Leg B.
3. B1, B2 answer 18x
4. B2 18x, B1 200OK(no SDP) (back to back)

The code is modified to validate the remote tag based on the forking list not the final one.

Workaround: Disable the Prack.

The SBC in a TLS Client role does not verify the peer's certificate if authClient is set to "false"

Impact: The SBC in a TLS client role does not verify the peer's certificate if the authClient flag in the tisProfile is set to "false".

Root Cause: The issue is caused by an invalid configuration. For an SBC in SIP Peering environment, the recommended value of the authClient flag is "true". For an SBC in SIP Access environment, the recommended value of the authClient is "false".

In a SIP Peering case, the tlsProfile's authClient may be set to "false" inadvertently and the SBC in a TLS client role does not verify the peer's certificate.

Steps to Replicate: 

1. Configure SIP-TLS in Peering case with authClient=false without configuring the peer's certificate chain's Root CA in the SBC.
2. Attempt to make a SIP-TLS call to peer.

The TLS session is established without verifying peer's certificate chain.

The code is modified to verify the peer TLS server's certificate when the SBC acts as a SIP-TLS client, irrespective of the authClient setting.

Workaround: Correct the configuration by setting authClient to "true" in SBC Peering case.

The SCM Process was leaking a resource related to a NRMA sessPtr.

Impact: The SCM process may leak memory in some early call failure scenarios.

Root Cause: In early call failure scenarios, a different function is called to free the Call Block (and the memory linked off of it) than the function that frees the Call Block in successful call scenario.

The function that is called in some early call failure scenario was not freeing all of the memory that had been allocated for the call.

Steps to Replicate: The steps cannot be reproduced.

The code is modified so that all the memory that is allocated for a call is freed in all early call failure scenarios.

Workaround: None.

RtmSbyIcmHandle PRS cores, standby PRS cores when modifying IP Header

Impact: Standby PRS process cores in 1 to 1 HA mode.

Root Cause: The standby BRM mirrors modified IP hdr structure to standby.

Steps to Replicate: There are no steps to recreate the PRS core.

The code is modified to check redundancy mode and set mirroring flag accordingly since XrmFlowChange() can be invoked from active and standby context. The BRM mirroring function was originally invoked from XrmFlowChange().

Workaround: None.

A 300 response with embedded Identity header size of over 512 bytes in the contact is discarded with Force-Requery Redirection

Impact: The SBC drops embedded Contact header in 3xx responds when larger than 2k bytes.

Root Cause: Currently buffer support for embedded header is too small (max = 2k bytes).

Steps to Replicate: 

1. Enable embedded header in 3xx.
2. Egress responds to 3xx with embedded header size large.

The code is modified to increase buffer support up to 6,000 bytes.

Workaround: None.

The remote DTLS/SRTP Peer discards the SRTP packets due to an unexpected increase in ROC encryption. 

Impact: There is a one-way audio issue on the DTLS/SRTP call leg after an INVITE is sent with Replaces on the RTP call leg.

Root Cause: When the SIP registrar switched over, it signaled a call hold combined with an INVITE with Replaces method to modify the media path. The call was put on hold and existing Ethernet Resource (XRESs) and Bus Resources (BRES) were deactivated. A new BRES with new RID was allocated and replaced the previous BRES. Before activating the new BRES, Ethernet Resource Manager (XRM) calculated the new SSN/ROC based on XRES's saved SSN/ROC. But in the calculation, the XRM incorrectly increased ROC value which caused one way audio after the call is re-activated. 

Steps to Replicate: The steps are not reproducible. 

The code is modified to correct the resource allocation logic in XRM.

Workaround: None.

The "EMA - System Administration - File Upload" does not allow a .pfx certificate file to be uploaded.

Impact: The EMA does not support the uploading of a certificate file with a .pfx extension through the "EMA - System Administration - File Upload" page.

Root Cause: There is no requirement to allow a file to be uploaded with a .pfx extension, hence the support for the same is not available.

Steps to Replicate: 

1. Log into the EMA.
2. Navigate to the "System Administration - File Upload" screen.
3. Select a file with a .pfx extension.
4. Upload the file.

The upload of the file will be successful.

The code is modified to allow a file with a .pfx extension to be uploaded.

Workaround: The file has to be manually copied to the SBC through the SSH.

A duplicate MIME-Version header is added on a SIP over Core call.

Impact: A duplicate MIME-version header is added by the SBC when an incoming INVITE already has the MIIME-version header.

Root Cause: When the SBC encounters MIME content it adds the MIME-version by default. When an unknown header transparency is enabled at the egress IPSP and the incoming message has a MIME version header, it is transparently passed to the egress. This results in A duplicate MIME-version header at the egress side.

Steps to Replicate: 

1. Setup a basic SIP-SIP call.
2. Send an INVITE message having the MIME content and MIME-version header.
3. Enable a PIDF transparency at the ingress IPSP.
4. Enable the PIDF and an unknown header transparency at the egress IPSP.
5. Verify if a duplicate MIME-version header is present inthe  egress INVITE.
   This can be tested without sending the MIME-version in the INVITE as well.

The code is modified to check for the MIME content and the MIME-version header.  If there is an unknown header transparency then it is not added it to message. Only the MIME-version will be added by the SBC.

Workaround: None

An incorrect DSP insertion/rejection reason can be seen recorded in the ACT record in the case of an incomplete offer/answer.

Impact: An incorrect DSP insertion/rejection reason is the result of an incomplete offer/answer. 

Root Cause:

Example:

1. A T.38 is present in the Leg A and Leg B in the PSP.
2. The egress peer rejects the offer.
3. A 4xx message attempt record is updated with the DSP reject reason as "Call Rejected Unlicensed."

In the problem scenario where the T.38 is enabled as transcodable codec during an initial offer/answer, the SBC is not able to find the heaviest transcodable codec. The setting for the dspRejectionReason is "Rejected codec unlicensed".

Steps to Replicate: 

1. Set up a basic SIP-SIP call configuration using the PSX.
2. Enable the T.38 and G711 u in Leg A and Leg B in the PSP .
3. Check the CDR and verify the DSP Rejection Reason.

The code is modified to update the dspRejectionReason to "Rejected codec unlicensed" for only the cases where the license is unavailable .

Workaround: None

Log is incorrect when using regex to filter value to be stored.

Impact: After adding an SMM rule for a value to a variable, there is a logging problem only - the wrong value is being written in the DBG log.

Root Cause: Logging the wrong data.

Steps to Replicate: Configure the SMM rule to store a value to a variable and look for the debug log message: "SipsMmUtilStoreValue ..."

The code is modified so the data log is stored to a variable correctly.

Workaround: Ignore the logging message.

Parsing the ttc-charging-params in the P-Charging-Vector only succeeds if the parameters have a certain order.

Impact: Parsing of ttc-charging-params in P-Charging-Vector succeeds only if the parameters have a certain order.

Root Cause: The issue is with the contractor parameter that is also picking up all subsequent parameters.

Steps to Replicate: 

1. Run incoming ttc-charging-params in P-Charging-Vector.
2. Run subsequent parameters after the contractor param.

All the subsequent parameters are ignored.

The code is modified to correct the Contractor parameter to be telephone number only.

Workaround: Use the SMM to reorder the parameters.

ASAN : ERROR: AddressSanitizer: SEGV on unknown address 0x000000000004.

Impact: While generating early attempt CDR records, the code was trying to read ingress remote gateway information that was not available and this resulted in trying to deter a NULL pointer.

Root Cause: The code did not account for an edge case scenario where ingress remote gateway information was not available and tried to access a NULL pointer, which can result in a coredump.

Steps to Replicate: Run some call scenarios where the incoming call is queued and then processed later.

The code is modified to check if the pointer is valid before trying to read from it.

Workaround: Disable early attempt CDRs to avoid this issue.

The LDG goes down and triggers ARS - IP ACL.

Impact: The XRM debug command failed to dump static discard ACL stats.

Root Cause: The existing logic only dumps maximum 100 entries of each allocated ACL list. If a user has more than 100 allocated ACL list in admit TCAM ACL list, then the entry 101 to 200 is dumped for next category of ACL list, and so on.

Steps to Replicate: 

1. Configure a set of SIP sigPorts.
2. Unhide debug command.
3. Issue a command "request sbx xrm debug command acl\ -stat", or "request sbx xrm debug command acl\ -cfg\ 50"

The code is modified to:

1. Return the count of allocated ACL list.
2. Specify number of entries to display, which is limited to <= 100. If user does not specify the number of entries, then we will default to 100.
3. Display allocated ACL rules of each category, either from the beginning of the list, or continue from last entry of previous request.
4. Have the user repeat the request multiple times to reach the end of the list. 

The change applies to both ACL config and stats.

Workaround: Configure less than 10 signaling ports.

The SBC is not sending message over IP Sec tunnel to UE when UE idles around one hour.

Impact: In IMS AKA connections, the SBC was sending a response to UE in clear when UE switched communication from UDP to TCP

Root Cause: The SBC was not opening IMS AKA ports for TCP communication when initial registration happened over UDP

Steps to Replicate: Run initial registration over UDP. Send INVITE/PRACK over TCP and UDP. Repeat the test with initial registration over TCP.

The code is modified to allow communication on both UDP and TCP irrespective of whether initial registration was on UDP or TCP.

Workaround: None.

G722 is in 183/200 SDP to ingress peer but 711U audio packets sent

Impact: When the SBC is playing tone and in subsequent response the Codec is changed, the SBC is not sending updated codec toward Ingress.

Root Cause: When the codec is changed in 183 after 180 w/o SDP, the SBC sends old codec in 183 and tries to send the updated codec in the Update. However, since offer answer is not completed the SBC queues the update. After 200ok the SBC should release the queued SDP. However, in the earlier release the queued SDP was not released

Steps to Replicate:

1. Invite is received with multiple codec i.e ( 0 18 8 9 102 101), the SBC sends Invite toward egress.
2. From egress 180 without SDP is received, the SBC starts playing tone in G722 codec.
3. From egress 183 is received with new codec i.e(0), the SBC sends 183 with SDP with old codec (G722).
4. 200ok with SDP(0) is received from egress.

The SBC should trigger re-INVITE toward ingress with updated codec (g722).

The code is modified to release the queued SDP when 200ok is received

Workaround: None.

Uploading a .p12 file through the Configuration --> Security Configuration --> Commands --> Upload Certificate logs the user out.

Impact: Uploading a .p12 certificate through the "EMA - Configuration - Security Configuration - Commands - Upload Certificate" results into logging out the user and failing to upload the certificate.

Root Cause: The CSRF token was not passed in the certificate upload request. Due to this, the upload request was rejected and the user is logged out.

Steps to Replicate:

1. Login to EMA.
2. Navigate to Configuration --> Security Configuration --> Commands --> Upload Certificate screen.
3. Select a certificate file to upload.
4. Click Save.
5. The upload should be successful.

The code is modified to pass the csrf token in the certificate upload request.

Workaround: Upload the file through the Administration --> System Administration --> File Upload --> Add Files to Queue --> Upload All Files.

LeakSanitizer error found in sanitizer.CE_2N_Comp_ScmProcess_0,1,2,3

Impact: The SBC leaks a small amount of memory while loading the ISUP signaling profile from CDB.

Root Cause: The functions which read the ISUP signaling profile from CDB were allocating memory to store the information before storing internally and did not free up the memory at the end of processing.

Steps to Replicate: This issue was only observed while testing with an ASAN enabled build as the amount of memory leaked is so small.

The code is modified to make sure that memory is correctly freed at the end of reading the ISUP signaling profile information from CDB.

Workaround: None.

LeakSanitizer: detected memory leaks.

Impact: The SBC was leaking memory while processing MTRM configuration data.

Root Cause: While processing the MTRM configuration, the SBC was reading data to internal memory for validation and not freeing up the memory at the end of the validation process.

Steps to Replicate: Run various MTRM configuration changes and check there are no memory leaks.

The code is modified to make sure the configuration validation memory is correctly freed up at the end of processing.

Workaround: None.

The SCM Process cored during call execution of re-INVITE/UPDATE call scenarios.

Impact: The SCM process was coring during re-INVITE/UPDATE call scenarios.

Root Cause: The code was trying to update packet ccb information, resulting in the dereferencing of a NULL pointer and a coredump.

Steps to Replicate: Re-run a selection of re-INVITE/UPDATE test cases to confirm no coredump occurred.

The code is modified to ensure that the pointer is not NULL before dereferencing the pointer to avoid a coredump.

Workaround: None.

PortFix SBX-118373: There was an Active SBC 7000 DNS Process core.

Impact: The DNS Process on the active CE on a system switchover may coredump.

Root Cause: A NULL DNS TCB (transaction control block) was encountered while the Active CE was shutting down (during restart).

Steps to Replicate: The steps cannot be reproduced.

The code is modified to guard against using a NULL DNS TCB.

Workaround: None.

PortFix SBX-110756: Wrong behavior with sipAdaptiveTransparencyProfile enabled.

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

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

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

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

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

Workaround: None.

PortFix SBX-117280 to 8.2.5R007: Apache Axis security issues

Impact: The following vulnerabilities related to Apache 1.2 were identified with in the Ribbon SBC application:

Issue 1: The LI uses unsupported Apache Axis 1.2 (2005) on JBoss 5.1 (2009).

Issue 2: The LI exposes the Apache Axis AdminServlet without authentication (default for Axis 1.2).

Issue 3: The LI runs as the sonusadmin user, a privileged account.

Root Cause: The LI uses unsupported Apache Axis 1.2 (2005), exposes the Apache Axis AdminServlet without authentication and runs as the sonusadmin user, a privileged account.

Steps to Replicate: 

1. Access the url https://{SBC hostname}/liTargetProvisioning/services/AdminService from the browser.
   1. Result: An Axis error "No service is available at this URL" is displayed.
2. Access the url https://{SBChostname}/liTargetProvisioning/services/AdminService?wsdl from the browser.
   1. Result: An Axis error "Could not generate WSDL! There is no SOAP service at this location" is displayed.

The Apache Axis cannot be upgraded to version 1.4 for issue 1 due to the following:

The Axis 1.2 has 3 vulnerabilities CVE-2018-8032, CVE-2014-3596 and CVE-2012-5784 and the SBC application is not impacted by any of these.

Axis 1.4 has four vulnerabilities (3 from version 1.2 plus 1 new) out of which CVE-2019-0227 (this is the new one in version 1.4) could impact the SBC application.

As a result, for issue 1 no fix is required.

For issue 2 and 3, the code is modified to remove the AdminService.

Workaround: None.

PortFix SBX-117293: Unable to import a large SSL certificate to the standby node

Impact: Unable to import a large SSL certificate to the standby node.

Root Cause: Certificate was not getting restored on standby as its content was getting corrupted due to bufferoverflow.

Steps to Replicate: 

1. Import certificate with large DER content (more than 6400 bytes) and verify that action is aborted and user is presented with error.
2. Create a local-internal certificate with subjectAlternativeDnsName of size 512 chars to 4096 chars.

The code is modified to add validation to prevent bufferoverflow. Increased size of subjectAlternativeDnsName entries to 4096 chars.

Workaround: None.

PortFix SBX-112042: The SAM hangs and crashes during a correct switchover attempt.

Impact: After a switchover, the SAM process was not being terminated correctly.

Root Cause: SIPCM Terminate was taking longer time than AMF specified time value of two minutes and as a result, the AMF was forcefully aborting the SAM process.

Steps to Replicate: 

1. Launch the SBC HA.
2. Run the mix load.
3. Perform a switchover.

Incremented the AMF terminate timer from 2 min to 4 min for SAM process.

Workaround: Run the below cmd to increase the AMF timer value without any code changes.
removeenv.pl -n TERMINATE_TIMEOUT sam
addenv.pl -n TERMINATE_TIMEOUT -v 240000 sam

PortFix SBX-111141: The SBC 7000 softwareUpgradeStatus shows invalid characters for upgradeCompleteTime

Impact: After performing an upgrade, the upgradeCompleteTime field was not getting populated with the correct value. 'upgradeCompleteTime' showed invalid characters.

Root Cause: A variable ‘tmp’ defined within SonusSmSoftwareUpgradeCsv::populateTime has a pointer reference to SonusSmSoftwareUpgradeCsv::setSoftwareUpgradeCompleteTime function. Since ‘tmp’ variable’s scope was limited to SonusSmSoftwareUpgradeCsv::populateTime we were getting corrupted value when we access that in SonusSmSoftwareUpgradeCsv::setSoftwareUpgradeCompleteTime.

Steps to Replicate: Perform an upgrade and check upgradeCompleteTime through the CLI command:
show table system softwareUpgradeStatus

The code is modified by making the ‘tmp’ variable a static variable, so that gets allocated for the lifetime of program.

Workaround: None.

PortFix SBX-116240: EMA TLS profile certificates handling is not working properly.

Impact: The EMA TLS profile certificates handling is not working properly.

Root Cause: The EMA TLS profile certificates were not getting restored if incorrectly configured.

Steps to Replicate: Try configuring EmaTlsProfile clientCaCert and serverCert incorrectly:

1. Set remote cert as serverCert.
2. Set local cert as clientCaCert.
3. Verify that validation fails and user is prompted.

The code is modified to perform validation to ensure user doesn't configure emaTlsProfile.

Workaround: Reconfigure EmaTlsProfile with correct certificate types for clientCaCert (remote) and serverCert (local/local-internal).

Microsoft Azure reserves port 65330.

Impact: Some DNS queries fail to get a response in an Azure deployment. 

Root Cause: Microsoft does not allow VMs to use port 65330. The DNS queries are sent using this local port  and are dropped.

Steps to Replicate: Run DNS queries for a long period of time and check that port 65330 is not used.

The code is modified to mark port 65330 as reserved.

Workaround: The linux configuration can be manually updated to reserve the port. 

1. The following actions need to be run as root on the SBX.
   echo '5041,5043,65330' > /proc/sys/net/ipv4/ip_local_reserved_ports
2. Edit the following line in /etc/sysctl.conf
net.ipv4.ip_local_reserved_ports=5041,5043
   to append “,65330”
net.ipv4.ip_local_reserved_ports=5041,5043,65330
3. There is no need to reboot.

PortFix SBX-117921: A de-reference a NULL return value.

Impact: The SCM process allocates a null pointer resulting in a crash.

Root Cause: While trying to remove the EVS codecs from a call with a leg associated to the MRF/MRFP, the associated call leg is removed due to a race condition and the code dereferences a NULL pointer.

Steps to Replicate: The steps cannot be reproduced.

The code is modified to defend against the race condition and validates that the associated call leg pointer is not NULL before dereferencing it to avoid a coredump.

Workaround: None.

PortFix SBX-119262: ednsPayloadSize value is not applicable after S-SBC switchover

Impact: The ednsPayloadSize value is not taking effort following a switchover.

Root Cause: The SBC was missing code to restore the ednsPayloadSize value in an N:1 configuration.

Steps to Replicate: Assign a value to the ednsPayloadSize of the DNS configuration check that it is taking effect and then perform multiple switchovers and check that the configuration is still taking effect:

set global servers dns global ednsPayloadSize <512-4096 bytes>

The code is modified to correctly restore this configuration value.

Workaround: Following a switchover, the operator needs to remove and reapply the edns configuration value.

PortFix SBX-118109: EMA: Terminate call is not working from EMA

Impact: Terminate call command is failing from EMA

Root Cause: When terminate call operation is performed, the terminate call xpath is encoded by the UI and sent to the backend. The backend, however was not decoding the xpath due to which the operation was failing.

Steps to Replicate:

1. Run a long duration call (approximately for two mins or more).
2. Log in to EMA and go to All->Address Context ->Call Media Status Detail and note the GCID.
3. Click on All->Global and from commands, drop down select Terminate Call and give the value of GCID in the popup.
4. Click on terminateCall.

The call should get terminated

The code is modified to decode the xpath in the backend.

Workaround: No workaround.

PortFix SBX-113593: Observed that callResources are not properly clearing after the call is complete.

Impact: In a DSBC setup with multiple nodes in the T-SBC cluster, for the initial INVITE processing, resources (DSP, public xres and private xres) were allocated from TSBC1 (for codecs G729 on offer leg, G711 on answer leg). After receiving an answer with 729, the resources from TSBC1 were cleared up properly and the new resources allocated on a TSBC2 for G729 on leg0 and G729 on leg1, with priv xres(s) cleared up since it is a single DSP call. The call turns to be G729-G729 transcode.

Upon receiving a re-INVITE with G711, resources (dsp+priv xres+public xres) were allocated from TSBC1, and upon receiving answer (200OK) from UAS, new resources were allocated from another TSBC (TSBC2). Before activating these new resources from TSBC2, the TSBC1 resources on the call leg have to be deallocated. However, this was not being done correctly.

Root Cause: While freeing up resources for initial offer-answer on TSBC1, an incorrect resource mask (only dsp, and not the public/private xres) was being set in the deallocation command by SSBC to TSBC1. This resulted in the call structure on TSBC1 being held despite the call being terminated and resources being freed.

Steps to Replicate: Set up:

Run D-SBC with multiple nodes in TSBC cluster.
Route the PSP has codecs in order- G711, G729.

Scenario:

1. Make a UAC-SBC-UAS call where initially call is established as G729-G729 transcode call with PSP setting is transcode only and G711.
2. Send a re-INVITE through the UAC by changing codec to G711U call with transcode flag is transcode only.
3. Observe if there are any hung resources/active call count in the callResourceDetailsStatus / callCountStatus after a call has terminated.

The code is modified to reduce the number of DSP re-allocations between TSBCs by not allocating fresh DSPs for every new offer, unless absolutely required. This is achieved by performing the following tasks:

1. Setting the correct resource mask (dres+priv xres+public xres) in the deallocate command from the S-SBC to the T-SBC to free resources on the T-SBC.
2. Prevent the codec capability mask from being overwritten during reallocation based on answer (The codec mask for answer is frequently a subset or partial mask of that in the initial offer). This retains the codec capability mask set during previous offer-answer and retains the old DSP resource if it is capable in servicing the new offer instead of going for new resource allocation just because of the restricted capability mask set during answer processing.

Also, while deallocating resources on the T-SBC from the earlier offer-answer,
in the current working context, the S-SBC structure holding details of the resource being freed that includes the TSBC node gcid, node IP, and resource info pertaining to the DSP, private xres and public xres, is set to NULL if it is also referenced in any other existing contexts. This is to prevent the private xres also referenced in another context from being incorrectly freed.

Workaround: None.

PortFix SBX-117948: Deletion of a SMM Profile with 768 rules is failing.

Impact: Deletion of a SMM Profile with 768 rules is failing

Root Cause: There was a restriction of 1000 transactions per commit to avoid health check issues leading to failure while deleting SMM profile with large number of rules.

Steps to Replicate: Validate that deletion of SMM profile with 768 rule succeeds.

The code is modified as the operation was already being performed by disabling the healthcheck timeout for the duration of operation.

Workaround: No workaround.

PortFix SBX-116605: The SBC does not log SIP messages to the TRC file when routing calls using the DNS Lookup.

Impact: The SBC does not log SIP messages to the TRC file when routing calls using the DNS Lookup.

Root Cause: During a DNS lookup, the LogInfoSpec is not set with the proper logging details in the SIPCall data structure.

Steps to Replicate: Make a call from the Ingress side with the DNSLookup enabled. Post the call as successful and check the TRC file.

The code is modified to address the issue.

Workaround: None.

PortFix SBX-118922: There was a problem on the EMS SBC Manager's SIP Active Register Name Status List.

Impact: There was a problem on the EMS SBC Manager's SIP Active Register Name Status List.

Root Cause: The SBC browser reloads the screen when clicking the search button. On a reload functionality check for previous search text, if any available it will trigger search button. As a result, this loops continuously. 

Steps to Replicate: 

1. Log in to the EMA.
2. Navigate to All -> Address Context -> SIP Active Register Name Status.
3. Enter search text and click the Search button.

The page returns an entry according to the search text. The page does not refresh (loop).

The code is modified to stop the default browser behavior by clicking the Search button.

Workaround: No workaround.

PortFix SBX-116335: The SBC EMA presents only the SSL server certificate, instead of the full certificate chain.

Impact: The SBC EMA/PM web server isn't sending the full certificate chain while negotiating the TLS with clients.

Root Cause: The SSLCACertificateFile option is commented in SBC which makes the EMA/PM server send only its serverCertificate to the clients.

Steps to Replicate:

1. Initiate the TLS connection from the browser to the SBC EMA/PM server and capture packets using Wireshark on the client.
2. The CA certificate does not show up in the packets.

The code is modified to add the SSLCACertificateFile option. Now the EMA/PM web servers will send the CA certificate along with the server certificate during TLS negotiations.

Workaround: None.

PortFix SBX-114056: An RTCP goodbye message is sent after a 183 RESPONSE.

Impact: When monitoring a profile is enabled with an early media configuration, the early media from the endpoint is triggered. The
RTCP Bye packet is sent with the SSRC of the endpoint. The media continues with the same SSRC, resulting in issues because it is not compliant to the RFC.

Root Cause: The indication to stop monitoring is passed as soon as the early media is received. The deactivation and reactivation of resources cause it to send the RTCP bye packet with the SSRC. The SSRC is received from the endpoint.

Steps to Replicate:

1.  Configure monitoring profile with an early media authorization (EMA) flag enabled and the RTCP gen.
2. Configure the early media and create scripts with the P- early media supported.
3. The UAC sends an invite with the p-early media supported,
4. The UAS sends a 183 with a SDP that has a local PRACK and media with the SSRC1.
5. The UAS sends a 200 OK and media with the SSRC1.

The RTCP bye packet is suppressed for early media when the endpoint is playing the media.

Workaround: Disable the monitoring profile.

PortFix SBX-118050: The TERM IOI value has not returned in 18x/200 OK to the caller as expected in the IPX PCV header management.

Impact: Part of a feature introduced in the SBC Core 9.2.3 release contained these requirements:

Customer network

1. All messages toward the customer MUST be sent with a PCV header and use provisioned ioi values.
2. ioi in the PCV header will be the customer's assigned value for the PARTNER generating it.
3. When messages from PARTNER have a PCV with ioi, the ioi needs to be overwritten with the customer assigned PARTNER value.
4. Messages from the SBC may have a PCV but without ioi params in it.

Partner network

1. PCV may/may not be received from PARTNER with/without ioi params
2. PCV is not sent toward PARTNER in most cases but some PARTNER networks may want this in the future
3. So, this needs to be configurable and where applicable, provisioned ioi values used in the PCV in messages to the PARTNER
4. However in testing, when the far end is not set to sendPCV, the 18x/200 OK back to the Ingress trunk does not get sent the Term-IOI value, only the Orig-IOI in the 18x/200 OK. However, on the 200 OK from the BYE there is both Term/Orig IOI.

Ingress TG:
generateOrReplacePCV {
state enabled;
origIOI orig.Server.iqntipx;
termIOI term.Server.iqntipx;
sendPCVHeader enabled;

Both SIPCORE TGs.
generateOrReplacePCV {
state disabled;
sendPCVHeader enabled;

Egress TG:
generateOrReplacePCV {
state enabled;
origIOI orig.cust.iqntipx;
termIOI term.cust.iqntipx;
sendPCVHeader disabled;

A Call Flow Partner Peer PARTNER TG on the SBC TG on the SBC peer
4 <------- INVITE w/o PCV -------
-------- 18x w/o PCV ---------> <------------ INV w/o PCV ----------
---- 18x w [PCV w prov term-ioi] -→

Root Cause: The following configuration must be enabled:

Ingress TG:
generateOrReplacePCV {
state enabled;
origIOI orig.Server.abcdefg;
termIOI term.Server.abcdefg;
sendPCVHeader enabled;

Both SIPCORE TGs.
generateOrReplacePCV {
state disabled;
sendPCVHeader enabled;

Egress TG:
generateOrReplacePCV {
state enabled;
origIOI orig.cust.abcdefg;
termIOI term.cust.abcdefg;
sendPCVHeader disabled;

The issue is noticed for the following call flow:

Call Flow Partner Peer PARTNER TG on the SBC TG on the SBC peer
4 <------- INVITE w/o PCV -------
-------- 18x w/o PCV ---------> <------------ INV w/o PCV ----------
---- 18x w [PCV w prov term-ioi] -→

Steps to Replicate: The issue can be replicated by configuring the following:

Ingress TG:
generateOrReplacePCV {
state enabled;
origIOI orig.Server.abcdefg;
termIOI term.Server.abcdefg;
sendPCVHeader enabled;

Both SIPCORE TGs.
generateOrReplacePCV {
state disabled;
sendPCVHeader enabled;

Egress TG:
generateOrReplacePCV {
state enabled;
origIOI orig.cust.abcdefg;
termIOI term.cust.abcdefg;
sendPCVHeader disabled;

The issue is noticed for the following call flow:

A Call Flow Partner Peer PARTNER TG on the SBC TG on the SBC peer
4 <------- INVITE w/o PCV -------
-------- 18x w/o PCV ---------> <------------ INV w/o PCV ----------
---- 18x w [PCV w prov term-ioi] --->

The code is modified so when the generateOrReplacePCV functionality is enabled, carry forward the data like the original ioi, icid, etc. in the call block. This is used while processing 18x/200 OK and appropriately adds Term-IOI if configured and when sendPCVHeader is enabled.

Workaround: Enable sendPCVHeader on both trunk groups.

PortFix SBX-117119: The removeSavedConfig does not delete a saved config file unless 'show table system savedConfigList' is called beforehand.

Impact: The removeSavedConfig does not delete a saved config file unless 'show table system savedConfigList' is called beforehand.

Root Cause: When savedConfig and removeSavedConfig called one after the other, the internal list did not have the path to delete the file.

Steps to Replicate: 

1. Run the Saveconfig.
2. Run the removeSavedConfig.

The code is modified to update the internal list with path and file name.

Workaround: Before calling the removeSavedConfig, call the "show table system savedConfigList"

PortFix SBX-115853: The SBC sent an UPDATE with payload (128 101) that caused calling party to fail the call.

Impact: This is a SIP-GW1-GW2-SIP call. The issue is GW1 sends an UPDATE to client for codec G.729 but Payload Type as 128.

Root Cause: UPDATE is sent by GW1 to ingress because at ingress, there was Tone and Announcement profile configured and playing the Tone triggered by an UPDATE.

An UPDATE was sent to client with G729 as G729 was the first codec offered by Server in it's UPDATE message, as the Honor Remote Precedence flag was enabled in Ingress GW's PSP. The G729 PT is updated with wrong value of 128 instead of 18 in the NRMA code. The selected codec's rx PT was assigned with tx PT that contained invalid PT.

Steps to Replicate: 

1. Set up a SIP-GW-GW-SIP call.
2. Set up Tone and Announcement in Ingress GW TG.
3. Set Honor Remote Precedence flag enabled in Ingress TG PSP.
4. Sent an UPDATE from server with a codec other than G711 and a codec which is different from previously negotiated codec.
5. An UPDATE should be sent to client with correct PT.

The code is modified with a valid PT value.

Workaround: Set the Honor Remote Precedence flag disabled.

PortFix SBX-101758: There was an issue regarding field Ingress Codec inside the CDR for some calls with CLEARMODE.

Impact: The SIPI INVITE call fails when CLEARMODE as CODEC feature is enabled.

Root Cause: The call failed as CLEARMODE in the PSP was becoming NULL.

Steps to Replicate: Run the CLEARMODE as CODEC enabled and PSP has CLEARMODE as entry.

Test steps:

1. Use the SIPI scripts.
2. Enable ClearModeAsCodec flag in both ingress and egress TG. Add a CLEARMODE codec in ingress and egress PSP.
3. Use the scripts and make a SIPI-SIPI call.
4. The call should connect and CDR should be populated as DATA, CLEARMODE (P:71:0).

Tests can be done to verify different call flows:

1. SIPI-SIPI call with ingress offers CLEARMODE, Egress responds CLEARMODE.
   expected output: CDR and Call media status cli command should show data and CLEARMODE.
2. SIPI-SIP call with ingress offers CLEARMODE, Egress responds CLEARMODE.
   expected output: CDR and Call media status cli command should show data and CLEARMODE.
3. SIPI-SIP call with ingress offers CLEARMODE + G711U, Egress responds G711U.
   expected output: CDR and Call media status cli command should show audio and G711U.

The code is modified so that when the CLEARMODE as CODEC is enabled and the SIPI with CLEARMODE is received, the call is processed and the CDR gets updated with CLEARMODE (p:71:0).

Workaround: Not available.

PortFix SBX-114396: An UPDATE to modify AMR-NB to the AMR-WB failed in cases where a multi active TSBC was involved.

Impact: In a multiple T-SBC cluster setup, when receiving a modify offer (ex: with Update/reinvite) to change from a lower codec (AMR-NB) to a heavier codec (AMR-WB), the SBC was reallocating a new DSP to support the heavier codec. This DSP could be from the same T-SBC as the initial offer-answer DSPs (TSBC1), or a different T-SBC (TSBC2). In this case, the new DSP on offer leg was from TSBC2.

While processing an answer leg, the SBC incorrectly chose to reuse the existing DSP though it is from the first TSBC1 instead of TSBC2, the node from which the new DSP for the offer leg is allocated.

Root Cause: While processing the answer leg, when the SBC chooses to either reuse the previously-active DSP on the call leg, or reallocate a new DSP, the SBC did not check the node IP address of the T-SBC (where the DSP on the offer leg was allocated) against the previously-active DSP on the current answer leg.

Steps to Replicate: 

Set up:

1. Set up a D-SBC having multiple T-SBC nodes.
2. Transcode the PSP setting only.

Call flow:

1. Run an initial call after an INVITE, list 183/Prack and UPDATE for preconditions is AMR-NB–AMR transcode. DSPs for this call are from TSBC1.
2. Send an UPDATE to the change codec on egress leg from AMR to AMR-WB.

The DSP on offer leg is from TSBC2.

The code is modified so the SBC compares the node IP address of the T-SBC for a newly-allocated DSP on the offer leg with that of the previously-active DSP on the current answer leg. The SBC reuses the latter only if both of the IPs match; otherwise, a new DSP is allocated, and the previous DSP frees up later on.

Workaround: Run a single T-SBC in a cluster.

PortFix SBX-117279: The SBC init.d script checkForUpgradeRevert() file parsing is forgiving and can facilitate arbitrary command execution.

Impact: One of the scripts on the SBC has a security issue that in a particular scenario can cause potential privilege escalation from sonusadmin to root.

Root Cause: Script was running a marker content without input validation and location of marker was not secure.

Steps to Replicate: This code block gets executed only when an upgrade from version which has single debian root partition to three partition model. It is not applicable for any 6.0 or later installations.

The code modified to move the marker to a secure location owned by root and input validation is added in script as a added measure.

Workaround: No workaround.

PortFix SBX-114194:Observing memory leak in ScmProcess of active S-SBC during precondition update call flow

Impact: On the D-SBC, there was a memory leak in the cluster transcoding capability during Update with preconditions call flow.

Root Cause: On the D-SBC, the reference to cluster transcoding capability held in the current working PSP context was being lost, hence leading to memory leak.

Steps to Replicate: Run an Update with preconditions call flow on a D-SBC setup and monitor the memory on the active S-SBC node. Without the fix, there would be an increase in the memory usage of SCM Process indicating a memory leak.

The code is modified to avoid losing a reference to the current working PSP context cluster transcoding capability memory, by saving it to the pending Ack PSP context and ensuring to free this memory during the offer answer processing.

Workaround: None.

PortFix SBX-118108: The SBC is not sending SDP offer in outgoing INVITE with all the codecs that are configured in PSP.

Impact: The SBC is not sending out INVITE with all configured codecs (passthru + transcodable) when Audio + Text is received.

Root Cause: The issue only occurs when the D-SBC ( S/M/T ) set up receives an INVITE from Ingress peer with Audio and T.140 stream.

During offer processing, the SBC was checking the transcode capabilities for both Audio and text stream, causing this issue.

Steps to Replicate: 

1. Configure multiple codecs in Ingress and Egress PSPs.
2. Send multiple codecs in INVITE from Ingress Peer. (Audio + Text )
3. The SBC should sent all passthru and transcodable codecs configured in the PSP to Egress Peer.

The code is modified to address the issue.

Workaround: None.

Portfix SBX-114693: Need to Update all the Application code to set the V6 loopback address.

Impact: The SBC fails to identify an address as loopback address for an IPV6 call

Root Cause: New feature that was added in the 10.1 release exposes this issue.

Steps to Replicate: Run a NATed call from IPV6 end point.

The call must be established successfully and media should flow from EP1 to EP2 through the SBC.

The code is modified so that the SBC identifies the loopback address for an IPV6 call correctly.

Workaround: None.

PortFix SBX-117842: Number Translation criteria was not appearing after importing the file that contains number translation criteria.

Impact: Number Translation criteria was not appearing after importing the file that contains number translation criteria.

Root Cause: This issue is caused by a feature code check-in, in the SBC release 9.2.3.

Steps to Replicate: 

1. Log into the PM.
2. Navigate to Administration --> System Administration --> Profile Import/Export.
3. Click on Export Profile button.
4. Provide a File Name and Select the Type "Number Translation Criteria".
5. Check if all instances of that profile are listed.
6. Select an instance of the profile.
7. Click on the Export button.
8. Delete the profile from Number Translation Criteria.
9. Import the exported file that contains the Number Translation Criteria.

Expected Results: The number translation criteria should appear after the import.

Observed Issue: The number translation criteria is not appearing after the import.

The code is removed from all occurrences policy/SBXPIPE/SbxNumberTranslationCriteriaEntity.cpp

tfpem.serviceDmPmRuleIb.setData((char *)CONFD_GET_BUFPTR(key));
tfpem.serviceDmPmRuleIb.setDataNull(GUISVR_BOOL_FALSE);
tfpem.serviceDmPmRuleIb.setLoaded(GUISVR_BOOL_TRUE);

Workaround: No workaround.

PortFix SBX-115421: Serf Logs and Upgrade marker files are missing from sysDump.

Impact: Serf logs and upgrade marker files were missing from sysDump.

Root Cause: Capturing only specific log files without * regex.

Steps to Replicate: Run sysDump.pl script.

The code is modified to capture all the files including rolled over files.

Workaround: No workaround.

PortFix SBX-117972: While expecting BYE, the SBC is sending an INVITE to egress side.

Impact: The SBC sending a re-INVITE with text stream disabled when the egress EP sends 200 OK with Audio stream alone.

Root Cause: Since, the egress EP sent 200 OK with only audio stream, SBC internally disables the text stream on both call legs that is resulting in triggering of a Re-INV with text stream disabled towards UAS side.

Steps to Replicate: 

1. UAC sends INVITE Audio + Text to the SBC.
2. The SBC sends INVITE Audio + Text to UAS.
3. UAS sends 18x Audio + Text (port=0) to the SBC.
4. The SBC sends an INVITE to MRF server and MRF server responds back with valid Audio and Text Ports.
5. The SBC sends 18x Audio + Text to UAC.
6. UAS sends 200 OK Audio stream alone.

The code is modified so that if the peer already disables any media stream and if the SBC tries to trigger a re-INVITE towards the peer for disabling the same media stream, then suppress the triggering of the re-INVITE.

Workaround: None.

PortFix SBX-116190: Egress congestion handling should only be enabled for the 503 with a retry.

Impact: The SBC was treating 503 with or without Retry-After header as a peer overload scenario. But the SBC should only treat 503 responses with retry-after because those are unambiguously overload related.

Root Cause: The SBC was not verifying for the presence of Retry-After header to consider it as a peer overload scenario.

Steps to Replicate: Send a 503 with Retry-After header for a SIP INVITE.

The code is modified to address the issue.

Workaround: None.

Portfix SBX-117985: DSP Reload: Active SBC went down when dsp coredump was issued

Impact: Manual DSP coredump initiated via CLI fails to collect core-dump and initiates switchover in case of the SBC 5400.

Root Cause: While initiating manual DSP coredump, the DSP should be notified to copy the concerned memories to core-dump section for core-dump collection to happen successfully.
In case of the SBC 5400, sending of notification to DSPs were skipped due to non-support.

Steps to Replicate: * SBC 5400 with at least one DSP card.

1. Once the application is active, assuming DSP card to be present in slot #1, issue manual DSP core-dump command.
2. Enable debug commands (unhide debug).
3. Execute the following command.
4. Request an SBC drm debug command "dspcoredump dsp 1".

The code is modified to add support for SBC 5400 to notify DSP in case of manual DSP core-dump initiated through the  CLI.

Workaround: None.

PortFix SBX-90704: Ingress octets sent/egress octet rcvd for T.38 calls

Impact: When stopping CDRs for T.38 calls, the Ingress octets sent and received values are not correct.

Root Cause: For T38 packets, NP calculates incorrect packets when there is no RTP header for the T38 and as a result, some packets may be less than 12 bytes.

Steps to Replicate: Stop CDRs for T.38 calls. 

The code is modified to address the issue.

Workaround: None.

PortFix SBX-118302: MS TEAMS to PSTN call failed when SILK codec is enabled.

Impact: An MS TEAMS to PSTN call failed when SILK codec is configured and the lockdown preferred codec IPSP flag is enabled.

Root Cause: When the lock down preferred codec IPSP flag is enabled, one of the codec attributes related to the payload type is not copied properly during an auto answer on the egress call leg. As a result, the call is terminated.

Steps to Replicate:

1. Enable "Lock down Preferred codec" flag on the egress trunk.
2. Configure the packet service profile with "Transcode only" option.
3. Configure ingress route with SILK codec and egress route with PCMU codec.
4. UAC sends an INVITE with the SILK codec.
5. The SBC sends an INVITE with PCMU codec to UAS.
6. UAS sends a 200 OK with PCMU to the SBC.
7. The SBC sends a 200 OK with SILK to UAC.
8. UAC sends ACK to the SBC.
9. The SBC sends ACK to UAS.

The code is modified to copy the codec payload type value during an auto answer.

Workaround: If "Lock Down Preferred Codec" IPSP flag is disabled then the call scenario works fine.

PortFix SBX-116256: Observed a heap-buffer-overflow on address 0x6260000bf802 at pc 0x56063d63cca4 bp 0x7fe633ce2b00 sp 0x7fe633ce2af8.

Impact: A heap-buffer-overflow is observed when Option header with too many spaces or tab is received.

Root Cause: When too many space are inserted after Option header.

Pdullen is calculated wrongly and include all the spaces also so while doing pre parsing pdulen reaches beyond PDU and leads to coredump.

Steps to Replicate: Send option Message with large no spaces or tab such as: 
OPTIONS \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \t \tsip:9611912691@10.xx.yy.zzz:7050 SIP/2.0

The code is modified to change the startIndex so that it points to Offset Length that is equivalent to the Header length.

Now while calculating the PDU length, it is taken from Offset. With these changes, all spaces are taken into consideration and the length is correct.

Workaround: None.

PortFix SBX-116942: D-SBC (M-SBC) - The XRM/NP CPUs are also being used by a system task causing slowness in media tasks.

Impact: In the SWe, a few sbxPerf processes (example: top2) run on the media cgroup causing congestion issues.

Root Cause: Segregation of media and non-media processes at initialization time may fail, leading to non-media processes landing on a VCPUS that is meant for media processing.

Steps to Replicate: Install a fix build in the SWe and check whether the sbxPerf process (example: top2, atop) runs on the core0.

The code is modified to move the sbxPerf processes to the system cgroup. The segregation of processes is fixed as part of a separate issue.

Workaround: Reboot the SBC.

PortFix SBX-112980: The SBC interworks the extra precondition UPDATE towards the Egress.

Impact: The downstream forking and preconditions interwork using an UPDATE method are enabled.

When multiple 18x with a precondition are received by the SBC, the SBC sends an UPDATE request to complete the preconditions. The SBC sends an additional precondition UPDATE towards the egress, even though the preconditions are already completed.

Root Cause: There was an issue in the code when an UPDATE request is triggered a second time without checking whether preconditions are met already.

Steps to Replicate: Run the call flow per the customer's setup.

The code is modified to suppress the additional precondition UPDATE request, if preconditions are already met.

Workaround: None.

PortFix SBX-117803: MOH call failure for non core stream

Impact: Media On Hold (MOH) Call is failing for non core stream when NAT is enabled.

Root Cause: Call is failing because of frequent deactivation and reactivation of resources for a non core stream at the time of NAT relearning causing resources to go into asynchronous error

Steps to Replicate: 

1. Configure the NAT media and signalling.
2. RUN a hold resume with a two media stream (audio + video).
3. Check if it throws a BRM sync Error or if the resources are deactivated and reactivated frequently.

The code is modified for non core stream in a NAT call so that deactivation and reactivation of resources does not take place.

Workaround: 

1. Run the call with only core audio
2. Run the call without configuring NAT

PortFix SBX-114293: The S-SBC is unable to clear a call when there are multiple codec changes with RE-INVITES in call.

Impact: On the D-SBC, a two DSP transcode call involving multiple re-INVITEs has a hung private respone and a call termination takes more time than expected.  For example: a call hold/off-hold with a codec change from narrowband to wideband and vice versa.

Root Cause: On the T-SBC, for every DSP, two XRESs are allocated during a re-Invite: a public and a private XRES.
In a single DSP call, the private XRES is retained. But if the call requires both DSPs, the private XRES(s) on each call leg is released.
In the two DSP call scenario, after multiple re-Invites(hold/off hold with codec change) , a stale private XRES(s) is held unnecessarily in the previous pending ACK PSP context. The SBC is unable to terminate the call smoothly.

Steps to Replicate: 

1. Run the call flow with the initial call being a 2 DSP transcode call with AMRWB-AMRWB codecs.
2. Send multiple re-INVITES from the endpoint to change the codec to AMR and AMRWB and so on.
3. The output of the callResDetailStatus shows a hung private XRES(s).
4. After receiving a BYE message from the  end point, a call termination takes an unreasonably long time.

The code is modified to address a two DSP transcode call. The private XRES(s) is freed appropriately and the call is terminated smoothly when a BYE message is received from the endpoint.

Workaround: None.

Portfix SBX-118283: Azure : Observed Availability set gets created when parameter "create_availability_set_for_sbcs" =false

Impact: Availability Set being created when associated flags are set to "false".

Root Cause: Incomplete Azure terraform scripts allowing Availability Sets to be created.

Steps to Replicate: Re-ran terraform in the SBC HFE 2.2 setup to ensure Availability Set being created or not created as per the setting of the appropriate flags.

The code is modified to add new Availability Set modules in terraform to support creating or not creating them correctly based on the Availability Set flags.

Workaround: None.

PortFix SBX-117097: A DTLS SRTP call fails after the remote peer modifies the session - the SBC fails to process the incoming DTLS Client Hello.

Impact: The DTLS SRTP call fails after remote peer modified session.

Root Cause: The DTLS SRTP task maintains two contexts, one for client and one for server. They are being passed in when the SBC initiates/re-initiates the session. In this case, the SBC was initiating server session. But in DTLS SRTP session reinitiate function, we passed in client context instead that caused call failure. Also when reinitiating the session, the remote RTP address was not saved in CCB.

Steps to Replicate: The steps cannot be reproduced. 

The code is modified to:

1. Use the proper context when starting a server or client session.
2. Save remote RTP address in the CCB.

Workaround: None.

PortFix SBX-117911: A call between Cisco EP and PSTN failed as the SBC is sending incorrect attribute value for Video port 0.

Impact: The SBC sends a=sendrecv instead of a=inactive when video stream is received with port 0.

Root Cause: When changes were made to support additional video parameters in 9.2.x release, the datapath mode WSA set to default(a=sendrecv) when video stream was marked as absent. This was causing the SBC to send a=sendrecv.

Steps to Replicate: 

1. Initiating call from Cisco phone to PSTN endpoint and PSTN sends back 180 Ringing.
2. The SBC added SDP in the 180 Ringing for LRBT and sent back to CUCM Cisco phone.
3. Ensure SBC added audio m line with valid IP and port, and for Video added port Zero with a=inactive.
4. Answering the call from PSTN phone.
5. Now ensure that POLYCOM phone is in CONNECTED state after answering call.
6. Media Validation for Call between PSTN user and Cisco User on Cisco Phone.

The code is modified to inactive when video stream is marked as absent when port 0 is received.

Workaround: None.

PortFix SBX-118662: The LSWU failed due to Action Command Timeout

Impact: The LSWU failed from V10.01.01R3 to V10.01.02A3
admin@EMERALD> request system serverAdmin GARNET startSoftwareUpgrade <sbc package>

This command will start a live software upgrade. Do you want to proceed [no,yes] yes
Error: Action Command Timeout.

Root Cause: The issue is with media codec related packet size validations in appPreChecks during the LSWU was taking longer time.

Steps to Replicate: Run the following command: % request system serverAdmin GARNET startSoftwareUpgrade package <sbc package name>

The code is modified to address the issue.

Workaround: None.

PortFix SBX-117235: An additional UPDATE is being triggered by the SBC when the server side sends 18x with Valid Video Port.

Impact: In a delayed tone play scenario, the SBC is sending an additional UPDATE when egress EP sends 18x with valid audio and video ports

Root Cause: The SBC completed an initial offer-answer in INV and 18x with valid Audio and Video ports.

Later, due to delayed tone play logic, the SBC started playing the tone. As part of this tone play activation, the SBC is trying to switch OFF the video stream by triggering an UPDATE with video port as zero. The 200 OK (for UPDATE) is causing the SBC to abort the tone which is not supposed to happen.

Steps to Replicate: 

1. UAC sends INVITE with Audio and Video.
2. UAS sends 183 with Audio and Video
3. The SBC starts playing tone due to delayed ring back tone configuration.
4. The SBC triggers an UPDATE with video port as zero towards ingress EP.
5. A 200 OK (for UPDATE) response makes the SBC abort the tone.

The code is modified so that the SBC does not stop the tone play upon receiving a 200 OK (for UPDATE) response from the ingress EP.

Workaround: None.

PortFix SBX-116974: [Rakuten]: S-SBC is unable to send the 200OK for 2nd re-INVITE during the 4:1 redundancy with 2 RGs

Impact: S-SBC is not sending 200 O.K for RE-INVITE in 4:1 redundancy setup leading to call time-out from remote peer and subsequent call failure.

Root Cause: S-SBC is not able to locate the remoteGCID for the call in the DFE module.

Steps to Replicate:

1. Configure the setup to transparent precondition interworking + transcode scenario.
2. Send an initial INVITE with precondition attributes from UAC.
3. Now preconditions met. Now, call is with AMR-WB to AMR transcode scenario.
4. From UAS, send the 183 without SDP.
5. From UAS, send the UPDATE message, change the codec from AMR to AMR-WB.
6. Now, AMR-WB and AMR-WB transcoding call got established.
7. From UAS, send the 183 without SDP.
8. From UAS, send the UPDATE message , by changing the codec from AMR-WB to AMR.
9. Now, AMR-WB and AMR transcoding call established.
10. From UAS, send the 180 without SDP.
11. From UAS, send the UPDATE message, by changing the codec from AMR to AMR-WB.
12. 200OK of INVITE without SDP sent from UAS. Call got established.
13. From UAS, change the codec from AMRWB to AMR with Re-INVITE.
14. Now the call is established with AMR-WB and AMR transcoding call.
15. From UAS, change the codec from AMR to AMRWB with Re-INVITE.
16. Now the call is established with AMR-WB and AMR-WB transcoding call.
17. Send the BYE from UAC.

The code is modified so that the DFE module of the SSBC retains the RemoteGCID unless the call is not unstable. Prior to the fix, the Remote GCID was internally deleted by DFE in the DFE Sync message

Workaround: None.

PortFix SBX-118155: The S-SBC is unable to send the UPDATE towards the UAS endpoint for 183 dialog-3 during EGRESS precondition interworking scenario.

Impact: The S-SBC is unable to send the UPDATE towards the UAS endpoint for 183 dialog-3.

Root Cause: When ingress was not supporting UPDATE, the SBC was trying to send out and stuck in this state.

Steps to Replicate: 

1. Send the initial INVITE message without precondition attributes.
2. The SBC sends the INVITE to UAS with precondition attributes.
3. Send a 183 dialog-1 from UAS with precondition attributes.
4. Before preconditions met for 183 dialog-1 , Send the 183 dialog-2
5. Once preconditions met for 183 dialog-1, Send the 183 dialog-3 after the 183 dialog-2 (retransmission)
6. Now, the SBC process the 183 dialog-2 and send it UAC.
7. Before completing the preconditions for 183 dialog-2, send the 183 dialog-3 again from UAS (retransmission).
8. After preconditions met for 183 dialog-2, the SBC should dequeue the 183 dialog-3 and process it.
9. The SBC should generate UPDATE message for 183 dialog-3 and send to UAS.

The code is modified to locally answer the UPDATE when ingress peer does not allow UPDATE

Workaround: None

Portfix SBX-113553: Interworking between a 100 REL compliant UAS and a non 100 REL UAC. 

Impact: Interworking between a 100 REL compliant UAS and a non 100 REL UAC

Root Cause: The UAC is not 100 REL compliant and the SBC cannot forward the UPDATE to the UAC. It fakes a local answer 200 OK for this UPDATE with all the supported codecs of the UAC. This makes the SBC pick a pass through codec which is different from the codec already communicated to the UAC. An audio issue results until the call gets connected.

Steps to Replicate:

1. The UAC doesn't have a 100 REL support and UAS support 100 REL. Enable SendSingleCodecinAns for both the legs
2. The UAC sends an INVITE with the G729, AMR, AMRWB and PCMA to the SBC.
3. The SBC sends INVITE with G729 AMR, AMRWB and PCMA to the UAS.
4. The UAS sends 18x G729 and PCMA to the SBC.
5. The SBC sends 18x G729 to the SBC.
6. The UAS sends an UPDATE PCMA to the SBC.
7. The SBC sends a 200 OK Update message with the PCMA.
8. The call is transcoded from G729 to the PCMA.

The code is modified so that the SBC fakes the local answer 200 OK (for UPDATE here) with the last negotiated codec which is already communicated to the peer. The codec selection remains the same even after the offer-answer completion during an UPDATE-200OK handshake and there will not be any audio mismatch.

Workaround: None.

PortFix SBX-116062: SIPREC - Recorded streams cannot be decrypted successfully after call hold/unhold when the SIPREC server prefers a different SRTP crypto suite than the SBC

Impact: With SRTP is enabled for SIPREC: in the scenario mentioned below, SRTP Keys towards SIPREC Servers is corrupted and SIPREC server fails to decrypt the recorded audio stream.

1. The SBC offers more than one crypto suite towards SIPREC Server in the initial INVITE.
2. The SBC receives answer with the crypto suite other than the first preference.
3. The main call/CS call goes on hold/unhold.
4. The SBC sends a Re-INVITE towards the SRS with corrupted crypto key values and SIPREC server fails to decrypt the streams.

Root Cause: When the SBC receives the answer from SIPREC server with the crypto suite other than the first preference from the offer, the SBC Recorder control block would be updated with the key as received in the answer. However, the crypto suite continued to reflect the offer's top most crypto, thus resulting in corrupted key in further offers towards SRS.
The crypto suite from the answer was supposed to be updated in the recorder control block along with the answer key and maintain the correct pair of key and suite values.

Steps to Replicate: 

1. Configure the crypto suite profile with more than one crypto entry, attach it to the srsGroupProfile and enable SRTP.
2. Put the main call on/off hold and simulate the SIPREC server to send different crypto preference form the offer.
3. Make sure that the SBC is not sending corrupted key values in the Re-INVITEs towards SIPREC server.

The code is modified so that when the SBC receives an answer with crypto suite other than 1st preference form the offer, it updates the negotiated crypto in the control block.
When the CS call is put on hold/unhold, the SBC sends a re-INVITE towards the SRS with negotiated crypto key values.

Workaround: None.

PortFix SBX-118329: A call between CUCM EP and PSTN failed as the SBC is adding additional codecs that are not configured during 18x LRBT play.

Impact: The SBC sending all codecs received in the initial INVITE, in the 18x LRBT play.

Root Cause: The root cause for this issue is, when TFT and Audio Transparency is enabled, the SBC uses the codec in NSD, during tone play rather from PSP.

As part of multi-audio and other bug fixes, the NSD generation for tone Play changed, which is causing this issue.

Steps to Replicate: 

1. Configure the SBC for A-B call with Tone.
   Enable transcoderFressTransparency and seectiveSdpRelay flag.
2. Send multiple codecs in INVITE from UAC.
3. The SBC should send an INVITE out and should receive 18x from UAS.
4. The SBC should play tone with whatever codec that is configured in the PSP.

The code is modified so when the TFT and Audio Transparency is enabled, the SBC uses the older way to generate the codecs.

Workaround: None.

PortFix SBX-116123: The value set against GPU flag in /opt/sonus/conf/swe/capacityEstimates/.activeCallMixInput.json file is not an integer value" error message in DBG

Impact: On Managed N:1 MRFP node, when a custom CPU profile is applied, from OAM, by specifying the value against the useGPUForTranscoding field to false, following critical level message is logged in the .DBG file: 

" The value set against GPU flag in /opt/sonus/conf/swe/capacityEstimates/.activeCallMixInput.json file is not an integer value. "

This log does not indicate any issue with the the functionality of the profile activation.

Root Cause: On N:1 Managed MRFP node, the CDB gives the value against the filed useGPUForTranscoding as False(string), rather than 0(integer).

Application takes the value for the corresponding field as 0 by default, but a critical error message is logged in .DBG log.

Note: For the useGPUForTranscoding field value set to True, the corresponding logic was already in place, no issues in this scenario.

Steps to Replicate: For reproducing the issue on Managed N:1 MRFP, activate a traffic profile with useGPUForTranscoding value set to false, from the OAM, as shown below:

%set system sweTrafficProfiles VzW_callmix_profile useGPUForTranscoding false
%commit

% request system admin vsbcSystem saveAndActivate rebootSBCs true
%commit

All the N:1 MRFP nodes will go for a reboot and once the application comes up, observe the following logs in latest DBG logs:

" The value set against GPU flag in /opt/sonus/conf/swe/capacityEstimates/.activeCallMixInput.json file is not an integer value. "

The code is modified to address the issue.

Workaround: None.

Note: The log does not indicate an error in the functionality of profile activation.

PortFix SBX-116698: The SBC is sending out an Error-Info header in a 400 Bad Request even when the suppressErrorInfoHdr flag is enabled.

Impact: The SBC is sending out an Error-Info header in a 400 Bad Request even when the suppressErrorInfoHdr flag is enabled.

Root Cause: After the SBC restarts, the suppressErrorInfoHdr flag value is not updated correctly.

Steps to Replicate:

1. Enable the suppressErrorInfoHdr flag:
   --set global signaling sipSigControls suppressErrorInfoHdr enabled
2. Restart the SBC.
3. Send a Malformed INVITE from the UAC.
4. The SBC sends a 400 bad request in response to the malformed INVITE when the Error-Info header is eliminated.

The suppressErrorInfoHdr Flag value is updated properly after a restart.

Workaround: None.

PortFix SBX-119428: Frame Lost indication not set for AMRNB.

Impact: The frame lost flag is not being set based on talkState for AMRNB decoder.

Root Cause: When there is no frame to be fed to the AMRNB decoder, an indication of either 'frame loss' or 'no data' should be provided to the decoder. This indication should be determined based on the decoder's talk state. Currently, the 'no data' indication is set even if there is a frame loss, which is incorrect.

Steps to Replicate: 

1. Run a AMRNB to G711 call.
2. Stream a media with packet loss on the AMRNB leg.
3. Capture the media on the G711 leg.
   The media quality should be good which can be validated using PESQ analysis.

The code is modified to allow the frame loss flag to be set based on the decoder's talk state.

Workaround: None.

PortFix SBX-120625: SRTP one-way audio - SBC not resetting SRTP encryption ROC to zero when ssrcRandomizeForSrtp is enabled

Impact: One-way audio on SRTP calls; the far end is unable to decrypt SRTP packets due to ROC mismatch.

Root Cause: Once the SBC received re-INVITE on the egress call leg, BRM issued RID modify command to NP on ingress call leg to update SSRC in RID.

In the RID modify command, the clear last SSRC flag was not initialized properly which caused NP NOT to clear the ROC.

Steps to Replicate: ssrcRandomizeForSRTP Enabled/ passthru:

• Long call scenario (25 min) with SRTP, switchover.
• Long call scenario (25 min) with SRTP, re-invites.
  
  

ssrcRandomizeForSRTP Enabled/ transcode:

• Long call scenario (25 min) with SRTP, switchover.
• Long call scenario (25 min) with SRTP, re-invites.
  
  

ssrcRandomizeForSRTP disabled/ passthru:

• Long call scenario (25 min) with SRTP, switchover.
• Long call scenario (25 min) with SRTP, re-invites.
  
  

ssrcRandomizeForSRTP disabled/ transcode:

• Long call scenario (25 min) with SRTP, switchover.
• Long call scenario (25 min) with SRTP, re-invites.

The code is modified so that the NP RID enable and modify interface functions ignore the clear last SSRC flag - keeping ROC reset in sync with clear last SSRC.

Workaround: Disable ssrcRandomizeForSRTP.

PortFix SBX-11942: Frame Lost indicator not set for AMRWB & V 1.4 Library Upgrade

Impact: 

1. Frame lost flag is not being set based on talkState in AMRWB decoder
2. Divide by zero issue in AMRWB energy computation which can lead to a crash

Root Cause: 

1. When there is no frame to be fed to the AMRWB decoder, an indication of either 'frame loss' of 'no data' should be provided to the decoder. This indication should be determined based on decoder's talk state. Currently, 'no data' indication is set even if there is a frame loss, which is incorrect.
2. The denominator is a sum of two energy values, both of which were expected to be positive. However one of the energy values turned out to be negative. The negative energy value is attributed to incorrect handling of overflow when computing the energy value. The incorrect handling of the overflow makes a large positive number appear to be a negative value.

Steps to Replicate:

1. Run a AMRWB to G711 call.
2. Stream a media with packet loss on the AMRWB leg
3. Capture the media on the G711 leg. The media quality should be good which can be validated using PESQ analysis.

The code is modified so that the frame loss flag is set based on the decoder's talk state. As well, the divide by zero issue is addressed in the AMRWB library upgrade.

Workaround: None.