Table of Contents

About SBC Release Notes

The RN PN: 550-08477 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.01.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 Announcements

The following Ribbon announcements (formerly known as WBAs) 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). Applies to SBC 5100, SBC 5110, SBC 5200, and SBC 5210 only.

• 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: 1 (978) 614-8589

USA Toll-free: 1 (888) 391-3434

Worldwide Fax: 1 (978) 614-8609

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.02.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 Requirements for KVM

The following table lists the server hardware requirements.

SBC SWe Requirements for VMWare

The following table lists the server hardware requirements:

Requirements for Using the Infrastructure as Code Environment with SBC SWe

The following tarball file is required to use the IaC environment to deploy SWe N:1 deployments on VMware:

•  iac-1.1-20190808-060356.tar.gz

The environment in which you place and expand the IaC tarball must include:

• A Linux server running RedHat Enterprise Linux (RHEL), CentOS 7 or Debian 9
• Python 2.7 or later
• An internet connection for downloading and installing additional files that may be required for your deployment
• Root access on the instance or ability to become root (for example, using sudo su -)
• Access to the vSphere ESXi host IP from the Linux server where the IaC environment is set up.

For more information on IaC, refer to  Using the Ribbon IaC Environment to Deploy SBC SWe on VMware.

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.

Software Bundles

The following software release bundle is available for download from the Customer Portal:

• SBC5x7x_8.1

Download the appropriate software packages for your desired configuration from the Customer Portal (https://ribboncommunications.com/services/ribbon-support-portal-login) to your PC:

SBC 5000 Series (51x0/52x0) Firmware

• firmware-5XX0-V03.20.00-R000.img

• firmware-5XX0-V03.20.00-R000.img.md5

• bmc5X00_v3.20.0-R0.rom.md5sum

• bmc5X00_v3.20.0-R0.rom

SBC 5400 Firmware

• firmware-5400-V03.20.00-R000.img
• firmware-5400-V03.20.00-R000.img.md5

SBC 7000 Series Firmware

• firmware-7X00-V03.20.00-R000.img
• firmware-7X00-V03.20.00-R000.img.md5
  
  

SBC Core Operating System Installation Package

The ConnexIP Operating System installation package for SBC Core:

• sbc-V08.02.00R000-connexip-os_07.01.01-R000_9_amd64.iso
• sbc-V08.02.00R000-connexip-os_07.01.01-R000_9_amd64.iso.md5
  
  

SBC Core Application Package

The SBC Application installation and upgrade package for SBC Core:

• sbc-V08.02.00R000-connexip-os_07.01.01-R000_9_amd64.qcow2
• sbc-V08.02.00R000-connexip-os_07.01.01-R000_9_amd64.qcow2.md5
• sbc-V08.01.00-R000.x86_64.tar.gz
• sbc-V08.01.00-R000.x86_64.md5
• sbc-V08.01.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. There is a procedure for producing the required CSAR variant, for different personalities (S-SBC, M-SBC), different interface types (virtio, sriov).

Files required for CSAR creation: 

• createVnfmCsar.py
• vnfmSol001VnfdTemplate.yaml
• sbc-V08.02.00R000-connexip-os_07.01.01-R000_9_amd64.qcow2

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

For details on CSAR creation, refer to Creating a CSAR Package File. 

Upgrade Notes

08.02.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 in Release 08.02.00R000

SBX-3xxx

SBX-5xxxx

SBX-50090 SIP Priority Call Handling for GETS

This feature enhances the Government Emergency Telecommunications Service (GETS) functionality for the SBC. The following summarize the enhancements to the GETS feature:

Criteria to detect GETS calls.

• Handling of error or unexpected cases.
• CAC enhancements for GETS.
• Logging improvement for GETS.
• Call queuing support.
• Differentiated Services Code Point (DSCP) marking and priority treatment for GETS call packets.

The following features are covered in the SIP Priority Call Handling for GETS Feature:

• SBX-56529
• SBX-63719

For more information, refer to the following pages: 

SBX-50523 SIP Call Queuing for GETS

Calls are usually assigned to an idle resource (trunk or IP bandwidth) in a trunk group. If no resource is found in the trunk group and the call is recognized as an HPC call, the SBC queues the call till the required resource is available.

The SBC Core is enhanced to allow configurable queuing of HPC calls.

Note: The SBC performs HPC Call Queuing only if the TG CAC and HPC Oversubscription measures are already full.

Note: For an HA pair, the queued HPC calls are released during a switchover; only stable calls are synced to the standby SBC.

SBX-50524 Prioritize GETS-related Ingress Packets Based on Provisioned DSCP

A new profile for Differentiated Services Code Point (DSCP) is introduced to associate it with any interface. The DSCP profile contains DSCP values of HPC and non-HPC calls.

With this enhancement, the SBC preserves the received DSCP value in the initial Invite, and performs DSCP marking based on the HPC profile configuration.

Prior to the enhancement, DSCP configurations for SIP signaling were present in the HPC profile, and the SIP Signaling port (non-HPC).

SBX-52425 Supporting CPC to SIP Mappings for Trunk Groups in SBC Default Signaling Zone

This feature updates the SBC to support SIP Cause Code Mapping for CPC to SIP for trunk groups regardless of the signaling zone.

The PSX sends the SIP_USED_IN_CORE flag with the policy response to the egress SBC. If the egress SBC receives the SIP_USED_IN_CORE flag and the ingress zone of the egress SBC is in the default signaling zone, the egress SBC does not allow SIP Cause Code Mapping for CPC to SIP because the scenario is SIP In Core. If the PSX either is not present or does not enable the SIP_IN_CORE flag, then SIP Cause Code Mapping for CPC to SIP functions as if the SBC uses a non-default signaling zone.

For more information, refer to:

• Configuring SIP Cause Code Mapping
• SIP Cause Code Mapping - CPC To SIP Cause Map Profile
• CPC to SIP Cause Map Profile - CLI
• SIP Profiles

SBX-53120 Redesign Backup/Restore Screen

The Backup/Restore EMA screens are updated for this release.

For more information, refer to the following section:

• System Administration - Backup and Restore

SBX-53178 D-SBC: Support Legacy LI, IMS LI and P-DCS-LAES LI

Note: This feature is applicable only for CALEA users.

The SBC Core is enhanced to support all LI varieties (Default LI, IMS LI, and PSCI LI), when deployed as D-SBC (S-SBC and M-SBC) on cloud platforms.

With this enhancement, all LI varieties supported by the SBC are available across the following platforms:

• Hardware: SBC 5000 series, SBC 5400, and SBC 7000
• SWe/Cloud: I-SBC and D-SBC (S-SBC and M-SBC) on KVM and Openstack

Prior to this enhancement, only PSCI LI was supported on D-SBC.

For more information, refer to the following pages:

• Lawful Intercept
• Lawful Intercept Support on SBC SWe Cloud
• Configuring the SBC for Lawful Interception

SBX-53179 D-SBC: Support for Multi-party scenarios - REFER, REPLACE

The D-SBC is enhanced to support REFER (without replaces) in relay and local processing mode for audio pass-through calls.

For more information, refer to the following pages:

• Call Transfers
• Relay Flags - CLI
• SBC SIP Transparency Implementation Guide

SBX-6xxxx

SBX-66686 Support for LI integration with Siemens LiOS Delivery Function

The interface between PSX and the SBC is enhanced for the PSX to send, and the SBC to receive, the TAP ID. Use the EMS to perform the relevant configurations.

The TAP ID, or Lawful Intercept ID, is a decimal value between 1 and 4,294,967,295 (4 bytes). The default value of TAP ID is 0.

If the SBC receives a non-zero TAP ID from the PSX, it embeds the value in the Correlation ID (CCID) and sends the TAP ID as a separate Tag Length Value (TLV) in the Direct Signaling Report (DSR) message.

If the SBC receives the value 0 as TAP ID, it does not take any action.

For more information, refer to the following page:

• PCSI LI Support

SBX-66742 Custom User Groups on SBC

The SBC includes several default groups (such as Administrator, Operator, Field Service, Guest, Calea and Security Auditor) that use various levels of access to CDB data, and to CLI and NETCONF commands. Group permissions are based on the defined AAA rules which are not user-editable. As a result, there is little flexibility to create user-defined groups with permissions for the pre-defined groups. Additionally, users belonging to the custom group can only login to the CLI, but not the EMA.

The SBC is enhanced to create user-defined groups with flexibility to modify the AAA rules. New functionality includes:

• Providing custom group users access to both the CLI and EMA.
• Flexibility to modify the AAA rules to the newly created custom group.

For more information, refer to:

• User Roles and Responsibilities
• Managing SBC Core Users and Accounts
• Creating Custom Groups and Rules

 SBX-66765 Support for IPsec for Media with UDP Transport for LI

The SBC 5xx0, 5400 and 7000 systems are enhanced to add IPsec encryption for media packets directly inside the network processor. The enhancement also includes support for IPSec over UDP for X3 packets.

 Prior to this enhancement:

• IPsec encryption for media packets was not supported directly inside the SBC
• IPSec for LI with media was supported only over TCP

 For more information, refer to the following pages:

• Securing SBC Core Services in the Customer Network
• IPsec for Signaling
• Configuring SBC for IPsec IKEv1

SBX-67793 Call Established Time on CDR

Unlike some systems which includes the CDR Established Time field in the CDR, the SBC calculates the CDR Established Time value using the CDR fields.

The SBC calculates the Call Established Time using the following fields stored in the CDR records:

• Start Time (Date) of the call from field number 6
• Start Time (Time) of the call from field number 7
• Ticks from Setup Msg to Service Est from field number 10 in START and STOP Records and INTERMEDIATE records from filed number 9

For more information, refer to:

• Billing Introduction
• CAM Changes in This Release
• CDR Examples
• CDR Field Descriptions
• Troubleshooting Tools - CDR Viewer

SBX-68147 Redesign Routing Label, Routing Label Route, and Route Screen Using Angular

This feature updates the EMA Routing screen. The Routing screen replaces the Toolkit workspace panel with buttons, and other selection options, in the Routing Labels + Routing Label Routes and Routes tabs. This feature also updates the configuration panels in these tabs to improve usability.

For more information, refer to:

• Basic Call Flow Using ERE
• Call Routing: System Provisioning - Routing
• Frequently Asked Questions

SBX-7xxxx

SBX-70399 Non-INVITE 3xx Handling with Contact That has TGRP/Trunk-context and Embedded Route Headers

This feature updates the SBC to handle a 3xx response to the non-INVITE OOD SIP messages with a Contact header that has the tgrp and trunk-context parameters in the embedded Route header.

For more information, refer to:

• Embedded Headers Support in 3xx Contact Headers
  
  

SBX-70429 IMS LI: Buffering DSR Messages when Mediation Server Connection is Down

The SBC allows configuration of a maximum of 16 mediation servers for IMS LI in the Call Data Channel (CDC). When a call is tapped, the SBC selects among the Delivery Function 2 (DF2) servers in a round-robin manner, and establishes persistent TCP connections with all configured mediation servers. Prior to the enhancement, only one mediation server was supported.

Each mediation server object contains the Signaling(X2) and Media (X3) IP addresses. The SBC allows configuration of multiple mediation servers with the same X2 IP address but a different X3 IP address.

For IMS LI, the SBC does not support any Active-Standby configuration for the X2 servers. It assumes that the DF2 servers are running in Active-Active mode, and in case of a failure, moves the IP address of the active DF2 server to the standby DF2 server.

The X2 and X3 servers operate independently. Even if the X2 servers are not reachable, the SBC sends X3 media if DF3 servers are available, and vice versa.

The parameter dsrProtocolVersion is added to callDataChannel, and the groupTwoThousand is added as a vendorId.

Two alarms, sonusSbxImMediationServerX2MsgBufferFull and sonusSbxImMediationServerX2MsgBufferAvailable, are introduced to indicate the status of the DSR buffer. The alarms are raised depending on whether the DSR buffer is full, or available.

For more information, refer to the following pages:

• Intercept - CLI
• Show Status Address Context - Intercept
• Intercept - Call Data Channel
• Call Data Channel - Mediation Server
• Call Data Channel - Mediation Server Media Status
• Call Data Channel - Mediation Server Signaling Status
• sonusSbxImMediationServerX2MsgBufferFull - MAJOR
• sonusSbxImMediationServerX2MsgBufferAvailable - MAJOR

SBX-70525 Support BFD for Link Detection

The SBC uses Bidirectional Forwarding Detection (BFD) in remote end points and routers to continuously monitor the link availability of the SBC. If the BFD session is down, the router declares the link as down and the upper layer application protocol performs the appropriate actions (such as, not sending control packets).

The SBC supports the BFD asynchronous mode. In the asynchronous mode, the detection time decides the failure of the BFD session.

The ipInterface configuration adds the bfd parameter and its associated parameters.

For more information, refer to:

• Supported Standards
• Bidirectional Forwarding Detection
• IP Interface Group - IP Interface - Bfd or IP Interface - Bfd
• IP Interface Group - IP Interface - Bfd Status or IP Interface - Bfd Status
• IP Interface Group - CLI
• CLI Changes in This Release
  
  

SBX-70668 Capability to Support OCSP Stapling on SBX

The SBC supports Online Certificate Status Protocol (OCSP) stapling (refer to RFC 6961). OCSP stapling allows you to provide the validity information of your security certificate. With OCSP stapling, the client (the ingress peer that initiates the call to the SBC) does not need to query the OCSP responder to retrieve the certificate status.

Note: OSCP stapling supports the following interworking scenarios:

The security configuration adds the ocspStapling flag and ocspResponseCachingTimer parameter in the ocspProfile.

For more information, refer to:

• Supported Standards
• Security Configuration - Ocsp Profile
• OCSP Profile - CLI
• Show Table Profiles
• Show Table Profiles - Security
• CLI Changes in This Release
• SIP Profiles

SBX-71768 CALEA X3 Support For All Media Types With SS8

SBX-71836 GW Protocol Support for Message Bodies Including PIDF-XML

In earlier releases, the message body is not sent transparently to the other gateway when the following conditions applied:

• The SBC is the first gateway
• Any of the recently known message bodies comes in the INVITE request
• The transparency flag (either IPSP or HTP) is enabled

The SBC is enhanced so that:

• The second gateway can be either an SBC or GSX
• A generic approach is used for achieving transparency of recently known message bodies over GW-GW

SBX-71966 Call Trace to Capture SIPREC Legs

The SBC Core is enhanced with the capability to trace SIPREC legs to assist in debugging various issues associated with SIPREC legs, such as:

• Missing media packets
• Missing Signalling packets towards SIP Recording Server (SRS) in debug (.DBG) logs
• Crank back issues in QUAD SIPREC

As part of the enhancement, the flag sipRecLegsCapture is introduced under the callFilter parameter of the global callTrace object.

When the main call is traced and SIPREC is invoked based on a matching criteria, if the flag sipRecLegsCapture is set to enable:

• For single and DUAL SIPREC calls:
  • The media packets of the main call's leg (non-SIPREC side) and the SIPREC legs are logged in .PKT file.
  • The .TRC file contains SIP Protocol Data Units (PDUs) for SIPREC calls, as well as tracing data of the main call (depending on the level of the trace).
• For QUAD SIPREC calls:
  • Packets are not captured for the main call and the .PKT files do not have the media of the main call. However, media packets of the SIPREC legs are logged in the .PKT files.
  • The .TRC file contains SIP PDUs for SIPREC calls, as well as tracing data of the main call (depending on the level of the trace).

For more information, refer to the following pages:

• Call Trace - CLI
• Call Trace and Packet Capture - Call Trace

The SBC supports relay of "Application TCP/UDP" streams established using a SIP session.

New application bandwidth is introduced to allocate bandwidth from the media bandwidth pool. Before this feature, the application TCP/BFCP was supported only with video stream. This feature supports the application TCP/BFCP stream independent of video stream. 

This feature provides D-SBC with support to relay application streams established using SIP session with TCP, TCP/BFCP, TCP/* and UDP protocols.

For more information, refer to:

• Media - Packet Service Profile - QOS Values
• Packet Service Profile - CLI

SBX-73526 EMA Live Monitor Support for EVS Transcoding

The EMA Live Monitor capability now supports reporting on EVS transcoding. In the License Service Usage graph, for a customer configurable duration, EMA can display the number of licensed EVS transcoding sessions and the usage level.

For more information, refer to:

• Home - Live Monitor

SBX-73700 IMS LI Server Load Sharing

The SBC allows configuration of a maximum of 16 mediation servers for IMS LI in the Call Data Channel (CDC). When a call is tapped, the SBC selects among the Delivery Function 2 (DF2) servers in a round-robin manner, and establishes persistent TCP connections with all configured mediation servers. Prior to the enhancement, only one mediation server was supported.

Each mediation server object contains the Signaling(X2) and Media (X3) IP addresses. The SBC allows configuration of multiple mediation servers with the same X2 IP address but a different X3 IP address.

For IMS LI, the SBC does not support any Active-Standby configuration for the X2 servers. It assumes that the DF2 servers are running in Active-Active mode, and in case of a failure, moves the IP address of the active DF2 server to the standby DF2 server.

The X2 and X3 servers operate independently. Even if the X2 servers are not reachable, the SBC sends X3 media if DF3 servers are available, and vice versa.

The parameter dsrProtocolVersion is added to callDataChannel, and the groupTwoThousand is added as a vendorId.

For more information, refer to the following pages:

• Intercept - CLI
• Show Status Address Context - Intercept
• Intercept - Call Data Channel
• Call Data Channel - Mediation Server
• Call Data Channel - Mediation Server Media Status
• Call Data Channel - Mediation Server Signaling Status

SBX-74192 - SWe-Estimation Framework Support - 2.0

SBC SWe traffic profiles are used to characterize the call mix that operators expect to occur on their SBC SWe systems. SBC SWe systems can then enhance their VM performance by allocating CPU cores in a manner that maximizes capacity for the call mix specified in the active traffic profile. SBC SWe traffic profiles now include four additional parameters to better characterize the call mix of an SBC SWe system:

• sigCostFactor
• mediaCostFactor
• txPPSFactor
• rxPPSFactor

These profile parameters enable two additional attributes to appear in SWe capacity estimation output:

• Estimated TX PPS
• Estimated RX PPS

For more information, refer to:

• SWe Traffic Profiles - CLI
• Show Table System
• System - SWe Traffic Profiles
• System - SWe Capacity Estimate

SBX-76034 Support for CPU+GPU Hybrid Transcoding Instances

The term "Hybrid Transcoding" implies leveraging both CPU and GPU resources efficiently to accommodate a given codec combination for transcoding capability. With Hybrid Transcoding, a suitable VM instance (SBC SWe on KVM/Openstack) utilizes all the CPU and GPU resources allocated to it for provisioning a given transcode call mix scenario.

Prior to Hybrid Transcoding, the SBC supported either a pure CPU transcoding solution, or a pure GPU transcoding solution. However, in the pure GPU solution, many CPUs are left unused. For example, when a 32 vCPU, GPU-ISBC instance is used to provision just AMRWB-G711u calls, only 13 vCPUs are used, although such an instance can handle 7680 sessions for AMRWB-G711u transcoding. With Hybrid Transcoding, the remaining 19 vCPUs (32-13 vCPUs) are used for provisioning additional AMRWB-G711 sessions.

Hybrid Transcoding enables a GPU-SBC to support GPU codecs as well as non-GPU-supported codec in the same instance. For example, AMRWB-G711 and G726-G711 codecs are supported in the same instance. 

Hybrid Transcoding is supported in Custom GPU and Standard GPU traffic profiles.

For more information, refer to the following pages:

• Distributed SBC Architecture
• KVM Performance Tuning
• Configuring SBC SWe Cloud for GPU Transcoding
• SWe Traffic Profiles - CLI
• SWe Active Profile - CLI
• SWe Codec Mix Profile - CLI
• Activating Callmix Profile on SBC SWe
• System - CPU Transcode Status
• System - Gpu Transcode Status
• Configuring SBC SWe Cloud for GPU Transcoding
• System - SWe Traffic Profiles

The SBC is enhanced to send a response code for any internal errors or failures encountered by defining a new error string in an existing profile that consists of mapping of error strings to SIP response codes. The SBC defines a unique error string for each location in the code from where the error originates. The SBC then maps the error string to the configurable SIP response code using the existing profile.

Prior to SBC Core version 8.1, if a trunk group was in Out-of-Service state and the SBC received the INVITE message on that trunk group, it rejected the INVITE message with a fixed error code. 

For more information, refer to: 

• Configuring SIP Cause Code Mapping
• Internal SIP Cause Map Profile - CLI
• Internal SIP Cause Map Profile - Cause Map

SBX-8xxxx

SBX-85140 N:1 HA Support on SWe

N:1 HA deployments are now supported for SBC SWe deployments on VMware. Ribbon provides an infrastructure as code (IaC) environment to deploy SBC SWe N:1 HA instances in a VMware environment. The IaC environment provides the code, templates, sample files, and instructions needed for launching and managing virtualized SBC deployments. The instructions for working within the IaC environment are embedded as inline comments within the sample and template files and as separate readme files.

For more information, refer to:

• Using the Ribbon IaC Environment to Deploy SBC SWe on VMware

SBX-85753 Remove Policing Function From the SBC

 Some networks are divided into geographical superzones. In such cases, when video traffic travels between the superzones, the SBC applies the following policing for video traffic (the values shown here are hypothetical):

• Token Bucket Size (bytes): 80,000
• Fill Rate (kbps):                   b-line * 1.5 

The maximum of Token Bucket Size of GilCo's NGN is 100,000. Thus, when B-line is more than 10,000, the SBC may apply excessive policing and cause video deterioration. Therefore, token bucket size 80,000 for video is increased to more than 100,000 or disabling policing. To address this need, you can now disable the SBC's media policing function for audio/video/application streams.

For more information, refer to the following pages:

• Media System - CLI
• Traps - CLI
• System - Media

SBX-86182 OAM Node - Phase 2

For SBC SWe cluster deployments operating in OAM configuration mode, new command parameters provide additional options for managing configuration changes when using the CLI.

• If you start a CLI session and the OAM node holds a candidate configuration (committed changes that have not been save-activated), a warning banner indicates this condition.
• A new request command parameter (viewConfigurationChanges) allows you to list the pending list of committed changes.
• If you determine that you have committed configuration changes that you do not want to save-activate, the request parameter (discardCandidateConfiguration) allows you to discard the pending changes.

 For VNFM users, new options provided for the "createVnfmCsar.py" script that generates CSAR packages allow you to define VNFD files that create multiple redundancy groups in the same VNF and that enable customizing VM sizing of either the SBC or OAM nodes.

 In addition to N:1 deployments in an OpenStack cloud environment, SBC SWe N:1 HA deployments on VMware also require use of  OAM node configuration mode. 

For more information, refer to:

• Request System - CLI
• Show Command Details - CLI
• Reviewing Configuration Changes and Reverting Configuration (OAM Mode)
• Creating a CSAR Package File

SBX-89069 Alternative IP address cannot configure up to 254

The altIpVar configuration is the equivalent of altMediaIp configuration in cloud. Initially, when support for alt media IP addresses was added, a configuration of up to 14 addresses was supported. It is now extended to 254 addresses.

For more information, refer to the following page:

• IP Interface Group - CLI

Resolved Issues

Resolved Issues in 08.02.00R000 Release 

The following issues are resolved in this release:

Known Issues

Known Issues in 08.02.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 SBC SWe Cloud in an N:1 HA Model 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
• Rx, Rf interfaces
• Multimedia - MSRP, BFCP  
• Fax detection
• ICE/STUN
• SIP REFER
• SIP REPLACE

• Two stage calls

• H323 support

• 200 OK is not being sent for call HOLD when sdpAttributeRelay is enabled on the Trunk Group

SMM TEARDOWN on early dialog operation, SBC adds SDP in CANCEL