SBC Core 07.02.05R000 Release Notes

V05.01.00F007

V07.01.00F003

V07.02.00R000

V07.02.01R003

V07.02.01R004

V07.02.01R007

V07.02.01R008

V06.01.00R007

V05.01.02F008

V06.02.01F007

V06.02.01F008

V06.02.01F009

V06.02.01F010

V06.02.01F012

V06.02.02R000

V06.02.02R001

V06.02.02F001

V06.02.02F002

V06.02.02F003

V06.02.02F004

V06.02.02F005

V06.02.02F006

V06.02.02F007

V06.02.02F008

V06.02.02F009

V06.02.02F010

V06.02.02F014

V06.02.03R000 

Portfix SBX-95919: The Max Forward Header Support feature is not working for requests from terminating side.

Impact: The Max Forward Header Support feature is not working for requests from the terminating side. The SBC does not subtract 1 in the Max-Forwards header despite the rfc7332ValidateMaxForwards is set to enable.

Root Cause: This issue is caused when a BYE request that comes from the terminating side. Any other requests from the originating side are decreased correctly including the BYE request.
Handling the BYE from terminating side was not taken care of.

Steps to Replicate: Enable fc7332ValidateMaxForwards on both TG.

1. Initiate a call from A to B, B sends a 200 OK to connect the call.
2. B sends the Bye request. The SBC sends the Bye request to A.
   The Max forward header in the Bye is set to 70.
3. Check the Max forward SBC sends to A. The Max forward header should be decremented by one.

The code is modified so when BYE is received from the terminating side, decrease the max forward header by one.

Workaround: N/A

Portfix SBX-94762: The basic Relay-Relay of RTCP for T140 is not working in the latest build.

Impact: The RTCP NAPT PORT learning alone is not working in the SWe.

Root Cause: RTCP NAPT PORT learning flags ports definitions endian mismatch in the SWeNP was not triggering the learning and causing drops.

Steps to Replicate: Run calls with RTCP NAPT port learning alone call flows and ensure the RTCP packets are learnt and relayed accordingly.

The code is modified in the SWeNP media flow processing to fix the issue.

Workaround: N/A

Portfix SBX-96484: The MRFRM SIPSG standby CCB hash had multiple insert failures.

Impact: When there is hash insert failure, the case is not being handled properly.

Root Cause: There are a few major logs that came as part of load run that relates to the gcid hash insert failures in the MRFRM.

Steps to Replicate: Run a SBC call flow with 12 codecs with the GW signaling and configure the system in Sensitive mode.

The code is modified to perform a hash swap when there is hash collision.

Workaround: Run an MRF load and issue may be reproduced.

The DBG file was filling up with messages "SIPCM: *ThreadPool: messageSequence "

Impact: The DBG logs can be overrun with "SIPCM: *ThreadPool: messageSequence" messages.

Root Cause: The DBG logs can be overrun with "SIPCM: *ThreadPool: messageSequence" messages, when the double CRLF "pings" are received by the SBC over a UDP transport.

Steps to Replicate: Send double CRLF "pings" over UDP to the SBC.

The code is modified to properly dispose of double CRLF "pings" received by the SBC over the UDP.

Workaround: Inhibit the transmission (or reception) of Double CRLF "pings" over the UDP.

Portfix SBX-96323: The version header is removed on the SBC even though the transparency was enabled.

Impact: When running an OOD message call flow with MIME Header and Transparency is enabled for MIME Header, the MIME Header is not going in the egress message.

Root Cause: The MIME header is ignored by the SIP Parser.

Steps to Replicate: Run an OOD Message call-flow with Mime header.

The code is modified to add MIME header as a Transparent header.

Workaround: Use the SMM Message Scope Variables to store and add it in the outgoing message.

Portfix SBX-98367: The M-SBC lost connections to other M-SBC and S-SBCs.

Impact: The X710 SR-IOV PKT0 interface on the M-SBC stops receiving packets, resulting in connectivity loss with the S-SBC and other M-SBCs.

Root Cause: The default TX Free threshold setting for the DPDK X710 PMD holds up a larger number of packet buffers leading to buffer starvation and thereby stopping of packet rx on pkt0 port. The issue is particularly aggravated when the majority of calls have both legs on PKT0 and few calls have one leg on PKT1 and another on PKT0.

Steps to Replicate: 

1. Run calls with both media legs on the pkt0.
2. Run 100-200 calls with one media leg on pkt0 and another on pkt1.
3. Re-run calls with both legs on the pkt0.

The code is modified to prevent retaining a large number of packet buffers in the TX done queues.

Workaround: There is no guaranteed workaround, but enabling the LDG may help in reducing the chances of the reoccurrence of this issue.

Portfix SBX-100331: After adding the second mgmt port in the 23vcpu I-SBC (in RHEV platform 8.2.1 build), pkt and the mgmt port messes up.

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

Root Cause: There was a bug in the code that pulled non-existent port id on adding extra management port resulting in crash.

Steps to Replicate:

1. Make a large instance >15vCPU(default profile) without redundant packet ports.
2. Add extra management port and reboot.

The code is modified so the polling of extra management interface properly manages large instances in the SWe_NP code.

Workaround: N/A

The From header wrongly impacted by the SMM.

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

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

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

There were logical error on the 2nd rule when try to reconstruct the uri header into generic header that adding duplicated generic parameters.

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

Portfix SBX-99321: There is node resource congestion alarms after upgrading to 7.2S400.

Impact: Performing a time zone change from CLI can cause node resource congestion alarms in 7.2S400.

Root Cause: The problem was found to be caused due to a system daemon(cron) running in signaling group and exhausting signaling resources.

Details:
Whenever there is a timezone change, cron is restarted and when it is restarted from a process running in the SIG core(SM), cron gets scheduled in the SIG core. SIG cores are monitored for resource usage periodically and due to cron taking more resources while running cron jobs, the resource congestion alarms were getting raised by the SBC.

Steps to Replicate: 

1. Perform a timezone change from the CLI on SWE.
2. Note the pid of cron and check which cgroup it is apart of by running the following scripts:
   cat /cpusets/sig/tasks | grep `pidof cron`
   cat /cpusets/system/tasks | grep `pidof cron`

The code is modified so the scripts responsible for the timeZone change and cron restart are moved to the system cgroup.

Workaround:

1. Reboot the SBC after a timezone change, (or) 
2. Run below command to move cron to system cgroup:
   /usr/bin/cset proc -m -p `pidof cron` -t system --thread

A PRS process core occurred on the Standby Server.

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

Root Cause: The root problem was that the pkt2 on standby node was stuck in DOWN state due to possible network switch issue, while the pkt2 on active node was functioning as normal. All the activated XRESs selected on LIFs of the pkt2 were mirrored to standby and got inserted in the deferredXresList waiting for the standby pkt2 to be UP.

Then when one of those XRESs is reused for a different call and mirror to the standby node, that XRES may be stuck in the deferred XRESList because the deallocate request may have not been processed yet on the standby node. As a result, the PRS hit coredump was caused by the XRM accessing the NULL pointer inside of the XRES data structure.

Steps to Replicate: The SBC HA pair, active node has pkt ports all UP, and standby node has at least one of the pkt port DOWN.

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

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

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

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

The SBC20-SPO was adding an extra application/ISUP ACM content.

Impact: The 200 OK Bye has duplicated the ISUP body.

Root Cause: When the e2e Bye is enabled, 200 OK has duplicated the ISUP body.

Steps to Replicate:

1. Configure the isupMimeBodyRelay and e2e bye.
2. Run a sipi-sipi call, and the SBC sends 200 OK bye has duplicated isup body.

The code is modified so the SBC does not create an isup body internally for the e2e Bye and isupMimeBodyRelay.

Workaround: Disable the e2e Bye.

Both applications (iceSupport and SMM storeIPTG) coredumped.

Impact: The SMM drops an incoming call.

Root Cause: After a response failure to an invalid call, the SBC still tries to initiate a setup call. As a result, it accesses an invalid address.

Steps to Replicate: Configure the iceSupport, SMM storeIPTG, and an incoming call with the invalid candidate (no UDP).

The code is modified to add a address validation and not try to initiate a setup call if the call fails.

Workaround: N/A

Portfix SBX-99874: A second INVITE with a REPLACES collects the wrong PSX route.

Impact: A second INVITE with REPLACES collects the wrong PSX route.

Root Cause: There was a design gap, in case of multilevel INVITE with REPLACES, that the SBC was sending a light weight PSX look up with the incorrect source and destination trunk group. As a result, the SBC is receiving the incorrect TG configuration from PSX.

Steps to Replicate: 

1. A and B are connected.
2. C sends INVITE with REPLACES to replace A.
3. D sends INVITE with REPLACES to replace C.
4. D sends Re-INVITE with a=inactive.

The code is modified so the SBC sends light weight PSX lookup with the correct source and destination trunks to get the corresponding TG level configuration.

Workaround: N/A

There was a back-to-back coredump on the Server.

Impact: The SCM process cored due to memory corruption while parsing an INVITE with a very long and invalid CallId field, while the parseError trace logging was enabled.

Root Cause: The SCM process coredump is caused by memory corruption that is the result of the Trace Logging code overwriting a buffer.

This can happen when the SIP parser encounters an invalid CallId that is also very long.
It is also possible that other parsing errors can trigger this core, especially if the parse error was encountered for a particular header that is very long.

Steps to Replicate: This can be reproduced by enabling the parseError trace logging and then sending a INVITE that includes a badly formatted CallId, which is the maximum allowed size for a CallId:
"set global callTrace errorFilter errorType parseError"

The code is modified to not overwrite the end of the buffer when it is attempting to write a very long error message string.

Workaround: Disable the parseError tracing.

Portfix SBX-96001: The SBC 7000 has the wrong value for call duration.

Impact: The call service duration (CDR field numbers 10 and 14) has wrong values causing a billing issue.

Root Cause: This issue is seen when there is mid-call message in this case session refresh. Due to this session refresh, there are mid-call messages(INV/200OK/ACK) happens end to end. This makes the "callServiceEstTime" in the function CcRelayInfoMsg() overwritten every time causing the CDR fields 10 and 14 wrong values.

Steps to Replicate: 

1. Enable IPSP flag "End to End ACK" on both TGs.
2. Disable the flag "No CDR Change in End to End Ack".
3. Make a call from A to B and let the call be connected with session refresh enabled.
4. Once the session refresh happens, disconnect the call and check the CDR.

The code is modified such that the "callServiceEstTime" does not get overwritten once its recorded initially during the initial offer-answer.

Workaround: Enable the flag "No CDR Change in End to End Ack"

There was a switchover with the PRS process coredumping.

Impact: The PRS process coredumped due to memory corruption.

Root Cause: Customer encountered a PRS process core due to the memory corruption that happened earlier in processing. The core is the after effect of earlier corruption.

Steps to Replicate: None.

The code is modified to avoid the core, and to collect more diagnostic data if a core happens again.

Workaround: N/A

Intermittently, the SBC SWe accesses the sipSigPort for sending the SIP messages to the core side.

Impact: The relay options with registration may route to the wrong Sip Signaling Port and causing call fails from AS to IAD.

Root Cause: When the IAD sends a registration arrive from the SSP1 and relay options from an other SSP2. Since the options from the SSP2 do not match with RCB from SSP1, the SBC treat the options from the AS and triggering invalid routing to the wrong destination.

Steps to Replicate: Configure the SSP1 and SSP2, and enable maskRcbPort. The registration from SSP1 succeeds. Options from the SSP2 will trigger a relay back to the IAD (not AS). Subsequent calls from AS may fail or refresh registration.

The code is modified to detect the relay messages from the IAD or AS based on RCB looks up (not just based on SSP).

Workaround: Disable the maskRCBPort. Or use the SMM to make the SBC response to Options (not relay).

The dual system SCM process cores and causes a complete outage.

Impact: The SCM process may coredump during two stag SRTP calls.

Root Cause: The NULL pointer access caused the SCM process to coredump.

Steps to Replicate: The steps cannot be reproduced.

The code is modified to include additional NULL pointer protection to the SRTP licensing code.

Workaround: Disable the SRTP.

The eSBC JIAD622 crashed.

Impact: The root cause has an incorrect initialization in the third party T.38 stack.

Root Cause: The issue occurs when Version 3 T.38 fax is enabled. In such a case, in case a CED 2100 Hz is sent by the SBC to G711 leg while it gets T.38 ANSAM packets from T.38 side, the DSP hardware stack can crash.

Steps to Replicate: The test setup to recreate this problem involves special SIPP scenarios and the SBC configuration.

The SBC is configured for the ingress as G711 and egress G711 with T.38 for Version 3.
Also configure the ingress PSP as transcode only and ensure that the codecs allowed for transcoding for ingress has G711 and egress has both G711 and T.38.

The code is modified by getting a third-party stack that has proper initializations and protection code to avoid a crash.

Workaround: N/A

An SCM process coredump occurred on the SBC in sensitive mode, while running a call flow with 12 codecs over a GW signaling call flow.

Impact:The SCM process experienced a coredump.

Root Cause: In the SgCondenseAudioWildcard, scenarios may occur where the audioEnd and audio1 have the same IP address.

Steps to Replicate: Run an SBC call flow with 12 codecs with the GW signaling and configure the system in sensitive mode.

The code is modified to remove the equal condition between audioEnd and audio1.

Workaround: Configure the SBC in normal mode.

Observed DSP coredumps and MAJOR logs on 7000 Platform while running ICM Scaling suite.

Impact: The DSP coredumps were observed during the switchover tests.

Root Cause: Certain variables used in the interrupt context were not protected while being modified outside the interrupt. This impacted the inter-core health-check logic at DSP and incorrectly led to error being reported, eventually leading to core-dump.

Steps to Replicate: HA Pair of fully loaded SBC-5100/5200/5110/5210/5400/7000

1. Run a transcode load.
2. Initiate a switchover.

The code is modified so the variables are protected from interruption.

Workaround: N/A

Portfix SBX-99020: Observed Major logs with the error prints of 488 on the SBC 5210 platform while running direct media.

Impact: Calls stop working as the LIF bandwidth is not freed.

Root Cause: In case of a multi-stream direct media call with the last media stream as non-RTP stream, the SBC does not release the session bandwidth even when the call is released. This leads to a leakage in the interface bandwidth resulting in call failures after some time.

Steps to Replicate: Run direct media calls with multiple streams with last media stream as a non-RTP stream (BFCP, MSRP).

The code is modified to release the session bandwidth even when the last media stream is non RTP stream in a direct media call.

Workaround: N/A

A BYE message was sent to the wrong port.

Impact: The SBC does not update remote connection address when refresh INVITE is received from different port.

Root Cause: When the endpoint is registered over TLS initiating a call and after the call is established, the endpoint sends a refresh register from a modified port. When a refresh INVITE is sent with no SDP change, the SBC does not send BYE to a modified port when the call disconnects.

Steps to Replicate: 

1. Register endpoint over TLS.
2. Endpoint initiates a call, call gets connected.
3. Endpoint sends refresh register from modified port.
4. Endpoint sends refresh re-INVITE from modified port.
5. Called party disconnects the call.
6. Verify that the SBC sends BYE to modified port towards caller.

The code is modified to ensure the SBC updates the remote address when a refresh INVITE is received from a modified port.

Workaround: N/A

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

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

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

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

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

Workaround: Do not disable the signaling ports.

Portfix SBX-100650: The INVITE with replaces failure for the G722 only call.

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

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

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

The code is modified to pass the indicator to the PSX when processing the REFER that the SBC supports in newer codecs.

Workaround: N/A

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

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

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

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

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

Workaround: N/A

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

Impact: In an M-SBC deployment when making the M-SBC out of service (such as 'set global system action force mode outOfService'), the code was accessing free memory.

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

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

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

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

Portfix SBX-100624: The trunk group routing was not working when a SIP-I call is received.

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

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

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

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

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

Portfix SBX-101547: On a switchover, a coredump occurred after a call was placed on hold.

Impact: The code was dereferencing a NULL pointer and causing the SCM process to crash.

Root Cause: The customer had the passThruPrivacyInfo control enabled on both the ingress and egress privacy profiles. But the ingress side of the call did not pass through some expected information related to the INVITE message and it caused the code to dereference a NULL pointer.

Steps to Replicate: Unable to reproduce this issue, the code has been fixed based on code review and coredump analysis.

The code is modified to validate the pointer is not NULL before trying to use it.

Workaround: Disable the passThruPrivacyInfo controls.

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

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

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

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

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

Workaround: N/A

The SBC failed to send ACK to the right IP.

Impact: After a call was connected with egress received RR in 2xx, the SBC sends a reInvite, and received the rexmit of 2xx. Later on, the SBC sends ACK to the wrong destination.

Root Cause: A rexmit of 200OK, accidentally deletes the previous RR.

Steps to Replicate:

1. A calls B.
2. B responds with a 200OK with RR.
3. A reInvite triggers the SBC reInvite to B.
4. B responds with 2xx and rexmit 2xx.
5. The SBC sends ACK to the wrong destination (based on contact not from previous RR received).

The code is modified so the SBC ignores updating the data of the dialog.

Workaround: N/A

The SIPFE lookup returned the rcb pointing to wrong SCM post-upgrade.

Impact: After an upgrade, registrations mirroring on SIPFE is corrupted. As a result, incoming traffic for the AOR that may route to the wrong SCM and rejected by the SBC.

Root Cause: The packing redundancy data structure that was sent to the standby were incorrect due to word alignment issue (using sizeof() to pack the data).

Steps to Replicate: Multiple of the same AOR registers from a different source. After an upgrade, call for register end point may route to the wrong SCM.

The code is modified to re-implement the packing logic and avoid using sizeof() to calc the size of data structure.

Workaround: N/A

Portfix SBX-100223: The SMM for changing the ISUP message inside a SIP-I does not work properly.

Impact: When a message is received with the mime content having single msgbody. After the SMM application on the message body, the SBC reformats it as a normal msgbody instead on mime content.

Root Cause: When a message is received with the mime content having single msgbody. After the SMM application on the message body, the SBC reformats it as a normal msgbody instead on mime content. The reformatting is not handled properly.

Steps to Replicate: Add the SMM rules that applies to the message body. Send a message with mime content having single msgbody in it.

The code is modified so that the SBC reformats mime body after the SMM application is formatted correctly.

Workaround: N/A

The P-Early-Media header with sendrecv was sent back to the ingress before the SDP was established.

Impact: When the makeInBandToneAvailable is disabled, on Tone And Announcement profile, the SBC sends the 180 Ringing with the PEM header as sendRecv even when the egress 180 has no SDP. This causes ring back issues on the ingress endpoints.

Root Cause: When the makeInBandToneAvailable is disabled, the SBC does not include SDP in the 180 message sent to the ingress but still sends a PEM header as sendRecv.

Steps to Replicate: With a fix, the SBC is sending PEM header as inactive when the makeInBandToneAvailable is disabled and the egress 180 Ringing has no SDP.

The code is modified to ensure the SBC sends PEM header as inactive when the makeInBandToneAvailable is disabled and egress 180 Ringing has no SDP.

Workaround: Enable the makeInBandToneAvailable on Tone And Announcement Profile.

Portfix SBX-101145: The SBC is not sending the 183 (Dialog-2) to the ingress when the Downstream Forking and Loopback TG is configured.

Impact: The SBC is not sending the 183 (Dialog-2) to the ingress when preconditions and  Downstream Forking and Loopback TG is configured.

Root Cause: The preconditions are not handled in the ccE8S4 state when cc receives proc_msg.

Steps to Replicate: Configure preconditions, downstream forking and loopback TG. The egress leg receives a 183 for second dialog from UAS.

The code is modified to send the 18x message towards the ingress.

Workaround: N/A

The code is modified by getting a 3rd party stack that has the proper initialization and protection code to avoid a crash.

Workaround: N/A

Portfix SBX-99982: Observed the SCM process core on Openstack T-SBC while running load.

Impact: Observed the SCM process core on Openstack T-SBC while running load.

Root Cause: Missing the NULL check for the epRes before invoking IS_RES_AUDIOLESS,

Steps to Replicate: The steps cannot be reproduced.

The code is modified to add the missing NULL checks in all the places in NRMA for epRes before invoking the IS_RES_AUDIOLESS.

Workaround: N/A

Portfix SBX-93697: The PRS process cored on the M-SBC

Impact: The SCM coredump occurred when running the following test suite SBX-56559/Interwork P-Early-Media with a network that does not support the P-Early-Media and Relay.

Root Cause: The length of the string is not enough for logging and is causing the issue.

Steps to Replicate: Configure the system in sensitive mode and run the following test suite 56559/Interwork P-Early-Media with network that does not support P-Early-Media and Relay.

The code is modified to fit the required size and fix the issue.

Workaround: Configure the system in normal mode.

The SBC is converting two of the same rtpmaps into one line.

Impact: A duplicated media payload may cause a syntax error when the sdpSelectedAttribueRelay and transcodefree is sent to the other side.

Root Cause: A duplicated attribute line was merged into one line.

Steps to Replicate: Configure the sdpSelectedAttribeRelay and transcodefree. 

Platform/Feature: SBC

The SCMP coredumps occurred on the Server.

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

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

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

Steps to Replicate: A coredump analysis and code review.

Platform/Feature: SBC

The Bye URI Messages do not include the domain.

Impact: When the incoming INVITE contains a Contact header with a GR tag.

And the call flow is: SIP-SBC1 -- GW - GW - GSX- ISUP. The SBC includes an IP address in the reqURI of a BYE message and do not have FQDN present in the Contact of Ingress INVITE.

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

Steps to Replicate:

1. Reproduce the issue.
When the incoming INVITE contains a Contact header with a GR tag:

And call flow is: SIP-SBC1 -- GW - GW - GSX- ISUP, SBC includes an IP address in the reqURI of a BYE message and do not have FQDN ( present in Contact of Ingress INVITE )

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

Platform/Feature: SBC

Calls release cause 132 after a switchover.

Impact: The XRES uses the freed altMediaIpAddress unexpectedly in the standby XRM when the LIF is created.

Root Cause: When the standby XRM is notified with the LIF allocate request from NRS, it only receives the LIF's IP address. Any altMediaIpAddress will not be populated until the XRM has replied back to NRS. So when XRM is activating any XRES in the deferred activate list, the activation of XRES using altMediaIpAddress will be failed and freed.

Steps to Replicate: The SBC HA and SIPP call test setup:

1. Disable the keepAlive timer in the sipTrunkGroup.
2. Enable the debug INFO level logging.
3. Configure the altMediaIpAddress on LIF or LIFs if both ingress and egress legs have XRESs.
4. Configure the link detection on pkt port, threshold = 1 and enable it.
5. Make 5 basic SIP calls, call's mediaIpAddress = altMediaIpAddress, and call duration >= 20 mins.
6. Pull the cable from the pkt port, or ports if 2 pkt are interfaces involved, with link detection enabled.
7. Check the callCountStatus, wait for 5 min and plug in the cable on pkt port(s).
8. Check the callCountStatus again and wait for HA pair to finish syncing.
9. Perform a switchover again.

At step 6, the switchover triggered by link detection at step 7, 5 calls should be ACTIVE, check DBG log for following messages from XRM:

1. "XrmRedResAlloc: DEBUG! Context ID 0 XRES resId x on NIF y not allocated (on deferred list), LIF z not created"
2. "XrmNifMacAddrGet: Could not find LIF ifIndex z"
3. "XrmRedUdpAlloc: Context ID 0 Could not find UDP structure for LIF..."

At step 8, the calls should still be ACTIVE.
At step 9, the calls could be released during extensive audit, but not always.

Platform/Feature: SBC: CDR, Redundancy

The SBC7K core dumps again after the 6.2.1F010 update.

Impact: A rare race condition can cause the SamProcess to core with a Healthcheck failure when using the TLS.

Root Cause: The root cause of this issue is a rare race condition that allows one of the threads in the SamProcess to free memory, that is still being used by another thread in the same process.

Steps to Replicate: The steps cannot be reproduced.

Platform/Feature: SBC

The SBC services will not come up.

Impact: The standby fails to start and connect to the active, shutting down instead.

Root Cause: The address of the middleware checkpoint is lost and the checkpoint cannot be updated with the arrival of the new node, leading to it being shut back down.

Steps to Replicate: This is a one-off situation and can be easily reproduced.

Platform/Feature: SBC

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

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

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

Steps to Replicate:

1. Log into the EMA.
2. Navigate to
   All->profile->services->Transparency profile->SIP Header
3. Select the transparency profile.
4. Click on New Sip Header.
5. After that, the "Ignore Transparency " field will be visible.

Platform/Feature: SBC

Portfix SBX-95156: The SBC disconnects the call when it receives a 491.

Impact: A 491 received for a Re-Invite without an SDP was not being relayed to another Leg, even when the E2E Re-Invite and statusCode4xx6xx are enabled.

Root Cause: A 491 Relay logic is missing for the Re-Invite without SDP case.

Steps to Replicate:

1. Enable the E2E Re-Invite and the statusCode4xx6xx.
2. A 491 will be received for Re-Invite without a SDP sent.

Platform/Feature: SBC

Portfix SBX-95264: Calls stopped working after an upgrade to SBC5110 from V05.00.05F008 to V06.02.03F005.

Impact: In the X-dmi parameter, the "p=0.0.0.0" was changed to "p=" in 6.2.3F5 that was failing the parser.

Root Cause: The root trigger was the change in the IPUtilGetStr() since early 6.2 release checks the given ipAddr is a V4 or V6 address. In this case, the ipAddress was unspecified, so IPUtilGetStr() returns '\0'.

Steps to Replicate: The steps cannot be reproduced.

Platform/Feature: SBC

The 488 Response to the T38 Reinvite.

Impact: For a G.711-T.38 Fax call, if the SBC receives a G.711 reInvite with some change in SDP from ingress peer, then the SBC sends a G.711 reInvite to egress peer.

The customer expected the SBC to stay in a Fax call and not send any reInvite to the Egress peer.

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

Steps to Replicate: The steps cannot be replicated.

Platform/Feature: SBC

The code is modified so when the SBC detects a change in the SDP for a Fax call LEG, and if the codec active for that fax call LEG is G711 and there is no change in G711 LAW, then SBC stays in a Fax call and sends the 200OK with answer-SDP as per last offer-answer negotiation. Any change in DTMF, silence Suppress mode and any other SDP parameter is ignored.

Portfix SBX-96524: Getting the Pes Process coredump while running registrations.

Impact: Getting the Pes Process coredump while running registrations.

Root Cause: CallParamMatchName function is called with matchName which is of 15 byte array and strncpy is used to copy the string to the 50 byte array but with a wrong size of MATCH_NAME_SIZE which is defined as 30 byte*.*.

Passing bigger size than the actual destination string to strncpy is resulting in padding 0’s beyond the actual 15 bytes of the matchName. This was corrupting the stack and the stack pointer and causing a segmentation fault.

Steps to Replicate: The steps cannot be reproduced.

Platform/Feature: SBC

The SBC is not sending the RTCP to egress Peer for transcode only.

Impact: In the customer call flow:

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

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

Steps to Replicate:

1. Reproduce the problem in following call flow:
   Ingress Peer -- SIP -- GSX -- GW2GW -- SBC -- SIP -- Egress Peer
   This transcode only call and RTCP is enabled.
   Result: No RTCP sent by the SBC to egress.
2. Verify the issue by applying SamP with GWFE change but not change in ScmP.
3. Use the same setup. RTCP traffic was sent from the SBC to egress.

Platform/Feature: SBC

Portfix SBX-89741: There was a CPX core during an upgrade from V05.01.05R000 to V07.02.01R001.

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

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

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

Platform/Feature: SBC

Multiple switchovers causes non 5060 sipSigPorts to become inactive.

Impact: When a user configured >= 2 SIP Sig ports with same IP address but different port numbers, and they are using the same LIF group that contained 1 LIF, the pkt down triggered a switchover and it stayed down for extended time. After the pkt UP, a second switchover occurred, then only one Sig port went in service. The other Sig ports were stuck in OOS.

Root Cause: Since the pkt port was DOWN when the new standby node came back online, the SIP sig ports were restored while LIF was OOS. So address registrations were failed. After the SIPCM has reached a max number of retries, the LADDRs of the Sig ports, except the first one, were deleted in the NRS context.

When the pkt port came UP, the NRS brought LIF into service and registered the only one signaling address saved in the NRS context.

Steps to Replicate:

Test steps:
1. Configure 2 VLANs on the YF or BF pkt2.
2. Configure 4 SSPs on the first VLAN interface; 4 SSPs on the second VLAN interface. 4 SSPs use the udp/tcp port numbers 5060, 5160, 5260, and 5360 with the same IP address
3. Run the Sbxstop command.
4. Unplug the packet ports - YF pkt2
5. Run the Sbxstart command.
6. Display the SSPs on VLAN interfaces.

Platform/Feature: SBC

1. The code is modified to only delete LADDR before reaching the max number of retries.
2. Restore the pendingNrsReq flag properly when the address registration failed.

After the LDG triggered a switch over, the SBC is rejecting all the register message with a 500 internal error.

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

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

Steps to Replicate: The steps cannot be reproduced.

Platform/Feature: SBC

The SCM fast memory increase causes a delayed switchover with an outage.

Impact: If a multilevel INVITE with Replaces is run, the memory and CPU utilization by the Scm Process increases drastically and leads to a core dump.

Root Cause: Each INVITE with Replaces is a new Callgroup. Each call group has its own segments. For each segment, there are associated segments.

When a Release call is invoked, it releases all segments and each call segment frees the associated call segments.
During the release flow for such a call CC_EV_ASG_DISC_CMD event is posted multiple times for various orig and term GCID’s.

Please note that this ultimately frees up everything although the memory and CPU utilization shoots up.

Steps to Replicate:

1. Test multilevel INVITE replaces (more than 15).
2. Crash will not occur.

Platform/Feature: SBC

Now in the CC state machine, the CC_EV_ASG_DISC_CMD event is not posted multiple times for the same original and term labels. This leads to drastically reducing the looping, while also ensuring that all call segments (and associated segments) are freed.

The SBC fails to relay the 18x/2xx towards the ingress when the SBC is configured to play tone.

Impact: The SBC Fails to relay the 18x/2xx in case of the MSRP call when tone is configured. The SBC tries to allocate tone Resources even though the Audio stream is not present.

Root Cause: The SBC is going for Tone allocation, even though audio stream is not present.

Steps to Replicate: Run a MSRP call with the tone configured.

Platform/Feature: SBC: Application

Portfix SBX-91871: The metavar was assigned to none.

Impact: When only one of the nodes detects a network glitch in the N:1 setup, usingMetavarsOf field of the other node is set to none.

Root Cause: A metavar response message is not sent from the node that did not detect the network glitch.

Steps to Replicate: Bring down the HA link for less than 5 seconds such that only one node detects the network glitch.

Platform/Feature: SBC

Unable to establish the same number of sessions after the switchover.

Impact: Calls were getting cleared under load conditions after a switchover in the first gateway in a GW-GW setup.

Root Cause: When sessionKeepAlive is set and the SBC switched over, the SBC starts sending refresh INVITEs to the endpoints. Since this is a GW-GW setup, in such scenario's, the newly active GW-1 will send call processing messages to the GW-2. There was an issue in call processing at the GW-2 that resulted in call failures.

Steps to Replicate:

1. Create a SBC GW-GW setup and enable the sessionKeepAlive.
2. Establish a call load of more than 25K and once the call is stable, perform a switchover at the GW-1.
3. Calls will start failing

Platform/Feature: SBC

The SBC picks up an incorrect TG for incoming non-INVITE requests and responses to non-INVITE requests.

Impact: The SBC is picking up the wrong trunk group for incoming messages.
This is specific for a rare configuration when there is only 1 sigport sharing multiple trunkgroups, and the same peer source address routing traffic to different trunkgroups.

Root Cause: When the SBC processes inbound/outbound messages, it puts the TG into the cache table for processing after the response. In this case, there are two trunkgroups that swap back and forth for the same peer address. As a result, a subsequent request OOD may pick up the wrong TG due to registered end point.

Steps to Replicate: 

1. Run a configuration where there is only 1 sigport sharing multiple trunkgroups, and the same peer source address routing traffic to different trunkgroups.
2. Call B was sharing the same signaling port and the same peer IP.
3. An OOD to the SBC and route back to A.
4. Both outbound cases are using different TGs.

Platform/Feature: SBC

An incorrect transparency functionality causes calls to fail.

Impact: The To header transparency becomes active and launches a successful ENUM query may cause an incorrect RURI format. 

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

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

Platform/Feature: SBC

Portfix SBX-98992: The EMA logs are not being copied in SysDump, however, the folder is there.

Impact: The EMA logs are not captured by the sysdump. 

Root Cause: The EMA log location was changed in the 6.0.0 and the sysdump was never updated with the change.

Steps to Replicate: Run sysdump and verify the EMA logs are captured.

Platform/Feature: SBC

The EMA response time on the SBC 7.2.3 release is very high.

Impact: The EMA response time on the SBC 7.2.3 release is very high.

Root Cause: Making more than six TCP calls at a time from the browser.

Steps to Replicate: 

1. Log in to EMA.
2. Route from Configuration->System Provisioning-> Routing

A user can see the efficiency of screen loading.

Platform/Feature: SBC

The Scm Process cored.

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

Root Cause: Access the null pointer.

Steps to Replicate: The steps cannot be reproduced.

Platform/Feature: SBC

The Wall Comcast PM-SBC memory increasing.

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

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

Steps to Replicate: The steps cannot be reproduced.

Platform/Feature: SBC

The SIP to SIP call no ring back tone passed to the ingress when PEM header is enabled on egress endpoint.

Impact: There was no RBT when the PEM header is enabled, the Split 18x moves into alerting and progress flag is enabled.

Root Cause: This flow was never tested with flag, and with Split 18x into alerting and progress.

Steps to Replicate: Setup call with PEM enabled on the egress and with Split 18x flag enabled.

Platform/Feature: SBC

The caller SBC cancels the call after a 180 : 504 to the ingress, and CANCEL to egress.

Impact: A late media convert call with the DLRBT is not working.

Root Cause: A bad resource activation.

Steps to Replicate: Setup a late media convert call with the DLRBT enabled.

Platform/Feature: SBC

Portfix SBX-95874: The SBC's dump SCM process when running a MSRP call with the LI enabled.

Impact: The SCM process dumps when running a MSRP call with the PCSILI enabled.

Root Cause: The SBC sends an invalid Stream ID for non audio calls in NrmaDsbcSendDummySplitterCmd() and NrmaDsbcSendSplitterCmd() when invoking NrmaDsbcIssueXresCmd(). In the M-SBC, when processing the same correct stream, the EP res is not fetched because of an invalid stream ID and is why the SYS_ERR is triggered.

Steps to Replicate: Running a MSRP call with the PCSILI enabled.

Platform/Feature: SBC

The wrong codec selection for the LRBT when one 183 with the SDP followed by two 180 Ringing.

Impact: The Ingress Trunk had theSIP-I and LRBT enabled and the Egress side Trunk is configured with the SIP.

The transcode conditional is enabled and the AMR-WB , AMR ,G711 and G729 are present in the Ingress and Egress Route PSP. Transcoding for AMR and AMR-WB is disabled but enabled for the G711 and G729.

After the INVITE OFFER is relayed by the SBC to Egress, the SBC receives the 183 with pcma followed by two 180 ringing alerts from the Egress.

The SBC should send 183 with PCMA in the SDP but instead it sends amr-wb, the first codec from the Offer, to the Ingress and as a result the tone is played in AMR-WB, which is incorrect.

Root Cause: For every 180 ringing alert received from the Egress, the tone is stopped and restarted. During the second tone restart, the SBC makes a new Offer with a Route PSP and discards the current answer received from the Egress Peer.

Steps to Replicate: The steps cannot be reproduced.

Platform/Feature: SBC: SIP Applications

Portfix SBX-97856: A bad Update sent by the SBC to Ingress during the LRBT.

Impact: The SIP-I on the Ingress TG and the SIP on the Egress TG.

With the transcode conditional enabled, the AMR-WB transcoding disabled in PSP and LRBT enabled, when making a call, during the LRBT, the Egress peer sends an update with change of media port but the SBC sends unwanted UPDATE towards ingress side with the AMR-WB / 16k DTMF

Root Cause: After an update followed by 180 ringing alert is received from the Egress Peer with change in the port only, the SBC generated a new Offer to the Ingress with a Route PSP codec preference of AMR-WB discarding the active codec PCMA already negotiated.

Steps to Replicate: The steps cannot be reproduced.

Platform/Feature: SBC

Portfix SBX-94395

Impact: RTCP Packets discarded.

IPv6 to IPv4, NAT enabled on V6 side – RTCP Packets discarded for Audio+T140 call after call modify.

Root Cause: For non-audio streams call-modify scenarios, the optional spec flag to mark the IP version was not set in the NP Interface.

Steps to Replicate: None.

Platform/Feature: SBC

A SCM leak on the Standby.

Impact: The SCM may leak memory in calls with a SIP Relay and FQDN. The memory used to store the Domain information may be leaked.

Root Cause: There is an edge case where the memory used to store the Domain information for a SIP Relay call is not being freed.

Steps to Replicate: This issue has been found by a code inspection and the steps to reproduce this case have not been identified.

Platform/Feature: SBC

Portfix SBX-94512: The RTCP packets count is not getting populated consistently in the callMediaStatus.

Impact: With the RTCP relay monitoring feature, sometimes the RTCP packets are not relayed or discarded.

Root Cause: In the SWe NP, due to endian alignment code issue, the RTCP mode configuration flags were not set as per the call flows enable/modifications.

Steps to Replicate: This is sporadic, when multiple times RTCP REL MON call flows, modifications tried it might occur.

Platform/Feature: SBC

The SipSgProcessRelayRequestPrimitive: relay an INVITE without the cpcOrigMsgInfoPtr.

Impact: A increase in the DBG logs filling up with SipSgProcessRelayRequestPrimitive messages.

Root Cause: In case of an End2End Re-INVITE, the log message does not have any impact.

Steps to Replicate: The log level changed on the basis of code analysis and description.

Platform/Feature: SBC

A large increase in sonusSbxSscsRouteFailureWithoutGapNotification2 traps.

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

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

Steps to Replicate:

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

Platform/Feature: SBC

Portfix SBX-93967: Direct dial to a call queue, and then transfer to agent fails.

Impact: For the PSTN to Teams calls, when Teams was triggering an INVITE with replaces, perform a subsequent REFER. The SBC was not relaying the REFER-TO information from the REFER message to the subsequent INVITE. This was resulting in the wrong information being sent back to MS Teams and the call failed.

Root Cause: The SBC was not relaying the REFER-TO information from the REFER message to the subsequent INVITE.

Steps to Replicate: In a MS Teams setup run a call Q and transfer scenario where the call originates from the PSTN side.

Platform/Feature: SBC

External PSX became active after a switch over, though it was the OOS prior to the switch over.

Impact: When changing the multiple remote policy servers' mode together in one "commit", some of the server's operational stats in the standby node might not be synced.

Root Cause: When one of the remote policy servers' mode was being changed from the OOS to active, the standby node will not try to register with this server, and the iteration of all mode change servers will be stopped. This causes the rest of the servers, whose operStats have not been changed and remain unchanged. Therefore, the operStats of these servers at standby node will be out of sync with the active node.

Steps to Replicate:

1. In a working HA, provision at least 3 working remote policy servers.
2. While keeping the admin stat at enabled, only keep 1 of the servers mode as active, and rest are out of service.
3. Change those servers' mode, commit only after all the set commands finished.
4. Display the status using the 2 commands below:
   "show table system policyServer remoteServer"
   "show table system policyServer policyServerStatus"
5. Perform a switchover.
6. Repeat step 4. The operStat will be different from step 4.
7. Making call load, may be a load call rate, when the Node A is active, and then when the Node B is active. When the Node B is active, the policy request may still be sent to the remote server that you have already made the OOS when the Node A was active.

Platform/Feature: SBC

Calculated the size of a buffer as too small and error logs were being generated post upgrade.

Impact: Removes this incorrect log message:

SipsRedGetCallControlSizeCmd()
Minor .SIPSG: *SipsRedMirrorCallControlCmd: Potential for buffer
format ERROR. Available:16076 Calculated:383 Packed:277

Root Cause: This message is logged incorrectly when the code is calculating the size for a Redundancy message.

Steps to Replicate: The steps cannot be replicated.

Platform/Feature: SBC

The code is modified to remove this incorrect log message:

SipsRedGetCallControlSizeCmd()
Minor .SIPSG: *SipsRedMirrorCallControlCmd: Potential for buffer
format ERROR. Available:16076 Calculated:383 Packed:277

Portfix SBX-93456: The SWe NP worker has a segfault.

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

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

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

Steps to Replicate: Run JIO scenarios.

Platform/Feature: SBC

The RTP Inactivity Timer fires early upon performing a port switch-over on the M-SBC.

Impact: If a call starts out with no RTP packet at all, the RTP Inactivity Notification is triggered earlier than the configured threshold. This is only observed on the SWe SBC.

Root Cause: The timestamp used for inactivity detection is not set when the media resource is enabled in the network processor code.

Steps to Replicate: Run a test that establishes a call where the ingress peer does not send RTP. There are no switchovers or other events and the calls are disconnected before the timer expires. The timer is set to 30 seconds.

Call service Duration with a disconnect 145.

Platform/Feature: SBC

The SBC fails to route in advance to the 13th route.

Impact: When the PSX has more than 10 routes configured and all routes in the first policy response fail due to an internal cause, the call fails because the SBC cannot handle more routes correctly.

Root Cause: When the PSX has more than 10 routes configured and all routes in the first policy response fail due to an internal cause, the SBC's NRMA subsytem returns with an allocation failure.

Steps to Replicate:

1. Configure more than 10 routes on the PSX.
2. Force a failure on the first 10 routes due to an internal error.
3. Verify the call gets established on the routes in second policy response.

Platform/Feature: SBC

Portfix SBX-91398: The ASAN heap-use-after-free on the address DnsClientQueryServerCmd.

Impact: The DNS client running in the SBC while trying to query the DNS server, tries to identify the transport protocol used. If the query fails on the first server, it accesses the first DNS server's data structure to get the type of transport protocol.

Root Cause: This issue was reported as part of the ASAN Testing on the DNS regression suite in the SBC lab.

Steps to Replicate: This issue was found while running the DNS regression test suites.

Platform/Feature: SBC

The SBC fails to relay the 4xx-6xx responses when the IPTG authentication is enabled - all SIP causes are mapped to the CPC176 CPC_DISC_TG_AUTH_FAIL.

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

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

Steps to Replicate:

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

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

Platform/Feature: SBC

The SAM Process cores when the SNMP walk commands are executed during the TLS load.

Impact: When the getTlsSessionStatus command is executed when the TLS load is running, it will result in a SAM Process core.

Root Cause: The issue is because the SIPCM expects the SSL_get1_session() to increment the reference count of the SSL socketPtr. After the SIPCM returns from the SSL_get1_session() tries to decrement, the reference count during the time the socketPtr was deleted by another thread, which results in a double free.

Steps to Replicate: The steps cannot be reproduced.

Platform/Feature: SBC

The SIP OPTIONS was not responding after a failover.

Impact: A syntax error message during a switch over is unable to respond.

Root Cause: Internal messages drop due to other subsystems not being ready to process the message. Subsequent messages are stuck in the queue.

Steps to Replicate: Simple ping Options messages during a switchover.

Platform/Feature: SBC

The IPv4 Path MTU Discovery (RFC1191) was not working.

Impact: The IPv4 Path MTU Discovery (RFC1191) does not work.

The SBC uses the MTU of the outgoing network interface as the Path MTU.
Without the fix, the SBC does not update the Path MTU properly even if a router in the path sends "ICMP Destination Unreachable Fragmentation Needed" message with a smaller Path MTU value. The large packets requiring fragmentation to fit the Path MTU from the SBC will not reach the SIP peer.

Root Cause: In performing a route/fib, lookup in the updating Path MTU from "ICMP Destination Unreachable Fragmentation Needed" message did not consider the ipInterfaceGroup and addressContext. This resulted in not updating Path MTU of the proper route entry to the peer.

Steps to Replicate: The SBC sends IP packets of a length 1500 bytes toward the SIP peer when a path to the peer has a smaller MTU (e.g. 1400 bytes). A router with the smaller MTU sends "ICMP Destination Unreachable Fragmentation Needed" to the SBC. The SBC, with the fix, adjusts the Path MTU, performs the fragmentation and sends fragments to the SIP peer.

Platform/Feature: SBC

The lwresd process on the active node is killed when a reboot is issued.

Impact: When a reboot is issued at the command prompt on the active node, the slwresd process is killed prior to it being properly shutdown. This causes a delay in reboot processing as the system goes through a fault recovery processes rather than an expedited shutdown.

Root Cause: The reboot wrapper that kills a non-SBC processes and using the drbd mount point was inadvertently killing the swlresd process.

Steps to Replicate: On the active CE, issue a reboot at a command prompt.

Platform/Feature: SBC

A large number of TLS error messages were in DBG log.

Impact: The following log message was filling logs due to being incorrectly logged at the MINOR level (when it should have been at INFO level):

Minor .SIPSG: sipsgUtils.c (-27373) 27050. SipSgLogLevel4: missing callId need to parse

Root Cause: The following log message was incorrectly being logged at the MINOR level (when it should have been at INFO level):

Minor .SIPSG: sipsgUtils.c (-27373) 27050. SipSgLogLevel4: missing callId need to parse

Steps to Replicate: The only change was to change a log message from MINOR to INFO - there was no testing necessary.

Platform/Feature: SBC

The code is modified to change the following log message from MINOR to INFO:
Minor .SIPSG: sipsgUtils.c (-27373) 27050. SipSgLogLevel4: missing callId need to parse

Portfix SBX-89018: The ASAN heap-buffer-overflow in the CpcOptionalParameterSave from the SipSgCopySipUrlToCpc

Impact: When an INVITE arrived to start a new call, the SIP service group control "callRouting useRouteSet" is set to the value of "received" to try and route the call based on the routeset in the INVITE. While processing the URI information in the header and trying to map it into internal structures, the code was reading off the end of a memory block. This setup can cause a crash if the memory block is at the end of the heap.

Root Cause: The code was trying to apply a 4 byte alignment to the internal parameter length after the memory had already been allocated. This meant that sometimes, the parameter length got set to a larger value than the memory block size.

Steps to Replicate: This problem was identified while running ASAN testing in the Ribbon lab and cannot be reproduced using normal images.

Platform/Feature: SBC

A backup/restore file cannot be downloaded from the EMA if the file name contains a dot (.).

Impact: A backup/restore file cannot be downloaded from the EMA if the file name contains a dot (.).

Root Cause: In the downloadSavedConfig block, making an API call both the time (Running on the SBC or running on the EMS).

Steps to Replicate:

1. Login into EMA.
2. Navigate to
   Administration -> System Administration -> Backup/Restore
3. Download the Backup file.

Platform/Feature: SBC: EMA

Portfix SBX-72499: The PesP cored on the active node.

Impact: The PesP cored on the active node.

Root Cause: The Ref count is getting incremented and once it reached the max value, it is becoming zero and destroying the object in one thread. At the same time, the other thread is accessing the object and crashing.

Steps to Replicate: Keep running calls for a longer time by using only one IpSignalingProfile.

Platform/Feature: SBC: Application, ERE

Portfix SBX-95097: The SBC is sending incorrect RACK in the PRACK for a Late Media Call.

Impact: The SBC is sending incorrect RACK in the PRACK for a Late Media Call.

Root Cause: Whenever the PRACK with SDP comes as an answer, the PRACK entry holding RSEQ details is not getting removed from the list while being sent out, because of any subsequent 18x/PRACK without SDP coming out at the same time; the SBC is adding old RSEQ in RACK.

Steps to Replicate: Late Media call with first 18x and PRACK with SDP followed by an 18x and PRACK without SDP.

Platform/Feature: SBC

Missing the Egress Response Code in the Field 59.19.

Impact: Egress error response code is not updated for the SIP response “487 Request Cancelled” in the field number 59.19 in ATTEMPT CDR record.

Root Cause: In the “487 Request Cancelled” case, because there is no CANCEL sent for the INVITE, the correct function is not called that is responsible for adding field number 59.19 in the ATTEMPT CDR record.

Steps to Replicate: Set up the SBC to make a simple call flow as below, and check the CDR for field 45.19/20 and 59.19/20:

UAC.xml SBX UAS.xml
| | |
| INVITE | |
|=======>| |
| 100 | |
|<=======| |
| | INVITE |
| |=====>|
| | 487 |
| |<=====|
| | ACK |
| |=====>|
| | |
|480 | |
|<=======| |
| ACK | |
|=======>| |

Platform/Feature: SBC

Portfix SBX-95749: The SBC is not adding the Contact header in the 200 OK of UPDATE for a session refresh UPDATE.

Impact: The contact header is missing in the 200OK sent by the SBC for a session refresh UPDATE (an UPDATE without SDP or an UPDATE with the same SDP as last SDP).

Root Cause: The contact header is missing in the 200OK sent by the SBC for a session refresh UPDATE (an UPDATE without SDP or an UPDATE with the same SDP as last SDP).

Steps to Replicate:

1. Enable the E2E Update.
2. Trigger an UPDATE without SDP or an UPDATE with same SDP as last SDP.

Platform/Feature: SBC

The SBC was using the incorrect SIP signaling port for the challenged SUBSCRIBE.

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

Root Cause: When the usePortRangeFlag is enabled, the SBC may use an incorrect SIP Signaling Port when handling a SUBSCRIBE request with an Authorization header to the egress peer.

Steps to Replicate:

Provision the SBC to support CUCM (Cisco Unified Connection Manager) .
Ingress zone / sipTrunkGroup:
set addressContext default zone ZONE2 sipTrunkGroup SBXSUS4_LABSIP1 signaling registration requireRegistration required
set addressContext default zone ZONE2 sipTrunkGroup SBXSUS4_LABSIP1 signaling usePortRangeFlag disabled
set addressContext default zone ZONE2 sipTrunkGroup SBXSUS4_LABSIP1 signaling psxRouteForSubscribe enabled
commit

Egress zone / sipTrunkGroup:
set addressContext default zone ZONE4 sipTrunkGroup SBXSUS4_LABSIP2 signaling registration requireRegistration none
set addressContext default zone ZONE4 sipTrunkGroup SBXSUS4_LABSIP2 signaling usePortRangeFlag enabled
set addressContext default zone ZONE4 sipTrunkGroup SBXSUS4_LABSIP2 signaling psxRouteForSubscribe disabled
commit

set profiles signaling ipSignalingProfile DEFAULT_SIP commonIpAttributes relayFlags dialogEventPackage enable
commit

Perform REGISTRATION.

Perform a challenged SUBSCRIBE.

Platform/Feature: SBC

Co-existence of 4xx-6xx IPSP flag and Subscribe crankback is not working.

Impact: Out of dialog message fails to crankback when the relay 4xx-6xx is enabled.

Root Cause: The relay flag must not take precedent.

Steps to Replicate: Configure the crankback and enable relay 4xx-6xx flag. The subscribe response with failure must be able to crankback.

Platform/Feature: SBC: SIP

Portfix SBX-95941: An unknown header transparency flag interaction with Tagging.

Impact: STIR-SHAKEN related headers are duplicated when the STI service type is tagging and transparency is enabled.

Root Cause: This scenario was not handled when STIR-SHAKEN was supported in 7.2.0.

Steps to Replicate: STI Profile is assigned on Ingress and Egress TG, on Ingress STI Profile “Override P-Headers with configured values”  flag is enabled.

In egress IPSP (IPTG section) “Unknown header” transparency flag is enabled.

Platform/Feature: SBC

Portfix SBX-91996: The SBC fails to send a=fmtp parameter towards the UAC, when the SBC received a=fmtp parameter above a=rtpmap in the answer from UAS.

Impact: The SBC fails to send a=fmtp parameter towards the UAC, when the SBC received a=fmtp parameter above a=rtpmap for the Dynamic Payload in answer from the UAS.

Root Cause: When the FMTP line is received prior to the RTP line for a dynamic payload, Internal Logical issue is causing the issue. When the string holding FMTP line is terminated with \0, the SBC unable to parse manually.

Steps to Replicate:

Test Configuration:
==============

1. The SBC must be configured to handle the AMR passthru call.
2. The transcoding must be set as conditional.

Test Procedure:
=============

1. The UAC sends Invite with AMR WB codec.
2. The UAS sends 180 Ringing with AMR with following SDP:

m=audio 6084 RTP/AVP 106 100
a=fmtp:106 mode-set=0,2,5,7;max-red=0
a=rtpmap:106 AMR/8000
a=rtpmap:100 telephone-event/8000

Platform/Feature: SBC

Portfix SBX-93360: The SBC was sending an INVITE with the SRTP instead of RTP.

Impact: The SBC is sending the SRTP instead of RTP.

Root Cause: The intersection of working PSP and peer PSP does not take place in the stream absent case. The SRTP values are never updated.

Steps to Replicate:

1. Create a UAC with RTP.
2. Create two UAS with SRTP param.
3. Send a port =0 for hold response.
4. Check if the SBC is misbehaving while sending an INVITE to release hold from the far end.

Platform/Feature: SBC

Portfix SBX-71623: The SMM header criteria not matching complete header value.

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

Root Cause: The SMM value being checked is enclosed between <>.

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

Platform/Feature: SBC: Application

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

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

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

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

Platform/Feature: SBC

Disable media lockdown does not suppress the media lockdown re-INVITE when the SRTP is enabled.

Impact: If the SBC offers crypto, and peer does not reply with crypto in the answer, a re-INVITE is sent to lockdown the crypto attribute (no crypto). If NAT is enabled, there is one second media drop while re-learning for the new re-INVITE is happening. For non-NAT cases, nothing will be observable except for signaling change.

Root Cause: This issue was SBC's original behavior.

Steps to Replicate:

1. Setup the SBC so that it sends a crypto in offer.
2. In the answer from the peer - do not send any crypto attribute.

Without a fix, the SBC will send another re-INVITE if the fallback to unencrypted is allowed. With a fix, this extra re-INVITE will be suppressed.

Platform/Feature: SBC

The R-URI in NOTIFY messages was not using the correct port number in case of TLS.

Impact: The SIP NOTIFY messages relayed through the TLS, may contain a R-URI that uses the SIP signaling port number verses the TLS port number.

Root Cause: The relay software used the SIP signaling port number instead of using the TLS port number.

Steps to Replicate: The steps cannot be reproduced.

Platform/Feature: SBC: Call Control

When the SBC receives route header with a port and TLS, it increments the port number.

Impact: When the SBC receives route header with a port and TLS, it increments the port number.

Root Cause: The SipSgPopulateAndSendToEgress() incorrectly increments the TLS signaling port number, when an out-of-dialog SIP OPTIONS message being relayed contains a "transport=TLS" parameter in the top most ROUTE header, and TLS transport is used.

Steps to Replicate: When the SBC receives OPTIONS with the Route header, the SBC relays that OPTIONS to a Port+1.

Platform/Feature: SBC: SIP

The PrsP cored on the standby SBC node.

Impact: The standby PRS process core was triggered from the XRM, when processing the XRM_DEALLOCATE_CMD_MSG from the standby SIPFE before the XRM has received the RTM_SYNC_TO_ACT_START_NFY_MSG.

Root Cause: There were many registration bind timeouts reported on the active SIPFE that triggered deallocation of the registration blocks and closing of port range connections. An active SIPFE mirrored the port range connection close requests to the standby SIPFE that triggered XRM_DEALLOCATE_CMD_MSG being sent to the standby XRM. The bug was that active SIPFE used regular ICM alloc/send mechanism to send the redundancy requests while standby node was in the middle of sync to active node.

Steps to Replicate:

1. HA pair, SIP registration load test, with high number of registrations.
2. Cause registration binding timeouts.
3. Restart the standby node.

Platform/Feature: SBC

The 4 SCMs cored after switchover.

Impact: The SCMs have cored after a switchover.

Root Cause: There is a bug that allows the RTM to attempt to process the Call Audit fault while still in the STANDBY mode. Since the Call Audit fault must only be processed while in the Active Mode - this causes a core.

Steps to Replicate: The steps cannot be reproduced.

Platform/Feature: SBC

Portfix SBX-74922: Modem calls failing when the DSP engaged in the ingress SBC.

Impact: The Bell 103 Modems in a G711-G711 transcoded call does not succeed.

Root Cause: The SBC G711-G711 transcoded calls perform a DTMF detection and the removal operation that can falsely remove some short signals, which is fine for speech perception but can affect modem signals that have similar characteristics of some modem signals. The SBC has signal detector for more modern modem that send a 2100 Hz tone to precede actual modem transmission. Once that is detected, the DSP media handling disables the DTMF removal. The SBC, however, does not detect older modems that sends a 2225 Hz signal in the beginning.

Steps to Replicate: 

1. Make a G711-G711 forced transcoded call. Ensure that both legs have the DTMF remove enabled (dspchanstat).
2. Use modem2225g711.pcap that has the modem signal captured from the customer in the ingress.
3. Collect the media capture for the call and inspect the dspchanstat, as well as the output signal from egress.
4. The dspchanstat and faxconfirmed field show 0x0. Signal output shows drops in the FSK modem signal between 18.72 and 19.65.

Platform/Feature: SBC

Port the fix for SBX-86420 to 6.2 and 7.2 code branch.

Impact: Whenever the TLS transport is selected, the SBC is trying to increment FQDN port by 1. In this case, even when FQDNPort is Zero in SIPSG/SIPS, the port is incremented by 1. So the FQDN port is set 1 because of this SRV query is not sent to the DNS server.

Root Cause: Whenever the TLS transport is selected, the SBC is trying to increment FQDN port by 1. In this case, even when FQDNPort is Zero in SIPSG/SIPS, the port is incremented by 1. So the FQDN port is set 1 because of this SRV query is not sent to the DNS server.

Steps to Replicate:

1. Send an INVITE with the TGRP parameters in R-URI.
2. The SBC sends the TGRP information to the PSX.
3. The PSX does TGRP based routing and sends route.
4. The SBC must send the SRV query to the DNS to resolve port and IP details when egress peer is FQDN.

Platform/Feature: SBC

Portfix SBX-96170: When the SBC executes a "Teardown" to UPDATE request by the SMM, the To header and From header of response are malformed.

Impact: Write an SMM Rule to do a teardown on an UPDATE Request and Error Response has Malformed headers.

Root Cause: When a server request of UPDATE request is saved, optional headers are not being saved.

Steps to Replicate: Write a SMM rule to tear down update request with the 415 and the issue will be reproduced.

Platform/Feature: SBC

The direct media (release) not working, no x-dmi to BSFT in the 200 OK while the 18x has it.

Impact: The 200OK behindNapt and direct Media support is unable to treat as direct media.

Root Cause: The issue is due to an internal offer/answer update after the first 18x, the previous flags for behind NAPT was lost.

Steps to Replicate:

1. Ingress configuration behind Napt and direct Media support.
2. Egress sends the SRTP Invite and peer response 18x with non-secure RTP. Subsequent 18x/2xx sent to ingress is missing x-dmi line.

Platform/Feature: SBC: Media, Platform, SIP

To TAG broken when dialogTransp enabled and downStreamForking enabled.

Impact: When the dialog transparency, downstream forking and end to end PRACK is enabled, the SBC intermittently sends incorrect tagging in outgoing PRACK towards the egress.

Root Cause: A previous fix (SBX-63508) tries to address the scenario where downstream forking is enabled, dialog transparency is enabled and the 183 for the second dialog comes before PRACK when the first dialog is sent. But the pstCall structure was pointing to memory that may have been freed and re-used for storing some other SIP Message. So the To Tag sent from the SBC in an ACK message was incorrect.

Steps to Replicate:

1. Enable Downstream forking, dialog transparency and E2E PRACK.
2. Outgoing ACK from the SBC to egress has incorrect to Tag.

Platform/Feature: SBC: SIP

Portfix SBX-96448: ICE not getting completed when the simultaneous ringing is enabled.

Impact: When simultaneous ringing is enabled to multiple MS teams endpoints, in certain cases where the ICE STUN requests are received by the SBC before an SDP is received in signaling messages, ICE is not getting completed for the endpoint that answers the call resulting in media to and from that endpoint not flowing through the SBC.

Root Cause: The SBC answers the first STUN message with a use candidate and completes ICE learning for that endpoint. Subsequent stun messages from other endpoints with use candidate were answered but ignored for ICE learning.

Steps to Replicate: With simultaneous ringing enabled to two MS teams endpoints, initiate call through the SBC to MS teams and verify that irrespective of when the endpoint answers the call voice media can flow through the SBC. Test must be repeated around 10 times and call answered from a different end point each time.

Platform/Feature: SBC

Portfix SBX-95170: To allow early RTP ICE learning for the MS teams DLRBT media bypass scenarios.

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

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

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

Platform/Feature: SBC

Upgrade set all the CNAM Trunks to a Subscribe Rate of 1.

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

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

Steps to Replicate:

Configure SIP Trunk Group CAC ingress/egress subscribeRateMax and subscribeBurstMax, for example:
% set addressContext default zone ZONE sipTrunkGroup SIPTRUNK cac ingress callRateMax 1 callBurstMax 1 registerRateMax 1 registerBurstMax 1 callLimit 0 emergencyOversubscription 0 extendedEmergencyIpLimit 0 subscribeRateMax 10 subscribeBurstMax 20 otherReqRateMax unlimited otherReqBurstMax unlimited hpcOversubscription 0
% commit
% set addressContext default zone ZONE sipTrunkGroup SIPTRUNK cac egress callRateMax 1 callBurstMax 1 registerRateMax 1 registerBurstMax 1 callLimit 0 emergencyOversubscription 0 extendedEmergencyIpLimit 0 subscribeRateMax 10 subscribeBurstMax 20 otherReqRateMax unlimited otherReqBurstMax unlimited hpcOversubscription 0

Perform an LSWU upgrade.

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

Platform/Feature: SBC

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

Impact: The file /etc/fstab had an incorrect UUID for SWAP partition due to the timeout logs were seen on the boot-up.

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

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

Platform/Feature: SBC

The SMM writeCdr was failing to write to ATTEMPT CDR when acting upon 300 Multiple Choice.

Impact: The SBC is failing to write the SMM fields in the ATTEMPT CDR when acting upon the 300 Multiple Choice.

Root Cause: The code was missing to handle the SMM information for a Redirect Scenario in the CDR.

Steps to Replicate: Test Redirect cases, and ensure SMM CDR write operation is successful in ATTEMPT record.

Platform/Feature: SBC

Portfix SBX-94662: The SBC is unable to handle emergency calls (E911) when ICE is enabled.

Impact: When the call limit for ordinary calls is already consumed on a trunk group, a new 911 emergency call on that trunk group does not complete using the emergency call bandwidth if ICE is also configured on the trunk group.

Root Cause: An issue in software was not processing ICE data correctly when the call was transitioning from using ordinary bandwidth to using emergency bandwidth.

Steps to Replicate: With the SBC trunk group configured with ordinary call limit and additional emergency call limit and ICE enabled:

1. Establish as many calls as required routed via the trunk group to consume the ordinary call limit on that trunk group.
2. While the previous calls are active, initiate a new 911 emergency call to be routed via the trunk group and verify the call succeeds.

Platform/Feature: SBC: Media, SIP

Portfix SBX-96723: The Zone SMM Profile was not working when performing a sbxrestart/reboot.

Impact: The Zone SMM is not getting applied when performing a SBC restart.

Root Cause: The Zone SMM profile is not being restored during an SBC restart.

Steps to Replicate: Attach a Zone Profile with the fixed order, and run a call. The Zone SMM profile will be applied, and when performing a  SBC restart and running the call, the Zone SMM is not getting applied.

Platform/Feature: SBC

Portfix SBX-96937: Running the sysDump.pl on Openstack restarts the SBC.

Impact: Running the sysDump.pl on the 8.2.0R0 release on the SBC Openstack cloud platforms causes the SBC application to restart.

Root Cause: The openclovis is monitoring some files as markers, using notify and taking it down when the file open operations are done.

Steps to Replicate: Once the SBC application is up and running:

1. Run sysDump.pl and enter the default inputs.
2. The SBC application will not go down.

Platform/Feature: SBC

Portfix SBX-96939: The ImPr cored when the SBC was running a call load.

Impact: The SBC ImProcess cored when the LI server became unavailable.

Root Cause: When the LI server becomes unavailable and a large number of packets are queued up for that server, the ImProcess takes more than 10 seconds to clean up all those packets, and the process coredumps.

Steps to Replicate:

1. Establish a large number of LI calls.
2. Bring the LI server down.
3. Ensure that the ImProcess does not coredump.

Platform/Feature: SBC

7k DSP falsely detecting fax tone on music.

Impact: SBC falsely detects a modem tone (2100 Hz with phase reversals) for certain type of music.

Root Cause: Algorithm for modem tone detection first looks for 2100 Hz tone for 630 ms and a non-zero number of phase reversals. In certain type of rich harmonic tones, this results in large number of phase reversals. Typically for modem tones we expect no more than 2 phase reversals in 630 ms.

Steps to Replicate: Make g729 to g711 calls and stream the pcmu_stream1_withsilence3.pcap from the g711 leg.
Before a fix, a modem is detected on this signal as indicated in the dspchanstat.
tone2100PhaseRevCnt: 1.

Platform/Feature: SBC: DSP

The SBC does not send invite to subsequent routes in native forking when the SBC receives Invite with call-ID as "i".

Impact: An incoming short callId header "i" fails to send subsequent Invite for multi routes.

Root Cause: There was missing logic to look for callId header with a short name.

Steps to Replicate: Configure the native forking call and have incoming call with short name "i' for callId header.

Platform/Feature: SBC

TLS call failures were observed due to a port value set to 1 instead of 5061.

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

Root Cause: The issue is because when the route header is received without a port in it, the SIPSG was incrementing the port for the TLS. Since the port was not received, the port received is considered as 0. For the TLS, increment by 1. When incremented, the port becomes 1 and this gets used for sending an INVITE that is resulting in calls failing.

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

Platform/Feature: SBC

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

Asymmetric PRACK Interworking was not working as described.

Impact: Whenever any codec entry is deleted from codec list in the PSP and in the PSX, it rearranges the codec list immediately. There will not be any empty codec entry in the list.

The same issue is in the ERE, so it can be treated as a bug in the ERE.

Root Cause: When any CodecEntry is deleted, it is not rearranging the CodecEntry, which causes a NULL value in that place.

Steps to Replicate:

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

Result: The call will be successful.

Platform/Feature: SBC: ERE

Update scripts in the common/debian/install/sbx-install and orca/install.

Impact: Monit paths needed to be updated with the new definitions.

Root Cause: New definitions were introduced for monit paths.

Steps to Replicate: The steps cannot be replicated.

Platform/Feature: SBC

The LCA errors seen when the SBC is spawned.

Impact: A sbcDiagnostic.sh flags error in the LCA, because it greps for ERROR.

Root Cause: The keyKeeper.py prints in the lca.log ERROR whenever it is unable to delete a file that contains a pswd. The file may already be deleted or not even created, this may also throw error.

Steps to Replicate: Run the sbcDiagonostic.sh and check no errors are present from keyKeeper.py.

Platform/Feature: SBC

Portfix SBX-96471: While trying to become active on a switchover, the systrem rebooted since the DRBD could not be switched to the primary.

Impact: While trying to become active on a switchover, the systrem rebooted since the DRBD could not be switched to the primary.

Root Cause: The DRBD is configured so that whenever a low level error occurs, the DRBD will be detached and the dstate will become "diskless". This scenario was leading the standby for reboot.

Steps to Replicate:

1. Run "drbdadm detach mirror" on standby.
2. Perform a switchover.
3. The switchover will be successful.

Platform/Feature: SBC

Portfix SBX-70059: Support the HOLD/RESUME INVITE from the SIPREC SRS to pause and start pumping media towards the SRS.

Impact: With a second SIPREC server call hold, the RTP recording is not paused/stopped towards recording server.

Root Cause: With the RTCP snoop enabled, the NP API handler has an issue in handling the media snoop configuration update with a SIPREC hold.

Steps to Replicate: Test the SIPREC hold features with the RTCP snoop enabled.

Platform/Feature: SBC

Portfix SBX-90855: The ASAN has a new-delete-type-mismatch on the SrchCriteriaIb.

Impact: The ASAN has a new-delete-type-mismatch on the SrchCriteriaIb.

Root Cause: The srchCriteriaIbArray is a dynamically allocated array in the GUISERVER, but it was not released using delete, so it is reported by ASAN.

Steps to Replicate: Re-run the testcase in the ASAN build and verify that the issue is not reported again.

Platform/Feature: SBC

The IPACL causes a PRS deadlock.

Impact: The PRS process may coredump after the state disabling and enabling ACL rule(s), performing a switchover by powering the CE off immediately, and state disabling and enabling ACL rule(s).

Root Cause: The PRS used stale socket connections after the power off immediate switchover.

Steps to Replicate: Reproduce the PRS coredump issue by performing the following:

1. Create the ACL rule using the installed role active CE when the HA system is synchronized (full redundancy protection).
2. Perform a switchover to the installed roll standby CE.
3. Wait until the HA becomes synchronized (full redundancy protection).
4. Using EMA to installed roll standby CE:
   Disable the ACL rule
   Enable the ACL rule
   Disable the ACL rule
   Enable the ACL rule
5. Verify that the system is synchronized.
6. Power off the installed roll standby CE "Power Off Server - Immediate" using the BMC.
7. Using EMA to installed roll active CE:
   Disable the ACL rule
   Enable the ACL rule <--- PRS CORED

Platform/Feature: SBC

The SBC was not releasing the other leg when a call is disconnected during hold( MOH enabled).

Impact: The SBC was not releasing the other leg when a call is disconnected during hold( MOH enabled).

Root Cause: This is a race condition in the CC where the handler for the event ASG_DISC_CMD is not present, and for the CC state CC_VIRT_ESCR_VDREQ due the call being hung.

Steps to Replicate:

1. Make a TEAMS to PSTN call.
2. TEAMS holds the call (MOH).
3. TEAMS disconnects the call during MOH.

Platform/Feature: SBC

Portfix SBX-94562: The ASAN has a heap-buffer-overflow in the SipSgACDMNaptQualTblAddEntry.

Impact: There was a Heap Buffer Overflow in the function SipSgACDMNaptQualTblAddEntry().

Root Cause: The Memcpy is being used instead of StrnCpyZ().

Steps to Replicate: Run the PCR 5637 regression on an ASAN Build.

Platform/Feature: SBC

Portfix SBX-94402: The SBC was not throwing a parse error in TLS if the content-length is not sent in a PRACK message.

Impact: The SBC is not throwing a parse error when the content-length Header is not sent in PRACK request using the TLS transport.

Root Cause: Similar code is present in the TCP Transport but not in the TLS-TCP transport.

Steps to Replicate: 

1. Make a TLS call with the 100rel enabled.
2. Send PRACK without content-length header for 18x.

Platform/Feature: SBC

Portfix SBX-94403: Unable to establish the same number of sessions after the switchover.

Impact: Calls were getting cleared under load conditions after a switchover in the first gateway in a GW-GW setup.

Root Cause: When the sessionKeepAlive is set and when the SBC switched over, the SBC starts sending refresh INVITEs to the endpoints. Since this is a GW-GW setup, a newly active GW-1 will send call processing messages to the GW-2. There was an issue in call processing at GW-2 that resulted in call failures.

Steps to Replicate:

1. Create a SBC GW-GW setup and enable the sessionKeepAlive,
2. Establish a call load of more than 25K and once call is stable, perform a switchover at the GW-1.
3. Calls now start failing.

Platform/Feature: SBC

Portfix SBX-94389: When call transferring to the PSTN, the SBC was sending RTP/AVP instead of RTP/SAVP towards Teams in the ReINVITE.

Impact: The SBC was sending a Re-INVITE towards Teams with m= line protocol as RTP/AVP instead of RTP/SAVP. Because of this, Teams is sending a 488 call was failed.

Root Cause: After an abort_ann_tone event, the CC was not moving to cutthru mode.

Steps to Replicate:

1. The 'Announcement based tones' flag is enabled.
2. Make a call from the PSTN - Teams n/w.
3. After a call connect, a Teams user transfers the call to another Teams user, and the call will succeed.

Platform/Feature: SBC

The Scm Process coredumps when there is NO ROUTE from the PSX = 0.

Impact: The Scm process coredumps when there is a call clearing with "no route found" from the PSX/ERE.

Root Cause: There was a bug in the call disconnect handler that resulted in the Scm crash for a non-configured number.

Steps to Replicate: Run a basic SIP call with a non-configured number and the Scm Process must not crash while handling the disconnect.

Platform/Feature: SBC: Application

The early media PEM has a behavior issue if there is no PEM in 18x.

Impact: When the egress TG early media method is P Early Media and the P Early Media header is not received, the SBC does not send media to the ingress caller.

Root Cause: The audio data path mode is set to inactive for the PEM structure.

Steps to Replicate: 

1. PEM Header transparency is enabled and the egress TG configuration is listed below:

set addressContext default zone IPX_SIGNALING_VOLTE sipTrunkGroup 1009074301 media earlyMedia method pEarlyMedia
set addressContext default zone IPX_SIGNALING_VOLTE sipTrunkGroup 1009074301 media earlyMedia egressSupport enabled
set addressContext default zone IPX_SIGNALING_VOLTE sipTrunkGroup 1009074301 media earlyMedia defaultGatingMethod sendrecv
set addressContext default zone IPX_SIGNALING_VOLTE sipTrunkGroup 1009074301 media earlyMedia forkingBehaviour firstProvResponse

Call Flow: The 183 Session Progress from the egress contains SDP and no PEM header.
Issue: The SBC does not send media from egress to ingress and the caller receives dead air.

Platform/Feature: SBC

Portfix SBX-94324: In the SBC to GW to SBC scenario, the first SBC coredumps when the ingress invite contains four identity headers.

Impact: Making a GW-GW call that contains multiple identity headers will cause a crash.

Root Cause: There was a validation code to check that the internal CPC structures that carries the identity header information was correctly padded to a 4 byte alignment. This validation code was correct for one identity header but failed when more than one was present and as a result, triggered the system to crash.

Steps to Replicate: Send in an INVITE that contains two identity headers of type SHAKEN and route the call over a GW-GW connection to a second SBC.

Platform/Feature: SBC

Portfix SBX-98356: There was a SEGV on an unknown address 0x0000000000e5 (pc 0x5653a715fdde bp 0x7f84a52bfea0 sp 0x7f84a52bfe70 T9).

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

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

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

Platform/Feature: SBC

The trunks data cannot be displayed on the live monitor.

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

Root Cause: The Elastic Search interprets 'hypen' as a delimiter and as a result, the string is broken down into tokens for indexing. When a query is put in the ElasticSearch for data with trunkgroup name containing 'hyphen', no data is retrieved as the Elastic Search has stored the data not with the actual trunkgroup name but with tokens

Steps to Replicate: 

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

Platform/Feature: SBC

The ipRecMetadataProfile does not work for the request-uri in the V07.02.02.

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

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

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

Platform/Feature: SBC

The MAINTAIN ONLY CDR .ACT file extension during atomic write process was not utilizing the .TMP.

Impact: When the CDR files are copied to the remote server, the file is copied with a temporary extension .TMP. For some installations, the software running on the remote server moves those files with the .TMP extension before the SBC software renames them with an .ACT extension.

Root Cause: A temporary extension is used during the time files are copied to the remote server.

Steps to Replicate: Perform the following step:

1. Unhide debug
2. Set OAM accounting cdrServer admin primary useFilePostfix disable
3. Transfer a large file.

Note that the file that is being uploaded to the remote server has an ACT extension while it is being transferred.

Platform/Feature: SBC

A new option is added to fix the issue:

1. Unhide debug
2. Set oam accounting cdrServer admin primary useFilePostfix disable

By default, the useFilePostfix is set to enabled.

When set to disable, a temporary extension is not used when copying the file to the remote server.

The SBC application restarted twice.

Impact: The SCM cored due to a segmentation fault.

Root Cause: The SCM hit a segmentation fault due to an attempt to dereference a NULL pointer.

Steps to Replicate: The steps cannot be reproduced.

Platform/Feature: SBC

The PrsP cored on both the active and standby nodes at the same time.

Impact: The PRS process cored due to accessing a non accessible memory location while processing the MONSEC response from NP.

Root Cause: Based on the core analysis, the core dump was caused by an invalid MONSEC response from NP. There were many read media stats commands sent to NP at the same time with the MONSEC request. The response that was processing appeared like a valid PNPS_NP_RSP_RD_MEDIA_FLOW_STR response.Due to this observation, there may be some timing issue that sent media flow stat response to MONSEC.

Steps to Replicate: The steps cannot be reproduced.

Platform/Feature: SBC

The SBC adds a media IP address in the outgoing SDP although the call is a direct media call.

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

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

Steps to Replicate: 

Configure for Direct media and enable the e2e Re-Invite.

1. Send an Invite from A to B.

   
   

2. B sends a re-Invite to A.

   
   

3. A sends a re-Invite to B with SDP of 200 OK that is sent for previous re-Invite

Platform/Feature: SBC

All call registrations were failing on the SJ SBC7K.

Impact: RFC-5626 PING/PONG traffic may cause severe CPU utilization issues in the SBC.

Root Cause: RFC-5626 PING/PONG traffic was sent from the SAM process to the SCM process and back.

Steps to Replicate: Send a lot of RFC-5626 PING/PONG traffic.

Platform/Feature: SBC: Call Control

Investigate a PATHCHECK Process coredump.

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

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

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

Platform/Feature: SBC

A double SCM core resulted in an outage.

Impact: A double SCM core resulted in an outage.

Root Cause: While building the outgoing IAD message, there might be a case where the null values for a request message result in incomplete From and To headers, and cause a crash as a result.

Steps to Replicate: The steps cannot be reproduced.

Platform/Feature: SBC

The STI and Privacy interactions are incorrect.

Impact: When the STIR/SHAKEN is enabled, a default privacy behavior was not given preference when the Privacy header is present in the ingress INVITE as follows:

1. The STIR/SHAKEN is generating PAI/Privacy:id headers for all services when the PSX IPSP, SIP HTP, or PrivacyProfile->passThruPrivacyInfo is not configured to send the PAI header out. “Add verstat to PAI” flag is set, the SBC was generating the PAI/Privacy: id to add the verstat to PAI when no PSX IPSP, SIP HTP, or PrivacyProfile->passThruPrivacyInfo is configured to send the PAI header out.
2. The PrivacyParamRestricted configuration must have preference over STI service. The PrivacyParamRestricted->default must anonymize the From and Contact headers when Privacy: user,id,header,or uri is present in the ingress INVITE even when STI is enabled.
3. The PrivacyProfile configuration should be given preference over STI, when a privacy profile is configured to “applyPrivacyId/supportPrivacyId” and STI should not generate PAI/Privacy: id for any service.
4. The STIR/SHAKEN is removing the “Privacy: User” header from the egress signal after anonymizing From and Contact header, when the IPSP Privacy->Transparency is enabled and Privacy: User header is present in the ingress INVITE.
5. Anonymization format should be based on Privacy->Privacy Information and variantType.

Root Cause: 

1. After the verification service, the verstat should either be added to the PAI or the From header. The “Add verstat to PAI” needs enhancement to enable adding the verstat to From if the PAI is not present in the egress signal.
2. The PrivacyParamRestricted->default behavior anonymizes the From and Contact headers when Privacy: user, id, header, or uri is present in the ingress INVITE. The STI was not giving preference to PrivacyParamRestricted->default anonymization behavior for the privacy: id.
3. The PrivacyProfile configuration was not given preference when the “applyPrivacyId/supportPrivacyId” is enabled, and the STI was generating PAI/Privacy: id headers.
4. The SBC will not remove privacy: user after just anonymizing the From and Contact header and let the downstream switch(es) perform further anonymization.
5. A preference was not given to Privacy information and variantType while determining the anonymization format.

Steps to Replicate: Configuration:

1. Configure the STI profile on the SBC and attach the profile on to both the ingress and egress TG.
2. Configure the STI profile for Signing/Tagging/Verification service on the PSX.

Observations:

1. When no PSX IPSP->Privacy, SIP HTP, or PrivacyProfile->passThruPrivacyInfo configuration is enabled and the From is anonymized in the egress INVITE, PAI/Privacy header is generated.
2. The Ingress TG->Signaling->PrivacyParamRestricted->default is configured. Observed that “From” and contact headers are not anonymized, if the privacy: id is present in the ingress INVITE.
3. When no PSX IPSP->Privacy, SIP HTP, or PrivacyProfile->passThruPrivacyInfo configuration is enabled and privacyProfile configuration is:
   • The PrivacyProfile is configured with the “applyPrivacyId” flag enabled. The PAI/Privacy header is generated when the Privacy: id is present in the ingress INVITE.
   • The PrivacyProfile is configured with the “supportPrivacyId” flag enabled. The PAI/Privacy header is generated.
   (Note: The PrivacyProfile behaviour without any STIR/SHAKEN interactions. When PrivacyProfile is configured to “applyPrivacyId” and attached to the ingress TG or when the “supportPrivacyId” is configured in egress TG, the SBC will remove PAI headers from egress INVITE when the Privacy:id header is received in the invite. When the privacyProfile with the “supportPrivacyId” is configured in the egress TG, the SBC will remove PAI headers from egress INVITE, irrespective of the Privacy header.)
4. The “Privacy: User” header is not present in the egress signal, when the IPSP Privacy->Transparency, SIP HTP or PrivacyProfile->passThruPrivacyInfo is enabled and the Privacy: User header is present in the ingress INVITE.
5. The From and contact headers has “Anonymous@Anonymous.invalid” as opposed to "Anonymous” <sip:Restricted>. If the privacy: user header is present in the INVITE and when IPSP->Privacy->Privacy Information is P-Preferred-Id or Remote-Info Party.

Platform/Feature: SBC

1. The STIR/SHAKEN does not generate the PAI/Privacy: id headers for any services when no control is set to send the PAI headers out(no PSX IPSP, SIP HTP or PrivacyProfile->passThruPrivacyInfo configured), one of the mentioned control must be set for the PAI header to go out. The “Add verstat to PAI” Flag is changed to the “Prefer PAI”, to enable sending verstat in From if PAI is not present in the egress INVITE.
2. The PrivacyParamRestricted->default anonymizes the From and Contact headers when the Privacy: user,id,header,or uri is present in the ingress INVITE. The PrivacyParamRestricted->default anonymization behaviour for privacy: id is retained even when the STI is enabled.
3. The PrivacyProfile is given preference over the STI service.
4. The SBC is not removing the “Privacy: User” header after anonymizing the From and Contact header as part of STIR/SHAKEN service, when the IPSP Privacy->Transparency is enabled and Privacy: User header is present in the ingress INVITE. This enables the downstream switch(es) to perform further anonymization.
5. The format of anonymized From and Contact headers when IPSP->Privacy->Privacy Information is P-Preferred-Id or Remote-Party-ID is retained even when the STI profile is enabled. The example below is for variantType,

Portfix SBX-94513: The Antitrombone will not have a kickstart but undesired pattern "PCR7400 Direct Media Antitrombone Call" is found in the dbg.

Impact: For a direct media call using X-dmi, the SBC is not preferring X-dmi over anti trombone direct media. This could cause one way or two way audio issue.

Root Cause: The SBC selects the Antitrombone direct media instead of X-dmi.

Steps to Replicate: 

1. Run a basic XDMI DM call
2. Run a basic DM with NAT call with XDMI
3. Run a basic Antitrombone call with XDMI enabled

Platform/Feature: SBC

Portfix SBX-96951: Unable to write to the CDR in the ATTEMPT record due to 3xx.

Impact: Run a redirect scenario and write a SMM CDR operation on the 302 message. The CDR information is not populated in the attempt record.

Root Cause: The CDR information is not being updated to CC in this scenario.

Steps to Replicate: 

1. Run a Redirect Scenario.
2. Write a SMM CDR operation on the 302 message.

Platform/Feature: SBC

Portfix SBX-93764: The CAC handling is not working with the REFER and INVITE with replaces to 7.2.x.

Impact: In MS Teams call flows, they support music on hold service by default. The “on hold” feature was implemented by sending a REFER to the SBC so that the SBC then generates an INVITE out to the MS Teams music server and the B-leg is then released. The "off hold" feature was added to have the MS Teams phone replace the music on hold server call leg. Customer's are running with the CAC enabled in the lab and have call limit set to 10. Every time the SBC gets an INVITE with replaces, it reduces the CAC count on the ingress trunk group and then eventually fails.

Root Cause: The issue is that the Trunk Group and the Zone CAC are being performed for call pickup. Since CAC has already been performed for a call that is being picked up, a double count occurs that causes incorrect CAC failures.

Steps to Replicate: The steps cannot be reproduced.

Platform/Feature: SBC

A security patch drift for 7.2.4.

Impact: There are Nessus scan vulnerabilities.

Root Cause: There are Nessus scan vulnerabilities.

Steps to Replicate: Run a Nessus scan.

Platform/Feature: SBC

Portfix SBX-87180: Enable to trace with the TRC file SIP message outside the call, such as REGISTER and SUBSCRIBE.

Impact: Trace logs were not coming in the case of OOD when the trace level is set to 1 and the key is ipPeer

Root Cause: The current code does not send the TRC logs for OOD when the level is set to 1, and this option enabled now for OOD.

Steps to Replicate: Pre-Configuration:

-------------------------
admin@ELEANORSBX% show global callTrace | details
errorFilter {
errorType any;
}
maxTriggerCount 10;
callTraceTimer 111;
callFilter Naga {
state enabled;
level level1;
key peerIpAddress;
stopMatch unsupported;
match {
called "";
calling "";
contractor "";
redirecting "";
transferCapability unrestricted;
trunkGroup "";
peerIpAddress 10.54.81.11;
cddn "";
}
mediaPacketCapture disable;
}
signalingPacketCapture {
signalingPacketCaptureTimer 180;
state disable;
}
[ok][2019-04-19 14:44:24]

[edit]

In the configuration above, traces for all methods will be captured,

Platform/Feature: SBC

The heap-use-after-free in the DnsClientTcpMonitorDnsServerTimeout.

Impact: When using the DNS over the TCP, if there was a failure in reading from the TCP socket, the timeout processing was invoked for the outstanding DNS query and it was reading memory that has already been freed up.

Root Cause: This is an edge case error processing scenario where the pointers were being passed around internally and did not get updated to be null when the memory was freed.

Steps to Replicate: Issue was analysed based on a coredump and code review. The exact call scenario that caused the issue is unknown.

Platform/Feature: SBC

Portfix SBX-94486: The SBC was not releasing the other leg when call was disconnected during hold( MOH enabled).

Impact: The SBC is not releasing the other leg when call is disconnected during hold( MOH enabled).

Root Cause: This is a race condition in CC where the handler for the event ASG_DISC_CMD is not present for the CC state CC_VIRT_ESCR_VDREQ and as a result, the call is hung.

Steps to Replicate: 

1. Make a TEAMS to PSTN call.
2. The TEAMS holds the call (MOH).
3. The TEAMS disconnect the call during MOH.

Platform/Feature: SBC

The CE_Node2 log fill up disk space causing a switch over.

Impact: The SYS ERRs from the CpcGenericCodecIsRfc3389Applicable() were filling up the SYS log and CE_logs quickly.

Root Cause: Based on the analysis of genCodecData in SCM core file and source code inspection, a bug was found in CpcGenCodecCriterionMatch() that could return an unpredictable value when all attributes are invalid in a specified criterion. In the SCM core, call control blocks were found in the SIPSG with the GSM audio encoding that has all attributes set to invalid in the criterion.

Steps to Replicate: The steps cannot be reproduced.

Platform/Feature: SBC

The SBC drops a request from egress to a registered user.

Impact: Non-Invite messages may drop if received immediately after a registration/Subscribe from the AS.

Root Cause: When a request was sent out to the server, internally, it creates a control block for handling the response. When a Peer sends a request back with the same callId, the SBC found the control block that is wrong and causing the SBC to drop.

Steps to Replicate: A register an to B, and the B send message back the SBC.

Platform/Feature: SBC

A SIP-I Issue with HOLD for the SIP-I to SIP call.

Impact: The SIP-I body is not being sent out in a re-INVITE for HOLD.

Root Cause: The SIP subsystem is making a dip into the ISUP stack with wrong even type, that's why ISUP stack is not returning SIP-I body to be sent with.

Steps to Replicate: It is a complex scenario that is run into this situation when the re-INVITE for HOLD is to be sent out. It requires multiple offer/answers before the call is setup to end up in this situation. 

Platform/Feature: SBC: SIP Applications

If flag is set for PROGRESS and MID_CALL_INFO, the precedence is set to send the event as PROGRESS for dipping into the ISUP stack for ISUP body.

Portfix SBX-95851: The LeakSanitizer detected memory leaks in the DiamCsvAddPeer.

Impact: Unable to resolve the SRV fqdn for a diameter peer. Without this fix, the diameter connection cannot be established towards the diameter peer.

Root Cause: The wrong domain name is attached to diameter peer when a peer is created with the SRV domain fqdn internally in code.

Steps to Replicate: Create a  diameter peer with SRV fqdn.

Platform/Feature: SBC

Portfix SBX-94619: The intel microcode bundle is not the latest version.

Impact: There are vulnerabilities in hardware.

Root Cause: The CPU microcode is outdated.

Steps to Replicate: Run the Spectra-melt-down script on a host and check vulnerabilities.

Platform/Feature: SBC

In the I-SBC, PKT Port redundancy support is not present in 7.2.2 release.

Impact: The SBC Release 7.2.2 is missing the PKT Port redundancy support, when it is listed as available.

Root Cause: In the I-SBC, the PKT Port redundancy support is added in the 8.x releases, but not present in the 7.2.2 release.

Steps to Replicate: Configure the pkt port redundancy, port the switchover to see the service continuity on PKT ports with redundancy enabled.

Platform/Feature: SBC

Observing the CLI port SWO in the M-SBC is causing the MGMT link to go down.

Impact: On the CLI port, a switchover on packet interface has random connectivity loss for few seconds on other interfaces.

Root Cause: A bug in SWe_NP code was picking the incorrect NIF control blocks for standby ports causing intermittent signaling packet loss and a loss of ICMP packets resulting in connectivity failures. This happens specifically on high call loads, when workers are at 80% capacity.

Steps to Replicate:

1. Bring up setup with port redundancy and perform multiple CLI switch over.
2. Observe the link status of various ports.

Platform/Feature: SBC

Portfix SBX-87404: A reInvite is triggered before an ACK is verified. (Originated in release 6.2.4)

Impact: When the online validation (sessId and verId) is set to zero in 200OK, the SIPS fails to save the peer SDP.

Root Cause: When the o-line validation (sessId and verId) is set to zero in 200OK, the SIPS fails to save the peer SDP. This could trigger an unnecessary reInvite.

Steps to Replicate: Configure the SDP o-line version only. The SDP received in 200 Ok (multi codecs) for egress has a sessId and verId of zero. The SBC could send an unnecessary reInvite to the peer.

Platform/Feature: SBC

Optional fax parameters are being parsed by the SBC and, as a result, the 200 Ok is being discarded.

Impact: The SBC returns a parser error (4xx) for unsupported t38 attributes.

Root Cause: When the unsupported t38 attributes are received, the SBC shows it as an error.

Steps to Replicate: When the Incoming call has unsupported t38 attributes, the SBC shows a reply 4xx (parsed error).

Platform/Feature: SBC

The EMA receives a Proxy error whenever an operation takes a long time to complete.

Impact: When the user navigates to a SIP trunk group or DM PM rule creation screen, there is no response from the UI and after approximately a 2 minute interval, "Proxy error" is shown to the user.

Root Cause: The EMA reads the DM PM Rule, DM PM Sub Rule and DM PM Criteria data from the CDB through the Netconf interface. With a large amount of data, there is a significant delay in rendering the UI. The request from the browser times out, resulting in a Proxy Error to the user.

Steps to Replicate:

1. Configure more than 25,000 DM PM Criterias and more than 25,000 DM PM Rules.
2. Navigate to a SiP Trunk Group Creation Screen or DM PM Rule creation screen.
3. The create screen does not load and after some time results in Proxy error.

Platform/Feature: SBC

Instead of a CDB, the EMA reads the data for DM PM Rule, DM PM Sub Rule and DM PM Criteria directly from the Oracle Database, reducing the delay to a larger extent in rendering the UI.

When the Copy Trunk Group operation is performed, it can take up to 3 minutes to complete the copy operations. The 3 minute delay is due to the EMA performing some additional operation compared to new TG creation.

The MS Teams scenario with ICE causes the RTCP port value discrepancy with X when the RTP is Y and when MUX is supported.

Impact: When the SBC sends out re-INVITE messages on a call leg supporting ICE, it can still include a=rtcp:<rtp port + 1> value in the SDP that is different to the previously agreed RTP/RTCP MUX setup with the remote end.

Root Cause: The SBC was not considering the SDP answer from the peer when setting the RTCP port value.

Steps to Replicate:

1. Send INVITE to SBX ingress with valid audio stream in SDP.

2. From the egress endpoint, respond to the INVITE with a 180 ringing and a 200 OK, and in both cases include valid SDP that has an RTP ICE candidate (no RTCP).

a=rtcp-mux

3. At the ingress endpoint, respond to a 200 OK with valid ACK.

4. From ingress endpoint, send a re-Invite that includes an existing audio stream and add a new video stream in SDP.

5. Complete the call signaling and then clear the call.

Platform/Feature: SBC: MS Teams

Portfix SBX-86495: Add a lightweight MPSTAT analysis as a warning to the user. (Originated in release 8.1.0)

Impact: The SBC had random timeouts/healthchecks due to the high %steal (in mpstat output).

Root Cause: There is no warning given when the %steal value is high.

Steps to Replicate: On a VM or cloud machine, manually add a value in the mpstat.log and then run the script.

Plaform/Feature: SBC

The SIP level4 call trace filter must not be restricted by the maxTriggerCount.

Impact: Level 4 call traces are incorrectly restricted by the maxTriggerCount value.

Root Cause: The intention is that the level 4 traces runs all messages and not be restricted by the system wide trigger count. The count must only apply to per call level 1-3 traces.

Steps to Replicate:

1. Configure a level 4 call trace.
2. Configure the maxTriggerCount to a non-zero value.
3. Change calls that are traced as well as subsequent calls – once maxTriggerCount calls have been made, not be traced.

Platform/Feature: SBC

Portfix SBX-88122: The SBC failed to re-establish media session between the SBC and MS Teams Client after a call transfer initiated by Teams client has failed. (Originated in release 7.2.1)

Impact: In scenarios where MS Teams referred the call to another, the SBC started to play a RBT (ring back tone) and if the REFER failed due to the C-party not answering, the media is not established again between the A and B party.

Root Cause: The media resource used to play the RBT did not get freed up correctly when the REFER failed and this blocked the media flow from A to B being re-established.

Steps to Replicate: Make a call from PSTN to MS Teams, have MS Teams REFER the call to another user. Let the phone ring as C-party but do not answer it.

Platform/Feature: SBC

The Ssreq coredumped on the SYD SBC.

Impact: The ssreq server has a memory leak that may eat up virtual memory, when there is call load through the ssreq client.

Root Cause: The memory allocated for call data and call trace is not being deleted properly, leaving those memory blocks idle forever.

Steps to Replicate:

1. Set up the SBC system with a light or heavy call load.
2. Add a call load through ssreq client to the system, light traffic is enough.
3. Use the top command to watch the memory growth.

Platform/Feature: SBC

Portfix SBX-91481: The SamP cored. (Originated in release 6.2.4)

Impact: Under certain conditions, the SBC sends out a duplicate OPEN_ACK, causing the receiving GW to crash.

Root Cause: A bug in the GW Signaling code can cause a duplicate OPEN_ACKS to send when GW Signaling Links are bouncing.

Steps to Replicate: This problem is not reproducible.

Platform/Feature: SBC

Portfix SBX-87861: While performing a port switchover, the SBC active performed a reboot and the Standby did not takeover the calls. (Originated in release 8.1.0)

Impact: An SWe_NP thread hang was observed on a packet port pull out.

Root Cause: A cable pull was calling a reset on an interface that may take more than 5s on a thread health check threshold, causing the thread to lock on reset.

Steps to Replicate:

1. Bring up setup in port redundancy setup.
2. Cable pull packet interface to trigger port switchover.

Platform/Feature: SBC

Portfix SBX-91510: An ASAN global-buffer-overflow for the IPUtilGetIpAddressForPrefix. (Originated in release 8.1.0)

Impact: In the SBC, while validating whether the peer RTP address is trusted or not, the IP address is validated. While validating the IP Address, the prefix is passed along with the IP Address. The prefix length is passed as 128, irrespective of the IP Address version.

Root Cause: This issue was reported as part of the ASAN Testing on a PCR 8709 regression suite in the SBC lab.

Steps to Replicate: This issue was found while running a PCR 8709 regression test suite.

Platform/Feature: SBC

The RTP is sent to RTCP after a monitor success indication.

Impact: The SBC learns the RTCP port number and uses that to send RTP packets to the end point when RTP monitoring is enabled.

Root Cause: When the RTP montoring is enabled for a call and the media stream sends RTCP packet within the number of packets for authorization, an Network Processor (NP) learns the RTCP packet and notifies the application about the sourceIP and sourcePort.

Steps to Replicate:

1. Enable the RTP monitoring for a call.
2. Send RTCP packet first and then RTP packets.
3. The SBC may send to the learned RTP source port.

Platform/Feature: SBC

Portfix SBX-91090: PrsNP process core dump on standby of I-SBC HA on KVM while doing an sbxrestart. (Originated in release 8.1.0)

Impact: There is rare potential of race in healthcheck implementation of SWe_NP. It can cause a false healthcheck failure of the SWe thread and a result in SWe_NP thread crash.

Root Cause: Read and write a healthcheck global variable occurred in non-atomic manner from two different cores.

Steps to Replicate: This is a rare occurrence that happens randomly on idle systems. The steps cannot be consistently reproduced.

Platform/Feature: SBC

Replace the cdb_get when processing status commands.

Impact: Multiple issues were reported where the process cored from healthcheck timeout. The application must not call out to the CONFD when processing the CLI status requests.

Root Cause: Application must not call out to CONFD when processing the CLI status request.

Steps to Replicate:

1. Configure IPSEC testbed.

2. Start to run some calls.

3. From CLI, issue the following commands: "show table addressContext <address context> ipsec ikeSaStatus" "show table addressContext <address context> ipsec ikeSaStatistics" "show table addressContext <address context> ipsec ipsecSaStatus" "show table addressContext <address context> ipsec ipsecSaStatistics" "show table addressContext <address context> ipsec systemStatistics"

Platform/Feature: SBC

The DALSBX71A core dumped.

Impact: The SBC core dumped while processing a call with the call stack in 5.0.5R000 software.

Root Cause: NRMA has resources getting cleaned up in response to the ingress hanging up. At the same time, in response to egress received 183 Session Progress and 180 Ringing, the activate starts. In this race condition, the ipCktInfo is NULL and code illegally tries to access it and causes a core dump.

Steps to Replicate: No steps to replicate, only a code inspection was done to test the issue.

Platform/Feature: SBC

Failover from Node-A to Node-B.

Impact: Healthcheck failure while switching from nodeA to nodeB.

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

Steps to Replicate: Switchover from Active to standby.

Platform/Feature: SBC

Portfix SBX-91257: No Ring back is heard during a blind transfer. (Originated in release 7.2.1)

Impact: The SBC was playing a ring back tone while processing REFER and transferring the call. However, the tone was not heard on the original call leg because MS Teams had put the original call on hold.

Root Cause: The code was intentionally not sending re-INVITE messages in this scenario.

Steps to Replicate: Run any MS Teams transfer call scenario.

Platform/Feature: SBC

Call Graphs are showing more calls after upgrade.

Impact: Stale calls may be found on a newly upgraded SBC if upgrading from a version older then 6.1.0 to a version higher.

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

The only way to clean up these calls is to use the following commands:

unhide debug
request sbx rtm debug command “cleanup <gcid>

Steps to Replicate:

1. Create an audit key greater than 31 by multiple switch over on a HA system or by using instrumented code.

2. The audit key will create GCID values using the high bits ( bit 30-31) of GCID value.

3. Setup SIP calls on the system.

4. Initiate the LSWU on standby and after standby is upgraded to newer version, all the established calls on active will be synced.

5. Start the LSWU on active.

6. At this point, standby will become Active.

7. Hang up calls that were established before standby became Active.

8. Issue "show table global callSummaryStatus" CLI command and for all those calls data will be Unavailable.

9. These calls will consume resources. To verify the issue, perform the same steps mentioned above. After upgrading to version with fix, after calls are hung, resources must be released and show table global callSummaryStatus command will not show any orphaned calls.

Platform/Feature: SBC

The ipPeerCurrentStatistics and ipPeerIntervalStatistics are not working.

Impact: Getting the IP peer current statistics for individual IP peers was not working. The issue is reproduced when multiple IP peers are configured under the same zone.

Root Cause: Multiple IP Peers must be configured under same zone to reproduce this issue. When obtaining specific peer statistics, the peer name comparison within the same zone was missing.

Steps to Replicate: Configure multiple IP Peers under the same zone and then execute the command to obtain IP Peer Current/Interval statistics for a specific peer.

Platform/Feature: SBC

Portfix SBX-90947: The NP process core dumped while running a load on the HA setup.

Impact: A random SWe_NP crash occurs on a standby node while running a transcoded load.

Root Cause: RTCP resources are not managed properly by application layer on standby node. This causes a restart of already running timers on the SWe that causes a race and random crash.

Steps to Replicate:

1. Run a large number of transcoded calls, on HA pair.
2. Perform multiple swtichovers of SWE_NP coredump will be observed on standby node.

Platform/Feature: SBC

When using the metaVariableDynamic, LinkDetection is not activated in the SBC.

Impact: If the LinkDetection interfaces are configured to use addresses specified in the systemMetaVariable dynamic table, those addresses are not properly read and the LinkDetection is not activated.

Root Cause: The addresses were not properly read from the metaVariableDynamic table.

Steps to Replicate:

1. Add new entries to the metavariableDynamic table.
2. Create an ipInterface with meta keys added to metaVariableDynamic table.
3. Configure the Link Detection on the ipInterface.
4. Check the Link Detection status.

Platform/Feature: SBC

Memory leaks in the SIPSG.

Impact: While debugging a bug in a previous release (SCM crashed from segmentation fault fired from malloc()), memory leaks were found in the SIPSG related to subscription.

Root Cause: Observed through a source code inspection.

Steps to Replicate: Perform SIP regression tests.

Platform/Feature: SBC

Portfix SBX-90654: Unable to retrieve the parked call on MS Teams. (Originated in release 7.2.1)

Impact: The SBC was unable to retrieve a parked call. The call was not working correctly because the NRMA process had incorrectly swapped PSP information on the call legs.

Root Cause: This is a new call scenario being implemented for the MS Teams interop.

Steps to Replicate: Run a test call in the MS teams for call park and retrieve.

Platform/Feature: SBC: MS Teams

Portfix SBX-91907: The SBC fails to mount a cinder volume on first boot. (Originated in release 8.1.0)

Impact: The SBC fails to mount a cinder volume on first boot.

Root Cause: The bootcmd instruction to mount the volume was executed before the cinder volume was attached as part of instance creation. The cinder volume was not mounted on first boot and as a result, the SBC results in a failure.

Steps to Replicate: Launch the SBC instance with a cinder volume attached and ensure volume is mounted properly.

Platform/Feature: SBC

Portfix SBX-91820: In crank back scenarios, the SBC is taring down the SRS call even before the CS call is torn down.(Originated in release 7.2.1)

Impact: The SBC was immediately disconnecting the SRS call after establishing the SIP Rec session with the next available SRS. The initial SRS responds with a failure 4xx response.

Root Cause: The SBC, after finding the next reachable SRS when the initial one has failed with 4xx response, creates a new SIP Rec Call Block data matching to new SRS. In the older version of the SIP Rec Call Block, the state machine was invoked with a incorrect event. The incorrect event in the state machine was causing the deletion of old SIP Rec Call Block along with deleting the new SIP Rec Call Block.

Steps to Replicate:

1. Create a SRS Group with three SRS Servers.
2. Configure the num streams to 2.
3. The SBC tries to send SRS Invite to first 2 SRS.
4. Send the 4xx response from the first SRS and 2xx response from the 2nd SRS.
6. After receiving the 4xx response, the SBC tries to send new INVITE to 3rd SRS.
7. Send a 2xx response from 3rd SRS.
8. At this step, after ACK towards 3rd SRS, SBC immediately sends BYE to 3rd SRS.

Platform/Feature: SBC

A DTMF transcoding caused the call to disconnect.

Impact: A certain percentage of the traffic (5%of the calls) are failing due to an incorrect DTMF payload being sent by BROADSOFT.

Root Cause: The SBC was expecting that for a single HD CODEC entry in the 200 OK ANSWER, the Peer/Endpoint must send a matching 16K DTMF payload as per the RFC standard. But the BROADSOFT server at the Egress side is non compliant and sending a 8K DTMF, which is causing the call disconnection.

Steps to Replicate:

1. Enable the DTMF either on both the legs and Different Transcode Flag.

2. Send the PCMU with DTMF 8K from Ingress leg.

3. From Egress side, send the PCMU without any DTMF.

4. Ensure that the call is transcoded.

Platform/Feature: SBC

The SIP calls drop with vertical service code *65 after a minute.

Impact: The SBC is not able to send ACK to the Egress for call to connect.

Root Cause: A logical error when combined with multi features (e2eAck, e2eReInvite, and DLRBT).

Steps to Replicate:

1. Configure the e2e Ack, e2e reInvite, and DLRBT.
2. Egress response 183(sendrecv), 183(onhold), 180(no SDP), 200OK(sendrecv).
3. Peer change the SDP in 18x/2xx response causing internal offer/answer.
4. Ingress peer sends the reInvite right after ACK, causing internal state not able to send ACK out.

Platform/Feature: SBC

Q.850 reason header has a grammar issue.

Impact: Invalid format in the reason header in a SIP 500 message.

Root Cause: When the reason header transparency is enabled, a bug appears in the code.

Steps to Replicate: Enable the Reason header transparency along with ANM to CPG feature.

Platform/Feature: SBC

Portfix SBX-91599: There was a ASAN stack-buffer-overflow on the address in the StrNCpyZ.

Impact: There is an array, which is being used with string specifier and is not null terminated, which causes the overflow problem.

Root Cause: A buffer overflow.

Steps to Replicate: The steps are not reproducible.

Platform/Feature: SBC

The SBC failed over DEADLOCK detected and a ScmP core was generated as a result.

Impact: Access the NULL pointer in NRMA when deleting a tone profile.

Root Cause: The given targets name does not exist.

Steps to Replicate: Use CLI command to delete the non-existing announcement tone profile.

Platform/Feature: SBC

The SCMP coredump was related to ARS.

Impact: The SCM process may core dump when the SIP signaling port is out of service, and if calls are in progress and a SIP transaction timeout occurs.

Root Cause: If the SIP signaling port is out of service, and if calls are in progress and a SIP transaction timeout occurs.

Steps to Replicate: The steps cannot be replicated.

Platform/Feature: SBC

*BrmRedBresAlloc messages are overloading DBG logs.

Impact: BRM redundancy messages were filling up DBG logs.

Root Cause: Those were debug messages to help debug resource leaking issue.

Steps to Replicate: Use regression test only.

Platform/Feature: SBC

Oracle Java JDK vulnerabilities were observed for Nessus scans.

Impact: The Nessus Scan was reporting that embedded java in Oracle database has security vulnerabilities.

Root Cause: Oracle 12c has Java 1.6.0_75 embedded.

Steps to Replicate: Run a Nessus scan and the earlier vulnerability will go away.

Platform/Feature: SBC

Calls from MS Teams may have an audio loss for 30 seconds and then switch-over.

Impact: If there is an SBC switch-over after the call is established, there can be a delay (for example, 30 seconds) when re-establishing the media from the PSTN to MS Teams.

Root Cause: The stored SSN value does not get updated before the SBC switch-over occurs, and it causes the SSN to jump backwards after a switch-over, which causes the one way audio issue until the SSN value increments past the previously set value.

Steps to Replicate: Perform a switch-over after the LRBT is played and check that there is no one way audio issue.

Platform/Feature: SBC: MS Teams

The LSASBX71 switched over and causes both sides to core.

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

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

Steps to Replicate: The steps are not reproducible.

Platform/Feature: SBC

The GW Signaling code is modified to prevent a core.

Observed "SamProcess" core dump on an active box while running SIP-GW (cyclic) calls.

Impact: The SBC may core if the GW Signaling Port configuration is disabled while GW Signaling Link is up.

Root Cause: The core is caused by an attempted NULL pointer access.

Steps to Replicate: Disable the GW Sig Port while GW Sig Link is up.

Platform/Feature: SBC

The application is generating "User Error: monitoring/0/101 PAM authentication succeeded" in .SEC file.

Impact: The SEC log records all successful PAM authentication, which is causing the disc to fill.

Root Cause: Due to constant value re-organization, successful PAM authentication has been mistakenly logged in to SEC log.

Steps to Replicate:

1. Ensure that logs are configured at MAJOR level.
2. Put a TLS load on the SBC.

3. Many of the similar lines in the SEC log, as shown in the example below:

   154 07092019 155039.345656:1.01.00.56147.MAJOR .CHM: *User Error: monitoring/0/101 pam authentication succeeded via rest

4. Apply the same procedure in a fix version SBC and those lines will not be seen.

Platform/Feature: SBC

When running the 7.2.1R2 release, the SBC is responding with 'a=inactive' instead of 'a=sendrecv' in a 200OK SDP to late media re-invite, causing no audio.

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

Root Cause: A missing requirement.

Steps to Replicate:

Step 1: Generate SIP scripts for a call flow.
Step 2: Setup 7.2.1 system without a fix.
Step 3: Run the call flow to see that the problem is observed.

Platform/Feature: SBC

The MS Teams call flow when using hold/resume then transfer causes SCM crash.

Impact: When music on hold is used in the deployment and a call is put on hold/resumed and then transferred, the call is causing the SBC to coredump in the SCM process.

Root Cause: The SCM process was de-referencing a null pointer.

Steps to Replicate: Music on hold is used in the deployment and a call is put on hold/resume and then transferred.

Platform/Feature: SBC: MS Teams

Portfix SBX-92484: The SBC is dropping the 2nd codec for a text stream when the sendOnlyPreferredCodec flag is enabled. (Originated in release 8.1.0).

Impact: The SBC was dropping the second payload for a text stream if the "Send Only Preferred Codec flag" was enabled and the offer answer contains both t140 and red as payloads for this stream.

Root Cause: The "Send Only Preferred Codec" flag's logic was applied even to a text stream that resulted in the SBC picking the first codec and dropping the other.

Steps to Replicate:

1. Bring up the setup for an A-B call.

2. Enable the flag t140 on both PSPs.

3. Enable the flag sendOnlyPreferredCodec on both IPSPs.

4. Send INVITE from A with both Audio and text media stream with 2 codecs for text(t140 & red).

5. Send 200 OK from B with both Audio and text media stream with 2 codecs for text(t140 & red). Both of the payload is received through the t140 and red is received and no payload is dropping.

Platform/Feature: SBC

The SIP Domain is missing in the FROM header after an upgrade.

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

Root Cause: Introduced in a previous release to treat the FROM Uri for theRewriteIdentity only.

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

Platform/Feature: SBC