Skip to end of metadata
Go to start of metadata

Search the Release Notes:

On this page:

About SBC Release Notes

This page describes new features, new hardware and software requirements, and known limitations for the latest release of Sonus' Session Border Controller SBC 5000 series.

Related Documentation

The SBC 5000 series 04.00.02R000 documentation is located at the following Sonus Networks Wiki space: SBC 5000 Series Documentation.

Problems or Questions

For problems or questions, contact the Sonus Technical Assistance Center (TAC) via telephone, fax, or e-mail:

Worldwide Voice: 1 (978) 614-8589

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

Worldwide Fax: 1 (978) 614-8609

Email: TechnicalPublications@sonusnet.com.

About SBC 5000 Series

The Sonus Session Border Controller platforms: SBC 5100, 5110, 5200, 5210, provide enterprises and service providers with the features, performance, and reliability that they require. This versatile series of SBCs can be deployed as a Peering, Access, or enterprise SBC (e-SBC), and is tested for interoperability and performance against a variety of third party products and call flow configuration in the customer networks.

Interoperability

The SBC 5000 series software inter-operates with the following:

  • SIP/H.323 compliant IADs and IP-PBXs
  • Sonus PSX Policy Server Softswitch via SIP redirects and/or Diameter+ protocol
  • Sonus SBC 9000 through SIP call signaling and Sonus Networks MCS protocol

Compatibility with Sonus Products

This 04.00.02R000 release is compatible with the following Sonus product releases versions:

The minimum compatible release versions are listed.

Supported Device Bundles

PSX

GSX

EMS

DSI

ePSX OVA
V09.01.01R000V09.00.03R000V09.01.01R000V09.00.00R000V09.01.01R000
 V09.00.02R000 V08.04.07R000 (Linux) 
 V08.04.08R000 V08.04.02R000 P4 (Solaris) 

For Replica ePSX Installation on SBC:

  • Install/Upgrade PSX Master with the correct version before you install replica ePSX on SBC.
  • Ensure that PSX Master is running V09.01.01R000 version.

ePSX (OVA)

FileUsage
ePSX-V09.01.01R000.ova

ePSX installation package on SBC 5000 series.

ePSX installation is not supported on SBC 5100.

 The ePSX installation package is not available in the standard SBC package. It is provided separately.

To upgrade from ERE to ePSX, contact Sonus Technical Assistance Center (TAC).

Device Manager (DM) Support

When performing a new installation of SBC and EMS, you must also install the latest release of the DM in order to manage the SBC 5000 series system from the EMS. To determine which DM version to install, use the guidelines below:

If using EMS 09.01.01 releases, install the latest release of the DM package (EMS9.1.1_SBX5K4.0.2_DM1.0.0).

DM release notes are accessible from the following link: https://support.sonus.net/display/ALLDOC/Insight+Device+Manager.

Required Software and Firmware Versions

The following SBC 5000 series software and firmware versions are required for this release:

ComponentsSoftware/FirmwareVersion
SBC 5000 Series Platform

BMC

V02.05.00-R0

BIOS

V02.04.00-R0
(Minimum required: V02.01.02-R0)

ConnexIP OS

V02.00.05-R000

SBC 5000 Series Application

SonusDB

V04.00.02-R000
(Minimum required: V01.02.00-R000)

SBC Application

sbc-V04.00.02-R000

Prior SBC 5000 Series Software/Firmware Versions

SBC Release

BMC*

BIOS*

ConnexIP OS

SonusDB*

V02.00.06-R000V01.14.00-R000V01.06.03-R000V01.07.05-R000V02.00.06-R000
V02.00.06-R001V01.14.00-R000V01.06.03-R000V01.07.05-R000V02.00.06-R001
V02.00.06-R002V01.14.00-R000V01.06.03-R000V01.07.05-R000V02.00.06-R002
V02.00.06-F001V01.14.00-R000V01.06.03-R000V01.07.05-R000V02.00.06-F001
V02.00.06-F002V01.14.00-R000V01.06.03-R000V01.07.05-R000V02.00.06-F002
V02.00.06-F003V01.14.00-R000V01.06.03-R000V01.07.05-R000V02.00.06-F003
V02.00.06-F004V01.14.00-R000V01.06.03-R000V01.07.05-R000V02.00.06-F004
V02.00.06-F005V01.14.00-R000V01.06.03-R000V01.07.05-R000V02.00.06-F005
V02.00.06-F006V01.14.00-R000V01.06.03-R000V01.07.05-R000V02.00.06-F006
V02.00.06-F007V01.14.00-R000V01.06.03-R000V01.07.05-R000V02.00.06-F007
V02.00.07-R000V01.14.00-R000V01.06.03-R000V01.07.05-R000V02.00.07-R000
V02.00.07-F001V01.14.00-R000V01.06.03-R000V01.07.05-R000V02.00.07-F001
V02.00.07-F002V01.14.00-R000V01.06.03-R000V01.07.05-R000V02.00.07-F002
V02.00.07-F003V01.14.00-R000V01.06.03-R000V01.07.05-R000V02.00.07-F003
V02.00.08-R000V01.14.00-R000V01.06.03-R000V01.07.05-R000V02.00.08-R000
V02.00.08-F001V01.14.00-R000V01.06.03-R000V01.07.05-R000V02.00.08-F001
V02.00.08-F002V01.14.00-R000V01.06.03-R000V01.07.05-R000V02.00.08-F002
V02.00.09-R000V01.14.00-R000V01.06.03-R000V01.07.05-R000V02.00.09-R000
V02.00.09-F001V01.14.00-R000V01.06.03-R000V01.07.05-R000V02.00.09-F001
V02.00.10-R000V01.14.00-R000V01.06.03-R000V01.07.05-R000V02.00.10-R000
V02.00.10-R001V01.14.00-R000V01.06.03-R000V01.07.05-R000V02.00.10-R001
V02.00.11-R000V01.14.00-R000V01.06.03-R000V01.07.05-R000V02.00.11-R000
V02.00.12-R000V01.14.00-R000V01.06.03-R000V01.07.05-R000V02.00.12-R000
V03.00.00-R000V02.01.07-R000V02.00.00-R000V01.08.00-R000V03.00.00-R000
V03.00.01-R000V02.01.07-R000V02.00.00-R000V01.08.01-R000V03.00.01-R000
V03.00.01-R001V02.01.07-R000V02.00.00-R000V01.08.01-R000V01.02.00-R000
V03.00.01-F001V02.01.07-R000V02.00.00-R000V01.08.01-R000V01.02.00-R000
V03.00.02-R000V02.01.07-R000V02.00.00-R000V01.08.02-R000V01.02.00-R000
V03.00.02-R001V02.01.07-R000V02.00.00-R000V01.08.02-R000V01.02.00-R000
V03.00.02-F001V02.01.07-R000V02.00.00-R000V01.08.02-R000V01.02.00-R000
V03.00.02-F002V02.01.07-R000V02.00.00-R000V01.08.02-R000V01.02.00-R000
V03.00.02-F003V02.01.07-R000V02.00.00-R000V01.08.02-R000V01.02.00-R000
V03.00.02-F004V02.01.07-R000V02.00.00-R000V01.08.02-R000V01.02.00-R000
V03.00.03-R000V02.01.07-R000V02.00.00-R000V01.08.03-R000V01.02.00-R000
V03.00.03-R001V02.01.07-R000V02.00.00-R000V01.08.03-R000V01.02.00-R000
V03.00.03-R002V02.01.07-R000V02.00.00-R000V01.08.04-R000V01.02.00-R000
V03.00.04-R000V02.01.07-R000V02.00.00-R000V01.08.04-R000V01.02.00-R000
V03.00.04-F001V02.01.07-R000V02.00.00-R000V01.08.05-R000V01.02.00-R000
V03.00.04-F002V02.01.07-R000V02.00.00-R000V01.08.05-R000V01.02.00-R000
V03.00.04-F003V02.01.07-R000V02.00.00-R000V01.08.05-R000V01.02.00-R000
V03.00.04-F004V02.01.07-R000V02.00.00-R000V01.08.05-R000V01.02.00-R000
V03.00.04-F005V02.01.07-R000V02.00.00-R000V01.08.05-R000V01.02.00-R000
V03.00.04-F006V02.01.07-R000V02.00.00-R000V01.08.05-R000V01.02.00-R000
V03.00.04-F007V02.01.07-R000V02.00.00-R000V01.08.05-R000V01.02.00-R000
V03.00.05-R000V02.01.07-R000V02.00.00-R000V01.08.06-R000V01.02.00-R000
V03.00.05-F001V02.01.07-R000V02.00.00-R000V01.08.06-R000V01.02.00-R000
V03.00.06-R000V02.01.07-R000V02.00.00-R000V01.08.07-R000V01.02.00-R000
V03.00.06-F001V02.01.07-R000V02.00.00-R000V01.08.07-R000V01.02.00-R000
V03.00.07-R000V02.01.07-R000V02.00.00-R000V01.08.07-R000V01.02.00-R000
V03.01.00-R000V02.01.07-R000V02.00.00-R000V02.00.00-R007V01.02.00-R000
V03.01.00-R001V02.04.01-R000V02.01.01-R000V02.00.00-R007V01.02.00-R000
V03.01.00-F001V02.04.01-R000V02.01.01-R000V02.00.00-R007V01.02.00-R000
V03.01.01-R000V02.04.01-R000V02.01.02-R000V02.00.00-R007V01.02.00-R000
V03.01.01-R001V02.04.01-R000V02.01.02-R000V02.00.01-R007V01.02.00-R000
V03.01.01-F001V02.04.01-R000V02.01.02-R000V02.00.01-R008V01.02.00-R000
V03.01.01-F002V02.04.01-R000V02.01.02-R000V02.00.01-R008V01.02.00-R000
V03.01.02-R000V02.04.01-R000V02.01.02-R000V02.00.01-R010V01.02.00-R000
V03.01.02-R001V02.04.01-R000V02.01.02-R000V02.00.01-R010V01.02.00-R000
V03.01.02-R002V02.04.01-R000V02.01.02-R000V02.00.01-R011V03.01.02-R002
V03.01.03-R000V02.04.01-R000V02.02.00-R000V02.00.01-R012V03.01.03-R000
V03.01.03-R001V02.04.01-R000V02.02.00-R000V02.00.01-R012V03.01.03-R001
V03.01.04-R000V02.04.01-R000V02.02.00-R000V02.00.01-R013V03.01.04-R000
V03.01.05-R000V02.05.00-R000V02.03.00-R000V02.00.01-R014V03.01.05-R000
V04.00.00-R000V02.04.01-R000V02.02.00-R000V02.00.02-R000V04.00.00-R000
V04.00.01-R000

V02.04.01-R000

V02.02.00-R000

V02.00.03-R000

V04.00.01-R000

* Minimum required version for this release.

How to Verify Currently Installed Software/Firmware Versions

Use Platform Manager to verify the currently installed software and firmware versions.

Figure : Platform Manager - Software Versions

During an SBC upgrade process, the SonusDB version may not get upgraded and this will not have any functional impact.

Software Bundles

Download the required software bundles from the Customer Portal to your PC:

Verify all the downloaded .rom files with the respective Sonus supplied .md5 files to make sure that the .rom files are not corrupted.

Firmware

  • firmware-bmc5X00_v2.5.0-R0.tar.gz
  • firmware-bmc5X00_v2.5.0-R0.tar.gz.md5

Operating System

  • connexip-os_02.00.05-R000_amd64.iso
  • connexip-os_02.00.05-R000_amd64.iso.md5

Application

  • sbc-V04.00.02-R000.x86_64.tar.gz
  • sbc-V04.00.02-R000.x86_64.md5
  • sbc-V04.00.02-R000.x86_64.signature

For detailed information on installation and upgrade procedures, refer to Installing and Commissioning SBC 5000 Series.

Supported SBC 5000 Series Upgrade Paths

From release version...To release version...
V02.00.06R000V04.00.02R000
V02.00.06R001V04.00.02R000
V02.00.06R002V04.00.02R000
V02.00.06F001V04.00.02R000
V02.00.06F002V04.00.02R000
V02.00.06F003V04.00.02R000
V02.00.06F004V04.00.02R000
V02.00.06F005V04.00.02R000
V02.00.06F006V04.00.02R000
V02.00.06F007V04.00.02R000
V02.00.07R000V04.00.02R000
V02.00.07F001V04.00.02R000
V02.00.07F002V04.00.02R000
V02.00.07F003V04.00.02R000
V02.00.08R000V04.00.02R000
V02.00.08F001V04.00.02R000
V02.00.08F002V04.00.02R000
V02.00.09R000V04.00.02R000
V02.00.09F001V04.00.02R000
V02.00.10R000V04.00.02R000
V02.00.10R001V04.00.02R000
V02.00.11R000V04.00.02R000
V02.00.12R000V04.00.02R000
V02.02.07R000V04.00.02R000
V03.00.00R000V04.00.02R000
V03.00.01R000V04.00.02R000
V03.00.01R001V04.00.02R000
V03.00.01F001V04.00.02R000
V03.00.02R000V04.00.02R000
V03.00.02R001V04.00.02R000
V03.00.02F001V04.00.02R000
V03.00.02F002V04.00.02R000
V03.00.02F003V04.00.02R000
V03.00.02F004V04.00.02R000
V03.00.03R000V04.00.02R000
V03.00.03R001V04.00.02R000
V03.00.03R002V04.00.02R000
V03.00.04R000V04.00.02R000
V03.00.04F001V04.00.02R000
V03.00.04F002V04.00.02R000
V03.00.04F003V04.00.02R000
V03.00.04F004V04.00.02R000
V03.00.04F005V04.00.02R000
V03.00.04F006V04.00.02R000
V03.00.04F007V04.00.02R000
V03.00.05R000V04.00.02R000
V03.00.05F001V04.00.02R000
V03.00.06R000V04.00.02R000
V03.00.06F001V04.00.02R000
V03.00.07R000V04.00.02R000
V03.01.00R000V04.00.02R000
V03.01.00R001V04.00.02R000
V03.01.00F001V04.00.02R000
V03.01.01R000V04.00.02R000
V03.01.01R001V04.00.02R000
V03.01.01F001V04.00.02R000
V03.01.01F002V04.00.02R000
V03.01.02R000V04.00.02R000
V03.01.02R001V04.00.02R000
V03.01.02R002V04.00.02R000
V03.01.03R000V04.00.02R000
V03.01.03R001V04.00.02R000
V03.01.04R000V04.00.02R000
V03.01.05R000V04.00.02R000
V04.00.00R000V04.00.02R000
V04.00.01R000V04.00.02R000

SBC versions V02.00.06R000 and above can directly LSWU to V04.00.02R000.

Modifications to Existing Functionality

The descriptions of the following fields have changed since their functionality changed.

Disable Media Lock Down

From:

Disable Media Lock Down: Specifies the controls whether the SBC 5000 disables the Media Lock down flag. When disabled, enables media lock down by not sending SIP Re-INVITE/UPDATE messages. When enabled, disabled media lock down by sending Re-INVITE/UPDATE messages.

To:

Disable Media Lock down: If SBC offers both pass-thru and transcode codecs, the Minimize Relaying Of Media Changes From Other Call Leg flag effectively suppresses the re-INVITEs to peers when the peer answers with a single codec. However, if the peer has multiple codecs, The Minimize Relaying Of Media Changes From Other Call Leg flag in certain situations can not suppress the re-INVITEs as change in one of the common codecs is detected. In these situations, if the SBC’s most preferred codec matches the peers most preferred codec, the Disable Media Lock Down flag can be used to suppress this Modify Offer. The Disable Media Lock down flag controls the modify offer initiated by SBC to lock down the codec. If this flag is disabled, SBC sends a modify offer to lockdown the codec, if enabled, SBC will not initiate modify offer to lock down the codec.

Examples:

Example1:

In the following table, the Modify Offers (in green) are suppressed if the Minimize Relaying Of Media Changes From Other Call Leg flag is enabled:

Ingress Peer

 

SBC

 

Egress Peer

G711U

->

SBC offers G711U as pass-through codec and G729A as a transcode option by reserving a DSP channel

->

G711U,G729A

G711U

<-

SBC releases the DSP channel resulting in a G711U pass-thru call

<-

G711U

 

 

Receive capabilities of SBC have changed as a codec G729A was removed and the DSP channel de-allocated.
Default behavior is to send Modify Offer; to suppress, the Minimize Relaying Of Media Changes From Other Call Leg flag should be enabled

->

G711U

 

 

 

<-

G711U

Example 2:

The messages (in green) can be suppressed if the Disable Media Lock Down field is enabled.

Ingress Peer

 

SBC

 

Egress Peer

G711U

->

SBC offers G711U as pass-through codec and G729A as a transcode option by reserving a DSP channel

->

G711U,G729A

G711U

<-

SBC releases the DSP channel resulting in a G711U pass-thru call

<-

G711U,G729A

 

 

Receive capabilities of SBC have changed as a codec G729A was removed and the DSP channel deallocated.
Default behavior is to send Modify Offer; the Minimize Relaying Of Media Changes From Other Call Leg flag cannot suppress this Modify Offer as a common codec in the original offer and answer (G729A) has been removed; To suppress this re-INVITE, enable DML

->

G711U

 

 

 

<-

G711U

Ingress Peer

 

SBC

 

Egress Peer

G711U

->

SBC offers G711U as pass-through codec and G729A,G726 as transcode options by reserving a DSP channel

->

G711U,G729A,G726

G711U

<-

Transcode G711-G729A call. Egress codec is locked down to G729A

<-

G729A,G726

 

 

Receive capabilities of SBC have changed to G729A due to transcode.
Default behavior is to send Modify Offer to lockdown to G729A; the Minimize Relaying Of Media Changes From Other Call Leg flag cannot suppress this Modify Offer as a common codec in the original offer and answer (G726) has been removed; To suppress this re-INVITE, enable DML

->

G729A

 

 

 

<-

G729A

For more information, refer to Common IP Attributes (SIP), and commonIpAttributes (SIP).

Minimizing Relay of Media Changes From Other Call Leg

From

Minimize Relaying of Media Changes From Other Call Leg: This flag is used to minimize the relaying of media changes to the other call leg. When enabled, the SBC 5000 does not send re-INVITE messages from SIP Server 1 to SIP Server 2 in peer-to-peer passthrough without transcoding scenarios. This allows the call leg to SIP Server 2 to be shielded from the end-to- end propagation of SDP offers and answers. The SBC 5000 implements hold and resume operations for the call leg from SIP Server 1 internally and responds with answers without signaling to the other call leg that media is being stopped or restarted.
When disabled, the SBC 5000 does not minimize the relaying of media changes.

Note: When this parameter is enabled and a call is put on hold, SBC 5000 detection of rogue media may occur and the call may be reported as a rogue media offender. The UDP port associated with the call may be quarantined. If a Secure RTP call is put on hold for approximately five minutes, the audio is lost when the call is taken off hold. Use of this flag is discouraged. It should be used with the understanding of the drawbacks described in this note.

To

Minimize Relaying of Media Changes From Other Call Leg: The advertised Sonus SIP SDP described as a set of capabilities that the SBC can receive. SBC by default will issue a Modify Offer ( re-INVITE, UPDATE) whenever it detects a change in receive capabilities. In certain scenarios, the Modify Offer can be redundant, enabling Minimize Relaying of Media Changes flag suppresses redundant Modify offers being sent from SBC. When the flag is enabled,the SBC will not propagate a Modify Offer as long as it does not detect changes in the “common codecs” that have a detrimental impact on the end user experience. The “Common codecs” are codecs that exist both in the initial offer and answer – G711U in the example shown. Changes to common codecs imply changes to DTMF, packetization time, codec specific FMTP attributes, data-path-mode.

Examples:

Example1:

The re-INVITEs (in green) are suppressed if the Minimize Relaying Of Media Changes From Other Call Leg flag is enabled.

Ingress Peer

 

SBC

 

Egress Peer

G711U

->

SBC offers G711U as pass-through codec and G729A as a transcode option by reserving a DSP channel

->

G711U,G729A

G711U

<-

SBC releases the DSP channel resulting in a G711U pass-thru call

<-

G711U

 

 

Receive capabilities of SBC have changed as a codec G729A was removed; send Modify Offer to Peer to advertise the latest set of capabilities

->

G711U

 

 

 

<-

G711U

Example2:

SBC suppresses a Modify Offer from the ingress peer. The offer changes the maxptime from 10 to 20ms. An increase in maxptime can be suppressed – a device that advertises a maxptime of 20ms can also receive 10ms packets.

Ingress Peer

 

SBC

 

Egress Peer

G711U 10ms

->

 

->

G711U 10ms

G711U

<-

 

<-

G711U

Re-INVITE (G711U 20ms)

->

Suppress the re-INVITE if minimize media is enabled and respond to ingress peer; else forward the re-INVITE to egress

->

G711U 20ms

G711U

<-

 

<-

G711U

Conversely, irrespective of the state of the Minimize Relaying Of Media Changes From Other Call Leg flag All field cannot suppress a change of maxptime from 20ms to 10ms.

Ingress Peer

 

SBC

 

Egress Peer

G711U 20ms

->

 

->

G711U 20ms

G711U

<-

 

<-

G711U

Re-INVITE (G711U 10ms)

->

 

->

G711U,10ms

G711U

<-

 

<-

G711U

Example3:

A change of data-path-mode from sendrecv to sendonly ( HOLD request) can also be suppressable. The rational is that SBC can always ignore the media received from the peer and continue to send it media.

Ingress Peer

 

SBC

 

Egress Peer

G711U sendrecv

->

 

<-

G711U sendrecv

G711U

<-

 

->

G711U

Re-INVITE (G711U sendonly)

->

Suppress the re-INVITE if minimize media is enabled and respond to ingress peer; else forward the re-INVITE to egress

<-

G711U sendonly

G711U

<-

 

->

G711U

Conversely, SBC irrespective of the state of the Minimize Relaying Of Media Changes From Other Call Leg flag, cannot suppress a change of data-path-mode from sendonly to sendrecv.

Ingress Peer

 

SBC

 

Egress Peer

G711U sendonly

->

 

->

G711U sendonly

G711U

<-

 

<-

G711U

Re-INVITE (G711U sendrecv)

->

 

->

G711U sendrecv

G711U

<-

 

<-

G711U

For more information, refer to Common IP Attributes (SIP), and commonIpAttributes (SIP).

Relay Data Path Mode Changes

Relay Data Path Mode Changes: When the Relay Data Path Mode Change From Other Call Leg flag is enabled in conjunction with Minimize media, the HOLD modify offers (or more specifically any modify offer that changes the data-path-mode) will get propagated.

The Relay Data Path Mode Change From Other Call Leg flag is only applicable to cases when Minimize Relaying Of Media Changes From Other Call Leg flag is enabled.

Examples:

Example1:

When Minimize Relaying Of Media Changes From Other Call Leg flag is enabled, and when Relay Data Path Mode Change From Other Call Leg is disabled:

Ingress Peer

 

SBC

 

Egress Peer

G711U,G729A sendrecv

->

 

->

G711U,G729A sendrecv

G711U

<-

 

<-

G711U

Re-INVITE (G711U sendonly)

->

Suppress the re-INVITE and respond to ingress peer. Discard media received from the egress peer

 

 

G711U

<-

 

 

 

Example2:

When the Minimize Relaying Of Media Changes From Other Call Leg flag is enabled, and when Relay Data Path Mode Change From Other Call Leg is enabled:

Ingress Peer

 

SBC

 

Egress Peer

G711U,G729A sendrecv

->

 

->

G711U,G729A sendrecv

G711U

<-

 

<-

G711U

Re-INVITE (G711U sendonly)

->

 

->

G711U sendonly

G711U

<-

 

<-

G711U

For more information, refer to Common IP Attributes (SIP), and commonIpAttributes (SIP).

New Features

 The following new features/enhancements are included in this release:

SBX-8 MIME Handling with 3 CRLFs Between Mheaders and MIME Bodies

To inter-operate with Broadsoft, SBC can handle requests with 3 consecutive CRLFs between the message headers and the message body only for MIME (end of last header, one separating the headers from the body and one at the end of the preamble). An extra CRLF is sent in message between message header and the message body to support this feature.

For more information, refer to SIP Header Support.

SBX-206 Re PCR4741/4937 - Crankback after Redirection Fails for Certain Cases

For a 3xx redirect response with multiple contacts (having host port as SBC SIP signaling IP address), if the TG is disabled or the CAC limit is reached for a previous contact's route:

  • The subsequent contacts must be tried.
    For example, when A calls B, the ERE/PSX returns three routes – Route1, Route2, and, Route3. SBC sends INVITE towards B on Route1. B replies (3xx) with three contacts (Contact1, Contact2, and Contact3). The host port of all the three contacts is SBC SIP signaling IP address. The ERE/PSX is checked for the route towards Contact1. A single route RouteA1 is returned. When RouteA1 TG is disabled or CAC call limit is reached, the subsequent contacts (contact2 and contact3) must be tried. Therefore, Invite is sent for contact2.
  • The subsequent routes in the original route set must be tried, if all the contacts are exhausted.
    For example, when A calls B, the ERE/PSX returns three routes – Route1, Route2, and Route3. SBC sends INVITE towards B on Route1. B replies (3xx) with three contacts (Contact1, Contact2, and Contact3). The host port of all the three contacts is SBC SIP signaling IP address. The ERE/PSX is checked for the route towards Contact1. A single route RouteA1 is returned. When RouteA1 TG is disabled or CAC call limit is reached, the subsequent contacts (contact2 and contact3) must be tried. If all the contacts fail original routes, Route2 and Route3 must be tried.

For more information, refer to Crankback After 3xx Redirection.

SBX-2189 BMC host monitor / SBX-2190 Host HW watchdog timer

This PCR describes various components and actions managed by the BMC, BIOS and OS to detect low level lockup failures in SBX5x00/7x00, then auto restart is performed by the BMC.

BMC restarts during the following events

  • If BIOS fails during bootup.
  • If OS fails during bootup.
  • If the host gets locked up or ends up in a bad state where it cannot perform basic functionality like scheduling processes.

The maximum number of attempts to recover the host is three. After this, the host will require manual recovery and debug. The host implements a watchdog mechanism to manage the hardware timer in BMC to indicate that it is in healthy condition.

Host failures can be categorized in two major categories – Pre-OS boot stage and OS running stage.

FailureEffectNote
1.       BIOS Reset failureNo restart, BIOS locked upBIOS Boot monitor
2.       SSD Detection failureNo Bootup, BIOS may be stuck in EFI shell, BBS priority messed upBIOS Boot monitor
3.      Disk Corruption or Bad diskNo Bootup, BIOS may be stuck in EFI shell, BBS priority may be messed upNot monitored
4.       Hardware FailureBIOS lockupBIOS Boot monitor
5.      BIOS software failureBIOS lockupBIOS Boot monitor
6.      Kernel Panic during bootupHost restarts automatically or gets lockedOS Monitor / Watchdog Standard Mechanism
7.       Machine CheckHost Gets locked or restartsOS Monitor / Watchdog Standard Mechanism
8.       Kernel/Driver misbehaviorHost locked or restarts automaticallyOS Monitor / Watchdog Standard Mechanism
9.       Power Supply FailurePOWER_OK goes bad, host gets stuckPower Supply Monitor

SBX-2326 Direct Media Support When Using SIP-TLS SRTP 

The SBC supports the following Direct Media functionality.

  • Direct Media in Access scenario where SRTP/TLS is used on the access side and RTP/UDP is used towards the core, all calls between subscribers with in the same access group use direct media. For all other cases, the SBC anchors the media.
  • Direct Media when using SIP-TLS SRTP for endpoints behind NAT devices:
    • Encoding of SRTP SDP received from the peer as X-DMI and sending it as SDP attribute on the outgoing side (applies to all requests and responses supported by the SBC).
    • Decoding X-DMI attribute containing encoded SRTP SDP received and sending it as SDP to the peer when the media zone on the received X-DMI and the peer TrunkGroup are the same (applies to all requests and responses supported by the SBC)
  • Direct Media in Peering scenario where Direct Media over SRTP is established between two peers under the same media zone for both audio and video calls.
  • Remote ringback Broadsoft scenario in conjunction with direct media calls. For example:
    • SBC sends INVITE with SDP containing X-DMI attribute.
    • 180 response is received with SDP and no X-DMI. SBC will anchor the media at this point and send its own SDP on the ingress side.
    • 200 OK is received with SDP containing X-DMI attribute. SBC modifies the media to Direct Media.

Direct Media is allowed between endpoints in the same media zone belonging to the same SBC or a different SBC. For example, Direct Media with TLS/SRTP is applicable for a distributed network containing two SBCs. 

For more information, refer to SRTP for Media.

SBX-2986 RADIUS Authentication Shared Secret 8 Character Key Length 

The SBC RADIUS authentication shared secret key length range is expanded from 16-128 to 8-128 characters.

For more information, refer to Radius Authentication, RADIUS Server, Radius Authentication (CLI) and Accounting (CLI).

SBX-2657 TLS Encryption - Support AES256 bit Cipher Suites / SBX-3504 Support of TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 Cipher Suite

As an enhancement for this feature, SBC now supports three new ciphers for TLS Profile object:

  • rsa-with-aes-256-cbc-sha

  • rsa-with-aes-256-cbc-sha-256

  • tls_ecdhe_rsa_with_aes_256_cbc_sha384

To use these ciphers, the TLS Protocol Version, v1_2, should be enabled on the TLS Profile object.

For more information, refer to TLS for SignalingTLS Profile and TLS Profile (CLI).

SBX-2717 Pass-Through Functionality for GSM06.10 Codec

The SBC supports relaying the GSM Full Rate Audio (13kbit/s) codec in pass-through mode as defined by RFC 3551. Transcoding from GSM to any other codec is not supported at this time.

The External PSX and ePSX do not support GSM as a codec.

If GSM is the preferred codec for a given call, then it is also recorded in the CDRs as defined below.

Ingress Codec Type

Location:             STOP-79, ATTEMPT-69

Format:                String field up to 6 places.

                                <networkType>:<codecType>:<audioEncoding>

Description:       Indicates the codec used for the ingress side of the call.  Changes to this field are highlighted below <audioEncoding>; if not applicable, is set to 0.

Examples:           A GSM packet call with aLaw encoding will be displayed as: “P:66:0”

Egress Codec Type

Location:             STOP-80, ATTEMPT-70

Format:                String field up to 6 places.

                                <networkType>:<codecType>:<audioEncoding>

Description:       Indicates the codec used for the ingress side of the call.  Changes to this field are highlighted below..  <audioEncoding>; if not applicable, is set to 0.

Examples:           A GSM packet call with aLaw encoding will be displayed as: “P:66:0”

For more information, refer to CDR Field Descriptions, Supported CodecsProfiles- Codec Entry and Codec Entry (CLI).

SBX-2776 Support of Additional Bit Rates for G722.1

This feature enhances the Sonus SBC Portfolio to support the following bit rates:

  • Pass-through for G722.1 at 16000 Hz clock rate and bit rate of 16000 bps
  • Pass-through of G722.1 at 32000 Hz  clock rate

For more information, refer to Profiles- Codec EntrysipTrunkGroup signaling (CLI), SIP Trunk Group, and SIP Trunk Group - Signaling.

SBX-3076 SBC 5x00 4.0.2 Certificate and TLS Miscellaneous Enhancements - SAN support

Earlier, the user could request SBC to generate Key Pairs, Certificate Request and also install the corresponding certificates. The user could also specify the size of the private key (1K or 2K) and the certificate subject (distinguish name/DN). However, now, SBC extends the support for Subjective Alternative Name (SAN) while generating CSR.

The Subjective Alternative Name (SAN) is an X509 version 3 extension that allows an SSL certificate to specify multiple names that the certificate should match. This allows the user to secure a large number of domains with only one certificate. Even when SAN contains eMail addresses, IP Addresses, Regular DNS Host Name, and so on, SBC now supports only DNS Host Name.

The Lync 2013 video call requires a unique FQDN to identify SBC. This FQDN is not the same as the one used by the Mediation server for regular Audio Only calls. Since SBC now requires 2 FQDN to place bothe Audio and Video calls on Lync using static route from Lync FE, SBC local certificate must contain both the FQDNs for CN and SAN. This is required for a successful TLS connection set up between Lync and SBC.

For more information, refer to Certificate Management, MS Lync FQDN Support, Certificate, and PKI Security (CLI).

PSX-2244 Using Multiple Named Non-Routable IPTGs in defaultSigZone for Calls

SBC supports multiple named non-routable IP trunk groups created in the defaultSigZone for GW-GW, SIP Servers/ASX SIP Core routing and H.323 calls. The following routes are supported in defaultSigZone and default addressContext:

GW-GW Routing:

  • gwSigPort – Local GW IP address
  • defaultGwIptg [Used towards Sonus GW core to reach any Sonus Gateway not specified below]
    • prefix-0.0.0.0
  • namedGwIptg [Used towards specific Sonus GW]
    • prefix-10.1.x.x

Routing to SIP Servers/ASX, SIP hop-by-hop routing and SIP Core Optimized routing:

  • sipSigPort– Local SIP IP address
  • defaultSipIptg [Used towards any SIP Server and also used for Sonus SIP core]
    • prefix-0.0.0.0 [Wildcard IP to reach any SIP server/ Gateway not specified below]
  • namedSipCoreIptg [Used towards Sonus SIP core]
    • prefix-10.2.x.x [peer SBC address(s) acting as Gateway]
  • namedSipIptg1 [Used towards SIP Server-1]
    • prefix-10.3.x.x [SIP Server-1 contact address]
  • namedSipIptg2 [Used towards SIP Server-2]
    • prefix-10.4.x.x. [SIP Server-1 contact address]
  • namedSipIptg-ASX [Used towards ASX]
    • prefix-10.5.x.x. [ASX contact address]

Routing to H.323 servers:

  • h323SigPort– Local H323 IP address
  • defaultH323Iptg [Used towards any H323 Server]
    • prefix-0.0.0.0 [Wildcard IP to reach any H323 Server]
  • namedH323Iptg [Used H323 Server]
    • prefix-10.2.x.x [H323 Server-1 contact address]

 

Figure : Using Multiple Named Non-Routable IPTGs in defaultSigZone for Calls

For more information, refer to Routing Mechanisms.

SBX-3077 SBC 5x00 4.0.2 Certificate and TLS Miscellaneous Enhancements - TLS Empty Fragment Packets 

Lync 2013 uses a SIP method NEGOTIATE to set up a TLS connection between the Lync FE and SBC. Once this connection is successfully established, Lync 2013 starts sending the calls over the TLS connection to SBC. Earlier, OpenSSL stack from SBC inserts empty packets in the TLS response to the NEGOTIATE method. The Lync FE with an older version of TLC, does not set up the TLS connection when the TLS empty packets are received. Therefore, none of the calls reach SBC.

To support older version of TLS implementation, a new configurable option, Suppress Empty Fragments,  is added to TLS Profile object to optionally enable or disable the option to send empty packets in TLS connection.

Issues Resolved

Please Log in to view Issues Resolved for Release 04.00.02R000 page.

Known Issues

Please Log in to view Known Issues for Release 04.00.02R000 page.

Known Limitations

Please Log in to view Known Limitations for Release 04.00.02R000 page.