550-08642 07.01 SBC Core 11.01.00R000 Getting Started

SBC Core
Getting Started
Software Release: 11.01.00R000
Document Revision: 07.01
Published: December 15, 2022
https://ribboncommunications.com 550-08642
Copyright
© 2020-2022 Ribbon Communications Operating Company, Inc. © 2020-2022 ECI Telecom Ltd. All rights reserved. The compilation (meaning the
collection, arrangement and assembly) of all content on this site is protected by U.S. and international copyright laws and treaty provisions and may not
be used, copied, reproduced, modified, published, uploaded, posted, transmitted or distributed in any way, without prior written consent of Ribbon
Communications Inc.
Disclaimer and Restrictions

The publication is for information purposes only and is subject to change without notice. This publication does not constitute a commitment on the part of
Ribbon. While reasonable efforts have been made in the preparation of this publication to assure its accuracy, Ribbon assumes no liability resulting from
technical or editorial errors or omissions, or for any damages whatsoever resulting from the furnishing, performance, or use of the information contained
herein. Ribbon reserves the right to make changes to this publication and to Ribbon products without notice in its sole discretion. This publication is not
meant to define any interfaces between Ribbon products and any third-party hardware or software products.
Warranties
THIS INFORMATION IS PROVIDED “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NONINFRINGEMENT. IN NO
EVENT SHALL RIBBON BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OR PERFORMANCE OF THIS INFORMATION, EVEN IF
ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Compliance with Applicable Laws and Export Control Laws

The information in this publication is subject to all applicable U.S. federal, state, and local laws. The customer use, distribution, and transfer of any
technical information shall be in compliance with all applicable export and import laws and regulations. All Ribbon products and publications are
commercial in nature; and the use, duplication, or disclosure by the United States Government is subject to the restrictions set forth in DFARS 252.227-
7013 and FAR 52.227-19.
Trademarks
The trademarks, logos, service marks, trade names, and trade dress (“look and feel”) on this website, including without limitation the RIBBON and
RIBBON logo marks, are protected by applicable US and foreign trademark rights and other proprietary rights and are the property of Ribbon
Communications Operating Company, Inc. or its affiliates. Any third-party trademarks, logos, service marks, trade names and trade dress may be the
property of their respective owners. Any uses of the trademarks, logos, service marks, trade names, and trade dress without the prior written consent of
Ribbon Communications Operating Company, Inc., its affiliates, or the third parties that own the proprietary rights, are expressly prohibited.
UNCONTROLLED COPY: The original content is stored in an electronic database and is “write protected”; it may be altered only by authorized persons.
While copies may be printed, it is not recommended. Viewing of the original content electronically ensures access to the current content. Any hardcopies
taken must be regarded as uncontrolled copies.
For access to the technical documentation, log in through Ribbon Support Services website at
https://ribboncommunications.com/services/support-services/technical-documentation
Copyright © 2020-2022 Ribbon Communications Operating Company, Inc. (''Ribbon''). © 2020-2022 ECI Telecom Ltd. Page 2
1. Getting Started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 How to Access the SBC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.1 Logging Into EMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1.2 Logging Into the CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.1.3 Logging into EMA in Platform Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.1.4 Logging Into the BMC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.1.5 Accessing SOAP API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.1.6 Accessing REST API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.2 First Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.2.1 First Steps for SBC 5400 and 7000 Series . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.2.2 First Steps for SBC SWe on VMware or KVM Hypervisor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.2.3 First Steps for SBC SWe in an OpenStack Cloud Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.3 About SBC Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.4 About the SBC Core Family . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.4.1 SBC Core Application Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
1.4.2 SBC Software Edition - SBC SWe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
1.4.3 SBC Core Lifecycle Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
1.5 Feature Availability by Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
1.6 SBC Product Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
1.7 SBC Provisioning Limits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
1.8 SBC Performance Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
1.8.1 SBC 51x0 and 52x0 Performance Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
1.8.2 SBC 5400 Performance Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
1.8.3 SBC 7000 Performance Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
1.8.4 SBC SWe Performance Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
1.8.5 SLB Performance Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
1.9 Supported SIP Headers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
1.10 Supported Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
1.11 Routing and Policy Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
1.11.1 Routing Engines Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
1.12 SBC Module Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
1.13 Interoperability - IOT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
1.14 Copyright and Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Getting Started
Table of Contents
How to Access the SBC

Logging Into EMA
Logging Into the CLI
Logging into EMA in Platform Mode
Logging Into the BMC
Accessing SOAP API
Accessing REST API
First Steps
First Steps for SBC 5400 and 7000 Series
First Steps for SBC SWe on VMware or KVM Hypervisor
First Steps for SBC SWe in an OpenStack Cloud Environment
About SBC Documentation

About the SBC Core Family
SBC Core Application Architecture
SBC Software Edition - SBC SWe
SBC Core Lifecycle Management
Feature Availability by Platform

SBC Product Specifications
SBC Provisioning Limits
SBC Performance Metrics
SBC 51x0 and 52x0 Performance Metrics
SBC 5400 Performance Metrics
SBC SWe Performance Metrics
SLB Performance Metrics
Supported SIP Headers

Supported Standards
Routing and Policy Management
Routing Engines Comparison
SBC Module Descriptions

Interoperability - IOT
Copyright and Trademarks
How to Access the SBC
In this section: Related articles:
Logging Into EMA

EMA
EMA in Platform Mode
Command Line Interface
Baseboard Management Controller
Accessing SOAP API
SOAP API
Accessing REST API
REST API
Insight EMS SBC Configuration Manager
SBC SOAP API reference (EMS)
A Note About SFTP
The primary interfaces used to access the SBC are the Embedded Management Application (EMA) GUI, EMA in Platform Mode GUI, Command
Line Interface (CLI) and BMC (Baseboard Management Controller) GUI, Representational State Transfer Application Processing Interface (REST
API ) and Simple Object Access Protocol Application Processing Interface (SOAP API).
EMA
The EMA provides an easy method to provision, maintain and administer the SBC platform from any Web browser. This is the most frequently
used access method. For more details, refer to the EMA User Guide.
For login details, see Logging Into EMA.
EMA in Platform Mode

The EMA in Platform Mode provides current status of the platform, application software version information and system information. The EMA in
Platform Mode is also used to start, stop and restart the application as well as reboot the host. The EMA in Platform Mode supports upgrading the
operating system and application. Additional features include a web interface for generic troubleshooting activities, security and remote access
management.
For more information, refer to Logging into EMA in Platform Mode.
Command Line Interface

Command Line Interface (CLI) is the traditional method to configure systems from any machine with network access using a secure shell (SSH)
client terminal emulator).
For login details, refer to Logging Into the CLI.
Baseboard Management Controller

The Baseboard Management Controller (BMC) supports the following functions:
View basic system information

Change mouse mode
Configure BMC and EMA in Platform Mode network settings
Add, edit or remove users
Configure NTP settings
View or change SSL certificate
Perform remote control settings
Update BMC firmware and reboot BMC
Switch to EMA in Platform Mode
Integrated Lights Out Management (LOM)
For login details, refer to Logging Into the BMC
Note
Not applicable to the SBC Software Edition (SWe).
SOAP API
SBC Core SOAP APIs provide access to Simple Object Access (SOAP) API which is protocol specification used to exchange structured
information in the implementation of web services. It uses XML information set for its message format, and usually relies on other application
layer protocols, such as Hypertext Transfer Protocol (HTTP) or Simple Mail Transfer Protocol (SMTP), for message negotiation and
transmission. The advantage of using SOAP is that it is very versatile and use different transport protocols. The standard stacks use HTTP as a
transport protocol.
The SBC SOAP API supports the following requests for each managed object:
CREATE – creates a managed object in the SBC.

UPDATE – updates a managed object in the SBC.
DELETE – deletes a managed object in the SBC.
SHOW– retrieves managed object details from SBC.
User defined operations – For example, manual switchover of the SBC.
The EMS application maps each SOAP request to the corresponding REST request towards the SBC. In network configurations where EMS is
deployed, the EMS is also used to configure SBC Core using SOAP API for SBC. This interface supports provisioning as well the operations
exposed by the yang models. For details, refer to the EMS document SBC SOAP API reference.
For access details, refer to Accessing SOAP API.
REST API
REST APIs provide access to REpresentational State Transfer (REST) API which is a simple, stateless architecture style (not a protocol) that
uses the HTTP/HTTPS method ( such as GET, PUT, POST, DELETE) to retrieve the management information from the database. The main
advantage is its simple interfaces and can be modified while the application is running.
REST has the following properties:
Stateless: No client context is stored on the server. A request from the client will contain all the necessary information required to
process the request.
Client-Server model: In a client-server model, clients are associated with the user interface, and the servers manage data storage behind
the interface. This allows a separation between the client and server.
Cacheable: Improvement in scalability and performance when the client caches responses.
Language–independent: REST API uses open standards. Any language may be used to access the API ( C++, Java, etc. ) resources via
URI paths.
To use a REST API, your application makes HTTPs requests and parses the responses. Currently, the only supported response format is XML.
The methods used by developers are standard HTTP methods such as GET, PUT, POST, PATCH and DELETE.
For access details, refer to Accessing REST API.
Insight EMS SBC Configuration Manager

If your network includes the Insight EMS platform, and the SBC is added as a managed node or is part of a managed cluster, you can access a
web-based management interface from the EMS. The SBC Configuration Manager application provides GUI configuration and management
options similar to what the EMA GUI provides. The SBC Configuration Manager is accessible under Node Management by navigating to the Nod
e Inventory, Registration and Other Functions window (Network > Node Management > Function Manager) and selecting the Configure
function for a node. The SBC Configuration Manager is also accessible under Cluster Management by navigating to the Configurations tab for
a cluster (Network > Cluster Management > Manage VNFs > Configurations) and clicking on the Edit Configure option. Refer to EMS
documentation for more information on node and cluster management.
A Note About SFTP

The SBC Core includes the utility /opt/sonus/bin/SbcSftp with permissions -rwsr-xr-x, which allows you to securely transfer files to a
remote server using the Linux shell.
When executed, the program SbcSftp:
Creates the necessary Access Control List (ACL) to allow the sftp connection from the SBC Linux shell to a remote server
Uploads/Downloads specified files to/from the remote server over a SFTP session, if the user has permissions to access the file
Deletes the ACL
The advantage of using SbcSftp over standard sftp is that SbcSftp automatically creates and deletes ACLs for accessing the remote server.
For details, refer to SbcSftp - Secure File Transfers with Automated ACL Creation and Deletion.
Logging Into EMA

HTTPS Support Logging Into the BMC
Logging In
Supported Browsers and Client Computers
Procedure
Last Login Information
Configuring a Banner in the Login Screen
Logging Out of EMA
Security Enhancement to Allow Only One Concurrent EMA
Session
HTTPS Support
The EMA GUI is available via TLS-secured (https) access either directly through port 443 or indirectly through port 80 to 443. ACL rules are not
applicable to prevent unsecured (http) access.
A sample X.509 certificate, which is a copy of the BMC and the EMA Platform Mode certificate, is shipped along with the SBC shipment. The size
of this certificate is 2,000 bytes.
Note
The BMC is not applicable to SBC SWe.
The EMA uses the common Local Cert store of the SBC Core (used also for SIP/TLS) rather than having its own separate certificate store. The
operator may replace that sample certificate at any time. The replacement mechanism is implemented with post installation/upgrade scripts.
Certificates with RSA keys up to 4,096 bits are supported.
Enter the following URL in the browser to access the SBC EMA:
https://<hostname>
where <host name> is one of the management IP addresses of the SBC, or the equivalent DNS name. For example, https://10.54.41.8.
EMA uses a self-signed certificate which may produce a warning message from Internet Explorer and Firefox. These messages may be ignored.
Note
The SBC Core is delivered with sample self-signed X.509 certificates. Be aware that even though these sample certificates will allow
you to use HTTPS to access the SBC from EMA, BMC and EMA Platform Mode interfaces, using this protocol with the sample
certificates is not a truly secure access method. If your organization requires more secure access, refer to Generating PKI Certificates.
Note
The SBC Core supports SHA-256 for certificate verification.
Logging In
Supported Browsers and Client Computers
Refer to for a list of supported browsers and client platforms for accessing EMA.
Procedure
To log into the Embedded Management Application (EMA):
1. Launch your web browser.

2. Enter the SBC EMA URL <ip address/device name>
Note
When using Internet Explorer/Mozilla Firefox browser, a website security issue may prevent you from going directly to the SBC
application login screen, as shown in example below.
Figure 1: Certificate Security Error
3. Click Advanced.
Figure 2: Firefox Message - Self-Certified Website
4. Click Add Exception.

Figure 3: Firefox Message - Add Security Exception
5. Uncheck the Permanently store this exception check-box and click Confirm Security Exception. The Login window appears as
shown below.
Login
6. Enter your Username and Password. Your username and password will be supplied along with the SBC installation package. Once you
have successfully logged into the SBC, your temporary password expires and you are prompted to change your password.
Note
This change password screen appears only for the first login of the new user.
Change Password
Ensure your new password meets the following criteria:
Minimum length of characters is 8.

Minimum number of upper case characters is 1.
Minimum number of lower case characters is 1.
Minimum number of numeric digits is 1.
Minimum number of special characters is 1.
Maximum number of consecutive repeating characters is 3.
Minimum number of differences compared to the old password is 4.
Do not repeat any of the last 4 passwords.
7. Once your password is successfully changed, enter your username and new password on the Login screen and click Log In.
Note
You can also change the password in EMA without logging in to the application. The option to change password is available
on the SBC Application login screen.
Your username and password are same as that for the CLI.
Last Login Information

When a user logs into either the CLI or EMA, information on the last successful and failed login attempts is displayed. The information shown
includes:
1. Last successful login date and time.

2. Last successful login IP address.
3. Last unsuccessful login date and time.
4. Last unsuccessful login IP address.
5. Number of failed attempts after successful login.
Note
Items 3, 4 and 5 display only when the last successful login date is older than the last unsuccessful login date. See the figure Login
Message - Previous Unsuccessful Attempts.
Note
The Last Login Information also displays for a new user for the first login. The new user is first authenticated and then allowed to
change the system-generated password.
Configuring a Banner in the Login Screen
1. On the main screen, navigate to Admin > Application Management. Click Banner chiclet on the left hand side of the page to display
the Configure Login Banner window.
2. Enable Show Login Banner option. You can request the user to acknowledge the Banner by enabling the Require User to
Acknowledge Banner before Logging in option and also, you can request the user to acknowledge every time they login or only during
the first login.
3. Add your banner text in the text box next to Banner Text option to display your Banner content.
4. Click Save to save your edits.
Logging Out of EMA

To log out of EMA:
Hover the mouse pointer over <your_username> on the menu bar. and click Log Out.
Log Out
Security Enhancement to Allow Only One Concurrent EMA Session

This security enhancement is available beginning with SBC Core version 06.02.00R000.
This enhancement enables the EMA application (including EMA in platform mode) to disable concurrent user sessions. Once a new session is
established, any existing session is terminated immediately. When an EMA user attempts to log in, the system checks for any open sessions with
the same username. If any existing user session is identified, that user is immediately logged out from the application and allows the new user to
log in to the system.
Note
This feature is applicable to all EMA users (local users, radius users, PKI certificate-based users, and CAC users).

CLI Modes
Logging In
Exiting the CLI
This section provides information on logging into and exiting the SBC command line interface.
Note
Up to 16 simultaneous CLI sessions are allowed.
Logging In
Perform the following steps to log into the SBC CLI:
1. Use PuTTY or another terminal emulator to connect to the SBC server on port 22.
2. At the login prompt, enter your login ID and password. The default login ID and password are “admin”.
login as: admin

admin@10.11.12.111's password: *****
A message similar to the following appears:
admin connected from 10.11.12.13 using ssh on sbx1.eng.example.com

Your last successful login was at 2013-8-22 11:45:1
Your last successful login was from 127.0.0.1
admin@server1>
As a security measure, the following information may display upon login depending upon user access activity against your system. In the
example above, items 1 and 2 display after a successful login.
admin connected from 10.11.12.111 using ssh on MYSBC

Your last successful login was at 2014-5-15 18:32:21
Your last successful login was from 10.11.12.111
Your last unsuccessful login was at 2014-5-15 18:33:7
Your last unsuccessful login was from 20.30.40.50
There was 1 unsuccessful login attempt after your last login
Note
Rows 4, 5 and 6 display only when logging in immediately after an unsuccessful login to serve as a warning about a possible
unauthorized attempt to access your system.
Exiting the CLI
To exit the CLI, type exit at the prompt. For example:
admin@MYSBC> exit
Depending upon the method you used to access the CLI, either a message similar to the following appears, or your terminal session closes.
Connection to MYSBC closed

Logging Into EMA

Launch the EMA Platform Application from the BMC GUI Logging Into the BMC
or Web Browser
Security Enhancement - SBC Allows Only One Concurrent
EMA Session
The EMA Platform is bundled with the ConnexIP OS package and is accessible through configured host management interfaces. This application
is available from a different port (port 444) from the default EMA service port. The EMA Platform handles activities like SBC application
installation and upgrade as well as host troubleshooting, and it contains other OS utilities.
The following are prerequisites to use your PC to launch the EMA Platform:
The PC must support Windows XP or later

The PC must support one of the following browsers:
Internet Explorer (IE): Versions 9, 10, and 11
Mozilla Firefox: Version 31 and above
Google Chrome: Version 32 and above
The PC must be installed with OpenJDK Runtime Environment 6 update 19 or later to support the OpenJDK console
Note
The SBC is delivered with sample self-signed X.509 certificates. Be aware that even though these sample certificates allow you to use
HTTPS to access the SBC from the EMA Platform, BMC and EMA interfaces, using this protocol with the sample certificates is not a
truly secure access method. If your organization requires more secure access, refer to Uploading New SSL Certificates using SBC
7000 BMC for instructions on uploading replacement SSL certificates to meet your organization's security requirements.
Launch the EMA Platform in one of two ways:
a. From the BMC GUI

b. From a web browser – Enter https://<mgtport_ip>:444 in a Web browser, where <mgtport_ip> is the management
port IP address.
Note
The BMC GUI is not applicable to the SBC Software Edition.
Launch the EMA Platform Application from the BMC GUI or Web Browser
1. Perform either step a or b to launch the EMA Platform from either BMC GUI or a Web browser, respectively.
a. From BMC GUI menu bar, click the Platform Manager Port 0 or Platform Manager Port 1, as shown in Figure 1.
Note
On the Platform Manager, "Port 0" is associated with the MGMT0 port interface and "Port 1" is associated with
MGMT1 port interface.
Note
This method is not applicable for SBC SWe.
Figure 1: BMC Main Screen
b. Type https://<IP Address>:444 into a web browser and press Enter.

where, <IP Address> is the default management interface IP address. The EMA Platform Login dialog displays similar to the
figure below.
Figure 2: Login Screen
2. Login to the EMA Platform using default credentials:
Username: admin
Password: admin
Note: If you provide incorrect login credentials, an error message is displayed.
3.
3. The EMA Platform main screen similar to the figure below.
Figure 31: Platform Manager Main Screen
Note
If you log into the EMA Platform Mode when an installation procedure is being carried out, you see the following message:
"SBC Application Install in progress. Navigate to Administration > Software Install/Upgrade to view status"
4. Navigate to Monitoring Dashboard System and Software Info. This screen displays system information and SBC software details.
Figure 42: System Information
Security Enhancement - SBC Allows Only One Concurrent EMA Session

This security enhancement is available for SBC Core version 07.00.00R000 onward.
This enhancement enables the EMA application (including EMA in Platform Mode) to disable concurrent user sessions. Once a new session is
established, any existing session is terminated immediately. When an EMA user attempts to log in, the system checks for any open sessions with
the same username. If an existing user session is identified, that user is immediately logged out from the application, allowing the new user to log
into the system.
Note
This is applicable for all EMA users (local users, radius users, PKI certificate-based users, and CAC users).
Procedure
Perform the following steps to log into the Baseboard Management Controller (BMC) GUI:
1. Enter the BMC IP address in a web browser address bar.

2. At the login prompt, enter the BMC login ID and password. The default login/password is root/superuser.
Figure 1: BMC Login Prompt
3. If an incorrect password is entered, an "Invalid Authentication" message is displayed. After four unsuccessful attempts, the user ID is locked.
If this occurs, try to log in after 60 seconds.
4. After a successful login, the BMC window opens to the Dashboard, as shown in the following example.
Figure 2: BMC - System Information Tab
Brute-Force Attacks
To guard against brute-force attacks to the BMC, after four unsuccessful login attempts a user account is disabled for both SSH and Web UI logins.
Note that the number of unsuccessful login attempts equals the sum of both SSH and WEB UI login attempts. For example, if two unsuccessful
attempts are made from SSH and two from the WEB UI, the user account is locked by the server. This action is recorded in an appropriate event log.
The server automatically unlocks the user account after 60 seconds, whereby a user can reattempt to log into the BMC.
For more information, refer to:
Changing the BMC Password

Upgrading the BMC and BIOS Firmware
Accessing SOAP API
To access SOAP API, do the following:
1. Download the Javadoc file (sbc_api_doc_vxx_yy_zz.zip) on to your local system or local server.
2. Unzip to extract all the files.
3. Click on index.html file to get all the information about the various entities and operations.
For more information, refer to the "SBC SOAP API reference" in Insight EMS documentation.
Accessing REST API
Note
Beginning with SBC Core Release 11.01.00, REST API is deprecated and replaced with RESTCONF API.
This section provides information on logging into the SBC REST API.
Perform the following steps to login to SBC REST API:
1. Create a new user or use existing admin user.
2. If the password is not reset, then reset the system-generated password using CLI or EMA.
3. In /system/admin/{SYSTEM_NAME}/rest/state, set the rest state to 'enabled'.
4. In /oam/localAuth/user/{USER}/m2mAccess, set the m2mAccess to 'enabled'.
Note
Use CLI, EMA or REST API to perform steps 3 and 4.
5. Verify REST API access using the command:
curl -kisu admin:xxxx https://10.54.153.148/api/
If the access is successful, response to the above command will be ' 200 OK'.
Refer to SBC Core REST API for SBC 5400/7000/SWe REST API documentation.
First Steps
The following pages provide summaries of the key steps needed to get your SBC Core up and ready for provisioning.

Congratulations on receiving your SBC Core system!
Below is a summary of key steps needed to get your SBC up and ready for provisioning.
1
Create an IP plan
An IP plan helps you to gather configuration details, such as the IP addresses that the SBC Core will use for its management ports,
media ports and its next hop router. The media ports are used for SIP and RTP traffic.
For help with completing an IP Plan, see Creating an IP Plan.
2
Install the Hardware
For step-by-step instructions, see the appropriate page:
Installing SBC 5400 Hardware

Installing SBC 7000 Hardware
3
Configure the Field Service Port and Management Port IP address
The Field Service Port (FSP) is an Ethernet port located on the back of the SBC. This port allows you to access the SBC Baseboard
Management Controller (BMC) web page.
The BMC allows for system monitoring, power control, and configuring the Management Ports of the SBC. For step-by-step
instructions, see the appropriate page:
SBC 5400 - Configuring the Platform

Configuring the SBC 7000 Platform
4
Install SBC Application software
See Installing SBC Application for step-by-step instructions.
5 Install licenses
See Node-Locked Licensing for license descriptions and usage.
See System Administration - License Management to install license bundle files from the EMA UI.
6 Configure your system

You are now ready to configure your SBC for processing!
A large amount of information is needed to configure your platform. Use the Creating an IP Plan to help manage this information.
If you would like to set up a basic call flow to test your configuration, see How to Set up a Basic Call Flow.

Unable to render {include} The included page could not be found.
The following is a summary of key steps to get your SBC Software Edition (SWe) system up and ready for provisioning.
1 Create an IP plan
An IP plan helps you to gather configuration details, such as the IP addresses the management port, HA port and two media ports for
the SBC SWe virtual machine (VM). The media ports are used for SIP and RTP traffic.
Refer to Creating an IP Plan for SBC SWe on VMware or KVM Hypervisor for help with completing an IP plan.
2 Configure your SBC SWe environment

Before creating a VM and installing the SBC SWe software, you must create the virtual environment on the host or hosts allocated for
the SBC SWe.
To get started, refer to the page applicable to your environment:
VMware: Configuring Your Network for SBC SWe on VMware

KVM: Creating and Linking Network Bridge
3 Create a VM for the SBC

This step involves creating a VM and allocating resources, and configuring a datastore to contain the operating system (OS) and
application software.
Refer to the page applicable to your environment:
VMware
Creating Virtual Machine using vNetwork Standard Switch (vSwitch)
Creating Virtual Machine using vNetwork Standard Switch (vSwitch) in VMware ESXi Web Client
Creating Virtual Machine using vSphere Distributed Switch
KVM
Creating a New SBC SWe Instance on KVM Hypervisor
Creating a New SBC SWe Instance with PCI Pass-Through Device
4 Install the SBC application

Refer to the page applicable to your environment for step-by-step instructions to install the SBC application from the Embedded
Management Application (EMA):
Installing SBC Software on VMware

Installing SBC SWe on KVM Hypervisor
5 Install the License file

Install SBC licenses using the EMA. Refer to System Administration - License Management and Node-Locked Licensing for details.
6 Configure your system

You are now ready to configure your SBC SWe system for traffic!
A large amount of information is needed to configure your platform. Use the IP plan you created in step 1 to help manage this
information.
To set up a basic call flow to test your configuration, refer to How to Set up a Basic Call Flow.

SBC SWe systems can be deployed in the OpenStack environment using either Heat templates or the Ribbon Virtual Network Function Manager
(VNFM). Use the following links to see an overview of the steps required for each method.
Steps for SBC SWe Instantiation on OpenStack using Heat Templates

Steps for SBC SWe Instantiation on OpenStack using VNFM
About SBC Documentation
In this section:
Wiki Search Syntax

How to Search for Information in Online Documentation
Global search box
Product documentation landing page
Documentation outline
Space search
Keyboard CTRL+F shortcut
Safety Symbols
This section provides an introduction to the SBC Core consisting of the SBC 5400 series, SBC 7000 and SBC Software Edition product lines.
Information provided in this section includes key features, the SBC architecture and your first steps to accomplish to get started quickly with
configuring your SBC platform.
For an online list of Ribbon product acronyms, see .
Wiki Search Syntax

Click to learn more about using Wiki search syntax.
How to Search for Information in Online Documentation

There are five basic methods to search for product information in the online documentation portal.
Global search box

Space search
Global search box

Use the global search box to search for a subject across all Ribbon online product documentation.
Global Search Box
The product documentation landing pages provide a brief description of each major section as well as a listing of each immediate page under
those sections. Click on a link to go directly to the page.
Landing Page
The documentation outline is located on the left sidebar. Expand or collapse a section by clicking the plus/minus controls.
Documentation Outline
Space search
Use this search box to search for terms within the current product documentation space.
Click for an online list of Wiki search syntax.
Space Search
Type CTRL+F key combination when searching for a specific phrase on a page. A search box displays at the bottom of the page. Enter your
phrase, and then click the up or down arrow to cycle through each occurrence of the phrase. Other choices next to the search box include
"Highlight All" to highlight every occurrence of the phrase (as shown in example below) and "Match Case" to match the case as entered.
Note
Functionalities may differ depending on the browser being used.
CTRL+F Search
For a comprehensive list of Ribbon product acronyms, see online page.
Safety Symbols
The following Electrostatic Discharge (ESD) symbols are used throughout the documentation.
ESD Protective symbol identifies ESD protection devices, such as wrist straps, anti-static bags, etc.
ESD Susceptibility symbol warns of the presence of Ribbon devices susceptible to electrostatic discharge. Do not handle
equipment without wearing a properly grounded ESD wrist strap.
In this section:
What is an SBC?
Session
Border
Controller
Ribbon SBC Portfolio Components
SBC Core Architecture
What is an SBC?
A Session Border Controller is a special-purpose device that protects and regulates IP communications flows. As the name implies, session
border controllers are deployed at network borders to control IP communications sessions. Originally conceived to protect and control VoIP
networks, SBCs are now used to regulate all forms of real-time communications including VoIP, IP video, text chat and collaboration sessions..
Session
Border
Controller
Session
An SBC “Session” license unit is defined as a point-to-point conversation, two legs of a call, and is represented by a single Global Call ID (GCID).
Each session used decrements an official Ribbon License. When call transfers are processed using SIP REFER, even though two GCIDs are
created for the original and transferred call, the SBC uses only one Session license for the session.
A call leg is a single connection between the SBC and another device. A session between two devices includes a call leg between device A and
the SBC, and a call leg between the SBC and device B.
A call may require a single session or it may require multiple sessions resulting from call forking, conference call, call transfer, call recording or
other mechanisms. For example, a call between two registered users through a feature server consumes two sessions: one session from User A
to the Feature Server and one session from the Feature Server to User B.
The total number of concurrent sessions supported on the SBC platform may be limited by different factors, including:
Available Bandwidth – For calls with pass-through media, the SBC computes the media bandwidth required for each call leg, and
determines if there is sufficient bandwidth available to host the call. Calls exceeding the bandwidth limit of the interface are rejected.
Call Rate – If the incoming call rate exceeds the rated capacity of the platform, calls are discarded to protect the system from overload.
The number of concurrent sessions required is directly related to the Call Rate and the Call Hold Time (CHT). High call rates with a low
average CHT value will result in fewer sessions than the same call rate with a high average CHT value.
System Limits – Each platform includes upper limits on the number of sessions supported. For example, the SBC 5400 with 10GE
interfaces supports a maximum of 75,000 sessions.
License Limits – The SBC is licensed for the maximum number of sessions desired. However, the license limit may be less than what
the bandwidth, call rate or system limits support. Any call that exceeds the licensed limit of the SBC platform are rejected.
Example #1: Call with one Session

A customer has purchased a 5,000 package of licenses, calls are coming in and egressing the SBC with no call forking – so each ingress and
egress is one session. The maximum number of active calls is 5,000.
Figure 1: Call with one session
Example #2: Call with two Sessions
A customer has purchase a 5,000 package of licenses. Calls are coming in and getting transferred back through the SBC. Each call consists of
two sessions, so the maximum number of simultaneous active calls is 2,500.
Figure 2: Call with two sessions
Note
For multiple call transfers using SIP REFER, even though two GCIDs are created for the original and transferred call, the SBC uses
only one Session license for the session.
Border
Typically, these sessions will traverse one or more IP networks, whether on an enterprise network or multiple service provider networks. The SBC
sits at the border of each network in order to control the amount and type of sessions, as well as the type of data that can be used during these
sessions. In this sense the SBC is part firewall, protecting the network from malicious IP traffic, and part traffic cop, policing how much traffic can
enter the network in order to prevent overloads.
Controller
The SBC is a controller, which means it controls not only whether traffic can enter the network, but where it should be sent (referred to as
session routing) and what type of modifications should be made to the traffic (example, transforming a SIP message header into an H.323
message header or downgrading an HD voice call to a compatible voice codec).
Ribbon SBC Portfolio Components

The Ribbon SBC Portfolio is comprised of the following Session Border Controller products:
SBC Edge Portfolio
SBC 1000/2000
SBC SWe Edge
SBC CNe Edge
SBC Core
SBC 5400
SBC 7000
SBC Software Edition (SWe)
SBC SWe Cloud
The focus of this documentation space is on the SBC Core platforms. To view SBC Edge Portfolio product documentation, navigate to
the SBC Edge Documentation landing page.
The SBC Core addresses the next-generation needs of SIP communications by delivering embedded media transcoding, robust security and
advanced call routing in a high-performance, small form-factor device 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).
The SBC Core provides a reliable, scalable platform for IP interconnect to deliver security, session control, bandwidth management, advanced
media services and integrated billing/reporting tools in an SBC appliance. This versatile series of SBCs can be deployed as peering SBCs,
access SBCs or enterprise-SBCs (e-SBCs). The SBC product family is tested for interoperability and performance against a variety of third-party
products and call flow configurations in the customer networks.
The SBC Core can be further expanded to:
SBC 5400
Targets medium to large session count deployments (700 to 75,000). These capacities make this product particularly well suited for large
enterprises and medium to large service providers.
SBC 7000
Targets large session count deployments (up to 150,000 sessions). These capacities make this product particularly well suited for large
service providers. Example deployment scenarios include:
Service Provider Access – High subscriber and simultaneous call scale coupled with high availability and redundancy.
Service Provider Peering – High simultaneous call scale coupled with high availability and redundancy.
Enterprise and Service Provider Video – Supports large WAN interface bandwidth.
Wireless – Supports a large number of subscribers and calls where high availability is essential.
SBC Software Edition (SBC SWe)

Targets small to large session count deployments (25 to unlimited). These capacities make this product particularly well suited for small
to large enterprises and service providers. SBC SWe application resides on a private or public virtualized cloud, or on a dedicated server.
Ribbon offers different SBC personalities on the SBC SWe platform, as summarized below:
I-SBC: "Integrated SBC" with signaling, media, and (optional) transcoding functionality within a single node. An SBC instantiated
without a personality type defaults to I-SBC. This personality type is analogous to the SBC Core hardware platforms.
D-SBC: "Distributed SBC" refers to the architecture where the signaling, media, and (optional) transcoding functions are handled
by dedicated SBC nodes or clusters, and includes the personalities below:
S-SBC: "Signaling SBC" in a distributed SBC deployment. An SBC must be instantiated with the Signaling "personality"
to behave as an S-SBC.
M-SBC: "Media-handling SBC" in a distributed SBC deployment. An SBC must be instantiated with the Media
"personality" to behave as an M-SBC.
T-SBC: "Transcoding-handling SBC" in a distributed SBC deployment. T-SBC is a special case for an M-SBC.
"Transcoding-handling" requires specific configuration settings, but not a completely distinct "personality." Only
an M-SBC can be configured as a T-SBC.
SO-SBC: "Signaling Only SBC" is not an SBC personality, but denotes a configuration setting dedicated to handling signaling
only. Either an I-SBC or an S-SBC can be configured as an SO-SBC, which is the primary difference between S-SBC and SO-
SBC.
SBC Core Architecture

This following pages detail the SBC Core and SBC SWe architectures:

In this section:
High Level Architecture

Basic Configuration Objects
Address Context
IP Interface
IP Interface Group
Physical Port
Zone
SIP Signaling Port
Trunk Groups
Profiles
Packet Service Profile
Codec Entry
IP Signaling Profile
IP Peer
Global Call Routing
Routing Label
Route
This section describes the high-level SBC Core application architecture and the primary configuration objects.
High Level Architecture

This diagram depicts the high-level SBC Core application architecture and describes the configuration objects used when creating a basic call
flow, such as Address Contexts, Packet Service Profiles, IP Signaling Profiles, Trunk Groups, Signaling Ports, Routes and Interfaces.
High-Level Architecture
Basic Configuration Objects

This topic describes the basic SBC Core configuration objects including CLI command syntax and examples.
For a complete listing of configuration objects, see the CLI Reference Guide or EMA User Guide.
Address Context
An address context includes all objects associated with a particular IP address space. This includes IP packet interface groups, zones, as well as
the contents of each of these objects. In a "flat" IP address space such as the public IP address space, only the single "default" address context
is necessary. Additional address contexts are only needed to accommodate overlapping local IP addresses (e.g., the same IP addresses used in
multiple networks connected to the same SBC).
A default address context implicitly includes the management interface group and its contained management interfaces. These interfaces are
considered "trusted" network interfaces.
Command Syntax
% set addressContext <addressContext name>

diamNode
dnsGroup
intercept
ipAccessControlList
ipInterfaceGroup
ipsec
linkDetectionGroup
natDirectMediaGroup
rtpServerTable
staticRoute
zone
Example
The below rule blocks all traffic that is not explicitly allowed:
% set addressContext default ipAccessControlList rule DENYALL_UNTRUST precedence 65015 ipInterfaceGroup

EXTERNAL.IPIG action discard
IP Interface
An IP Interface represents an IP address assigned to a physical port in the system. An IP Interface is associated with an IP Interface Group, and
may contain a VLAN tag. VLAN tags are required if more than one IP Interface is associated with a single physical port on the SBC.
Note
The SBC 7000 system supports creating IP Interface Groups containing sets of IP interfaces that are not "processor friendly" (i.e.
carried on physical Ethernet ports served by separate processors). However, restrictions exist regarding the usage of such Interface
Groups.
(This ability does not apply to the SBC 5400 system which have only two physical media ports. IP interfaces from the two physical
ports may be configured within the same IP Interface Groups without restrictions.)
For complete details, refer to Configuring IP Interface Groups and Interfaces.
IP Interface Group
An IP Interface Group is a named object and contains one or more IP interfaces (IP addresses). An IP Interface Group is Address Context
specific, and is permanently bound to a particular Address Context.The service section of an IP trunk group, and a Signaling Port will reference
an IP Interface Group typically for purpose of restricting some sort of activity to that IP Interface Group (signaling and media respectively).
Physical Port
A Physical Port (four ports for SBC 5400 and SBC 7000) is independent of Address Context. If using VLAN tags, a port may carry multiple IP
Interfaces in the same or different Interface Groups or Address Contexts. MAC addresses are assigned on a per-Port basis.
The first IP Interface assigned to a port determines if VLAN tagging is used or not. If a VLAN tag is used on the first IP Interface associated with a
port, all IP Interfaces for that port must have VLAN tags.
Zone
Zone
A Zone groups a set of objects (for signaling and call routing information) for a particular Address Context (customer environment). A zone is
permanently bound to a particular Address Context, and is normally allocated per customer, per carrier, per organization or per service level
associated with one of the above groups. When configuring a zone, include zone name and ID as indicated below.
Zone objects include:
Call Admission Control

DNS Group
SIP Signaling Port/H.323 Signaling Port/ GW Signaling Port
SIP/H.323/Gateway Trunk Group
IP Peer (Signaling Endpoints)
Message Manipulation
Remote Device Type
For hardwar appliances, up to 2,048 zones (SBC 5400) and 4,000 zones (SBC 7000) are configurable. The SBC SWe supports 129 zones
("small" profile) or 4,000 zones ("large" profile). A zone may reference other objects within the address context such as interface groups, DNS
server groups, etc. While these objects may only be used by one customer, the SBC allows them to be shared among customers so they are
configured outside the zone.
The zone may also reference global objects such as call routing labels and call routes. Again, even though some global objects may only apply to
one customer, the SBC allows global objects to be shared among customers so they are configured outside the zone.
For comprehensive provisioning limits, see SBC Provisioning Limits.
Example
The following example sets an Address Context "default" to Zone "peer" with an ID of "2".
% set addressContext <addressContext_name> zone <zone_name>

cac
dnsGroup
gwSigPort
gwTrunkGroup
h323SigPort
h323TrunkGroup
id
ipPeer
messageManipulation
remoteDeviceType
sipSigPort
sipTrunkGroup
% set addressContext default zone peer id 2
SIP Signaling Port

A SIP Signaling Port is a logical address permanently bound to a specific zone and is used to send and receive SIP
call signaling packets. A SIP Signaling Port is capable of multiple transports such as UDP, SCTP, TCP and TLS/TCP.
SBC Core supports up to 16 SIP Signaling Ports per zone. These SIP Signaling Ports can use the same IP address,
but each must have its own unique UDP/TCP port. In the example below, three SIP Signaling Ports are created using
the same IP address but each with a unique UPD port.
SIP Signaling Port 1: 100.110.120.130 port 5060

A SIP Signaling Port can contain an IPv4 address, an IPv6 address or both. However, all SIP Signaling Ports within a
particular zone must use the same address types as shown in below examples.
Example 1:
SIP signaling port 1 - IPv4 address
Example 2:

Example 3:
SIP signaling port 1 - IPv4 / IPv6 addresses

SIP signaling port 2 - IPv4 / IPv6 addresses
A SIP Signaling Port must reference one IP Interface Group signifying that signaling associated with that port is
restricted to IP Interfaces in that group. Only reference IP Interface Groups within the same Address Context.
Command Syntax
% set addressContext <addressContext_name> zone <zone_name> sipSigPort <sipSigPort index>

dscpValue
ipAddressV4
ipAddressV6
ipInterfaceGroupName
mode
portNumber
recorder
sctpProfileName
state
tcpConnectTimeout
tlsProfileName
transportProtocolsAllowed
Example
This example sets the address context "default" to include a zone "core" with an ID of 3, a SIP signaling port set to 2, and an IP interface group
"IPIG1."
% set addressContext default zone core id 3 sipSigPort 2 ipInterfaceGroupName IPIG1 ipAddressV4 100.110.11.10
state enabled
Trunk Groups
The SBC autonomously manages calls to and from its signaling peers through Trunk Groups. Trunk groups enable the SBC to provide call
management functions (services processing, routing, call admission and accounting, reporting, etc.) for packet-to-packet communications.
Trunk groups are also used for call management between SBC within a carrier's network (known as SIP Trunk Groups in the core) as well as
between SBCs in a carrier's core VoIP network and outside VoIP devices (SIP Trunk Groups at the network edge). These other VoIP devices are
either under the carrier's administrative control or reside within the network of a packet peering partner.
The SBC signaling and routing is based on SIP and H.323 trunk groups. For SIP trunk groups, the following applies:
There can be multiple SIP trunk groups per Zone.

A single SIP trunk group can represent a group of peer devices (endpoints).
An Ingress SIP trunk group is selected by matching the layer 3 address on a signaling peer to any entry in an Ingress IP Prefix table
associated with the trunk group. This table is provisioned when building the trunk group.
As a best practice, always use UPPERCASE for trunk group names.
Note
Trunk group names must be unique across all address contexts, zones, and trunk group types.
Also, IP peer names must be unique across all address contexts, and zones.
Command Syntax
% set addressContext <addressContext_name> zone <zone_name> sipTrunkGroup <TG_NAME>

action
cac
callReservation
callRouting
congestionHandling
downstreamForkingSupport
dryUpTimeout
ingressIpPrefix
media
mode
packetOutage
parentSharedCacLimitsPoolName
policy
qoe
services
recordingDNpreference
signaling
state
ucidSupport
Example
This example creates a core SIP trunk group:
% set addressContext default zone core sipTrunkGroup CORE media mediaIpInterfaceGroupName IPIG1
Profiles
A Packet Service Profile (PSP) contains a list of up to four codec entries using ERE, and defines various parameters associated with voice
packet traffic between SBC and any IP-based remote device.
Note
The PSX supports configuring up to 12 codecs in the Packet Service Profile and Preferred Packet Service Profile. The SBC supports
receiving all 12 codecs from the PSX in the PSP and Preferred PSP. This applies to interworking with an external PSX (Advanced
ERE deployment scenario). See Routing and Policy Management for deployment scenario details.
Additionally, the SBC supports up to 12 codecs over Gateway links to SBCs and/or GSXs.
Note
An SBC-POL-RTU license is needed to enable more than four codecs.
The SBC makes appropriate negotiations and transcoding decisions based on PSP information. PSPs for voice packet traffic between a SBC and
a remote device are provided to the SBC by the Embedded Routing Engine (ERE) or external PSX as part of the Policy Response.
IP trunk groups are each assigned a PSP used for all calls (in or out) on that trunk group. The default PSP is G711 only (no transcoding).
Packet Service Profiles control the following trunk group media settings:
Codec
Packet Size
Transcoding options
Fax support
Command Syntax
% set profiles media packetServiceProfile <packetServiceProfile name>
aal1PayloadSize
codec
dataCalls
flags
honorRemotePrecedence
mediaPacketCos
packetToPacketControl
peerAbsenceAction
preferredRtpPayloadTypeForDtmfRelay
rtcpOptions
secureRtpRtcp
sendRoutePSPPrecedence
silenceFactor
silenceInsertionDescriptor
t38
typeOfService
videoCalls
voiceInitialPlayoutBufferDelay
Example
This example sets a media profile with a Packet Service Profile named "PSP" that uses a Silence Factor of "40", Type of Service "0", Voice Initial
Playout Buffer Delay of "10", Aal1 Payload Size of "47", Preferred RTP Payload Type for DTMF Relay of 128, Media Packet COS of 0 and Honor
Remote Precedence disabled.
% set profiles media packetServiceProfile PSP silenceFactor 40 typeOfService 0 voiceInitialPlayoutBufferDelay

10 aal1PayloadSize 47 preferredRtpPayloadTypeForDtmfRelay 128 mediaPacketCos 0 honorRemotePrecedence disable
Codec Entry
A Codec Entry object describes a specific codec that can be offered as part of the Packet Service Profile. Several default Codec entries are pre-
configured on the system, and are a good starting point when creating your own. It is recommended to name your Codec Entries in a descriptive
manner for easy selection during PSP creation or modification.
Codec Entry key fields:
Codec — the actual codec to be used

Packet Size — the size of each RTP voice packet, in milliseconds
Law — (G.711 only) A-law, u-law, derived from other leg
DTMF Relay method — RFC2833, in-band or out of band
Command Syntax
% set profiles media codecEntry <codecEntry_name>

codec
codingRate
dtmf
fax
law
modem
packetSize
preferredRtpPayloadType
sendSid
For complete command syntax, refer to the CLI Reference Guide.
Example
This example creates G711u_20ms_2833_T38 a G.711u entry for internal side that uses 20 ms and 2833 only.
% set profiles media codecEntry G711u_20ms_2833_T38 codec g711 packetSize 20 law ULaw
% set profiles media codecEntry G711u_20ms_2833_T38 dtmf relay rfc2833 removeDigits enable
IP Signaling Profile
IP Signaling Profiles control how various SIP egress and ingress parameters are set and processed by specifying the parameters associated with
H.323, SIP, and SIP-I communication sent as part of the outgoing signaling messages after applying standard protocol rules.
You may associate IP signaling profiles with IP trunk groups and virtual trunk groups. A unique profile must be used for each type of destination.
A default IP Signaling Profile, "DEFAULT_SIP", is available for use. If changes are required, rather than modifying the default profile, create a
new IP Signaling Profile.
A trunk group has both an IP Signaling Profile and an Egress IP Signaling profile. The Egress IP Signaling profile is used for outgoing signaling
(sent from the trunk group).
Command Syntax
% set profiles signaling ipSignalingProfile <unique_identifier>

commonIpAttributes
egressIpAttributes
ingressIpAttributes
ipProtocolType
Example
% set profiles signaling ipSignalingProfile DEFAULT_SIP commonIpAttributes callTransferFlags

forceReRouteViaPsxQuery enable
IP Peer
IP Peer is the IP address of the far-end device, and is permanently bound to a particular Zone. The primary purpose of this object is to facilitate
outbound call routing. An IP Peer is referenced in the routing label, and is used for outgoing calls for a particular trunk group. For inbound calls,
the set of IP Peers associated with the give Zone is searched using the peer IP address as the key.
For access configurations, one IP Peer is assigned to the feature server, not for each individual phone. If you define an IP Signaling Profile in the
IP Peer (policy subsection), it overrides the profile defined in the trunk group.
Command Syntax
% set addressContext <addressContext> zone <zone> ipPeer <ipPeer_name>

defaultForIp
ipAddress
ipPort
pathCheck
policy
sip
surrogateRegistration
Example
This example binds IP Peer "core_peer" to zone "core" and assigns IP address 111.100.11.1 to it with port 5060.
% set addressContext default zone core ipPeer core_peer ipAddress 111.100.11.1 ipPort 5060
Global Call Routing

Routing Label
A Routing Label consists of a set of routes and gateway/trunk group pairs. The Routing Label sends traffic between two trunk groups. One
Routing Label is created for each trunk group, and is used to send calls to that trunk group.
Command Syntax
% set global callRouting routingLabel <routingLabel_name>
action
overflowNOA
overflowNPI
overflowNumber
routePrioritizationType
routingLabelRoute
script
Example
This example sets routing label "TO_PEER" to send calls to trunk group "PEER".
% set global callRouting routingLabel TO_PEER routingLabelRoute 1 trunkGroup PEER ipPeer PEER inService
inService
Route
A Route is used to determine how call routing on SBC is accomplished. There are various ways to implement routing, such as:
Dialed number
Carrier
Calling number
Trunk group
Command Syntax
% set global callRouting route <routingType>
Example
In this example, a trunk group route is set to send calls arriving on trunk group "PEER" to Routing Label "TO_CORE" which routes call to "CORE"
trunk group.
% set global callRouting route trunkGroup PEER DALNBS01 standard Sonus_NULL 1 nationalType nationalType ALL
none Sonus_NULL routingLabel TO_CORE

Deployment Environments
Redundancy Models
Distributed SBC Architecture
SBC Personalities
Deployment Models Currently Supported by SBC SWe
The Ribbon SBC Software Edition (SWe) is the virtualized version of the Ribbon Session Border Controller (SBC). As a software-based
application, the SBC SWe decouples SBC features and functionality from proprietary hardware and greatly expands the options for where and
how the SBC is deployed. This article provides an overview of some key characteristics that contribute to the wide range of SBC SWe
deployment models.
Deployment Environments
In contrast to installation on dedicated SBC hardware, the SBC SWe software runs as a virtual machine (VM) or as a virtual network function
(VNF) in a variety of virtualized environments. The software-based nature of SBC SWe enables great flexibility in network design. Operators
select the environment and determine the number and size of SBC SWe instances, or nodes, they need to meet their requirements. Working with
virtual instances, an operator can readily adapt the deployment capacities by creating or tearing down SBC SWe nodes as their requirements
change. You can deploy the SBC SWe in the following environments:
On a dedicated server: Deploy the SBC SWe as a VM on commercial off-the-shelf (COTS) hardware equipped with a hypervisor, such
as a VMWare vSphere ESXi or KVM environment.
In a private cloud: Deploy the SBC SWe as a VNF in an enterprise’s private cloud infrastructure, such as an OpenStack cloud
environment.
In a public cloud: Deploy the SBC SWe as a VNF in a public cloud environment such as Amazon Web Services (AWS), Google Cloud
Platform (GCP) and Azure.
Redundancy Models
Hardware-based SBCs provide redundancy when deployed in a 1:1 high-availability (HA) configuration. The SBC SWe supports the 1:1 HA
model, but also supports an N:1 HA model in which N (up to 4) active nodes are backed up by a single standby node. The characteristics of
these redundancy models are summarized below:
1:1 HA – A single active SBC node is backed up by a single standby node. The active SBC node holds the active configuration for the
pair and replicates configuration changes to the standby node so the nodes stay in sync. If an EMS is included in the deployment it
provides a repository to store the configuration history for the pair.
N:1 HA – In an N:1 deployment, multiple nodes (up to 4) are active at the same time and the active nodes are backed up by a single
backup node. A 1:1 HA pair of dedicated Operations, Administration, and Maintenance (OAM) nodes is required in the deployment to
configure and manage SBC N:1 HA nodes. An EMS is required in the deployment to store the configuration history for the SBC cluster.

The traditional Integrated SBC (I-SBC) architecture provides all the services associated with an SBC – call processing, media policing,
transcoding, signaling normalization, and so on – within a single node. Hardware-based SBCs support the integrated SBC model.
The SBC SWe also supports a Distributed SBC (D-SBC) architecture that separates the signaling, media, and (optional) transcoding functions
and implements them on separate node clusters. Clusters communicate with each other by means of a control protocol to jointly provide the full
set of SBC services. Separating the services enables flexible scaling of the functional components to meet the specific requirements of a
deployment. Refer to Distributed SBC Architecture for more information.
SBC Personalities
The SBC SWe supports a range of different deployment models and requirements. Some of these variations are referred to as specific SBC
"personalities" from a node instantiation standpoint, while other variations are special use cases of other personalities. Terminology related to
SBC personalities is explained below:
I-SBC: "Integrated SBC" with signaling, media, and (optional) transcoding functionality within a single node. An SBC instantiated without
a personality type defaults to I-SBC. This personality type is analogous to the SBC Core hardware platforms.
D-SBC: "Distributed SBC" refers to the architecture in which the signaling, media, and (optional) transcoding functions are handled by
dedicated SBC nodes or clusters, and includes the personalities below:
S-SBC: "Signaling SBC" in a distributed SBC deployment. An SBC must be instantiated with the Signaling "personality" to
behave as an S-SBC.
M-SBC: "Media-handling SBC" in a distributed SBC deployment. An SBC must be instantiated with the media "personality" to
behave as an M-SBC.
T-SBC: "Transcoding-handling SBC" in a distributed SBC deployment. T-SBC is a special case for an M-SBC.
"Transcoding-handling" requires specific configuration settings, but not a completely distinct "personality." Only an M-
SBC can be configured as a T-SBC.
SLB: “SIP-aware front-end Load-Balancer” refers to a personality consisting of nodes that provide a public-facing front end for SIP traffic
targeting the SBC. In addition to providing load balancing for the back-end SBC nodes, the SLB architecture insulates the network from
making configuration updates in response to increases/decreases in nodes by providing a single IP address access point for traffic from
peers.
SO-SBC: "Signaling Only SBC" is not an SBC personality, but denotes a configuration setting dedicated to handling signaling only.
Either an I-SBC or an S-SBC can be configured as an SO-SBC, which is the primary difference between S-SBC and SO-SBC.
Deployment Models Currently Supported by SBC SWe

The following tables summarize the current support the SBC SWe provides for different combinations of deployment options and platforms.
The first table lists the redundancy models currently supported by different types of SBC nodes. In this table, the column for OAM nodes refers to
the OAM nodes themselves, not the nodes they are managing.
Table 1: Redundancy Model Support by Specific SBC Node Type
Redundancy
Model SBC Node Types
S-SBC M-SBC T-SBC I-SBC SLB OAM
1:1 HA Supported Supported Supported Supported Supported Supported
N:1 HA Supported Supported Supported Supported Not Supported N/A
The second table lists specific platforms and which types of SBC nodes can be deployed on each.
Table 2: Platforms Supporting Specific SBC Node Types
Current
Platform Support SBC Node Types
OAM
(For N:1 HA
S-SBC M-SBC T-SBC I-SBC SO-SBC SLB Deployments)
VMWARE vSphere /ESXi Supported Supported Supported Supported Supported Supported Supported
KVM Not Supported Not Supported Not Supported Supported Supported Supported Supported
Red Hat Virtualization (RHV) Not Supported Not Supported Not Supported Supported Supported Supported Supported
OpenStack Supported Supported Supported Supported Supported Supported Supported
AWS Not Supported Not Supported Not Supported Supported Supported Supported Not Supported
GCP Not Supported Not Supported Not Supported Supported Supported Supported Not Supported
Azure Not Supported Not Supported Not Supported Supported Supported Supported Not Supported
Note
The SBC SWe does not currently support "elastic cloud computing" environments.
Ribbon Distributed SBC Solution
SBC Redundancy Groups
Why Distribute the SBC?
In traditional real-time communication, voice sessions have a one-to-one relationship between signaling and media (S1:M1), either with or without
transcoding. A traditional, integrated signaling and media network element (integrated SBC, or I-SBC) effectively meets the requirements of this type
of session. I-SBCs often run on custom hardware and are scaled horizontally to provide a deployment its required capacity.
As services evolve to support multimedia sessions, the traffic becomes more dynamic. The next generation communication may have one session
with no media (S1:M0), or one session with multiple media (S1:Mn) relationships, with or without transcoding. Effective handling requires considering
the following three planes independently:
Signaling plane: for more IM presence status

Media plane: for video, MSRP, multiple streams per session
Transcoding plane: for transcoding / transrating / transizing of audio or video
Ribbon Distributed SBC Solution

The D-SBC architecture breaks the main SBC functions into separate services and assigns them to separate clusters. A cluster consists of multiple
discrete nodes supporting one main function, such as signaling or media, with all nodes providing the same service. A virtual environment supports
multiple clusters simultaneously, each providing a specific SBC function:
The S-SBC cluster terminates signaling and provides only DoS protection for signaling traffic.
The M-SBC cluster acts as a policer or rate limiter for media traffic.
The T-SBC cluster provides media inter-working or transcoding.
These clusters coordinate with each other and are linked by the S-SBC using the Ribbon Media Control protocol on a per-call basis. A cluster
contains one or more SBC redundancy groups (RGs).
SBC Redundancy Groups

An SBC redundancy group (RG) consists of one or more SBC SWe node instances. All the instances in an RG must have homogeneous resource
allocation, configuration and personality. All RGs in a cluster must be of the same SBC type (signaling SBC or media SBC), which dictates the
cluster type such as a signaling cluster or a media cluster.
Figure 1: D-SBC Deployment Model Example
Why Distribute the SBC?

The D-SBC architecture distributes functions throughout the network to utilize network resources effectively.
The advantages of decomposing include:
Flexibility to Scale: In an I-SBC all the components use the same hardware to service incoming calls on the SBC instance. But, in a
distributed SBC (D-SBC) each component can scale independently within its cluster depending on the traffic requirements.
Example: Signaling components can be scaled if the traffic requires high signaling such as presence without the media component.
Similarly, traffic with high media requirements, like video calls, can be served by instantiating more instances in the media cluster. Traffic
that needs high transcoding requires instantiating more instances in the transcoding cluster.
Service Chaining: The SBC includes functions such as call control, routing and policy, signaling normalization, IP firewall and policy, and
media transcoding (or trans-rating). Each component of the D-SBC logically provides one or more such functions instantiated in a cluster to
support scaling based on the traffic requirement. The signaling component of the SBC chains one or more such functions per call without
knowing the media cluster details.
Investment Protection: Reusing existing custom hardware for media interworking saves cost. Custom hardware can coexist with software
media components providing media inter-working services. Also, when required it is invoked as an external media server.
High Resilience with Low Media Latency: Geographically separated media clusters can be deployed closer to the edge of the network.
This results in switching media at the edge instead of backhauling to the core. This reduces media latency and backhaul costs with increased
quality of experience. The use of multiple media instances provides resiliency enabling selection of media service components from different
sites.

In this section:
Using RAF to Automate LCM
Using RAF to Automate LCM

Contents
Ribbon Automation Framework Operator

Ribbon Automation Framework Scripts
Ribbon Automation Framework Operator
In this section: Additional topics:
Selecting IaC or RAF to Upgrade SBC SWe

Overview
Installing SLB SWe on KVM Hypervisor
Prerequisites
Installing SLB SWe on VMware
Software Bundle
Setting up RAF Container
Overview
The Ribbon Automation Framework (RAF) provides Ansible® playbooks, Terraform modules, and Automation Operators that enable the
automation of lifecycle management (LCM), provisioning, and testing of Ribbon applications. You can integrate Ribbon provided Ansible
playbooks, Terraform modules, and Automation Operators into automation environments, or execute Ansible playbooks, Terraform modules, and
Automation Operators manually by updating a file with the required end state and applying that file.
Note
The Automation Environment and RAF's Role diagram includes the following terms:
Communication Service Provider (CSP)

Continuous Integration (CI)
Continuous Delivery (CD)
Lifecycle Management (LCM)
Automation Environment and RAF's Role
Note
This section does not cover Provisioning and Testing.
The APIs and technology that implement the Ansible playbooks, Terraform modules, and Automation Operators depend on the application and
the automation domain (see the following figure).
RAF Automation Domains and Technologies
The Automation Operators encase the automation tools and steps in a container that executes in any container execution environment. RAF
Automation Operators provide the APIs to deploy and manage your Ribbon application. A unique Automation Operator container and supporting
documentation exist for each application and infrastructure combination (for example, the SBC Core 10.00.00R00 release for AWS). The
following figure illustrates the Automation Operator.
Automation Operator Environment
Note
Each environment is different, so Ribbon expects that you know how to
store and version control the manifest files,

provide persistent storage for the RAF state, and
run a container in a container environment.
The following is an outline of the top-level tarball:
Note
The README files in the tarball include supporting documentation. The first file you should review in the tarball is the README.md file.
The PACKAGE-CONTENTS.md file outlines the contents in the tarball and how to use them.
raf_operator-<application_name>-<provider>-V<application_version>-b<application_build_number>.tar.gz
example_manifests-<application_name>-<provider>-V<application_version>-b<application_build_number>.tar.gz
help
ansible
raf.ansible.log_info.md
raf.ansible.object_check.md
raf.ansible.object_info.md
raf.ansible.object.md
raf.ansible.operation_info.md
raf.ansible.operation.md
README.md
cli
README.command_ref.md
README.md
manifest-schemas
rest
swagger.yaml
PACKAGE-CONTENTS.md
raf-ansible-<release_date>.<application_build_number>.tar.gz
raf_operator-<application_name>-<provider>-V<application_version>-b<application_build_number>-image.tar.gz
README.md
stackctl-<release_date>-<application_build_number>-py3-none-any.whl
version
The following is an example outline of the top-level tarball:
raf_operator-sbc-aws-V10.00.00A001-b12.tar.gz
example_manifests-sbc-aws-V10.00.00A001-b12.tar.gz
help
ansible
raf.ansible.log_info.md
raf.ansible.object_check.md
raf.ansible.object_info.md
raf.ansible.object.md
raf.ansible.operation_info.md
raf.ansible.operation.md
README.md
cli
README.command_ref.md
README.md
manifest-schemas
rest
swagger.yaml
PACKAGE-CONTENTS.md
raf-ansible-21.7.12.tar.gz
raf_operator-sbc-aws-V10.00.00A001-b12-image.tar.gz
README.md
stackctl-21.7-12-py3-none-any.whl
version
Prerequisites
Software Bundle
The following table contains the list of required files.
File Names
sbc-V10.01.00R000-aws_container.tar.gz
Setting up RAF Container

This section outlines how to set up your container environment to execute the Automation Operator.
Caution
Persistent data (such as object states) is maintained in the /objects directory of the container, which is mapped to a host directory or
volume. You must make sure that the disk space is reliable and persistent (for example, by using network or cloud storage). If you use
a Docker desktop for Windows, you must use a volume because you cannot set permissions on files created in a New Technology
Files System (NTFS) formatted host directory. For information about what happens when you specify a non-existent volume while
using the docker run command to start the container, refer to the Tips for using bind mounts or volumes section in Manage data in
Docker.
For more information about RAF, refer to the following:
RAF Overview
RAF Automation Operator Terminology
Note
The procedure in this section uses the Docker container as an example, but you can set up RAF in any container environment.
Prerequisites
Note
The RAF container supports Python versions 3.6 or later. Support for Python 2.7 is deprecated.
Before you set up the RAF Docker container, you must have the following:
A host machine with the latest version of Docker installed. To install Docker, refer to the Docker Installation procedure for your operating
system.
A Docker engine that is running.
Appropriate access rights on the host machine to run Docker commands (refer to Manage Docker as a non-root user for Linux-based
hosts).
If your application is deployed on a host that has only an IPv6 connection, set up an IPv6 connectivity in the docker host.
A RAF automation operator package.
Start
1. Log into your host server.
2. Use the following command syntax to create a new directory.
mkdir <directory_name>
The following is an example command.
Example
mkdir raf_operator_pkg
3. Use the following command syntax to change to the new directory.
cd <new_directory_name>
Example
cd raf_operator_pkg
4. Use the following command syntax to extract the RAF automation operator package on the server or PC with docker installed and
running.
tar xvzf <raf_package>
5. Use the following command syntax to load the RAF container image.
docker load --input <container_image_tarball>
Example
docker load --input raf_operator-*image.tar.gz
6. Use the following command to make sure the RAF container image successfully loaded into docker.
6.
docker image ls
7. Create the following host persistent storage (similar to cloud storage) where you can save Ribbon application images, cloud and virtual
resource state information, and such. Make sure that the disk space is reliable and persistent (for example, by using network or cloud
storage).
The following are required mount points:
objects: Stores resource state information and logs. Depending on the deployment size, 2 to 4 GB is required.
resources: The images specific to the application and provider. This requires enough storage space to save the application
images.
To create the host persistent storage, you must copy the application images and tarball to the $WORKDIR/resources/images directory.
The following is an example of how to create the host persistent storage.
Example
WORKDIR=/opt/ribbon
mkdir -p $WORKDIR/objects $WORKDIR/resources/images
8. Use the following command syntax to run the RAF container.
Note
Each container must have a unique <container_name> and <host_port>.
docker run -d --name=<container_name> -p <host_port>:80 --mount "type=bind,src=<host_persistent_store>,

dst=/objects" --mount "type=bind,src=<host_static_resource>,dst=/resources,readonly" <docker_image>
In the preceding command,
<container_name> is the name of the container you want to launch.

<host_port> is the port number on the host that you want to map to the RAF container port and use for REST APIs.
<host_persistent_store> is a host directory (type=bind,src=<path_on_host_to_dir>) or volume (type=volume,
src=<volume_name>) that stores persistent data.
<host_static_resource> is a host directory that contains static resources such as disk images.
<docker_image> is the name of the RAF container image.
The following is an example of how to run the RAF container.
Example
docker run -d --name=raf_test -p 8080:80 --mount "type=bind,src=$WORKDIR/objects,dst=/objects" --

mount "type=bind,src=$WORKDIR/resources,dst=/resources,readonly" raf:21.08
9. Use one of the following procedures to access RAF. Use the CLI or Ansible® to deploy and manage applications manually, and the
REST API to deploy and manage applications using automation.
Setting up CLI to Deploy Applications

Setting up Ansible to Deploy Applications
Accessing RAF REST API to Deploy Applications
Additional Commands
Use the following command syntax to
stop the RAF container:
docker stop <container_name>
delete the RAF container:
docker rm <container_name>
restart the RAF container:
docker start <container_name>

docker restart <container_name>
Ribbon Automation Framework Scripts
In this section: Additional topics:
Selecting IaC or RAF to Upgrade SBC SWe

Overview
Installing SLB SWe on KVM Hypervisor
Terraform Modules
Installing SLB SWe on VMware
Ansible Playbooks
Prerequisites
Software Bundle
Extract the Terraform Modules' or Ansible Playbooks'
Tarball
Overview
The Ribbon Automation Framework (RAF) provides Ansible® playbooks, Terraform modules, and Automation Operators that enable the
automation of lifecycle management (LCM), provisioning, and testing of Ribbon applications. You can integrate Ribbon provided Ansible
playbooks, Terraform modules, and Automation Operators into automation environments, or execute Ansible playbooks, Terraform modules, and
Automation Operators manually by updating a file with the required end state and applying that file.
Note
The Automation Environment and RAF's Role diagram includes the following terms:
Communication Service Provider (CSP)

Continuous Integration (CI)
Continuous Delivery (CD)
Lifecycle Management (LCM)
Automation Environment and RAF's Role
Note
This section does not cover Provisioning and Testing.
The APIs and technology that implement the Ansible playbooks, Terraform modules, and Automation Operators depend on the application and
the automation domain (see the following figure).
RAF Automation Domains and Technologies
Terraform Modules
Terraform modules are provided for easy integration into any Terraform environment.
For RAF, LCM Terraform modules are packaged in a .TAR file with supporting documentation (README files).
Terraform Modules Environment
The following is an outline of the top-level Terraform modules tarball:
Note
The first file you should review in the tarball is the README.md file.
<application_name>-V<application_version>-<provider>_terraform_modules.tar.gz
diagrams
RAF-Overview.png
help
automation_scripts
README.setup.md
infrastructure-automation
<provider>
life-cycle-automation
common
<application_name>
instantiate-terminate
upgrade-rollback
pkginfo
README.md
requirements.txt
setup.py
system_requirements
The following is an example outline of the top-level Terraform modules tarball:
sbc-V10.01.00A001-aws_terraform_modules.tar.gz
diagrams
RAF-Overview.png
help
automation_scripts
README.setup.md
aws
common
sbc
upgrade-rollback
pkginfo
README.md
requirements.txt
setup.py
system_requirements
Ansible Playbooks
Ansible playbooks are provided for easy integration into any Ansible environment.
For RAF, LCM Ansible playbooks are packaged in a .TAR file with supporting documentation (README files).
Ansible Playbooks Environment
The following is an outline of the top-level Ansible playbooks tarball:
Note
The first file you should review in the tarball is the README.md file.
<application_name>-V<application_version>-<provider>_ansible_playbooks.tar.gz
diagrams
RAF-Overview.png
help
automation_scripts
README.setup.md
<provider>
common
<application_name>
upgrade-rollback
pkginfo
README.md
requirements.txt
setup.py
system_requirements
The following is an example outline of the top-level Ansible playbooks tarball:
sbc-V10.01.00A001-kvm_ansible_playbooks.tar.gz
diagrams
RAF-Overview.png
help
automation_scripts
README.setup.md
kvm
common
sbc
upgrade-rollback
pkginfo
README.md
requirements.txt
setup.py
system_requirements
Prerequisites
Software Bundle
The following table contains the list of required files.
File Names
sbc-V10.01.00R000-aws_container.tar.gz
sbc-V10.01.00R000-kvm_automation_scripts.tar.gz
Extract the Terraform Modules' or Ansible Playbooks' Tarball

This section outlines how to extract the tarball of the Ribbon Automation Framework (RAF) Terraform modules or Ansible® playbooks.
Prerequisites
A Linux server (RHEL or CentOS 8, Ubuntu 18, or Debian 9 or later)
Note
Ribbon recommends that you use public images (for example, Amazon Linux 2 AMI) for public clouds.
Python 3.6 or later

An internet connection to download and install the required packages (python-pip and virtualenv) and their dependencies
Root access on the instance to install the required packages using the setup.py script
Caution
Check for errors while you run the setup.py script. If you are not currently running as root, change to the root user (for
example, using the sudo su command).
The Terraform modules' or Ansible playbooks' tarball for your specific application and provider (refer to your application's release notes
for how to download the tarball)
Start
1. Log into the RAF server where you will extract the Terraform modules' or Ansible playbooks' tarball (see the following command syntax).
ssh <username>@<server_IPAddress>
2. Change to the root user.
sudo su
3. Use the following command syntax to create a directory where you want to extract the tarball.
mkdir <directory_name>
The following is an example of how to create a directory.
Example
mkdir my_raf
4. Use the following command syntax to copy the tarball to the directory you previously created.
cp <tarball_name> <directory_name>/
The following are examples of how to copy the tarball to the directory.
Example
cp sbc-V10.00.00R000-aws_terraform_modules.tar.gz my_raf/
cp ems-V14.00.00R000-rhv_ansible_playbooks.tar.gz my_raf/
5. Use the following command syntax to change to the directory you previously created.
cd <directory_name>/
The following is an example of how to change the directory.
Example
cd my_raf/
6. Use the following command syntax to extract the tarball.
tar xvfz <tarball_name>
The following are examples of how to extract the tarball.
Example
tar xvfz sbc-V10.00.00R000-aws_terraform_modules.tar.gz
tar xvfz ems-V14.00.00R000-rhv_ansible_playbooks.tar.gz
7. For further steps, such as how to setup the execution environment, refer to the README.md file located in the directory where you
decompressed your application's tarball.
Feature Availability by Platform
IMPORTANT
The SBC 51xx and SBC 52xx platforms are not supported from release 11.0.0 onwards. This release supports the SBC 5400, SBC
7000 and SBC SWe platforms.
The following table lists selected SBC Core key features, and their availability in this release by product. Features in this table are not supported
in all platforms/environments.
Note
This is not a comprehensive list of features. For a more inclusive and detailed listing of features, refer to the Feature Guides.
= Supported
= Not supported
Hardware-Based Software-Based Platforms

Platforms
SBC 5400 SBC SBC SWe SBC SWe (Cloud)

7000 (Virtual)
Integrated SBC D-SBC AWS GCP Azure
Feature VMware OpenStack Comments
in OpenStack
/KVM /VMware
IP-Related Features
Alternate/Multiple IP
Support
ARP Probing
DHCP Support
Direct I/O Support N/A N/A N/A N/A N/A N/A N/A
EVRC-B Codecs Pass-through
Geographical Refer to SBC Core Redundancy details.

Redundancy (GRHA)
H.323 Support gap for cloud
IPsec
IPv6 Support 2
Link Detection: Refer to SBC Core Redundancy for details.
N:1 Redundancy Refer to Distributed SBC Architecture for

details.
S-SBC: 4+1
M-SBC: 4+1
NIC Teaming
Note: Not in
KVM
Physical link detection NOTE: Physical link detection is supported

only on Direct I/O Packet Interfaces on the
SBC SWe.
Registration Display Refer to SIP Registration

Enhancement
(1:1 deployments) S-SBC only
(1:1
deployments)
SIP over SCTP
SIP Registrar NOTE: An SBC Core acting as a SIP
Registrar is only available on the SBC HW
and the SBC SWe I-SBC deployments, and
not on the D-SBC and SBC CNe
deployments. For more information, refer to SI
P Registrar Functionality.
SLB
SR-IOV N/A N/A
SRTP
Standby packet port (See note 1 Refer to SBC Core Redundancy for details.
support below)
Media-Related Features
Fax transcoded calls Refer to Fax Over IP
G.711–T.38
(V0)
G.711–T.38
(V3)
T.38 (V0)–T.
38 (V0)
Fax/Modem Fallback
GPU Transcoding (for

VMware)
(for KVM)
Opus Transcoding
UC (Video, BFCP,
Content Share)
1Supported for four packet port configuration only. Not supported for any other packet port configuration.
2The SBC Core SWe/Cloud on AWS and GCP does not support IPv6. However, AWS infrastructure supports IPv6, but GCP infrastructure does
not.
SBC Product Specifications
In this section:
Product Specifications
Codec Packetization Periods
Transcoded Sessions
IMPORTANT
The SBC 51xx and SBC 52xx platforms are not supported from release 11.0.0 onwards. This release supports the SBC 5400, SBC
7000 and SBC SWe platforms.
Product Specifications
The following table provides product specification details of the SBC Core systems:
Specification Category SBC 5400 SBC 7000 SBC SWe

(2x10G)
SIP/GW Call Call set-up rate (cps) 700 1,350 Refer to SBC SWe
Set-up Performance Metrics
Call latency 30 ms @ 700 30 ms @
cps 1,350 cps
Sessions by SIP 75,000 150,000

Signaling
Protocols*
Sessions by G.729 75,000 150,000

Codec*
G.711 (20 ms) 75,000 99,000
RTCP 1:1 with RTP 1:1 with RTP

Sessions sessions sessions
Scale
Registrations Initial register rate with no calls, in registers per second (Includes 1,250 1,300 400
initial Register Authentication)
Security TLS connections set-up rate (without mutual authentication) 500/second 2,000/second 50/second
Maximum number of IPSEC tunnels 2,048 2,048 2,048

(4,096 IPSEC (4,096 IPSEC (4,096 IPSEC SAs)
SAs) SAs)
IPSEC (IKE) setup rate 120/second 120/second 50/second
Maximum number of SRTP sessions 75,000 150,000** 44,000
Maximum number of registered subscribers on IMS AKA 375,000 1 million 320,000
Number of Over UDP with an interval refresh REGISTER of 120 sec. 600,000*** 2 million*** 1 million
Subscribers
Over UDP/NAT with an interval refresh REGISTER of 30 sec. 225,000 348,000 256,000
Over UDP/NAT with an interval refresh REGISTER of 60 sec. 300,000 384,000 512,000
Over TCP with an interval refresh REGISTER of 300 sec. 425,000 896,000 720,000***
Over TLS with an interval refresh REGISTER of 300 sec. 375,000 725,000 720,000
* The session count represents the aggregate number of sessions on one system.
** G.729 @ 40 ms packet size.
*** Not tested.
Codec Packetization Periods

See for the listing of transcoded and pass-through packetization periods of the supported codecs.
Transcoded Sessions
The number of transcoded sessions available on the SBC 5400 and SBC 7000 platforms are determined by the DSP card configurations.
For details, please see DSP Channel Densities for SBC 5400 and 7000.
SBC Provisioning Limits

In this section:
Number of IP Addresses per Call Leg Size

Configuration Limits
Provisioning Limits
SIPREC-based Recording Limitations
Maximum CLI Load Times
Approximate Start-up Times for Standalone SBC
IMPORTANT
The SBC 51xx and SBC 52xx platforms are not supported from release 11.0.0 onwards. This release supports the SBC 5400, SBC 7000
and SBC SWe platforms.
Number of IP Addresses per Call Leg Size

Note
The numbers in the tables in this section are based on the assumption that the ingress terminates on one IP interface and the egress on
another IP interface.
The number of call legs supported for a given number of IP Addresses on different SBC platforms are as follows:
SBC 7000, assuming UDP ports 4,000 through 64,444 are configured for media port usage - See table below.
SBC 5400 with 10GE interfaces - Supports a maximum of 75000 sessions, requiring 4 IP addresses per call leg.
SBC SWe - Operators must work with the account team and network design to determine the maximum session count supported on the SBC
SWe.
For SBC 7000 media resource allocation scenarios, the SBC requires a minimum of 10 IP addresses configured to support 150,000 call legs (one
Primary IP address plus 9 alternate IP addresses in non-VLAN configuration).
The number of IP addresses needed per interface to support call legs:
Number of Call Legs Number of IP

Addresses Needed per Interface
150,000 10
140,000 9
130,000 8
120,000 7
110,000 6
96,000 5
80,000 4
64,000 3
45,000 2
25,000 1
For example, to use 100,000 call legs you must configure at least six (6) IP addresses because five IP addresses will only allow up to 96,000 call legs
through the SBC.
The SBC Core supports configuring up to 14 alternate media addresses. For more details, refer to Alternate Media IP Addresses Support.
The following table is applicable to the SBC SWe.

22,000 1
41,000 2
49,000 3
54,000 4
The following table is applicable to the SBC SWewith "largemedia" profile. The largemedia profile is used to reduce the number of media IPs. The
session capacity and provisioning limits for the largemedia profile are the same as the large profile.

28,000 1
49,000 2
60,000 3
Configuration Limits
The SBC 7000 supports a large number of configurable objects and is capable of supporting from a few very large customers to thousands of small
customers. Important details about the provisioning system include:
Interactive provisioning of configuration objects (such as commands typed at the CLI or entered in the EMA or EMS) does not affect call
handling or capacity.
Provisioning behavior does not depend on the number of existing entities. The addition of the 10,000th instance is roughly comparable to
adding the first such instance.
Caution
Bulk or non-interactive provisioning may affect call handling. Operations such as sourcing a CLI script with many configuration commands
(or even a few commands affecting particularly large objects) should only be done during a maintenance window or at non-busy-hour
intervals.
Provisioning Limits
The SBC Core provisioning limits are shown in the following table.
Note
The largemedia profile is used to reduce the number of media IPs.
Configuration Provisioning Limits

Objects
SBC SBC SBC SWe SLB

7000 5400
VM Memory VM Memory VM Memory VM Memory VM Memory VM Memory VM Memory

>= 10 GiB 18 GiB RAM 18 GiB RAM 18 GiB RAM >= 10 GiB 18 GiB RAM 18 GiB RAM
("largeuseracl" ("largeuseracl"
RAM ("large" profile) ("largemedia" RAM ("large" profile)
("small" profile) profile) ("small" profile)
profile) profile)
Address Contexts 4,000 2,048 129 2,048 2,048 2,048 129 2,048 2,048
SIP Signaling 4,000 2,048 129 4,000 256 4,000 129 4,000 256
Ports
H.323 Signaling 2,048 2,048 129 129 129 129 N/A N/A N/A
Ports
SIP Trunk Groups 40,000 20,000 1,024 20,000 20,000 20,000 N/A N/A N/A
H.323 Trunk 2,048 2,048 129 256 256 256 N/A N/A N/A
Groups
Gateway Trunks 128 128 128 128 128 128 N/A N/A N/A
Maximum IP 40,000 20,000 1,024 20,000 20,000 20,000 N/A N/A N/A
Trunk Groups
of All Signaling
Types
Zones 4,000 2,048 129 4,000 4,000 4,000 129 4,000 4,000
DNS Groups 2,048 2,048 129 129 129 129
IP Interfaces 4,0965 4,0965 1295 2,0485 2,0485 2,0485 1295 2,0485 2,0485
IP Interfaces 4,000 2,048 129 1,024 1,024 1,024 129 1,024 1,024
Groups
IP Peers 40,000 20,000 1,024 20,000 20,000 20,000 N/A N/A N/A
Alternate Media 254 254 254 254 254 254 N/A N/A N/A
IP Addresses
(per LIF)
IP Addresses 8,192 8,192 258 4,096 4,096 4,096 258 4,096 4,096
IP ACLs 50,0001 25,0002 2,0003 10,5924 10,5926 10,5924 2,0003 10,5924 10,5926
Dynamic Black 4,000 2,000 100 100 100 100 N/A N/A N/A
List (DBL) Entries
Enhanced DBL 100 N/A N/A N/A

Profiles
SIP Adaptor 1,024 1,024 256 512 512 512 N/A N/A N/A
Profiles
Tone Package 2,048 N/A N/A N/A

Profiles
Surrogate 1,000 1,000 N/A N/A N/A

Registration
Profiles
AoRs for 256 per surrogate 256 per surrogate registration profile N/A N/A N/A
Surrogate registration profile
Registrations
SWe Traffic Refer to SBC SWe Traffic Profiles for details.

Profiles
Shared CAC 4,000 N/A N/A N/A

Limits Pools
Footnotes
1 - Includes approximately 10,000 IP ACLs for signaling ports (2 x 4,000 SIP, 2,000 H323) and 100 IP ACLs for OAM. A maximum of 35,648 IP ACLs
are allowed for users.
2 - Includes approximately 4,000 IP ACLs for signaling ports and 100 IP ACLs for OAM. A maximum of 17,824 (for SBC 5400) IP ACLs are allowed
for users.
3 - The number of user-defined ACLs is 772.
5 - The maximum number of IP interfaces on a single SR-IOV packet interface is limited by the maximum number of VLANs supported on the VF.
The maximum VLANs supported on SR-IOV VF interfaces depend on NIC type/capability.
1. For Intel X540, X550 NICs, the maximum VLANs supported on the SR-IOV VF interface is 63.
2. For X710 with trust mode enabled, the maximum VLANs supported on SR-IOV interfaces is 63.
For the other NIC types, refer to the NIC specification provided by the vendor.
7 - The maximum number of surrogate registrations supported:
The maximum number of surrogate registrations supported on the SBC 7000, SBC 5400 platform is 256,000. (1,000 Surrogate Registration
profiles and each profile supports 256 surrogate AORs)
The maximum number of surrogate registrations supported on the SBC SWE platform is 64,000 per SCM instance up to a maximum of
256,000.
Note
The IP address number is twice that of the IP interface number. You can assign each interface an IPv4 and IPv6 address.
Info
One GiB (gibibyte) = 2^30 (1,073,741,824 bytes).
The time required to add an object to an existing configuration is immaterial (It takes much longer to actually type the command or complete the EMA
/EMS fields). However, bulk loading of a large configuration from the CLI may take a substantial amount of time.
Caution
See cautionary note above about the potential bulk configuration loading on call handling performance.
While the SBC 7000 supports large limits on multiple types of configuration objects, a few typical usage scenarios exist. The length of time to bulk
load a configuration depends on the size of the configuration. Consequently, four SBC Core profile classes are defined to give customers a rough
idea for the bulk loading time relevant to their configuration:
1K profile – comprised of 1,000 instances each of Address Contexts, Zones, IP Interface Groups, IP Interfaces, Signaling Ports, and Trunk
Groups
4K profile – comprised of 4,000 instances each of Address Contexts, Zones, IP Interface Groups, IP Interfaces, Signaling Ports, and Trunk
Groups
4K/10K profile – comprised of 4,093 instances of IP Interfaces, 2,048 instances each of Zones, Address Contexts, IP Interface Groups, SIP
Signaling Ports, 10,000 IP Peer, and 10,000 IP Trunks (see Note below).
4K/40K profile [SBC 7000 series only] – comprised of 4,000 instances each of Address Contexts, Zones, IP Interface Groups, IP Interfaces,
Signaling Ports; and 40,000 Trunk Groups.
SIPREC-based Recording Limitations

Criteria/Cluster/Profile PSX ERE
Call Recording Criteria There is no hard-coded limit on the number of CRC objects you can Up to 128 CRC objects are allowed.
(CRC) create.
SRS Group Cluster Up to 256 SRSGC objects are allowed. Up to 256 SRSGC objects are
(SRSGC) allowed.
SRS Group Profile (SRSGP) Up to 256 SRSGP objects are allowed. Up to 256 SRSGP objects are
allowed.

The following table lists the maximum CLI load times for the above profile classes.
Configuration Profile Maximum CLI Load Time
1K 2.5 hours
4K 4 hours
4K/10K 3 hours
4/40K (7000 only) 10 hours
For a system previously loaded with configuration, the start-up time also depends on the amount of configuration. The start-up time is considered the
time from when the SBC application is started (by PM) to the time that the SBC is ready to accept calls.
Note that this start-up time is typically only relevant to standalone systems after an upgrade. For a HA system, the standby is activated to handle calls
while the SBC is being started or restarted.
Approximate Start-up Times for Standalone SBC

The following table lists the approximate start-up times for a standalone SBC based on its configuration profile:
Configuration Profile Maximum Time

to Service Ready
No configuration 5 minutes
1K 10 minutes
4K 20 minutes
4K/10K 22 minutes
4K/40K (7000 only) 45 minutes
SBC Performance Metrics

The following pages detail system performance metrics for the various SBC Core platforms.
Info
For LSWU performance metrics, refer to LSWU Performance Metrics page.

Distributed SBC on OpenStack Performance Metrics
KVM Hypervisor Performance Metrics
Performance Metrics for Small SBC SWe Configurations
SBC SWe Performance Metrics on OpenStack using QLogic 536FLR-T NIC Cards
VMware Hypervisor Performance Metrics
SBC SWe on Public Cloud Performance Metrics
In this section:
SBC 51x0 Platforms

Pass-Through With/Without sRTP
H.323 Performance Metrics
Maximum Initial (challenged) REGISTER Rate with Background Load
SIP Session and Registration Capacity Limits
Video Calls Metrics
SUBSCRIBE/NOTIFY Benchmark (with ERE)
SBC 52x0 Platforms
Video Calls Metrics
SUBSCRIBE/NOTIFY Benchmark for SBC 52x0 (with ERE)
This page includes SBC 51x0 and SBC 52x0 performance metrics. Refer to SBC 5400 Performance Metrics for SBC 5400 performance details.
SBC 51x0 Platforms

Table 1: Pass-Through with sRTP for SBC 51x0
Packet Size
Codec
10 ms 20 ms 40 ms
G.711 6,900 9,000 9,900
G.729 10,000 10,000 10,000
Table 2: Pass-Through without sRTP for SBC 51x0
Codec Packet Size
10 ms 20 ms 30 ms 40 ms
G.711 7,400 9,978 10,000 10,000
G.726 9,900 10,000 10,000 10,000
G.729 10,000 10,000 10,000 10,000
G.722 7,400 9,978 10,000 10,000
AMR (12.2k) -BWE 10,000 10,000
AMR (12.2k) -OA 10,000 10,000
eVRC 10,000 10,000
eVRC-B 10,000 10,000
G.722.1 10,000 10,000
AMR-WB - BWE 10,000 10,000
AMR-WB-OA 10,000 10,000
iLBC - 20 ms 10,000 10,000
iLBC - 30 ms 10,000
G.723.1 10,000

Table 3: H.323 Performance Metrics
Specification Category Limit
H.323 call setup Call setup rate 100 cps
Call latency 50 ms @ 100 cps
Fast start or tunneled H.245 calls SIP--H.323 or GW--H.323 9,000
H.323--H.323 9,000
Separate H.245 calls (50 ms @ 50 cps) SIP--H.323 or GW--H.323 1,000

Table 4: Maximum Initial (challenged) REGISTER Rate with Background Load (SIP calls/second)
Initial SIP Number of Interval of Refresh

Registration/Sec Subscribers REGISTER (Seconds) SIP Calls/Sec
UDP 300 50,000 30 125
400 100,000 90 100
TCP 400 100,000 300 100
TLS 300 100,000 300 125

Table 5: SIP Session and Registration Capacity Limits
Call Hold Refresh

Sessions SIP Calls/Sec (seconds) REGISTER Subscribers
Interval (seconds)
Non-TLS Peering 9,900 150 66
TLS Peering 9,900 150 66
UDP 9,000 150 60 30 50,000
9,000 150 60 60 100,000
TCP 9,000 150 60 300 100,000
Video Calls Metrics

Table 6: Video Calls Metrics
Specification Limit
SIP-SIP conference sessions (media anchored) consisting of five streams: audio, main video, content share video, far end camera 4,500
control (FECC), and floor control (BFCP).
SIP-SIP conference sessions with direct media 4,500
SIP-SIP conference sessions 150

cps
H.323-H.323 video sessions (media anchored) comprising up to two media streams (one audio, one video) 1,000
H.323-H.323 video sessions 25 cps
SUBSCRIBE/NOTIFY Benchmark (with ERE)

Table 7: SUBSCRIBE/NOTIFY Benchmark for SBC 51x0 (with ERE)
Scenario SUBSCRIBE REGISTER Calls SUBSCRIBEs REGISTRATIONs Calls

/Sec /Sec /Sec
SUBSCRIBE From Unregistered user 500,000 200
SUBSCRIBE with 100,00 Calls 200,000 9,996 200 100
SUBSCRIBE with 6,000 calls and 32,000 Registrations 200,000 32,000 6,000 200 300 100
(Calls from Registered user)
SUBSCRIBE with 64,000 Registrations (Subscribe from 300,000 64,000 200 300
registered user)
SBC 52x0 Platforms

Table 8: Pass-Through with sRTP for SBC 52x0
Packet Size
Codec
10 ms 20 ms 40 ms
G.711 13,950 18,000 22,950
G.729 24,075 43,425 63,450
Table 9: Pass-Through without sRTP for SBC 52x0
Packet Size
Codec
10 ms 20 ms 30 ms 40 ms
G.711 14,850 19,800 22,050 23,400
G.726 19,800 29,700 35,550 39,600
G.729 26,900 48,150 64,000 64,000
G.722 14,850 19,800 22,050 23,400
AMR (12.2k) - BWE 35,550 63,450
AMR (12.2k) - OA 35,550 63,450
eVRC 63,450 63,450
eVRC-B 63,450 63,450
G.722.1 29,925 39,600
AMR-WB - BWE 63,450 63,450
AMR-WB - OA 63,450 63,450
iLBC - 20 ms 63,450 63,450
iLBC - 30 ms 54,900
G.723.1 63,450

Table 10: H.323 Performance Metrics
Specification Category Limit
H.323 call setup Call setup rate 200 cps
Call latency 50 ms @ 200 cps
Fast start or tunneled H.245 calls SIP--H.323 or GW--H.323 24,000
H.323--H.323 12,000
Separate H.245 calls (50 ms @ 150 CPS) SIP--H.323 or GW--H.323 2,000

Initial SIP Number of Interval of SIP Calls/Sec

Registration/Sec Subscribers Refresh
REGISTER
(seconds)
UDP 400 128,000 30 150
1,000 256,000 60 150
TCP 800 256,000 300 150
TLS 800 192,000 300 150

Call Hold Refresh REGISTE

Sessions SIP Calls/Sec (seconds) R Subscribers
Interval (seconds)
TLS Peering 63,450 450 141
UDP 42,000 350 120 60 256,000
42,000 350 120 30 128,000
TCP 42,000 350 120 300 256,000
Video Calls Metrics
Table 13: Video Call Metrics
Specification Limit
control (FECC), and floor control (BFCP)

cps
H.323-H.323 video sessions (media anchored) comprising up to two media streams (one audio, one video) 1,600
H.323-H.323 video sessions 40 cps
SUBSCRIBE/NOTIFY Benchmark for SBC 52x0 (with ERE)

Table 14: SUBSCRIBE/NOTIFY Benchmark for SBC 52x0 (with ERE)

/Sec /Sec /Sec
SUBSCRIBE From Unregistered user 1,000,000 300
SUBSCRIBE with 32,000 calls and 64,000 Registrations 200,000 64,000 32,000 300 600 400
(calls from Registered user)
SUBSCRIBE with 128,000 Registrations (subscribe from 800,000 128,000 300 600
Registered user)
In this section:
Provisioning Capacities
Video Calls Metrics
SUBSCRIBE/NOTIFY Benchmark for SBC 5400 (with ERE)
Dynamic Capacities
Sessions
This page includes SBC 5400 performance metrics.
Provisioning Capacities
Table 1: SBC 5400 Performance and Capacity
Specification Category SBC 5400 Platform
SIP/GW Call Set-up Call set-up rate 700 cps
Call latency 30ms @ 700cps
Sessions by Signaling Protocols* SIP 75,000
Sessions by Codec* G.729 (20 ms) 75,000
G.711 (20 ms) 75,000
RTCP Sessions Scale 1:1 with RTP sessions
Registrations Initial register rate with no calls, in registers per second 1250
(Includes initial Register Authentication)
Security TLS connections set-up rate 750

(without mutual authentication)
Maximum number of IPSec tunnels 2,048 (4,096 IPSec SAs)
IPSEC (IKE) setup rate 150
Maximum number of SRTP sessions 75,000
Maximum number of registered subscribers on IMS AKA 256,000
Subscribers Over UDP with an interval refresh REGISTER of 1800 sec. 600,000
Over UDP/NAT with an interval refresh REGISTER of 30 sec. 225,000
Over UDP/NAT with an interval refresh REGISTER of 60 sec. 300,000
Over TCP with an interval refresh REGISTER of 300 sec. 425,000
Over TLS with an interval refresh REGISTER of 300 sec. 375,000
* The session count represents the aggregate number of sessions on one system.
Note
The SBC 5400 supports 75K passthrough calls standalone.

The recommended peak capacity in HA systems is 68.5K calls.

Table 2: Pass-Through with sRTP
Codec Packet Size
10 ms 20 ms 40 ms
G.711 28,000 50,000 75,000
G.729 32,000 64,000 75,000
Table 3: Pass-Through Without sRTP
Codec Packet Size
10 ms 20 ms 30 ms 40 ms
G.711 50,000 75,000 75,000 75,000
G.726 50,000 75,000 75,000 75,000
G.729 50,000 75,000 75,000 75,000
G.722 50,000 75,000 75,000 75,000
AMR (12.2k) -BWE N/A 75,000 N/A 75,000
AMR (12.2k) -OA N/A 75,000 N/A 75,000
eVRC N/A 75,000 N/A 75,000
eVRC-B N/A 75,000 N/A 75,000
G.722.1 N/A 75,000 N/A 75,000
AMR-WB - BWE N/A 75,000 N/A 75,000
AMR-WB-OA N/A 75,000 N/A 75,000
iLBC - 20 ms N/A 75,000 N/A 75,000
iLBC - 30 ms N/A N/A 75,000 N/A
G.723.1 N/A N/A 75,000 N/A

Initial SIP Number of Interval of SIP Calls/Sec

Registration/Sec Subscribers Refresh
REGISTER
(seconds)
UDP 800 225,000 30 200
1,500 300,000 60 300
TCP 1,000 425,000 300 300
TLS 750 375,000 300 300

Sessions SIP Calls/Sec Call Hold Refresh REGISTE Subscribers

(seconds) R
Interval (seconds)
TLS Peering 74,400 600 124
UDP 72,000 400 180 30 225,000
72,000 500 144 60 300,000
TCP 54,000 500 108 300 425,000
Note
In the current implementation, the “send” and “receive” buffer size for TCP packets is restricted to 64 kilobytes. Due to this limitation,
the SBC cannot handle traffic where the product of the TCP packet size (measured in kilobytes) and the processor rate (measured in
cycles per second) exceeds 64. For example, if the packet size is 3 kilobytes and the processor rate is 25 cycles per second, the
product is 75 - which is greater than the TCP buffer size. If the TCP buffer overflows, the SBC resets the connection. This is
particularly important when the packet sizes are large, as in case of packets containing the INFO header that bloats the packet sizes.
Video Calls Metrics

Specification Limit
control (FECC), and floor control (BFCP)

cps

SUBSCRIBE/NOTIFY benchmarking metrics for SBC 5400 are provided below.
Table 7: SUBSCRIBE/NOTIFY Benchmark for SBC 5400 (with ERE)
Scenario SUBSCRI REGIST Calls SUBSCRIBE REGISTRATION CALLS

BE ER /Sec /sec /Sec
SUBSCRIBE From Unregistered user 1,500,000 300

00
SUBSCRIBE with 40,000 calls and 128,000 Registrations (Calls from 400,000 128,000 40,0 300 600 600
Registered user) 00
SUBSCRIBE with 256,000 Registrations (subscribe from registered user) 1,000,000 256,000 300 600
Dynamic Capacities
The SBC 5400 can support up to 75,000 simultaneous calls.
Combination of RTP and RTCP calls.

SRTCP and SRTP with 40 ms or larger packets.
The SBC 5400 can be subject to bandwidth limitations that prevent the total call count from reaching 75,000.
Sessions
The following table lists the SBC 5400 session limits:
Table 8: Sessions
Functionality SBC 5400
Call recording sessions (NICE/SIPREC) 32,000
Lawful Intercept Sessions 2048
Media capture tool (MCT) sessions 10
NP-based DTMF detection (simultaneous digits) 1,024
NP-based DTMF insertion (simultaneous digits) 1,024
In this section:

Video Calls Metrics
This page includes SBC 7000 SIP performance, registration, and capacity metrics.

Table 1: Pass-Through without sRTP
Packet Size
Codec
10 ms 20 ms 30 ms 40 ms
G.711 75,000 99,000 112,000 119,000
G.726 85,000 150,000 150,000 150,000
G.729 85,000 150,000 150,000 150,000
G.722 75,000 99,000 112,000 119,000
AMR (12.2k) -BWE 150,000 150,000
AMR (12.2k) -OA 150,000 150,000
eVRC 150,000 150,000
eVRC-B 150,000 150,000
G.722.1 150,000 150,000
AMR-WB - BWE 150,000 150,000
AMR-WB-OA 150,000 150,000
iLBC - 20 ms 150,000 150,000
iLBC - 30 ms 150,000
G.723.1 150,000
Table 2: Pass-Through with sRTP
Packet Size
Codec
10 ms 20 ms 40 ms
G.711 60,000 90,000 110,000
G.729 65,000 120,000 150,000

Initial SIP Number of Interval of Refresh

Registration/Sec Subscribers REGISTER (Seconds) SIP Calls/Sec
UDP 1,500 450,000 30 250
2,500 600,000 60 350
TCP 2,000 850,000 300 500
TLS 1,500 750,000 300 420

Call Hold Interval of Refresh

Sessions SIP Calls/Sec (seconds) REGISTER (seconds) Subscribers
Non-TLS peering 121,500 1,350 90
TLS peering 108,000 1,200 90
UDP 60,000 700 90 60 600,000
45,000 500 90 30 450,000
TCP 85,000 950 90 300 850,000
Note
In the current implementation, the “send” and “receive” buffer size for TCP packets is restricted to 64 kilobytes. Due to this limitation,
the SBC cannot handle traffic where the product of the TCP packet size (measured in kilobytes) and the processor rate (measured in
cycles per second) exceeds 64. For example, if the packet size is 3 kilobytes and the processor rate is 25 cycles per second, the
product is 75 - which is greater than the TCP buffer size. If the TCP buffer overflows, the SBC resets the connection. This is
particularly important when the packet sizes are large, as in case of packets containing the INFO header that bloats the packet sizes.
Video Calls Metrics

Specification Limit
control (FECC), and floor control (BFCP).
SIP-SIP conference sessions 550 cps

Table 6: SUBSCRIBE/NOTIFY Benchmark for SBC 7000 (with ERE)

/Sec /Sec /Sec
SUBSCRIBE From Unregistered user 6,000,000 1,000
SUBSCRIBE with 100,000 Calls 3,000,000 100,000 1,000 1,000
SUBSCRIBE with 75,000 calls and 1 million Registrations 3,000,000 1,000,000 75,000 1,000 1,500 1,000
(Calls from Registered user)
SUBSCRIBE with 1.2 million Registrations (subscribe from 4,000,000 1,200,000 1,000 1,500
registered user)
In this section...
Overview
Server and VM Details
Benchmarking Setup
Performance Metrics
Increasing RAM on Active SBC SWe Systems
Overview
The SBC SWe performance metrics for simultaneous sessions for various call scenarios are summarized in the "Benchmarking Results" section
of the following pages. Note that these numbers apply to our recommended CPU and memory configurations, and the results may vary
depending on the actual CPUs used. Exceeding these simultaneous sessions metrics may result in poor call performance, including longer call
setup times and/or poor voice quality. Ribbon recommends maintaining call rates within the performance limits benchmarked below.

Server Details VM Details Max

Link
Configuration Size
Server CPU Processor RAM Hyperthreading vCPUs Memory Disk Network Interface
Type Speed Sockets (GB) Allocated (GB) Size Mode
(GHz) (GB)
Config-1 HP DL380 2.3 2 256 ACTIVE 32 32 100 Pass-Through Mode 10 Gbps

Gen10 (SR-IOV)
Config-2 Gold 6140 32 Direct I/O
Note
For deployments that require it, you can instantiate the SBC SWe in smaller-sized configurations that use limited memory and vCPU
resources. However, the limited resources place some restrictions on capacity and capabilities. Refer to Small SBC SWe Deployment
Characteristics and Performance Metrics for Small SBC SWe Configurations for more information.
Benchmarking Setup
The two test beds used to collect benchmarking data are depicted below.
The VM is hosted on a single NUMA node, where the NIC is connected.
Benchmarking Setup for SBC SWe Using SR-IOV interfaces
Benchmarking Setup for SBC SWe Configured in Pass-Through Mode (Direct I/O)
Performance Metrics
This section includes benchmarking results using the following configurations with and without DoS. Contact your Ribbon representative if you
are interested in benchmarking data for other call scenarios.
Table 1: SWe VMware Benchmarking Data
Call Scenario/Configuration Configuration Traffic Profile CPS/CHT Simultaneous

Sessions
G729a passthru Config-2 (32 vCPU) standard_passthrough_profile 450/106 47,700
x-code G729a->G711u Config-2 (32 vCPU) standard_transcoding_profile 79/51 4,029
G729a pass through with TLS/SRTP enabled on ingress leg config-2 (32 vCPU) standard_passthrough_profile 430/51 21,930
G729a Direct Media config-2 (32 vCPU) standard_signaling_profile 1000/40 40,000
MultiExcerpt named 'KVM Hypervisor Performance Metrics' was not found
The multiexcerpt named 'KVM Hypervisor Performance Metrics' was not found. Please check the page name and MultiExcerpt name used in
the MultiExcerpt Include macro.
Increasing RAM on Active SBC SWe Systems

Use the following procedure to increase RAM size on active (live) systems to increase SBC SWe session capacity.
Note
The SBC SWe requires a minimum memory reservation of 6 GB.
Step Action
1 Power down the designated standby SBC.
2 Increase the RAM size of the VM system, and then power-on the standby SBC.
3 Perform a manual switchover, and then power-down the previously active SBC. Refer to the following pages for details:
EMA: System - Admin
CLI: Admin - CLI
4 Increase the RAM size of the VM system for the powered-down SBC, and then power it back up.
5 Manually switchover to revert the active/standby SBCs back to their original states prior to beginning this procedure.
6 Follow LSWU steps if you are upgrading to the next release.
Distributed SBC on OpenStack Performance Metrics
Distributed SBC Performance

The metrics for a distributed SBC (D-SBC) deployment in an OpenStack cloud environment are included on this page.
Table 1: Microservices SBC Performance
Type: Sessions SIP Calls/Second

S
(Signaling)
M (Media)
S-SBC 120,000 Signaling Sessions 1,000 CPS
M-SBC 40,000 Media Sessions N/A
Note
The maximum NP-based Tones supported per M-SBC is 8000 tones (1/5th of max sessions per M-SBC – 40000 media sessions).
The maximum CPS on the SSBC for supporting tones for 1/5th of 120K sessions is 950 cps.
Notes
S-SBC 32 vCPU (hyper-threading enabled), 128 GB, SR-IOV vNIC for PKT0/PKT1, virtio vNIC for MGT, 100 GB HDD,
HugePage memory
M-SBC 16 vCPU (hyper-threading enabled), 32 GB RAM, SR-IOV vNIC for PKT0/PKT1, virtio vNIC for MGT and HA, 100 GB
HDD, HugePage memory
Notes
RHOSP 13.0 Queens OpenStack Release with RHEL 7.6 (Maipo) Host OS
CPU-model set as "host-model"
KVM Hypervisor Performance Metrics

Table 1: SWe KVM Benchmarking Data

Sessions
x-code G729a G711u Config-1 (32 vCPU) standard_transcoding_profile 54/90 4,860
G729a pass through with TLS/SRTP enabled on ingress leg Config-1 (32 vCPU) standard_passthrough_profile 550/90 49,500
G729a Direct Media Config-1 (32 vCPU) standard_signaling_profile 1000/40 40,000
Note
For deployments that require it, you can instantiate the SBC SWe in smaller-sized configurations that use limited memory and vCPU
resources. However, the limited resources place some restrictions on capacity and capabilities. Refer to Small SBC SWe Deployment
Characteristics and Performance Metrics for Small SBC SWe Configurations for more information.
Performance Metrics for Small SBC SWe Configurations
In this section:
2 vCPU SBC SWe Deployments

Reduced Memory SBC SWe Deployments
For deployments that require it, you can instantiate the SBC SWe in smaller-sized configurations that use limited memory and vCPU resources. T
he following benchmarking information applies to these configurations. Refer to Small SBC SWe Deployment Characteristics for limitations and
restrictions in such deployments.
2 vCPU SBC SWe Deployments

Ribbon performed testing of 2 vCPU SBC SWe setups on VMware and KVM Hypervisor systems with the following characteristics.
Table 1: 2 vCPU Setup on VMware
Server Details VM Details
CPU RAM vCPUs Memory Disk Network Max

Server Type Speed (GB) Allocated (GB) Size Interface Mode Link
(GHz) (GB) Size
Dell PowerEdgeR740 2.4 256 2 6 100 SR-IOV 10 Gbps
Intel(R) Xeon(R) Gold 6148 CPU @ 2.40GHz
Table 2: 2 vCPU Setup on KVM Hypervisor
CPU RAM vCPUs Memory Disk Network Max

Server Type Speed (GB) Allocated (GB) Size Interface Mode Link
(GHz) (GB) Size
Dell PowerEdgeR740 2.3 256 2 6 100 SR-IOV 10 Gbps
Intel(R) Xeon(R) Gold 6148 CPU @ 2.30GHz
The default SWe traffic profile must be used for all 2 vCPU deployments. The following values apply to both VMware and KVM Hypervisor
deployments.
Table 3: 2 vCPU Benchmarking Results
Call Scenario/Configuration Traffic Profile CPS/CHT Simultaneous

Sessions
G729a passthru default 18/25 450
Reduced Memory SBC SWe Deployments

Ribbon performed testing of reduced-memory setups on KVM Hypervisor systems with the following characteristics.
Table 4: Reduced Memory Setup
CPU Processor RAM vCPUs Memory Disk Network Max

Server Type Speed Sockets (GB) Hyperthreading Allocated (GB) Size Interface Link
(GHz) (GB) Mode Size
HP DL380 Gen10 2.3 2 256 Active 4 6 100 SR-IOV 10 Gbps
8 9.5 100 SR-IOV 10 Gbps
Intel(R) Xeon(R) Gold 6140 CPU @ 2.30
GHz
The following table lists the performance benchmarks for a system deployed with 6 GB of RAM and 4 vCPUs.
Table 5: Performance Metrics for 6 GB/4vCPU Systems on KVM
Call Scenario/Configuration Traffic Profile CPS/CHT(sec) Simultaneous

Sessions
G729a passthru standard_passthrough_profile 5/100 500
Transcoding G729a G711u standard_transcoding_profile 3/74 222
G729a pass through with TLS/SRTP enabled on ingress leg standard_passthrough_profile 5/100 500
G729a direct media standard_signaling_profile 5/100 500
The following table lists the performance benchmarks for a system deployed with 9.5 GB of RAM and 8 vCPUs.
Table 6: Performance Metrics for 9.5 GB/vCPU Systems on KVM
Call Scenario/Configuration Traffic Profile CPS/CHT(sec) Simultaneous

Sessions
Transcoding G729a G711u standard_transcoding_profile 15/60 900
G729a pass through with TLS/SRTP enabled on ingress leg standard_passthrough_profile 136/60 8160
G729a direct media standard_signaling_profile 136/60 8160
SBC SWe Performance Metrics on OpenStack using QLogic
536FLR-T NIC Cards
In this section...
I-SBC
D-SBC
The following benchmarking numbers are specific to SBC SWe deployments using QLogic 536FLR-T NIC cards in an RHOSP 13.0 (Queens)
OpenStack release environment.
I-SBC
The following table contains benchmarking numbers for integrated SBC (I-SBC) SWe 1:1 HA deployments with the following characteristics:
SR-IOV packet interfaces

10 vCPU
32 GB RAM
100 GB HDD
Table 1: I-SBC Benchmarking Results

Sessions
D-SBC
The following table contains benchmarking numbers for distributed SBC (D-SBC) SWe deployments consisting of S-SBC 1:1 HA and M-SBC 1:1
HA nodes with the following characteristics:
SR-IOV packet interfaces

10 vCPU
32 GB RAM
100 GB HDD
Table 2: D-SBC Benchmarking Results

Sessions
G729a passthru standard_signalling_profile (S-SBC) 190/60 11000
standard_msbc_profile (M-SBC)
Note
The QLogic 536FLR-T NIC card is not qualified on VMWare, KVM, or Red Hat Enterprise Virtualization (RHEV).
VMware Hypervisor Performance Metrics
Table 1: SWe VMware Benchmarking Data

Sessions
x-code G729a->G711u Config-2 (32 vCPU) standard_transcoding_profile 79/51 4,029
G729a pass through with TLS/SRTP enabled on ingress leg config-2 (32 vCPU) standard_passthrough_profile 430/51 21,930
G729a Direct Media config-2 (32 vCPU) standard_signaling_profile 1000/40 40,000
SBC SWe on Public Cloud Performance Metrics

In this section:
AWS Performance Metrics

Azure Performance Metrics
GCP Performance Metrics
AWS Performance Metrics
In this section:
AWS Benchmarking Setup

Benchmarking Setup Details
Instance Types
CPU Instances
AWS SLB Performance Data
Deployment Types on AWS with SLB
AWS with SLB Performance Testbed
SLB Performance Data


1. Benchmarking is performed on an SBC HA with HFE.
a. The call flow includes 9 signaling messages with media.
b. Calls are tested from Public to Private network
2. The SBC HA with HFE and PKTART are running on the default tenant.
3. The PKTART Tool flavor uses c5.2xlarge to benchmark all of the SBC with HFE Instances except c5.4xlarge.
a. For the c5.4xlarge Instance, the PKTART flavor used is the same as the SBC.
4. The performance test is done for one hour.
5. Perflogger is used for Logs collection.
6. There is a 2,000 sessions System Limit for M5.xlarge for default profile.
7. TLS/SRTP enabled at Public side traffic. Separate TLS connection (Port) used for each call.
8. SRTP Calls are executed from PKTART.
Instance Types
S. NO. Instance Type IOPS RAM (MB) CPU HDD (GB)
1 M5.xlarge 500 16384 4 65
2 M5.2xlarge 500 32768 8 65
3 C5.2xlarge 500 16384 8 65
4 C5.4xlarge 500 32768 16 65
5 P3.2xlarge 500 62464 8 65
CPU Instances
Call Scenario Instance CPS Simultaneous Worker Core Signaling Core UXPAD Core Average Max SWe
Memory Profile
Type /CHT Sessions CPU Utilization
wrkr CPU% Sig CPU% UXPAD CPU% Utilization %
core# core Core #

#
G711u-UDP-passthrough M5.xlarge 20/100 2000 Core 2 15.17% Core 1 15.06% Core 3 0.56% 10.32% 43.22% Default
G729A-UDP-passthrough M5.xlarge 20/100 2000 Core 2 18.83% Core 1 14.35% Core 3 0.55% 9.70% 43.26% Default
G711u-Passthrough-TLS- M5.xlarge 20/100 2000 Core 2 40.84% Core 1 22.93% NA NA 22.61% 42.49% Standard
(shared) Passthroug
SRTP enabled h Profile
25.09%
Core 3
G711u-OPUS transcoded M5.xlarge 2/48 96 Core 2 3.94% Core 1 10.65% Core 3 39.49% 15.07% 38.81% Standard
Transcodin
g Profile
G711-UDP passthrough M5.2xlarge 40/150 6000 Core 2 32.32% Core 1 24.71% Core 4 0.39% 18.06% 28.77% Default
(Shared)
Core 3 32.14% 22.99% Core 5 0.70%
Core 6
24.03%
Core 7
G729A-UDP passthrough M5.2xlarge 45/150 6750 Core 2 37.36% Core 1 27.30% Core 4 0.42% 20.16% 29.25% Default
(Shared)
Core 3 36.38% 25.01% Core 5 0.84%
Core 6
26.82%
Core 7
G729A-UDP passthrough c5.2xlarge 40/150 6000 Core 2 32.93% Core 1 23.78% Core 4 0.33% 17.52% 55.69% Default
(Shared)
Core 3 31.36% 22.30% Core 5 0.63%
Core 6
22.89%
Core 7
G711-Passthrough TLS- c5.2xlarge 30/200 6000 Core 2 47.48% Core 1 10.18% NA NA 20.40% 55.38% Standard
(Shared) Passthroug
SRTP enabled h Profile
Core 3 52.18% 12.81%
Core 4
10.05%
Core 5
11.67%
Core 6
11.77%
Core 7
G711-OPUS c5.2xlarge 7/60 420 Core 2 8.47% Core 1 16.63% Core 3 35.09% 22.89% 46.42% Standard
Transcodin
Core 4 38.19%
g Profile
Core 5 39.25%
Core 6 38.15%
G711-UDP pass through c5.2xlarge 40/150 6000 Core 2 30.31% Core 1 24.61% Core 4 0.34% 17.59% 55.87% Default
(Shared)
Core 3 31.14% 23.37% Core 5 0.61%
Core 6
24.04%
Core 7
G729-Passthrough- c5.2xlarge 30/150 4500 Core 2 47.92% Core 1 13.33% NA NA 20.91% 53.78% Standard
(Shared)
SRTP enabled Passthroug
Core 3 34.95% 15.64%
Core 4 h Profile
12.49%
Core 5
13.89%
Core 6
14.19%
Core 7
g711-g729-Transcoded c5.2xLarge 10/128 1280 Core 2 20.82% Core 1 21.00% Core 3 71.82% 45.63% 47.86% Standard
Transcodin
Core 4 74.74% g Profile
Core 5 81.97%
Core 6 79.92%
g729-Passthrough c5.4xlarge 40/150 6000 Core 4 12.44% Core 1 15.04% Core 8 0.24% 8.92% 31.86% Default
(Shared)
Core 5 13.30% 15.09% Core 9 0.33%
Core 12
Core 6 13.21% 14.02% Core 10 0.27%
Core 13
Core 7 13.33% 14.25% Core 11 0.47%
Core 14
14.44%
Core 15
g711-Passthrough c5.4xlarge 40/150 6000 Core 4 10.03% core1 13.86% Core 8 0.23% 8.74% 32.65% Default
(Shared)
Core 5 09.92% 14.16% Core 9 0.32%
Core 12
Core 6 10.13% 12.95% Core 10 0.25%
Core 13
Core 7 10.07% 13.20% Core 11 0.47%
Core 14
13.29%
Core 15
g711-passthrough-SRTP c5.4xlarge 30/150 4500 Core 4 12.81% Core 1 12.85% Core 8 0.43% 8.15% 31.15% Default
(Shared)
enabled
Core 5 12.71% 12.75% Core 9 0.31%
Core 12
Core 6 12.70% 11.65% Core 10 0.15%
Core 13
Core 7 12.71% 11.86% Core 11 0.66%
Core 14
12.09
Core 15
g711-g729A udp- c5.4xlarge 10/150 1500 Core 2 21.56% Core 1 17.03% Core 3 33.54% 25.88% 28.44% Standard
(Shared) Transcodin
transcoded g Profile
Core 4 32.55%
Core 15
14.51% Core 5 33.48%
Core 6 28.102%
Core 7 31.12%
Core 8 29.82%
Core 9 31.28%
Core 10 31.80%
Core 11 33.82%
Core 12 31.37%
Core 13 32.76%
opus-20ms-g711u-20ms c5.4xLarge 3/142 426 Core 2 8.18% Core 1 9.38% Core 3 12.38% 12.75% 27.89% Standard
(Shared)
Transcodin
Core 4 13.60%
Core 15 g Profile
8.42% Core 5 14.37%
Core 6 16.56%
Core 7 14.68%
Core 8 19.82%
Core 9 16.59%
Core 10 14.76%
Core 11 15.05%
Core 12 13.43%
Core 13 12.60%
GPU Instances
Call Instance HFE CPS Simultaneous Worker Core Signaling Core Average Max SWe DSP
Instance Memory Profile
Scenario Type Type /CHT Sessions CPU Utilization Utilization
wrkr CPU% Sig CPU% Utilization %
core# core
#
G711u-G729a p3.2xlarge M5.2xlarge 38/100 3800 Core 2 55.11% 47.72% 38.51% 14.66% 82%
transcoding Core 1 50.47% Standard
(Shared) GPU I-SBC
42.79% Profile
Core 3
41.99%
Core 4
28.08%
Core 5
33.57%
Core 6
Core 7
G711u-G722 p3.2xlarge M5.2xlarge 36/100 3600 Core 2 46.17% Core 1 44.09% 34.20% 14.86% Standard 78%
(Shared) GPU I-SBC
transcoding Profile
46.62%
Core 3
38.45%
Core 4
34.60%
Core 5
23.62%
Core 6
31.68%
Core 7
AWS SLB Performance Data

Deployment Types on AWS with SLB
1. HFE/HA SBC behind HFE/HA SLB
2. HFE/HA SBC behind HA SLB

The diagram below depicts the HFE front-ending the SLB and SBC.
Pktarts are used as testing the SLB performance as UAC and UAS
600pxFor Standalone SLB/SBC, replace HFE-SLB and HFE-SBC with standalone SLB and SBC
SLB Performance Data
SLB SLB SLB SLB SLB SLB SBC Number Sessions SBC SBC SBC
Instance Sessions CPS Average Max SWe Instance of SBCs /SBC Average CPU Max SWe
Type /CHT CPU Memory Profile Type Utilization % Memory Profile
Utilization Utilization Utilization
% % %
M5. 50K 500/100 11.99% 37.04% Standard M5. 7 7K 8.56% 29.3% Default
xlarge SLB 2xlarge
(HFE) Profile (SA)
(IPv4
UDP)
M5. 50K 500/100 15.22% 36.96% Standard M5. 6 8.3K 14.67% 31.04% Default
xlarge SLB 2xlarge
(HFE) Profile (HFE
UDP HA)
C5. 50K 500/100 10.18% 42.6% Standard C5. 6 8.3K 17.04% 62.5% Default
2xlarge SLB 2xlarge
(HFE) Profile (SA)
UDP
2xlarge SLB 2xlarge
(HFE) Profile (HFE
HA)
UDP
C5. 36K 500/72 11.98% 40.71% Standard C5. 4 9K 20.65% 62.4% Default
2xlarge SLB 2xlarge (2HFE and 2
(HFE) Profile (HFE SA
UDP and SA) instances)
2xlarge SLB 2xlarge (3 HFE and
(HFE) Profile (HFE 3 SA
and SA) instances)
TLS
Note
Test parameters:
Tested using two SLB HFE EIPs for two different clients each. SLB had two backend SBCs
Tested ~4,000 session load with media enabled on m5.xlarge SLB and SBC setups
Azure Performance Metrics
In this section:
Benchmarking Setup
Instance Types
Azure SLB Performance Data
Azure Performance Data
Benchmarking Setup
The two test beds used to collect benchmarking data are depicted below.
1:1 HA SBC-CE with HFE 2.1 on Azure.

Test tools: Two PKTARTs on Azure, one for UAC in Public Subnet and other one for UAS with private Subnet.
Auzure Deployment Diagram

1. The performance number below has no alarms or any other error unless specified.
2. The limiting factor is packet loss and re-transmissions unless any other is specified(excluding trans-code).
Instance Types
S. No. Instance Type CPU RAM HDD IOPS
(GB)
1 Standard_D8s_v3 8 32 65 500
2 Standard_D3s_v3 4 16 65 500
3 Standard_D16s_v3 16 32 65 500
Due to Azure platform and network indeterministic performance, some sessions include a range to compensate.
Call Instance HFE 2.1 / CPS Simultaneous Worker Core Signaling Core UXPAD Core Average Max SWe
Memory Profile
Scenario Type Standalone /CHT Sessions CPU Utilization
Utilization %
wrkr CPU Sig CPU% UXPAD CPU%

core# % core Core #
#
G729A- Standard_D8 HFE 2.1 40/100 4000 Core 2 36.78% Core 1 29.57% NA NA 26.889% 26.81% Standard
s_v3 (Shared)
passsthrough Passthroug
36.60%
Core 3 h Profile
27.85%
Core 4
21.22%
Core 5
27.26%
Core 6
24.13%
Core 7
G711u- Standard_D8 HFE 2.1 40/100 4000 Core 2 24.08% Core 1 21.84% NA NA 19.28% 26.61% Standard
s_v3 (Shared)
23.87%
Core 3 h Profile
20.30%
Core 4
14.42%
Core 5
19.87%
Core 6
16.94%
Core 7
G729A- Standard_D8 HFE 2.1 7/84 588 Core 2 16.94% Core 1 20.25% Core 3 51.72% 34.002% 24.60% Standard
s_v3
G711u- Transcodin
Core 4 65.88%
Transcode g Profile
Core 5 61.48%
Core 6 45.44%
Core 7 1.35%
(tpad)
G711u- Standard_D8 HFE 2.1 40/100 4000 Core 2 53.97% Core 1 25.75% NA NA 28.03% 26.57% Standard
passsthrough s_v3 (Shared)
Passthroug
51.38%
TLS/SRTP Core 3 h Profile
Enabled on 23.15%
ingress leg Core 4
only 17.59%
Core 5
23.56%
Core 6
20.345%
Core 7
G711u- Standard_D8 Standalone 40/100 4000 Core 2 24.095% Core 1 33.715% Core 4 2.365% 19.26% 27.95% Standard
passsthrough s_v3 (Shared)
Passthroug
Core 3 23.785% 30.965% Core 5 1.94%
Core 6 h Profile
28.965%
Core 7
G729A- Standard_DS HFE 2.1 20/100 2000 Core 2 35.412% Core 28.63% N/A N/A 24.60% 50.69% Standard
passsthrough 3_v2 1 (Share
d) Passthroug
28.785%
h Profile
Core 3
G711u- Standard_DS HFE 2.1 20/100 2000 Core 2 38.17% Core 1 28.334% N/A N/A 24.30% 50.92% Standard
passsthrough 3_v2 (Shared)
Passthroug
35.17%
Core 3 h Profile
G729A- Standard_DS HFE 2.1 2.2/100 220 Core 2 8.00% Core 1 11.91% NA NA 22.91% 47.68% Standard
3_v2 (Shared)
G711u- Transcodin
63.731%
Transcode Core 3 g Profile
G711u- Standard_DS HFE 2.1 20/100 2000 Core 2 58.21% Core 1 27.95% NA NA 29.77% 51.36% Standard
passsthrough 3_v2 (Shared)
Passthroug
27.84%
TLS/SRTP Core 3 h Profile
Enabled on
ingress leg
only
G711u- Standard_DS Standalone 20/100 2000 Core 2 32.30% Core 1 23.143% NA NA 22.312% 50.23% Standard
3_v2 (Shared)
23.514%
Core 3 h Profile

Note
The performance number below has no alarms or any other error unless specified.
The limiting factor is packet loss and re-transmissions unless any other is specified(excluding transcode).
The core wise usage is not mentioned here as profile used is default in most of the cases, unless specified.
Accelerated Networking is enabled on packet port
Azure Performance Data

SLB Deployment Call SLB SLB SLB SLB SLB SBC No. SBC SBC SBC Transport
Instance SLB/SBC Type Sessions CPS Avg CPU Max SWe Instance of Sessions Avg CPU Max
Type /CHT Utilization Memory Active Type SBCs Utilization Memory
% Utilization Profile % Utilization
% %
Standard HFE2.1/HFE2.1 G711- 50k 500/100 16.56% 21.52% Standard Standard 7 ~7k per SBC 21.48% 30.22%
D8s v3 Passthru SLB Profile D8s v3
8vCPU 8vCPU
Standard HFE2.1/SA G711- 50k 500/100 19.02% 41.7% Standard Standard 6 ~8.3k 14.98% 25.09%
DS3 v2 Passthru SLB Profile D16s v3
4vCPU 16vCPU
Standard SA/SA G711- 50k 500/100 16.77% 21.98% Standard Standard 6 ~8.3K 22.97% 31.53%
8vCPU 8vCPU
Standard HFE2.1/HFE2.1 G711- 50k 500/100 17.47% 21.17% Standard Standard 7 ~7k 20.46% 30.3%
8vCPU 8vCPU
GCP Performance Metrics
In this section:
GCP Benchmarking Setup

Performance Metrics
Instance Type HA
Performance Tests
GCP SLB Performance Data
Deployment Types on GCP with SLB
GCP Performance Data
GCP Benchmarking Setup

GCP Deployment Diagram:
Performance Metrics
Note
Unless explicitly mentioned, the performance numbers below are collected without raising any alarms or errors.
The limiting factors are packet loss and retransmissions, unless anything is specified (excluding transcode).
The core-wise usage is not mentioned, as in most cases the Default profile is used.
SRTP Calls are executed from PKTART.
TLS/SRTP is enabled at the Public side traffic. One TLS connection (Port) is used for all calls.
Instance Type HA
S. No. Instance Type vCPU RAM HDD
(GB) (GB)
1 n1-standard-4 4 15 65
2 n1-standard-8 8 30 65
Performance Tests
S. Instance Type Instance Type Test Scenario Traffic Profile CPS Sessions Maximum CPU/Core
No. HA HFE /CHT Memory Utilization %
Utilization % (Avg/Max)
1 n1-standard-4 n1-standard-4 G711U_Pass- Default 15/100 1500 45.06% 12.2/20.82%

through
2 n1-standard-4 n1-standard-4 G729_Pass-through Default 14/100 1400 44.59% 11.40/14.75%
3 n1-standard-4 n1-standard-4 TLS SRTP_G711U Default 18/100 1800 46.08% 19.5/26.83%
4 n1-standard-4 n1-standard-4 G711U- Default 2.5/100 250 42.94% 29.15/32.36%

G729_transcode
5 n1-standard-8 n1-standard-8 G711U_Pass- Default 17/100 1700 27.27% 9.84/14.08%

through
6 n1-standard-8 n1-standard-8 TLS SRTP_G711U Default 40/100 4000 28.77% 24.53/27.64%
7 n1-standard-8 n1-standard-8 G711U-G729 Standard Transcoding 10/100 1000 24.77% 43.41/41.41%

transcode Profile
8 n1-standard-8 n1-standard-8 G729_Pass-through Default 17/100 1700 27.07% 9.65/10.04%
GCP SLB Performance Data

Deployment Types on GCP with SLB
1. Standalone SBC behind HFE/HA(2.1) SLB
2. HFE/HA(2.1) SBC behind HFE/HA(2.1) SLB
GCP Performance Data

SLB SLB SLB SLB SLB SLB SBC No. SBC SBC SBC SBC Transport
Instance Sessions CPS SWe Avg CPU Max Instance of Sessions SWe Avg CPU Max
Type /CHT Active Utiization Memory Type SBCs Active Utilization Memory
Profile % Utilization Profile % Consumed
45K 450/100 Standard 9.33% 20.98% 6 7.5K Default 13.18% 25.81% UDP
16vCPU 16vCPU
SLB Profile
(HFE2.1 (SA SBC)
SLB)
16vCPU 16vCPU
SLB Profile
(HFE2.1 (HFE2.1
SLB) SBC)
16vCPU 16vCPU
SLB Profile (3 HFE
(HFE2.1 (HFE2.1
2.1 + 3
SLB) + SA
SA)
SBCs)
In this section:
Capacity Limits
Flavor: 32 VCPU, 64 GB RAM, and 100 GB HDD
SIP Sessions and Registration Capacity Limits
SUBSCRIBE/NOTIFY Benchmark
Capacity Limits
The following table represents the capacity limits:
Type Scenario SIP Calls/Second Call Hold

(Seconds)
SLB TLS peering 7000 10
SLB UDP peering 7000 10
SLB TCP peering 7000 10
SIP Sessions and Registration Capacity Limits

The following table represents the SIP sessions and the registration capacity limits:
Type - Initial SIP Number of Interval of Refresh SIP Calls/Second

Registration/Second Subscribers REGISTER (Seconds)
SLB UDP 10,000 1.5 Million 300 3000
10,000 1.5 Million 90 2500
10,000 1.5 Million 60 1500
SLB TCP 8500 1.5 Million 300 2000
SLB TLS 2400 1 Million 3600 -
SUBSCRIBE/NOTIFY Benchmark
The following table represents the SUBSCRIBE/NOTIFY benchmarks with the ERE:
Type Scenario SUBSCRIBE REGISTER Calls SUBSCRIBEs REGISTRATIONs Calls

/Sec /Sec /Sec
SLB SUBSCRIBE with 1.5 million registrations (Subscribe from a 1.2 Million 1.5 Million - 9,000 10,000 -
registered user)
Supported SIP Headers
The SBC Core supports the SIP headers listed in this section.
Note
The SBC supports up to 20 parameters per SIP header to accommodate enhanced services such as IMS and VoLTE using call flows
such as ICS and SRVCC.
IMPORTANT
Ribbon recommends using the Transparency Profile to configure transparency on the SBC Core for new deployments, as well as applyi
ng additional transparency configurations to existing deployments. Do not use IP Signaling Profile flags in these scenarios because the
flags will be retired in upcoming releases.
Refer to the SBC SIP Transparency Implementation Guide for additional information.
Note
The SBC treats User-Agent and Server headers as known headers beginning in release 4.1.0. The SBC accepts these headers based
on ABNF grammar format and restricts them to a maximum of 10 server-vals. You must explicitly turn ON these headers for
transparency. Additionally, if a header requires more than 10 server-vals in compliance with ABNF grammar, the header must convert
to an unknown header using SMM.
SIP provides a mechanism to represent common header field names in an abbreviated form. This may be useful when messages are
too large to be carried on the transport available to it. A compact form may be substituted for the longer form of a header field name at
any time without changing the semantics of the message. A header field name may appear in both long and short forms within the
same message. A compact form of some common header field names is also defined for use when overall message size is an issue.
Any headers marked with an alternate like: ' | ' indicates the long form or the short form of the header.
In order to maintain backward capability, as of 4.1.6R0 and 4.2.4R0 releases, the SBC relaxes the ABNF grammar formatting to allow
invalid syntax server-vals plus an unlimited number of server-vals for these two headers.
The SBC does not process or send the Date header natively. If you need to pass the Date Header transparently, use the SBC’s
Header Transparency feature.
SIP Header List
Key:
= Supported
= Not supported
A
Supported Feature
Release Added
SIP Header (since 3.1.7)
Send Receive and Process
Accept
Accept-Contact|a
Accept-Language 4.0.0
Accept-Resource-Priority
Alert-Info
Allow
Also
Anonymity
Authorization
C
Supported Feature
Release Added
CallConnectId
Call-ID|i
Call-Info
Contact|m
Content-Disposition
Content-Type|c
Content-Encoding|e
Content-Length|l
CSeq
D
Supported Feature
Release Added
Diversion
E
Supported Feature
Release Added
Error-Info
Event|o
Expires
F
F
Supported Feature
Release Added
Feature-Caps 5.1.0
Flow-Timer 4.0.0
From|f
G
Supported Feature
Release Added
Geolocation
Geolocation-Error
Geolocation-Routing
H
Supported Feature
Release Added
History-Info
I
Supported Feature
Release Added
Identity 7.2.0
Info-Package 5.1.0
M
Supported Feature
Release Added
Max-Forwards
MIME-Version
Min-Expires
Min-SE
O
Supported Feature
Release Added
Overload-Control
P
Supported Feature
Release Added
P-Access-Network-Info
P-Area-Info
P-Asserted-Identity
P-Associated-URI
P-Attestation-Indicator 7.2.0
Path
P-Asserted-Service 5.1.0
P-Called-Party-ID
P-Carrier-Info
P-CDR-Info
P-Charge-Info
P-Charging-Function-Addresses
P-Charging-Vector
P-ChgMsg-Info
P-Com.Session-Info 5.1.0
P-DCS-Billing-Info 4.0.0
P-DCS-LAES
P-Early-Media
"P-K-Adn"
P-K-Cfl
P-K-Cfo
P-Orig-CA
P-Origination-ID 7.2.0
P-Preferred-Identity
P-Profile-Key 5.1.0
Privacy
Proxy-Authenticate
Proxy-Authorization
Proxy-Require
P-Sig-Info
P-Svc-Info
P-Term-CA
P-Visited-Network-ID
R
Supported Feature
Release Added
RAck
Reason
Record-Route
Recv-Info 5.1.0
Referred-By|b
Refer-Sub 4.0.0
Refer-To|r
Remote-Party-ID
Replaces
Reply-To
Requested-By
Require
Resource-Priority
Retry-After
Route
RSeq
S
Supported Feature
Release Added
Security-Client
Security-Server
Security-Verify
Server 4.0.0
Service-Route
Session-Expires|x
Sip-Etag 4.0.0
Sip-If-Match 4.0.0
Subscription-State
Supported|k
Suppress-If-Match 4.0.0
T
Supported Feature
Release Added
Target-Dialog
Timestamp
To|t
U
Supported Feature
Release Added
UnSupported
User-Agent 4.0.0
User-to-User
V
Supported Feature
Release Added
Via|v
W
Supported Feature
Release Added
Warning 4.0.0
WWW-Authenticate
X
Supported Feature
Release Added
X-ATP
X-AUT
X-BCI
X-CALLING-NUM
X-Carrier-Info
X-CHGDelay
X-CHGInfo
X-CONTRACT-ADDR
X-EMG
X-FCI
X-FWDORIG-NUM
X-GENERIC-NUM
X-ISUPEvent
X-ISUPMtype
X-MS-MediaPath 8.2
X-MS-UserLocation 8.2
X-NOCI
X-OBCI
X-ORIGCLD-NUM
X-REDBWDINF
X-REDCAP
X-REDCNT
X-REDFWDINF
X-Service-Indicator
X-Service-Type
X-TMR
X-USI
Supported Standards
In this section:
Supported Standards
3GPP
ETSI
GSMA
IETF
ITU
NENA
SIP Forum
PacketCable
Telecommunication Technology Committee
Other Specifications
References
Supported Standards
The following standards are supported to the extent that pertains to Ribbon product features to which they apply. The entire standard
is not necessarily supported, only the section(s) of the standard that impact a given feature.
3GPP
Table 1: Supported 3GPP Standards
Standard Description
3GPP TS Customized Applications for Mobile network Enhanced Logic (CAMEL); Service description; Stage 1
22.078
3GPP TS IP Multimedia Subsystem, Stage 1

22.228
3GPP TS Group Services and Systems Aspects; Network architecture

23.002
3GPP TS Numbering, Addressing and Identifications

23.003
3GPP TS Basic call handling; Technical realization

23.018
3GPP TS Customized Applications for Mobile network Enhanced Logic (CAMEL) Stage 2
23.078
3GPP TS Presence Service, Architecture and functional description

23.141
3GPP TS Policy and charging control architecture

23.203
3GPP TS End-to-end Quality of Service (QoS) concept and architecture

23.207
3GPP TS IP Multimedia (IM) session handling; IM call model; Stage 2

23.218
3GPP TS Architectural requirements

23.221
3GPP TS IP Multimedia Subsystem (IMS); Stage 2

23.228:
3GPP TS IP Multimedia Subsystem (IMS) Service Continuity; Stage 2

23.237
3GPP TS IP Multimedia System (IMS) centralized services; Stage 2
23.292
3GPP TS Conferencing using the IP Multimedia (IM) Core Network (CN) subsystem; Stage 3
24.147
3GPP TS IMS Multimedia telephony service and supplementary services; Stage 3

24.173
3GPP TS Internet Protocol (IP) multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description
24.229 Protocol (SDP); Stage 3
3GPP TS Messaging service using the IP Multimedia (IM) Core Network (CN) subsystem; Stage 3
24.247
3GPP TS Support of SMS over IP networks; Stage 3

24.341
3GPP TS Communication Diversion (CDIV) using IP Multimedia (IM)Core Network (CN) subsystem; Protocol specification
24.604
3GPP TS Conference (CONF) using IP Multimedia (IM) Core Network (CN) subsystem; Protocol specification
24.605
3GPP TS Message Waiting Indication (MWI )using IP Multimedia (IM) Core Network (CN) subsystem; Protocol specification
24.606
3GPP TS Originating Identification Presentation (OIP) and Originating Identification Restriction (OIR) using IP Multimedia (IM) Core
24.607 Network (CN) subsystem; Protocol specification
3GPP TS Terminating Identification Presentation (TIP) and Terminating Identification Restriction (TIR) using IP Multimedia (IM) Core
24.608 Network (CN) subsystem; Protocol specification
3GPP TS Communication HOLD (HOLD) using IP Multimedia (IM) Core Network (CN) subsystem; Protocol specification
24.610
3GPP TS Anonymous Communication Rejection (ACR) and Communication Barring (CB) using IP Multimedia (IM) Core Network (CN)
24.611 subsystem; Protocol specification
3GPP TS Communication Waiting (CW) using IP Multimedia (IM) Core Network (CN) subsystem; Protocol Specification
24.615
3GPP TS Extensible Markup Language (XML) Configuration Access Protocol (XCAP) over the Ut interface for Manipulating Simulation
24.623 Services
3GPP TS Mandatory speech CODEC speech processing functions; AMR speech Codec; General description
26.071
3GPP TS Mandatory Speech Codec speech processing functions; Adaptive Multi-Rate (AMR) speech codec; Transcoding functions
26.090
3GPP TS Mandatory speech codec speech processing functions Adaptive Multi-Rate (AMR) speech codec; Source controlled rate
26.093 operation
3GPP TS Speech codec list for GSM and UMTS

26.103
3GPP TS IP Multimedia Subsystem (IMS); Multimedia telephony; Media handling and interaction
26.114
3GPP TS Terminal acoustic characteristics for telephony; Requirements

26.131
3GPP TS Speech and video telephony terminal acoustic test specification

26.132
3GPP TS Packet Switched Conversational Multimedia Application; Default Codecs

26.235
3GPP TS Packet Switched Conversational Multimedia Applications; Transport Protocols

26.236
3GPP TS Customized Applications for Mobile network Enhanced Logic (CAMEL) Phase 3; CAMEL Application Part (CAP) specification
29.002
29.078
3GPP TS Inter-IMS Network to Network Interface (NNI)

29.165
3GPP TS Media Gateway Control Function (MGCF) - IM Media Gateway (IM-MGW) Mc interface; Stage 3
29.332
3GPP TS Interworking between the IM CN subsystem and IP networks

29.162
3GPP TS Interworking between the IP Multimedia (IM) Core Network (CN) subsystem and Circuit switched (CS) Networks
29.163
3GPP TS Interworking between SIP-I based circuit-switched core network and other networks
29.235
3GPP TS Proxy Mobile IPv6 (PMIPv6) based Mobility and Tunnelling Protocols
29.275
3GPP TS Domain Name System Procedures; Stage 3

29.303
3GPP TS InterWorking Function (IWF) between MAP based and Diameter based interfaces”
29.305
3GPP TS Multimedia Resource Function Controller (MRFC) - Multimedia Resource Function Processor (MRFP) Mp interface; Stage 3
29.333
3GPP TR Signalling interworking between the 3GPP profile of the Session Initiation Protocol (SIP) and non-3GPP SIP usage
29.962
3GPP TS Telecommunication management; Charging management; Charging data description for the IP Multimedia Subsystem (IMS)
32.225
3GPP TS Telecommunication management; Charging management; IP Multimedia Subsystem (IMS) charging

32.260
3GPP TS Telecommunication management; Charging management; Charging data description for CS domain
32.205
3GPP TS Telecommunication management; Charging management; Charging data description for PS domain
32.215
3GPP TS Telecommunication management; Charging management; Charging data description for IMS domain
32.225
3GPP TS Telecommunication management; Charging management; Charging data description for application services
32.235
3GPP TS Telecommunication management; Charging management; Charging architecture and principles

32.240
3GPP TS Telecommunication management; Charging management; Circuit Switched (CS) domain charging
32.250
3GPP TS Telecommunication management; Charging management; Packet Switched (PS) domain charging
32.251
3GPP TS Telecommunication management; Charging management; Wireless Local Area Network (WLAN) charging
32.252

32.260
3GPP TS Telecommunication management; Charging management; Multimedia Messaging Service (MMS) charging
32.270
3GPP TS Telecommunication management; Charging management; Location Services (LCS) charging

32.271
3GPP TS Telecommunication management; Charging management; Push-to-talk over Cellular (PoC) charging
32.272
3GPP TS Telecommunication management; Charging management; Multimedia Broadcast and Multicast Service (MBMS) charging
32.273
3GPP TS Telecommunication management; Charging management; Multimedia Telephony (MMTel) charging

32.275
3GPP TS Telecommunication management; Charging management; Charging Data Record (CDR) transfer
32.295
3GPP TS Telecommunication management; Charging management; Online Charging System (OCS): Applications and interfaces
32.296
3GPP TS Telecommunication management; Charging management; Charging Data Record (CDR) file format and transfer
32.297
3GPP TS Telecommunication management; Charging management; Charging Data Record (CDR) parameter description
32.298
3GPPTS Telecommunication management; Charging management; Diameter charging applications

32.299
3GPP TS 3G security; Access security for IP-based services

33.203
3GPP TS IP Network Level Security

33.210
3GPP TR Security aspects of early IP Multimedia Subsystem (IMS)

33.978
3GPP 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Codec for Enhanced Voice
26.441 Services (EVS); General Overview
3GPP TR Signalling interworking between the 3GPP profile of the Session Initiation Protocol (SIP) and non-3GPP SIP usage
29.962
3GPP TR Security aspects of early IP Multimedia Subsystem (IMS)

33.978
3GPP TS Customized Applications for Mobile network Enhanced Logic (CAMEL); Service description; Stage 1
22.078
3GPP TS 3rd Generation Partnership Project;

22.228 Technical Specification Group Services and System Aspects;
Service requirements for the Internet Protocol (IP) Multimedia core network Subsystem (IMS); Stage 1
3GPP TS Group Services and Systems Aspects; Network architecture

23.002

23.003 Technical Specification Group Core Network and Terminals; Numbering, addressing and identification
3GPP TS 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Support of Dual Tone Multi-
23.014 Frequency (DTMF) signalling
3GPP TS Basic call handling; Technical realization

23.018
3GPP TS Customized Applications for Mobile network Enhanced Logic (CAMEL) Stage 2
23.078
3GPP TS Presence Service, Architecture and functional description

23.141
3GPP TS IMS Emergency Sessions

23.167
3GPP TS 3rd Generation Partnership Project;. Technical Specification Group Services and Systems Aspects; Policy and charging control
23.203 architecture
3GPP TS End-to-end Quality of Service (QoS) concept and architecture

23.207
3GPP TS IP Multimedia (IM) session handling; IM call model; Stage 2

23.218
3GPP TS Architectural requirements
23.221
3GPP TS 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; IP Multimedia Subsystem
23.228 (IMS);Stage 2
3GPP TS WLAN Interworking

23.234
3GPP TS IP Multimedia Subsystem (IMS) Service Continuity; Stage 2

23.237
3GPP TS IP Multimedia System (IMS) centralized services; Stage 2

23.292
3GPP TS Conferencing using the IP Multimedia (IM) Core Network (CN) subsystem; Stage 3
24.147
3GPP TS 3rd Generation Partnership Project Technical Specification Group Core Network and Terminals;; IMS multimedia telephony
24.173 communication service and supplementary services; Stage 3
3GPP TS 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; IP Multimedia Subsystem
24.182 (IMS) Customized Alerting Tones (CAT); Protocol specification
3GPP TS 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; IP Multimedia Subsystem
24.183 (IMS) Customized Ringing Signal (CRS); Protocol specification
3GPP TS 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; IP multimedia call control
24.229 protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3
3GPP TS 3rd Generation Partnership Project; IP Multimedia (IM) Core Network (CN) subsystem IP Multimedia Subsystem (IMS) service
24.237 continuity; Stage 3
3GPP TS 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Flexible Alerting (FA) using IP
24.239 Multimedia (IM) Core Network (CN) subsystem; Protocol specification
3GPP TS Messaging service using the IP Multimedia (IM) Core Network (CN) subsystem; Stage 3
24.247
3GPP TS 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Personal Network
24.259 Management (PNM); Stage 3
3GPP TS Support of SMS over IP networks; Stage 3

24.341

24.604 Technical Specification Group Core Network and Terminals; Communication Diversion (CDIV) using IP Multimedia (IM) Core
Network (CN) subsystem; Protocol specification

24.605 Technical Specification Group Core Network and Terminals; Conference (CONF) using IP Multimedia (IM) Core Network (CN)
subsystem; Protocol specification
3GPP TS Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); LTE; Message
24.606 Waiting Indication (MWI) using IP Multimedia (IM) Core Network (CN) subsystem; Protocol specification
3GPP TS 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Originating Identification
24.607 Presentation (OIP) and Originating Identification Restriction (OIR) using IP Multimedia (IM) Core Network (CN) subsystem;
Protocol specification

24.608 Technical Specification Group Core Network and Terminals; Terminating Identification Presentation (TIP)
and Terminating Identification Restriction (TIR) using IP
Multimedia (IM) Core Network (CN) subsystem; Protocol specification

24.610 Technical Specification Group Core Network and Terminals; Communication HOLD (HOLD) using IP Multimedia (IM) Core

24.611 Technical Specification Group Core Network and Terminals; Anonymous Communication Rejection (ACR) and Communication
Barring (CB); using IP Multimedia (IM) Core Network (CN) subsystem; Protocol specification

24.615 Technical Specification Group Core Network and Terminals; Communication Waiting (CW) using IP Multimedia (IM) Core
24.616 Technical Specification Group Core Network and Terminals; Malicious Communication Identification (MCID) using IP
Multimedia (IM) Core Network (CN) subsystem; Protocol specification
3GPP TS Extensible Markup Language (XML) Configuration Access Protocol (XCAP) over the Ut interface for Manipulating Simulation
24.623 Services

24.628 Technical Specification Group Core Network and Terminals;
Common Basic Communication procedures using IP Multimedia (IM) Core Network (CN) subsystem

24.629 Technical Specification Group Core Network and Terminals; Explicit Communication Transfer (ECT) using IP Multimedia (IM)
Core Network (CN) subsystem;
Protocol specification

24.642 Technical Specification Group Core Network and Terminals;
Completion of Communications to Busy Subscriber (CCBS) and Completion of Communications by No Reply (CCNR)
using IP Multimedia (IM) Core Network (CN) subsystem; Protocol specification
3GPP TS Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS);
24.654 LTE; Closed User Group (CUG) using IP Multimedia (IM) Core Network (CN) subsystem, Protocol Specification)
3GPP TS Mandatory speech CODEC speech processing functions; AMR speech Codec; General description
26.071
3GPP TS 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; ANSI-C code for the
26.073 Adaptive Multi Rate (AMR) speech codec
3GPP TS Mandatory Speech Codec speech processing functions; Adaptive Multi-Rate (AMR) speech codec; Transcoding functions
26.090
3GPP TS Mandatory speech codec speech processing functions Adaptive Multi-Rate (AMR) speech codec; Source controlled rate
26.093 operation
3GPP TS Speech codec list for GSM and UMTS

26.103
3GPP TS 3rd Generation Partnership Project;Technical Specification Group Services and System Aspects; IP Multimedia Subsystem
26.114 (IMS); Multimedia Telephony; Media handling and interaction
3GPP TS Terminal acoustic characteristics for telephony; Requirements

26.131
3GPP TS Speech and video telephony terminal acoustic test specification

26.132
3GPP TS Packet Switched Conversational Multimedia Application; Default Codecs

26.235
3GPP TS Packet Switched Conversational Multimedia Applications; Transport Protocols

26.236
3GPP TS Universal Mobile Telecommunications System (UMTS); LTE; Codec for Enhanced Voice Services (EVS); Detailed algorithmic
26.445 description
29.002
29.078
3GPP TS Interworking between the IM CN subsystem and IP networks

29.162
3GPP TS Interworking between the IP Multimedia (IM) Core Network (CN) subsystem and Circuit switched (CS) Networks
29.163
3GPP TS 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Inter-IMS Network to Network
29.165 Interface (NNI)
3GPP TS Interworking between SIP-I based circuit-switched core network and other networks
29.235
3GPP TS 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Domain Name System
29.303 Procedures; Stage 3
3GPP TS InterWorking Function (IWF) between MAP based and Diameter based interfaces”
29.305
3GPP TS Media Gateway Control Function (MGCF) - IM Media Gateway (IM-MGW) Mc interface; Stage 3
29.332
3GPP TS Multimedia Resource Function Controller (MRFC) - Multimedia Resource Function Processor (MRFP) Mp interface; Stage 3
29.333
3GPP TS Telecommunication management; Charging management; Charging data description for CS domain
32.205
3GPP TS Telecommunication management; Charging management; Charging data description for PS domain
32.215
3GPP TS Telecommunication management; Charging management; Charging data description for the IP Multimedia Subsystem (IMS)
32.225
3GPP TS Telecommunication management; Charging management; Charging data description for application services
32.235
3GPP TS Telecommunication management; Charging management; Charging architecture and principles

32.240
3GPP TS Telecommunication management; Charging management; Circuit Switched (CS) domain charging
32.250
3GPP TS Telecommunication management; Charging management; Packet Switched (PS) domain charging
32.251
3GPP TS Telecommunication management; Charging management; Wireless Local Area Network (WLAN) charging
32.252

32.260
3GPP TS Telecommunication management; Charging management; Multimedia Messaging Service (MMS) charging
32.270
3GPP TS Telecommunication management; Charging management; Location Services (LCS) charging

32.271
3GPP TS Telecommunication management; Charging management; Push-to-talk over Cellular (PoC) charging
32.272
3GPP TS Telecommunication management; Charging management; Multimedia Broadcast and Multicast Service (MBMS) charging
32.273
3GPP TS Telecommunication management; Charging management; MultiMedia Telephony (MMTel) charging

32.275
3GPP TS Telecommunication management; Charging management; Charging Data Record (CDR) transfer
32.295
3GPP TS Telecommunication management; Charging management; Online Charging System (OCS): Applications and interfaces
32.296
3GPP TS Telecommunication management; Charging management; Charging Data Record (CDR) file format and transfer
32.297
3GPP TS Telecommunication management; Charging management; Charging Data Record (CDR) parameter description
32.298
3GPP TS 3G security; Access security for IP-based services

33.203
3GPP TS IP Network Level Security

33.210
3GPP TS Telecommunication management; Charging management; Diameter charging applications

32.299
ETSI
Table 2: Supported ETSI Standards
ETSI ES 282 001 NGN Functional Architecture Release 1
ETSI ES 282 002 PSTN/ISDN Emulation Sub-system (PES); Functional architecture
ETSI ES 282 003 Resource and Admission Control Sub-system (RACS); Functional Architecture
ETSI ES 282 004 Network Attachment Sub-System (NASS)
ETSI ES 282 007 NGN IMS Architecture
ETSI EN 383 001 Interworking for SIP/SIP-T (BICC, ISUP)
ETSI ES 283 002 PSTN/ISDN Emulation Subsystem (PES); H.248 ARG control
ETSI ES 283 003 NGN SIP and SDP
ETSI TS 181 005 Services and Capabilities Requirements
ETSI TS 181 006 Services and Capabilities Requirements for TISPAN NGN Rel. 1
ETSI TR 182 005 NGN User data
ETSI TS 182 006 IMS stage 2 Endorsement
ETSI TS 182 012 IMS-based PSTN/ISDN Emulation Subsystem; Functional Architecture
ETSI TS 183 002 Common Basis Communication Procedures, Protocol Specification
ETSI TS 183 043 IMS-based PSTN/ISDN Emulation Stage 3 Specification
ETSI TS 185 001 Quality of Service (QoS) Framework and Requirements
ETSI TS 187 001 NGN Security requirements
ETSI TS 187 003 Security Architecture
ESTI EN 300 356-1 Integrated Services Digital Network (ISDN); Signalling System No.7; ISDN User Part (ISUP) version 3 for the
international interface; Part 1: ISUP Basic services[ITU T Recommendations Q.761 to Q.764 (1997), modified
ETSI ES 201 235- Access and Terminals (AT); Specification of Dual-Tone Multi-Frequency (DTMF) Transmitters and Receivers; Part 2:
2 V1.2.1 (2002-03) Transmitters
ETSI ETS 300 374- Intelligent Network (IN); Intelligent Network Capability Set 1 (CS1); Core Intelligent Network Application Protocol
1 (INAP); Part 1: Protocol specification
ETSI PRI (Q.931 – Integrated Services Digital Network (ISDN); Digital Subscriber Signalling System No. One (DSS1) Protocol; Signalling
ETSI EN 300-403) Network Layer for Circuit- Mode Basic Call Control; Protocol Specification
ETSI TR 103 393 Emergency Communications (EMTEL); Advanced Mobile Location for emergency calls
V1.1.1 (2016-03)
GSMA
Table 3: Supported GSMA Standards
GSMA BA27 Charging and Accounting Principles
GSMA IR.34 Guidelines for IPX Provider networks (Previously Inter-Service Provider IP Backbone Guidelines)
GSMA IR.65 IMS Roaming and Interworking Guidelines
GSMA IR.67 DNS/ENUM Guidelines for Service Providers and GRX/IPX Providers
GSMA IR.74 Video Share Interoperability Specification
GSMA IR.77 Inter-Operator IP Backbone Security Requirements For Service Providers and Inter-operator IP backbone Providers
GSMA IR.79 Image Share Interoperability Specification
GSMA IR.83 SIP-I Interworking Description
GSMA IR.84 Video Share Phase 2 Interoperability Specification
GSMA IR.88 LTE Roaming Guidelines
GSMA IR.90 RCS Interworking Guidelines
GSMA IR.92 IMS Profile for Voice and SMS
GSMA IR.94 IMS Profile for Conversational Video Service
GSMA IR.95 SIP – SDP Inter-IMS NNI Profile
GSMA NGRAI Next Generation Roaming and Interoperability (NGRAI) Project Scope White Paper
GSMA RCC.07 Rich Communication Suite 5.1 Advanced Communications Services and Client Specification
GSMA RCC.71 RCS Universal Profile Service Definition Document
GSMA SE.35 IMS Services and Applications
IETF
Table 4: Supported IETF Standards
RFC 768 User Datagram Protocol
RFC 791 (updated by RFC 1349) Internet Protocol (Type of Service in the Internet Protocol Suite)
RFC 792 (updated by RFC 950, RFC Internet Control Message Protocol
4884)
RFC 793 (updated by RFC 3168) Transmission Control Protocol
RFC 826 Ethernet Address Resolution Protocol
RFC 1305 Network Time Protocol (Version 3) Specification, Implementation
RFC 1393 Traceroute Using an IP Option
RFC 1591 Domain Name System Structure and Delegation
RFC 1631 The IP Network Address Translator (NAT)
RFC 1771 Border Gateway Protocol-4
RFC 1812 (updated by RFC 2644) Requirements for IP Version 4 Routers - IETF tools
RFC 1878 Variable Length Subnet Table For IPv4
RFC 1889 RTP: A Transport Protocol for Real-Time Applications
RFC 1918 Address Allocation for Private Internets
RFC 1966/2796 Route Reflectors
RFC 1981 Path MTU Discovery for IP version 6
RFC 1997 BGP Communities Attribute
RFC 2198 RTP Payload for Redundant Audio Data
RFC 2283/2858 Multiprotocol Extensions for BGP-4
RFC 2327 SDP
RFC 2409 The Internet Key Exchange (IKE)
RFC 2410 The NULL Encryption Algorithm and Its Use With Ipsec
RFC 2439 BGP Route Flap Damping
RFC 2460 Internet Protocol Version 6 (IPv6) Specification
RFC 2461 (updated by 4311) Neighbor Discovery for IP Version 6 (IPv6)
RFC 2464 Transmission of IPv6 Packets over Ethernet Networks
RFC 2465 Management Information Base for IP Version 6
RFC 2474 Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers
RFC 2475 An Architecture for Differentiated Services
RFC 2544 Benchmarking Methodology for Network Interconnect Devices
RFC 2617 HTTP Authentication: Basic and Digest Access Authentication
RFC 2675 IPv6 Jumbograms
RFC 2697 A Single Rate Three Color Marker
RFC 2698 A Two Rate Three Color Marker
RFC 2711 IPv6 Router Alert Option
RFC 2740 OSPF for IPv6
RFC 2766 (updated by 3152) Network Address Translation - Protocol Translation (NAT-PT)
RFC 2865 (updated by 2868, RFC Remote Authentication Dial In User Service (RADIUS)
3575)
RFC 2866 (updated by RFC 2867) RADIUS Accounting
RFC 2833 RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals
RFC 2915 The Naming Authority Pointer (NAPTR) DNS Resource Record
RFC 2916 E.164 number and DNS
RFC 2918 Route Refresh Capability for BGP-4
RFC 2976 The SIP INFO Method
RFC 3065 Autonomous System Confederations for BGP
RFC 3087 Control of Service Context using SIP Request-URI
RFC 3095 RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and
uncompressed
RFC 3140 Per Hop Behavior Identification Codes
RFC 3164 The BSD Syslog Protocol
RFC 3204 MIME media type ISUP
RFC 3246 An Expedited Forwarding PHB (Per-Hop Behavior)
RFC 3260 New Terminology and Clarifications for Diffserv
RFC 3261 SIP: Session Initiation Protocol (SIP)
RFC 3262 Reliability of Provisional Responses in Session Initiation Protocol (SIP)
RFC 3263 Session Initiation Protocol (SIP): Locating SIP Servers
RFC 3264 An Offer/Answer Model with the Session Description Protocol (SDP)
RFC 3265 Session Initiation Protocol (SIP) - Specific Event Notification
RFC 3267 (2002) Real-time Transport Protocol RTP Payload Format and File Storage Format for Audio Codecs
RFC 3309 Stream Control Transmission Protocol (SCTP) Checksum
RFC 3311 The Session Initiation Protocol (SIP) UPDATE Method
RFC 3312 Integration of Resource Management and Session Initiation Protocol (SIP)
RFC 3313 Private Session Initiation Protocol (SIP) Extensions for Media Authorization
RFC 3319 Dynamic Host Configuration Protocol (DHCPv6) Options for Session Initiation Protocol (SIP)
Servers
RFC 3323 A Privacy Mechanism for the Session Initiation Protocol (SIP)
RFC 3324 Short Term Requirements for Network Asserted Identity
RFC 3325 Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted
Networks
RFC 3326 The Reason Header Field for the Session Initiation Protocol (SIP)
RFC 3327 Session Initiation Protocol (SIP) Extension Header Field for Registering Non- Adjacent Contacts
RFC 3329 Security Mechanism Agreement for the Session Initiation Protocol (SIP)
RFC 3361 Dynamic Host Configuration Protocol (DHCP-for-IPv4) Option for Session Initiation Protocol (SIP)
Servers
RFC 3372 Session Initiation Protocol for Telephones (SIP-T): Context and Architectures
RFC 3389 Real-time Transport Protocol (RTP) Payload for Comfort Noise (CN)
RFC 3398 ISUP to SIP Mapping
RFC 3411 An Architecture for Describing SNMP Management Frameworks
RFC 3412 Message Processing and Dispatching for SNMP
RFC 3413 Simple Network Management Protocol (SNMP) Applications
RFC 3414 User-based Security Model (USM) for version 3 of the Simple Network Management
RFC 3415 View-based Access Control Model (VACM) for the SNMP
RFC 3418 Management Information Base (MIB) for the SNMP
RFC 3420 Internet Media Type message/sipfrag
RFC 3428 Session Initiation Protocol (SIP) Extension for Instant Messaging
RFC 3436 Transport Layer Security over Stream Control Transmission Protocol
RFC 3455 Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3rd-
Generation Partnership Project (3GPP)
RFC 3484 Default Address Selection for Internet Protocol version 6 (IPv6)
RFC 3486 Compressing the Session Initiation Protocol (SIP)
RFC 3513 Internet Protocol Version 6 (IPv6) Addressing Architecture
RFC 3515 The Session Initiation Protocol (SIP) Refer Method
RFC 3550 RTP: A Transport Protocol for Real-Time Applications
RFC 3551 RTP Profile for Audio and Video Conferences with Minimal Control
RFC 3556 Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP)
Bandwidth
RFC 3581 An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing
RFC 3584 SIP Extension for Symmetric Response Routing
RFC 3588 Diameter Base Protocol
RFC 3596 DNS Extensions to Support IP Version 6
RFC 3605 Real Time Control Protocol (RTCP) attribute in SDP
RFC 3608 Session Initiation Protocol (SIP) Extension Header Field for Service Route Discovery During
Registration
RFC 3611 RTP Control Protocol Extended Reports (RTCP XR)
RFC 3680 A Session Initiation Protocol (SIP) Event Package for Registrations
RFC 3711 Secure Real-time Transport Protocol
RFC 3715 IPsec-Network Address Translation (NAT) Compatibility Requirements
RFC 3761 The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS)
Application (ENUM)
RFC 3768 Virtual Router Redundancy Protocol (VRRP)
RFC 3826 The Advanced Encryption Standard (AES) Cipher Algorithm in the SNMP User-
RFC 3840 Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)
RFC 3841 Caller Preferences for the Session Initiation Protocol (SIP)
RFC 3842 A Message Summary and Message Waiting Indication Event Package for the Session Initiation
Protocol (SIP)
RFC 3859 Common Profile for Presence (CPP)
RFC 3862 Common Presence and Instant Messaging (CPIM): Message Format
RFC 3891 The Session Initiation Protocol (SIP) "Replaces" Header
RFC 3892 The Session Initiation Protocol (SIP) Referred-By Mechanism
RFC 3903 Session Initiation Protocol (SIP) Extension for Event State Publication
RFC 3911 The Session Initiation Protocol (SIP) "Join" Header
RFC 3947 Negotiation of NAT-Traversal in the IKE
RFC 3948 UDP Encapsulation of IPsec ESP Packets
RFC 3951 Internet Low Bit Rate Codec (iLBC)
RFC 3952 RTP Payload Format for iLBC (internet Low Bit Rate Codec) Speech
RFC 3959 The Early Session Disposition Type for the Session Initiation Protocol (SIP)
RFC 3960 Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP)
RFC 3966 The tel URI for Telephone Numbers
RFC 3971 Secure Neighbor Discovery for IPv6 (No support for certification paths anchored on trusted parties)
RFC 3972 Cryptographically Generated Addresses
RFC 3994 Indication of Message Composition for Instant Messaging
RFC 4006 Diameter Credit-Control Application
RFC 4022 Management Information Base for the Transmission Control Protocol (TCP)
RFC 4028 Session Timers in the Session Initiation Protocol (SIP)
RFC 4032 Update to the Session Initiation Protocol (SIP) Preconditions Framework
RFC 4092 Usage of the Session Description Protocol (SDP) Alternative Network Address Types (ANAT)
Semantics in the Session Initiation Protocol (SIP)
RFC 4103 RTP Payload for Text Conversation
RFC 4113 Management Information Base for the User Datagram Protocol (UDP)
RFC 4109 Algorithms for Internet Key Exchange version 1 (IKEv1)
RFC 4117 Transcoding Services Invocation in the Session Initiation Protocol (SIP) Using Thurd Party Call
Control (3pcc)
RFC 4119 A Presence-based GEOPRIV Location Object Format
RFC 4123 Session Initiation Protocol (SIP)-H.323 Interworking Requirements
RFC 4145 TCP-Based Media Transport in the Session Description Protocol (SDP)
RFC 4168 The Stream Control Transmission Protocol (SCTP) as a Transport for the Session Initiation Protocol
(SIP)
RFC 4213 Basic Transition Mechanisms for IPv6 Hosts and Routers
RFC 4291 Internet Protocol Version 6 (IPv6) Addressing Architecture”; RFC3513 (Obsoletes RFC2373,
Obsoleted by RFC4291)
RFC 4292 IP Forwarding Table MIB
RFC 4293 Management Information Base for the Internet Protocol (IP)
RFC 4294 IPv6 Node Requirements
RFC 4240 Basic Network Media Services with SIP
RFC 4244 An Extension to the Session Initiation Protocol (SIP) for Request History Information
RFC 4293 Management Information Base for the Internet Protocol (IP)
RFC 4301 Security Architecture for the Internet Protocol
RFC 4302 IP Authentication Header
RFC 4303 IP Encapsulating Security Payload (ESP)
RFC 4306 Internet Key Exchange (IKEv2) Protocol
RFC 4307 Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2)
RFC 4308 Cryptographic Suites for Ipsec
RFC 4320 Actions Addressing Identified Issues with the Session Initiation Protocol’s (SIP) Non-INVITE
Transaction
RFC 4412 Communications Resource Priority for the Session Initiation Protocol (SIP)
RFC 4443 Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification
RFC 4457 The Session Initiation Protocol (SIP) P-User-Database Private-Header (P-Header)
RFC 4458 Session Initiation Protocol (SIP) URIs for Applications such as Voicemail and Interactive Voice
Response (IVR)
RFC 4482 CIPID: Contact Information for the Presence Information Data Format
RFC 4488 Suppression of Session Initiation Protocol (SIP) REFER Method Implicit Subscription
RFC 4538 Request Authorization through Dialog Identification in the Session Initiation Protocol (SIP)
RFC 4566 Session Description Protocol (SDP)
RFC 4567 Key Management Extensions for SDP and RTSP
RFC 4568 SDP Security Descriptions for Media Streams
RFC 4572 Connection-Oriented Media Transport over the Transport Layer Security (TLS)
RFC 4573 MIME Type Registration for RTP Payload Format for H.224
RFC 4575 A Session Initiation Protocol (SIP) Event Package for Conference State
RFC 4583 Session Description Protocol (SDP) Format for Binary Floor Control Protocol
RFC 4585 Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP
/AVPF)
RFC 4629 RTP Payload Format for ITU-T Rec. H.264 Video
RFC 4662 A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists
RFC 4694 Number Portability Parameters for the "tel" URI
RFC 4730 A Session Initiation Protocol (SIP) Event Package for Key Press Stimulus (KPML)
RFC 4733 RTP Payload for DTMF Digits; Telephony Tones; and Telephony Signals
RFC 4740 Diameter Session Initiation Protocol (SIP) Application
RFC 4753 ECP Groups for IKE and IKEv2
RFC 4815 RObust Header Compression (ROHC): Corrections and Clarifications to RFC 3095
RFC 4821 Packetization Layer Path MTU Discovery
RFC 4835 Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP)
and Authentication Header (AH)
RFC 4861 Neighbor Discovery for IP Version 6 (IPv6)
RFC 4862 IPv6 Stateless Address Autoconfiguration
RFC 4867 RTP Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive
Multi-Rate Wideband (AMR-WB) Audio Codecs
RFC 4855 Media Type Registration of Payload Formats in the RTP Profile for Audio and Video Conferences
RFC 4891 Using IPsec to Secure IPv6-in-IPv4 Tunnels
RFC 4916 Connected Identity in the Session Initiation Protocol (SIP)
RFC 4961 Symmetric RTP / RTP Control Protocol (RTCP)
RFC 4964 The P-Answer-State Header Extension to the Session Initiation Protocol for the Open Mobile
Alliance Push to Talk over Cellular
RFC 4967 Dial String Parameter for the Session Initiation Protocol Uniform Resource Identifier
RFC 4975 Message Session Relay Protocol (MSRP)
RFC 4976 Relay Extensions for the Message Session Relay Protocol (MSRP)
RFC 5002 The Session Initiation Protocol (SIP)P-Profile-Key Private Header (P-Header)
RFC 5009 Private Header (P-Header) Extension to the Session Initiation Protocol (SIP) for Authorization of
Early Media
RFC 5025 Presence Authorization Rules
RFC 5031 A Uniform Resource Name (URN) for Emergency and Other Well-Known Services
RFC 5049 Applying Signaling Compression (SigComp) to the Session Initiation Protocol (SIP)
RFC 5067 Infrastructure ENUM Requirements
RFC 5079 ACR Response Code
RFC 5095 Network Time Protocol Version 4 (for IPv6)
RFC 5104 Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)
RFC 5139 Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO)
RFC 5168 XML Schema for Media Control
RFC 5227 IPv4 Address Conflict Detection
RFC 5245 Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols
RFC 5282 Using Authenticated Encryption Algorithms with the Encrypted Payload of the Internet Key
Exchange version 2 (IKEv2) Protocol
RFC 5285 A General Mechanism for RTP Header Extensions
RFC 5318 The Session Initiation Protocol (SIP) P-Refused-URI-List Private-Header (P- Header)
RFC 5343 Simple Network Management Protocol (SNMP) Context EngineID Discovery
RFC 5359 Session Initiation Protocol Service Examples
RFC 5360 A Framework for Consent-Based Communications in the Session Initiation Protocol (SIP)
RFC 5365 Multiple-Recipient MESSAGE Requests in the Session Initiation Protocol (SIP)
RFC 5366 Conference Establishment Using Request-Contained Lists in the Session Initiation Protocol (SIP)
RFC 5367 Subscriptions to Request-Contained Resource Lists in the Session Initiation Protocol (SIP)
RFC 5368 Referring to Multiple Resources in the Session Initiation Protocol (SIP)
RFC 5373 Requesting Answering Modes for the Session Initiation Protocol (SIP)
RFC 5393 Addressing an Amplification Vulnerability in Session Initiation Protocol (SIP) Forking Proxies
RFC 5438 Instant Message Disposition Notification (IMDN)

RFC 5438 Errata
RFC 5491 GEOPRIV Presence Information Data Format Location Object (PIDF-LO)Usage Clarification,
Considerations, and Recommendations
RFC 5502 The SIP P-Served-User Private-Header (P-Header) for the 3GPP IP Multimedia (IM) Core Network
(CN) Subsystem
RFC 5503 Private Session Initiation Protocol (SIP) Proxy-to-Proxy Extensions for Supporting
RFC 5547 SDP Offer/Answer Mechanism To Enable File Transfer
RFC 5552 SIP Interface to VoiceXML Media Services
RFC 5590 Transport Subsystem for the Simple Network Management Protocol (SNMP)
RFC 5621 Message Body Handling in the Session Initiation Protocol (SIP)
RFC 5626 Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)
RFC 5627 Obtaining and Using Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol
(SIP)
RFC 5658 Addressing Record-Route Issues in the Session Initiation Protocol (SIP)
RFC 5688 A Session Initiation Protocol (SIP) Media Feature Tag for MIME Application Subtypes
RFC 5705 Keying Material Exporters for Transport Layer Security (TLS)
RFC 5763 Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using
Datagram Transport Layer Security (DTLS)
RFC 5764 Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time
Transport Protocol (SRTP)
RFC 5768 Indicating Support for Interactive Connectivity Establishment (ICE) in the Session Initiation Protocol
(SIP)
RFC 5798 Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6
RFC 5806 Diversion Indication in SIP
RFC 5839 An Extension to Session Initiation Protocol (SIP) Events for Conditional Event Notification
RFC 5880 Bidirectional Forwarding Detection (BFD); Updated by RFC7419, RFC7880
RFC 5881 Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)
RFC 5883 Bidirectional Forwarding Detection (BFD) for Multihop Paths
RFC 5905 Network Time Protocol Version 4 (for IPv6)
RFC 5939 Session Description Protocol (SDP) Capability Negotiation
RFC 5952 A Recommendation for IPv6 Address Text Representation
RFC 5954 Essential Correction for IPv6 ABNF and URI Comparison in RFC 3261
RFC 5966 DNS Transport over TCP - Implementation Requirements
RFC 5976 Y.1541-QOSM: Model for Networks Using Y.1541 Quality-of-Service Classes
RFC 5996 Internet Key Exchange Protocol Version 2 (IKEv2)
RFC 5998 An Extension for EAP-Only Authentication in IKEv2
RFC 6026 Correct Transaction Handling for 2xx Responses to Session Initiation Protocol (SIP) INVITE
Requests
RFC 6044 Mapping and Interworking of Diversion Information between Diversion and History-Info Headers in
the Session Initiation Protocol (SIP)
RFC 6050 A Session Initiation Protocol (SIP) Extension for the Identification of Services
RFC 6086 Session Initiation Protocol (SIP) INFO Method and Package Framework
RFC 6135 Alternative Connection Model for MSRP UA
RFC 6140 Registration for Multiple Phone Numbers in the Session Initiation Protocol (SIP)
RFC 6184 RTP Payload Format for H.264 Video
RFC 6223 Indication of Support for Keep-Alive
RFC 6228 Session Initiation Protocol (SIP) Response Code for Indication of Terminated Dialog
RFC 6230 Media Control Channel Framework
RFC 6337 Session Initiation Protocol (SIP) Usage of the Offer/Answer Model
RFC 6347 Datagram Transport Layer Security Version 1.2
RFC 6357 Design Considerations for Session Initiation Protocol (SIP) Overload Control
RFC 6377 Non-reliable provisional response to the INVITE
RFC 6432 Carrying Q.850 Codes in Reason Header Fields in SIP (Session Initiation Protocol) Responses
RFC 6442 Location Conveyance for the Session Initiation Protocol
RFC 6665 SIP-Specific Event Notification
RFC 6679 Explicit Congestion Notification (ECN) for RTP over UDP
RFC 6714 Connection Establishment for Media Anchoring
RFC 6716 Definition of the Opus Audio Codec
RFC 6724 Default Address Selection for Internet Protocol Version 6 (IPv6)
RFC 6733 Diameter Base Protocol
RFC 6794 A Framework for Session Initiation Protocol (SIP) Session Policies
RFC 6809 Mechanism to Indicate Support of Features and Capabilities in the Session Initiation Protocol (SIP)
RFC 6881 Best Current Practice for Communications Services in Support of Emergency Calling
RFC 6891 Extension Mechanisms for DNS (EDNS (0)
RFC 6910 Completion of Calls for the Session Initiation Protocol (SIP)
RFC 6961 The Transport Layer Security (TLS) Multiple Certificate Status Request Extension
RFC 7090 Public Safety Answering Point (PSAP) Callback
RFC 7118 The WebSocket Protocol as a Transport for the Session Initiation Protocol (SIP)
RFC 7130 Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces
RFC 7135 Registering a SIP Resource Priority Header Field Namespace for Local Emergency
Communications
RFC 7200 A Session Initiation Protocol (SIP) Load-Control Event Package
RFC 7245 An Architecture for Media Recording Using the Session Initiation Protocol
RFC 7315 Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3GPP
RFC 7316 The Session Initiation Protocol (SIP) P-Private-Network-Indication Private Header (P-Header)
RFC 7329 A Session Identifier for the Session Initiation Protocol (SIP)
RFC 7332 Loop Detection Mechanisms for Session Initiation Protocol (SIP) Back-to-Back User Agents
(B2BUAs)
RFC 7339 Session Initiation Protocol (SIP) Overload Control
RFC 7433 A Mechanism for Transporting User-to-User Call Control Information in SIP
RFC 7434 Interworking ISDN Call Control User Information with SIP
RFC 7459 Representation of Uncertainty and Confidence in the Presence Information Data Format Location
Object (PIDF-LO)
RFC 7462 URNs for the Alert-Info Header Field of the Session Initiation Protocol (SIP)
RFC 7549 3GPP SIP URI Inter-Operator Traffic Leg Parameter
RFC 7614 Explicit Subscriptions for the REFER Method
RFC 7621 A Clarification on the Use of Globally Routable User Agent URIs (GRUUs)in the SIP Event
Notification Framework
RFC 7647 Clarifications for the Use of REFER with RFC 6665
RFC 7798 RTP Payload Format for High Efficiency Video Coding (HEVC)
RFC 7865 Session Initiation Protocol (SIP) Recording Metadata
RFC 7866 Session Recording Protocol
RFC 7913 P-Access-Network-Info ABNF Update
RFC 7989 End-to-End Session Identification in IP-Based Multimedia Communication Networks
RFC 8055 Session Initiation Protocol (SIP) Via Header Field Parameter to Indicate Received Realm
RFC 8068 Session Initiation Protocol (SIP) Recording Call Flows
RFC 8119 SIP "cause" URI Parameter for Service Number Translation
RFC 8197 A SIP Response Code for Unwanted Calls
RFC 8224 Authenticated Identity Management in the Session Initiation Protocol (SIP)
draft-ietf-sip- manyfolks-resource- 03 Integration of Resource Management and SIP Extensions for Resource Management
IETFdraft-ietf-insipid- logme-marking- Marking SIP Messages to be Logged

09
IETF draft-jesske- sipcore-reason- ISUP Cause Location Parameter for the SIP Reason Header Field
q850- loc-00
IETF draft-mohali-sipcore-originating- A P-Served-User Header Field Parameter for Originating CDIV session case in Session Initiation
cdiv-parameter-00 Protocol (SIP)
ITU
Table 5: Supported ITU Standards
ITU-T G.107 The E-model: a computational model for use in transmission planning
ITU-T G.108 Application of the E-model: A planning guide
ITU-T G.114 International telephone connections and circuits – General Recommendations on the transmission
quality for an entire international telephone connection
ITU-T G.711 Pulse code modulation (PCM) of voice frequencies
ITU-T G.722 7 kHz audio-coding within 64 kbit/s
ITU-T G.729 G.729 : Coding of speech at 8 kbit/s using conjugate-structure algebraic- code-excited linear prediction
(CS-ACELP)
ITU-T H.248 Gateway Control Protocol Version 2
ITU-T Q.1912.5 Interworking between Session Initiation Protocol (SIP) and Bearer Independent Call Control protocol or
ISDN User Part
ITU-T Q703 Message Transfer Protocol Layer 2 (MTP2)

ETSI 300 008 to 300 008-1
ITU-T Q704 and Q707 ETSI 300 Message Transfer Protocol Layer 3 (MTP3)
008 to 300 008-1
ITU-T Q711 – Q714 ETS 300 009 Signaling Connection Control Part procedures (SCCP)
ITU-T Q771 – Q774 ETSI 300 Transaction Capabilities Application Part (TCAP)
134
ETSI 300 287
ITU-T Y.1540 Internet protocol data communication service - IP packet transfer and availability performance
parameters
ITU-T Y.1541 Network performance objectives for IP-based services
NENA
Table 6: Supported NENA Standards
08-001 v2 Interim VoIP Architecture for Enhanced 9-1-1 Services (i2)
SIP Forum
Table 7: Supported SIP Forum Standards
SIPConnect 1.0 Direct IP peering between SIP-enabled IP PBXs and VoIP service provider networks
SIPConnect 1.1 SIP-PBX/ Service Provider Interoperability
SIPConnect 2.0 Updated guidelines for SIP-PBX / Service Provider Interoperability
PacketCable
Table 8: Supported PacketCable Standards
PKT-SP-ESP-103-040113 PacketCable Electronic Surveillance Specification
PKT-SP-ES-DCI-C01- PacketCable 2.0 – PacketCable Electronic Surveillance Delivery Function to Collection Function Interface
140314 Specification
Telecommunication Technology Committee

JJ-90.30 Common interconnection interface between IMS operator's networks. For more information, refer to https://www.ttc.or.jp
/application/files/5615/5443/0175/JJ-90.30Ev5.pdf.
Other Specifications
Table 9: Other Specifications
ACIF C518:2006 Call Charging and Billing Accuracy
ACIF C519:2004 End-to-End Network Performance for the Standard Telephone Service
ACIF C542:2003 Industry Code: Billing
ACIF G.549: Interconnection Implementation Plan

2000
ACIF G.557: Location Information for Emergency Calls

2014
AS/ACIF S038 - Requirements for ISDN Primary Rate Access Interface

2001
CA G632:2007 Communication Alliance Guideline - Quality of Service parameters for networks using the Internet Protocol
CA G633:2007 Communication Alliance Guideline - Testing Arrangements for Quality of Service Parameters for Internet Protocol
Services
CA G634:2007 Communication Alliance Guideline - Quality of Service parameters for Voice over Internet Protocol (VoIP) services
CA G635:2007 Communication Alliance Guideline - Testing Arrangements for Quality of Service Parameters for Voice over Internet
Protocol (VoIP) Services
ECMA – TR87 Using CTSA for SIP Phone User Agents (uaCTSA)
JTAPI Java Telephony API (JTAPI) version 1.1/1.2/1.3/1.4/2.0
ATIS-1000074 Signature-Based Handling Of Asserted Information Using Tokens (Shaken)
ATIS-0300116 Interoperability Standards between Next Generation Networks (NGN) for Signature-Based Handling of Asserted
information Using Tokens (SHAKEN)
ATIS-1000080 Signature-based Handling of Asserted information using toKENs (SHAKEN): Governance Model and Certificate
Management
ATIS-0300251 Codes for Identification of Service Providers for Information Exchange
ATIS-1000054 ATIS Technical Report on Next Generation Network Certificate Management
ATIS-1000094 Signature-based Handling of Asserted information using toKENs (SHAKEN): Calling Name and Rich Call Data Handling
Procedures
References
The following public websites provide standards definition details.
http://www.ietf.org/
http://www.rfc-editor.org/index.html
http://en.wikipedia.org/wiki/Main_Page
http://www.3gpp.org
http://www.nena.org
https://www.etsi.org
https://www.cablelabs.com/specs
https://www.ttc.or.jp/e
Routing and Policy Management

Key Features
Policy Server Modes
Installing SBC Application
Deployment Scenarios
Upgrading SBC Application
SBC ERE
Category - Call Routing
Basic and Advanced ERE
Basic Call Flow Using ERE
ERE With External PSX
Configuration - System Provisioning
Centralized PSX
CLI Configure Mode
Configurations Controlled by ERE
Disable or Enable ERE on Cloud Instances
Example userData file
The SBC Core routing and policy management involves high performance SIP routing with scalable routing policies for service-provider and
enterprise networks.
Key Features
AD Service
Screening, blocking, routing, presentation, call type filters
Route prioritization
Leading digit routing; International routing; URI based routing
Digit/parameter manipulation
ENUM Service
E911 support; Priority Call handling
Toll-free routing
Least cost routing
Number portability
Policy Server Modes

The SBC Core servers provide the following routing and policy management options for your network:
Embedded Routing Engine (ERE) – ERE provides less routing and policy management functionality and is intended for smaller
networks with no complex routing needs.
External Ribbon Policy Server (PSX) – PSX combines complex call-routing functionality with exceptional capacity to support larger
networks.
SBC is configurable to interact with up to nine centralized external PSXs, or a combination of external PSXs and ERE.
Configuration Basic ERE Advanced ERE Centralized External PSX
Number of SBCs Deployed Small Small Large

(Small: 1-3, Large: more than 3)
Routing Complexity Simple Complex Complex
For performance and capacity comparison of ERE and PSX, refer to Routing Engines Comparison.
Deployment Scenarios
SBC ERE
Basic and Advanced ERE
Basic ERE is the default routing engine on the SBC for performing basic call routing services. The Advanced ERE is a licensed option for
customers requiring expanded routing functionality.
The ERE can be installed by selecting the embedded routing engine (ERE) option while installing the SBC application using the EMA Platform
Mode. For more information on installing SBC application (ERE Configuration), refer to Installing SBC Application.
Features Basic-ERE Advanced-ERE
Maximum Number of Routes 2,000 100,000
Route Prioritization Route prioritization Route prioritization with more parameters

such as Time of Day and overflow routing.
Routing Mechanisms Routing mechanisms such Routing mechanisms such as User Name,
as Standard Destination Based Routing, Call Type,
User Name and Standard Digit Type and Time Range.
Destination Based Routing.
Call Screening and Blocking Services Not applicable Call screening and call blocking services to
enable a carrier to restrict calls based on either
origination, destination or both.
ERE With External PSX

You can configure the SBC to use an external PSX for routing and the ERE for fallback routing. When the external PSX is up and running, all
routing is handled by the external PSX and ERE routing configurations are ignored.
Thus, in the unlikely event that the external PSX goes down, you can fall back to ERE routing by simply setting the SBC's remote server state to
'disabled' from the EMA UI.
To set up an external PSX for routing, perform the following:
1. Configure remote server from EMA (refer to Policy Server - Remote Server for details).
a. Navigate to Configuration > SystemSetup tab.
b. Click the arrow next to Policy Server perspective in the navigation panel, and select Remote Server option. The "Remote
Server" configuration window displays.
c. Configure the remote policy server settings to use the external PSX.
2. Provision routing for the SBC in the external PSX using the PSX Manager.
3. Provision routing from EMA (refer to Category - Call Routing for details).
a.
3.
a. Navigate to Configuration > System Provisioning tab.

b. From the Category drop-down menu, select Call Routing.
c. Choose applicable perspectives to provision routing using ERE.
For more information on the routing and policy management features supported by ERE, refer to Routing Engines Comparison.
Centralized PSX
The centralized PSX server combines call routing functionality with the exceptional capacity of storing tens of millions of call routes in a single
database. This SBC-Centralized PSX deployment distributes that routing intelligence to every PSX server in the network and simplifies the
provisioning process. For more information on PSX, refer to the PSX Documentation.
The following figure depicts the SBC deployed with external PSX and EMS.
To configure external PSXs as Active and Standby remote policy servers from the SBC 5400/7000 server, refer to Configuring SBC for External
PSX.
Configurations Controlled by ERE

The following SBC configuration objects are controlled by the ERE.
AD Attribute Profile
AD Profile
Aor Group
Call Parameter Filter Profile
Call Parameter Filter Group Profile
Call Recording Criteria
Call Routing
Carrier (Global object)
Class of Service
Codec Entry
Codec List Profile
Codec Routing Priority
Country (Global object)
Crypto Suite Profile
DM/PM Criteria (Digit Parameter Handling object)
DM/PM Rule (Digit Parameter Handling object)
Domain Controller Profile
e911 (Servers object)
e911VpcDevice (Servers object)
Element Routing Priority Profile
enumDomainName
enumDomainName Label
Enum Service (Servers object)
Feature Control Profile
Holiday Profile
IP Signaling Peer Group
Ip Signaling Profile
Lwresd Profile
Media Qos KPI Profile
NPA/Nxx (Global object)
Number Globalization Profile
Numbering Plan (SIP Trunk Group Policy)
Number Translation Criteria (Digit Parameter Handling object)
Prefix Profile (Digit Parameter Handling object)
Route (Call Routing object)
Routing Label (Call Routing object)
Script (Global object)
Signaling Profile
Signaling QoS KPI Profile
SIP Domain (Global object)
Srs Group Cluster
Srs Group Profile
Subscriber (Global object)
Time Range Profile
Trunkgroup
Voip Subscriber
Disable or Enable ERE on Cloud Instances

When an instance is launched on cloud platforms, if the instance is installed with the "enableERE" option set to false in the user data provided to
the instance, the ERE processes will not run, and the policy must be provided by an external PSX cluster. When an instance is launched on cloud
platforms with type m-sbc or type slb, the ERE processes will not run.
Therefore, the I-SBC and S-SBC can use the local policy server, but only if it is installed with the "enableERE" set to true in the instance user
data.
Example userData file

Note
The following example shows only a section of the total user data file with the enableERE option set to enabled.
Example userData file - enableERE
{
"ThirdPartyCpus": "0",
"ThirdPartyMem": "0",
"enableCoreEMA": "enabled",
"enableERE": "enabled",
"enableREST": "enabled",
"enableTS": "enabled"
The following matrix provides a comparison of the SBC Core routing engines and which features are available for each configuration.
Refer to Node-Locked Licensing for a list of applicable licenses to enable these features.
Table 1: Routing Engines Comparison of Available Features
= supported Centralized PSX Basic ERE Advanced ERE1

= no coverage
Transport
Diameter+: UDP Diameter+: UDP Diameter+: UDP
SIP: UDP, TCP, SCTP
ENUM: UDP
Platforms Customer provided COTS server

SBC 7000 series SBC 7000 series
SBC SWe SBC SWe
Provisioning
Interface EMS GUI EMS EMS
API via EMS EMA EMA
CLI via EMS CLI CLI
Routing Engine
Protocol Diameter+ Diameter+ (for local SBC) Diameter+ (for local SBC)
SIP Redirect
SIP Proxy
ENUM Server
Max. Routes Tens of millions 2,000 100,000
Performance 4,500 dips/second

(Diameter+) SBC 5400 – 650 dips/second SBC 5400 – 650 dips/second
SBC 7000 – 1,350 dips/second SBC 7000 – 1,350 dips/second
Redundancy SBC box level redundancy 1:1 SBC box level redundancy 1:1
Master-Replica architecture
GR Master
N:1 Replicas
Routing Database Database is replicated from PSX Master PostGRE DB PostGRE DB

to multiple call processing replicas
Configuration is mirrored to standby SBC Configuration is mirrored to standby SBC
in HA mode. in HA mode.
External Lookups
ENUM: AoR, LNP, CNAM ENUM: AoR, LNP, CNAM ENUM: AoR, LNP, CNAM
DNS: NAPTR, SRV, A (separately licensed feature) (separately licensed feature)
AIN DNS: NAPTR, SRV, A (supported DNS: NAPTR, SRV, A (supported
INAP on the SBC outside of the ERE) on the SBC outside of the ERE)
SCP: TollFree, LNP, CNAM
SIP: Authcode, LCR, LNP
Wireless: GSM-MAP, IS-41,
CAMEL
Standard Routing
Called Number Called Number Called Number
Domain Domain Domain
Call Parameter Filter Profile Call Parameter Filter Profile
Call Type Call Type
Digit Type Digit Type
Time Range Time Range
Partition
Transmission Medium
User Name
Routing User Name User Name User Name
Domain Domain Domain
Call Parameter Filter Profile Call Parameter Filter Profile
Call Type Call Type
Digit Type Digit Type
Time Range Time Range
Partition
Transmission Medium
Routing Label Route Prioritization: Same Prioritization as Basic ERE with the
Route Prioritization: addition of:
Sequence Sequence
Proportion Proportion Overflow Routing
All Proportion All Proportion ToD, DoW, Special Days
Round Robin Round Robin
Least Cost Least Cost
Overflow Routing
ToD, DoW, Special Days
Route Hopping
Local Route Prioritization
Nested Routing Label
TAR Routes
Services
Screening Screening
Blocking Blocking
Info Digit Screening
CPC Screening
Authcode
Business Group
Call Processing
Entities Calling Number Trunk Group Calling Number
(for routing, Trunk Group Trunk Group
services) Carrier Carrier
Gateway
Business Group
Billing Number
Chosen IXC
Origination LATA
Called NOA
Originating LEC
Call Processing
Numbering Plan Numbering Plan Numbering Plan
Prefix Profile Prefix Profile Prefix Profile
SIP Domain SIP Domain SIP Domain
IP Signaling Profile IP Signaling Profile IP Signaling Profile
Packet Service Profile (12 Packet Service Profile on Trunk Packet Service Profile on Trunk
codecs) Groups (4 codecs) Groups and IP Peer (12 codecs)
Dial Plan
Number Length Enforcement
Overlapped Dialing
Tones and Announcements
DM/PM
Assignment Ingress TG Ingress TG Ingress TG
Prefix Profile Prefix Profile Prefix Profile
Egress TG Egress TG Egress TG
Before Number Translation
After Number Translation
Routing Label
Route
DM/PM Criteria Called Number and Calling Number only
Number
Translation
Hosted LNP
LCR
GW-GW signaling
support
H.323 Gatekeeper
Audio HD Codec
Routing
Video Routing Pass-through Pass-through

Pass-through
Bandwidth-based Routing
Microsoft Teams MS Teams DR multi-tenant MS Teams DR single tenant only MS Teams DR multi-tenant
Direct Routing
E911
(Separately licensed feature) (Separately licensed feature)
Test Routes
Shadow DB
External PSX N/A

Policy Server Diameter+ queries to centralized Diameter+ queries to centralized
Support PSX PSX
Fallback/failover between Fallback/failover between
centralized PSX to/from ERE centralized PSX to/from ERE
Alarms/Traps
/Stats
AD Query and Fixed AD parameters Flexible AD parameters Flexible AD parameters

Routing
IMS* N/A
ATCF / EATF E-CSCF
E-CSCF IBCF
IBCF P-CSCF
IPX-Proxy (S8HR - S8 home
Routing)
P-CSCF
* Ribbon recommends using the PSX for IMS deployments.
SBC Module Descriptions

In this section:
Application Modules
Application Support Modules
Platform Services Modules
Policy Modules
This page describes the various software modules used in the SBC Core system.
Application Modules
Application Modules
Table 1: Application Modules
Module Name Description

ID
ASG Applicatio Provides script handling logic.

n Service
Group
CC Call Maintains a signaling protocol agnostic representation of overall call.

Control
DCM Distribute It manages the D-SBC traffic and connection status between D-SBC nodes.
d
Connectio
n Manager
DFE Distribute Maintains call signaling channels for D-SBC communication between other remote nodes and local subsystem
d FE (NRM, NRMA, RRM, and so on.).
DS Directory The Directory Services Process is the integration point for both internal (embedded PSX) and external policy-based
Services routing. Its primary responsibility is to terminate the Diameter+ protocol and to convert back and forth between the
internal representation of call control information (in the form of CPC structures) and the Diameter+ messages
GWFE Gateway The GW FE provides terminations for signaling links between all gateways in a network to support communication
Forwardin between GW SGs.
g Engine
GWSG Gateway Gateway to Gateway Service Group supports the H.323 based gateway to gateway signaling protocol.
to
Gateway
Service
Group
H323FE H.323 The H323FE process provides a H.323 front-end capability. It is responsible for dispatching calls to a target
Front End application (H323SG) instance.
H323SG H.323 Receives H.323 messages from H.323FE and maintains H.323 oriented representation of call leg. This module
Service interacts with Node Resource Management agents to allocate call resources and with call control modules.
Group
NRM Node NRM is a centralized coordinator of system resources and it accomplishes this task via communication with its
Resource agents (NRMA)
Manager
NRMA Node Responsible for managing the allocation of specific resources needed for a call such as DSPs for transcoding.
Resource Locus of the offer-answer state machine.
Manager
Agent
RRM Remote The Distributed RRM is responsible for location and management of individual media transport resources (XRES)
Resource and transcoding resources (DRES) across the distributed M-SBC and T-SBC cluster nodes.
Manager
SIPFE SIP Front The SIPFE process provides a SIP front-end capability. It is responsible for dispatching calls to a target application
End (SIPSG) instance and for all interactions with the IP transport.
SIPSG SIP Parses SIP messages and maintains SIP-oriented representation of call leg. This module interacts with Node
Service Resource Management agents to allocate call resources and with call control modules.
Group
TRM Trunk Provides functionality for IP trunk group selection . This module also provides checks for call counts and bandwidth
Resource for call admission control.
Manager
Application Support Modules

Table 2: Application Support Modules
ID
BRM Bus Bus/Bandwidth Manager is responsible for the allocation and activation of internal SonicBus resources for a call.
/Bandwi
dth
Manager
CAM Call The Call Accounting Model is responsible for receiving internal messages containing Call Accounting information and
Accounti for passing this information along to its ultimate destination.
ng
Model
CPX Confd The CPX task acts as intermediary between Confd API and the underlying application. It is responsible for packaging
Proxy notifications and for performing validation activities implemented by application call-backs (the reason the process is
in the Application domain).
DNS Domain The DnsClient is responsible for resolving names via a DNS query. It interfaces with SIPSG and the SIPS transaction
Name layer, providing support for RFC3263 (Locating SIP servers).
System
DRM DSP The DSP Resource Manager is responsible for allocating and activating DSP based resources for a call.
Resourc
e
Manager
DS Director The Directory Services Process is the integration point for both internal (embedded PSX) and external policy-based
y routing. Its primary responsibility is to terminate the Diameter+ protocol and to convert back and forth between the
Services internal representation of call control information (in the form of CPC structures) and the Diameter+ messages.
Process
IM Intercep The Intercept Manager is a component of the Lawful Intercept implementation

t
Manager
IPM Policer The IPM process is responsible for collecting policer statistics (e.g. policed packets, top 10 offender list) at regular
Statistic intervals from NP and providing the same information to performance manager when requested.
s
Manager
LBS Load It is used for evenly distributing media requests between nodes in an M-SBC nodes cluster in a distributed SBC
Balancin deployment.
g
Service
NRS Node This service provides routing services for control and user IP traffic.
Routing
Service
PATHCH PathCh The PathCheck process is responsible for periodically checking connectivity towards configured IP end points via
ECK eck ICMP ping packets. It reports any change in connectivity status to SIP. The SIP ARS (Address Reachability Service)
process adds the unreachable endpoints to an application-level Black List it maintains.
PFM Perform The PFM task is responsible for gathering periodic performance statistics from applications and maintaining historical
ance performance statistics in the CDB database
Manager
RTM Redund The RTM process acts as a central coordination point for call data mirroring (done on a call-by-call basis as calls
ancy stabilize and terminate) and for synchronization (done when a standby card comes on line and assumes a role as a
Task ready-standby).
Manager
XRM Transpo This task is responsible for management and configuration of the NP layer. This includes the application-level
rt activities involve with monitoring events in support of maintenance of NP-level Dynamic Black Lists.
Resourc
e
Manager
Platform Services Modules

Table 3: Platform Services Modules

ID
CHM Confd CHM is a glue layer between the CSPS SAF-based middleware and the third party Confd process. It acts as an SAF
High- AMF proxy responding the AMF API and managing the lifetime of the Confd process.
Availabi
lity
Manag
er
ENM Event The Event Manager is responsible for accepting events and then dispatching the events as appropriate to log files
Manag and possibly SNMP traps. The Event manager is also responsible for providing the alarm manager role – to manage
er knowledge of current active alarms and potentially alarm history.
FM Fault The Fault Manager is responsible for receiving faults signaled via the Event Manager (Events send over ICM) and
Manag then dispatching notification as appropriate.
er
SM System System Manager collects hardware inventory information through openhpi interface, correlates it with configuration
Manag data and makes it available through SM agent APIs. Live software upgrade/revert state machine is built into System
er Manager which co-ordinates the package transfer from remote servers and running LSWU through management
interface. System Manager also controls process level core dump settings, handling and imposing user configured
space/count limits.
Policy Modules
Table 4: Policy Modules
Module ID Description
LWRESD (Light Weight Resolver The LWRESD process is used for ENUM queries/lookups.
Daemon)
PES (Policy Execution Server) The PES Process implements the routing and policy logic. It is essentially a database application with a
sophisticated application-level caching mechanism.
PIPE Policy Provisioning Entity responsible for provisioning policy data into the PostgreSQL Database.
REPD (Replication Daemon) The REPD Process is responsible for managing the replication of data from one instance of the
PostgreSQL database to another.
SCPA (Service Control Point The SCPA process is responsible for E911 queries to external servers.
Adaptor)
SLWRESD (Sonus Light Weight The enhanced SLWRESD process is used for ENUM queries/lookups in conjunction with load balancing.
Resolver Daemon)
Databases
Table 5: Databases
Database Description
Name
CDB - ConfD The SBC uses ConfD for:

Database
Creating, modifying and deleting configurations
Viewing status and statistics
Performing actions
ConfD provides several northbound interfaces for access to the SBC. The SBC uses the northbound interfaces CLI,
Netconf, REST, and SNMP.
ConfD provides a single southbound interface to the SBC software. The SBC has southbound interfaces to load
configuration, get configuration changes, perform actions, and view status/statistics.
On the first startup, or whenever CDB is empty, it will load seeded data from XML files. These files are in /opt/sonus/sbx/tailf
/var/confd/cdb.
Policy DB The SBC uses PostgreSQL database software as storage for ERE Policy DB.
Presently, ERE Policy DB is used to store policy data, SBC statistical data, and EMA data.
Interoperability - IOT
Ribbon solutions are designed and tested to provide interoperability with legacy equipment (TDM, H.323), multiple SIP vendors and standards,
application providers, international standards, and more.
To view Ribbon SBC product interoperability testing information, go to Interoperability Testing Home.
Copyright and Trademarks
Copyright
© 2020-2022 Ribbon Communications Operating Company, Inc. © 2020-2022 ECI Telecom Ltd. All rights reserved. The compilation (meaning the
collection, arrangement and assembly) of all content on this site is protected by U.S. and international copyright laws and treaty provisions and may
not be used, copied, reproduced, modified, published, uploaded, posted, transmitted or distributed in any way, without prior written consent of Ribbon
Communications Inc.
Disclaimer and Restrictions

The publication is for information purposes only and is subject to change without notice. This publication does not constitute a commitment on the part
of Ribbon. While reasonable efforts have been made in the preparation of this publication to assure its accuracy, Ribbon assumes no liability resulting
from technical or editorial errors or omissions, or for any damages whatsoever resulting from the furnishing, performance, or use of the information
contained herein. Ribbon reserves the right to make changes to this publication and to Ribbon products without notice in its sole discretion. This
publication is not meant to define any interfaces between Ribbon products and any third-party hardware or software products.
Warranties
THIS INFORMATION IS PROVIDED “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NONINFRINGEMENT. IN NO
EVENT SHALL RIBBON BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR
TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OR PERFORMANCE OF THIS INFORMATION,
EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Compliance with Applicable Laws and Export Control Laws

The information in this publication is subject to all applicable U.S. federal, state, and local laws. The customer use, distribution, and transfer of any
technical information shall be in compliance with all applicable export and import laws and regulations. All Ribbon products and publications are
commercial in nature; and the use, duplication, or disclosure by the United States Government is subject to the restrictions set forth in DFARS
252.227-7013 and FAR 52.227-19.
Trademarks
The trademarks, logos, service marks, trade names, and trade dress (“look and feel”) on this website, including without limitation the RIBBON and
RIBBON logo marks, are protected by applicable US and foreign trademark rights and other proprietary rights and are the property of Ribbon
Communications Operating Company, Inc. or its affiliates. Any third-party trademarks, logos, service marks, trade names and trade dress may be the
property of their respective owners. Any uses of the trademarks, logos, service marks, trade names, and trade dress without the prior written consent
of Ribbon Communications Operating Company, Inc., its affiliates, or the third parties that own the proprietary rights, are expressly prohibited.
UNCONTROLLED COPY:
The original content is stored in an electronic database and is “write protected”; it may be altered only by authorized persons. While copies may be
printed, it is not recommended. Viewing of the original content electronically ensures access to the current content. Any hardcopies taken must be
regarded as uncontrolled copies.

550-08642 07.01 SBC Core 11.01.00R000 Getting Started

Uploaded by

Copyright:

Available Formats

You might also like

550-08642 07.01 SBC Core 11.01.00R000 Getting Started

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

550-08642 07.01 SBC Core 11.01.00R000 Getting Started

Uploaded by

Copyright:

Available Formats

SBC Core

Disclaimer and Restrictions

Compliance with Applicable Laws and Export Control Laws

How to Access the SBC

About SBC Documentation

Feature Availability by Platform

Supported SIP Headers

SBC Module Descriptions

How to Access the SBC

Logging Into EMA

For login details, see Logging Into EMA.

EMA in Platform Mode

For more information, refer to Logging into EMA in Platform Mode.

Command Line Interface

For login details, refer to Logging Into the CLI.

Baseboard Management Controller

View basic system information

For login details, refer to Logging Into the BMC

CREATE – creates a managed object in the SBC.

For access details, refer to Accessing SOAP API.

REST has the following properties:

For access details, refer to Accessing REST API.

Insight EMS SBC Configuration Manager

A Note About SFTP

When executed, the program SbcSftp:

Logging into EMA in Platform Mode

Certificates with RSA keys up to 4,096 bits are supported.

1. Launch your web browser.

Figure 1: Certificate Security Error

4. Click Add Exception.

Minimum length of characters is 8.

Last Login Information

1. Last successful login date and time.

Logging Out of EMA

Security Enhancement to Allow Only One Concurrent EMA Session

Logging Into the CLI

login as: admin

A message similar to the following appears:

admin connected from 10.11.12.13 using ssh on sbx1.eng.example.com

admin connected from 10.11.12.111 using ssh on MYSBC

Connection to MYSBC closed

Logging into EMA in Platform Mode

Logging Into EMA

The PC must support Windows XP or later

Launch the EMA Platform in one of two ways:

a. From the BMC GUI

Figure 1: BMC Main Screen

b. Type https://<IP Address>:444 into a web browser and press Enter.

Figure 2: Login Screen

2. Login to the EMA Platform using default credentials:

Figure 31: Platform Manager Main Screen

Figure 42: System Information

Security Enhancement - SBC Allows Only One Concurrent EMA Session

1. Enter the BMC IP address in a web browser address bar.

For more information, refer to:

Changing the BMC Password

To access SOAP API, do the following:

2. Unzip to extract all the files.