SBC Core 08.00.00R000 Release Notes

Table of Contents

About SBC Release Notes

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.

Related Documentation

The SBC Core 08.00.xx documentation is located at the following Wiki space: SBC Core Documentation.

Release Notes Use and Distribution

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.

Associated Ribbon Bulletins

The following Ribbon Bulletins are referenced in this release note:

• Warning-18-00028230: Call failure during LSWU when upgrading 5.x release to 6.2.1 or higher (VMWare or KVM) with 10 or more vCPUs configured.
• Warning-17-00022847: The DNS configuration parameters within the address contexts may cause certain configurations to fail during an upgrade
• Warning-17-00022689: Duplicate Trunk Group or Zone names can cause unexpected behavior
• Warning-14-00020748: Verify system and databases are fully in sync prior to Live Software Upgrade (LSWU)

• Bulletin-18-00028529: The System Security Intrusion Detection AIDE Reports False Positive Alarms

Problems or Questions

For problems or questions, contact Ribbon Support through telephone or fax: 

Worldwide Voice: 

USA Toll-free: 

Worldwide Fax: 

About SBC Core

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.

Interoperability

The SBC Core software interoperates with the following:

• SIP/H.323 compliant IADs and IP-PBXs
• PSX Policy Server Softswitch via SIP redirects and/or Diameter+ protocol
• SBC 9000 through SIP call signaling and Networks MCS protocol
• NetScore collection, analysis, monitoring, and reporting of selected Key Performance Indicators (KPIs) on a near-real time basis
  
  

H.323-SIP and SIP-H323 Calls

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.

• For CLI IPSP flag details, refer to Flags - CLI.
• For EMA IPSP flag details, refer to Common Ip Attributes - Flags.

Compatibility with Ribbon Products

Refer to SBC 5000-7000-SWe Interoperability Matrices for the latest and minimum compatible product versions supporting the 08.00.00R000 release.

Sample Heat Templates Included in This Release

To instantiate the SBC instances, the following templates can be used:

SBC SWe Cloud Requirements for OpenStack

The system hosting the SBC SWe Cloud must meet the below requirements for OpenStack:

The system hosting the SBC SWe must meet the following requirements to achieve the performance targets listed: 

OpenStack Requirements

The SBC SWe supports the following OpenStack environments:

• Newton with RHOSP 10 and RHEL 7.4
• Queens with RHOSP 13 and RHEL 7.5

SBC SWe Cloud Requirements for AWS

• The system hosting AWS requires 65GiB of disk size.
• AMI ID required to launch an instance is ami-05109212. Contact your Ribbon sales representative to get access to AMI ID.

SBC SWe Requirements for KVM

The following table lists the server hardware requirements.

SBC SWe Requirements for VMWare

The following table lists the server hardware requirements:

Required Software and Firmware Versions

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. 

How to Verify Currently Installed Software/Firmware Versions

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.

SBC Core Application Package

The SBC Application installation and upgrade package for SBC Core:

• sbc-V08.00.00R000-connexip-os_06.02.01-R000_4_amd64.qcow2
  
• sbc-V08.00.00R000-connexip-os_06.02.01-R000_4_amd64.qcow2.md5
• sbc-V08.00.00-R000.x86_64.tar.gz
• sbc-V08.00.00-R000.x86_64.md5
• sbc-V08.00.00-R000.x86_64.signature

For detailed information on installation and upgrade procedures, refer to SBC Core Software Installation and Upgrade Guide.

Cloud Service Archive (CSAR) Packages for VNFM Deployment on OpenStack

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:

• ssbc_virtio_7.2.csar
• ssbc_sriov_7.2.csar
• msbc_virtio_7.2.csar
• msbc_sriov_7.2.csar

Files required for CSAR creation: 

• createVnfmCsar.py
• vnfmSol001VnfdTemplate.yaml
• sbc-V08.00.00R000-connexip-os_06.02.01-R000_4_amd643.qcow2

For detailed information on installation and upgrade procedures, refer to SBC Core Software Installation and Upgrade Guide.

Upgrade Notes

08.00.00R000 Upgrade Information

Support of maddr Post-Upgrade

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:

• If you are using the SBC with a Broadsoft system and the SBC is configured for registration access (where the SBC sits between SIP phones and the Broadworks System). Otherwise no new REGISTER will be processed (phones will lose registration).
• If you are using the SBC with other feature servers that require maddr processing.

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:

• SIP Trunk Group - Signaling - CLI
• SIP Trunk Group - Signaling (EMA)

SBC SWe Pre-Upgrade Requirements

VM CPU resource allocation requirements

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.

Disable Call Trace feature prior to LSWU/upgrade

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.

Manually check for Hostcheck Validation Failed message

Perform the following procedure on the Standby to check for the Hostcheck Validation Failed message in the upgrade.out log.

1. Log on to ESXi of the Standby SBC SWe.
   
   
2. Check in/opt/sonus/staging/upgrade.out (this log shows the Hostcheck Validation Failed error).
   
   
3. Power off the VM.
   
   
4. Reduce the number of vCPUs assigned to VM by one and set the CPU reservation to the appropriate value.
   
   
5. Power on the VM. The SBC SWe successfully upgrades to the latest version 6.2.0. 
   
   
6. Run the command show table system serverSoftwareUpgradeStatus to confirm the successful upgrade.
   
   
7. Perform similar procedure for LSWU on Active.

Preparing for Upgrade (All Platforms)

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>

  Note

  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.

• Upgrade through Platform Manager: If upgrading using Platform Manager, simply ignore the "Wrong Signature" warning message and continue the upgrade normally.

Supported Live Software Upgrade (LSWU) Paths

The SBC Core supports Live Software Upgrade from releases listed in the table below:

New Features

New Features in 08.00.00R000 Release

43? 46 on ICD page

SBX-25924 / 32316 / 53181 / 60306 / 69021 / 69022 / 69038  MSRP Enhancements

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:

• Topology hiding or B2BUA support for MSRP sessions
• TCP connection reuse or multiplexing of MSRP sessions over a common TCP connection
• Distributed SBC support for MSRP sessions

For more information, refer to: 

SBX-39002 - Improve "clearmode" Codec Negotiation

For more information, refer to: 

SBX-44930 SBC SWe and CE Gateway Signaling Support (MCS)

For more information, refer to: 

SBX-48781 - Use postgres Database in ERE - not needed?

For more information, refer to: 

SBX-51725 / SBX-72926 Active Directory Merge from PSX To ERE / Flexible AD Support for ERE

Active Directory Support is added to the SBC. For large enterprises with a bigger subscriber base, the SBC 5K (along with PSX), provides a better solution in terms of call capacity. 

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:

• Subscriber Identity
• Display name
• Home phone number
• Mobile phone number
• Office/Lync phone number

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.

As explained above, for Flexible AD to work, the configurations are classified into two categories:

1. Configuration to Sync Data from Remote Server
2. Synced data use during call processing

For more information, refer to: 

SBX-63318 /SBX-53949 SBC Support for Multiple Syslog Server and Secure remote Syslog for TCP

For more information, refer to: 

SBX-61487 Support Debian 9

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:

• SBC Core Software Installation and Upgrade Guide

SBX-62630 / SBX-68171 tgrp and trunk-context Parameter Taken into Account Together

For more information, refer to: 

SBX-64899 and 72002 Support N:1 HA for on S-SBC and T-SBC cluster

For more information, refer to: 

SBX-67068 REG Relay After Multiple Consecutive 503 Responses

For more information, refer to: 

SBX-67075 Support One Gbps Speed on SBC 5400 Management Port

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: 

SBX-67513 Increase Number of Variables in SMM Profile

Currently, a SIP adaptor profile cannot use more than 30 variables (from var1 to var30). The number of variables supported in an SMM Profile is now increased from 30 to 100. 

For more information, refer to:

• System Provisioning - SIP Adaptor (SMM) Profile
• SIP Adaptor Profile - CLI

SBX-68167 - Remove SLS from Code and Documentation

For more information, refer to: 

SBX-68179 - SBC SWe: Support D-SBC in a VMware Environment

For more information, refer to: 

SBX-68182 Send 480 for per-peer policing discards of SUBSCRIBE

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 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:

• Internal SIP Cause Map Profile - CLI
• Internal SIP Cause Map Profile - Cause Map
• Signaling Profiles - Internal SIP Cause Map Profile - Cause Map

SBX-69356 - Session KeepAlive Retry after Switchover

For more information, refer to: 

SBX-69377 Support for Additional Media Statistics in SBC CDR - SWE

For more information, refer to: 

SBX-70370 - Support SIPRec on D-SBC on any platform including VMware, KVM, Openstack or AWS

For more information, refer to: 

SBX-70520 - Report Licensing Mode in Licensing Interval Statistics

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: 

• Show Table Global
• Global - Call Count Current Statistics
• Global - Call Count Interval Statistics

SBX-71264 - SIP Aware Front End Load Balancer

For more information, refer to: 

SBX-71271 - Cloud Provisioning OAM Model

For more information, refer to: 

SBX-71313 Rules in SMM Profile are 768

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: 

• SIP Adaptor Profile - CLI
• System Provisioning - SIP Adaptor (SMM) Profile
• SMM Rules

SBX-71398 - Overflow Route Configured in the routing label, works only for error codes mapped in Crank Back Profile

For more information, refer to: 

SBX-71489 Qualify Intel X550 based NIC Cards for SBC SWe

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:

• For KVM Hypervisor
• For VMware
• For OpenStack

SBX-72002 - Support for M+N Signaling and Media SBC VNF Relationship Model

For more information, refer to: 

SBX-72181 TCP Connection Failure Alarm in case Socket Queue Limit is Full

For more information, refer to: 

SBX-72198 Support Virt-IO with VLAN Tag on S-SBC

For more information, refer to: 

SBX-72263 - Estimation Accuracy wrt call-mix and Core Allocation

For more information, refer to: 

SBX-73382 - QCOW2 Image Replacement Upgrade Support

For more information, refer to: 

SBX-73494 Address Gaps in GPU Solution

For more information, refer to: 

SBX-73593 - SILK Codec Transcode Support on SBC SWe

For more information, refer to: 

SBX-73680 Local Survivable Mode for Calls and Registrations

For more information, refer to: 

SBX-76818 CLONE - Japan Number Portability Enhancement

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

• INVITE sip: + 81312345678;npdi;rn=+8134512345@example.ne.jp;user=phone SIP/2.0
• The rn parameter gets mapped to the called party number 
• The R-URI gets mapped to the called directory number
• The SBC generates the redirection counter parameter with the value of 1.

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:

• SIP Trunk Group - Signaling
• SIP TG - Signaling - Variant Type - CLI

SBX-85122 - NWL Licensing Documentation Update

For more information, refer to: 

(34 total but 43 with the ones paired up)

Resolved Issues

Resolved Issues in 08.00.00R000 Release 

The following issues are resolved in this release:

Known Issues

Known Issues in 08.00.00R000 Release 

The following issues exist in this release:

Known Limitations

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 Access Control List (ACL) is not installed to configure SNMP traps for accepting traffic. A dynamic ACL is added to configure SNMP traps. An ACL must be installed for SNMP traps for accepting traffic.
• The physical NIC connectivity must be in active state at the hypervisor level before starting the SWe instance on the SBC SWe platforms. In case of SWe instance with SR-IOV interfaces, manual restart of the SWe instance is required if physical NIC connectivity goes down while the instance is in progress.

• 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 Antitrombone feature is not supported on the D-SBC.
• EMS identifies the nodes based on the VNFC-ID. While instantiating SBC/PSX cloud nodes, ensure that you use a unique VNFC-ID only. If you reuse an existing VNFC-ID, EMS treats this as a re-registration request and overwrites the existing data on the cloud node.
• While configuring the SBC SWe Cloud instances, the CLIs commits successfully even if any metaVariable provided is incorrect. The SBC SWe Cloud instance cannot validate the CLIs, as the CDB configuration file is stored in the SBC Configurator and is shared among all the other SBC SWe Cloud instances in the cluster.
• Editing IP Interface is not reflected in the if configuration (ifConfig). This behavior is observed only on the S-SBC when action is set to "dryup" mode on the IP Interface. The IP address changes are not updated in the kernel and will not be displayed when ifconfig linux command is executed. In case of S-SBC, if the ipInterface configuration needs to be modified and if the action is set to "dryup" in ipInterface configuration, it must be set to "force" before disabling the ipInterface and making any changes.
• 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.
  
  

Performing Heat Stack Update when userdata is Updated with SSH Keys

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 M-SBCs in an N:1 Redundancy Group for the relevant procedure. 

Restricted Functionality with SBC

The following functionalities are not supported with SBC Microservices:

• SRTP
• Far end NAT traversal
• DTMF inter-working
• RTCP termination for pass-through calls
• Direct Media and Antitrombone
  
• NICE, SIP-REC
• Rx, Rf interfaces
• Multimedia - MSRP, BFCP  
• Fax detection
• ICE/STUN
• SIP REFER
• SIP REPLACE

• Two stage calls

• H323 support
• GW signaling support

Restricted Functionality with SBC for AWS

The following functionalities are not supported with SBC for AWS:

• The EC2 does not support VM console. The SSH must be used to access the VM.
• The smarctl disk status is not supported on Amazon instance.
• All the networking ports must be in different subnets.
• The instance creation and reboot process take approximately 4 to 6 minutes to complete.
• IP spoofing or L2 learning is not supported.
• It is required to associate an EIP on MGT0 for an HA, and the CFN template automatically assigns the EIP. This is required for communicating with AWS servers while instance switchover. The EIP switchover takes 15-20 seconds.

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.