550-08638 07.01 SBC Core 11.01.00R000 FAQs and Tips

SBC Core
FAQs and Tips

Software Release: 11.01.00R000
Document Revision: 07.01
Published: December 15, 2022
https://ribboncommunications.com 550-08638
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. FAQs and Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 SBC Core Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1.1 Call and Message Routing Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.1.2 Differences Between Trunking and Access Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.1.3 Link Verification Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.1.4 PSP Codec Selection for the Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.1.5 Reference Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.1.6 Tips From Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
1.1.7 How to Retrieve Complete CLI Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
1.2 Frequently Asked Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
FAQs and Tips
Table of Contents
SBC Core Tips

Frequently Asked Questions
SBC Core Tips
In this section:
Call and Message Routing Details

Differences Between Trunking and Access Configuration
Link Verification Configuration
PSP Codec Selection for the Call
Reference Configuration
Tips From Users
How to Retrieve Complete CLI Output
This section describes general tips and other useful information for the SBC Core.
Hardware and BMC-related topics do not apply to the SBC SWe platform.
Congratulations on obtaining your SBC Core platform! Below is a summary of the steps to follow to get your SBC functional.
1. Create an IP plan. This plan lays out what the IP addresses the SBC will use for its management ports, media ports and next hop router.
The media ports are used for SIP and RTP traffic. Example IP plans:
a. SBC 7000 series: Creating an IP Plan
b. SBC SWe: Creating an IP Plan for SBC SWe on VMware or KVM Hypervisor).
2. Install the Hardware. See Installing SBC 5400 Hardware or 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.
4. Install SBC Application software. This is accomplished from the EMA. See Installing SBC 7000 Series Software.
You are now ready to configure your SBC platform for processing! See How to Set up a Basic Call Flow.
Background on SIP Trunking and Access

The SBC basically acts as a SIP B2BUA (Back to Back User Agent). An important concept on the SBC is that all signaling and routing is based
upon Trunk Groups.
SIP Trunk Groups are a logical connection between the SBC and a far end. A SIP Trunk can be one to one or one to many with the SBC always
being a single point. A SIP Trunk for end point (phones) access will be one IP address on the SBC with the far end consisting of many different
end points. A SIP Trunk for a carrier or PBX will generally be a one to one connection.
Access configurations involve end points (SIP phones, IADs, Soft Clients, etc.) that Register via the SBC to their feature server (Class 5, PBX,
Hosted PBX, etc.). The SBC can cache Registrations in order to reduce the processing time the feature server spends on them. Even in Access
configurations, a set of endpoints is represented by a trunk group.
From an SBC viewpoint, all calls (SIP sessions) involve two trunk groups on the SBC. For example, if Party A wished to connect to Party B via
the SBC, two trunk groups on the SBC are involved, one to Party A and one to Party B. There are generally two types of point-to-point SIP
Trunks: Interconnect between two carriers and Interconnect between a PBX and a carrier. Interconnection between carriers is static and do not
require registrations.
In the case of interconnection between a carrier and a PBX, the amount of Registrations that can take place vary.
In a static trunking environment, no registrations take place. This is similar to two carriers interconnecting.
PBX can use Group registration for its endpoints.
When a pilot number is Registered, calls are routed (via the feature server) to that pilot number (which would include the extension in the
INVITE) on the PBX.
Each endpoint can Register
Both SIP Trunking and Access configurations may be implemented on the same SBC server.
Commonly Used Element Names
Below is a list of commonly used element names on the SBC platforms.
To see system name and hostname conventions and restrictions, see System Name and Hostname Naming Conventions page.
Name Description Examples
DALNBS01
System Should be in all CAPS. DALSBC01
Name On a HA system the units are referred to as one name. This
name is used in billing,
external PSX queries (if done), and system logs.
The 1st 3 letters describer the physical location of the system,
for example Dallas = DAL
The 2nd 3 letters are NBS or SBC to indicate what this
machine is.
The last two characters are numerical, indicating which
number NBS at this particular location
Unit #1 of The System name with an "a" appended on it DALNBS01a

HA name
Unit #2 of The System name with an "b" appended on it DALNBS01b

HA name
IP Interface Represent the type of far ends. TRUST_IPIG, UNTRUST_IPIG Or

Group INTERNAL_IPIG, EXTERNAL_IPIG
IP Interface Include the packet port number and VLAN tag (if used) in the name IPIF0
IPIF1
IPIF2_200
Zone All CAPS INTERNAL, EXTERNAL, CUSTOMER_A
Describes the far end.
Trunk CORE, PEER, CUSTOMER_A

Groups All CAPS
Can use underscores
Describes the far end. Will show up in billing records, so
discuss with your downstream billing team
Packet Create a unique one for each customer type. Append "PSP" at the SIP_PEER_PSP
Service end.
Profile
Signaling Lower case "peer" prefixing the trunk group peerCUSTOMER_A

Peer
Routing rlToCUSTOMER_A, TO_CUSTOMER_A

Label The text "rlTo" prefixing the trunk group.
Or prefix "TO_" to the trunk group name.
Appears in the billing record
IP Signaling CUSTOMER_A_IPSP ALLPEERS_PSP

Profile Describers the signaling flags associated with the customer.
Could be re-used among multiple customers
Leave the DEFAULT unmodified, create a new ones as
needed.
Append "_IPSP" to the trunk group name or type of peer.
Link The names should include the IP Interface Group. UNTRUST_LDG_A, UNTRUST_LDG_B,
Detection TRUST_LDG_A, TRUST_LDG_B, MGT_LDG_A,
Groups Include an "A" or "B" to indicate the unit. MGT_LDG_B
Call and Message Routing Details
Calls and non-call messages such as REGISTER, SUBSCRIBE, NOTIFY are routed in a similar manner.
The Route and Routing Label are used to determine how routing is done. On the SBC, there are different ways to implement routing (destination
number, carrier, subscriber number, and trunk group). Trunk Group routing is used for this example configuration. It is the simplest and most straight
forward way for a "pure" SBC function to be implemented. It allows the operator to add users / routable numbers without having to configure those
numbers into the SBC.
For our Trunk Group routing configuration, calls that arrive on trunk group "CORE" are sent to Routing Label "TO_PEER", which routes the call to
trunk group "PEER". And in the other direction, calls that arrive on trunk group "PEER" are sent to Routing Label "TO_CORE", which routes the call to
the "CORE" trunk group.
For Access configurations, the same principle applies. Calls from trunk group "PHONES" are sent to trunk group "ACCESSCORE". Calls from trunk
group "ACCESSCORE" will be routed to "PHONES". However, since "PHONES" is configured to Support / Require Registration, the SBC will look up
the destination number in its cached Registration table (also referred to as the AOR (Address of Record table)), and send the call to that device
(which will be an IP address and port used to get to the device).
The SBC can also use an external PSX for routing. You can view which method is being used under "System" > "Global Config" / "Local Server" /
"Remote Server", or the CLI command:
> show status system policyServer
Differences Between Trunking and Access Configuration
The configurations for a Trunking application and Access application are very similar. Both are based on the "Trunk Group" concept. It may seem
strange that a set of phones that register with unique IP addresses are considered a trunk group, but it is actually helpful in configuring and
debugging the SBC Core.
As for how a set of phones can be considered a trunk group, this is accomplished by the following mechanism:
1. Phones Register to a SIP Port on the SBC

2. The SIP Port is in a Zone
3. The Trunk Group is in the same Zone
4. The Trunk Group is configured to Require/Support Registration (see below)
The key differences between an Access Configuration and a Trunking Configuration are shown below:
Table 1: Key Differences between Access and Trunking Configuration
Element Access Details Trunking
Details
Trunk On the Trunk group facing the phones (PHONES in our example), the "Registration Required" parameter must be Registration
Group: set. You should also set the Expires timer which controls how often the phones will Register. And the Inside Expires is not
Registrati timer, which is how often the SBC will Register with the Feature Server (PBX or Class 5 Softswitch) on behalf of the required, so
on phone. The Inside timer is typically 1 hour, while the phones Registration timer is typically 60 seconds. this
Required parameter
parameter is not set.
IP Peer: The IP Peer for messaging TO the phones is not explicitly configured (indicating to the SBC that it should look in its IP address
IP local stored Registration table to determine the IP of the far
address address to use to route the INVITE to the phone). The Routing label in the 'Standard Route' for this Zone should be end.
configured with only the TrunkGroup and no ipPeer.
Ingress The Ingress IP Prefix (Network Selector Table in GSX 9000 terminology) for messaging FROM the phones is 0.0.0.0. IP address
IP Prefix This indicates that no fixed IP address should be required in receiving messages from the phones (the Registration of the far
table is checked instead). The Ingress IP Prefix is located under the Trunk Group (which is under the Zone). end.
Trunk If there is a NAT/NAPT device (Network Address Translation) between the phones and the SBC (common if phones Generally
Group: are on the public internet), the NAPT for Signaling flag and the NAPT for Media flag should be turned on. These there is no
NAT flags are part of the SIP Trunk group configuration. NAT on
/NAPT Trunking
Settings configuration
s.
Link Verification Configuration

In this section:
Physical Link Detection

Logical Link Detection
Example Configurations
Configuring Link Detection
Configuring Physical Port
This section details best practices for configuring link detection groups.
Configuring link detection allows the SBC to switch over to a standby system based upon a configurable threshold of interface failures. Without
link detection, the SBC does not use interface failures for SBC switchover determination.
Recommended threshold values (switchover criteria) are:
Port Type Threshold
Management 2
Media 1
Ribbon recommends configuring only a single link monitor on any Ethernet port regardless of the number IP interfaces on that port.
Physical Link Detection

The user may configure a link monitor with a null destination (0.0.0.0) so that pinging is disabled so that only the physical health of the port is
monitored. A null destination is normally recommended on external interfaces when the internal and external interfaces go to the same Ethernet
switch pair.
Physical Link Detection is always instantaneous, regardless of Logical Link Detection.
Logical Link Detection
When a user configures a non-null destination for a link monitor, the link monitor periodically pings the destination (using ICMP Echo Request
packets for the SBC 5400), and then retries if it fails to get a response. This technique is used to determine logical failures of the connected
switch.
When configuring a SBC series link monitor with a non-null destination on any interface with a user-created Deny All ACL (Access Control List),
ensure that there are earlier ACLs that allows ICMP responses from the link monitor destination IP addresses.
Most logical failures of a L3 switch, such as a route processor failure, do not cause its Ethernet ports to go down at the physical level (i.e. loss
of carrier), thereby silently discarding traffic.
Ribbon recommends using a switch-local IP address for the destination, such as a Switch Virtual Interface (SVI, Cisco terminology) or a Routed
VLAN Interface (RVI, Juniper terminology) rather than the VRRP/HSRP address. If such functionality is not available, the VRRP/HSRP/virtual-
chassis IP address may be used as a link monitor destination.
Logical link detection should never be used as a peer checking mechanism (refer to Path Check Profile - CLI for that type of functionality).
Since the SBC 7000 uses ICMP on active port and ARP ACD probes on standby ports, the destination must be on the local subnet of
the Media interfaces for SBC to perform probing.
The following timer and retry values are recommended:
Parameter Value
verifyTimer 1000 ms
responseTimer 500 ms
reattemptTimer 1000 ms
retries 2
Logical link detection parameters (timers/retries) do not effect physical link failure detection (e.g. loss of carrier). Reaction to physical link failures
are always instantaneous regardless of how logical link detection is configured.
Example Configurations
The diagram below depicts the generic recommended cabling configuration for the SBC series. The physical connections drive the link detection
configuration.
Figure 1: SBC 5400 Series Cabling Configuration for Link Verification
Specifically, the above diagram shows the SBC platform which has four media ports.
A second Ethernet switch pair (sw3 and sw4) is not required, but is shown for clarity (some deployments may have yet another separate switch
pair for management ports).
Ribbon recommends that both management ports of each node connect to the same switch pair unless:
the user configures a link monitor null destination (0.0.0.0) on the management ports, or
the user has engaged Ribbon Professional Services to understand the pros and cons of deviating from that design.
The diagram below depicts the generic recommended cabling configuration for the SBC 7000. The physical connections drive the link detection
configuration.
Table 2: SBC 7000 Series Cabling Configuration for Link Verification
Configuring Link Detection
The following example configuration applies to the SBC series.
set addressContext default linkDetectionGroup MANAGEMENT_LDG_A ceName SBC01A type mgmt linkMonitor LM_1
destination 10.1.1.2
interfaceGroup mgmtGroup interface mgmtIntf1
verifyTimer 1000 responseTimer 500 reattemptTimer 1000 retries 2
set addressContext default linkDetectionGroup MANAGEMENT_LDG_A ceName SBC01A type mgmt linkMonitor LM_1 state
enabled
commit
set addressContext default linkDetectionGroup MANAGEMENT_LDG_A ceName SBC01A type mgmt linkMonitor LM_2 state
enabled
commit
set addressContext default linkDetectionGroup MANAGEMENT_LDG_B ceName SBC01B type mgmt linkMonitor LM_3
set addressContext default linkDetectionGroup MANAGEMENT_LDG_B ceName SBC01B type mgmt linkMonitor LM_3 state
enabled
commit
set addressContext default linkDetectionGroup MANAGEMENT_LDG_B ceName SBC01B type mgmt linkMonitor LM_4 state
enabled
commit
set addressContext default linkDetectionGroup INTERNAL_LDG_A ceName SBC01A type ip linkMonitor LM_2A
interfaceGroup INTERNAL_IPIG interface IPIF2_200
set addressContext default linkDetectionGroup INTERNAL_LDG_A ceName SBC01A type ip linkMonitor LM_2A state
enabled
commit
set addressContext default linkDetectionGroup INTERNAL_LDG_B ceName SBC01B type ip linkMonitor LM_2B
set addressContext default linkDetectionGroup INTERNAL_LDG_B ceName SBC01B type ip linkMonitor LM_2B state
enabled
commit
set addressContext default linkDetectionGroup INTERNAL_LDG_A ceName SBC01A type ip linkMonitor LM_3A state
enabled
commit
set addressContext default linkDetectionGroup INTERNAL_LDG_B ceName SBC01B type ip linkMonitor LM_3B state
enabled
commit
set addressContext default linkDetectionGroup EXTERNAL_LD_LDG_A ceName SBC01A type ip linkMonitor LM_0A
interfaceGroup EXT_LD_IPIG interface IPIF0_300
set addressContext default linkDetectionGroup EXTERNAL_LD_LDG_A ceName SBC01A type ip linkMonitor LM_0A state
enabled
commit
set addressContext default linkDetectionGroup EXTERNAL_LD_LDG_B ceName SBC01B type ip linkMonitor LM_0B
set addressContext default linkDetectionGroup EXTERNAL_LD_LDG_B ceName SBC01B type ip linkMonitor LM_0B state
enabled
commit
set addressContext default linkDetectionGroup EXTERNAL_LD_LDG_A ceName SBC01A type ip linkMonitor LM_1A state
enabled
commit
set addressContext default linkDetectionGroup EXTERNAL_LD_LDG_B ceName SBC01B type ip linkMonitor LM_1B state
enabled
commit
set addressContext default linkDetectionGroup MANAGEMENT_LDG_A ceName SBC01A type mgmt threshold 2
set addressContext default linkDetectionGroup MANAGEMENT_LDG_A ceName SBC01A verifyTimer 1000 responseTimer 500
reattemptTimer 1000 retries 2
set addressContext default linkDetectionGroup MANAGEMENT_LDG_A ceName SBC01A state enabled
commit
set addressContext default linkDetectionGroup INTERNAL_LDG_A ceName SBC01A type ip threshold 1
set addressContext default linkDetectionGroup INTERNAL_LDG_A ceName SBC01A verifyTimer 1000 responseTimer 500
set addressContext default linkDetectionGroup INTERNAL_LDG_A ceName SBC01A state enabled
commit
set addressContext default linkDetectionGroup EXTERNAL_LD_LDG_A ceName SBC01A type ip threshold 1

set addressContext default linkDetectionGroup EXTERNAL_LD_LDG_A ceName SBC01A verifyTimer 1000 responseTimer
500 reattemptTimer 1000 retries 2
set addressContext default linkDetectionGroup EXTERNAL_LD_LDG_A ceName SBC01A state enabled
commit
set addressContext default linkDetectionGroup MANAGEMENT_LDG_B ceName SBC01B type mgmt threshold 2
set addressContext default linkDetectionGroup MANAGEMENT_LDG_B ceName SBC01B verifyTimer 1000 responseTimer 500
set addressContext default linkDetectionGroup MANAGEMENT_LDG_B ceName SBC01B state enabled
commit
set addressContext default linkDetectionGroup INTERNAL_LDG_B ceName SBC01B type ip threshold 1

set addressContext default linkDetectionGroup INTERNAL_LDG_B ceName SBC01B verifyTimer 1000 responseTimer 500
set addressContext default linkDetectionGroup INTERNAL_LDG_B ceName SBC01B state enabled
commit
set addressContext default linkDetectionGroup EXTERNAL_LD_LDG_B ceName SBC01B type ip threshold 1

set addressContext default linkDetectionGroup EXTERNAL_LD_LDG_B ceName SBC01B verifyTimer 1000 responseTimer
500 reattemptTimer 1000 retries 2
set addressContext default linkDetectionGroup EXTERNAL_LD_LDG_B ceName SBC01B state enabled
commit
Configuring Physical Port

This applies to SBC 7000 only.
set addressContext ADDR_CONTEXT_1 linkDetectionGroup LDG1 ceName bf013.eng.sonusnet.com threshold 0 linkMonitor

LM1 destination 10.7.6.50 interfaceGroup IFG_PKT0_0 interface LIF_PKT0_0 physicalPort pkt0_p state enabled
commit
set addressContext ADDR_CONTEXT_1 linkDetectionGroup LDG1 linkMonitor LM2 destination fd00:10:6b21:2007::6:50
interfaceGroup IFG_PKT0_0 interface LIF_PKT0_0 physicalPort pkt0_s state enabled
commit
PSP Codec Selection for the Call
Packet Service Profiles (PSP) specify audio encoding methods and associated media attributes that the SBC uses when negotiating the media
capabilities for calls during initial call setup.
During call setup several PSP are merged to determine the encoding for the call. For a detailed description of the PSP merge process, see SBC Core
Features Guide as well as "PSX Product Description" and "PSX Provisioning Guide" documents.
Four different groups of available codec and other media preferences (packet size, DTMF transport method, etc.) are available on each call:
1. Offered by the originator (in the SIP INVITE)

2. Configured on the SBC trunk group of the originator (in the PSP)
3. Configured on the SBC trunk group for the terminator (in the PSP)
4. Allowed by the terminator (in the 200 OK)
Numerous outcomes are possible regarding which codec(s) is/are used for the call, depending on how the PSP are configured. You could, for
example:
Use the originator's first choice codec and force transcoding.

Use the originating trunk group first choice codec and force transcoding.
Pass the call through without any transcoding.
Negotiate the codec's and only transcode if no common codec is found.
Reference Configuration
In this section: Related articles:
Configuring IP Interface Groups and Interfaces

High Level Simple Configuration
Call Routing: System Provisioning - Routing
Configuration Details
Creating an IP Plan
Zones
SBC Core Software Installation and Upgrade Guide
SIP Signaling Ports
SBC SIP Transparency Implementation Guide
Packet Service Profile (PSP)
Codec Entry
IP Signaling Profile
Trunk Groups
IP Peer
Routing Label
Route
Link Detection
Configuration Questionnaire
Information Needed for Software Application
Installation
Call Processing Configuration for Simple Routing
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 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.
The configuration discussed in this section has been tested in the Ribbon lab. The goal is to show a simple working configuration that can be
used as a basis for SBC Core user customization.
High Level Simple Configuration

Trunk group routing will be used to send all traffic that arrives on "Outside" trunk to "Inside" trunk, and vice versa. This allows for no additional
configuration changes on the SBC as the operator adds more numbers to be routed.
This configuration will support G.729A on the "Outside" with G.711 on the "Inside" so transcoding will occur.
A single Address Context will be configured, so no overlapping IP address will be used.
Both "Outside" and "Inside" specific configuration data must be made. Below is a summary of the key configuration items.
Table 1: Key Configuration Items
Configuration "Outside": PEER "Inside": CORE
Item
Zone SIP Port and Trunk Group reside in Zone SIP Port and Trunk Group reside in Zone
SIP Signaling Public IP address on the SBC that far end will send Private IP address on the SBC that the feature server will send
Port messages to. messages to
Packet Service Specify G.729A Specify G.711

Profile
IP Signaling SIP Parameter settings SIP Parameter settings

Profile
Trunk Group Includes IP of where messages will arrive from. If Includes IP of where messages will arrive from. Will be the feature
far ends are registering server SIP port IP address.
devices (phones), use 0.0.0.0 for ingress IP Prefix.
Signaling Peer IP address of far end IP address of feature server
Routing Label One per trunk group One per trunk group
Route One per trunk group One per trunk group
Configuration Details
Please use default values except as noted. For this example the Address Context "default" is used, since there is no over-lapped IP addressing.
The term "operator" is used to mean the Carrier, Service Provider, or Enterprise that owns the SBC.
To get into configuration mode from the CLI:
admin@DFWNBS01a> configure
Entering configuration mode private
Zones
Create four new zones, each one representing an external customer or operator equipment.
Two are used for the Trunking configuration

Two are used for the Access configuration.
As additional customer (non-operator) far ends are added, they can be put into a new zone. For additional operator equipment, you may use a
new zone or re-use the existing one.
Table 2: Zone Usage | Zone Types
Zone Configuration Usage Purpose
peer Trunking Traffic to/from far end carrier
core Trunking Traffic to/from operator trunking equipment
phones Access Traffic to/from phones
accesscore Access Traffic to/from operator feature server
Example of Using Zone Types in CLI
% set addressContext default zone peer id 2

% set addressContext default zone core id 3
% set addressContext default zone phones id 4
% set addressContext default zone accesscore id 5
On the SBC main screen, navigate to Configuration > System Provisioning > Category: Base Provisioning > Zone.
SIP Signaling Ports

The SIP Signaling Ports live on (the IP addresses are owned by) the SBC. These are the IP addresses that external (non-SBC equipment) send
SIP traffic to and receive SIP traffic from. For this example four new SIP Ports are created (two for Trunking and two for Access). The term
"operator" is used to mean the Carrier, Service Provider, or Enterprise that owns the SBC.
Table 3: SIP Port Usage
SIP Port #/ Zone Configuration Usage Purpose
1 / peer Trunking Traffic to/from far end carrier
2 / core Trunking Traffic to/from operator trunking equipment
3 / phones Access Traffic to/from phones
4 / accesscore Access Traffic to/from operator feature server
In the configuration examples, each SIP Signaling port is in a unique Zone. The non-SBC equipment (phones, operator feature server, other
Carriers, operator trunking server) sends/receives SIP messages to/from the IP addresses and port configured. The default protocol allowed is
UDP and port is 5060.
Caution
When a SIP Port is created (IP address is assigned), the system also creates an ACL that allows connection attempts to all ports on
the IP address. This means that someone could attempt to SSH to the IP address of the SIP Port. To prevent unwanted access
attempts, you should manually create ACLs that specify what is allowed and what is not. See the ACL section of this document for
details.
% set addressContext default zone peer id 2 sipSigPort 1 ipInterfaceGroupName EXTERNAL_IPIG ipAddressV4

10.35.66.189 state enabled
% set addressContext default zone core id 3 sipSigPort 2 ipInterfaceGroupName INTERNAL_IPIG ipAddressV4
192.168.75.10 state enabled
% set addressContext default zone phones id 4 sipSigPort 3 ipAddressV4 10.35.66.143 portNumber 5060
transportProtocolsAllowed sip-udp ipInterfaceGroupName EXTERNAL.IPIG
% set addressContext default zone accesscore id 5 sipSigPort 4 ipAddressV4 10.35.66.179 portNumber 5060
transportProtocolsAllowed sip-udp ipInterfaceGroupName EXTERNAL.IPIG
On the SBC main screen, navigate to Configuration > System Provisioning > Category: Base Provisioning > Signaling Ports > Sip Sig Port.
Packet Service Profile (PSP)

Packet Service Profiles control the media settings such as Codec, Packet Size, Transcoding options, and fax support on a trunk group. For
example you can specify that only G.729A codec is allowed to the PHONES trunk group, while G.729A and G.711 are allowed to the
ACCESSCORE trunk group. Each PSP can contain up to four Codec entries when using ERE. These Codec entries describe a codec, its packet
size, and its law (A or U). Several default Codec entries are pre- configured on the system, and you can use these as an example to create your
own.
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.
If you do not wish to use the default Codec Entries you will need to create custom Codec Entries before you can create Packet Service Profiles,
since the PSP reference the Codec Entries. For example, you may want to have a PSP that specifies 20ms packet size, RFC2833 transport,
allows for G.729A codec, and allows transcoding of G.711 to G.729A.
In our example two, Packet Service Profiles are created. You should create new PSPs based on the default one, instead of modifying the default
one. And they should be named in such a way so that you can identify what their function is.
On the SBC main screen, go to Configuration > System Provisioning > Category: Trunk Provisioning > Packet Service Profile.
Codec Entry
The Codec Entry describes one specific codec that can be offered as part of the Packet Service Profile. Several default Codec Entries are
included with the SBC. It is recommended to name the Codec Entry in a descriptive manner, so it is easy to select during the Packet Service
Profile creation or modification.
Some of the key fields of the Codec Entry include:
Codec – the actual codec to be used

Packet Size – the size of each RTP voice packet, in milliseconds.
Law – Alaw, Ulaw, derived from other leg
DTMF Relay method – should RFC2833 be used, in-band or out of band
Example 1:
Create G711u_20ms_2833_T38 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
% set profiles media codecEntry G711u_20ms_2833_T38 fax toneTreatment faxRelayOrFallbackToG711
% set profiles media codecEntry G711u_20ms_2833_T38 modem toneTreatment fallbackToG711
% set profiles media codecEntry G711a_20ms_2833_T38 codec g711 packetSize 20 law ALaw
% set profiles media codecEntry G711a_20ms_2833_T38 dtmf relay rfc2833 removeDigits enable
% set profiles media codecEntry G711a_20ms_2833_T38 fax toneTreatment faxRelayOrFallbackToG711
% set profiles media codecEntry G711a_20ms 2833_T38 modem toneTreatment fallbackToG711
Example 2:
Create G711u_40ms_2833_T38, G711a_40ms_2833_T38, and G729ab_40ms_2833_T38 entries for pubic facing side, G.711u, G.711a and G.
729A, all using RFC2833 and 40ms packet size.
G.711U 40ms_2833_T38:
% set profiles media codecEntry G711u_40ms_2833_T38 codec g711 packetSize 40 law ULaw
% set profiles media codecEntry G711u_40ms_2833_T38 dtmf relay rfc2833 removeDigits enable
% set profiles media codecEntry G711u_40ms_2833_T38 fax toneTreatment faxRelayOrFallbacktoG711
% set profiles media codecEntry G711u_40ms_2833_T38 modem toneTreatment fallbackToG711
% set profiles media codecEntry G711a_40ms_2833_T38 codec g711 packetSize 40 law ALaw
G.711a 40ms_2833_T38:
% set profiles media codecEntry G711a_40ms_2833_T38 dtmf relay rfc2833 removeDigits enable
% set profiles media codecEntry G711a_40ms_2833_T38 fax toneTreatment faxRelayOrFallbackToG711
% set profiles media codecEntry G711a_40ms 2833_T38 modem toneTreatment fallbackToG711
G.729ab 40ms_2833_T38:
% set profiles media codecEntry G729ab_40ms_2833_T38 codec g729ab packetSize 40

% set profiles media codecEntry G729ab_40ms_2833_T38 dtmf relay rfc2833 removeDigits enable
% set profiles media codecEntry G729ab_40ms_2833_T38 fax toneTreatment faxRelayOrFallbacktoG711
% set profiles media codecEntry G729ab_40ms_2833_T38 modem toneTreatment fallbackToG711
On the SBC main screen, navigate to Configuration > System Provisioning > Category: Call Routing > Codec Entry.
IP Signaling Profile
IP Signaling Profiles control how various SIP egress and ingress parameters are set and processed. A unique profile should be used for each
type of destination. Each trunk group has an assigned IP Signaling Profile. You can see this from the EMA GUI via Configuration > System
Provisioning > Category: Trunk Provisioning > 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 the outgoing
signaling (sent from the trunk group).
The IP Signaling profile configured on the IP Peer will overwrite the IP Signaling profile configured on the trunk group.
The IP Signaling Profile "DEFAULT_SIP" is available to use. If you do not wish to use the default one as is, it is recommended to create a new
one and leave the DEFAULT_SIP unchanged. You should use the default values for the IP Signaling profile, except for Access configurations, do
the following:
1. Turn on all Common IP Attributes: Relay flags (to allow all messages to pass through SBC).
2. Turn on all Common IP Attributes: Transparency for headers.
3. Turn on Egress IP Attribute: Transparency
Trunk Groups
An important concept on the SBC is that all signaling and routing is based upon Trunk Groups. Even in Access configurations, a set of endpoints
is represented by a trunk group. It is convention that the trunk group names are CAPATALIZED.
For the example configuration, four trunk groups are created. Two are created for the "SIP Trunking" configuration and two for the "Access"
configuration.
Table 4: Trunk Group Usage
Trunk Group Name Configuration Usage Purpose
CORE Trunking Trunk to operator network equipment (carrier that owns the SBC)
PEER Trunking Trunk to far end (another carrier or PBX for example)
PHONES Access Trunk to the set of phones
ACCESSCORE Access Trunk to the operator (owner the SBC) feature server. For example, PBX.
% set addressContext default zone core sipTrunkGroup CORE ingressIpPrefix 192.168.75.5 32

% set addressContext default zone core sipTrunkGroup CORE media mediaIpInterfaceGroupName IPIG1
% set profiles signaling ipSignalingProfile CORE_IPSP egressIpAttributes numberGlobalizationProfile NO_GLOBAL_IP
% set profiles signaling ipSignalingProfile CORE_IPSP commonIpAttributes relayFlags thirdPartyBodies enable
% set profiles signaling ipSignalingProfile CORE_IPSP commonIpAttributes transparencyFlags unknownBody enable
unknownHeader enable
% set addressContext default zone core sipTrunkGroup CORE policy signaling ipSignalingProfile CORE_IPSP
% set profiles media packetServiceProfile CORE_PSP codec codecEntry1 G711-EITHER_OOB-2833 codecEntry2
G729AEITHER_OOB-2833 codecEntry3 G729AB-EITHER_OOB-2833
% set profiles media packetServiceProfile CORE_PSP packetToPacketControl codecsAllowedForTranscoding thisLeg
g711a,g711u,g729,t38
% set profiles media packetServiceProfile CORE_PSP packetToPacketControl codecsAllowedForTranscoding otherLeg
g711a,g711u,g729,t38
% set addressContext default zone core sipTrunkGroup CORE policy media packetServiceProfile CORE_PSP
% set addressContext default zone core sipTrunkGroup CORE state enabled mode inService
On the SBC main screen, go to Configuration > System Provisioning > Category: Trunk Provisioning > Trunk Group > SIP Trunk Group.
IP Peer
The IP Peer is the IP address of the far end device. The IP Peer is referenced in the Routing Label, and is used for outgoing calls for a particular
Trunk Group.
If you define an IP Signaling Profile in the IP Peer (policy sub section), it will overwrite the one defined the in trunk group.
For Access configurations, it is not necessary to have a IP Signaling Peer to the individual phones. You do need one to the feature server.
% set addressContext default zone core ipPeer core_peer ipAddress 192.168.75.5 ipPort 5060
% set addressContext default zone peer ipPeer peer_peer ipAddress 10.35.66.187 ipPort 5060
% set addressContext default zone accesscore ipPeer accesscore_peer ipAddress 10.35.66.140 ipPort 5620
On the SBC main screen, navigate to Configuration > System Provisioning > Category: Trunk Provisioning > IP Peer
Routing Label
The Routing Label is used by the Route object to send traffic from one trunk group to the other, and vice versa. Trunk Group routing is used for
this purpose.
One Routing Label is created for each Trunk Group. This Routing Label is used to send calls to that Trunk group. In the below example, the
Routing Label "TO_CORE" sends calls to "CORE" trunk group. There is also a Routing Label "TO_PEER" that sends calls to "PEER" trunk group.
% set global callRouting routingLabel TO_PEER routingLabelRoute 1 trunkGroup PEER ipPeer PEER inService
inService
% set global callRouting routingLabel TO_CORE routingLabelRoute 2 trunkGroup CORE ipPeer CORE inService
inService
% set global callRouting routingLabel TO_PHONES routingLabelRoute 3 trunkGroup PHONES inService inService
% set global callRouting routingLabel TO_ACCESSCORE routingLabelRoute 4 trunkGroup ACCESSCORE ipPeer ACCESSCORE
inService inService
To view the Routing workspace, select Configuration > System Provisioning > Category: Call Routing > Routing
When Trunk Group is selected as the option for Route Type, all Trunk Group related fields display.
When IP Peer is selected as the option for Route Type, the Trunk Group related fields are hidden and the field, "Zone for TG and IP
Peer" is changed to "Zone for IP Peer". This selection allows you to create Routing Label Routes with just an IP Peer as an option.
For more information about configuring a Routing Label from the EMA, refer to Call Routing: System Provisioning - Routing.
Route
The Route is used to determine how call routing is done. There are different ways to implement routing (dialed number, carrier, calling number,
trunk group, etc.) Trunk Group routing is used for this example configuration. It is the simplest and most straight forward way for a "pure" SBC
function to be implemented. It allows the operator to add users / routable numbers without having to configure those numbers into the SBC.
For our Trunk Group routing, calls that arrive on trunk group "CORE" are sent to Routing Label "TO_PEER", which routes the call to trunk group
"PEER". And in the other direction, calls that arrive on trunk group "PEER" are sent to Routing Label "TO_CORE", which routes the call to the
"CORE" trunk group.
In the examples below "DALNBS01" is the name of the SBC being used in this document.
% set global callRouting route trunkGroup PEER DALNBS01 standard Sonus_NULL 1 all all ALL none Sonus_NULL
routingLabel TO_CORE
% set global callRouting route trunkGroup CORE DALNBS01 standard Sonus_NULL 1 all all ALL none Sonus_NULL
routingLabel TO_PEER
% set global callRouting route trunkGroup PHONES DALNBS01 standard Sonus_NULL 1 all all ALL none Sonus_NULL
routingLabel TO_ACCESSCORE
% set global callRouting route trunkGroup ACCESSCORE DALNBS01 standard Sonus_NULL 1 all all ALL none Sonus_NULL
routingLabel TO_PHONES
% commit
To view the Routing workspace, select Configuration > System Provisioning > Category: Call Routing > Routing
For more information on Routing Label, refer to Call Routing: System Provisioning - Routing.
Link Detection
Link Detection is only useful for HA systems (2 units).
Link detection is used to determine if the active unit needs to be failed over to the other unit. If a certain number of links (configurable) within a
"link detection group" fail then a failover will occur. A link is considered failed if it loses connectivity to the router (for example if the cable is pulled
or if the router port is turned down). In addition if a non-zero ping target IP address is configured, a link can be marked out of service if pings to
this predefined IP address fail.
It is recommended to use 0.0.0.0 as the ping target for enterprise and simple deployments. This disables the "ping" test functionality (other link
detection functionality is not affected). If you do wish to activate the system failovers using a ping target, please contact Ribbon.
If you do activate the ping test functionality (configure a non-zero ping target) you need to be careful to ensure that the ping target IP will
ALWAYS respond to "ping", otherwise the SBC detects a link failure, and could cause a failover to the other unit.
Note
Before "enabling" Link Detection make sure the link lights on the SBC are illuminated, and that the router port is up. Otherwise, right when Link
Detection is enabled, a failure will be detected and the unit may fail over.
Configuration Questionnaire
There is an extensive amount of information you need to have up front, before starting the configuration of your SBC Core. You will need to have
completed the physical connectivity (Hardware Installation) and IP plan (what IP address will be assigned to each physical port) for your SBC.
The IP Plan is generally completed using an Excel spreadsheet. This spreadsheet shows the IP address that will be allocated for each of the
various interfaces in your network.
Even for a simple network, it is important to create this document for future reference. See Creating an IP Plan for details. If needed, please
contact Ribbon for an example spreadsheet.
Information Needed for Software Application Installation

Once you have installed the SBC hardware, the application software must be installed. As part of this installation, you will be prompted for some
configuration information. This step is done from the EMA.
The steps for installing the application are described in SBC Core Software Installation and Upgrade Guide. As a quick summary, the information
configured during this step includes (for each unit of a High Availability (HA) pair:
System Name
Host name
Management IP address for management port 0
Management IP address for management port 1
NTP server IP address
Note
The BMC is not applicable to the SBC SWe platform.
Call Processing Configuration for Simple Routing
Table 5: Call Processing Configuration for Simple Routing
Field Description Example Your

Data
Zones SIP Port and Trunk Group reside in Zone. Each Zone represents an external customer peer core phones
(endpoints). accesscore
There are also a Zone(s) used for internal (Trusted) nodes.
SIP Port on Private IP address used to send and receive SIP messages to equipment on the Private side 192.168.75.10 Included in
(Internal) side of the network IP Plan
SIP Port on Public IP address used to send and receive SIP messages to equipment on the Public side of 10.35.66.189 Included in
side the network IP Plan
Trunk Group to CORETG

Server
on Trusted Private
side
Trunk Groups to PEERTG

Server
on the Un- trusted
Public side
Codec Entries One entry for each codec that could be used. Used in the PSP (below) G711-20-RFC2833
Packet Service Used by the Trunk Group to determine the Codecs, Packet Size, Transcoding G711-EITHER_OOB- 2833
Profiles options. Name this so that it is easy to see which options are offered.
G729AB- EITHER_OOB-
2833
CDR Server (SFTP IP address and log in information for a downstream SFTP server that will receive CDR
server) sent by the SBC 5400 series
Routing Label One for each trunk group TO_PEER TO_CORE
Route Using Trunk group routing. Trunk Group CORETG routes to Routing Label TO_PEER, 2 Routes added, one for
and PEERTG routes to TO_CORE each trunk
group that routes to the
other trunk group.
CLI Script Creates Trunk Group and Routes

Key fields that will change for each trunk group added:
1. NEW_TRUNK - trunk group name.

2. 216.37.55.90 - ip address of far end.
3. CAC call limit currently 50
4. rlToNEW_TRUNK - routing label to NEW_TRUNK
5. peerNEW_TRUNK - ip peer NEW_TRUNK
6. Numbers that route to the pbx - 7652320276 (the below script assumes that the following are already defined):
7. PBX_SIP- ipsignaling profile
8. pspMediaRelay - packet service profile
9. "#" = comment lines
# Start of Scrip to add a new trunk group and routing information
# CREATE trunk group
configure
set addressContext "default" zone "zonePublicTrunking" sipTrunkGroup "NEW_TRUNK" media
mediaIpInterfaceGroupName "customerPublic"
set addressContext "default" zone "zonePublicTrunking" sipTrunkGroup "NEW_TRUNK" ingressIpPrefix
"216.37.55.90" "32"
set addressContext "default" zone "zonePublicTrunking" sipTrunkGroup "NEW_TRUNK" policy media
packetServiceProfile "pspMediaRelay"
set addressContext "default" zone "zonePublicTrunking" sipTrunkGroup "NEW_TRUNK" policy signaling
ipSignalingProfile "PBX_SIP"
set addressContext "default" zone "zonePublicTrunking" sipTrunkGroup "NEW_TRUNK" signaling methods message
"reject" publish "reject" subscribe "reject" notify "reject" info "reject" register "reject" update "reject"
set addressContext "default" zone "zonePublicTrunking" sipTrunkGroup "NEW_TRUNK" cac callLimit "50"
set addressContext "default" zone "zonePublicTrunking" sipTrunkGroup "NEW_TRUNK" mode inService
set addressContext "default" zone "zonePublicTrunking" sipTrunkGroup "NEW_TRUNK" state enabled
commit
# Far end IP
set addressContext "default" zone "zonePublicTrunking" ipPeer "peerNEW_TRUNK" ipAddress "216.37.55.90" ipPort
"5060"
## need to add PSP and sig profile
set addressContext default zone zonePublicTrunking ipPeer peerNEW_TRUNK policy ipSignalingProfile PBX_SIP
set addressContext default zone zonePublicTrunking ipPeer peerNEW_TRUNK policy packetServiceProfile
pspMediaRelay
commit
# Numbers and routing label - do a commit after each 5 number ranges added
commit
set global callRouting routingLabel "rlToNEW_TRUNK" routingLabelRoute "1" trunkGroup "NEW_TRUNK" ipPeer
"peerNEW_TRUNK" commit
set global callRouting route "none" "Sonus_NULL" "Sonus_NULL" "standard" "7652320276" "1" "all" "all" "ALL"
"none" "Sonus_NULL" routingLabel "rlToNEW_TRUNK"
set global callRouting route "none" "Sonus_NULL" "Sonus_NULL" "standard" "7652320277" "1" "all" "all" "ALL"
"none" "Sonus_NULL" routingLabel "rlToNEW_TRUNK"
set global callRouting routingLabel "rlToNEW_TRUNK"
commit
exit
# End of Script
Tips From Users
1. The accounting subsystem's default value for earlyAttemptState is disabled. This can result in lost ATTEMPT records (e.g. calls that hit the
SBC, fail, but for which there is no accounting record that the call ever hit the box).
Enabling this value can help with troubleshooting when setting up a system.
% set oam accounting admin earlyAttemptState enabled
2. The eventLog subsystem's default values are not optimized for heavy traffic. Set, the filterWriteMode to 'optimize'.
% set oam eventLog typeAdmin system fileWriteMode optimize fileSize 8192 filterLevel minor
% set oam eventLog typeAdmin debug fileWriteMode optimize fileSize 8192 filterLevel major
% set oam eventLog typeAdmin security fileWriteMode optimize fileSize 8192 filterLevel major
% set oam eventLog typeAdmin acct fileWriteMode optimize fileSize 8192 filterLevel info
% set oam eventLog typeAdmin trace fileWriteMode optimize fileSize 2048 filterLevel info
3. When using PSX for routing, ensure the system name configured during the SBC application installation is the same as what will be
configured on the PSX.
Also ensure the trunk group names are the same between SBC and PSX. Trunk group names should be in ALL CAPS. Just like the GSX
9000, the trunk group name and node name are sent in the policy request to the PSX. If there is a mismatch, the PSX will not find the node
and trunk group combination, thus the call will fail to route properly.
4. Back up your system at least once a week. If many configuration changes have been made, go ahead and back up the system after the
changes. These backups allow you to roll back to a previous configuration in the event of an error.
How to Retrieve Complete CLI Output

This command gives you the complete CLI output. You can also get specific parts of the CLI by modifying the command:
show configuration details | display set relative| nomore
Example of specific output:
show configuration details addressContext <AC Name> zone <ZONE Name> sipTrunkGroup <SIP TG Name> | display set
relative| nomore
Frequently Asked Questions

This section provides solutions to frequently asked questions (FAQs) about the SBC Core systems.
To search for a specific word or term, use the keyboard shortcut CTRL+F.
Click on a frequently asked question to learn more:
Can I change my SFPs from copper to fibre?

How do I transfer files from one unit to the other?
How do I block certain country codes?
How do I display numbers in the routing table?
How do I display the status of all the trunk groups in a Zone?
How do I display trunk group configuration data?
What if my video calls are not working?
How do I import a ".cli" script file from the EMA GUI?
How do I delete a specific routed number via CLI?
How do I delete a Trunk Group?
How do I turn Globalization (+1) on and off per trunk group
How do I display the status of the HA ports?
How do I display registered users (Access configuration)?
How do I view user types and passwords?
How do I change default passwords?
How do I view media range (base and max)?
How do I set up billing to transfer to SFTP server?
If I have multiple SIP Signaling Ports configured in a Zone, which is the source IP when sending a request to a peer?
How many routes per call does the ERE support?
If I replace my CDR server but keep the same IP address, are any changes needed on SBC?
Does SBC HA use a heartbeat scenario to talk to the other box?
I am using Linux shell 'top' command and see CPU utilization over 100% for a process. What does this mean?
Is there a simple way to compare my CLI configuration settings against the default values?
Can I install custom Linux scripts or make other OS level changes?
How may CLI 'set' commands can I commit at one time?
How do I monitor IP addresses of users logged into the SBC?
What is the maximum number of DM/PM rules allowed on the ERE?
Can I configure the SBC to send CDRs to multiple primary CDR servers?
Why can I not read OIDs directly from the MIB tables?
How long does it take to save an SMM containing a very large number of rules?
How does the SBC handle the call when the destination of "Refer-to" Header is down?
When the SBC receives “Refer-to” header, can the SBC assign multiple destination IP addresses including “Refer-to” header?
Can I change my SFPs from copper to fibre?
"I'm moving my SBC 5k from one building to another and need to change my SFPs from copper to fibre. Can I just swap them with the Ribbon-
provided SFPs before I power on the SBC, or is there more involved?"
You can swap the SFPs as long as you make sure to use the Ribbon-provided SFPs. Do not use a mix fiber and copper SFPs (all PKT ports have to
be the same and all HA ports have to be the same).
How do I transfer files from one unit to the other?

You can transfer files from one unit of a HA pair to the other (this comes in handy for large files that you may have to send over a slow VPN), using
SCP and port 2024.
Beginning with release 3.1, file transfers must be performed using SFTP on port 2024. Use the following steps as a guide (you can use any CLI
account in the Administrator group):
1. From the source SBC, login to Linux shell using admin/admin and change directory to where the file is located.
2. Connect to target SBC. In this example, SBXa is the source and SBXb is the target SBC.
admin@SBXa$ sftp -oPort=2024 admin@SBXb

Connecting to SBXb
admin@SBXb's password: <password>
Connected to SBXb
3. Use the put command to transfer a file to the specified directory as shown in the example below.
sftp> put sbc-V03.01.00-R000.x86_64.tar.gz /opt/sonus/external
How do I block certain country codes?

Create a Class of service BLOCK_COUNTRY_CODES. This will contain the country codes to block, and also not hit the "Non Subscriber" call
blocking.
Associated this class of service with the trunk group that is originating the calls (that you wish to block calls to certain country codes)
Example:
% show profiles services classOfService

BLOCK_COUNTRY_CODES
screening {
script "";
}
blocking { service enable; entry "" 20 {
callType internationalType;
}
entry "" 27 {
callType internationalType;
}
} nonSubscriberCallTypeFiltering private,nationalOperator,localOperator,nationalType,internationalType
,internationalOperator,longDistanceOperator,ipVpnService,test,transit
,otherCarrierChosen,carrierCutThrough,userName,mobile;
set addressContext default zone zonePublicTrunking sipTrunkGroup
APBX5TEST policy services classOfService BLOCK_COUNTRY_CODES
How do I display numbers in the routing table?
To display all numbers:
admin@DFWNBS01a> show table global callRouting route
To display numbers to a certain route label:
admin@DFWNBS01a> > show table global callRouting route routingLabel TO_BLUECARRIER

CALL
TIME PARAMETER
ELEMENT ELEMENT ELEMENT ROUTING DESTINATION DESTINATION CALL DIGIT RANGE
DOMAIN FILTER
ROUTING
TYPE ID1 ID2 TYPE NATIONAL COUNTRY TYPE TYPE PROFILE PROFILE NAME
LABEL
-------------------------------------------------------------------------------------------------------------------
-------------
trunkGroup BLUECARRIER BASSBC01 standard 9723014999 1 all all ALL none Sonus_NULL
TO_BLUECARRIER
TO_BLUECARRIER
trunkGroup CISCOCORE BASSBC01 standard Sonus_NULL 1 all all ALL none Sonus_NULL
TO_BLUECARRIER
trunkGroup TIHO_TRK BASSBC01 standard Sonus_NULL 1 all all ALL none Sonus_NULL
TO_BLUECARRIER
To display a specific number:
admin@DFWNBS01a> show table global callRouting route trunkGroup BLUECARRIER BASSBC01 standard 9723014999
CALL
TIME PARAMETER
ELEMENT ELEMENT ELEMENT ROUTING DESTINATION DESTINATION CALL DIGIT RANGE FILTER DOMAIN
ROUTING
TYPE ID1 ID2 TYPE NATIONAL COUNTRY TYPE TYPE PROFILE PROFILE NAME
LABEL
-------------------------------------------------------------------------------------------------------------------
-------------
TO_BLUECARRIER
You can also do a search from the EMA GUI. To view the Routing workspace, see Call Routing: System Provisioning - Routing.
Figure 1: Routes
How do I display the status of all the trunk groups in a Zone?

admin@DFWNBS01a> show status addressContext default zone zonePublicTrunking trunkGroupStatus
trunkGroupStatus APBX5TEST {
state inService;
totalCallsAvailable50;
totalCallsInboundReserved0; inboundCallsUsage0; outboundCallsUsage0;
totalCallsConfigured50; priorityCallUsage0; totalOutboundCallsReserved
0; bwCurrentLimit-1; bwAvailable-1; bwInboundUsage0; bwOutboundUsage0;
packetOutDetectStatenormal;
}
trunkGroupStatus TKSOFTWARE {
state inService;
totalCallsAvailable10;
totalCallsInboundReserved0; inboundCallsUsage0; outboundCallsUsage0;
totalCallsConfigured10; priorityCallUsage0; totalOutboundCallsReserved
0; bwCurrentLimit-1; bwAvailable-1; bwInboundUsage0; bwOutboundUsage0;
packetOutDetectStatenormal;
}
How do I display trunk group configuration data?

You can view the trunk group configuration data using the CLI.
admin@DFWNBS01a> show table addressContext default zone zonePublicTrunking
sipTrunkGroup APBX5TEST
state enabled; mode inService; policy {
carrier0000;
country1; sipDomain""; localizationVariant northAmerica; digitParameterHandling {
numberingPlanNANP_ACCESS; ingressDmPmRule ""; egressDmPmRule"";
}
callRouting {
elementRoutingPriority DEFAULT_IP;
}
media {
packetServiceProfile pspMediaRelay;
}
services {
classOfService BLOCK_COUNTRY_CODES;
}
signaling {
ipSignalingProfile PBX_SIP;
}
}
cac {
callLimit 50;
}
signaling {
methods {
message reject;
publish reject; subscribe reject; notify reject; info reject; register reject; update reject;
}
}
media {
mediaIpInterfaceGroupName customerPublic;
}
What if my video calls are not working?

Check following:
1. Video bandwidth:
a. Check CAC configuration
b. Check reduction factor
2. Passthrough calls are permitted:
a. Check Packet Service Profile flags (no transcode option)
b. No convert mode for Late Media video calls
3. Codec List Profile – check if codecListProfile manipulation results in no coded in offer/answer
4. Ingress/Offered SDP – check if video m -line is present
How do I import a ".cli" script file from the EMA GUI?

This mechanism can be used to speed up the process of configuring the SBC. A script file can be prepared (based on specific data from other
existing systems) and then imported into the SBC. For example you could create a trunk group and routable numbers for one particular customer in
one script file. You then import this script, and the customer is fully provisioned and ready to go.
The ".cli" file contains CLI commands, exactly of the same format as typing in the commands from the CLI. It should be in text format only. Note that
the default behavior of the system is to interpret "spaces" as a request for auto-completion, so that extra spaces in your ".cli" file will cause errors.
You can turn this function off by using the CLI command:
> set complete-on-space false
Steps:
1. Create text file with CLI commands. It is best to use Microsoft WordPad (should not use Word). This file must start with "configure" and end
with "commit". Name of file must end in ".cli". Note that this is case sensitive ".CLI" will not work. Also note you may need to save the file as
"text", then rename the file to end in ".cli".
2. Include the "commit" command after each five CLI commands.
3. On the SBC main screen, navigate to Administration > System Administration > Configuration and Profile Import/Export.
For more information on upload configuration, refer to System Administration - Configuration and Profile Import and Export - PM.
See example CLI script to create a new trunk group and routing information "CLI Script Creates Trunk Group and Routes" on page Reference
Configuration.
How do I delete a specific routed number via CLI?

You must put in the full routing data involving the number to delete it via the CLI.
admin@DFWNBS01a% delete global callRouting route none Sonus_NULL Sonus_NULL standard 2144761510 1 all all ALL none
Sonus_NULL
How do I delete a Trunk Group?

The trunk group must be disabled and out of service before you can delete it.
admin@SBC01a% set addressContext default zone zonePublicTrunking sipTrunkGroup "PURDUERES_7655883470 " state
disabled mode outOfService
admin@SBC01a% commit
admin@SBC01a% delete addressContext default zone zonePublicTrunking sipTrunkGroup "PURDUERES_7655883470 "

admin@SBC01a% commit
How do I turn Globalization (+1) on and off per trunk group

You may need to send Globalized numbers out to a carrier trunk group, while stripping the +1 off calls that are sent to PBX trunk groups. This is
accomplished via the trunk groups IP Signaling Profile. Within the IP signaling profile there is a Globalization profile. On the trunk group that needs
Globalization, the IP signaling profile should contain a Globalization Profile that enables globalization. On the trunk group that globalization should not
occur, a different IP Signaling profile is needed (one that has a Globalization profile that disables globalization).
You can also remove the numberGlobalizatoinProfile from the IP signaling profile that does not need Globalization (if you did not need any of the
settings).
Using the DM-PM rule SIP_REMOVE_PLUS1 does not work if globalization is turned on.
Trunk group example:
1. Associate an IP Signaling Profile which has Globallization Profile turned off to the trunk group.
% set addressContext default zone zonePublicTrunking sipTrunkGroup DECA_3175672646 policy signaling

ipSignalingProfile PBX_SIP
% commit
2. Verify change, where NO_GLOBAL is a profile that does not globalize any numbers.
> show configuration profiles signaling ipSignalingProfile PBX_SIP
egressIpAttributes {
numberGlobalizationProfile NO_GLOBAL;
flags {
bgcfTargetSchemeTransparency disable;
> show configuration profiles signaling numberGlobalizationProfile NO_GLOBAL

entry calledNumber {
digitType all;
countryCodeSource destination;
globalize disable;
}
(the above results are shortened for brevity)
How do I display the status of the HA ports?

Check the states of these ports after initial system configuration to ensure the fibers are installed correctly and the two units are communicating.
admin@SBC01a> show status system highAvailabilityPort status DFWNBS01a haPort1 {

macAddress 00:10:1b:01:11:1c;
ipAddress 0.0.0.0;
negotiatedSpeed speed1000Mbps;
oosReason na;
How do I display registered users (Access configuration)?

The SBC can cache Registration information by turning on the Trunk Group field "Require Registration". It is often useful to display the users that
have successfully Registered.
% show status addressContext default sipRegCountStatistics

% show status addressContext default sipActiveRegNameStatus
How do I view user types and passwords?

On the SBC Application (accessed by the EMA and the CLI), various types of users are predefined. Each type of user has different capabilities.
Please see Managing SBC Core Users and Accounts for details.
To add a new user or reset password from the EMA GUI, perform following:
1. On the SBC main screen, navigate to Administration > Users and Application Management > User and Session Management.
2. From User and Session Management window, select user or click appropriate Edit/Add/Delete icon (Refer to Users and Application
Management - User and Session Management).
To add a new user from CLI:
% set oam localAuth user <user_name> group <group_name>
How do I change default passwords?

Some customers may require that all default passwords are changed. The default passwords and method to change them are described at Managing
SBC Core Users and Accounts.
How do I view media range (base and max)?
To check the range of ports that used for media:
admin@SBC01A > show configuration system media mediaPortRange baseUdpPort baseUdpPort 1024;
admin@SBC01B > show configuration system media mediaPortRange maxUdpPort maxUdpPort 65148;
Port 5060 is reserved for SIP and is automatically excluded.
How do I set up billing to transfer to SFTP server?

You can set up to transfer CDR to an off board SFTP server on a regular basis, for example once per hour.
1. Set up the cdrServer. Information needed are the IP address, user name, password, file name extension, and the path on the server where
the billing files will be stored.
The full path should be given "/export/home/billing"
The file name extension can be the name of the System, for
example "DALNBS01"
admin@DALNBS01a> show table oam accounting cdrServer admin
2. Set up the duration for the accounting logs to rollover to the next file (for example 60 minutes).
Set a start time of the format "2011-08-24T18:00:00"

Set rollover type to "repetitive"
Set rollover action to "start"
admin@DALNBS01a> show table oam eventLog typeAdmin acct
3. Check the status of the transfer:
admin@DALNBS01a> show table oam accounting cdrServer s
If I have multiple SIP Signaling Ports configured in a Zone, which is the source IP when
sending a request to a peer?
As a best practice, Ribbon recommends configuring one signaling port per zone. The SBC chooses a port (usually the first port) in the zone for
outbound connections. However, the SBC cannot enforce the use of a specific signaling port within the zone to initiate a call on a trunk group. The
trunk is assigned to a zone and not to a signaling port in the configuration model. To associate a unique source port for each trunk group, create
separate zones defining a single signaling port per zone.
How many routes per call does the ERE support?

The ERE returns up to 10 routes. If more than 10 routing label routes are created, only the first 10 in-service routes are returned.
If I replace my CDR server but keep the same IP address, are any changes needed on SBC?
The SBC writes CDRs locally, and simply transfers them using SFTP to the CDR server (for example, DSI L0 server) based on the IP address listed
in CDR server settings on the SBC. If you replace the CDR server with another server, but maintain the same IP address and user settings, no
change is needed on the SBC.
Does SBC HA use a heartbeat scenario to talk to the other box?

The SBC uses Transparent Inter-process Communication (TIPC) to monitor several processes and applications running on the opposite server.
I am using Linux shell 'top' command and see CPU utilization over 100% for a process. What
does this mean?
The top command returns the sum of CPU utilization by all threads within a process. The SBC is a multi-core system, and the process in question is
utilizing more than one core. For more accurate results, use top –Hcommand to see process utilization per core/thread.
Is there a simple way to compare my CLI configuration settings against the default values?
Yes! You can view both configured values and defaults using the 'show' command. First, turn on default values setting using the following 'set'
command:
set show defaults true
Next, enter your 'show configuration' command:
show configuration <one or more list objects>
Refer to CLI System-Level Mode for details.
Can I install custom Linux scripts or make other OS level changes?

NO! SBC Core is a closed network device. Customer modifications at the Linux level are not allowed or supported. These modifications can cause
stability, update and fail-over issues on SBC platform. Customers must ONLY configure the SBC using the supported interfaces(CLI, REST, EMA,
EMS).
How may CLI 'set' commands can I commit at one time?
Note
As a best practice, issue a commit command after each group of approximately 10 set commands are entered.
How do I monitor IP addresses of users logged into the SBC?

Login to the EMA and navigate to Administration > Users and Application Management > User Management window and view User Sessions table.
What is the maximum number of DM/PM rules allowed on the ERE?

The ERE does not limit the number of DM/PM rules.
Can I configure the SBC to send CDRs to multiple primary CDR servers?
Currently, the SBC only supports one one primary and one secondary CDR server.
Why can I not read OIDs directly from the MIB tables?
The OIDs are indexes in the MIB tables, and indexes are not readable using SNMP GET requests. The SNMP GETNEXT requests are used to find
out what indexes are currently present in the MIB tables. For more information, refer to the section How to Retrieve Ribbon Enterprise MIB OIDs.
How long does it take to save an SMM containing a very large number of rules?
It can take several hours to execute and save an SMM with a very large number of rules.
For example, saving an SMM profile containing 10,000 rules, 80,000 criterion and 50,000 actions can take approximately 3 hours and 45 minutes.
This delay applies to all interfaces (CLI, GUI and REST API).
How does the SBC handle the call when the destination of "Refer-to" Header is down?
If the destination of “Refer-to” header is down due to some reason, then the SBC reconnects the original call between the transferee and transferor
again.
When the SBC receives “Refer-to” header, can the SBC assign multiple destination IP
addresses including “Refer-to” header?
The SBC cannot assign multiple destination IP addresses that include "Refer-to" headers.

550-08638 07.01 SBC Core 11.01.00R000 FAQs and Tips

Uploaded by

Copyright:

Available Formats

550-08638 07.01 SBC Core 11.01.00R000 FAQs and Tips

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-08638 07.01 SBC Core 11.01.00R000 FAQs and Tips

Uploaded by

Copyright:

Available Formats

SBC Core

FAQs and Tips

Disclaimer and Restrictions

Compliance with Applicable Laws and Export Control Laws

SBC Core Tips

Call and Message Routing Details

Background on SIP Trunking and Access

Name Description Examples

Unit #1 of The System name with an "a" appended on it DALNBS01a

Unit #2 of The System name with an "b" appended on it DALNBS01b

IP Interface Represent the type of far ends. TRUST_IPIG, UNTRUST_IPIG Or

Zone All CAPS INTERNAL, EXTERNAL, CUSTOMER_A

Describes the far end.

Trunk CORE, PEER, CUSTOMER_A

Signaling Lower case "peer" prefixing the trunk group peerCUSTOMER_A

Routing rlToCUSTOMER_A, TO_CUSTOMER_A

IP Signaling CUSTOMER_A_IPSP ALLPEERS_PSP

> show status system policyServer

Differences Between Trunking and Access Configuration

1. Phones Register to a SIP Port on the SBC

Table 1: Key Differences between Access and Trunking Configuration

Link Verification Configuration

Physical Link Detection

Recommended threshold values (switchover criteria) are:

Port Type Threshold

Physical Link Detection

Physical Link Detection is always instantaneous, regardless of Logical Link Detection.

The following timer and retry values are recommended:

Figure 1: SBC 5400 Series Cabling Configuration for Link Verification

Table 2: SBC 7000 Series Cabling Configuration for Link Verification

set addressContext default linkDetectionGroup EXTERNAL_LD_LDG_A ceName SBC01A type ip threshold 1

set addressContext default linkDetectionGroup INTERNAL_LDG_B ceName SBC01B type ip threshold 1

set addressContext default linkDetectionGroup EXTERNAL_LD_LDG_B ceName SBC01B type ip threshold 1

Configuring Physical Port

set addressContext ADDR_CONTEXT_1 linkDetectionGroup LDG1 ceName bf013.eng.sonusnet.com threshold 0 linkMonitor

PSP Codec Selection for the Call

1. Offered by the originator (in the SIP INVITE)

Use the originator's first choice codec and force transcoding.

In this section: Related articles:

Configuring IP Interface Groups and Interfaces

For complete details, refer to Configuring IP Interface Groups and Interfaces.

High Level Simple Configuration

A single Address Context will be configured, so no overlapping IP address will be used.

Table 1: Key Configuration Items

Packet Service Specify G.729A Specify G.711

IP Signaling SIP Parameter settings SIP Parameter settings

Signaling Peer IP address of far end IP address of feature server

Route One per trunk group One per trunk group

To get into configuration mode from the CLI:

Two are used for the Trunking configuration

Table 2: Zone Usage | Zone Types

Zone Configuration Usage Purpose

peer Trunking Traffic to/from far end carrier

core Trunking Traffic to/from operator trunking equipment

phones Access Traffic to/from phones

accesscore Access Traffic to/from operator feature server

Example of Using Zone Types in CLI

% set addressContext default zone peer id 2

SIP Signaling Ports