This document describes new features, the latest hardware and software requirements, known limitations and other pertinent release information for the latest release of SBC Core.
Please note that all Ribbon bugs reported by customers on a given software release will be fixed in the latest release on that software release branch.
To view and download the latest End of Product Sale (EoPS) and other End Of Life (EOL) notices, navigate to the Resource Library on the corporate website (https://ribboncommunications.com/company/get-help/resource-library).
The SBC Core 07.02.xx documentation is located at the following Wiki space: SBC Core 7.2.x Documentation.
Ribbon Release Notes are protected under the copyright laws of the United States of America. This work contains proprietary information of Ribbon Communications, Westford, MA-01886, USA. Use, disclosure, or reproduction in any form is strictly prohibited without prior authorization from Ribbon Communications.
The following Ribbon Bulletins are referenced in this release note:
Bulletin-18-00028529: The System Security Intrusion Detection AIDE Reports False Positive Alarms
To view/download Ribbon bulletins, do the following:
The WBA section may not include all Warnings, Bulletins and Alerts associated with this release. Before attempting to upgrade to any release, it is recommended to check the Customer Portal in Salesforce for any newly published WBAs that may include this release in the "affected versions" section.
For problems or questions, contact the Global Support Assistance Center:
Ribbon Support Portal: https://ribboncommunications.com/services/ribbon-support-portal
Voice: +1-833-RIBBON1 (1-833-742-2661)
The SBC Core platforms address the next-generation needs of SIP communications by delivering media transcoding, robust security and advanced call routing in a high-performance, 2RU, and 5RU form-factor devices enabling service providers and enterprises to quickly and securely enhance their network by implementing services like SIP trunking, secure Unified Communications and Voice over IP (VoIP).
For more product information, refer to the section About SBC Core in the main documentation space.
The SBC Core software interoperates with the following:
NetScore maintains a list of remote host keys for all nodes from which it collects data. If NetScore is deployed in your network, connectivity to the SBC will be lost any time the SBC software is reinstalled because the SBC’s host key is updated during the install. Refer to NetScore Release Notes for steps needed to reconnect to the SBC.
When using H.323-SIP and SIP-H.323 call flows, an additional Re-invite/Update may get generated towards the SIP side. To suppress this, enable the IP Signaling Profile (IPSP) flag Minimize Relaying Of Media Changes From Other Call Leg
at the SIP side.
H.323 is not supported on SBC SWe cloud deployments.
When upgrading your network, ensure to upgrade each product to the most current release to take advantage of the latest features, enhancements, and fixes.
For complete interoperability details between various Ribbon products, including backwards compatibility, refer to Ribbon Product Compatibilities.
Refer to SBC 5000-7000-SWe Interoperability Matrices for the latest and minimum compatible product versions supporting the 07.02.04R003 release.
When upgrading your network, ensure to upgrade each product to the most current release to take advantage of the latest features, enhancements, and fixes.
For complete interoperability details between various Ribbon products, including backwards compatibility, refer to Ribbon Product Compatibilities.
Refer to SBC 5000-7000-SWe Interoperability Matrices for the latest and minimum compatible product versions supporting all releases. For specific interoperability information for the 07.02.04R003 release, refer to the following table:
To instantiate the SBC instances, the following template can be used:
Example template files are packaged together in .tar.gz and .md5 files separate from the SBC Core application installation and upgrade files:
For more information on the requirements for the SBC SWe Cloud for OpenStack, refer to For OpenStack.
For more information on the requirements for the SBC SWe Cloud for KVM, refer to For KVM Hypervisor.
For more information on the requirements for the SBC SWe Cloud for VMWare, refer to For VMware.
The following SBC 5000 series (51x0/52x0), SBC 5400 and SBC 7000 software and firmware versions are required for this release. For 5xx0 the BIOS can be installed during app install, whereas for 5400 and 7000 the BIOS is included in the firmware package and is installed during the firmware upgrade.
The firmware package of SBC 5400 and 7000 series includes BMC, BIOS, and other binaries. The firmware is upgraded from the BMC.
Use the EMA to verify the currently installed software and firmware versions.
Log on to the EMA, and from the main screen navigate to Monitoring > Dashboard > System and Software Info.
The following software release bundles are available for download from the Customer Portal:
Download the appropriate software packages for your desired configuration from the Customer Portal (https://ribboncommunications.com/services/ribbon-support-portal-login) to your PC:
firmware-5XX0-V03.21.00-R000.img
firmware-5XX0-V03.21.00-R000.img.md5
bmc5X00_v3.21.0-R0.rom.md5sum
bmc5X00_v3.21.0-R0.rom
Execute the Method Of Procedure (MOP) only for upgrading the FPGA image of an SBC 7000 DSP-LC card when the SBC 7000 DSP-LC FPGA version is 0x14. The MOP can be applied at any version time, with the only restriction being that the BMC firmware version is at least 3.2.1R0. However, if the SBC application is running version V05.01.00R000 or higher, then the DSPs will be set to disabled and transcoding and transrating calls will fail if the SBC 7000 DSP-LC FPGA version is 0x14. Therefore, it is necessary to upgrade the SBC 7000 DSP-LC FPGA if the version is 0x14, before upgrading the SBC to 5.1.0. However, the MOP can be applied if the application version is higher than 5.1.0. Click Here to view the 550-06210_DSP-LC_FPGA_Upgrade_MOP.
The ConnexIP Operating System installation package for SBC Core:
Once the ConnexIP ISO procedure is completed, the SBC application package is automatically uploaded to SBC platforms.
The SBC Application installation and upgrade package for SBC Core:
For detailed information on installation and upgrade procedures, refer to SBC Core Software Installation and Upgrade Guide.
These files are for SBC SWe deployments in the OpenStack cloud using VNFM.
For VNFM deployment, the VNF Descriptor (VNFD) file is provided in a Cloud Service Archive (CSAR) package for the type of SBC cluster being deploying. VNFs are independent and CSAR definitions are imported into the VNFM via an Onboarding mechanism. The SBC has several different CSAR variants, for different personalities (S-SBC, M-SBC) and interface types (virtio, sriov). The supported CSAR packages for the SBC are:
Files required for CSAR creation:
For detailed information on installation and upgrade procedures, refer to SBC Core Software Installation and Upgrade Guide.
Only perform a LSWU on an SBC 70000 when the total number of active calls on the system is below 18,000. If the criteria is not met, a double failure during the upgrade may occur, thereby losing all active calls. If such a failure occurs, both active and standby SBC services will go down. Contact Ribbon Support immediately.
Release 7.2 requires additional user account security practices for SBC SWe deployments in Openstack cloud environments. During upgrade of SBC SWe cloud instances deployed using Heat templates, you must use a template that includes SSH keys or passwords for the admin and linuxadmin accounts. The example Heat templates have been updated to include information on how to specify this type of data in the userdata section of a template.
Once the installation or upgrade completes on the SBC 51x0 and SBC SWe platforms, the copy of the installation package (321290561) is automatically removed from the system.
As an SBC Core password security enhancement, user passwords automatically expire after upgrading to 7.2.x. As a result, users are required to change their passwords upon initial login immediately following the upgrade.
Customers using the Network licensing mode will stay on the Network licensing mode after upgrade to the SBC 7.2.4 Release.
Customers using Legacy mode will stay on the Legacy mode after upgrade to SBC 7.2.4 Release. Once upgraded to SBC 7.2.4 Release, the customer will not be able to set Network License mode.
The SBC 7.2 5xx0 and 7000 platforms may exhibit a 7% degradation of CPU performance relative to earlier releases. This is attributable to the Spectre/Meltdown security patches.
For the procedure specific to SBC SWe upgrades on KVM Hypervisor or VMware to take advantage of performance improvements due to hyper-threading, refer to MOP to increase vCPUs Prior to Upgrading SBC SWe on VMware or KVM Hypervisor.
In NFV environments, the method used for upgrades involves rebuilding the instance, which requires additional disk space on the host. The minimum disk space needed for this operation is listed in the table below.
The SBC 51xx and 52xx systems require 24GB of RAM to run 6.x code or higher.
Prior to performing an upgrade to release 07.02.04R003, remove usernames that do not conform to the new SBC user-naming rules to prevent an upgrade failure. The following user-naming rules apply:
Usernames can contain a maximum of 23 characters.
The following names are not allowed:
tty disk kmem dialout fax voice cdrom floppy tape sudo audio dip src utmp video sasl plugdev staff users nogroup i2c dba operator
Note: Any CLI usernames consisting of digits only or not conforming to new user naming rules will be removed after performing a restore config in release 7.2.4R003.
Prior to performing an upgrade to the 7.2 release, the dnsGroups with type mgmt must be specified/updated with the "interface" field. The steps are included in WBA "W-17-00022847". To view the WBA, log on to the Support Portal and click the Announcement link from the menu bar. Enter the bulletin number (last eight numbers) in the search field and press Return.
Prior to performing an upgrade to 7.2 release, the duplicate trunk groups or zones must be removed. The steps are included in WBA "W-17-00022689". To view the WBA, log on to the Support Portal and click the Announcement link from the menu bar. Enter the bulletin number (last eight numbers) in the search field and press Return.
If the above MOP is not run, the LSWU process may fail because of duplicate trunk group or zone names.
If you are upgrading from any SBC version with ePSX configuration to the 07.02.04R003 release, execute the Method of Procedure, MOP to Reconfigure SBC (with ePSX) to External PSX Prior to an Upgrade to 06.00.00R000 Release prior to performing an upgrade. For a list of supported LSWU paths, refer to Supported Upgrade Paths.
When upgrading SBC Core to release 5.0.0 (and above) from a pre-4.2.4 release, complete the "Action to take" immediately after the upgrade if either condition that follows is applicable:
Action to take: On the SIP trunk group facing Broadsoft (or other feature server), set the SIP Trunk Group signaling flag, honorMaddrParam
, to enabled
on the Trunk Group(s) requiring maddr handling. The default is ‘disabled
’.
set addressContext <addressContext name> zone <zone name> sipTrunkGroup <TG name> signaling honorMaddrParam <disabled | enabled>
See the following pages for configuration details:
Starting with 4.2.4R0 release, CPU resource allocation requirements for SBC SWe VM are strictly enforced contrary to previous releases. You must review and verify these VM settings (including co-hosted VMs) against the documented "VM Configuration Recommendations" on the For VMware page in the Hardware and Software Requirements section before upgrading. If you encounter a problem, correct the CPU reservation settings as specified in step 6 of the "Adjust Resource Allocations" procedure on Creating a New SBC SWe VM Instance with VMXNET3. CPU reservation should be set as “number of vCPUs assigned to VM * physical processor CPU frequency". If VM uses the same number of vCPUs as the number of physical processors on the server, this reservation may not be possible. In this case, reduce the number of vCPUs assigned to VM by one and set the CPU reservation to the appropriate value.
When using the show table system serverSoftwareUpgradeStatus
command during the upgrade, the Standby server's LSWU status will always display "Upgrading" even though the upgrade may have failed due to host checker validation. To check if host validation failed for the Standby, check for HostCheck Validation Failed message in the upgrade.out
log.
As a prerequisite for SWe LSWU/upgrade, disable the Call Trace feature prior to performing the LSWU/upgrade and re-enable it once the LSWU/upgrade is completed.
Perform the following procedure on the Standby to check for the Hostcheck Validation Failed message in the upgrade.out
log.
/opt/sonus/staging/upgrade.out
(this log shows the Hostcheck Validation Failed error).show table system serverSoftwareUpgradeStatus
to confirm the successful upgrade.Prior to performing a Live Software Upgrade (LSWU), verify if the system and the databases are in sync. The steps are included in WBA "Warning-14-00020748". To view the WBA, log on to the Support Portal and click the Announcements link from the menu bar. Enter the bulletin number (last eight numbers) in the search field and press Return.
The SBC 7.2 release skips the SRV query if the flag in a DNS NAPTR response from the DNS server indicates to proceed with "A" record query as per RFC 2915/3403. This is a change in behavior from previous releases, where the SBC performed SRV queries irrespective of the "flag" setting returned by DNS Server. If you use DNS NAPTR/SRV/A record query from SBC to determine peer transport address, ensure the DNS Server is configured to return ‘S’ flag to invoke an SRV query.
In this release, LSWU infrastructure is added to the Platform Manager (PM), providing the ability to perform LSWU upgrades to later releases using the PM. However, this feature is not currently supported in 4.2.x releases and should not be used at this time.
Please read the following information and take necessary actions before starting your upgrade to this release.
Since the release 4.1.4, the cryptographic key pair used to sign and verify the package has been changed to enhance security. When installing/upgrading from all 4.0.x releases, all pre-4.1.4 releases (4.1.3 and earlier), and all pre-4.2.3 releases (4.2.2R00x and earlier), do one of the following, depending upon your upgrade method:
LSWU through CLI: Skip the integrity check during LSWU by using the CLI command below.
During LSWU, use the integrityCheck
skip
option when upgrading from CLI:
> request system serverAdmin <server> startSoftwareUpgrade integrityCheck skip package <package>
Integrity check works as expected only when upgrades are started from 4.1.x releases (4.1.4R000 or later) or from 4.2.3R000 or later releases.
Downgrading to any pre-5.0 release from this release requires a ConnexIP re-ISO installation. For more information, refer to:
Customer running 7.1 or 7.2 releases must check the eventLog configuration to confirm that the memusage log type has a server1 syslog configuration and if it is not present, they need to manually create before attempting to upgrade to the latest code.
The following command example output shows how to confirm with the server1 config is present for the memusage log type:
show configuration oam eventLog typeAdmin typeAdmin packet { state enabled; fileCount 64; fileSize 10240; filterLevel info; servers server1; } typeAdmin memusage { state enabled; } Update the configuration with the following commands - configure set oam eventLog typeAdmin memusage servers server1
The SBC Core supports Live Software Upgrade from releases listed in the table below:
Prior to upgrading to 7.x, run the following command to verify availability of at least 40 MB free disk space in the /boot partition.
df -kh
There are no new features in this release.
For lists of the features in previous 7.2.x releases, refer to the following release notes:
The following Severity 1 issues are resolved in this release:
The following Severity 2-4 issues are resolved in this release:
The following Severity 1 issues are resolved in this release:
The following Severity 2/3 issues are resolved in this release:
SBX-100596 Steps to Replicate
When sending an 420, all headers present in incoming request except the ones which are marked as passthrough are sent in Unsupported header. Incoming INVITE Require Header sipParamFilterProfile Config , rejectRequest enabled common for all test cases. Unsupported Header in 420 Bad extension sent to Ingress ( with fix ) Require: Replaces set profiles services sipParamFilterProfile PROFIL1 sipHeader require action passthrough timer Unsupported: replaces Require: Replaces,timer set profiles services sipParamFilterProfile PROFIL1 sipHeader require action passthrough timer Unsupported: replaces Require: Replaces,timer, path,eventlist set profiles services sipParamFilterProfile PROFIL1 sipHeader require action passthrough Replaces,timer Unsupported: path,eventlist Require: Replaces,timer, path,eventlist,unknownHeader1 ( Includes unknown header as well ) sipParamFilterProfile PROFIL1 sipHeader require action passthrough Replaces Unsupported: timer, path,eventlist,unknownHeader1 Require: Replaces,timer, path,eventlist,unknownHeader1 ( Includes unknown header as well ) sipParamFilterProfile PROFIL1 sipHeader require action passthrough Replaces, timer, unknownHeader1 Unsupported: path, eventlist Require: Replaces,timer, path, eventlist, unknownHeader1 ( Includes unknown header as well ) sipParamFilterProfile PROFIL1 sipHeader require action passthrough Replaces, timer, unknownHeader2 Unsupported: path, eventlist, unknownHeader1 ( note that unkonwnheader2 was configured in passthrough list ) Require: Replaces,timer, path,eventlist,unknownHeader1, unknownHeader2 sipParamFilterProfile PROFIL1 sipHeader require action passthrough unknownHeader1, unknownHeader2 Unsupported: timer, replaces, path, eventlist
The following issues are resolved in this release:
SBX-98498 Steps to Replicate
---------------------- dbgDecode CALL FLOW FILE ---------------------- timestamp gcid ingress call leg [ sonus gateway ] egress call leg INVITE <sip:IP>@00.00.000.00:5060;dtg=<example> Via: SIP/2.0/UDP 10.00.000.00:<branch tag>=<example> Via: SIP/2.0/UDP 10.00.000.00:<audio tag>;branch=<example> From: "OBS" <sip:IP@10.00.00.00:<audio tag>>;tag=<example> To: Customer<sip:example@10.00.000.00:5060> Call-ID: <customer call ID> CSeq: 1 INVITE Content-Type: application/sdp sdp { c=IN IP4 <IP address> m= <media tag> a=sendrecv } 17:22:10.773748 [gcid 0x00080000]: [ingressPeer][ sip] ------------------->> [ sip][sonus] SIP/2.0 100 Trying Via: SIP/2.0/UDP 10.00.000.00:<branch tag>=<example> Via: SIP/2.0/UDP 10.00.000.00:<audio tag>;branch=<example> From: "OBS" <sip:IP@branch tag>;tag=<example> To: sut <sip:IP@branch IP>;tag=<address> Call-ID: <customer call ID> CSeq: 1 INVITE 17:22:10.00000 [gcid 0x00080000]: [ingressPeer][ sip] <<------------------- [ sip][sonus] INVITE sip:+<example>;phone-context=private@10.00.00.00:00000;user=phone SIP/2.0 Via: SIP/2.0/UDP <IP address>:5060; branch=<example> From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example> To: <sip:IP@branch IP>;tag=<address> Call-ID: <customer call ID> CSeq: <variable> INVITE Content-Type: application/sdp sdp { c=IN IP4 <IP address> m=<media tag> a=sendrecv } 17:22:10.855252 [gcid 0x00080000]: [sonus][ sip] ------------------->> [ sip][egressPeer] INVITE sip:<example>phone-context=private@10.00.00.00:25768;user=phone SIP/2.0 Via: SIP/2.0/UDP <IP address>:5060;branch=<example> From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example> To: <sip:IP@branch IP>;tag=<address> Call-ID: <customer call ID> CSeq: <variable> INVITE Content-Type: application/sdp sdp { c=IN IP4 <IP address> m=<media tag> a=sendrecv } 17:22:11.338578 [gcid 0x00080000]: [sonus][ sip] ------------------->> [ sip][egressPeer] SIP/2.0 180 Ringing Via: SIP/2.0/UDP <IP address>:5060;branch=<example> From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example> To: <sip:IP@branch IP>;tag=<address> Call-ID: <customer call ID> CSeq: <variable>INVITE RSeq: 1 17:22:11.358614 [gcid 0x00080000]: [sonus][ sip] <<------------------- [ sip][egressPeer] PRACK <sip IP address>:25768;transport=UDP SIP/2.0 Via: SIP/2.0/UDP <IP address>:5060;branch=<example> From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example> To: <sip:IP@branch IP>;tag=<address> Call-ID: <customer call ID> CSeq: <variable>PRACK RAck: 1 <variable>INVITE 17:22:11.362756 [gcid 0x00080000]: [sonus][ sip] ------------------->> [ sip][egressPeer] SIP/2.0 180 Ringing Via: SIP/2.0/UDP <IP address>:5060;branch=<example> Via: SIP/2.0/UDP <IP address>:35015;branch=<example> From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example> To: <sip:IP@branch IP>;tag=<address> Call-ID: <customer call ID> CSeq: <variable> INVITE RSeq: <variable> Content-Type: application/sdp sdp { c=IN IP4 <IP address> m=<media tag> a=sendrecv } 17:22:11.391771 [gcid 0x00080000]: [ingressPeer][ sip] <<------------------- [ sip][sonus] PRACK <sip IP address> SIP/2.0 Via: SIP/2.0/UDP <IP address>:5060;branch=<example> From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example> To: <sip:IP@branch IP>;tag=<address> Call-ID: <customer call ID> CSeq: <variable> PRACK RAck: <variable> INVITE 17:22:11.394747 [gcid 0x00080000]: [ingressPeer][ sip] ------------------->> [ sip][sonus] SIP/2.0 200 OK Via: SIP/2.0/UDP <IP address>:5060;branch=<example> From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example> To: <sip:IP@branch IP>;tag=<address> Call-ID: <customer call ID> CSeq: <variable> PRACK 17:22:11.397195 [gcid 0x00080000]: [ingressPeer][ sip] <<------------------- [ sip][sonus] SIP/2.0 200 OK Via: SIP/2.0/UDP <IP address>:5060;branch=<example> From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example> To: <sip:IP@branch IP>;tag=<address> Call-ID: <customer call ID> CSeq: <variable> PRACK 17:22:11.467157 [gcid 0x00080000]: [sonus][ sip] <<------------------- [ sip][egressPeer] SIP/2.0 180 Ringing Via: SIP/2.0/UDP <IP address>:5060;branch=<example> From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example> To: <sip:IP@branch IP>;tag=<address> Call-ID: <customer call ID> CSeq: <variable>INVITE RSeq: <variable> 17:22:15.470342 [gcid 0x00080000]: [sonus][ sip] <<------------------- [ sip][egressPeer] PRACK sip:10.54.81.66:25768;transport=UDP SIP/2.0 Via: SIP/2.0/UDP <IP address>:5060;branch=<example> From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example> To: <sip:IP@branch IP>;tag=<address> Call-ID: <customer call ID> CSeq: <variable>PRACK RAck: <variable> INVITE 17:22:15.475654 [gcid 0x00080000]: [sonus][ sip] ------------------->> [ sip][egressPeer] SIP/2.0 180 Ringing Via: SIP/2.0/UDP <IP address>:5060;branch=<example> Via: SIP/2.0/UDP <IP address>:35015;branch=<example> From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example> To: <sip:IP@branch IP>;tag=<address> Call-ID: <customer call ID> CSeq: <variable> INVITE RSeq: <variable> 17:22:15.478644 [gcid 0x00080000]: [ingressPeer][ sip] <<------------------- [ sip][sonus] PRACK <sip IP address> Via: SIP/2.0/UDP <IP address>:5060;branch=<example> From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example> To: <sip:IP@branch IP>;tag=<address> Call-ID: <customer call ID> CSeq: <variable> PRACK RAck: <variable> INVITE Content-Type: application/sdp 17:22:15.481542 [gcid 0x00080000]: [ingressPeer][ sip] ------------------->> [ sip][sonus] SIP/2.0 200 OK Via: SIP/2.0/UDP <IP address>:5060;branch=<example> From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example> To: <sip:IP@branch IP>;tag=<address> Call-ID: <customer call ID> CSeq: <variable> PRACK 17:22:15.484805 [gcid 0x00080000]: [ingressPeer][ sip] <<------------------- [ sip][sonus] SIP/2.0 200 OK Via: SIP/2.0/UDP <IP address>:5060;branch=<example> From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example> To: <sip:IP@branch IP>;tag=<address> Call-ID: <customer call ID> CSeq: <variable> PRACK 17:22:15.582867 [gcid 0x00080000]: [sonus][ sip] <<------------------- [ sip][egressPeer] SIP/2.0 183 Session Progress Via: SIP/2.0/UDP <IP address>:5060;branch=<example> From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example> To: <sip:IP@branch IP>;tag=<address> Call-ID: <customer call ID> CSeq: <variable>INVITE RSeq: 3 Content-Type: application/sdp sdp { c=IN IP4 <sip IP address> c=IN IP4 <sip IP address> m=<media tag> a=sendrecv } 17:22:15.786568 [gcid 0x00080000]: [sonus][ sip] <<------------------- [ sip][egressPeer] PRACK <sip IP address>;transport=UDP SIP/2.0 Via: SIP/2.0/UDP <IP address>:5060;branch=<example> From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example> To: <sip:IP@branch IP>;tag=<address> Call-ID: <customer call ID> CSeq: <variable>PRACK RAck: <variable> INVITE 17:22:15.795065 [gcid 0x00080000]: [sonus][ sip] ------------------->> [ sip][egressPeer] SIP/2.0 200 OK Via: SIP/2.0/UDP <IP address>:5060;branch=<example> From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example> To: <sip:IP@branch IP>;tag=<address> Call-ID: <customer call ID> CSeq: <variable> PRACK 17:22:15.797360 [gcid 0x00080000]: [sonus][ sip] <<------------------- [ sip][egressPeer] SIP/2.0 183 Session Progress Via: SIP/2.0/UDP <IP address>:5060;branch=<example> Via: SIP/2.0/UDP <IP address>:35015;branch=<example> From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example> To: <sip:IP@branch IP>;tag=<address> Call-ID: <customer call ID> CSeq: <variable> INVITE RSeq: <variable> 17:22:15.797978 [gcid 0x00080000]: [ingressPeer][ sip] <<------------------- [ sip][sonus] PRACK <sip IP address> SIP/2.0 Via: SIP/2.0/UDP <IP address>:5060;branch=<example> From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example> To: <sip:IP@branch IP>;tag=<address> Call-ID: <customer call ID: sip IP address> CSeq: <variable> PRACK RAck: <variable> INVITE Content-Type: application/sdp 17:22:15.800737 [gcid 0x00080000]: [ingressPeer][ sip] ------------------->> [ sip][sonus] SIP/2.0 200 OK Via: SIP/2.0/UDP <IP address>:5060;branch=<example> From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example> To: <sip:IP@branch IP>;tag=<address> Call-ID: <customer call ID: sip IP address> CSeq: <variable>PRACK 17:22:15.804002 [gcid 0x00080000]: [ingressPeer][ sip] <<------------------- [ sip][sonus] UPDATE <sip IP address>;transport=UDP SIP/2.0 Via: SIP/2.0/UDP <IP address>:5060;branch=<example> From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example> To: <sip:IP@branch IP>;tag=<address> Call-ID: <customer call ID: sip IP address> CSeq: <variable>UPDATE Content-Type: application/sdp sdp { c=IN IP4 <sip IP address> m=<media type> a=sendrecv } 17:22:15.844104 [gcid 0x00080000]: [ingressPeer][ sip] <<------------------- [ sip][sonus] SIP/2.0 200 OK Via: SIP/2.0/UDP <IP address>:5060;branch=<example> From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example> To: <sip:IP@branch IP>;tag=<address> Call-ID: <customer call ID: sip IP address> CSeq: <variable>UPDATE Content-Type: application/sdp sdp { c=IN IP4 <sip IP address> m=<media type> a=sendrecv } 17:22:15.844634 [gcid 0x00080000]: [ingressPeer][ sip] ------------------->> [ sip][sonus] SIP/2.0 180 Ringing Via: SIP/2.0/UDP <IP address>:5060;branch=<example> From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example> To: <sip:IP@branch IP>;tag=<address> Call-ID: <customer call ID: sip IP address> CSeq: <variable>INVITE RSeq: <variable> 17:22:20.803253 [gcid 0x00080000]: [sonus][ sip] <<------------------- [ sip][egressPeer] PRACK <sip IP address>;transport=UDP SIP/2.0 Via: SIP/2.0/UDP <IP address>:5060;branch=<example> From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example> To: <sip:IP@branch IP>;tag=<address> Call-ID: <customer call ID: sip IP address> CSeq: <variable>PRACK RAck: <variable> INVITE 17:22:20.807563 [gcid 0x00080000]: [sonus][ sip] ------------------->> [ sip][egressPeer] SIP/2.0 200 OK Via: SIP/2.0/UDP <IP address>:5060;branch=<example> From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example> To: <sip:IP@branch IP>;tag=<address> Call-ID: <customer call ID: sip IP address> CSeq: <variable>PRACK 17:22:20.808144 [gcid 0x00080000]: [sonus][ sip] <<------------------- [ sip][egressPeer] SIP/2.0 180 Ringing Via: SIP/2.0/UDP <IP address>:5060;branch=<example> Via: SIP/2.0/UDP <IP address>:35015;branch=<example> From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example> To: <sip:IP@branch IP>;tag=<address> Call-ID: <customer call ID: sip IP address> CSeq: 1 INVITE RSeq: 279809 17:22:20.809687 [gcid 0x00080000]: [ingressPeer][ sip] <<------------------- [ sip][sonus] PRACK <sip IP address> SIP/2.0 Via: SIP/2.0/UDP <IP address>:5060;branch=<example> From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example> To: <sip:IP@branch IP>;tag=<address> Call-ID: <customer call ID: sip IP address> CSeq: <variable>PRACK RAck: <variable> INVITE Content-Type: application/sdp 17:22:20.812694 [gcid 0x00080000]: [ingressPeer][ sip] ------------------->> [ sip][sonus] SIP/2.0 200 OK Via: SIP/2.0/UDP <IP address>:5060;branch=<example> From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example> To: <sip:IP@branch IP>;tag=<address> Call-ID: <customer call ID: sip IP address> CSeq: <variable>PRACK 17:22:20.816141 [gcid 0x00080000]: [ingressPeer][ sip] <<------------------- [ sip][sonus] SIP/2.0 180 Ringing Via: SIP/2.0/UDP <IP address>:5060;branch=<example> From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example> To: <sip:IP@branch IP>;tag=<address> Call-ID: <customer call ID: sip IP address> CSeq: <variable>INVITE RSeq: <variable> 17:22:21.314820 [gcid 0x00080000]: [sonus][ sip] <<------------------- [ sip][egressPeer] PRACK <sip IP address>;transport=UDP SIP/2.0 Via: SIP/2.0/UDP <IP address>:5060;branch=<example> From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example> To: <sip:IP@branch IP>;tag=<address> Call-ID: <customer call ID: sip IP address> CSeq: <variable>PRACK RAck: <variable> INVITE 17:22:21.318799 [gcid 0x00080000]: [sonus][ sip] ------------------->> [ sip][egressPeer] SIP/2.0 200 OK Via: SIP/2.0/UDP <IP address>:5060;branch=<example> From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example> To: <sip:IP@branch IP>;tag=<address> Call-ID: <customer call ID: sip IP address> CSeq: <variable>PRACK 17:22:21.319450 [gcid 0x00080000]: [sonus][ sip] <<------------------- [ sip][egressPeer] SIP/2.0 180 Ringing Via: SIP/2.0/UDP <IP address>:5060;branch=<example> Via: SIP/2.0/UDP <IP address>:5060;branch=<example> From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example> To: <sip:IP@branch IP>;tag=<address> Call-ID: <customer call ID: sip IP address> CSeq: <variable>INVITE RSeq: <variable> 17:22:21.321235 [gcid 0x00080000]: [ingressPeer][ sip] <<------------------- [ sip][sonus] PRACK <sip IP address>:5060 SIP/2.0 Via: SIP/2.0/UDP <IP address>:5060;branch=<example> From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example> To: <sip:IP@branch IP>;tag=<address> Call-ID: <customer call ID: sip IP address> CSeq: <variable>PRACK RAck: <variable> INVITE Content-Type: application/sdp 17:22:21.324074 [gcid 0x00080000]: [ingressPeer][ sip] ------------------->> [ sip][sonus] SIP/2.0 200 OK Via: SIP/2.0/UDP <IP address>:5060;branch=<example> From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example> To: <sip:IP@branch IP>;tag=<address> Call-ID: <customer call ID: sip IP address> CSeq: <variable>PRACK 17:22:21.326579 [gcid 0x00080000]: [ingressPeer][ sip] <<------------------- [ sip][sonus] SIP/2.0 200 OK Via: SIP/2.0/UDP <IP address>:5060;branch=<example> From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example> To: <sip:IP@branch IP>;tag=<address> Call-ID: <customer call ID: sip IP address> CSeq: <variable>INVITE Content-Type: application/sdp sdp { c=IN IP4 <sip IP address> m=<media type> a=sendrecv } 17:22:25.823182 [gcid 0x00080000]: [sonus][ sip] <<------------------- [ sip][egressPeer] UPDATE <sip IP address>35015;transport=UDP SIP/2.0 Via: SIP/2.0/UDP <IP address>:5060;branch=<example> From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example> To: <sip:IP@branch IP>;tag=<address> Call-ID: <customer call ID: sip IP address> CSeq: <variable>UPDATE Content-Type: application/sdp sdp { c=IN IP4 <sip IP address> m=<media type> a=sendrecv }
The following severity 1 issues are resolved in this release:
The following Severity 2 and 3 issues are resolved in this release:
The following Severity 1 issues are resolved in this release:
The following Severity 2/3 issues are resolved in this release:
There are no known issues in this release.
The following issues exist in this release:
There are no known issues in this release.
The following issue exists in this release:
The following issue exists in this release:
The following issues exist in this release:
The following Severity 1 issues exist in this release:
The following Severity 2/3 issues exist in this release:
The following issues exist in this release:
The following Severity 1 issues exist in this release:
The following Severity 2, 3, and 4 issues exist in this release:
The following limitations exist in this release:
Due to a known EMA GUI issue, it can take up to 10 minutes to process each SMM rule when provisioning SMM on the SBC using the EMA. This will be fixed in a future release.
The Antitrombone feature is not supported on the D-SBC.
The VLAN tagged SRIOV packet interfaces are unable to ping endpoint Gateway IPs in the VMware platform because of an issue with VMWare.
When upgrading SBC SWe cloud instances to release 7.2, you must update your Heat template userdata section to include mandatory SSH key information. An issue in OpenStack requires that you use the stack-update process rather than re-launch after updating the template, which leads to a new UUID for the instance. As a result, you must regenerate and apply new license bundles to the upgraded instances during the upgrade.
Refer to Upgrading M-SBCs in an N:1 Redundancy Group for the relevant procedure.
The following functionalities are not supported with SBC Microservices:
Two stage calls
Network Licensing Limitations
After switchover during grace period, when the new standby SBC comes up and establishes itself as standby, there is a short period (a few minutes) when the standby is synchronized for normal operation, but the new standby has not yet completed establishing its licensing state using the grace license information. If there is a second SBC switchover during that window, the new active SBC (which became active before completing license state synchronization) will lose calls until it re-acquires the grace licenses.
For configuring Network Wide Licensing, refer to Configuring Network Wide Licensing on D-SBC. This procedure is common for D-SBC and SBC.
This document describes new features, the latest hardware and software requirements, known limitations and other pertinent release information for the latest release of SBC Core.
Please note that all Ribbon bugs reported by customers on a given software release will be fixed in the latest release on that software release branch.
To view and download the latest End of Product Sale (EoPS) and other End Of Life (EOL) notices, navigate to the Resource Library on the corporate website (https://ribboncommunications.com/company/get-help/resource-library).
The SBC Core 07.02.xx documentation is located at the following Wiki space: SBC Core 7.2.x Documentation.
Ribbon Release Notes are protected under the copyright laws of the United States of America. This work contains proprietary information of Ribbon Communications, Westford, MA-01886, USA. Use, disclosure, or reproduction in any form is strictly prohibited without prior authorization from Ribbon Communications.
The following Ribbon Bulletins are referenced in this release note:
Bulletin-18-00028529: The System Security Intrusion Detection AIDE Reports False Positive Alarms
To view/download Ribbon bulletins, do the following:
The WBA section may not include all Warnings, Bulletins and Alerts associated with this release. Before attempting to upgrade to any release, it is recommended to check the Customer Portal in Salesforce for any newly published WBAs that may include this release in the "affected versions" section.
For problems or questions, contact the Global Support Assistance Center:
Ribbon Support Portal: https://ribboncommunications.com/services/ribbon-support-portal
Voice: +1-833-RIBBON1 (1-833-742-2661)
The SBC Core platforms address the next-generation needs of SIP communications by delivering media transcoding, robust security and advanced call routing in a high-performance, 2RU, and 5RU form-factor devices enabling service providers and enterprises to quickly and securely enhance their network by implementing services like SIP trunking, secure Unified Communications and Voice over IP (VoIP).
For more product information, refer to the section About SBC Core in the main documentation space.
The SBC Core software interoperates with the following:
NetScore maintains a list of remote host keys for all nodes from which it collects data. If NetScore is deployed in your network, connectivity to the SBC will be lost any time the SBC software is reinstalled because the SBC’s host key is updated during the install. Refer to NetScore Release Notes for steps needed to reconnect to the SBC.
When using H.323-SIP and SIP-H.323 call flows, an additional Re-invite/Update may get generated towards the SIP side. To suppress this, enable the IP Signaling Profile (IPSP) flag Minimize Relaying Of Media Changes From Other Call Leg
at the SIP side.
H.323 is not supported on SBC SWe cloud deployments.
When upgrading your network, ensure to upgrade each product to the most current release to take advantage of the latest features, enhancements, and fixes.
For complete interoperability details between various Ribbon products, including backwards compatibility, refer to Ribbon Product Compatibilities.
Refer to SBC 5000-7000-SWe Interoperability Matrices for the latest and minimum compatible product versions supporting the 07.02.04R003 release.
When upgrading your network, ensure to upgrade each product to the most current release to take advantage of the latest features, enhancements, and fixes.
For complete interoperability details between various Ribbon products, including backwards compatibility, refer to Ribbon Product Compatibilities.
Refer to SBC 5000-7000-SWe Interoperability Matrices for the latest and minimum compatible product versions supporting all releases. For specific interoperability information for the 07.02.04R003 release, refer to the following table:
To instantiate the SBC instances, the following template can be used:
Example template files are packaged together in .tar.gz and .md5 files separate from the SBC Core application installation and upgrade files:
For more information on the requirements for the SBC SWe Cloud for OpenStack, refer to For OpenStack.
For more information on the requirements for the SBC SWe Cloud for KVM, refer to For KVM Hypervisor.
For more information on the requirements for the SBC SWe Cloud for VMWare, refer to For VMware.
The following SBC 5000 series (51x0/52x0), SBC 5400 and SBC 7000 software and firmware versions are required for this release. For 5xx0 the BIOS can be installed during app install, whereas for 5400 and 7000 the BIOS is included in the firmware package and is installed during the firmware upgrade.
The firmware package of SBC 5400 and 7000 series includes BMC, BIOS, and other binaries. The firmware is upgraded from the BMC.
Use the EMA to verify the currently installed software and firmware versions.
Log on to the EMA, and from the main screen navigate to Monitoring > Dashboard > System and Software Info.
The following software release bundles are available for download from the Customer Portal:
Download the appropriate software packages for your desired configuration from the Customer Portal (https://ribboncommunications.com/services/ribbon-support-portal-login) to your PC:
firmware-5XX0-V03.21.00-R000.img
firmware-5XX0-V03.21.00-R000.img.md5
bmc5X00_v3.21.0-R0.rom.md5sum
bmc5X00_v3.21.0-R0.rom
Execute the Method Of Procedure (MOP) only for upgrading the FPGA image of an SBC 7000 DSP-LC card when the SBC 7000 DSP-LC FPGA version is 0x14. The MOP can be applied at any version time, with the only restriction being that the BMC firmware version is at least 3.2.1R0. However, if the SBC application is running version V05.01.00R000 or higher, then the DSPs will be set to disabled and transcoding and transrating calls will fail if the SBC 7000 DSP-LC FPGA version is 0x14. Therefore, it is necessary to upgrade the SBC 7000 DSP-LC FPGA if the version is 0x14, before upgrading the SBC to 5.1.0. However, the MOP can be applied if the application version is higher than 5.1.0. Click Here to view the 550-06210_DSP-LC_FPGA_Upgrade_MOP.
The ConnexIP Operating System installation package for SBC Core:
Once the ConnexIP ISO procedure is completed, the SBC application package is automatically uploaded to SBC platforms.
The SBC Application installation and upgrade package for SBC Core:
For detailed information on installation and upgrade procedures, refer to SBC Core Software Installation and Upgrade Guide.
These files are for SBC SWe deployments in the OpenStack cloud using VNFM.
For VNFM deployment, the VNF Descriptor (VNFD) file is provided in a Cloud Service Archive (CSAR) package for the type of SBC cluster being deploying. VNFs are independent and CSAR definitions are imported into the VNFM via an Onboarding mechanism. The SBC has several different CSAR variants, for different personalities (S-SBC, M-SBC) and interface types (virtio, sriov). The supported CSAR packages for the SBC are:
Files required for CSAR creation:
For detailed information on installation and upgrade procedures, refer to SBC Core Software Installation and Upgrade Guide.
Only perform a LSWU on an SBC 70000 when the total number of active calls on the system is below 18,000. If the criteria is not met, a double failure during the upgrade may occur, thereby losing all active calls. If such a failure occurs, both active and standby SBC services will go down. Contact Ribbon Support immediately.
Release 7.2 requires additional user account security practices for SBC SWe deployments in Openstack cloud environments. During upgrade of SBC SWe cloud instances deployed using Heat templates, you must use a template that includes SSH keys or passwords for the admin and linuxadmin accounts. The example Heat templates have been updated to include information on how to specify this type of data in the userdata section of a template.
Once the installation or upgrade completes on the SBC 51x0 and SBC SWe platforms, the copy of the installation package (SBC Core Installation and Upgrade Package) is automatically removed from the system.
As an SBC Core password security enhancement, user passwords automatically expire after upgrading to 7.2.x. As a result, users are required to change their passwords upon initial login immediately following the upgrade.
Customers using the Network licensing mode will stay on the Network licensing mode after upgrade to the SBC 7.2.4 Release.
Customers using Legacy mode will stay on the Legacy mode after upgrade to SBC 7.2.4 Release. Once upgraded to SBC 7.2.4 Release, the customer will not be able to set Network License mode.
The SBC 7.2 5xx0 and 7000 platforms may exhibit a 7% degradation of CPU performance relative to earlier releases. This is attributable to the Spectre/Meltdown security patches.
For the procedure specific to SBC SWe upgrades on KVM Hypervisor or VMware to take advantage of performance improvements due to hyper-threading, refer to MOP to increase vCPUs Prior to Upgrading SBC SWe on VMware or KVM Hypervisor.
In NFV environments, the method used for upgrades involves rebuilding the instance, which requires additional disk space on the host. The minimum disk space needed for this operation is listed in the table below.
The SBC 51xx and 52xx systems require 24GB of RAM to run 6.x code or higher.
Prior to performing an upgrade to release 07.02.04R003, remove usernames that do not conform to the new SBC user-naming rules to prevent an upgrade failure. The following user-naming rules apply:
Usernames can contain a maximum of 23 characters.
The following names are not allowed:
tty disk kmem dialout fax voice cdrom floppy tape sudo audio dip src utmp video sasl plugdev staff users nogroup i2c dba operator
Note: Any CLI usernames consisting of digits only or not conforming to new user naming rules will be removed after performing a restore config in release 7.2.4R003.
Prior to performing an upgrade to the 7.2 release, the dnsGroups with type mgmt must be specified/updated with the "interface" field. The steps are included in WBA "W-17-00022847". To view the WBA, log on to the Support Portal and click the Announcement link from the menu bar. Enter the bulletin number (last eight numbers) in the search field and press Return.
Prior to performing an upgrade to 7.2 release, the duplicate trunk groups or zones must be removed. The steps are included in WBA "W-17-00022689". To view the WBA, log on to the Support Portal and click the Announcement link from the menu bar. Enter the bulletin number (last eight numbers) in the search field and press Return.
If the above MOP is not run, the LSWU process may fail because of duplicate trunk group or zone names.
If you are upgrading from any SBC version with ePSX configuration to the 07.02.04R003 release, execute the Method of Procedure, MOP to Reconfigure SBC (with ePSX) to External PSX Prior to an Upgrade to 06.00.00R000 Release prior to performing an upgrade. For a list of supported LSWU paths, refer to Supported Upgrade Paths.
When upgrading SBC Core to release 5.0.0 (and above) from a pre-4.2.4 release, complete the "Action to take" immediately after the upgrade if either condition that follows is applicable:
Action to take: On the SIP trunk group facing Broadsoft (or other feature server), set the SIP Trunk Group signaling flag, honorMaddrParam
, to enabled
on the Trunk Group(s) requiring maddr handling. The default is ‘disabled
’.
set addressContext <addressContext name> zone <zone name> sipTrunkGroup <TG name> signaling honorMaddrParam <disabled | enabled>
See the following pages for configuration details:
Starting with 4.2.4R0 release, CPU resource allocation requirements for SBC SWe VM are strictly enforced contrary to previous releases. You must review and verify these VM settings (including co-hosted VMs) against the documented "VM Configuration Recommendations" on the For VMware page in the Hardware and Software Requirements section before upgrading. If you encounter a problem, correct the CPU reservation settings as specified in step 6 of the "Adjust Resource Allocations" procedure on Creating a New SBC SWe VM Instance with VMXNET3. CPU reservation should be set as “number of vCPUs assigned to VM * physical processor CPU frequency". If VM uses the same number of vCPUs as the number of physical processors on the server, this reservation may not be possible. In this case, reduce the number of vCPUs assigned to VM by one and set the CPU reservation to the appropriate value.
When using the show table system serverSoftwareUpgradeStatus
command during the upgrade, the Standby server's LSWU status will always display "Upgrading" even though the upgrade may have failed due to host checker validation. To check if host validation failed for the Standby, check for HostCheck Validation Failed message in the upgrade.out
log.
As a prerequisite for SWe LSWU/upgrade, disable the Call Trace feature prior to performing the LSWU/upgrade and re-enable it once the LSWU/upgrade is completed.
Perform the following procedure on the Standby to check for the Hostcheck Validation Failed message in the upgrade.out
log.
/opt/sonus/staging/upgrade.out
(this log shows the Hostcheck Validation Failed error).show table system serverSoftwareUpgradeStatus
to confirm the successful upgrade.Prior to performing a Live Software Upgrade (LSWU), verify if the system and the databases are in sync. The steps are included in WBA "Warning-14-00020748". To view the WBA, log on to the Support Portal and click the Announcements link from the menu bar. Enter the bulletin number (last eight numbers) in the search field and press Return.
The SBC 7.2 release skips the SRV query if the flag in a DNS NAPTR response from the DNS server indicates to proceed with "A" record query as per RFC 2915/3403. This is a change in behavior from previous releases, where the SBC performed SRV queries irrespective of the "flag" setting returned by DNS Server. If you use DNS NAPTR/SRV/A record query from SBC to determine peer transport address, ensure the DNS Server is configured to return ‘S’ flag to invoke an SRV query.
In this release, LSWU infrastructure is added to the Platform Manager (PM), providing the ability to perform LSWU upgrades to later releases using the PM. However, this feature is not currently supported in 4.2.x releases and should not be used at this time.
Please read the following information and take necessary actions before starting your upgrade to this release.
Since the release 4.1.4, the cryptographic key pair used to sign and verify the package has been changed to enhance security. When installing/upgrading from all 4.0.x releases, all pre-4.1.4 releases (4.1.3 and earlier), and all pre-4.2.3 releases (4.2.2R00x and earlier), do one of the following, depending upon your upgrade method:
LSWU through CLI: Skip the integrity check during LSWU by using the CLI command below.
During LSWU, use the integrityCheck
skip
option when upgrading from CLI:
> request system serverAdmin <server> startSoftwareUpgrade integrityCheck skip package <package>
Integrity check works as expected only when upgrades are started from 4.1.x releases (4.1.4R000 or later) or from 4.2.3R000 or later releases.
Downgrading to any pre-5.0 release from this release requires a ConnexIP re-ISO installation. For more information, refer to:
Customer running 7.1 or 7.2 releases must check the eventLog configuration to confirm that the memusage log type has a server1 syslog configuration and if it is not present, they need to manually create before attempting to upgrade to the latest code.
The following command example output shows how to confirm with the server1 config is present for the memusage log type:
show configuration oam eventLog typeAdmin typeAdmin packet { state enabled; fileCount 64; fileSize 10240; filterLevel info; servers server1; } typeAdmin memusage { state enabled; } Update the configuration with the following commands - configure set oam eventLog typeAdmin memusage servers server1
The SBC Core supports Live Software Upgrade from releases listed in the table below:
There are no new features in this release.
For lists of the features in previous 7.2.x releases, refer to the following release notes:
The following Severity 1 issues are resolved in this release:
The following Severity 2-4 issues are resolved in this release:
The following Severity 1 issues are resolved in this release:
The following Severity 2/3 issues are resolved in this release:
SBX-100596 Steps to Replicate
When sending an 420, all headers present in incoming request except the ones which are marked as passthrough are sent in Unsupported header. Incoming INVITE Require Header sipParamFilterProfile Config , rejectRequest enabled common for all test cases. Unsupported Header in 420 Bad extension sent to Ingress ( with fix ) Require: Replaces set profiles services sipParamFilterProfile PROFIL1 sipHeader require action passthrough timer Unsupported: replaces Require: Replaces,timer set profiles services sipParamFilterProfile PROFIL1 sipHeader require action passthrough timer Unsupported: replaces Require: Replaces,timer, path,eventlist set profiles services sipParamFilterProfile PROFIL1 sipHeader require action passthrough Replaces,timer Unsupported: path,eventlist Require: Replaces,timer, path,eventlist,unknownHeader1 ( Includes unknown header as well ) sipParamFilterProfile PROFIL1 sipHeader require action passthrough Replaces Unsupported: timer, path,eventlist,unknownHeader1 Require: Replaces,timer, path,eventlist,unknownHeader1 ( Includes unknown header as well ) sipParamFilterProfile PROFIL1 sipHeader require action passthrough Replaces, timer, unknownHeader1 Unsupported: path, eventlist Require: Replaces,timer, path, eventlist, unknownHeader1 ( Includes unknown header as well ) sipParamFilterProfile PROFIL1 sipHeader require action passthrough Replaces, timer, unknownHeader2 Unsupported: path, eventlist, unknownHeader1 ( note that unkonwnheader2 was configured in passthrough list ) Require: Replaces,timer, path,eventlist,unknownHeader1, unknownHeader2 sipParamFilterProfile PROFIL1 sipHeader require action passthrough unknownHeader1, unknownHeader2 Unsupported: timer, replaces, path, eventlist
The following issues are resolved in this release:
SBX-98498 Steps to Replicate
---------------------- dbgDecode CALL FLOW FILE ---------------------- timestamp gcid ingress call leg [ sonus gateway ] egress call leg INVITE <sip:IP>@00.00.000.00:5060;dtg=<example> Via: SIP/2.0/UDP 10.00.000.00:<branch tag>=<example> Via: SIP/2.0/UDP 10.00.000.00:<audio tag>;branch=<example> From: "OBS" <sip:IP@10.00.00.00:<audio tag>>;tag=<example> To: Customer<sip:example@10.00.000.00:5060> Call-ID: <customer call ID> CSeq: 1 INVITE Content-Type: application/sdp sdp { c=IN IP4 <IP address> m= <media tag> a=sendrecv } 17:22:10.773748 [gcid 0x00080000]: [ingressPeer][ sip] ------------------->> [ sip][sonus] SIP/2.0 100 Trying Via: SIP/2.0/UDP 10.00.000.00:<branch tag>=<example> Via: SIP/2.0/UDP 10.00.000.00:<audio tag>;branch=<example> From: "OBS" <sip:IP@branch tag>;tag=<example> To: sut <sip:IP@branch IP>;tag=<address> Call-ID: <customer call ID> CSeq: 1 INVITE 17:22:10.00000 [gcid 0x00080000]: [ingressPeer][ sip] <<------------------- [ sip][sonus] INVITE sip:+<example>;phone-context=private@10.00.00.00:00000;user=phone SIP/2.0 Via: SIP/2.0/UDP <IP address>:5060; branch=<example> From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example> To: <sip:IP@branch IP>;tag=<address> Call-ID: <customer call ID> CSeq: <variable> INVITE Content-Type: application/sdp sdp { c=IN IP4 <IP address> m=<media tag> a=sendrecv } 17:22:10.855252 [gcid 0x00080000]: [sonus][ sip] ------------------->> [ sip][egressPeer] INVITE sip:<example>phone-context=private@10.00.00.00:25768;user=phone SIP/2.0 Via: SIP/2.0/UDP <IP address>:5060;branch=<example> From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example> To: <sip:IP@branch IP>;tag=<address> Call-ID: <customer call ID> CSeq: <variable> INVITE Content-Type: application/sdp sdp { c=IN IP4 <IP address> m=<media tag> a=sendrecv } 17:22:11.338578 [gcid 0x00080000]: [sonus][ sip] ------------------->> [ sip][egressPeer] SIP/2.0 180 Ringing Via: SIP/2.0/UDP <IP address>:5060;branch=<example> From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example> To: <sip:IP@branch IP>;tag=<address> Call-ID: <customer call ID> CSeq: <variable>INVITE RSeq: 1 17:22:11.358614 [gcid 0x00080000]: [sonus][ sip] <<------------------- [ sip][egressPeer] PRACK <sip IP address>:25768;transport=UDP SIP/2.0 Via: SIP/2.0/UDP <IP address>:5060;branch=<example> From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example> To: <sip:IP@branch IP>;tag=<address> Call-ID: <customer call ID> CSeq: <variable>PRACK RAck: 1 <variable>INVITE 17:22:11.362756 [gcid 0x00080000]: [sonus][ sip] ------------------->> [ sip][egressPeer] SIP/2.0 180 Ringing Via: SIP/2.0/UDP <IP address>:5060;branch=<example> Via: SIP/2.0/UDP <IP address>:35015;branch=<example> From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example> To: <sip:IP@branch IP>;tag=<address> Call-ID: <customer call ID> CSeq: <variable> INVITE RSeq: <variable> Content-Type: application/sdp sdp { c=IN IP4 <IP address> m=<media tag> a=sendrecv } 17:22:11.391771 [gcid 0x00080000]: [ingressPeer][ sip] <<------------------- [ sip][sonus] PRACK <sip IP address> SIP/2.0 Via: SIP/2.0/UDP <IP address>:5060;branch=<example> From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example> To: <sip:IP@branch IP>;tag=<address> Call-ID: <customer call ID> CSeq: <variable> PRACK RAck: <variable> INVITE 17:22:11.394747 [gcid 0x00080000]: [ingressPeer][ sip] ------------------->> [ sip][sonus] SIP/2.0 200 OK Via: SIP/2.0/UDP <IP address>:5060;branch=<example> From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example> To: <sip:IP@branch IP>;tag=<address> Call-ID: <customer call ID> CSeq: <variable> PRACK 17:22:11.397195 [gcid 0x00080000]: [ingressPeer][ sip] <<------------------- [ sip][sonus] SIP/2.0 200 OK Via: SIP/2.0/UDP <IP address>:5060;branch=<example> From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example> To: <sip:IP@branch IP>;tag=<address> Call-ID: <customer call ID> CSeq: <variable> PRACK 17:22:11.467157 [gcid 0x00080000]: [sonus][ sip] <<------------------- [ sip][egressPeer] SIP/2.0 180 Ringing Via: SIP/2.0/UDP <IP address>:5060;branch=<example> From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example> To: <sip:IP@branch IP>;tag=<address> Call-ID: <customer call ID> CSeq: <variable>INVITE RSeq: <variable> 17:22:15.470342 [gcid 0x00080000]: [sonus][ sip] <<------------------- [ sip][egressPeer] PRACK sip:10.54.81.66:25768;transport=UDP SIP/2.0 Via: SIP/2.0/UDP <IP address>:5060;branch=<example> From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example> To: <sip:IP@branch IP>;tag=<address> Call-ID: <customer call ID> CSeq: <variable>PRACK RAck: <variable> INVITE 17:22:15.475654 [gcid 0x00080000]: [sonus][ sip] ------------------->> [ sip][egressPeer] SIP/2.0 180 Ringing Via: SIP/2.0/UDP <IP address>:5060;branch=<example> Via: SIP/2.0/UDP <IP address>:35015;branch=<example> From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example> To: <sip:IP@branch IP>;tag=<address> Call-ID: <customer call ID> CSeq: <variable> INVITE RSeq: <variable> 17:22:15.478644 [gcid 0x00080000]: [ingressPeer][ sip] <<------------------- [ sip][sonus] PRACK <sip IP address> Via: SIP/2.0/UDP <IP address>:5060;branch=<example> From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example> To: <sip:IP@branch IP>;tag=<address> Call-ID: <customer call ID> CSeq: <variable> PRACK RAck: <variable> INVITE Content-Type: application/sdp 17:22:15.481542 [gcid 0x00080000]: [ingressPeer][ sip] ------------------->> [ sip][sonus] SIP/2.0 200 OK Via: SIP/2.0/UDP <IP address>:5060;branch=<example> From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example> To: <sip:IP@branch IP>;tag=<address> Call-ID: <customer call ID> CSeq: <variable> PRACK 17:22:15.484805 [gcid 0x00080000]: [ingressPeer][ sip] <<------------------- [ sip][sonus] SIP/2.0 200 OK Via: SIP/2.0/UDP <IP address>:5060;branch=<example> From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example> To: <sip:IP@branch IP>;tag=<address> Call-ID: <customer call ID> CSeq: <variable> PRACK 17:22:15.582867 [gcid 0x00080000]: [sonus][ sip] <<------------------- [ sip][egressPeer] SIP/2.0 183 Session Progress Via: SIP/2.0/UDP <IP address>:5060;branch=<example> From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example> To: <sip:IP@branch IP>;tag=<address> Call-ID: <customer call ID> CSeq: <variable>INVITE RSeq: 3 Content-Type: application/sdp sdp { c=IN IP4 <sip IP address> c=IN IP4 <sip IP address> m=<media tag> a=sendrecv } 17:22:15.786568 [gcid 0x00080000]: [sonus][ sip] <<------------------- [ sip][egressPeer] PRACK <sip IP address>;transport=UDP SIP/2.0 Via: SIP/2.0/UDP <IP address>:5060;branch=<example> From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example> To: <sip:IP@branch IP>;tag=<address> Call-ID: <customer call ID> CSeq: <variable>PRACK RAck: <variable> INVITE 17:22:15.795065 [gcid 0x00080000]: [sonus][ sip] ------------------->> [ sip][egressPeer] SIP/2.0 200 OK Via: SIP/2.0/UDP <IP address>:5060;branch=<example> From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example> To: <sip:IP@branch IP>;tag=<address> Call-ID: <customer call ID> CSeq: <variable> PRACK 17:22:15.797360 [gcid 0x00080000]: [sonus][ sip] <<------------------- [ sip][egressPeer] SIP/2.0 183 Session Progress Via: SIP/2.0/UDP <IP address>:5060;branch=<example> Via: SIP/2.0/UDP <IP address>:35015;branch=<example> From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example> To: <sip:IP@branch IP>;tag=<address> Call-ID: <customer call ID> CSeq: <variable> INVITE RSeq: <variable> 17:22:15.797978 [gcid 0x00080000]: [ingressPeer][ sip] <<------------------- [ sip][sonus] PRACK <sip IP address> SIP/2.0 Via: SIP/2.0/UDP <IP address>:5060;branch=<example> From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example> To: <sip:IP@branch IP>;tag=<address> Call-ID: <customer call ID: sip IP address> CSeq: <variable> PRACK RAck: <variable> INVITE Content-Type: application/sdp 17:22:15.800737 [gcid 0x00080000]: [ingressPeer][ sip] ------------------->> [ sip][sonus] SIP/2.0 200 OK Via: SIP/2.0/UDP <IP address>:5060;branch=<example> From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example> To: <sip:IP@branch IP>;tag=<address> Call-ID: <customer call ID: sip IP address> CSeq: <variable>PRACK 17:22:15.804002 [gcid 0x00080000]: [ingressPeer][ sip] <<------------------- [ sip][sonus] UPDATE <sip IP address>;transport=UDP SIP/2.0 Via: SIP/2.0/UDP <IP address>:5060;branch=<example> From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example> To: <sip:IP@branch IP>;tag=<address> Call-ID: <customer call ID: sip IP address> CSeq: <variable>UPDATE Content-Type: application/sdp sdp { c=IN IP4 <sip IP address> m=<media type> a=sendrecv } 17:22:15.844104 [gcid 0x00080000]: [ingressPeer][ sip] <<------------------- [ sip][sonus] SIP/2.0 200 OK Via: SIP/2.0/UDP <IP address>:5060;branch=<example> From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example> To: <sip:IP@branch IP>;tag=<address> Call-ID: <customer call ID: sip IP address> CSeq: <variable>UPDATE Content-Type: application/sdp sdp { c=IN IP4 <sip IP address> m=<media type> a=sendrecv } 17:22:15.844634 [gcid 0x00080000]: [ingressPeer][ sip] ------------------->> [ sip][sonus] SIP/2.0 180 Ringing Via: SIP/2.0/UDP <IP address>:5060;branch=<example> From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example> To: <sip:IP@branch IP>;tag=<address> Call-ID: <customer call ID: sip IP address> CSeq: <variable>INVITE RSeq: <variable> 17:22:20.803253 [gcid 0x00080000]: [sonus][ sip] <<------------------- [ sip][egressPeer] PRACK <sip IP address>;transport=UDP SIP/2.0 Via: SIP/2.0/UDP <IP address>:5060;branch=<example> From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example> To: <sip:IP@branch IP>;tag=<address> Call-ID: <customer call ID: sip IP address> CSeq: <variable>PRACK RAck: <variable> INVITE 17:22:20.807563 [gcid 0x00080000]: [sonus][ sip] ------------------->> [ sip][egressPeer] SIP/2.0 200 OK Via: SIP/2.0/UDP <IP address>:5060;branch=<example> From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example> To: <sip:IP@branch IP>;tag=<address> Call-ID: <customer call ID: sip IP address> CSeq: <variable>PRACK 17:22:20.808144 [gcid 0x00080000]: [sonus][ sip] <<------------------- [ sip][egressPeer] SIP/2.0 180 Ringing Via: SIP/2.0/UDP <IP address>:5060;branch=<example> Via: SIP/2.0/UDP <IP address>:35015;branch=<example> From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example> To: <sip:IP@branch IP>;tag=<address> Call-ID: <customer call ID: sip IP address> CSeq: 1 INVITE RSeq: 279809 17:22:20.809687 [gcid 0x00080000]: [ingressPeer][ sip] <<------------------- [ sip][sonus] PRACK <sip IP address> SIP/2.0 Via: SIP/2.0/UDP <IP address>:5060;branch=<example> From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example> To: <sip:IP@branch IP>;tag=<address> Call-ID: <customer call ID: sip IP address> CSeq: <variable>PRACK RAck: <variable> INVITE Content-Type: application/sdp 17:22:20.812694 [gcid 0x00080000]: [ingressPeer][ sip] ------------------->> [ sip][sonus] SIP/2.0 200 OK Via: SIP/2.0/UDP <IP address>:5060;branch=<example> From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example> To: <sip:IP@branch IP>;tag=<address> Call-ID: <customer call ID: sip IP address> CSeq: <variable>PRACK 17:22:20.816141 [gcid 0x00080000]: [ingressPeer][ sip] <<------------------- [ sip][sonus] SIP/2.0 180 Ringing Via: SIP/2.0/UDP <IP address>:5060;branch=<example> From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example> To: <sip:IP@branch IP>;tag=<address> Call-ID: <customer call ID: sip IP address> CSeq: <variable>INVITE RSeq: <variable> 17:22:21.314820 [gcid 0x00080000]: [sonus][ sip] <<------------------- [ sip][egressPeer] PRACK <sip IP address>;transport=UDP SIP/2.0 Via: SIP/2.0/UDP <IP address>:5060;branch=<example> From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example> To: <sip:IP@branch IP>;tag=<address> Call-ID: <customer call ID: sip IP address> CSeq: <variable>PRACK RAck: <variable> INVITE 17:22:21.318799 [gcid 0x00080000]: [sonus][ sip] ------------------->> [ sip][egressPeer] SIP/2.0 200 OK Via: SIP/2.0/UDP <IP address>:5060;branch=<example> From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example> To: <sip:IP@branch IP>;tag=<address> Call-ID: <customer call ID: sip IP address> CSeq: <variable>PRACK 17:22:21.319450 [gcid 0x00080000]: [sonus][ sip] <<------------------- [ sip][egressPeer] SIP/2.0 180 Ringing Via: SIP/2.0/UDP <IP address>:5060;branch=<example> Via: SIP/2.0/UDP <IP address>:5060;branch=<example> From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example> To: <sip:IP@branch IP>;tag=<address> Call-ID: <customer call ID: sip IP address> CSeq: <variable>INVITE RSeq: <variable> 17:22:21.321235 [gcid 0x00080000]: [ingressPeer][ sip] <<------------------- [ sip][sonus] PRACK <sip IP address>:5060 SIP/2.0 Via: SIP/2.0/UDP <IP address>:5060;branch=<example> From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example> To: <sip:IP@branch IP>;tag=<address> Call-ID: <customer call ID: sip IP address> CSeq: <variable>PRACK RAck: <variable> INVITE Content-Type: application/sdp 17:22:21.324074 [gcid 0x00080000]: [ingressPeer][ sip] ------------------->> [ sip][sonus] SIP/2.0 200 OK Via: SIP/2.0/UDP <IP address>:5060;branch=<example> From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example> To: <sip:IP@branch IP>;tag=<address> Call-ID: <customer call ID: sip IP address> CSeq: <variable>PRACK 17:22:21.326579 [gcid 0x00080000]: [ingressPeer][ sip] <<------------------- [ sip][sonus] SIP/2.0 200 OK Via: SIP/2.0/UDP <IP address>:5060;branch=<example> From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example> To: <sip:IP@branch IP>;tag=<address> Call-ID: <customer call ID: sip IP address> CSeq: <variable>INVITE Content-Type: application/sdp sdp { c=IN IP4 <sip IP address> m=<media type> a=sendrecv } 17:22:25.823182 [gcid 0x00080000]: [sonus][ sip] <<------------------- [ sip][egressPeer] UPDATE <sip IP address>35015;transport=UDP SIP/2.0 Via: SIP/2.0/UDP <IP address>:5060;branch=<example> From: "OBS" <sip:+<example>@<IP address>;user=phone>;tag=<example> To: <sip:IP@branch IP>;tag=<address> Call-ID: <customer call ID: sip IP address> CSeq: <variable>UPDATE Content-Type: application/sdp sdp { c=IN IP4 <sip IP address> m=<media type> a=sendrecv }
The following severity 1 issues are resolved in this release:
The following Severity 2 and 3 issues are resolved in this release:
The following Severity 1 issues are resolved in this release:
The following Severity 2/3 issues are resolved in this release:
There are no known issues in this release.
The following issues exist in this release:
There are no known issues in this release.
The following issue exists in this release:
The following issue exists in this release:
The following issues exist in this release:
The following Severity 1 issues exist in this release:
The following Severity 2/3 issues exist in this release:
The following issues exist in this release:
The following Severity 1 issues exist in this release:
The following Severity 2, 3, and 4 issues exist in this release:
The following limitations exist in this release:
Due to a known EMA GUI issue, it can take up to 10 minutes to process each SMM rule when provisioning SMM on the SBC using the EMA. This will be fixed in a future release.
The Antitrombone feature is not supported on the D-SBC.
The VLAN tagged SRIOV packet interfaces are unable to ping endpoint Gateway IPs in the VMware platform because of an issue with VMWare.
When upgrading SBC SWe cloud instances to release 7.2, you must update your Heat template userdata section to include mandatory SSH key information. An issue in OpenStack requires that you use the stack-update process rather than re-launch after updating the template, which leads to a new UUID for the instance. As a result, you must regenerate and apply new license bundles to the upgraded instances during the upgrade.
Refer to Upgrading M-SBCs in an N:1 Redundancy Group for the relevant procedure.
The following functionalities are not supported with SBC Microservices:
Two stage calls
Network Licensing Limitations
After switchover during grace period, when the new standby SBC comes up and establishes itself as standby, there is a short period (a few minutes) when the standby is synchronized for normal operation, but the new standby has not yet completed establishing its licensing state using the grace license information. If there is a second SBC switchover during that window, the new active SBC (which became active before completing license state synchronization) will lose calls until it re-acquires the grace licenses.
For configuring Network Wide Licensing, refer to Configuring Network Wide Licensing on D-SBC. This procedure is common for D-SBC and SBC.