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 08.00.xx documentation is located at the following Wiki space: SBC Core 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:
For problems or questions, contact Ribbon Support through telephone or fax:
Worldwide Voice: 1 (978) 614-8589
USA Toll-free: 1 (888) 391-3434
Worldwide Fax: 1 (978) 614-8609
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 08.00.00R000 release.
To instantiate the SBC instances, the following templates 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:
The system hosting the SBC SWe Cloud must meet the below requirements for OpenStack:
Intel Xeon processors (Nehalem micro-architecture or above) with 6 cores and above (processors should support hyper-threading). Ribbon recommends Westmere (or newer) processors for better SRTP performance. These processors have the AES-NI instruction set for performing cryptographic operations in hardware. Minimum 4 NICs. Make sure NICs have multi-queue support which enhances network performance by allowing RX and TX queues to scale with the number of CPUs on multi-processor systems. The Intel I350, x540, x550, and 82599 Ethernet adapters are supported for configuring as SR-IOV and DirectPath I/O pass-through devices. The PKT ports must be 10 Gbps SR-IOV enabled ports. 6 NICs are required to support PKT port redundancy.Configuration Requirement Processor RAM Minimum 24 GiB Hard Disk Minimum 100 GB Network Interface Cards (NICs)
The system hosting the SBC SWe must meet the following requirements to achieve the performance targets listed:
All NIC ports must come from the same NUMA node from which the M-SBC SWe instance is hosted.
The SBC SWe supports the following OpenStack environments: The SBC SWe was tested on OpenStack Queens with RHOSP 13 and RHEL 7.5.OpenStack Requirements
The following table lists the server hardware requirements. Intel Xeon processors (Nehalem micro-architecture or above) with 6 cores and above (processors should support hyper threading). Ribbon recommends using Westmere (or newer) processors for better SRTP performance. These processors have the AES-NI instruction set for performing cryptographic operations in hardware. The supported CPU Family number is 6 and CPU Model number must be newer than 26. Refer to the Intel Architecture and Processor Identification document for more information. Make sure NICs have multi-queue support which enhances network performance by allowing RX and TX queues to scale with the number of CPUs on multi-processor systems. The Intel I350, x540, x550, and 82599 Ethernet adapters are supported for configuring as SR-IOV and DirectPath I/O pass-through devices. Number of ports allowed:Configuration Requirement Processor RAM Minimum 24 GB Hard Disk Minimum 500 GB Network Interface Cards (NICs) Ports
The SBC SWe software only runs on platforms using Intel processors. Platforms using AMD processors are not supported. The following table lists the server hardware requirements: Intel Xeon processors (Nehalem micro-architecture or above) with 6 cores and above (processors should support hyper threading). Ribbon recommends using Westmere (or newer) processors for better SRTP performance. These processors have the AES-NI instruction set for performing cryptographic operations in hardware. The supported CPU Family number is 6 and CPU Model number must be newer than 26. Refer to the Intel Architecture and Processor Identification document for more information. ESXi 6.5 and later releases require approximately 2 physical cores to be set aside for hypervisor functionality. The number of VMs which can be hosted on a server must be planned for accordingly. Minimum 4 NICs, if physical NIC redundancy is not required. Make sure NICs have multi-queue support which enhances network performance by allowing RX and TX queues to scale with the number of CPUs on multi-processor systems. Intel I350, x540, x550, x710 and 82599, Mellanox Connect - 4x, and Mellanox Connect - 5x. Number of ports allowed: Configuration Requirement Processor RAM Minimum 24 GB Hard Disk Minimum 500 GB Network Interface Cards (NICs) Ports
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.19.00-R000.img
firmware-5XX0-V03.19.00-R000.img.md5
bmc5X00_v3.19.0-R0.rom.md5sum
bmc5X00_v3.19.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 1.25.0. 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.
A LSWU on an SBC 7000 should only be performed 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 8.0 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 08.00.00R000 Release Notes) is automatically removed from the system.
As an SBC Core password security enhancement, user passwords automatically expire after upgrading to 8.0.x. As a result, users are required to change their passwords upon initial login immediately following the upgrade.
Customers using network licensing mode will be converted to node locked mode (formerly legacy mode) after upgrade to the SBC 8.0.0 Release.
The SBC 8.0 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 the case of a Live Software Upgrade (LSWU) from 6.0.0R000/6.0.0R001/6.0.0F001/6.0.0F002 to 8.0, The action “Perform Pre-Upgrade Checks” from PM is not supported. Please contact Ribbon Support.
The number of rules across SMM profiles in a system is limited to 2000, and the number of actions across profiles in a system is limited to 10000.
Ensure the above conditions are met before LSWU.
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.
SWe SBC software enforces I-SBC instances to run only with a single vNUMA node in order to achieve deterministic performance. SWe SBC VM having >8 vCPUs hosted on dual-socket physical server with VMware ESXi software needs to follow the steps below to correct vNUMA topology before upgrading to latest SWe SBC software:
vsish -e get /net/pNics/<PKT port name - vmnicX>/properties | grep "NUMA"
If any of the above settings requires modification, follow the steps below on SWe SBC HA system:
numa.autosize.once = FALSE
numa.nodeAffinity’ = 0 or 1 (based on PKT port NIC affinity)
On ESXi 6.5 and above releases, vSphere web client can be used to add above rows under Edit settings > VM options > configuration parameters > add parameters;
On ESXi 6.0 and below releases, it can be added under Edit > Advanced > general > configuration parameters > add rows using vSphere client.
For more information, refer to:
Prior to performing an upgrade to release 08.00.0R000, usernames that do not conform to the new SBC user-naming rules must be removed to prevent upgrade failure. Upgrade can proceed successfully after removing all invalid usernames. 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 8.0.0R000.
Prior to performing an upgrade to the 8.0 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 Bulletins 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.
Prior to performing an upgrade to 8.0 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 Bulletins link from the menu bar. Enter the bulletin number (last eight numbers) in the search field and press Return.
If you are upgrading from any SBC version with ePSX configuration to the 08.00.00R000 release, execute the Method of Procedure, MOP to Re-configure 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 SBC Core 08.00.00R000 Release Notes.
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 Bulletins link from the menu bar. Enter the bulletin number (last eight numbers) in the search field and press Return.
The SBC 8.0 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:
The SBC Core supports Live Software Upgrade from releases listed in the table below:
The following features are part of the 08.00.00R000 Release:
In addition to supporting RFC 6714 "Connection Establishment for Media Anchoring" (CEMA) handling of Message Session Relay Protocol (MSRP) sessions, the SBC now supports the following:
For more information, refer to:
Currently, the SBC supports clearmode
data calls using existing IPSP flag clearmodeForDataCalls
. If the SBC receives clearmode
in the codec list of the request message, the SBC allows only CLEARMODE to be sent in the egress offer. This results in several failed calls with multiple codecs in request including clearmode
.
Some installations use SMM to remove clearmode
from the codec list and then allow the SBC to process it, and add CLEARMODE in the egress offer using SMM. Therefore, CLEARMODE gets retained in the offer along with other codecs.
This feature overcomes this issue, where the SBC can offer only CLEARMODE in its egress INVITE, and to treat clearmode
as any other pass-thru codec.
The SMM workaround is replaced by a native implementation on the SBX.
As part of this feature, CLEARMODE, which is a simple PCM (Pluse Code Modulation), is treated as a CODEC which is configurable in the PSX/ERE. The SBC treats it as any other codec with Intersection (no Augmentation). For bandwidth calculation, it uses the G711 configuration.
The above mentioned new treatment for CLEARMODE is controlled through a NEW IPSP flag to maintain backward compatibility with the existing CLEARMODE flag.
For more information, refer to:
Large deployments of GSX/SBC9000 and SBC 5000 series/5400/7000 support MCS gateway signaling and the PSX routing designs, the billing systems, and the back office provisioning systems uses the flat routing model that is possible with MCS gateway signaling.
The SBC SWe and SBC SWe Cloud also support the Multimedia Conferencing System (MCS) gateway signaling between the other SBC products and the GSX/SBC9000 when using an external PSX. The MCS gateway signaling adds value to the SBC SWe in large cloud deployments. Implementing this feature saves effort in re-engineering the PSX database, billing collection systems, and automated routing systems.
In addition to FQDN, MCS signaling on the SBC SWe supports IP address configurations. When the DNS solution is not available, the SBC allows the user to configure static IP addresses in a centralized location such as Master PSX for the MCS signaling endpoints. The IP is used with 1:1 signaling SBC clusters such that, the cluster only has one MCS IP address.
The SBC supports the vast hardware-based GSX/SBC9000 system networks containing auto-scaling architectures using MCS signaling. Because auto-scaling requires the use of DNS resolution, the resolution is made at the PSX, and the IPs returned as part of the Diameter+ response.
MCS gateway signaling supports the following:
SBC uses the MCS gateway signaling for communications between:
For more information, refer to:
The SBC Core is enhanced to support Flexible Active Directory functionality for large enterprises with a bigger subscriber base to provide a better call capacity solution.
In Enterprise deployments, ERE is required to retrieve the User information from the Microsoft Active directory database and use it for call routing and policy decisions. This reduces the administrative overhead of provisioning and managing the user information at two places. The ERE will retrieve the Subscriber information by querying the Active Directory database, which includes:
Since LDAP is a known slow response protocol, the SBC fetches the data from the remote server and stores it in the local database instead of querying real time to the remote server. This data is later used during calls to manipulate various call parameters and use them in routing logic.
For more information, refer to:
Security analytics is dependent on centralized Syslog aggregation, with the expectation that the Syslog communication is secured. The primary Syslog security threats to address are:
To eliminate these threats, RFC 5425 defines a TLS Transport Mapping for Syslog. This feature supports the RFC 5425-compliant transport option in addition to the existing UDP, TCP, and RELP Syslog remote protocols.
The SBC is enhanced to:
The SBC supports the Rsyslog method of sending event messages to the Syslog server with the following capabilities:
/var/log/
files to transfer over Syslog. It captures the Linux session console logs and transfers it through the Syslog. /var/log/session/session.*
files and pushes it to the Syslog Server.For more information, refer to:
The SBC is migrated to the latest supported version of Debian. This is needed to ensure that there is sufficient runway on Debian community upgrades to meet support requirements, especially in the context of security patches.
For more information, refer to:
Trunk Groups are identified by two parameters: tgrp and trunk-context
The trunk-context
establishes the scope of the trunk group specified in the tgrp
parameter and determines if it is for a single gateway, a set of gateways, or an entire domain managed by the service provider.
The value in the trunk-context
identifies a gateway.
When the remote party sends the invite with both tgrp =
egress_tg, trunk_context
= Egress IP / Egress IP + Port / FQDN
, the SBC chooses the egress trunk group based on the tgrp
parameter in the Request-URI (R-URI). The SBC uses the trunk-context as destination, if there is no IP Peer or IP Signaling Peer Group is not configured.
The SBC does not provision the IP peer when the remote IP address is already provisioned in some other system and the user does not want duplicate provisioning, or when the user does not know the remote IP address.
For more information, refer to:
The Signaling SBC (S-SBC) and Media SBC (M-SBC) support N:1 Redundancy, where N is based on the HA port capacity, call load and performance requirements. For release 8.0, N=4.
HA bandwidth is upgraded from 1 Gbps to 10 Gbps.
For more information, refer to:
The SBC is enhanced to preserve the RCB on receiving error responses (4xx/5xx/6xx, except 401, 407, 408, and 7xx) for the Refresh REGISTER, and relays the same error response locally to the UE. As the RCB state is COMPLETED, the SBC relays subsequent Refresh REGISTER messages towards the Registrar. Also, the SBC deletes the RCB when the last negotiated/active time expires.
A new parameter preserveRcbOnRefreshRegErrResponse
is introduced to the signaling
registration
object, to toggle preservation of the RCB on receiving error response (4xx/5xx/6xx) for Refresh Registration. This parameter helps to retain backward compatibility by controlling the behavior.
For more information, refer to:
The SBC 5400 firmware/software is enhanced in this release to add support for 1 Gbps speeds to the management ports (in addition to the existing 100 Mbps support), including the support of half or full duplex with auto-negotiation on all four management ports. Each management port auto-negotiates the speed/mode independently from other management ports.
Additionally, the SBC Core is enhanced to display the negotiated management port speed and current bandwidth for all management ports from the CLI/EMA.
Since this enhancement allows 1 Gbps traffic bandwidth for all management ports, it increases the possibility of a traffic overload condition due to the increased bandwidth of the combined management, media and signaling traffic. To address this, the SBC sets the management traffic as the lowest priority. Thus, the system drops the management packets, as necessary, to avoid impacting media or signaling traffic.
For more information, refer to:
The number of variables supported in an SMM Profile is now increased from 30 to 100. (From var1 to var30 to var1 to var100).
For more information, refer to:
Beginning with release 8.0, the concepts of a site license server (SLS), network license mode, and local license mode are fully obsolete and removed from documentation and user interfaces. This includes EMA and CLI configuration options, alarms, and related statistics. In addition, the term "legacy," in reference to the SBC licensing mode in which a license bundle is associated with a specific hardware serial number or UUID, is replaced with the more descriptive term: "node locked."
For more information, refer to:
Prior to SBC 8.0, the SBC supported the tgrp/trunk-context
functionality in R-URI for INVITE only. The SBC now supports the tgrp/trunk-context
functionality in R-URI for NON-INVITE messages (same as DTG).
The light dip principle instructs the Diameter+ PSX to skip most of the services and return a single route for the specified trunk group. This is useful for networks where an upstream SIP device (for example, the PSX Proxy which anchors the SIP session) performs crank back / route advance and sends the profile.
For more information, refer to:
The SBC is enhanced to use the configured Internal SIP Cause Map Profile attached to the Trunk Group to send an error response when the SUBSCRIBE rate control is reached based on configured CAC profile on Trunk Group/(static) IpPeer.
The SBC also uses the configured cause string in the Internal SIP Cause Map Profile attached to the Trunk Group to send cause text in the Reason header when rejecting the SUBSCRIBE message due to Ingress endpoint CAC (Trunk Group/IpPeer).
For this feature, a SUBSCRIBE rate control that sends a 480 (temporarily unavailable) response on per-peer policing is added to the SBC.
The SBC uses the existing sipInternalCauseCode
profile to send the custom SIP response code, subsEndPointRatePolicing
, which is added under the causeMap
parameter. An optional custom cause string for this particular use of a 480 response can be sent in the reason header of the SIP error response, by using the sipCauseText
configuration. An example of the optional cause string is "subscription rate limiting". sipCauseText
is configurable and is highly desirable for troubleshooting.
This feature is only for out-of-dialog SUBSCRIBE messages, not in-dialog SUBSCRIBE messages. The SBC will reject inbound Subscription requests from a given peer, based on an ingress rate control set on the peer's interface.
For more information, refer to:
After the switchover, some calls are dropped due to session refresh. The SBC sends out a session refresh to the old TCP connection in order to keepalive the message for 60 seconds. This keepalive also creates a new TCP connection between the SBC and the EP. If the SBC performs a session refresh before it receives a keepalive message from the EP, the call is dropped due to stack timeout.
The SBC sends out session refresh randomly after switchover. The minimum value is currently 15 seconds. A new timer, sipSwitchoverKeepAliveDelay
, provides the user with an option to have any configurable value in the range provided, ensuring that the SBC does not send out a session refresh before spending the EP's keepalive of 60 seconds.
For more information, refer to:
The SWe and SWe Cloud flavors (I-SBC on OpenStack) of the SBC are enhanced to support additional media statistics in the CDR.
With this enhancement, all the additional media statistics originally introduced in the 7.1 feature “SBX-65788 SBC shall populate additional media stats in CDR - 5K/7K support” are now supported on SWe Cloud (I-SBC on OpenStack).
For more information, refer to:
Session recording is a capability which can be utilized for various purposes: to comply with regulation, to monitor quality of service of representatives, and to store call information for quality analysis. Ribbon I-SBC currently supports recording interfaces like Legacy LI, IMS LI, ComCast LI, and SIPREC which are not being supported on D-SBC. Release 8.0 adds support for SIPREC on D-SBC for passthru calls as in I-SBC. The SDP and metadata sent to the SRS reflect the correct Codec in which the media is sent. In the INVITE towards the SRS server, only m line with audio is supported. D-SBC also supports multiple commands for initiating recording towards different SRS and QUAD siprec as in I-SBC.
In addition to providing the peak number of instances for different types of calls, the global Call Count Current Statistics and Call Count Interval Statistics tables now identify the license mode of the SBC from which the statistics were retrieved. The possible values are Node Locked (nodeLocked) and Domain (domain). Node Locked refers to the most common form of licensing in which a license is bound to a specific SBC node through its serial number (hardware-based SBC) or its universally unique identifier (VM-based SBC SWe systems). Domain refers to network-wide domain licensing (NWDL) in which a license is associated with a domain. NWDL is supported on some large-scale distributed SBC or cloud-based systems.
For more information, refer to:
With the wide adoption of cloud and virtualization technologies (NFV), the physical network functions (PNF) become virtual network functions (VNF) running on virtualized infrastructure manager (VIM) (like Openstack), Ribbon has virtualized SBC, PSX and EMS (among other products) that has already been deployed in Tier 1 environments. While NFV adoption will ultimately result in Capex/Opex reduction for operators, this also throws some challenges.
To address these concerns, a SIP-aware front-end load-balancer (SLB) is available for SBC and PSX. SLB as a front-end means that a single IP address is exposed towards peer operators. SLB in turn distributes the traffic among back-end call-processing VMs. Ultimately, SLB has its own capacity limits and deployments need to make use of DNS, should the traffic requirements demand more than one SLB instance (SLB is in HA mode and hence it is actually more than one HA pair). However, as long as a single SLB (HA pair) addresses the traffic equivalent to a single site traffic (and hence that equivalent number of back-end call-processing VMs), there is no need to return to using DNS for SLB. Instead, if the traffic goes beyond what a SLB can handle, the solution is to create a new SLB with a new IP and expose that to the peer.
In prior releases, a designated “Headend” SBC was used to configure SBC SWe clusters. In SBC release 8.0, the OAM node and Direct Single configuration models replace the Headend model.
The OAM node configuration model incorporates a 1:1 HA pair of dedicated Operations, Administration, and Maintenance (OAM) nodes to configure and manage SBC nodes in N:1 distributed deployments. The OAM node provides the northbound interface for the VNF, including SSH/CLI, NetConf, and REST interfaces. You use the OAM node interfaces to configure the cluster and it is responsible for disseminating the cluster configuration to the SBC nodes within the cluster. Although the nodes register with the EMS, the SBC nodes within the VNF get their configuration updates only from the OAM node.
The Direct Single configuration model applies to deployments in which there is a single active SBC node, such as standalone or 1:1 HA deployments. For this smaller type of deployment, the SBC node itself provides the northbound interfaces for the VNF while the EMS continues to provide a repository to store the configuration history. In the case of a 1:1 HA deployment, the active node replicates configuration changes to the backup node.
For both models, the EMS continues to provide cluster management including a storage repository for cluster configurations. To enable migration, Insight EMS 12.0 continues to support the Headend configuration model for SBC clusters on prior releases. However, SBC clusters on release 8.0 must use either the OAM node or Direct Single configuration model.
For more information, refer to:
The SBC is enhanced to support up to 768 rules in an SMM profile. The rules are applied sequentially to the messages.
For more information, refer to:
Overflow routing (which is last-means) now works for error codes not mapped in the Crankback profile. Previously, when an overflow number was configured, the overflow route worked only for error codes mapped in the Crankback profile. An additional action is available so that the SBC will directly attempt the last route (which would be the overflow route).
You must configure the routing label so it points to all regular routes + overflow route as "last route" in the routing label.
For more information, refer to:
x550 based NIC cards are qualified. They are supported on KVM (SR-IOV) and VMware (SR-IOV and Direct I/O).
For more information, refer to:
Some deployments use a single S-SBC VNF tied to a single M-SBC VNF. Each VNF contains one Redundancy group.
The SBC is enhanced to expand the S-SBC redundancy model from 1+1 to N+1. This allows the SBC to:
The "VLAN-aware" guests capability has been validated on the SBC with the OpenStack Queens release.
As part of the released software package, Ribbon offers a template file heatRgActiveVlanProviderNetworkNoDhcpTemplate.yaml
, which acts as a boilerplate heat template for Virt-IO with OVS and VLAN tags. The enhancement is unavailable for VNFM based deployments.
The enhancement is unavailable for VNFM based deployments.
For more information, refer to:
Currently, estimation is based on call-mix for all profiles. Estimation is enhanced by re-calculating the estimation based on final core partitioning. This applies to all standard and custom profiles. New parameters (Max Passthrough Sessions and Max Crypto Sessions) have been added to the sweCapacityEstimate table.
For more information, refer to:
The SBC SWe is enhanced with a command-line tool kvmInstall.py
contained within a tarball kvmInstall-1.0.0.tar.gz
, which is available as part of the released software bundle. The tool significantly improves the workflow for the installation and upgrade of SBC SWe on KVM for QCOW2
based deployments, especially when an LSWU is performed.
For more information, refer to:
Prior to SBC 8.0 release, for GPU-based solutions, the SBC could not offer more than one transcodable codec in the outgoing offer for following reasons:
The SBC is enhanced to offer all the configured transcodable codecs that the SBC supports, in the outgoing offer and address the above GPU gaps.
The configured codecs include:
For more information, refer to:
The SBC currently provides pass-through support for the SILK codec in narrowband (NB), mediumband (MB), wideband (WB), and super-wideband (SWB) formats. It will now also support transcoding for the NB and WB SILK codec variants. SILK transcoding support applied to SBC 5110, 5210, 5400 and 7000 platforms, and is now available in SWe.
In the event of loss of connection with the Application Server (AS), the SBC switches to Local Survivable Mode and handles the call processing with limited functionality. It provides local registration support and limited local calling capabilities. The feature uses the Address Reachability Service (ARS) functionality to detect and blacklist the AS. The ARS is enhanced to support per request type blacklisting on 503 retry-after response for the following SIP requests:
For more information, refer to:
The existing control variantType
is used, with the value being set to ttc.
However, the parts of the JJ90.30 specification that ttc actually supports are as follows:
When this control is set to TTC the SBC supports the following interworking mapping:
For SIP to ISUP
For ISUP to SIP
If the called directory number parameter is present then it gets mapped into the R-URI, and the called party number is mapped into the rn parameter and the npdi parameter is included.
For more information, refer to:
The following issues are resolved in this release:
The following 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 HA interface must not be configured with link localaddress or subnet. For example, do not configure it with 169.254.0.0/16 subnet.
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 8.0, 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 SBCs in an N:1 Redundancy Group for the relevant procedure.
The following functionalities are not supported with SBC Microservices:
Two stage calls