| Issue ID | Sev | Problem Description | Resolution |
---|
1 | SBX-93247 | 2 | 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 | The code is modified so that the memory used to store the Domain information is freed whenever the standby Relay Call Block is freed. |
2 | SBX-94865 / SBX-94512 | 2 | Portfix SBX-94512: The RTCP packets count is not getting populated consistently in the callMediaStatus. Impact: With the RTCP relay monitoring feature, 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 code is modified to be applied correctly in the SWe now. |
3 | SBX-94998 | 3 | 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 | Change the log level to info since it happens when the E2E Re-INVITE flag is enabled and does not have any negative impact. |
4 | SBX-92582 | 2 | 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: - Configure more than 10 routes on the PSX Routing Label (11 routes for example).
- All 10 routes fail.
- The SBC sends another query more route and those fail as well.
- The SBC still send additional query to the PSX which fails because the PSX have returned all the
Platform/Feature: SBC | The code is modified to ensure the SBC avoids sending additional Diameter query to the PSX when the PSX has returned all the routes. |
5 | SBX-95323 / SBX-93967 | 2 | 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 | The code is modified to pass the REFER-TO information from the REFER to the INVITE in this scenario for the MS Teams setup. |
6 | SBX-91737 | 2 | 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: - In a working HA, provision at least 3 working remote policy servers.
- While keeping the admin stat at enabled, only keep 1 of the servers mode as active, and rest are out of service.
- Change those servers' mode, commit only after all the set commands finished.
- Display the status using the 2 commands below:
"show table system policyServer remoteServer" "show table system policyServer policyServerStatus" - Perform a switchover.
- Repeat step 4. The operStat will be different from step 4.
- 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 | The code is modified for all remote servers requested by the CLI users, although remote servers are not registered even if the mode is being changed from the OOS to active. result, the operStates at standby node stays synced with the active node. |
7 | SBX-92114 | 3 | 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 |
8 | SBX-94814 / SBX-93456 | 2 | 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 | Avoid overwriting the skb_work->skb from add_ptr. |
9 | SBX-93712 | 2 | 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 | Set the timestamp to the current time when the media resource is enabled. |
10 | SBX-94811 | 2 | 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 | The code is modified to ensure the SBC handles more than 10 routes from the PSX correctly. |
11 | SBX-91463 / SBX-91398 | 2 | 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 code is modified to fetch the transport protocol from the next available DNS server in the list and trigger the DNS query. |
12 | SBX-91057 | 2 | 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: - Egress sends the 183 Session Progress.
- Egress sends the 486 Busy Here.
- The SBC does not send the 486 Busy code to Ingress.
- 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 code is modified to ensure the SBC, upon receipt of provision response, clears the authentication flag and relays the cause code from the egress to the ingress. |
13 | SBX-95033 | 2 | 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 code is modified to ensure to lock the SSL socketPtr before performing any operation so that no thread tries to access it. |
14 | SBX-93105 | 3 | 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 | During a switchover, the message drops. |
15 | SBX-95007 | 2 | 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 code is modified to add ipInterfaceGroup and addressContext information in handling the "ICMP Destination Unreachable Fragmentation Needed" message in the Linux kernel. |
16 | SBX-94994 | 2 | 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 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 | The code is modified to properly detect all the SBC processes so that the slwresd is not killed by the wrapper and therefore is not detected as having failed. |
17 | SBX-94377 | 2 | 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 |
18 | SBX-89209 / SBX-89018 | 2 | 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 | The code is modified to correctly handle the memory management so that it does not read off the end of the memory block. |
19 | SBX-94790 | 3 | 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: - Login into EMA.
- Navigate to
Administration -> System Administration -> Backup/Restore - Download the Backup file.
Platform/Feature: SBC: EMA | Make an API call if it is running the EMS on a normal method while on the SBC. |
20 | SBX-91113 / SBX-72499 | 2 | 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 | The code is modified to stop the Ref count from getting incremented when it reaches the max value. |
21 | SBX-95244 / SBX-95097 | 2 | 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 | To fix the issue, remove the RSEQ details from the PRACK entry List while sending PRACK with SDP out. |
22 | SBX-94571 | 2 | 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 | The code is modified to add the field number 59.19 in the ATTEMPT CDR record, in “487 Request Cancelled” case. |
23 | SBX-95833 / SBX-95749 | 2 | 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: - Enable the E2E Update.
- Trigger an UPDATE without SDP or an UPDATE with same SDP as last SDP.
Platform/Feature: SBC | The code is modified to add the contact header by the SBC when not provided by an application in the 200OK for a Session Refresh Update(an UPDATE without SDP or an UPDATE with the same SDP as last SDP). |
24 | SBX-95470 | 2 | 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 | The code is modified to use the proper connection Id, when the usePortRangeFlag is enabled, and when the SUBSCRIBE request with Authorization header is sent to the egress peer. |
25 | SBX-95261 | 2 | 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 to crankback. Platform/Feature: SBC: SIP | For failure response, the crankback feature must take precedent. |
26 | SBX-95941 / SBX-95930 | 3 | 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 | STIR-SHAKEN related headers are given higher precedence and ignored transparency for the P-ORIGINATION-ID and P-ATTESTATION-INDICATOR headers when the STI service type is "tagging". |
27 | SBX-92128 / SBX-91996 | 2 | 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: ============== - The SBC must be configured to handle the AMR passthru call.
- The transcoding must be set as conditional.
Test Procedure: ============= - The UAC sends Invite with AMR WB codec.
- 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 | The code is modified to handle internal logic when FMTP line string is terminated with \0. |
28 | SBX-95831 / SBX-93360 | 2 | 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 . The SRTP values are never updated. Steps to Replicate: - Create a UAC with RTP.
- Create two UAS with SRTP param.
- Send a port =0 for hold response.
- Check if the SBC is misbehaving while sending an INVITE to release hold from the far end.
Platform/Feature: SBC | The code is modified for the SRTP values for stream absent case. |
29 | SBX-95520 / SBX-71623 | 3 | 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 | The code is modified to consider the entire header of comparing the criterion. |
30 | SBX-95995 / SBX-85852 | 2 | 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 | The code is modified to allow configuration changes only when both the CDB and ORACLE DB are available for READ_WRITE and when the sync is completed. |
31 | SBX-94518 | 2 | 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: - Setup the SBC so that it sends a crypto in offer.
- 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 | If a crypto line is sent in an offer and none are received in the answer, if the minimize media and media lockdown flags are appropriately set to minimize offer/answers, a re-INVITE to lock down cryto attribute is not sent. |
32 | SBX-70842 | 2 | 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 | The code is modified to use the TLS port number when relaying the SIP NOTIFY messages. |
33 | SBX-59908 | 2 | 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 code is modified to prevent incorrectly incrementing 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. |
34 | SBX-95810 | 2 | 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: - HA pair, SIP registration load test, with high number of registrations.
- Cause registration binding timeouts.
- Restart the standby node.
Platform/Feature: SBC | Replace the regular ICM alloc/send with an RTM alloc/send in SIPFE when mirroring the port range connection close request to the standby node. The RTM then delivers the request to standby SIPFE properly based on the RTM sync state. |
35 | SBX-95895 | 3 | 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 | The code is modified to prevent the RTM from processing the Call Audit fault while in the STANDBY mode. |
36 | SBX-93067 / SBX-74922 | 2 | 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: - Make a G711-G711 forced transcoded call. Ensure that both legs have the DTMF remove enabled (dspchanstat).
- Use modem2225g711.pcap that has the modem signal captured from the customer in the ingress.
- Collect the media capture for the call and inspect the dspchanstat, as well as the output signal from egress.
- The dspchanstat and field show 0x0. Signal output shows drops in the FSK modem signal between 18.72 and 19.65.
Platform/Feature: SBC | The code is modified to look for the 2225 Hz tone of at least 750 ms at which point, the DTMF remove feature is disabled. It is important to understand that this fix only applies to G711-G711 transcoded calls and not any compressed calls. |
37 | SBX-96094 | 2 | 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: - Send an INVITE with the TGRP parameters in R-URI.
- The SBC sends the TGRP information to the PSX.
- The PSX does TGRP based routing and sends route.
- The SBC must send the SRV query to the DNS to resolve port and IP details when egress peer is FQDN.
Platform/Feature: SBC | In case of the TLS transport at egress, remote the fqdnPort is incremented by 1 only when the port received from the PSX other then zero. A check is added in sipsgSendFsmRmAlloc() function. |
38 | SBX-96305 / SBX-96170 | 2 | 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 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 code is modified to save the headers when saving an Update message as a server request. |
39 | SBX-95706 | 2 | 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: - Ingress configuration behind Napt and direct Media support.
- 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 | The code is modified to update the flags again when received in subsequent 18x/2xx. |
40 | SBX-94546 | 2 | 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:
Platform/Feature: SBC: SIP | The code is modified to ensure to tag in the ACK message sent from the SBC is correct. |
41 | SBX-96802 / SBX-96448 | 2 | 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 | The code is modified so that after receiving a SDP with the ICE ufrag in signaling message. The SBC only completes ICE learning against the stun requests that have the same remote ufrag as that received in the SDP. |
42 | SBX-96817 / SBX-95170 | 2 | Portfix SBX-95170: 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 | When the SBC receives the first 18x response for the outgoing call, as well as starting the ring back tone based on DLRBT, enable the ICE learning and respond to STUNs on the RTP port. |
43 | SBX-94579 | 2 | 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 | The source code that provides this functionality is removed, because it is no longer needed. |
44 | SBX-96856 / SBX-92117 | 2 | 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: to fix version and ensure there is no swap entry in fstab file and also there is no timeout logs. Platform/Feature: SBC | The code is modified to remove the SWAP entry from the /etc/fstab file as there is not SWAP enabled on the SBC. So, after installing/upgrading to the fix version, there is no timeout logs. |
45 | SBX-73719 | 3 | 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 | The code is modified to write the SMM information in the CDR for a Redirect Scenario. |
46 | SBX-96691 / SBX-94662 | 2 | 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: - Establish as many calls as required routed via the trunk group to consume the ordinary call limit on that trunk group.
- 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 | The code is modified to process the ICE data correctly when a call is transitioning to using emergency bandwidth. |
47 | SBX-96770 / SBX-96723 | 2 | 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 | The code is modified to restore the Zone SMM Profile during an SBC restart. |
48 | SBX-97194 / SBX-96937 | 2 | Portfix SBX-96937: Running the sysDump.pl on Openstack 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: - Run sysDump.pl and enter the default inputs.
- The SBC application will not go down.
Platform/Feature: SBC | As part of sysdump, backing up of /opt/sonus/sbx/openclovis/var/run/notify directory is excluded. |
49 | SBX-96945 / SBX-96939 | 2 | 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: - Establish a large number of LI calls.
- Bring the LI server down.
- Ensure that the ImProcess does not coredump.
Platform/Feature: SBC | The code is modified to disable the healthcheck while cleaning up the packets. |
50 | SBX-95176 | 2 | 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 | Modem tone detection algorithm is modified so that in case it finds a modem tone for 630 ms, in case number of phase reversals is larger than 3, its rejected as a spurious detection. |
51 | SBX-94698 | 2 | 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 | The code is modified to support short header name callId. |
52 | SBX-96992 | 2 | 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. |
53 | SBX-96834 | 2 | 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 | The code is modified so that there is no NULL value in between the two CodecEntry's. |
54 | SBX-93329 | 3 | 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 | Updated the monit paths to resolve this issue. |
55 | SBX-95474 | 2 | 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 | The code is modified so the parameters sonusUtils.logger.error changes to sonusUtils.logger.info and some other logs so there is no grep ERROR. |
56 | SBX-96952 / SBX-96471 | 2 | 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: - Run "drbdadm detach mirror" on standby.
- Perform a switchover.
- The switchover will be successful.
Platform/Feature: SBC | While coming up as active after a switchover, the dstate of DRBD is checked, and if it is "diskless" the DRBD is attached before proceeding further. |
57 | SBX-97545 / SBX-70059 | 3 | 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 | The code is modified for the NP API handler to resolve this issue. |
58 | SBX-94935 / SBX-90855 | 3 | 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 code is modified to fix the issue. |
59 | SBX-87399 | 3 | 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: - Create the ACL rule using the installed role active CE when the HA system is synchronized (full redundancy protection).
- Perform a switchover to the installed roll standby CE.
- Wait until the HA becomes synchronized (full redundancy protection).
- Using EMA to installed roll standby CE:
Disable the ACL rule Enable the ACL rule Disable the ACL rule Enable the ACL rule - Verify that the system is synchronized.
- Power off the installed roll standby CE "Power Off Server - Immediate" using the BMC.
- Using EMA to installed roll active CE:
Disable the ACL rule Enable the ACL rule <--- PRS CORED
Platform/Feature: SBC | The code is modified to re-open the connection to ConfD (on the immediate power off of the Active system), to prevent a PRS health check timeout coredump. |
60 | SBX-94486 | 2 | 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: - Make a TEAMS to PSTN call.
- TEAMS holds the call (MOH).
- TEAMS disconnects the call during MOH.
Platform/Feature: SBC | Added a handler for the event ASG_DISC_CMD for the CC state CC_VIRT_ESCR_VDREQ, so that the DISC cmd gets propagated to the other active peer call side and the call gets terminated correctly. |
61 | SBX-96178 / SBX-94562 | 2 | 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 | The MemCpy is replaced by the StrnCpyZ(). |
62 | SBX-96180 / SBX-94402 | 2 | 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: - Make a TLS call with the 100rel enabled.
- Send PRACK without content-length header for 18x.
Platform/Feature: SBC | The code is modified for the TLS-TCP Transport to resolve the issue. |
63 | SBX-95118 / SBX-94403 | 2 | 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: - Create a SBC GW-GW setup and enable the sessionKeepAlive,
- Establish a call load of more than 25K and once call is stable, perform a switchover at the GW-1.
- Calls now start failing.
Platform/Feature: SBC | The code is modified to now take care of processing multiple segments and to successfully establish a GW-GW connection. |
64 | SBX-94782 / SBX-94389 | 2 | 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: - The 'Announcement based tones' flag is enabled.
- Make a call from the PSTN - Teams n/w.
- After a call connect, a Teams user transfers the call to another Teams user, and the call will succeed.
Platform/Feature: SBC | During an inbandtones event triggered in the CC, when an abort_ann_tone event returns and if the cutthru is already received, set the cutthru to cutthru_pending. |
65 | SBX-97316 | 2 | 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 code is modified to handle call disconnects with 'no routes found' in the PSX/ERE without a Scm Process crash. |
66 | SBX-86374 | 2 | 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: 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 | The code is modified to ensure the audio data path mode is set to default gating mode. |
67 | SBX-99097 / SBX-94324 | 2 | 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 | The code is modified to ignore any padding rules for the particular internal CPC structures that carry the identity header information. |
68 | SBX-98387 / SBX-98356 | 2 | 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 code is modified to check that the trunk group configuration exists before trying to read the configuration. |
69 | SBX-95679 | 2 | 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 | Before querying the ElasticSearch for data, check if trunkgroup name contains hyphen, if it does then it is broken into tokens and the token is used to query for data. |
70 | SBX-97830 | 2 | 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 code is modified to correct the logical error. |
71 | SBX-96028 | 2 | 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: - Unhide debug
- Set OAM accounting cdrServer admin primary useFilePostfix disable
- 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: - Unhide debug
- 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. |
72 | SBX-97617 | 3 | 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 code is modified to ensure that the pointer is not NULL before dereferencing it. |
73 | SBX-97800 | 2 | 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 code is modified to check that npPoolId and numSecIds are in the defined range. |
74 | SBX-97851 | 2 | 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. Send an Invite from A to B.
B sends a re-Invite to A.
A sends a re-Invite to B with SDP of 200 OK that is sent for previous re-Invite
Platform/Feature: SBC | The code is modified to ensure the SBC updates the SIPstack SDP for direct media scenarios. |
75 | SBX-98098 | 3 | 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 | The code is modified to fast-path RFC-5626 PING/PONG traffic. |
76 | SBX-96953 | 2 | 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).
Platform/Feature: SBC | The code is modified to handle slower/longer traceroute completions. |
77 | SBX-95475 | 3 | 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 code is modified to avoid a coredump in cases where there are NULL values for a Request Message. |
78 | SBX-98198 / SBX-97916 | 2 | 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: - 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.
- 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.
- 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.
- 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.
- Anonymization format should be based on Privacy->Privacy Information and variantType.
Root Cause: - 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.
- 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.
- The PrivacyProfile configuration was not given preference when the “applyPrivacyId/supportPrivacyId” is enabled, and the STI was generating PAI/Privacy: id headers.
- The SBC will not remove privacy: user after just anonymizing the From and Contact header and let the downstream switch(es) perform further anonymization.
- A preference was not given to Privacy information and variantType while determining the anonymization format.
Steps to Replicate: Configuration: - Configure the STI profile on the SBC and attach the profile on to both the ingress and egress TG.
- Configure the STI profile for Signing/Tagging/Verification service on the PSX.
Observations: - 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.
- The Ingress TG->Signalling->PrivacyParamRestricted->default is configured. Observed that “From” and contact headers are not anonymized, if the privacy: id is present in the ingress INVITE.
- 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.) - 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.
- 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 | When the STI is enabled, the Privacy behavior is given preference over STI, which effectively means no changes in privacy behavior.
- 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.
- 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.
- The PrivacyProfile is given preference over the STI service.
- 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.
- 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,
From: "Anonymous" <sip:Restricted@example.com>;tag=gK08000282 Contact: "Anonymous" sip:Restricted@example.com:5060 Format of anonymized From and Contact headers when STI profile is enabled, when IPSP->Privacy set to P-Asserted-ID is as follows, From: "Anonymous" <sip:Anonymous@Anonymous.invalid>;tag=gK080004bb Contact: "Anonymous" sip:Anonymous@10.54.46.45:5060 |
79 | SBX-98566 / SBX-94513 | 2 | 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: - Run a basic XDMI DM call
- Run a basic DM with NAT call with XDMI
- Run a basic Antitrombone call with XDMI enabled
Platform/Feature: SBC | The code is modified to ensure the X-dmi is preferred over anti trombone |
80 | SBX-98598 / SBX-96951 | 2 | 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: - Run a Redirect Scenario.
- Write a SMM CDR operation on the 302 message.
Platform/Feature: SBC | The code is modified to update the CC about the SMM CDR Information. |
81 | SBX-95970 / SBX-93764 | 3 | Portfix SBX-93764: The CAC handling is not working with the REFER and INVITE with replaces to 7.2.x. Impact: call flows, they support music on hold service by default. The “on hold” feature was implemented by sending a REFER to the SBC so 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 | The code is modified so the CAC is not performed for call pickup scenarios and for double counting all call licenses for call pickup. |
82 | SBX-96858 | 3 | A security patch drift for 7.2.4. Impact: There are Nessus vulnerabilities. Root Cause: There are Nessus vulnerabilities. Steps to Replicate: Run a Nessus scan. Platform/Feature: SBC | Update vulnerable packages to latest. |
83 | SBX-93229 / SBX-87180 | 2 | 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 code is modified to send the TRC logs when the level is set 1 and the key is ipPeer. |
84 | SBX-98660 | 3 | 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 | The code is modified to pass around the index values rather than the pointers and memory blocks being retrieved based on the index value that allows the code to verify if the associated memory block is free before accessing it. |
85 | SBX-96686 / SBX-94486 | 2 | 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: - Make a TEAMS to PSTN call.
- The TEAMS holds the call (MOH).
- The TEAMS disconnect the call during MOH.
Platform/Feature: SBC | The code is modified so that, the DISC cmd gets propagated to the other active peer call side and the call gets terminated correctly. |
86 | SBX-94591 | 2 | 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 | 1. Fix the bug in the CpcGenCodecCriterionMatch(). 2. Downgrade the debug message from the SipSgConvNsdMediaRawTransparencyToSdp() to the INFO level. |
87 | SBX-97948 | 2 | 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 | The code is modified to ensure the internal callId is unique so the incoming request can create a separate one. |
88 | SBX-98401 | 2 | 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.
|
89 | SBX-96816 / SBX-95851 | 2 | 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 | Removed attaching the wrong domain name to the diameter peer when the SRV based FQDN is configured for a diameter peer. |
90 | SBX-96754 / SBX-94619 | 3 | 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 | The code is modified to reflect the latest version. |