LEARN HOW TO

USE PERIMETA
Learn How To
Use Perimeta

Sean Ferguson

CONFIDENTIAL
Copyright 2000 – 2016 Metaswitch Networks. All rights reserved.

This manual is issued on a controlled basis to a specific person on the

understanding that no part of the Metaswitch Networks product code or
documentation (including this manual) will be copied or distributed without prior
agreement in writing from Metaswitch Networks.

Metaswitch Networks reserves the right to, without notice, modify or revise all
or part of this document and/or change product features or specifications and
shall not be responsible for any loss, cost, or damage, including consequential
damage, caused by reliance on these materials.

Metaswitch and the Metaswitch logo are trademarks of Metaswitch Networks.

Other brands and products referenced herein are the trademarks or registered
trademarks of their respective holders.

01 October 2016

Version: 2

CONFIDENTIAL
Contents

Learn How To Page

Introduction and Overview

Get to grips with the guide.....................................................................................................7

An introduction to Perimeta....................................................................................................9

Understand the types of network Perimeta connects to.......................................................11

Understand Perimeta’s system roles.....................................................................................13

Understand the different Perimeta platforms.........................................................................15

The Configuration Interfaces

Use the Craft Terminal..........................................................................................................17

Use the CLI..........................................................................................................................19

Add new Craft/CLI users......................................................................................................23

Use the CLI stager...............................................................................................................25

Basic System Setup

Configure Perimeta’s management network connection.......................................................29

Configure Perimeta to use DNS............................................................................................31

Configure Perimeta to use NTP............................................................................................33

Apply your Perimeta license..................................................................................................35

Set up Perimeta billing..........................................................................................................37

Basic Service Configuration

Understand the layers of Perimeta configuration...................................................................39

CONFIDENTIAL
Contents

Learn How To Page

Understand port groups and view your port group scheme..................................................41

Add a service interface.........................................................................................................43

Set up Perimeta’s media interfaces.......................................................................................49

Configure a basic adjacency.................................................................................................51

Configure and apply an adjacency interoperability profile......................................................55

Create an account................................................................................................................57

Understand how Perimeta handles SIP registrations.............................................................59

Configure capacity control limits on an adjacency.................................................................63

Set up NAT traversal.............................................................................................................67

Configure phones and peers to work with Perimeta..............................................................71

Add a new peer to your deployment.....................................................................................73

Use Peer Groups to load-balance between peer servers......................................................79

Routing

Design and configure routing policy tables............................................................................81

Security

Understand the different levels of Perimeta security..............................................................91

Plan and configure your dynamic blacklisting profiles............................................................93

Advanced Security Configuration

Configure DSCP packet marking........................................................................................103

CONFIDENTIAL
Contents

Learn How To Page

Understand and configure DTMF interworking....................................................................107

Set up Perimeta’s H.323 support........................................................................................111

Control the media codecs used in your network.................................................................113

Set up media transcoding..................................................................................................117

Set up media bypass..........................................................................................................121

Understand Perimeta’s redundancy features.......................................................................127

Understand Perimeta’s advanced message editing features...............................................129

Add a TLS certificate to Perimeta.......................................................................................131

Set up Perimeta to be managed by MetaView Web............................................................135

Diagnostics

Use the Service Assurance Server (SAS)............................................................................141

View Perimeta alarms and events.......................................................................................151

Configure Perimeta to work with an SNMP client................................................................153

Configure Perimeta to work with a Syslog server................................................................155

Use packet capture and Wireshark to examine Perimeta traffic...........................................157

Solve basic Perimeta problems..........................................................................................163

Investigate blacklisting........................................................................................................167

View recent logs in the Craft Terminal.................................................................................171

Record per-call logs...........................................................................................................173

Gather a diagnostics package............................................................................................177

CONFIDENTIAL
 Get to grips with the guide
Get to grips with the guide
This is the Learn How To Guide for Perimeta, Metaswitch’s Session Border Controller. It’s
designed to give you the knowledge and skills you’ll need to manage and configure Perimeta.
Work through this guide, and by the end you’ll be familiar with all the key pieces of Perimeta
config, and ready to set up Perimeta to protect your network!
You might already have seen a version of our Perimeta Commissioning Guide, and it’s worth
knowing how that guide relates to this one. This Learn How To Guide is a comprehensive tour
of Perimeta configuration, with individual tasks that teach you how to use particular settings
and features. The Commissioning Guide is a step-by-step process designed to give you the
most effective path to putting together a working, fully configured Perimeta deployment in
a real environment. It’s tailored to your particular Perimeta platform, and is more direct than
this guide - but it uses pre-defined configuration, and working through it won’t necessarily
leave you with the understanding you need to make your own changes to your configuration
later. This guide will give you that understanding, as well as showing you how to monitor and
troubleshoot your system once it’s up and running.
You don’t need to have access to a Perimeta system to work through this guide, but it
helps. Throughout, we’ll show you step-by-step how to configure Perimeta features using its
management interfaces, and those steps will make more sense (and be easier to remember) if
you have access to a lab system, so you can actually work through them and play around with
the commands. Just don’t play around with a live system!

CONFIDENTIAL 7
8
Get to grips with the guide

CONFIDENTIAL
 An introduction to Perimeta
An introduction to Perimeta
If you’re reading this, you probably already know that Perimeta is a Session Border Controller
(SBC) from Metaswitch; or, more precisely, a family of SBC products, providing a range of
solutions tailored for a wide variety of VoIP (Voice over IP) networks. You probably also know
that SBCs like Perimeta exist to protect VoIP networks against external threats. You might also
know that SBCs can help you control your VoIP traffic, putting limits on it and modifying it to
help different devices interoperate.

How does Perimeta protect your network?

Your core VoIP devices need to connect to the outside world to do their job, whether they’re
accepting registrations from IP phones over the global internet, connecting to other carriers
through SIP trunks, or supporting IP PBXs at customer sites. Any of these scenarios can
expose your equipment (your softswitches, SIP application servers etc.) to threats it was not
designed to deal with.
These threats can include:
• Denial Of Service (DOS) attacks
• theft of service
• port scanning and other methods of gathering sensitive information about your network.
A traditional firewall cannot effectively protect against these threats, because it cannot recognize
legitimate VoIP traffic and distinguish it from prohibited or malicious traffic. That’s why you need
a VoIP-aware SBC like Perimeta.

When you deploy Perimeta, all VoIP traffic (both signaling and media) passes through it on the
way in and out of your core network. This allows Perimeta to police that traffic and protect
your VoIP infrastructure in numerous ways.
• It prevents any non-VoIP traffic from entering your core VoIP network.
• It only permits known devices (phones that have identified themselves by registering, or
previously configured trunks/PBXs) to make calls.
• It only admits media traffic that is part of a legitimate signaled call.
• It rewrites signaling messages to hide the internal architecture of your network (topology
hiding).
• It identifies and blacklists sources that repeatedly send suspicious, malformed or excessive
traffic.

What else does Perimeta do?

Perimeta’s primary purpose is to safeguard your network. However, its VoIP-awareness and
position at the edge of your network allow it to provide a range of useful function, helping to
ensure the smooth running of your VoIP services.

CONFIDENTIAL 9
An introduction to Perimeta

• Access or peer devices are often behind NAT (Network Address Traversal) devices, which
can cause problems for VoIP signaling, with discrepancies between actual contact IP
addresses and ports and the IP addresses provided in SIP messages. Perimeta has a full
set of NAT traversal features, covering both signaling and media, which allow your VoIP
traffic to flow unimpeded.
• Many SIP devices have differing implementations of various SIP specifications and do not
interoperate well (or at all!) - because all SIP traffic passes through the SBC, it is perfectly
placed to interwork between such devices. Perimeta comes equipped with a range of
dedicated configuration options that provide straightforward solutions for a host of common
interoperability problems. Beyond that, it provides a suite of powerful SIP and SDP editing
tools, allowing you to create your own tailored solutions!
• Differences in codec support can create a similar stumbling block for media. Depending on
your license, Perimeta can provide software-based media transcoding without the need for
expensive additional equipment.
• Perimeta tracks a vast number of statistics on both signaling and media traffic, including a
range of voice quality statistics, providing you with comprehensive information about your
VoIP services.
These highlights are only a few selections from Perimeta’s feature set.

10 CONFIDENTIAL
 Understand the types of network Perimeta connects to
Understand the types of network Perimeta connects to
The three network types
Perimeta’s features and configuration are based on connections to three types of network.
Every Perimeta Session Controller connects to at least one network of each type.
• We’ve already encountered core networks. These are the networks that contain your
VoIP infrastructure; the devices you want Perimeta to protect, such as your softswitch. For
most Perimeta deployments there will only be one core network.
• Access networks are the other side of the coin. These are the networks containing SIP
phones, peer connections, PBXs, and any other devices that will send and receive VoIP
traffic to and from your core network.
• The management network contains the non-VoIP devices that connect to Perimeta; the
SSH client you use to configure your Session Controller, DNS and NTP servers, network
management systems that monitor your Session Controller using SNMP, etc. There is only
one management network for each Session Controller.
Typically, the interfaces to your core networks will use a different physical link than the interfaces
to your access networks (as well as different subnets) for maximum security and separation of
core and access. For systems deployed on hardawre, the management network is always on
a different physical link if there are enough physical links available.

CONFIDENTIAL 11
 Understand the types of network Perimeta connects to

12
CONFIDENTIAL
 Understand Perimeta’s system roles
Understand Perimeta’s system roles
The two Perimeta deployment models
Perimeta has two deployment models that determine how your Perimeta deployment handles
signaling and media.
• In the integrated model, a single Perimeta Session Controller handles both signaling and
media. This provides the greatest simplicity and convenience in terms of hardware and
configuration, and is ideal for smaller-scale deployments.
• In the distributed model, a single Session Controller still handles signaling, but it acts as
a controller for one or more others that handle media only (in some cases, it can handle
some of the media itself). As well as allowing greater scaling of media capacity than in an
integrated deployment, distributed deployments allow you to provide local media handling
for networks and customers in remote locations.
It’s important to understand which deployment model you are using when you configure
Perimeta! The diagrams below show you how the two models work, and also introduce a few
acronyms you’re going to need to know.

Some key acronyms - ISC, SSC and MSC

You’re going to be seeing these three acronyms over and over again throughout the rest of this
guide. They refer to the different Perimeta system roles. Each Perimeta Session Controller fills
one of these roles, which determine how it functions and what traffic it handles. Here’s what
they mean.
• ISC stands for Integrated Session Controller. An ISC handles signaling and media traffic,
and is an integrated deployment all on its own! You can also use an ISC to control MSCs in
a distributed deployment, in which it can also handle some of the media itself. However, its
signaling capacity is typically lower than that of an SSC on equivalent hardware.

CONFIDENTIAL 13
Understand Perimeta’s system roles

• SSC stands for Signaling Session Controller. An SSC handles signaling traffic only, and
is only used in distributed deployments. It controls one or more MSCs to handle the media
traffic, programming them with the details of signaled calls.
• MSC stands for Media Session Controller. An MSC handles media traffic only, and is
only used in distributed deployments. It is controlled by an SSC or ISC.

14 CONFIDENTIAL
 Understand the different Perimeta platforms
Understand the different Perimeta platforms
Perimeta is available on three different kinds of platform - Metaswitch’s dedicated CH6010
hardware, commercial off-the-shelf (COTS) hardware, or virtualized environments.
For a lot of what we’ll cover in this guide, your platform isn’t actually very important. The
Perimeta software is the same whatever the platform - you configure it the same way, and it
does mostly the same things.
Your platform does affect some things, of course - most obviously, how you physically install
and cable up your system. There are also a few bits of configuration that can vary between the
different platforms, so it’s important to know which platform you’re using.

CH6010 hardware
The CH6010 is a purpose-built Perimeta hardware chassis using the ATCA (Advanced
Telecommunications Computing Architecture) standards - a popular set of standards
for communications hardware. Each CH6010 Perimeta Session Controller comes as a single
appliance, with the chassis containing two processor-blades. Each of these processor blades
runs a separate instance of the Perimeta software, and together they work as a redundant pair
- while one (the primary) is providing service, the other one is always a backup, ready to take
over if the primary fails.

COTS hardware
For service providers who want to source their own hardware, Perimeta is compatible with
various models of commercial off-the-shelf (COTS) hardware. Each system needs a pair of
servers for redundancy. Unlike the CH6010 (in which the chassis connects the redundant pair),
you’ll need an Ethernet connection between the two servers.
Perimeta supports a range of different platforms at varying levels of cost and performance.
Metaswitch can also extend support to new platforms, as long as they meet certain minimum
requirements, which are set out in full in the Perimeta Hardware Requirements Guide.

CONFIDENTIAL 15
Understand the different Perimeta platforms

Virtualized environments
For service providers who wish to take advantage of the flexibility and scalability provided by
running their systems on virtual machines (VMs), you can deploy Perimeta in both VMWare and
OpenStack environments.
For more information on what is needed to run Perimeta in a virtual environment, please see
our Metaswitch Products Virtual Infrastructure Requirements Guide.

16 CONFIDENTIAL
 Use the Craft Terminal
Use the Craft Terminal
What is the Craft Terminal?
The Craft Terminal is one of Perimeta’s two management interfaces. It’s a menu-based system
that provides access to some basic operations and configuration options for your Session
Controller. It also allows you to access the other management interface, the Command Line
Interface or CLI, which includes most of the more advanced Perimeta configuration.
The Craft Terminal looks something like this.

The Craft Terminal - Main menu

Start here
In this section you will learn how to:
• Log in to the Craft Terminal.
• Navigate around the Craft Terminal menus and select options.
You will need:
• An SSH client such as Putty, on a machine with a connection to your Session Controller’s
management network.
• The management IP address of your Session Controller.

Note: When you first install your Session Controller it won’t have an IP address yet, so you won’t be
able to use SSH to access the Craft Terminal. In this case, you can access the Craft Terminal
directly using (depending on your Perimeta platform) a serial cable /serial concentrator, or
keyboard, video and mouse connected to your hardware.

• A username and password for a user account on your Session Controller.

Task 1: Log in to the Craft Terminal

1. Start up your SSH client and connect to the Session Controller management IP address. If
you need to set the port, set it to 22 (the standard SSH port).
2. When prompted, log in with your username and password.
Checkpoint:You have now logged in to the Craft Terminal.

CONFIDENTIAL 17
Use the Craft Terminal

Task 2: Explore the Craft Terminal

1. Once you’ve logged in, you’ll see the Main menu, just like in the image above. The first few
lines give you some status information about Perimeta, but just now you’ll want to look at
the lines that begin with a number. These are menu options, which you select by typing in
their number.
2. Try selecting the Admin menu by looking for the number next to it. Type in that number and
press Enter. You’ll see a whole new set of options.
3. Notice that some options have a > symbol next to them. These are the options that open
new menus. Options without this symbol perform operations or allow you to change
configuration settings. Type 0 and press Enter to go back up to the previous menu.
Checkpoint: You can now navigate through the Craft Terminal menus.
Helpful shortcuts
You’ve already learned everything you need to know to get around the Craft Terminal, but these
handy tips can help speed things up.
• You can type = at any time to jump back to the root menu.
• You can press Enter without selecting any options to refresh the status information at the
top of the menu.
• If you already know which options you’ll want in a menu and its sub-menus, you can type
multiple commands at once. For example, you could type 2 1 4 and press Enter to
immediately select option 2 in the first menu, select option 1 in the next menu, and then
select option 4 in the menu after that.

18 CONFIDENTIAL
 Use the CLI
Use the CLI
What is the CLI?
The CLI (command line interface) is the more advanced of Perimeta’s two management interface.
It provides a vast array of commands covering various areas of Perimeta’s configuration. If
you’re going to learn how to use your Perimeta system, you’re going to need to master the CLI.
The CLI does what it says on the tin; you type in commands, and they do one of the following
things.
• Move you around within the CLI. The CLI is organised into different modes, and which
mode you’re in determines which commands you can use. You can move between modes
using various commands; more on this below.
• Change configuration settings, covering everything from IP address assignments to SIP
interoperability options to CLI user details.
• Take immediate actions, such as applying a license key or pinging an IP address to check
the connection.
• Display information. You can view a range of statistics, service status information, and
details of existing configuration.

Navigating the CLI: Understanding modes

There are hundreds of commands in the CLI. To keep things ordered, they are organized into a
hierarchy. We call it that because the commands really are organized in a pyramid; a pyramid
of modes. Don’t worry if that doesn’t make much sense right now; bear with us and it’ll be
much clearer once you’ve seen how it works in practice. The key thing you need to know is
that the CLI commands available for you to use depend on which mode you are currently in.
Let’s start with an example, and a handy shortcut that makes using the CLI much easier - the
? key. Pressing ? will show you exactly which commands are available in your current mode,
with a brief summary of what each command does. You can see what this looks like below.

Lines that begin with bramley3 (the system name) here are the command prompt; the text
after the # symbol is what the user typed in. You can see how ? gives a list of available
commands.

CONFIDENTIAL 19
Use the CLI

You can also see how the available commands changed after the user typed sbc. That’s
because sbc is a mode command. It moves you to a different mode. In that mode there
are different commands available, some of which are also mode commands, and lead to yet
more modes! In this case, signaling is also a mode command; notice how the prompt
changes from bramley3(sbc)# to bramley3(signaling)# when you change modes so
you always know what mode you’re currently in.

Warning! Mode commands can do more than move you around. Some also activate features or create
configuration objects, then move you to a mode with further settings for that feature or
object. Don’t assume that a command doesn’t change configuration just because it’s a mode
command!

The other types of command are basic commands and universal commands. Basic
commands are limited to specific modes and just do things - they change a setting or perform
an action. Universal commands work anywhere, regardless of what mode you’re in - these
usually display information (commands that begin with show) or help navigate around the CLI.
Hopefully you can now understand why the CLI modes are like a pyramid; within (or below)
each mode can be more modes, with more modes below them, and so on. Here’s a diagram
showing a small part of the CLI and how the hierarchy fits together.

Getting around
The simplest way to move around the CLI is to use the mode commands, as in the examples
above. As well as any modes below your current mode, you can jump back to an ancestor
mode at any time by typing its command.

20 CONFIDENTIAL
 Use the CLI
An ancestor mode is one that you pass through on the way down the pyramid to your current
mode. For example, in the pyramid diagram above, signaling and sbc are ancestors of
control.

Note: You can also use any command you could use if you were in a particular ancestor of your
current mode, as long as there aren’t multiple possible commands with the same name. For
example, if you were in the control mode from the diagram above, you could still use the
congestion command from the signaling mode, since signaling is an ancestor of
control. After using it you would be back in the signaling mode.

You can jump back up the pyramid using the exit and end commands. Using exit takes
you up one level (it exits your current mode). Using end takes you all the way back to the top
level of the CLI.
If you get confused about your current location, just type show config location to see your
current mode and all its ancestors.

Using basic commands: Syntax and parameters

In general, Perimeta commands have the same basic syntax: <command>[parameters]. Some
commands don’t need any parameters, some need several.
For example, this is the command for adding a local IPv4 address to your Perimeta configuration.
local-ip-address ipv4 address
The address part is a parameter; when you use the command, you replace it with the address
you want to add. For example:
local-ip-address ipv4 1.2.3.4
If you’re unsure about what parameters a command uses, you can type the first part of the
command and press ?, which will show the valid options for what you can type next.
So far, so easy. However, sometimes you need to include spaces in a parameter value, and
the CLI needs to distinguish between a space within the parameter and the space that marks
the end of it. If your parameter value includes spaces, you must enclose it in quotation marks.
For example:
sip interop-profile “My first interoperability profile”
This command has a single parameter value of My first interoperability profile.
What if you actually want to include quotation marks in a parameter value (it might not seem
likely, but you’ll need to if you want to write scripts for Perimeta’s advanced message editing
features)? You’ll need to escape them by adding a preceding \ character. And if you want to
use a \, you’ll need to do the same thing! Here’s a rather unlikely alternative name for your
interoperability profile.
sip interop-profile “Profile with a \” and a \\ in its name”
The resulting name for the profile is Profile with a “ and a \ in its name. Other
characters you must escape to use in parameter values are #, !, and ? - the first two normally
mark everything that follows them as a comment which the CLI will ignore, and ? triggers help
text as you’ve already seen.

Viewing your current configuration

Before diving in and changing your configuration, you’re probably going to want to check the
current state of things. You can use the show config command to have a look at the current
configuration on your system, displayed as a list of CLI commands (helpfully indented to show
the hierarchy and make it clear which commands are in which modes).

CONFIDENTIAL 21
Use the CLI

Note: The output from show config displays Perimeta’s current settings; it is not a record of
commands entered. The commands appear in the order they are defined in the CLI, not the
order they were originally typed in.

This command comes in a few flavours.

Command Description
show config Shows all current configuration on your system, not
including built-in defaults.
show config here Shows current configuration for your current CLI
mode and all modes below it in the hierarchy.
show config defaults-included Shows configuration including the built-in defaults.
show config here defaults-included
show config warnings Shows only commands that currently have active
warnings about configuration problems.
Paging options
Some commands, like a full show config, will give you pages and pages of output. You can
choose whether you want Perimeta to display it page-by-page (with you having to press a key
after each page to move to the next one) or all at once for you to scroll back through or copy
and paste. Just use one of these commands from anywhere in the CLI:
• paging-options enable to see output page-by-page.
• paging-options disable to see output all at once.

Changing your mind: No commands

Sometimes you need to deactivate a feature, or return a setting you’ve changed to its default
state. You can do this for any command that changes configuration by adding no in front
of it to create its equivalent no command. For example, the command dynamic-peer-
routing enables Perimeta’s dynamic routing feature; if you later changed your routing setup
and wanted to turn dynamic routing off, you would use this:
no dynamic-peer-routing

22 CONFIDENTIAL
 Add new Craft/CLI users
Add new Craft/CLI users
When you first set up Perimeta, you’ll log in as the default user, called defcraft. Later on,
you’ll usually want to add more users, for a couple of reasons:
• Giving each person who configures Perimeta their own user details lets you keep track
of who made what changes. Perimeta keeps logs of all configuration changes, including
which users made them.
• You can give each user a different user level. The user level controls what each user is
allowed to do.

Note: Perimeta also supports authentication with an external user database (such as Microsoft
Active Directory) using the RADIUS protocol. This lets you manage your Craft users and their
user levels for different products all in one place.

User levels
Here are all the user levels you can choose from:
Super users
Super users can use almost all configuration. They’re the only users who can create other
users, and only they can upgrade the Perimeta software. However, they can’t use the CLI
stager, which lets you prepare changes in the CLI ahead of time - only admin users can use
the stager. We’ll come back to the stager later in this guide.
The default user, defcraft, is a super user.
Admin users
Admin users can use all the configuration super users can, except for upgrade and creating
other users. They’re the only users who can use the CLI stager.
Support users
Support users can only change diagnostics configuration. So they can change settings for
logging, alarms, etc., but they can’t change any service-related settings.
Read-only users
Read-only users can view information using show commands and Craft options that show
current settings, but they can’t change any configuration at all. They also can’t upload files to
Perimeta using SFTP (they can still download files). All the other user levels can upload files.

Note: If you’re set up for lawful interception (which you have to have licensed), you’ll also have
lawful interception users, and they’re the only users that can set up lawful interception. Details
about that are limited to the Perimeta Lawful Interception Guide, which is only available to
specially authorized users.

Passwords
When you add a user, you’ll have to give them a password. The rules for Perimeta passwords
depend on your configuration, but the minimum (and default) requirements are:
• They have to be six characters or longer.
• They can’t be made up of lots of repeats of a small handful of characters (e.g. ‘AaAaAAAA’).
• They can’t be simple sequences like ‘1234567’ or ‘ABCDEFG’.

CONFIDENTIAL 23
Add new Craft/CLI users

• They can’t be two letters, six numbers, and then another letter, because that’s the format
of personal identity numbers used in some countries (e.g. ‘TB482947T’).
• They can’t be a small variation on a dictionary word (e.g. ‘tomato12’).
It’s possible to change your configuration to add stricter rules, e.g. requiring passwords to
contain special characters - check out the section Configuring password complexity in the
Perimeta Operations and Maintenance Guide if you want to do that.

Start here
In this section you will learn how to:
• Add a new Craft/CLI user with a specific user level.

Task 1: Add the new user

1. Start up the CLI (using a super-user, like the default defcraft - remember, they’re the
only ones that can add other users!) and use these commands to get into the users
configuration mode.
config
system
users

Note: When we give you lists of CLI commands like this, we’ll indent them to show the mode
hierarchy. So when system is indented in the commands above, it shows that it’s a level
below the top-level config mode. You’ll see the same thing if you view configuration using
the show config command. You don’t need to indent the commands when you type them
in! Just type in the words, pressing Enter after each line.

2. Use this command to add the user:

user username
Replace username with the username for your new user.

Note: As well as adding the user, this command will take you to a mode that lets you change
settings for that user. You can also use this mode for existing users to change their password
and user level. Even non-super-users can use it to change their own password.

3. Use this command to set the user’s password:

password cleartext-value
The CLI will prompt you to enter the password. Type it in and press Enter. Remember to
make sure it matches the restrictions in Passwords on page 23.
4. Use this command to set the user level.
level userLevel
Replace userLevel with one of these: super-user, admin, support, or read-only.
Checkpoint: You have now created a new user.

24 CONFIDENTIAL
 Use the CLI stager
Use the CLI stager
What is the stager?
Once you have Perimeta in service, you’ll need to make any significant configuration changes
in maintenance windows. That’s a specified time when any interference with your service
or unexpected problems caused by your changes will have the least possible impact - which
usually means the middle of night!
Depending on how your organization works, it might be easier for you to prepare the details
of your configuration changes ahead of time, and then just have someone apply the prepared
changes during the maintenance window. That’s exactly what the CLI stager lets you do.
Turning on the stager moves various parts of CLI configuration into a special sub-mode.
Changes you make in that mode aren’t immediately applied. They only come into effect when
you run a special command to apply them. The stager also lets you immediately roll back the
changes you’ve applied if they cause any problems.

Warning! When the stager is turned on, it’s the only way to change the configuration it covers. You
should make a clear decision on whether or not you’ll use it, and either keep it turned on
or leave it off. Turning it on and off regularly can cause all sorts of confusion and workflow
problems.

Restrictions on the stager

There are some restrictions on the stager that you should bear in mind:
• The stager doesn’t cover the whole CLI. The parts it doesn’t include are listed below.
• To make configuration changes in the stager, you have to be logged in as a user with the
admin user level. Super-users can’t use the stager.

Note: If this user level stuff doesn’t make much sense to you, take a look at Add new Craft/CLI
users on page 23 for an explanation.

What isn’t included in the stager?

All commands in the stager are part of the config mode of the CLI (which is where all the
configuration options are - commands outside config are for triggering immediate actions), but
there are various areas it doesn’t include. If you have the stager turned on, these commands
stay in the normal CLI, and changes you make to them will happen straight away.

Note: You might wonder why the stager doesn’t include these areas of config. In most cases, it’s
because they’re things we’d expect you to set up when you first commission Perimeta. The
stager is designed for normal, in-service additions and changes to configuration, like adding a
new peer device.

If you’re reading this for the first time, you might not understand what some of these areas of
configuration are. Don’t worry. You can refer back to this list after you’ve worked through this
guide and learned more about Perimeta configuration.
• User configuration (usernames, user levels, passwords, and so on).
• Service interface configuration.
• Media address configuration.
• Security certificate configuration (for encryption).

CONFIDENTIAL 25
Use the CLI stager

• Lawful interception configuration.

• Delegate subscriber configuration.
• H.248 configuration (connections between MSCs and SSCs/ISCs).
• Connections to diagnostics clients (SNMP) and to the Metaswitch Service Assurance
Server.
• Diameter protocol configuration.
• The time offset from UTC (used if you have time-based routing).

Start here
In this section you will learn how to:
• Turn on the CLI stager.
• Access the stager and prepare a set of changes to apply later.
• Apply stored stager changes (and if necessary, roll them back).
You’ll need to log in as a Craft/CLI user with the admin user level to do this. If you don’t know
how to create one, have a look at Add new Craft/CLI users on page 23.

Task 1: Turn on the CLI stager

Warning! This will kick out anyone currently logged in to the CLI.
1. Start up the CLI and use these commands to turn on the stager.
actions
system
staging-configuration
enable
Follow the prompts to confirm that you want to use the stager.
If you later decide you want to deactivate the stager, just use the same commands, but change
enable to disable.

Warning! Deactivating the stager will remove any prepared changes that you haven’t yet applied!
Checkpoint: You have now turned on the CLI stager.

Task 2: Prepare configuration changes in the CLI stager

1. Start up the CLI and use these commands to check if there are any unapplied stager
changes already stored:
actions
system
staging-configuration
view-changes
This will show you any changes waiting to be applied. It’s always a good idea to check
these to see if they’ll conflict with the changes you’re going to make.

26 CONFIDENTIAL
 Use the CLI stager
Note: If there are stored changes that you want to get rid of, you can use discard-changes to
remove them. Be careful! Once they’re gone, they’re gone, and the only way to get them
back is to configure them all over again.

2. Type these commands to return to the root of the CLI and then to enter the stager.
end
staging-configuration
3. Make your configuration changes as you would in the config mode of the normal CLI.
4. When you’ve finished view the changes again using the commands from the first step in
this task (to run view-changes), and check that the changes are what you wanted.

Task 3: Apply stored changes from the CLI stager

1. Start up the CLI. Use these commands to check for any current warnings or alarms, so that
you can compare them after applying your changes.
show config warnings
show alarms
Make a note of any alarms or warnings. Obviously, if any of them seem serious you may
want to postpone your changes and investigate the problem!
2. Use these commands to apply your stored changes from the stager.
actions
system
staging-configuration
apply-changes
Follow the prompts. The CLI will ask whether you want to view the changes - make sure
you do! Check that they’re the changes you’re expecting to apply before you confirm them.

Note: Perimeta doesn’t apply the changes exactly as you entered them - instead it looks at
everything you’ve done, and makes config changes to achieve the same result with the
minimum amount of disruption to your system. The final configuration will always be the same
as what you’ve entered through the stager, though.

3. The CLI will tell you when it’s finished applying the changes. Once it is, use show config
warnings and show alarms again, and check that there aren’t any new warnings or
alarms.

Note: For substantial changes, it’s also a good idea to make some test calls if possible.
4. If there are serious problems and you want to roll back your changes, use these commands:
actions
system
staging-configuration
rollback
Follow the prompts to roll back your changes.
Checkpoint: You now know how to use the CLI stager.

CONFIDENTIAL 27
 Use the CLI stager

28
CONFIDENTIAL
 Configure Perimeta’s management network connection
Configure Perimeta’s management network connection
You can configure all the IP addresses and network details for Perimeta’s management network
connection in the Craft Terminal. You’ll first do this when you commission Perimeta - which
you’ll usually have to do through a direct console connection, since there won’t be an IP
address to connect to yet!

Note: For virtual systems you’ll connect to the console through your hypervisor. For a non-virtual
systems you’ll use a serial cable or Keyboard, Video, and Mouse (KVM), depending on your
hardware.

Information you’ll need

This is what you’ll need to configure every setting for the management connection. If it’s already
configured and you’re just changing something, you won’t need to know all of these.
• The virtual system management IP address. This is the main management address for
your whole Perimeta system; whichever Perimeta instance is currently the primary one will
always use this IP address.

Note: Perimeta systems are (usually) deployed in redundant pairs. One instance (usually each
instance is a separate physical blade or server) is always primary and currently handling
service, and the other is a backup that can immediately take over if something goes wrong.

• Individual management IP addresses for each of the two Perimeta instances. You’ll use
these if you need to access a particular instance regardless of which is primary.
• An extra two IP addresses for each instance, as probing IP addresses. Perimeta only uses
these for sending out connectivity tests (probes) to check the status of the management
connection.
• The subnet prefix length for your management network subnet; this is the length (in bits)
of the part of the management IP addresses that is common to all addresses in your
management network. For example, if your management network subnet is made up of
addresses beginning with 192.45, the prefix length is 16 (each of the four parts of an IPv4
address is 8 bits).
• The IP address of the default gateway for your management network.
• One to three probe target IP addresses. These are devices in your management network
that Perimeta can send its connection test probes too. This can be any device that will
reliably respond to IP pings (ICMP protocol messages), but here are some tips:
• If you use Metaswitch’s MetaView Server and Service Assurance Server products, you
can use their IP addresses as probe targets.
• NTP time servers can be useful targets.
• Don’t use the default gateway router. They give ICMP pings low priority, so they don’t
reply to them reliably.

Management probes - how they work

Perimeta uses the ICMP probes to check that its connection to the management network is
working. It sends them regularly to the targets you set. If three probes in a row on one of its
management connections fail, Perimeta will consider that connection to be dead until a probe
succeeds. If the connection that fails is the one the primary Perimeta instance is currently
using, it will switch to using the other connection - if both have failed, Perimeta will switch over
to the backup instance.

CONFIDENTIAL 29
Configure Perimeta’s management network connection

Start here
In this section you will learn how to:
• Configure the management network connection in the Craft Terminal.

Task 1: Set up the management IP addresses

1. Start up the Craft Terminal and choose these options:
• Admin
• Network
• Management
• Set IP
2. First, the Craft Terminal will ask you for the system management IP address and subnet
prefix length. You’ll need to type in the IP address followed by a / character, and then the
prefix length; for example, 192.45.54.1/16 if your system IP address was 192.45.54.1
and the prefix length was 16 bits.
3. You’ll now be prompted for each IP address in turn; type them in. If you’re leaving any of
them unchanged, you can just press Enter without typing anything in to skip them.
4. Once you’ve finished, the Terminal will show you all the settings you’ve chosen and ask you
to confirm, as shown below. If you’ve made a mistake, just choose Modify to go through
the settings again.

Checkpoint: You have configured the management connection for your Session Controller.

30 CONFIDENTIAL
 Configure Perimeta to use DNS
Configure Perimeta to use DNS
DNS is the Domain Name System, which allows the use of hostnames like example.com
instead of IP addresses. DNS servers store the details of which hostnames map to which IP
addresses.
If SIP devices using your service will use hostnames, you’ll need DNS servers in your
management network for Perimeta to connect to. Perimeta can use just one DNS server, but if
it fails you’ll be in trouble, so we strongly advise having multiple servers!

Note: If your network setup means you can’t have DNS servers in your management network, you
can configure DNS servers in each service network instead. We’ll talk about this later in the
chapter Add a service interface on page 43; this chapter covers the configuration of DNS
servers in the management network only.

Unless you’re living on the wild side with only one DNS server, you’ll need to choose how
Perimeta distributes each request between your servers. You’ve got two options:
1. Hunt - Perimeta always uses the first DNS server in the list, but if that stops working,
Perimeta will move on to the second (and so on). You should choose Hunt if your primary
DNS server is capable of handling all of Perimeta’s requests, without overloading.
2. Round robin - Perimeta sends each request to a different DNS server in the list (in the
order they’re configured). You should choose this if you want to spread the load across all
the DNS servers in your network.
To configure Perimeta to use DNS, you’ll need to know the IP addresses of the DNS servers.
You must ensure these addresses are reachable from your management network.

Start here
In this section you will learn how to:
• Configure Perimeta with DNS server IP addresses.
• Choose how Perimeta distributes requests between multiple servers.

Task 1: Configure the DNS server IP addresses

1. Start up the Craft Terminal and choose these options:
• Admin
• Network
• DNS
• Set DNS servers
2. Type in the DNS server IP addresses at the prompts, separated by spaces.
Checkpoint: You have now configured Perimeta to use DNS servers to resolve hostnames.

Task 2: Choose how Perimeta distributes requests across multiple servers

1. Start up the Craft Terminal and choose these options:
• Admin
• Network
• DNS
• Set selection mode

CONFIDENTIAL 31
Configure Perimeta to use DNS

2. Choose either ‘Hunt’ or ‘Round robin’ using the prompts.

Checkpoint: You have now chosen the method Perimeta uses to distribute requests to the
DNS servers.

32 CONFIDENTIAL
 Configure Perimeta to use NTP
Configure Perimeta to use NTP
NTP is the Network Time Protocol. NTP servers keep different network devices in sync and
make sure they know the correct time and date.
Using NTP servers is very important! In any live environment, you need to make sure Perimeta
has accurate time information, particularly for billing files, which, depending on the regions you
are operating in, may be legally required to have NTP-accurate timestamps.
Ideally, you should have two or more NTP servers available through Perimeta’s management
network, so that there are backups if Perimeta can’t connect to one of them. You’ll need to
know the IP addresses of each NTP server.

Start here
In this section you will learn how to:
• Configure Perimeta with NTP server IP addresses.
Perimeta should be stopped when you configure these settings. That shouldn’t be a problem,
since you’ll usually be configuring them when you first set it up. If you do need to stop it, there’s
a Craft Terminal option under Admin -> Start/Stop -> Stop.

Warning! Stopping Perimeta will completely interrupt your service. It is in actually possible to configure
the NTP settings without stopping Perimeta, but the procedure is rather more involved. See
the section Managing NTP Servers in the Perimeta Intial Setup Guide for full instructions if
you need to make these changes on a running system.

Task 1: Configure the NTP server IP addresses

1. Start up the Craft Terminal and choose these options:
• Admin
• System config
• Time
• Update NTP
• Set list of NTP servers
2. When prompted, type in all your NTP server IP addresses, separated by commas.
3. Back at the Time menu, choose List NTP and check the listed IP addresses are correct.
If not, repeat the update.
Checkpoint: You have now configured Perimeta with NTP server IP addresses.

Task 2: Check that the NTP connection is working

1. Still in the Time menu, choose the Query NTP option.
remote refid st t when poll reach delay offset jitter
================================================================
*127.127.1.1 .PB-A. 10 l 3 16 377 0.043 0.002 0.022
+127.127.1.4 .PB-A. 10 1 3 16 381 0.073 0.004 0.013

CONFIDENTIAL 33
Configure Perimeta to use NTP

The * indicates the currently active server, and other reachable servers are marked with
a +. The only column you’re worried about just now is offset, which shows you how
well-synchronized Perimeta is with the NTP server. The value should be as close to 0 as
possible, and it must stay within +/-128ms. If it’s above 100 or below -100, check again - if
it stays that way, you’ll need to do some troubleshooting:
2. Consult your network administrator to see if it could be caused by network problems on
your management network.
3. Try rebooting your Session Controller (the Craft Terminal option is under Admin -> Reboot).
4. If necessary, repeat the previous task and remove the problematic NTP server from your
list.
Once the NTP servers are successfully updated, you can start Perimeta again if you stopped it
to do these tasks; you’ll find the Craft option under Admin -> Start/Stop -> Start.
Checkpoint: You have now confirmed that your NTP configuration is working.

34 CONFIDENTIAL
 Apply your Perimeta license
Apply your Perimeta license
Perimeta systems must have a license to run. As well as allowing you to use Perimeta, your
license specifies whether you can use certain features and can also specify limits on things like
the number of calls you’re allowed to process through Perimeta.
Each license comes with a license key. This is a long string of text characters. You have to
apply the license key to your system, using the CLI, before you can use Perimeta for calls. If
your license changes later and you get a new license key, you can update your license key in
the same way.

License validation
After you enter the license key in the CLI, Perimeta has to validate the key before it considers
itself licensed (so you can’t just type a load of gibberish, or copy the key from your friend Dave’s
Perimeta).
There are two different mechanisms Perimeta can use to validate a license key: Distributed
Capacity Managers or USB security tokens. Which mechanism you use depends on your
deployment, but you use the same method on every Perimeta you have.

1. Distributed Capacity Managers

If your deployment includes Metaswitch Distributed Capacity Managers (DCMs), Perimeta
will contact one of these to validate its license key. You’ll have DCMs if you use virtualized
systems, or if your license has capacity limits that are shared across multiple Perimetas (rather
than each Perimeta having a licensed capacity of its own).
When setting up Perimeta for the first time, you’ll need to configure it with a connection to a set
of DCMs, referred to as a DCM group. Perimeta regularly contacts the DCM group for license
validation. If the connection to the DCM group fails, Perimeta will continue to operate for seven
days but you won’t be able to make any configuration changes in the CLI until the connection is
restored. You’ll receive alarms if this happens, so don’t worry about having to keep a constant
eye on the connection.

2. USB security tokens

If you don’t use DCMs in your deployment, your license key is validated using USB security
tokens. You need to insert the tokens into the USB ports of your Perimeta hardware; if the
tokens are missing, your license key won’t work and Perimeta won’t provide any service.
You’ll have security tokens for both your primary and backup instances of Perimeta. That
means that if the token in the primary fails (very unusual) or is accidentally removed, Perimeta
switches to the backup - the backup still counts as licensed so long as it has its own token -
and service can continue while you replace the token.
If a token does fail, you can replace it with the spare token provided with your system. Your
spare token isn’t tied to your license key; it’ll still work, but only for thirty days, which gives
you time to request and insert a replacement. This is to make sure all token replacements are
tracked.

Don’t panic
Licensing can get pretty complicated when you look at all of the options available, but you
don’t need to worry about most of it - you just need to know how it works for your system.
There’s not much you actually have to do either; in fact there are only three licensing tasks:
1. Apply a license key in the CLI.
2. Configure a connection to a DCM group in the Craft menu (if you’re using DCMs to validate
your license).

CONFIDENTIAL 35
Apply your Perimeta license

3. Watch out for any alarms to do with licensing and take the action they recommend.
...and we’re about to walk you through the first two!

Start here
In this section you will learn how to:
• Apply your Perimeta license key in the CLI.
• Configure Perimeta to connect to a DCM group.

Task 1: Apply your license key

This task applies to everyone, regardless of which licensing validation method you use.
If you use USB tokens for license validation, before you start make sure that your USB tokens
are inserted into USB ports of your Perimeta hardware.
1. Start up the CLI and use these commands to apply your license key:
actions
system
apply-license
When prompted, type or paste in your license key.

Note: The CLI will show you the details of your license when you apply the key. If you want to check
them later, just use the show license command.

Checkpoint: You have applied your Perimeta license key.

Task 2: Configure a connection to a DCM group

You only need to do this task if you are using DCMs in your network to validate licenses.
1. Start up the Craft terminal and select these options:
• Admin
• License Management
• Distributed Capacity Manager Group Configuration
• Join Distributed Capacity Manager Group
2. Select Processor-blade A or Processor-blade B depending on which Perimeta
blade you are using.
3. Follow the prompts to enter the IP address of one of the DCMs in your group (it doesn’t
matter which DCM you pick, and you can use the same one for both processor blades).
4. Repeat the above steps for the other processor blade.
Checkpoint: You have set up the connection from Perimeta to your DCM group.

36 CONFIDENTIAL
 Set up Perimeta billing
Set up Perimeta billing
Perimeta can store billing records of calls, in an XML format. If you’re not using your softswitch
to record billing information, you can set up Perimeta to record billing information and to upload
the records to a remote server.

Note: Perimeta also supports Rf charging, for providing call billing information in IMS networks.
We’re only going to cover the XML billing method here.

We call Perimeta’s billing records call detail records (CDRs). The individual XML files Perimeta
generates contain multiple CDRs. By default, Perimeta closes off an individual file every hour,
with all the CDRs for the last hour in that file.
The files Perimeta creates are compressed XML files (in gzip .tar.gz archive files) with a
timestamp in their filename; you can add a prefix or suffix to all the filenames if you want to
make the files easily identifiable. The filenames are similar to this (prefix and suffix are stand-ins
for any prefix/suffix you configure):
prefix XML_2012-07-20_06h15_16_UTC suffix
On Metaswitch Communities, you can download the Perimeta XML Billing SDK, which contains
resources to help you deal with the billing files produced by Perimeta. The SDK contains:
• Sample billing files
• A billing file scheme
• XSLT transforms for billing files.

Upload options
Perimeta supports two options for transferring billing files to your billing server:
1. Upload the files to your billing server using FTP or SFTP. This is known as FTP (or SFTP)
push.
2. Store the billing files locally, so that the billing server can log in using SFTP and transfer the
files itself. This is known as SFTP pull.

Start here
In this section you will learn how to:
• Turn on Perimeta billing.
• Configure the Perimeta to upload the files to a billing server, or make them available for
SFTP pull.

Task 1: Set up billing

1. Start up the CLI and type these commands to turn on billing:
config
sbc
signaling
billing
method xml
2. Type end and then exit to quit the CLI.
3. In the Craft Terminal (you’ll be in the main menu after quitting the CLI), choose these options:

CONFIDENTIAL 37
Set up Perimeta billing

• Admin
• Billing
• Modify upload configuration
4. Follow the prompts to fill in all the information required for FTP/SFTP push or SFTP pull.
You’ll need the following information to hand:
• If you’re using FTP (or SFTP) push:
• The IP address of the FTP billing server you want to upload the records to.
• The username and password Perimeta should use to access the billing server.
• If necessary, the directory on the billing server Perimeta should upload the records
to.
• If you’re using SFTP pull, the username of a Craft user account you want to use to
retrieve the billing files.
• If necessary, a prefix or suffix (or both) that Perimeta should add to the filenames of its
billing files.
• You can set up Perimeta to send email notifications when it uploads billing files or
when there’s an error with the upload. If you want to do this, you’ll need some extra
information:
• The IP address and port for your email server (this has to be reachable on the
management network).
• The email address to send the notifications to.
• The email address for Perimeta to send the notifications from.
Checkpoint: You have now set up Perimeta to make billing records and upload them to your
billing server.

Task 2: Make a test billing file transfer

1. Back in the billing menu, choose the Upload billing files now option.
2. If Perimeta has any problems during the upload, it will give you an error message. If it
does, repeat Task 1 and double-check your settings. It’s also worth checking that your
billing server is working and whether there are any current problems with your management
network.
3. If the upload is successful, connect to your billing server and check that the billing files are
present and in the correct directory.
You have confirmed that your billing configuration is working.

38 CONFIDENTIAL
 Understand the layers of Perimeta configuration
Understand the layers of Perimeta configuration
The Perimeta configuration model
Most of what Perimeta does centres around its connections to various networks; you’ve
already encountered the core, access, and management networks. Accordingly, Perimeta
configuration is centred around its interfaces to these networks. Perimeta needs interfaces
to each network at multiple layers (corresponding to the abstraction layers of the internet
protocol suite - if you’ve no idea what that means, bear with us), so there are multiple Perimeta
configuration objects that layer onto each other as shown below.

There’s a lot to understand here, but we’ll work through the objects one by one so that you
understand how the whole thing fits together.

Note: You might have noticed that the management network is missing. That’s because it typically
uses completely separate interfaces from the rest of your system, and is configured
separately; you don’t need to worry about it for the moment.

Layer-by-layer
Link layer: Port groups
As the name suggests, port groups group the Ethernet ports (or virtual ports, on virtual
systems) on your system and assign a name to the group. You can then use that name to
select the right set of Ethernet ports when you configure objects at the higher layers.

CONFIDENTIAL 39
Understand the layers of Perimeta configuration

A group can contain a single Ethernet port, or multiple ports to provide redundancy or
aggregation for higher bandwidth.

Internet layer: Service interfaces

Service interface objects define Perimeta’s connection to service networks; that is, the core
and access IP networks that carry signaling and media. Each one configures the connection
to a particular IP subnet. These objects sit underneath both signaling and media connections,
and include settings such as Perimeta’s local IP addresses (a single service interface can have
more than one local IP address), default gateways, and IP probing settings.

Did you know? Until recently, pretty much every IP network used four-part 'IPv4'
addresses like 1.2.3.4. However, there's a looming problem - the vast growth of the internet
means the stock of unused IPv4 addresses is in danger of running out! At some point we'll all
need to move to IPv6, which uses a new, longer, type of IP address - there are more possible
IPv6 addresses than there are stars in the observable universe. Perimeta supports both IPv4
and IPv6, of course.

Each service interface uses a specific port group for its link layer connection. You can only use
the same port group for more than one service interface if they use different VLANs (virtual local
area networks).

Note: VLANs use numbered ‘tags’ to separate traffic on the same physical network, with devices
treating Ethernet frames with different tags as if they were on different Ethernet networks.

Application and transport layer 1: Adjacencies

Perimeta uses separate configuration objects to handle signaling and media (remember, in
some cases these two types of traffic are handled by separate Session Controllers). The
objects that control Perimeta’s signaling interfaces are adjacencies.
An adjacency defines a point of contact for endpoints in a particular network; an IP address
and port for signaling traffic to flow to and from Perimeta. Each adjacency uses one service
interface, but you can have multiple adjacencies on the same service interface, using different
IP addresses or different ports on the same IP address.
Adjacencies will come up again and again as you learn to use Perimeta. Most signaling
configuration is controlled through or refers to adjacencies.

Note: Most adjacencies are used for SIP signaling, but Perimeta also provides some H.323
support, for which you can use dedicated H.323 adjacencies.

Application and transport layer 2: Media addresses

Media configuration is much simpler than signaling. All the details of the media streams in a call
are sorted out at the signaling level. Pretty much all you have to do is assign the IP addresses for
media, by configuring media addresses. These are the IP addresses you assign for sending
and receiving media on each service interface.

Note: On an ISC (which, you might remember, handles both signaling and media), media addresses
can be on the same service interfaces as adjacencies, and even be the same addresses
used by the adjacencies.

40 CONFIDENTIAL
 Understand port groups and view your port group scheme
Understand port groups and view your port group scheme
Perimeta’s service (signaling and media) interface connections use dedicated Ethernet
ports (there’ll be up to 8). To select these ports in Perimeta configuration, you’ll need to use
configuration objects called port groups.

Note: If you’re running Perimeta on virtual machines, these aren’t real Ethernet ports. Perimeta
thinks they are, but they’ll actually be virtual ports - your virtualization software will handle the
mapping between them and actual hardware ports, but that’s invisible to Perimeta.

The point of a port group is to select the ports for Perimeta’s service interface connection to a
particular network - when you configure these connections, you’ll have to choose a port group
for each one. The name ‘port group’ is a little misleading, since a port group sometimes only
has one port in it! But port groups can also provide a more complicated (but often useful) setup
There are two things port groups can add beyond just selecting an Ethernet port for your
service interface connections:
• Aggregation. A port group can include pairs of Ethernet ports that are aggregated -
they’re combined into a single connection, which Perimeta treats as if it was a single port
with double the bandwidth (usually 2 Gb/s instead of 1 Gb/s).
• Redundancy. Instead of a single connection, a port group can include two un-aggregated
ports, or two aggregated port pairs. This adds redundancy to your service connections,
because if a network interface can’t connect on one port (single or aggregated) in the
group, Perimeta can switch it over to the other one.

Note: If you don’t use port groups for redundancy, typically because you need more bandwidth and
can’t afford to leave ports as idle backups, you’re still protected against Ethernet connection
problems - Perimeta Session Controllers use a redundant pair of Perimeta instances, on
separate blades/servers/VMs, so Perimeta can respond by switching to its backup instance.
Port group redundancy just provides an extra level of redundancy (and switching ports is
lower-impact than a full switchover to the backup instance).

Port group schemes

How many port groups there are on your system, how many ports they contain and which
ports are aggregated are all determined by your port group scheme.
You’ll set the port group scheme when you first set up your system - it’s not something you can
chop and change for a working system! Which port group schemes are available will depend
on your Perimeta platform and how its ports are set up, so we can’t cover the specific schemes
here - but the Commissioning Guide for your platform provides all the necessary details for
when you’re setting up your system.
What we will give you is an example port group scheme to show you what they involve. This is
for the CH6010 platform, which has six Ethernet ports, RPG1 to RPG6.

Example port group scheme

Aggregated ports
• RPG1 and RPG2 are aggregated as bond0.
• RPG3 and RPG4 are aggregated as bond1.
Port groups
• There is a port group containing bond0 and bond1 as a redundant pair.
• There is a port group containing RPG5 and RPG6 as a redundant pair.

CONFIDENTIAL 41
Understand port groups and view your port group scheme

Start here
In this section you will learn how to:
• View the port group scheme on your system, including the names of the port groups and
which ports they include.

Task 1:
1. Start up the Craft Terminal and select these options:
• Admin
• Network
• Redundant Port Groups
• Get Redundant Port Group Scheme
You have now viewed your system’s port group scheme.

42 CONFIDENTIAL
 Add a service interface
Add a service interface
Service interfaces are crucial to your Perimeta configuration. They provide the IP-level network
connections needed for your higher-level signaling and media configuration. We’ll take you
through the key parts of a service interface, then show you how to set one up in the CLI.

Basic settings: ID, port group, and VLAN

These three basic settings create the identity of your service interface.
• The service network ID is a number that you assign to uniquely identify the network this
service interface connects to. If you have more than one Session Controller, they need to
use the same IDs for the same networks; so if the service interface to your core network on
your SSC uses ID 1, then the interfaces to your core network on each of your MSCs also
need to use ID 1.
• You assign each service interface to a port group, which specifies which ethernet ports
it uses. You’ll need to know the port group name; usually these are CoreNetwork and
AccessNetwork, but you might have chosen different ones when you set up your port
groups.
• The VLAN tag setting is only necessary if your service interface will use a VLAN (virtual
local area networks). This will depend on how your network is set up; it is required if you
want to have more than one service interface using the same port group. The VLAN tag is
a number and needs to match up to VLAN configuration on your Ethernet switches; consult
their documentation if you need to know how to set up a VLAN.

IP settings
Your service interfaces need the following settings giving the details of their IP subnet (or
subnets - you can configure the same service interface with both an IPv4 and IPv6 subnet).
• The local IP addresses for Perimeta. For each IP address, you’ll also need a unique
name, known as a service address name. You’ll use this to identify the IP address in
other areas of configuration.
• The subnet prefix length, in bits.
• The IP address of the default gateway for the subnet.

Probing
Perimeta monitors whether service interfaces are working properly by sending out probes
from each ethernet port used by the interface, to check the connection to the service network.
These are ARP packets on IPv4 subnets or NDP packets on IPv6 subnets. You’ll need to
configure some key settings for these probes.
• A probe target. This is the IP address Perimeta will send probes to, so it needs to be
a device that reliably answers ARP requests! The best choice (and the default) is almost
always the default gateway.
• A probe source style. This setting controls the IP address Perimeta will send probes
from. The best approach is to use four dedicated IP addresses in the subnet, only used for
Perimeta’s probes; this is called specific-source. If you don’t have enough IP addresses
available in the subnet to do this, you can use an all-zeroes IP address (such as 0.0.0.0 for
IPv4), or the subnet prefix followed by all zeroes, but you need to be sure that your routers
will support the setting you use - not every router will support these source addresses.
If you do use specific-source probing, you’ll need to configure the probe source IP
addresses for each port used by the service interface.

CONFIDENTIAL 43
Add a service interface

Trust level
Perimeta needs to know how much security to apply to your service interfaces. A service
interface to your core network, full of devices you control and with no access to the outside
world, doesn’t need the same level of protection as a service interface exposed to the whole
internet. You can choose between three levels of trust.
• Trusted interfaces should only be reachable by devices you control (or absolutely trust).
Devices using these interfaces do not have to register before Perimeta will accept their
traffic, and Perimeta won’t apply dynamic blacklisting to them, which is its main method of
protection against attacks.
• Untrusted interfaces should almost always be what you use on any access side connection.
Perimeta will apply its full range of security features, and devices will have to register before
Perimeta will accept their traffic, unless you explicitly permit their IP address in advance.
• Untrusted-priority interfaces are a special case; Perimeta accepts traffic from devices
that haven’t registered or been pre-configured, but still applies dynamic blacklisting to
them. This might occasionally be necessary when connecting to networks with devices
that do not register, if you do not know what IP addresses they will use - but it is less secure
than untrusted.

Warning! Do not use untrusted-priority unless you are absolutely sure you need to, and never use it on
networks that are not protected against IP spoofing.

Criticality
If a service interface connection goes down, due to port problems, network issues, and so on,
Perimeta has two possible options to keep the interface working. If your port groups provide
redundant pairs of Ethernet ports, and the other Ethernet port in the pair still has a connection,
Perimeta can just switch over to using that. Additionally, a Perimeta Session Controller is
usually set up as a high-availability (HA) redundant pair, meaning that the primary instance of
Perimeta constantly saves information about configuration and call states to a backup, which
can take over at any time if the primary fails - if there are no redundant pairs of ports, or if both
ports in a pair lose connection, Perimeta can switch to the backup to keep up its connection
to the service interface.

Note: What a Perimeta instance is depends on your deployment platform - it’ll be an individual
processor-blade within the chassis on CH6010 hardware, an individual server on COTS
hardware, or an individual virtual machine in a virtualized deployment.

However, in some particularly disastrous situations, there might be some service interface
connections that are down on the current primary instance, and some that are down on the
backup instance. To know whether to switch over, Perimeta needs to know how important
each service interface is to your deployment. That’s what the criticality setting is for.
Criticality is a number between 0 and 1000, and Perimeta continually adds up the criticality of
all the live interfaces on the primary and backup instances; if it becomes higher on the backup,
Perimeta will switch over (called a software protection switch or SPS).
The best way to come up with criticality numbers for your service interfaces is to decide how
proportionally important they are for your deployment. If you have a single core interface to
your softswitch that is necessary for all calls, set it to 1000 - and make sure the total of your
other interfaces doesn’t add up to more than 1000! Here’s an example to make it a bit clearer:
• You have one core interface and give it a value of 1000.
• You have three access interfaces. One handles 40% of your calls, and the other two handle
30% each, so you give the first one criticality of 400, and the other two 300 each.

44 CONFIDENTIAL
 Add a service interface
The result is that Perimeta will prioritize maintaining a connection to the 40% network over
either one of the 30% networks, but not both (since they would have a total criticality of 600).
And crucially, it would never prioritize any combination of the access interfaces over your
essential core interface.

DNS
Back in Configure Perimeta to use DNS on page 31, we said that if you’re unable to have DNS
servers in your management network, you can configure DNS servers on each service interface.
You can also choose to configure DNS servers on a service interface if you want that service
interface to use different DNS servers to the DNS servers configured on the management
network.
As with DNS servers in the management network, when you configure more than one you also
have to choose how Perimeta distributes requests between the servers, from the following
options:
1. Hunt - Perimeta always uses the first DNS server in the list, but if that stops working,
Perimeta will move on to the second (and so on). You should choose Hunt if your primary
DNS server is capable of handling all of Perimeta’s requests, without overloading.
2. Round Robin - Perimeta sends each request to a different DNS server based on the order
you have configured in a list. You should choose Round Robin if you want to spread the
load across all the DNS servers in your network.

Start here
In this section you will learn how to:
• Create a service interface.
• Configure the service interface’s IP settings, trust, criticality and DNS servers.
You’ll need to get into the CLI to do all this. It’s easy to find - log in to the Craft Terminal and it’s
right there in the very first menu. If you can’t remember how to access Craft, re-read Use the
Craft Terminal on page 17 to refresh your memory.

Task 1: Create the service interface

1. Start up the CLI and type the following commands to get you into the correct mode for
creating a service interface.
config
system
2. To create the service interface, you’ll use the following command.
service-interface servN
When text in commands appears like this, it means you’re going to have to replace that part
of the command with something. In this case, you replace the N with a number to identify the
service interface. It’s usually easiest to use the same number as the service-network ID. So, if
we start with service interface number one, the command is:
service-interface serv1
As well as creating the service interface, this command takes you to the CLI mode you’ll use
to configure it. If you ever want to change the settings for a service interface, you can get back
to it using the same commands you used here.
Checkpoint: You have now created a service interface.

CONFIDENTIAL 45
Add a service interface

Task 2: Configure the basic settings

Starting point: You’ll need to be in the service interface mode, as at the end of Task 1. Here’s
a reminder of the commands you need to get there.
config
system
service-interface servN
1. Use this command to set the service-network ID:
service-network ID
Replace ID with the service network ID number.
2. Use this command to set the port group.
port-group-name portGroupName
Replace portGroupName with the name of the port group for your service interface.
3. If you are using VLANs and need to set a VLAN tag for your service interface, use this
command:
vlan-id VLANTag
Replace VLANTag with the ID tag of the VLAN you want to use.
Checkpoint: You have now configured the basic settings for your service interface.

Task 3: Configure the IP subnet

Starting point: You’ll need to be in the service interface mode, as at the end of Task 1. Here’s
a reminder of the commands you need to get there.
config
system
service-interface servN
1. The IP settings are in their own sub-modes beneath the service-interface mode. To
access them, type one of these commands:
ipv4
or, for an IPv6 subnet
ipv6
2. Use this command to set the default gateway IP address:
gateway-ip-address gatewayAddress
Replace gatewayAddress with the IP address of the default gateway.
3. Use this command to set the subnet prefix length.
subnet-prefix-length prefixLength
Replace prefixLength with the subnet prefix length in bits (not as a subnet mask).
4. Use these commands to configure each local IP address and its service address name.
local-ip-address address
service-address addressName

46 CONFIDENTIAL
 Add a service interface
Replace address with the local IP address and addressName with the service address name.
Repeat for each local IP address your Session Controller will use on this subnet.
There may be some rare circumstances when you need to configure a local IP address
that is not part of the subnet. This is perfectly possible, and such addresses are known as
off-lan IP addresses. They’re configured in the same way, except the config has an extra
attribute:
local-ip-address address off-lan
service-address addressName
5. If you want to send probes to a target other than the default gateway (if you’re not sure, just
leave this setting as the default), use this command:
probes-target probeTarget
Replace probeTarget with the probe target IP address.
6. Choose the probe source style using one of these commands:
• If you want to use the (recommended) specific-source style with dedicated probe
source IP addresses:
probes-source-style specific-source
• If you want to use the all-zeroes source IP address for all probes:
probes-source-style all-zero
• If you want to use the subnet prefix followed by all zeroes as the source IP address for
all probes:
probes-source-style subnet-all-zero
7. If you’re using the specific-source style, set the source IP addresses for the probes using
these commands:
probes-source-ip shelf A interface 1 address1
probes-source-ip shelf A interface 2 address2
probes-source-ip shelf B interface 1 address3
probes-source-ip shelf B interface 2 address4
Replace address1, address2, etc. with your probe source IP addresses.
Checkpoint: You have now configured the IP settings for the service interface.

Task 4: Configure the remaining settings

Starting point: You’ll need to be in the service interface mode, as at the end of Task 1. Here’s
a reminder of the commands you need to get there.
config
system
service-interface servN
1. Set the trust level for this service interface using one of these commands:
network-security trusted
or
network-security untrusted
or

CONFIDENTIAL 47
Add a service interface

network-security untrusted-priority
2. Set the criticality value for this service interface using this command:
criticality critValue
Replace critValue with the criticality value for the interface.
3. If your service interface uses IPv6 rather than IPv4, you’ll need to change the probing
protocol using this command:
probes-type ipv6
4. If you need to configure DNS servers on this service interface:
• Use this command to specify the list of servers:
dns-servers serverList
where serverList is a space separated list of the IPv4 or IPv6 addresses of the DNS
servers (up to a maximum of 16 entries). For example:
dns-servers 10.1.1.1 10.1.1.2 10.1.1.3
• Use this command to choose the method used to distribute requests to the list of
servers:
dns-selection-mode method
where method is either hunt or round-robin, depending on what you’ve chosen to
use.
Checkpoint: You have now fully configured your service interface.

48 CONFIDENTIAL
 Set up Perimeta’s media interfaces
Set up Perimeta’s media interfaces
Media addresses
Compared to most areas of Perimeta configuration, setting up your media interfaces is relatively
simple; you don’t need to do much more than assign the IP addresses your Session Controller
(that’s an ISC or MSC for media, remember) will use for media.

Note: These addresses have to be local addresses configured on your service interfaces.
Media realms
If you’re using distributed signaling and media, Perimeta needs to know which media addresses
on your MSCs other devices can actually reach. To provide this information, you use a setting
called the media realm.
A media realm is just a name (such as internet) that you assign to Perimeta IP addresses
to show that phones or other devices that can contact one address can contact any other
address in the realm. You set a realm for each MSC media address, and for each of their
equivalents on the signaling side - SSC/ISC adjacencies (which we’ll be getting to shortly).
When Perimeta needs to set up the media for one side of a call, it can tell which MSC media
addresses it can use by checking for media realms that match the setting on the adjacency;
remember, if the phone can reach the adjacency address, it must be able to reach any media
address in the same realm.

Note: You don’t need to use realms if the adjacency (the signaling address) and all the media
addresses you want to use with it are on the same ISC (they can even be the same address),
so long as they’re on the same service interface - but you always need to use realms for
MSC media addresses.

If you’re using MSCs for your media, the key things you need to make sure of are:
• For every IP address your deployment uses for signaling, you must assign a realm, and
your deployment must have at least one media address in the same realm. If you have
more than one signaling address in the same realm (i.e. they’re both on the same network,
or mutually reachable through connections to the internet or similar) you don’t need a
separate media address for each - there just has to be at least one for each realm. You
don’t need an address in every realm on every MSC, but there has to be a media address
somewhere for each realm.

Note: You don’t need an address in each realm on every MSC, but if an MSC doesn’t have an
address in a particular realm, it can’t be used for any calls involving a signaling address in that
realm.

• Every IP address in the same realm must be reachable from every other IP address in the
realm. If you’re not sure which addresses are mutually reachable, check with your network
administrator.

Start here
In this section you will learn how to:
• Configure a media address on your ISC or MSC.
You’ll need to know:
• The local IP address you’re going to assign as a media address. You must already have a
service interface with this IP address configured on it.

CONFIDENTIAL 49
Set up Perimeta’s media interfaces

• The service network ID number of the service interface.

Task 1: Configure a media address

1. Start up the CLI and type the following commands to get you into the correct mode for
configuring a media address.
config
sbc
media
2. Use this command to configure your media address:
media-address ipv4 address service-network SNID
Replace address with the IP address and SNID with the service network ID (if you’re using
IPv6, change ipv4 to ipv6 as well).
3. If you’re using an MSC, use this command to set the media realm for your address:
realm realmName
Replace realmName with the media realm you want to use for this media address.
Checkpoint: You have now configured a media address.

50 CONFIDENTIAL
 Configure a basic adjacency
Configure a basic adjacency
What is an adjacency?
Adjacencies are Perimeta’s interfaces for signaling traffic (usually SIP, but you can also create
H.323 adjacencies for some limited H.323 support). Basically, this means that an adjacency
is an IP address and port on one of your service interfaces that Perimeta will use to send and
receive signaling traffic.
However, the adjacency configuration object includes a lot more settings than just an IP and
port. Most of Perimeta’s signaling configuration works through adjacencies, and you’ll set up
things like traffic limits, interoperability settings, and media policies (such as transcoding) using
adjacencies. You’ll be seeing a lot of these.
Since so many key settings depend on adjacencies, you’ll typically want separate adjacencies
for connections to things like:
• Your softswitch.
• Individual SIP peers (SIP trunks or PBXs).
• Sets of SIP phones that use the same settings (you can use different adjacencies for phones
of different models if they need different interoperability settings).

Warning! All incoming traffic must be sent to a configured adjacency. If traffic arrives that doesn’t
match an adjacency, Perimeta will just drop it. This is one of the ways Perimeta keeps your
network secure.

How Perimeta decides which adjacency incoming traffic is for

This is how Perimeta matches incoming traffic to an adjacency.
• The service interface the traffic arrives on must be the one the adjacency is on. Remember,
which service interface traffic is on is determined by which physical port it arrives on, and
which VLAN it is on (if you are using VLANs).
• The destination IP address and port for the traffic must be the adjacency IP address and
port.
• You can choose to configure an adjacency to allow only UDP or only TCP traffic; if you have
used this setting, the incoming traffic must use the correct protocol to match the adjacency.

Note: UDP and TCP are underlying transport protocols for IP traffic. SIP supports both.
• You can choose to configure a set range of permitted remote IP addresses for an
adjacency. If you do, incoming traffic must come from an IP address in that range to match
the adjacency. Typically you’ll use this to limit an adjacency to one specific remote device,
such as your softswitch or the other end of a SIP trunk.

Basic settings
These basic settings are key to every adjacency.
• An adjacency name. You’ll need to refer to your adjacency in various other areas of
configuration, so make sure your adjacency names clearly indicate what the adjacency is
for. The maximum name length is 32 characters.
• The local IP address, identified by its service address name, not the address itself. The
service address name is the name you assigned when you configured the local address on
the service interface.

CONFIDENTIAL 51
Configure a basic adjacency

• The signaling peer IP address (or hostname) and port. For adjacencies that connect
to a single remote device (softswitch, the other end of a SIP trunk, etc.), that device is
the signaling peer. Adjacencies that connect to lots of devices, such as open access
adjacencies for SIP phones, do not have a signaling peer and you can set this to 0.0.0.0.
• The adjacency type. This setting tells Perimeta what kind of connection this adjacency is
for, and affects how Perimeta routes signaling and deals with SIP registrations. There are
three basic types:
• Core adjacencies connect to devices in your core network (in particular, the device that
acts as a SIP registrar, typically your softswitch).
• Access adjacencies are open to connections from registering SIP endpoints (typically
SIP phones).
• Peering adjacencies are used for SIP trunks (the connection to another service
provider’s network) and SIP PBX peers.

Note: There are other adjacency types - one for SIP recording (SIPREC) servers, and a few for IMS
networks - but if you’re not using SIPREC or IMS, you can just ignore them!

• The remote address rangesets a limited range of addresses that are allowed to contact
this adjacency; this is optional and you can choose to have an adjacency open to any
remote address. You specify the range as an IP subnet, using an address and prefix length.
For example, 192.168.0.0 and prefix length of 16 bits (each of the four parts of an IPv4
address is 8 bits) would allow any remote address beginning 192.168.

Note: If your adjacency has a signaling peer, you’ll usually want to set the remote address range to
the signaling peer address (with the prefix length at the full address length - 32 for IPv4, 128
for IPv6) to limit connections to the signaling peer only.

Traffic forcing
There’s an additional option associated with the signaling peer that’s important to how
adjacencies work. If there is a signaling peer, you can choose to force traffic to it, rather than
routing the traffic based on its SIP headers. Although it’s technically possible to turn this off, it’s
almost always correct to turn it on unless you have some specific reason not to; the point of
having an adjacency to a specific device is so that you can send traffic to that device!

Start here
In this section you will learn how to:
• Create an adjacency object.
• Configure its basic settings.

Warning! This isn’t everything there is to adjacencies! We’ll take you through the basic settings you
need to create a working adjacency, but there are many other settings and options available.
We’ll come back to the commonly used ones in other parts of this guide.

Task 1: Create the adjacency

1. Start up the CLI and type the following commands to get into the signaling mode, which is
where you’ll find all Perimeta’s signaling-specific configuration, including adjacencies.
config
sbc
signaling

52 CONFIDENTIAL
 Configure a basic adjacency
2. To create the adjacency, use this command:
adjacency sip name
Replace name with the name you’ve picked for your adjacency.
As well as creating the adjacency, this command takes you to the CLI mode you’ll use to
configure it. If you ever want to change the settings for your adjacency, you can get back
to it using the same commands you used here.
Checkpoint:You have now created an adjacency.

Task 2: Configure the basic adjacency settings

Starting point: You’ll need to be in the adjacency mode, as at the end of Task 1. Here’s a
reminder of the commands you need to get there.
config
sbc
signaling
adjacency sip name
1. Use this command to select the local IP address, using the service address name:
service-address addressName
Replace addressName with the service address name.

Note: Remember, this is the name configured for the local IP address on the service interface
object. If you don’t know it, you can type show config to see all your configuration and look
for the service-interface commands to find the service interface objects. Then look for
the service-address commands indented beneath them to see which IP addresses have
which names.

2. If you’re using a local port other than 5060, use this command to select it:
signaling-local-port portNumber
Replace portNumber with the local port you want to use.
3. Use this command to configure the signaling peer:
signaling-peer peerAddress
If this adjacency will have an actual signaling peer device, replace peerAddress with the peer
IP address or hostname. If this is an open adjacency, replace it with 0.0.0.0 instead.
4. If the signaling peer uses a port other than 5060 for SIP, use this command to configure it:
signaling-peer-port portNumber
Replace portNumber with the port the signaling peer uses. If this is an open adjacency with
the signaling peer set to 0.0.0.0, set this to 0.
5. If this adjacency has a signaling peer, use this command to turn on traffic forcing:
force-signaling-peer all-requests
6. Use this command to set the adjacency type:
adjacency-type typeSetting
Replace typeSetting with one of preset-core, preset-access, or preset-peering,
depending on the appropriate adjacency type.

CONFIDENTIAL 53
Configure a basic adjacency

7. If you want to limit connections to this adjacency to a limited remote address range, use
this command:
remote-address-range ipv4 subnetAddress prefix-len prefixLength
Replace subnetAddress with the subnet IP address defining the subnet you want to permit
connections from (if you want to limit connections to a single IP address, this is the full
address).
You have now created an adjacency.

54 CONFIDENTIAL
 Configure and apply an adjacency interoperability profile
Configure and apply an adjacency interoperability profile
What is an interoperability profile?
Depending on how your system is set up, you might well have a lot of different adjacencies. For
example, you might connect to a lot of different SIP trunks.
The point of adjacency interoperability profiles (interop profiles for short) is to let you
configure certain settings for multiple adjacencies at once. Often you’ll have different adjacencies
that connect to the same types of devices and use the same interop settings. Setting up an
interop profile means you can configure those settings in one place, and have it apply to all the
adjacencies that use that profile.
Profiles are completely optional, and all the settings in them are available directly on adjacencies
in an interop sub-mode.
We won’t list all the different settings that you can configure in interop profiles here - there are
a lot, and most of them are quite involved; you’ll likely never use lots of them. What we will do
is show you how to create and apply profiles - then, when we cover individual settings that you
can use profiles for, we’ll point it out.

What happens if you have both adjacency settings and a profile applied?
If you’ve explicitly configured a setting in the interop mode of an adjacency and it conflicts
with the adjacency’s current interop profile, the setting on the adjacency wins out, but any
other settings from the profile still apply. That means you can override part of a profile for an
adjacency while still using the rest of the settings.
To make it easier to see what’s going on, you can view the settings Perimeta is actually applying
for any adjacency. Just use these commands, replacing adjacencyName with the name of your
adjacency:
config
sbc
signaling
adjacency sip adjacencyName
interop
show config here defaults-included
This will show you the current interop settings for the adjacency; any that are coming from
an interop profile instead of actually being configured in the interop mode will be marked
Effective value.

Start here
In this section you will learn how to:
• Create an adjacency interoperability profile.
• Apply the profile to an adjacency.

Task 1: Create an adjacency interoperability profile

1. Start up the CLI and use these commands.
config
sbc

CONFIDENTIAL 55
Configure and apply an adjacency interoperability profile

signaling
sip interop-profile name
Replace name with a name for the interop profile.
2. Type in any settings for the interop profile.
Here’s an example of a profile - don’t worry too much about what the settings do for the
moment.
sip interop-profile example
dynamic-peer-routing
preferred-transport udp
registration rewrite-register
Checkpoint: You have created an adjacency interoperability profile.

Task 2: Apply your profile to an adjacency

1. Start up the CLI (if you’re still in the interop profile mode, type end to jump back to the top
level) and type these commands to apply your profile to one of your adjacencies.
config
sbc
signaling
adjacency sip adjacencyName
default-interop-profile profileName
Replace adjacencyName with the name of the adjacency, and profileName with the name
of your interop profile.
You have now applied your interop profile.

56 CONFIDENTIAL
 Create an account
Create an account
An account is just a group of adjacencies, usually representing a set of adjacencies that are all
different connections to the same customer. They do a few different things:
• You can set capacity control limits (limits on call/subscriber numbers, bandwidth, etc.) on
accounts.
• You can configure most ‘call media policy’ settings for an account. These settings cover
things like media codec selection, permitting encoded media (SRTP), and various other
media-related policies. Setting them on an account is just a shortcut to setting them on the
adjacencies in that account.
• You can route SIP messages based on which account a message comes from.
You can do all of these things using individual adjacencies - accounts are entirely optional, but
they can be a handy way to deal with multiple adjacencies at once.

Start here
In this section you will learn how to:
• Create an account.
• Add an existing adjacency to your account.

Task 1: Create your account

1. Start up the CLI and use these commands to create the account:
config
sbc
signaling
account name
Replace name with a name for the account.

Note: As well as creating the account, these commands take you to the CLI mode you’ll need to
set limits, policy, etc. for the account. Use the same commands when you need to access
the account again in future.

Checkpoint: You have now created an account.

Task 2: Add an adjacency to your account

1. Start up the CLI and use these commands to add an adjacency to your account:
config
sbc
signaling
adjacency sip adjacencyName
account accountName
Replace adjacencyName with the name of the adjacency and accountName with the name
of the account.

CONFIDENTIAL 57
 Create an account

58
CONFIDENTIAL
 Understand how Perimeta handles SIP registrations
Understand how Perimeta handles SIP registrations
What is a SIP registration?
When one of your customers uses a SIP phone or softphone, it has to register with your
softswitch first. Registering means sending a message to a ‘registrar’ (this is usually just your
softswitch) to say ‘this subscriber (identified by their phone number, or sometimes a username)
is using this device, and can be reached at this IP address/domain name’. The registrar stores
a record, lasting for a set period of time, that associates the contact details with the subscriber.
When someone else tries to call the subscriber, they do it via the registrar, which has a record
of the subscriber’s current location (the IP address they registered) and can set up the call.
A successful basic registration comes down to just two SIP messages:
• A REGISTER request from the phone. This tells the registrar which subscriber is registering,
and the IP address or domain name it can reach them at.
• An OK response from the registrar. If the registration fails for some reason, this’ll be an error
message instead.

How does Perimeta fit in?

To protect your registrar, Perimeta needs to be in the path for all signaling traffic between the
registrar and external devices. That means all registrations have to go through Perimeta - the
process works like this:
1. You’ll have at least two adjacencies configured on Perimeta - an access adjacency for
the registering phones to use, and a core adjacency for the connection to your registrar.
You might need more access adjacencies if you’ll have phones registering from different
external networks, and/or more core adjacencies if you have more than one registrar.
2. You’ll configure your phones to send their registration requests to their Perimeta access
adjacency. You’ll usually do this by setting the access adjacency IP address (or domain
name) as the outbound proxy for registrations on the phones, while still configuring the
registrar’s details as normal.
3. Your Perimeta routing configuration will route registrations that arrive on the access
adjacency to the core adjacency.
4. Perimeta will rewrite the Contact header of REGISTER requests before sending them on
to the registrar. This is the part of the REGISTER request that tells the registrar where
to send messages intended for the registering subscriber. It’s a SIP URI, so it’s in the
<sip:username@domain> form.
Perimeta changes:
• the domain part to an IP or domain name for the Perimeta core adjacency, so that the
registrar sends messages for the subscriber to Perimeta
• the username part to a unique identifier, so that Perimeta can identify which SIP device
each message is intended for.
The result is to rewrite something like this (not a full header - there’ll usually be various
parameters as well):
Contact: <sip:[email protected]>
to something like this:
Contact: <sip:[email protected]>

CONFIDENTIAL 59
Understand how Perimeta handles SIP registrations

Note: Perimeta will also rewrite the domain part of Via headers in a similar way, and make various
other changes so that the exchange with the registrar is a separate SIP dialog from the
exchange with the phone.

The subscriber database

Perimeta stores the details of registrations in its own subscriber database, for a few reasons:
• Perimeta’s security features require external devices to register before they can send other
traffic to your core network (unless you’ve configured an exception for the specific device),
so it needs to track which devices are registered.
• Perimeta records the source adjacency of each registration and the unique identifier it
added to the Contact header, allowing it to effectively route incoming calls to the registered
subscriber.
• The database allows Perimeta to monitor the number of registrations active on the system
and on specific adjacencies, so that you can access this information through diagnostics
and place limits on it if necessary.

Registration monitoring
If you turn on registration monitoring on the adjacency facing the registrar, Perimeta will ask
the registrar to keep it updated on the status of each registration. If the registration changes for
a reason that Perimeta isn’t aware of - for example, if the subscriber registers from a different
phone through a different SBC - this setting makes sure that Perimeta can update its database
appropriately.
This feature is useful, but it does require that your registrar supports SIP SUBSCRIBE requests
for the status of registrations. Check your registrar’s documentation to see if it does.

Phones that don’t support an outbound proxy: REGISTER rewriting

With phones that don’t allow you to set an outbound proxy for registrations, the situation
becomes a bit more complicated. You’ll need to configure your phones with their Perimeta
access adjacency as the registrar instead of as the proxy. This means that various headers in
the REGISTER requests (To, From, and the Request-URI at the start of the message) will be
wrong; they’ll include the address/domain of the Perimeta core adjacency when they should
be using the address/domain of the registrar.
Perimeta’s REGISTER rewriting feature fixes this by rewriting the headers, but you’ll need to
turn it on with a setting on the access adjacency (you can set this for multiple adjacencies
using an interop profile). You’ll also need to set the registrar domain name or IP address that
Perimeta should write into the REGISTER headers - you’ll set this on your core, registrar-facing
adjacencies.

Start here
In this section you will learn how to:
• Enable registration monitoring on the adjacency facing your registrar. Only do this if your
registrar supports SIP SUBSCRIBE for updates on subscriber registrations.
• Set up REGISTER rewriting for a system with phones that don’t support outbound proxy
configuration.

Task 1: Enable registration monitoring

1. Start up the CLI and use these commands:
config

60 CONFIDENTIAL
 Understand how Perimeta handles SIP registrations
sbc
signaling
adjacency sip name
registration monitor
Replace name with the name of the adjacency facing your registrar.

Task 2: Set up REGISTER rewriting

Note: You can enable REGISTER rewriting on access adjacencies using direct configuration on
each adjacency, or by using an interoperability profile that applies to multiple adjacencies.
You only need to do one of the two. If you need to refresh your memory about how to set
up and apply interoperability profiles, take a look back at Configure and apply an adjacency
interoperability profile on page 55.

Access adjacencies - Using an interoperability profile

1. Start up the CLI and use these commands to configure REGISTER rewriting on the interop
profile:
config
sbc
signaling
sip interop-profile name
registration rewrite-register
Replace name with the name of the interop profile.
Access adjacencies - Using direct adjacency configuration
Follow these steps for each access adjacency used by phones that don’t support outbound
proxy configuration.
1. Start up the CLI and select the adjacency using these commands:
config
sbc
signaling
adjacency sip name
interop
registration rewrite-register

Replace name with the name of the access adjacency.

Core adjacency (facing the registrar)
Follow these steps for the core adjacency facing your registrar; this will set the registrar
IP address or domain name that Perimeta should write into the headers of the REGISTER
messages. This setting won’t trigger rewriting on its own - it just tells Perimeta what to do if
rewriting was already triggered on the access side.

Note: If you have more than one registrar, just repeat these steps for the adjacency to each of
them.

CONFIDENTIAL 61
Understand how Perimeta handles SIP registrations

1. Use these commands to set the IP address/domain name for rewriting REGISTERs.
config
sbc
signaling
adjacency sip name
registration target address address
Replace address with the registrar IP address or domain name Perimeta should write into
the headers of REGISTERs (it’ll only do this when they come from an access adjacency
with the registration rewrite-register setting).
Checkpoint: You have now set up REGISTER rewriting.

62 CONFIDENTIAL
 Configure capacity control limits on an adjacency
Configure capacity control limits on an adjacency
What is capacity control?
Capacity control is a Perimeta feature that lets you place limits on the traffic that goes through
Perimeta. You’ll usually want to do this for one of two reasons:
• To protect your core devices from sudden spikes in traffic - if, say, a popular TV phone-in
suddenly floods your network with calls.
• To control the traffic levels you allow for your customers or peer organizations based on
your contracts (service-level agreements or SLAs) with them.
You’ll configure your capacity control limits for individual adjacencies (or accounts - an account
is a group of adjacencies with some shared limits and policies). Limits can apply to the
adjacency in three different ways:
• Adjacency limits apply to the whole adjacency. For example, you can set a limit on the
total number of concurrent subscribers allowed on the adjacency, or the total number of
concurrent calls on the adjacency.
• Source IP address limits apply to each individual source IP address on an adjacency.
For example, you can set a limit on the total number of concurrent calls allowed from each
IP address. You can only configure source IP address limits on an adjacency, not on an
account.
• Calling number limits apply to each individual calling number using the adjacency. These
are exactly the same limits as the adjacency limits - they just apply at a different scope.
So you can apply a limit to the total number of calls that any one calling number can be
making at one time - obviously that would be a lot smaller than the limit on calls for the
entire adjacency!

Note: You don’t configure limits for a specific calling number. When you configure a calling number
limit, it will apply separately to each and every calling number that appears on the adjacency.

Warning! Don’t use calling number limits on your SIP trunk adjacencies! The variety of calling numbers
Perimeta has to try and track if you do this can cause memory problems.

• Call limits apply to each individual call going through the adjacency. These are a different
set of limits to the adjacency and calling number limits. For example, you can set a limit on
the duration of calls or the number of media streams per call.
If a limit is reached, Perimeta will reject some traffic to make sure it stays within the limit. For
example, if an adjacency reaches its limit on concurrent calls, Perimeta won’t allow any new
calls to be set up on that adjacency until some existing calls end.
You can configure Perimeta to raise an alarm when the level of traffic reaches a certain percentage
of the capacity control limit. This lets you alert administrators when traffic is beginning to rise to
unacceptable levels, and when the limits are breached.

Note: Emergency calls are an exception to all capacity control limits.

Rate and gauge limits

Adjacency and calling number limits are either rate limits or gauge limits. A gauge limit just
checks whether some counter - say, the number of current calls on the adjacency - is over the
limit. Rate limits, as the name suggests, monitor the rate of some kind of event instead, such
as the rate at which new calls are being set up.

CONFIDENTIAL 63
Configure capacity control limits on an adjacency

You can specify rate limits as per-second or per-minute rates. They’re measured in the same
way - setting some limit at 60 per-minute is the same as setting it at 1 per-second.
Each rate limit actually splits into two different limits - the burst rate limit and the sustain rate
limit. The burst rate limit is higher, but checked over a much shorter period; by default, Perimeta
measures the rates for sustain rate limits over the last 60 seconds, and burst rate limits over
the last 6 seconds.
This means that a small spike in traffic that goes over one of your sustain rate limits won’t trigger
Perimeta to start rejecting any traffic unless the increase is sustained over time, which keeps
your service consistent in the face of random variation in traffic rates. However, if the short-term
spike is large enough, it will trigger the burst rate limit and Perimeta will react immediately to
prevent network overload.
You can configure burst rate limits manually, but unless you have very specific requirements
about traffic levels, it’s usually best to just set sustain rate limits - Perimeta will calculate a burst
rate limit automatically.

Directional limits
You can configure any of the adjacency limits as a directional limit. That’s a limit that only
applies to calls or registrations going in one direction - so you can apply an adjacency limit on
concurrent calls that only counts calls that originate on that adjacency (i.e. the caller connects
on that adjacency to make the call).
You can apply separate limits for each direction or only limit one direction, and you can apply
directional limits as well as non-directional ones (which just count any call, registration, etc.
going in either direction towards the limit) - basically, you can use any combination you like!

Note: Be careful with media bandwidth limits - when you set up a directional bandwidth limit, it
doesn’t only count bandwidth used in one direction. It counts all the bandwidth reserved for
calls set up in that direction.

Limit tables
These tables show all the capacity control limits you can use, and the CLI command for each
limit. We’ll show you where in the CLI to use them below.

Adjacency/source IP/calling number limits

Limit Description Rate/ CLI command
Gauge

Call setup rate Maximum rate of call setup messages (INVITEs) - be Rate call-rate
aware that if you use SIP authentication, there will be
two INVITEs for each call instead of one.
Registration rate The maximum rate of registrations. Includes Rate regs-rate
re-registrations but doesn't include the extra
registrations from Perimeta's fast-registration feature.
In-call signaling The maximum rate of SIP signaling messages within Rate in-call-rate
rate a call. Doesn't include the messages used to set up
and tear down the dialog.
Out-of-call Maximum rate of SIP signaling messages that aren't Rate out-of-call-
signaling rate part of a call or registration. rate

Concurrent calls The maximum number of concurrent calls. Gauge num-calls

64 CONFIDENTIAL
 Configure capacity control limits on an adjacency
Registered The maximum number of concurrently registered Gauge regs
subscribers subscribers.

Bandwidth Maximum total bandwidth allocated for all current Gauge bandwidth
calls. Perimeta allocates a certain amount of
bandwidth for each call based on its codecs, which
is what counts towards this limit - Perimeta prevents
calls exceeding their allocation.
Media streams Maximum number of concurrent media streams. Gauge media-streams
A couple of extra notes about using some of these limits:
• Bandwidth limits are specified for bidirectional media; be aware of this when setting up your
limits. For example, 1 Gb/s Ethernet links provide 1 Gb/s of bandwidth in each direction.
If you used one of these links for several adjacencies, the total bandwidth limit for the
adjacencies would have to be 2 Gb/s or more to allow them to use the full capacity of the
link.
• If you want to set a registration limit, you’ll need to use registration monitoring so that
Perimeta gets updates from the registrar if registrations change. Have a look back at
Understand how Perimeta handles SIP registrations on page 59 if you need a reminder of
what registration monitoring is.

Call limits

Limit Description CLI command

Bandwidth The maximum bandwidth that can be allocated to a bandwidth

single call.
Duration The maximum duration of a call. call-duration
Media streams The maximum number of media streams per call. media-streams
Media renegotiations The maximum number of media renegotiations per call. media-renegotiations

Start here
In this section you will learn how to:
• Configure capacity control limits on an adjacency.
• Configure Perimeta to raise alarms when traffic is approaching the limits

Task 1: Configure the limits

1. Start up the CLI and use these commands to select the adjacency:
config
sbc
signaling
adjacency sip name
Replace name with the name of the adjacency.
2. Use whichever one of these commands matches the type and direction of the limit you’ll
configure first.
• adjacency-limits
• adjacency-limits as-destination

CONFIDENTIAL 65
Configure capacity control limits on an adjacency

• adjacency-limits as-source
• source-ip-address-limits as-source
• calling-number-limits
• call-limits
The as-destination and as-source commands set directional limits that only count
calls or registrations when this adjacency is the destination or the source, respectively.
3. Find the command for the limit you want to set in the tables above, and use it to set the
limit. For gauge adjacency/calling number limits and the call limits, you just need to add
the value after the command. For a rate limit, you’ll need to add sustain before the limit
value, and either per-second or per-minute after it.
Here are a few examples of commands for limits:
call-rate sustain 200 per-minute
num-calls 1000
regs-rate sustain 5 per-second

Note: If you want to manually configure burst rate limits, change the sustain to manual-burst.
4. Add any other limits you want to configure. If you need to change between types of limit,
just use the exit command to go back up to the adjacency mode
Checkpoint : You have now configured a set of capacity control limits for an adjacency.

Task 2: Configure alarm thresholds for capacity control limits

1. Start up the CLI and use these commands to navigate to the alarm thresholds section:
config
sbc
diagnostics
alarm-thresholds
2. Use the following command to configure the adjacency alarm thresholds:
default-adjacency-alarms direction
Replace direction with as-destination for limits using the adjacency as their destination,
or as-source for limits using the adjacency as their source. Alternatively, omit direction for
a limit covering both directions.
3. Enter the command corresponding to the alarm limit you want to configure (e.g. num-
calls-limit).
4. Now configure the thresholds for minor, major and critical alarms. You’ll have to configure
the threshold (as a percentage) at which an alarm is raised, and the threshold at which it
clears. We recommend setting the clear threshold to be much lower than the raise threshold,
to avoid multiple alarms being raised and cleared when traffic varies around a certain level.
Here’s an example command:
major-threshold 80% clear 60%
This sets Perimeta to raise a major alarm when traffic reaches 80% of the configured
threshold, and to clear the alarm when traffic falls back below 60% of the threshold.
Checkpoint : You have now configured Perimeta to raise alarms when traffic levels approach
your capacity control limits.

66 CONFIDENTIAL
 Set up NAT traversal
Set up NAT traversal
What is NAT?
NAT is short for network address translation. It’s a handy way of letting devices in private
networks connect to other networks and the internet without each device needing its own IP
address that would have to be unique across all the networks. It works like this:
• Devices in the private network have their own private IP addresses within that network.
These addresses are only guaranteed to be unique within that network, so they can’t be
used outside it.
• The router at the edge of the private network applies NAT, translating between the private
addresses and (usually) a single public IP address for the whole network.
• To allow the single public address to provide connections to different devices in the private
network, the router will map specific ports on the public IP address to individual private
addresses in the network, creating a NAT pinhole - a path between a device in the private
network and the outside world.
Pinholes can be temporary, created automatically by the router when a device in the network
sends traffic out and removed after a set time without any traffic flowing through them.
They can also be more permanent (static pinholes) - these usually have to be explicitly
configured on the router.

NAT and VoIP

NAT is pretty commonly used in IPv4 networks, but unfortunately its an absolute nightmare for
VoIP. When a phone sends SIP signaling messages to register its location or set up a call, it
includes its IP address as contact information in the message. But if the phone’s behind a NAT,
the IP address it includes will be wrong!
The softswitch (or whatever other SIP device the phone is talking to) needs to know the public
address of the phone - the NAT pinhole. But the phone doesn’t know anything about the NAT
- it will just include its private address, which the softswitch can’t reach. The NAT router will
translate the IP headers of messages it forwards, but it’s not a VoIP device, and it won’t change
the SIP.
The result? A lot of confused devices, and no calls!

How Perimeta helps: NAT traversal

One of Perimeta’s most useful features is a way (or several ways) of getting around this problem
and providing NAT traversal.
Using an SBC like Perimeta already removes part of the problem - your softswitch doesn’t
need to know the actual address for your phones. As far as it’s concerned, the address of each
subscriber is your core-side Perimeta adjacency. All that matters is that Perimeta itself knows
the correct address for phones.
As long as Perimeta knows that a phone is behind NAT, it can compensate by ignoring the
contact information the phone signals and using the information from the IP headers instead,
which should give the address and port for the NAT pinhole to the phone.

Detecting NAT
So, the important thing is that Perimeta has to know when phones are behind NAT. You have
two options for NAT detection. Both of them apply to individual adjacencies.
• If every device connecting to one of your adjacencies will be behind NAT, you can just tell
Perimeta to apply NAT traversal to every connection on that adjacency.

CONFIDENTIAL 67
Set up NAT traversal

• Alternatively, for adjacencies that will have some devices behind NAT and some not,
Perimeta can try and detect whether each device is behind NAT. It does this by checking
whether the address in the SIP headers (specifically, the top-most Via header) matches
the source address in the IP headers.

Keeping the pinhole open

Even when Perimeta knows that phones are behind NAT, there’s still a problem. The contact
details Perimeta stores for a phone when it registers need to stay valid for as long as the
registration does, so that calls can reach the phone. However, temporary NAT pinholes only
stay open if traffic continues flowing through them. A phone can register, then have the pinhole
close due to inactivity, making it unreachable.
There are a couple of ways to prevent this problem. If your phones are using TCP for SIP
signaling, you can configure them to use a ‘keepalive’ mechanism to keep the connection
open. This usually only applies if you’re using the TLS security protocol to encrypt your SIP
signaling; normally phones will use UDP for SIP.
For those phones that use UDP or those that don’t support a keepalive mechanism, you can
use a Perimeta feature called fast-registration to keep the connection open. When you turn
on fast-registration for an adjacency, Perimeta alters its responses to REGISTER messages
on that adjacency, instructing the registering phones to re-register after a much shorter period
than usual (typically 30 seconds). The constant stream of repeated REGISTER messages
keeps the NAT pinhole open and makes sure calls can reach the phones.
Of course, if your softswitch was receiving a REGISTER every thirty seconds from every
subscriber, it would probably start to struggle! To protect the softswitch, Perimeta just handles
the extra messages itself, only passing one through if the normal period is up or if the phone
changes its details.

Note: Perimeta also supports the SIP Outbound (RFC 5626) mechanism for NAT traversal in IMS
networks. So if you’re in an IMS network that supports SIP Outbound, you don’t need to use
fast-registration.

Start here
In this section you will learn how to:
• Configure the NAT detection setting for an adjacency.
• Activate fast-registration on an adjacency.
You only need to do this for adjacencies which might have a NAT between the adjacency and
the SIP devices connecting to it; for example, you shouldn’t need to do it for core adjacencies,
because there shouldn’t be NAT between Perimeta and your core SIP devices.

Task 1: Configure NAT traversal

1. Start up the CLI and use these commands to select the adjacency you’re going to configure
NAT traversal settings for:
config
sbc
signaling
adjacency sip Name
Replace Name with the name of the adjacency.
2. Use this command to set the NAT detection setting for your adjacency:

68 CONFIDENTIAL
 Set up NAT traversal
nat NATSetting
Replace NATSetting with either force-on (assume NAT for all devices) or autodetect
(detect NAT status, device-by-device).
3. Use these commands to enable fast-registration for endpoints behind NAT on this
adjacency.
interop
registration fast-register enable
4. If your endpoints are using TCP, use the following command to allow them to use fast
registration also.
tcp fully-supported
Checkpoint: You have now configured NAT traversal for an adjacency.

CONFIDENTIAL 69
 Set up NAT traversal

70
CONFIDENTIAL
 Configure phones and peers to work with Perimeta
Configure phones and peers to work with Perimeta
You’ll need to set up your SIP phones (and/or PBXs) and your softswitch to use Perimeta. You’ll
also need to co-ordinate with the service providers who control the peer devices at the far end
of any SIP trunks.
We can only tell you the basics here - different devices will have different configuration methods
and might call the same setting by slightly different names, so you’ll need to look at the
documentation for your devices to figure out exactly what to do.
SIP phones/PBXs
The key setting for your SIP phones is the one that determines where they send their registrations
and call requests as a first hop - meaning the first IP address/domain name they send them
out to. This setting will typically be called something like outbound proxy.
Set the outbound proxy on your phones to either the IP address of your Perimeta access
adjacency, or a domain name that’s associated with that address on your DNS (domain name
system) servers.
SIP PBXs should have a similar setting - set it to the IP address or domain name of the
Perimeta peering adjacency for the PBX.
Softswitch
What you need to do on your softswitch will vary depending on its configuration model, but
here are the basics:
• Registrations from SIP subscribers provisioned on the softswitch will arrive from the IP
address of your core Perimeta adjacency. Your softswitch must permit this (which might not
always require any additional configuration).
• Any SIP trunks and/or SIP PBXs configured on your softswitch should have the Perimeta
core adjacency IP address as their proxy.
Trunking peers
Service providers with trunks connecting to your softswitch must set the devices at the far end
of the trunks (typically their switches or their own SBCs) to connect to the IP address or domain
name of the Perimeta peering adjacency for the trunk.

CONFIDENTIAL 71
 Configure phones and peers to work with Perimeta

72
CONFIDENTIAL
 Add a new peer to your deployment
Add a new peer to your deployment
When you first set up Perimeta, you’ll set up all your configuration to work with a certain set of
network and devices - but what about when you want to add new peers later on? Let’s work
through what you need to do to add a new peer to your running system.
In this chapter we’ll be following the case of adding a connection to a single peer - if you’re
interested in setting up a load-balanced group of peers, check out the next chapter Use Peer
Groups to load-balance between peer servers on page 79.

Before you start: allocating IP addresses and ports

It’s always a good idea to make sure each peer has its own adjacency. That means you can
apply separate capacity limits, interoperability settings, and so on to each peer. To create a new
adjacency for your new peer, you’ll need to assign one or the other of these:
• A new local IP address for Perimeta to use for the new adjacency.
• A new, unused port on an existing Perimeta IP address for the new adjacency.
Usually you should use a new IP address if you have the addresses available, since it’s always
easiest to use the default SIP port, 5060, wherever you can.

Start here
In this section you will learn how to:
• Add a new peer to an existing Perimeta deployment.

Task 1: Add the new IP address to the service interface

If you’re adding a new local IP address, you’ll need to add it to the right service interface before
you can use it for an adjacency.

Note: We’re assuming that you’ll use a service interface you’ve already configured - remember, a
service interface is either just a specific physical connection, or a VLAN, so you’re only likely
to need a new service interface if you’re adding a new VLAN. If you do need to, look back at
Add a service interface on page 43.

1. Start up the CLI and use these commands to get into the system configuration mode.
config
system
2. Use show config here to have a look at your service interfaces. Each one will look
something like this:
service-interface serv2
description “General Access Network”
service-network 2
port-group-name AccessNetwork
ipv4
subnet-prefix-length 26
gateway-ip-address 53.53.53.1
local-ip-address 53.53.53.10

CONFIDENTIAL 73
Add a new peer to your deployment

service-address AccessAddress4-01
local-ip-address 53.53.53.11
service-address TrunklAddress4-01
probes-target 53.53.53.1
probes-source-style specific-source
probes-source-ip shelf A interface 1 53.53.53.15
probes-source-ip shelf A interface 2 53.53.53.16
probes-source-ip shelf B interface 1 53.53.53.17
probes-source-ip shelf B interface 2 53.53.53.18
activate
network-security untrusted
criticality 1000
probes-interval 1000
vlan-id 3
Check which service interface (which of serv1, serv2, etc.) is the one you need to add
the IP address to - by looking at the description, port group, VLAN tag (if you use VLANs),
and so on.

Note: Once you find the service interface, make a note of the service network ID (the number in the
service-network line - you’ll need it in the next task).

3. Add the IP address to the service interface using these commands:

service-interface name
ipv4
local-ip-address address
service-address addressName
Replace name with the service interface name you found in the last step, address with the
new local IP address, and addressName with a unique name for that address (you’ll use this
name to identify the address in adjacencies).
Here’s an example of what the service interface we showed you above would look like in show
config with another IP address (name ‘NewPeer-01’) added.
service-interface serv2
description “General Access Network”
service-network 2
port-group-name AccessNetwork
ipv4
subnet-prefix-length 26
gateway-ip-address 53.53.53.1
local-ip-address 53.53.53.10
service-address AccessAddress4-01
local-ip-address 53.53.53.11

74 CONFIDENTIAL
 Add a new peer to your deployment
service-address TrunklAddress4-01
local-ip-address 53.53.53.20
service-address NewPeer-01
probes-target 53.53.53.1
probes-source-style specific-source
probes-source-ip shelf A interface 1 53.53.53.15
probes-source-ip shelf A interface 2 53.53.53.16
probes-source-ip shelf B interface 1 53.53.53.17
probes-source-ip shelf B interface 2 53.53.53.18
activate
network-security untrusted
criticality 1000
probes-interval 1000
vlan-id 3
Checkpoint: You have added the new IP address to the service interface.

Task 2: Add the peer as a known source

To protect your network, Perimeta only allows SIP traffic from known sources, except for
registration requests, which are allowed from unknown sources unless they’re affected by
capacity limits or Perimeta has banned the source for suspicious behavior. Known sources can
be devices on a trusted core network, phones that have successfully registered, or devices
that you explicitly configure as known sources. For a new peer that doesn’t register, you have
to add explicit configuration.
1. Use these commands to add the peer IP address as a known source so that Perimeta will
allow traffic from it.
config
system
ip-access-control
trusted-sources
permit-peer service-network ID ipv4 address
Replace ID with the service network ID you noted down in the last task, and address with
the peer IP address. You can replace ipv4 with ipv6 if you’re using IPv6.

Note: If you’re planning to receive traffic from multiple sources in an IP address range, you can
use the command permit-peer range to add them all at once, rather than having to
configure each separately.

Task 3: Add the adjacency for the peer

1. Type these commands to get into signaling configuration mode:
config
sbc
signaling

CONFIDENTIAL 75
Add a new peer to your deployment

2. Now you’ll need to create the adjacency. As a starting point, here’s the recommended
basis for a peering adjacency from the foundation Perimeta configuration. Don’t type this
in yet! Copy or type it into a text editor so you can make changes to it before you paste it
into the CLI.
adjacency sip Trunk1
adjacency-limits
regs 0
regs-rate sustain 0 per-minute
call-media-policy
media-bypass-policy forbid
deactivation-mode normal
force-signaling-peer all-requests
adjacency-type preset-peering
privacy trusted
realm TrunkMedia1
remote-address-range ipv4 21.21.21.50 prefix-len 32
service-address TrunkAddress4-01
signaling-local-port 5060
signaling-peer 21.21.21.50
dynamic-routing-domain-match 21.21.21.50
signaling-peer-port 5060
statistics-setting detail
default-interop-profile Peer
activate

Note: If you already have peering adjacencies, you might be better off using show config here,
then copying and editing one of the existing ones.

3. You’ll need to replace all the occurrences of 21.21.21.50 with the IP address or domain
name of the peer; remote-address-range has to be an IP address, but signaling-
peer and dynamic-routing-domain-match can be a domain name if you’re using
one to route to the peer.
4. You’ll also need to replace TrunkAddress4-01 with the service-address name for the local
Perimeta IP address you added and configured a name for in the last task.
5. Use show config here to look at your signaling configuration, and check whether there’s
configuration like this already in place:
sip interop-profile Peer
description “for use with a Peer”
header-settings from rewrite host local port include
header-settings via passthrough-inbound
ping-enable

76 CONFIDENTIAL
 Add a new peer to your deployment
interval 8
lifetime 8
dynamic-peer-routing
This is the foundation interoperability profile (a set of interop settings you can use for multiple
adjacencies) for peer adjacencies. Yours might be different, depending on how you set up
your system originally.
If the name in the first line in your peering interop profile isn’t Peer, go back to the adjacency
configuration in your text editor and change the default-interop-profile to use the
right name.
If you don’t seem to have a peering interop-profile, type or copy in the foundation one
above.
6. Finally, copy in your updated adjacency information.

CONFIDENTIAL 77
 Add a new peer to your deployment

78
CONFIDENTIAL
 Use Peer Groups to load-balance between peer servers
Use Peer Groups to load-balance between peer servers
In the previous chapter, Add a new peer to your deployment on page 73, we looked at setting
up a connection between Perimeta and a new SIP peer. We assumed the peer was a single
entity, with one IP address. But what if the peer you’re connecting to has a pool of servers,
and you need to load-balance the traffic between them? Luckily, you don’t need to go and
configure a new adjacency for each of them and do some funky routing - instead you can use
Perimeta’s peer groups feature.

What are peer groups?

Peer groups allow you to configure a group of signaling peers as a single configuration object,
which you can then reference from one or more adjacencies. A peer group can be one of two
types:
• In a DNS-configured peer group, you configure the group with a single hostname which
returns a set of DNS records (and it’s from these that Perimeta discovers the pool of servers).
• In a locally-configured peer group, you manually configure the list of servers in the group.
Where possible, you should use a DNS-configured group as it makes the configuration simpler.

How Perimeta load balances across a peer group

Perimeta distributes requests between the servers in a peer group in one of two ways,
depending on the type of group.
• For a locally-configured peer group, Perimeta distributes the requests randomly between
the servers, with each server having an equal weighting.
• For a DNS-configured peer group, Perimeta uses the weightings and priorities returned in
the DNS records to determine the order in which it should send requests. It follows the rules
laid out in RFC 3263, so check that out if you want to know the complete logic.

Monitoring Availability
You can configure Perimeta to monitor the availability of each server in a peer group. Perimeta
does this by sending SIP OPTIONS messages to the servers, and detecting any that either fail
to respond or send a failure response code. Perimeta won’t then attempt to use that particular
server until the OPTIONS messages start receiving successful responses again.
While you don’t need to turn on availability checking in order to use the peer group, doing so
reduces the time taken to set up calls in the event one of the servers fails (as Perimeta won’t
waste time sending requests to that server).

Start here
In this section you will learn how to:
• Configure a peer group.
• View the current status of a peer group.

Task 1: Configure a peer group

1. Start up the CLI and use these commands to create a new peer group:
config
sbc
signaling
peer-group sip name

CONFIDENTIAL 79
Use Peer Groups to load-balance between peer servers

Replace name with a name for the peer group.

2. Use the description command to add a description to your peer group.
3. If you want to create a DNS-configured peer group, use this command:
dns-peers hostname IPVersion
where:
• hostname is the hostname of your peer.
• IPVersion is the IP version of the addresses that will be returned in the DNS responses
(either ipv4 or ipv6).
4. If you want to create a locally-configured peer group, use this command for each server
you want to add to the group:
peer peerName IPVersion address port portNumber
where:
• peerName is a name for the peer.
• IPVersion is the IP version of the addresses that will be returned in the DNS responses
(either ipv4 or ipv6).
• address is the IP address of the peer.
• portNumber is the port on the peer Perimeta should send messages to. You can leave
this out if you want Perimeta to use port 5060.
5. If you want Perimeta to monitor the servers in the peer group for failures, type this command:
ping-enable
You can then use the commands in the table below to customize the monitoring behavior.
Checkpoint: You have now added a peer group.

Task 2: View the status of your peer group

1. Start up the CLI and use these commands to create a new peer group:
show sbc peer-group name
where name is the name of your peer group.
Perimeta will give you detailed information on the peer group, including the availability of all
of the servers in the group.
Checkpoint: You have verified the status of the peer group you created.

Using Peer Groups

You can configure an adjacency to use a peer group in the same way as you would a single
peer (as we saw in Add a new peer to your deployment on page 73), except that you use the
command signaling-peer-group instead of signaling-peer.
Remember that before Perimeta will accept traffic from the servers in the peer group, the
peers need to be added as known sources. The previous chapter Add a new peer to your
deployment on page 73 contains the steps for this.

80 CONFIDENTIAL
 Design and configure routing policy tables
Design and configure routing policy tables
Routing policy: An introduction
Let’s start by making it clear what Perimeta’s routing policy configuration is for. You’ve already
learned how signaling flows to and from Perimeta through adjacencies. When signaling traffic
arrives on an adjacency, Perimeta has to decide where to send it next. That means selecting
an adjacency to send it out from. In some cases, this is straightforward:
• SIP uses two key kinds of message - requests and responses to those requests. Perimeta
automatically routes responses back to the adjacency the original request came from.
• Another key aspect of SIP signaling is the use of dialogs. Some types of SIP request
set up a dialog between two SIP devices, and later, related messages can be part of that
dialog. The main example of a dialog is a call, which is set up with a SIP INVITE message.
Perimeta routes messages in existing dialogs automatically based on the sources of the
initial request and response.
• SIP phones in access networks will usually register with a registrar device in your core
networks (typically your softswitch). All registrations should pass through Perimeta, and
it keeps a record of them. When it receives a message on an adjacency with a core
adjacency type, it checks whether the message is for a registered phone; if it is, Perimeta
automatically routes it to the adjacency that phone registered on.

Note: The reason Perimeta only automatically routes to subscribers from core adjacencies is that
you will typically want messages arriving from the access side to go to your softswitch first.

For all other messages, Perimeta consults your routing policy configuration to tell it how to
choose the destination adjacency.

Did you know? If you wanted to do some routing in 17th-Century England and Wales, you'd
have needed a copy of Britannia Volume the First, or an Illustration of the Kingdom of England and
Dominion of Wales - one of the very first road atlases.

Routing policy tables

So how does routing policy configuration work? You’ll put together a set of routing policy
tables. Routing tables come in various types depending on what information they use to
route messages; so a source adjacency table routes based on the adjacency the message
came from, a destination domain table routes based on the domain name of the message’s
destination, and so on.
Each table includes one or more rows (called entries in the CLI), which usually include some
kind of condition (based on the type of table), and some action for Perimeta to take. They can
also include the name of a destination adjacency, and some other possible settings depending
on the type of table.
When Perimeta looks at a table, it works through the rows and finds whether the message
being routed matches their condition. Which row ends up being chosen depends on the type
of table – in general Perimeta will try to find a best-match, but in some cases rows with lower
indexes take precedence over higher ones. Once Perimeta has chosen a row, it will take the
action specified in that row, which can be any one of these:
• Go to another routing table.
• Finish routing and send the message to the selected destination adjacency.

CONFIDENTIAL 81
Design and configure routing policy tables

• Finish routing and reject the message, sending an error message back to the message
source.
• Perform an ENUM lookup on the current destination number (not covered here).
Tables can have wildcard entries that will match any message. We suggest you put these at the
end of the table so that they’re easier to find, and so that they’re the last rows to be checked
in the cases where lower indexes take precedence.
Your set of routing policy tables forms a call policy set. You set which table Perimeta will start
with (which can be different for calls and registrations), and it works through other tables from
there.

Note: Call policy sets can also include number analysis tables, which manipulate and validate
source and destination phone numbers. Typically that’s something you want to do on your
softswitch, rather than on Perimeta, so we won’t go into that here.

This probably all seems a bit abstract just now. Don’t worry - routing policy for most deployments
is actually fairly simple. We’ll work through an example to show you how routing tables work in
practice, and how you can configure them.

The other type of table: Number analysis

Before Perimeta applies your routing tables, it can put incoming calls through number analysis
tables. These tables can edit the source number or destination number of the call and validate
them against set rules (rejecting calls that fail validation) - typically checking whether they begin
with or include particular number codes.
It’s unusual to use your Session Border Controller to do number analysis, this is typically the
sort of thing your softswitch will do - we won’t cover number analysis in detail here.

Worked example: A simple deployment

In this section you will learn how to:
• Plan out how your routing will work and which tables you’ll need.
• Design the tables themselves and the entries they’ll include.
• Implement your tables in a call policy set in the CLI.

Task 1: Make a list of your routing requirements

First up, you’ll want to make a list of all the things you want your routing to do. In most
deployments, your basic requirement will be making sure traffic coming from the access/
peering side gets to the right core adjacency, and that any traffic from the core side that isn’t to
subscribers gets to the right access adjacency (usually a SIP trunk). You need to flesh that out
into a specific set of requirements.
Here’s an example list that sets out the needs of our example deployment. This is a deployment
with one core adjacency to a softswitch, core1, one open access adjacency for registering
SIP phones, openAccess, and two peering adjacencies to SIP trunks, trunk1 and trunk2.
• Route any requests from the three access/peering adjacencies to the core adjacency.
• Route any requests from the core adjacency (that aren’t to registered phones - remember,
they get routed automatically) to one of the two peering adjacencies, based on the domain
name in the message destination.
Of course, to do this you’ll need to know what kind of information Perimeta will actually let you
route on. Here’s the list of everything you can route on (every type of routing table) with a basic
Perimeta license.

82 CONFIDENTIAL
 Design and configure routing policy tables
• Source adjacency.
• Source account.
• Source number/username (userinfo part - before the ‘@’ - of the SIP From header).
• Destination number/username (userinfo part of the SIP P-Called-Party-ID header or the
Request-URI if there’s no P-Called-Party-ID).
• Source domain name (domain part - after the ‘@’ - of the SIP From header).
• Destination domain name (domain part of the of the SIP P-Called-Party-ID header or the
Request-URI if there’s no P-Called-Party-ID).
• Carrier identification code.
• Category (assigned by SIP MMF, not covered in detail in this guide)
• Source trunk group ID.
• Destination trunk group ID.

Note: If your license includes Advanced Routing features, you can also route based on time of day
or create routing tables that choose destinations based on load-balancing, least-cost routes,
or voice quality statistics for the potential destinations.

We won’t cover all of these here, but the routing tables work in pretty much the same way for
each type of condition.

Task 2: Plan out the structure of your routing policy

Now that you know what your routing tables need to do, it’s time to figure out the routing tables
you’ll need and how they fit together. You’ll need to take these steps:
1. Choose a starting table, with the first type of condition Perimeta will apply to all messages.
This’ll usually be a source adjacency table, since you’ll want to route messages differently
depending on where they come from.
2. Decide on all the possible outcomes for this table. Outcomes can be a destination adjacency
for the message to get routed to, another routing table for Perimeta to work through, or
rejection of the message.
3. For each new table you added as an outcome of the first one, decide the outcomes in the
same way.
4. Keep going until you don’t have any tables to add (all your outcomes for your last set of
tables are destinations or rejections).
The easiest way to do this is probably to draw a flowchart showing the tables and their possible
outcomes. Here’s one for our example deployment.

CONFIDENTIAL 83
Design and configure routing policy tables

Routing policy example - flowchart

If it isn’t obvious, squares are for routing tables and diamonds are for destination adjacencies -
keeping all the possible destination outcomes for a table in one diamond keeps the chart neat,
but don’t forget that trunk1 and trunk2 are different outcomes!

Task 3: Plan out your individual routing tables

Now that you know which tables you need, you’ll need to plan the actual tables and their
entries. Let’s start by looking at the source adjacency table for our example deployment.

Table name: sourceAdjTable

Entry index Source adjacency Set destination Action
adjacency
1 core1 N/A Go to routing table:
destDomTable
100 * core1 Complete routing
Simpler than you thought? Although our example has four possible source adjacencies, there’s
no need to write out a separate table entry for each one! Since we want the same outcome
for all source adjacencies except core1, we can use the wildcard (the \\* symbol) for that
outcome. This will match any adjacency, so if the message is not from core1 (so the first row
doesn’t match), Perimeta will always apply the second row.
You might have noticed that the second row has an index of 100 instead of 2. That’s because
of these rules, which you should always follow when you design a routing table:
• Always have exactly one wildcard entry at the end of the table, to catch anything that
doesn’t match the more specific entries above it.
• Always set the wildcard index much higher than the indexes of the other entries. Doing this
means you can easily go back and inset more entries before the wildcard if you need them
later.

84 CONFIDENTIAL
 Design and configure routing policy tables
A special case: dynamic domain routing
The remaining table in our example needs to use the destination domain of the message to
send it to either trunkl or trunk2. This is a very commonly used type of routing. You can do
it by configuring a table entry for each domain name to select the correct adjacency, but there’s
a better way - using Perimeta’s dynamic domain routing feature.
Enabling dynamic domain routing tells Perimeta to check the destination domain of the
message against domain names that you configure on the adjacency objects themselves,
instead of explicit entries in the routing table. When it finds an adjacency with a matching
domain name, it selects that adjacency as the destination.
Dynamic domain routing helps keep your routing tables simple when you have lots of possible
destination adjacencies. It also lets you add new adjacencies (for new trunks, PBXs, etc.)
without having to change your routing configuration - which is handy, because it’s tricky to edit
routing policy while your Session Controller is running!
Here’s our second routing table, which applies dynamic domain routing.

Table name: destDomTable

Entry index Destination domain Set destination Action
adjacency
100 * Apply dynamic Complete routing
domain routing
101 * trunk1 Complete routing
Now there are two wildcards! Don’t get confused just yet. Any row that uses dynamic domain
routing will only match if Perimeta can actually find an adjacency with the right domain
configured on it. Otherwise, Perimeta will move on to the next row.
In this table, we need the second wildcard after the dynamic routing line to catch anything
that doesn’t match any adjacencies. In our example we’re sending any messages like that to
trunk1 as a default, but you could also choose to reject the messages as invalid.
As well as setting up your routing tables, you have to enable dynamic domain routing on any
adjacencies that will use it - we’ll get to that below.

Task 4: Configure it all in the CLI

Call policy sets can be complex, in case you hadn’t figured that out already! So, unlike the other
tasks you’ve seen, we won’t be taking you through entering one command at a time. Instead,
we recommend you type out your full set of call policy set configuration ahead of time and then
just copy and paste it into the CLI. We’ll show you the full call policy set for our example and
explain the key commands.

Note: Creating your CLI configuration ahead of time for copy and paste is often a good idea for
other areas of configuration too. Figuring out exactly what you need to do in advance can be
less error-prone than doing it bit-by-bit.

Here’s the full call policy set for our example deployment:
config
sbc
signaling
call-policy-set 1
rtg-src-adjacency-table sourceAdjTable
description “First routing table, divides core and access.”

CONFIDENTIAL 85
Design and configure routing policy tables

entry 1
match-adjacency core1
action next-table destDomTable
entry 100
match-adjacency *
dst-adjacency core1
action complete
rtg-dst-domain-table destDomTable
description “Second routing table, routes traffic from core”
entry 100
match-domain *
dst-adjacency dynamic-peer-routing
action complete
entry 101
match-domain *
dst-adjacency trunk1
action complete
first-call-routing-table sourceAdjTable
complete
Compare this configuration to the tables in the previous section to see how it works. You can
see that:
• there are commands to create and name each table, such as rtg-src-adjacency-
table
• sourceAdjTable
• within each table there are entry commands to add each table entry, with further
commands for the action, match condition, and the destination adjacency, if needed
• after the tables there’s a first-call-routing-table command to set which table in
the call policy set Perimeta starts with
• there’s a complete command at the end; this locks the call policy set as ready to use, and
you’ll need to remove it with no complete if you want to make changes later on.
The last thing you need to know is how to activate a call policy set once you’ve configured it.
You can configure multiple call policy sets in the CLI, identified by a number (have a look at the
call-policy-set command above - you’ll see it specifies number 1).
To activate a call policy set, use these commands:
config
sbc
signaling
active-call-policy-set ID
Replace ID with the number of the set you want to activate.

86 CONFIDENTIAL
 Design and configure routing policy tables
It is possible to make changes to the active call policy set, and Perimeta will police the
changes to reject those which would invalidate the routing config. Before you make changes,
we recommend copying the existing call policy into a new call policy set, so that you have a
backup you can switch to easily if things go wrong.

Note: For those wanting to be extra cautious, it is possible to forbid the editing of the active call
policy set.

Enabling dynamic domain routing on your adjacencies

If your call policy set uses dynamic domain routing, like this one does, you’ll need to configure a
couple of settings on all the adjacencies you want to be possible targets for the domain routing
table. Here’s what you need to do for each adjacency:
1. Start up the CLI and use these commands:
config
sbc
signaling
adjacency sip name
dynamic-peer-routing
dynamic-routing-domain-match domain
Replace name with the name of your adjacency, and domain with the domain name that
you want to associate with the adjacency - so that the dynamic domain routing table
selects this adjacency for messages sent to that domain name.
If you don’t include a dynamic-routing-domain-match command, Perimeta will try and
use the adjacency signaling-peer setting, but it’s always a good idea to set the domain
explicitly - it makes your configuration clearer.

Warning! Make sure each domain name is only configured on one adjacency! If you configure the same
dynamic routing domain name on multiple adjacencies, Perimeta won’t know which one to
route to.

Testing your routing tables

You can do some basic testing of routing tables in the CLI so long as they only use the source
number, destination number, and source adjacency - this function doesn’t work for routing
that uses domain names (like our example) or other parts of messages. To run a test, use this
command:
show sbc route dest-number destNumber src-adj adjacency src-number
sourceNumber
Replace destNumber, adjacency, and sourceNumber with the destination number, source
adjacency, and source number you want to test - Perimeta will show you which destination
adjacency it would select for those values, based on your current active call policy set.

Going further
The example we’ve worked through here is only a small taste of what’s possible with routing
tables. You might not need to do anything more complicated, and many deployments will
only need a couple of tables similar to those above. However, if your requirements are more
extensive, you can use more entries, more tables, and tables of different kinds to create more
complex routing logic.

CONFIDENTIAL 87
Design and configure routing policy tables

We won’t list every command for every type of routing table here, but we will give you a few more
examples of the most common types of table. You can refer to the Perimeta Configuration and
Interoperability Guide or the Perimeta CLI reference for full lists of commands for every type of
table. The important thing is that you work through the stages we’ve given you here to make
sure you put together a consistent, logical set of tables that do what you want them to do!

Note: Some of the more advanced routing features, such as time-of-day tables and re-routing on
failure, are only available if your Perimeta license includes the advanced routing feature pack.

Extra example tables

Source/destination number or username
Here ‘s a table that shows routing based on the source number or username of the incoming
message.
rtg-src-id-table exampleSourceTable
description “Example source number routing table”
entry 1
match-id digits (0208)364575[1-4]
dst-adjacency exampleAdj1
action complete
entry 2
match-id digits 0123 prefix
dst-adjacency exampleAdj2
action complete
entry 100
match-id digits X prefix
action next-table otherTable
entry 101
match-id text-regex .*
action next-table otherTable
The match-id lines work like the match lines in the tables you’ve already seen, controlling
which messages match which entries in the table - but these ones need a little more explanation,
since these tables let you be a bit more flexible than having to put in routing rules for every
possible number.
The first entry matches (0208)364575[1-4], which shows a couple of different tricks you
can use. The part in ( ) is optional. So a number that begins with 0208 and matches the rest
is allowed, but you can delete the 0208 and it’ll still match. The part in [ ] is a range. So the last
number can be 1, 2, 3 or 4. The rest (the 364575 in the middle) has to match exactly. So here
are some numbers that would match this entry:
02083645751
02083645753
3645751
3645754

88 CONFIDENTIAL
 Design and configure routing policy tables
The second entry says prefixafter the number. That means all that matters is whether the
start of the source number matches your string. So these numbers would all match the 0123
prefix entry.
01234567891
01230000000
0123
01234571231

Note: You can still use the optional numbers and ranges from the first entry in prefixes.
The third and fourth entries are wildcards there to catch any calls that don’t match the first two.
The third uses an X, which counts as a wildcard that can be any digit from 0 to 9. Using this as
a prefix will catch any source number that begins with a digit. However, sometimes (with certain
setups using softphones) the source ‘number’ is a SIP username instead, so the last entry uses
a regular expression that will match any text username to catch those. Don’t worry if you don’t
know what regular expressions are - you can just copy this one for your wildcard entries.
Entries for tables routing on destination number or username work in exactly the same way.
The only difference is a different command for creating the table. For example:
rtg-dst-id-table exampleDestinationTable
Source domain
Source domain tables are very similar to destination domain tables, although there’s no
equivalent of dynamic domain routing - all entries match a specific source domain (or a wildcard).
rtg-dst-domain-table exampleDestDomainTable
entry 1
match-domain example.com
dst-adjacency exampleAdj
action complete
entry 100
match-domain *
action next-table otherTable
Source account
Source account tables work in exactly the same way as the source adjacency tables you’ve
already seen, but with slightly different commands, as in this example:
rtg-src-account-table exampleAccountTable
entry 1
match-account myAccount
dst-adjacency exampleAdj
action complete
entry 100
match-account *
action next-table otherTable

CONFIDENTIAL 89
 Design and configure routing policy tables

90
CONFIDENTIAL
 Understand the different levels of Perimeta security
Understand the different levels of Perimeta security
Perimeta exists to protect your network. To do this, it needs to apply some strict rules, carefully
controlling which traffic it allows through. Understanding these rules will help you understand
how your system works, and help make sure your configuration doesn’t leave any chinks in
Perimeta’s armor!

Intelligent access control

Intelligent access control refers to the whole set of finely-tuned filters and limits Perimeta
applies to make sure excessive or malicious traffic never makes it into your core network. Think
of it as a set of high fences with carefully-guarded checkpoints as the only way through, each
one applying a different set of entry rules to every data packet coming through.
Intelligent access control applies differently to signaling and media, with Perimeta distinguishing
between the two based on the destination port range. We’ll take you through each in turn.

Signaling
Here’s how intelligent access control applies to incoming signaling:
• Signaling packets must be sent to a valid IP address and port, meaning that they have to
match a configured adjacency on the service interface it arrives on (if you’ve forgotten, it’s
the ethernet port and VLAN tag that determine which service interface a packet arrives on).
• Signaling packets (other than REGISTER messages) must be from a known source. More
on this below, but it basically means that it must be from an address or network Perimeta
is aware of and has some reason to trust.
• SIP signaling messages must be valid SIP. Perimeta rejects any that are malformed.
• If Perimeta is overloaded and needs to drop some incoming signaling traffic, it assigns
different priorities to signaling traffic based on the type of packet and where it comes
from. It then limits the rate of lower-priority traffic, dropping some of it if necessary, to make
sure high-priority traffic gets through.
• Perimeta dynamically monitors suspicious traffic from particular sources (such as invalid
messages or excessive amounts of otherwise valid traffic). If a particular address or network
is sending a high rate of suspicious traffic, Perimeta applies dynamic blacklisting, de-
prioritizing and eventually banning all traffic from the suspicious source. Perimeta can
quickly discard traffic from blacklisted sources without spending much effort processing it,
which helps protect Perimeta itself from attacks.

Known and unknown sources

So, signaling other than REGISTER messages must be from a known source - but what exactly
counts as a known source? Here are all the reasons Perimeta will count an IP address as
known:
• It is connecting on a service interface with the trusted or untrusted-priority trust
level setting. All sources on these networks are automatically known sources. That’s why
you have to be very careful with this setting!
• It has successfully registered with your softswitch through Perimeta (using a REGISTER
message). This only counts for as long as the registration lasts.
• You have explicitly configured it as a known source in the CLI. This feature lets you allow
traffic from specific devices that don’t register - for example, the peer at the other end of
a SIP trunk.

CONFIDENTIAL 91
Understand the different levels of Perimeta security

Media
Intelligent access control for media is a bit simpler than for signaling. Here’s how it works:
• When a call is successfully signaled through Perimeta, Perimeta sets up a media gate,
assigning a Perimeta media address and port (on an ISC or MSC) to each side of the call. It
updates the signaling messages to tell the endpoints in the call where to send their media.
Perimeta only allows media packets through if they arrive at a media gate for a current call.
• Media packets must be UDP packets using RTP/RTCP (or encrypted SRTP). Packets
Perimeta doesn’t recognise as valid media will be dropped.
• Perimeta assigns a certain amount of bandwidth for each call, based on the codecs
signaled. It limits each call to its assigned bandwidth, and will drop excess packets to
prevent a call exceeding the limit.

Configuring a known source

In this section you will learn how to:
• Configure an IP address in an untrusted network as a known source, so that Perimeta will
allow it to make calls without registering first.
You’ll need to know:
• The IP address you want to add as a known source.
• The service network ID of the service interface the source will connect on.
You’ll typically need to do this for the IP addresses of all your SIP trunking peers.

Task 1: Configure the known source in the CLI

1. Start up the CLI and use these commands to get into the known sources configuration
mode:
config
sbc
system
ip-access-control
trusted-sources
2. Use this command to add the known source to Perimeta’s list.
permit-peer service-network networkID ipv4 address
Replace networkID with the service network ID, and address with the IP address of the
known source.

Note: You can also change ipv4 to ipv6 for an IPv6 address.
Checkpoint: You have now added a known source.

92 CONFIDENTIAL
 Plan and configure your dynamic blacklisting profiles
Plan and configure your dynamic blacklisting profiles
What is dynamic blacklisting?
Dynamic blacklisting is one of Perimeta’s core security features. It’s absolutely key to how
Perimeta protects your core network.
The point of blacklisting is for Perimeta to identify devices on untrusted, access-side networks
that might be threats to your core network, so that it can act to shield your core devices against
those threats. It does this by carefully monitoring any suspicious behaviour by different traffic
sources. A traffic source can be one of several different things:
• A whole service network - the entire network connected to a single Perimeta service
interface. An entire network could become a threat because of a distributed denial of
service (DDOS) attack, in which an attacker uses large number of different devices (perhaps
compromised through a virus) to try and flood your network with traffic and bring it down.
• An IP address.
• A particular port on an IP address - in some circumstances, different ports on a single IP
address represent different devices (with NAT routers, for example). In those cases it makes
more sense for Perimeta to monitor the different ports separately.
Perimeta tracks a range of different types of potentially suspicious traffic from these sources.
We call the different types of traffic Perimeta tracks different blacklisting reasons. Some
blacklisting reasons are suspicious in themselves, like malformed SIP messages, but some
are normal types of traffic such as registration messages. We include these types of traffic
because some attacks will use large amounts of otherwise valid traffic to try and overload your
core network.

Understanding blacklisting thresholds

So, Perimeta is monitoring various types of potentially-suspicious traffic from different traffic
sources. What does it do with this information?
It continually checks the rate of suspicious events for each blacklisting reason against a set of
thresholds. These are configured by you and are different for different traffic sources - after all,
what counts as a suspicously high number of messages for a single IP address is very different
from what counts as a suspiciously high number of messages for a whole network!
As the rate of suspicious events received from a source for a particular blacklisting reason
passes each of up to four increasingly high thresholds, Perimeta takes different actions to
protect your core network from the suspicious traffic source:
• At the lowest threshold, it raises a minor alarm.
• At the next threshold, it raises a major alarm.
• At the next threshold, it downgrades the source. Perimeta will continue to process and
forward traffic from the source, but at a lower priority than other traffic - if Perimeta starts to
become overloaded, it will make sure other traffic gets through first, discarding traffic from
the downgraded source if necessary.
• At the highest threshold, it bans the source. Perimeta will discard all traffic from the source
with minimal processing until the ban expires.

Note: Downgrades and bans raise their own alarms as well, to make sure you know what’s
happening.

All these thresholds are rates - so you might have a downgrade threshold for excess registration
messages that kicks in if a source sends registrations at a rate higher than 20 per minute.

CONFIDENTIAL 93
Plan and configure your dynamic blacklisting profiles

Blacklisting reasons
Here’s a table giving every type of event that can count as a blacklisting reason. You can set up
blacklisting thresholds for any of these. You’ll want to refer back to this table when you come
to plan out your thresholds; we’ve included the CLI keyword for each reason so you can easily
use the table figure out what our configuration examples further down are actually doing!

Reason CLI keyword Events counted

Authentication failure auth-failure Perimeta receives a SIP request containing authentication
credentials, forwards that message to a registrar, and the registrar
challenges those credentials (with a 401 or 407 response).
Capacity limit capacity-limit Perimeta rejects a request because it exceeds the configured
exceeded capacity control limits.
Corrupt message corrupt-message Perimeta receives a SIP message which it is unable to parse. This
may indicate an attempt to exploit bugs in third-party products'
error handling.
Endpoint registration endpt-reg Perimeta receives a SIP REGISTER message (including those
received as a result of its fast registration feature, which
vastly increases the number of registrations from phones). An
unexpectedly large number of messages may indicate a denial of
service attack.
Endpoint registration endpt- Perimeta receives a SIP REGISTER message that it forwards to
(excluding fast- registrar-reg the registrar; this excludes messages that it discards due to its fast
registers). registration feature and allows you to differentiate between a large
number of REGISTERs received due to fast registration and a large
number due to a potential denial of service attack.
Number validation num-validation- Perimeta receives a SIP message containing source or destination
failure failure numbers which are rejected by its number analysis.
Routing failure routing-failure Perimeta receives a SIP message which then results in a 404,
410, 485, or 604 response code, either downstream or generated
by Perimeta because it has failed to route the message to an
outbound adjacency.
Bad source address source-addr Perimeta receives a SIP message and matches it to an adjacency,
but the source address, port, and/or transport protocol does not
match the remote address range in the adjacency configuration.
This may mean that an unauthorized party has attempted to
connect to your system.
Excessive messages spam Perimeta receives any SIP message (excluding extra REGISTERs
received due to the fast registration feature). An unexpectedly large
number of messages may indicate a denial of service attack.
TCP failures tcp-abuse The Session Controller receives a TCP connection which is
terminated (at either end) without being authenticated by a
successful REGISTER, or it receives a connection which it
terminate because it does not receive any data, or a subscriber
using a TLS/TCP connection fails to comply with the TLS protocol.
TLS renegotiations tls-reneg A TLS subscriber renegotiates the encryption parameters for its
connection. Excessive renegotiations may indicate a denial of
service attack

94 CONFIDENTIAL
 Plan and configure your dynamic blacklisting profiles
How it’s all configured - profiles and scopes
Here’s how you actually set up your thresholds in the CLI:
• You configure a set of blacklisting thresholds, for various different blacklisting reasons, in a
blacklisting profile.
• You apply your profile at one of five different scopes, to set the traffic sources that profile
will apply to.
This system lets you apply the same profile (the same set of blacklisting thresholds) to multiple
different traffic sources. For example, you can configure a profile with appropriate thresholds
for individual SIP phones, and then apply it to IP address or IP address/port sources (whichever
actually represent individual phones) on various different networks.
Next we’re going to go through the different scopes you can apply your profiles at. Don’t worry
if you’re feeling a bit lost - this is one of the more complicated bits of Perimeta configuration,
but it is important! Once we’ve gone through this high-level overview, we’ll show you how an
actual profile works in some example configuration, and that should make things clearer.

Scopes
We’ll separate the scopes out by the type of traffic sources they include - service network, IP
address, or IP address/port.
Service network scope
There’s one scope for service network sources, and it’s straightforward - you just apply your
profile and the thresholds it includes to a particular service network, using the service network
ID.

Note: The service network ID is a number you configure on the service interface object in the CLI to
use as an identifier for the network that interface connects to. We covered them back in Add
a service interface on page 43.

IP address scopes
There are two scopes you can use to apply your profile to IP address sources:
• You can apply your profile to a specific IP address (on a specific service network).
• You can apply your profile at the per-address scope. This means you select a service
network and Perimeta applies your profile separately to each individual IP address on the
service network. So each IP address gets identical blacklisting thresholds, but they aren’t
shared - it’s as if you applied a distinct copy of your profile to each individual IP address in
turn. Obviously, this is useful on service networks where you don’t know all the different IP
addresses that phones and other devices will use in advance.
You might have noticed that these two scopes can overlap! You can configure a profile that
applies to every IP address on a network, and one that applies to a specific IP address on that
network. The specific IP address now has two profiles applied to it - what happens now?
Perimeta always prefers the more specific profile. In this situation, the IP address with its own
specific profile would only take thresholds from that profile. Perimeta would ignore the network-
wide per-address profile for that IP address.
Port scopes
There are two scopes you can use to apply your profile to port sources (a single port on a single
IP address).
• You can apply your profile to the port sources on a single IP address. This means you select
an IP address (on a service network) and Perimeta applies your profile separately to each
port source on that IP address.

CONFIDENTIAL 95
Plan and configure your dynamic blacklisting profiles

• You can apply your profile to all the port sources on a service network. As with choosing
an IP address, Perimeta applies the profile separately to each port source on the service
network.
As with IP address scopes, if two profiles overlap for a port source, Perimeta will prefer the
more specific one - the one applied to an IP address instead of a whole network.

Start here
In this section you will learn how to:
• Put together a blacklisting profile, setting the thresholds for different blacklisting reasons.
• Apply your blacklisting profile at your chosen scope.

Task 1: Create a blacklisting profile

We’re going to deal with this a little differently than most of the other tasks in this guide. There
are a lot of CLI commands included in a typical blacklisting profile. Most of them do similar
things, setting the same kinds of threshold over and again for different blacklisting reasons - but
a step-by-step ‘type this command, then this command, then this command’ process would
be long and confusing. Instead, we’re going to give you a ready-made profile and show you
how you can change it to get the profiles you need for your purposes.
With the more complex areas of CLI configuration like this one, we really recommend working
out and checking your configuration in advance in a text editor, so you can copy and paste it
into the CLI. It’s much easier than trying to create something like a blacklisting profile line-by-
line.
Here’s our example profile:
profile Peer250
description “Profile for Trunk or PBX with 250 calls”
reason auth-failure
trigger-period 30 seconds
minor-alarm-rate 6 per-minute
major-alarm-rate 2 per-second
ban-rate 3 per-second
ban-duration 10 minutes
reason routing-failure
trigger-period 30 seconds
minor-alarm-rate 150 per-minute
major-alarm-rate 38 per-second
ban-rate 50 per-second
ban-duration 10 minutes
reason endpt-reg
trigger-period 30 seconds
minor-alarm-rate 6 per-minute
major-alarm-rate 2 per-second
ban-rate 3 per-second

96 CONFIDENTIAL
 Plan and configure your dynamic blacklisting profiles
ban-duration 10 minutes
reason capacity-limit
trigger-period 30 seconds
minor-alarm-rate 6 per-minute
major-alarm-rate 2 per-second
ban-rate 3 per-second
ban-duration 10 minutes
reason corrupt-message
trigger-period 30 seconds
minor-alarm-rate 6 per-minute
major-alarm-rate 2 per-second
ban-rate 3 per-second
ban-duration 10 minutes
reason source-addr
trigger-period 30 seconds
minor-alarm-rate 6 per-minute
major-alarm-rate 2 per-second
ban-rate 3 per-second
ban-duration 10 minutes
reason spam
trigger-period 30 seconds
minor-alarm-rate 15 per-second
major-alarm-rate 225 per-second
ban-rate 300 per-second
ban-duration 10 minutes
reason num-validation-failure
trigger-period 30 seconds
minor-alarm-rate 6 per-minute
major-alarm-rate 2 per-second
ban-rate 3 per-second
ban-duration 10 minutes
reason tcp-abuse
trigger-period 30 seconds
minor-alarm-rate 6 per-minute
major-alarm-rate 2 per-second
ban-rate 3 per-second
ban-duration 10 minutes

CONFIDENTIAL 97
Plan and configure your dynamic blacklisting profiles

reason tls-reneg
trigger-period 30 seconds
minor-alarm-rate 6 per-minute
major-alarm-rate 2 per-second
ban-rate 3 per-second
ban-duration 10 minutes
reason endpt-registrar-reg
trigger-period 30 seconds
minor-alarm-rate 6 per-minute
major-alarm-rate 2 per-second
ban-rate 3 per-second
ban-duration 10 minutes
This profile is designed to be appropriate for a single peer SIP device - a SIP trunk or a PBX
- that you expect to have a usual load of about 250 calls at a time. That means you’d usually
expect to apply it at IP address scope.
Hopefully it’s pretty obvious how the profile breaks down by blacklisting reason. There’s a
command for each blacklisting reason - like reason corrupt-message - and the indented
commands immediately below it apply specifically to that blacklisting reason, setting its
blacklisting thresholds and a couple of related settings.
Lets look more closely at the corrupt messages section of our example profile:
reason corrupt-message
trigger-period 30 seconds
minor-alarm-rate 6 per-minute
major-alarm-rate 2 per-second
ban-rate 3 per-second
ban-duration 10 minutes
Here’s what each part of this does:
• The key commands are minor-alarm-rate, major-alarm-rate, and ban-rate.
These set the blacklisting thresholds. So ban-rate 3 per-second means any source
using this profile will get a ban if it starts sending more than three corrupt SIP messages
per second. You can set any threshold using either per-second or per-minute units - it
doesn’t matter which you use, but make sure you don’t get them mixed up!
• The ban-duration 10 minutes command is quite self-explanatory. It just sets how
long a ban triggered for this blacklisting reason will last. You don’t need to make this too
long - if the source is still breaking the threshold when the ban expires, Perimeta will quickly
ban it again! 10 minutes is usually a reasonable length - long enough for Perimeta not to be
overloaded when a malicious source is repeatedly unbanned and rebanned, short enough
to minimize the lengths of bans caused by temporary device malfunctions or traffic surges.
• The trigger-period 30 seconds command sets the time period over which Perimeta
measures the rate of events to check against the threshold. There’s usually no reason to
change this from the default 30 seconds.
If you’ve been paying attention, you might have noticed that there’s a threshold missing! Our
example profile doesn’t include downgrade thresholds. You don’t have to include any of the

98 CONFIDENTIAL
 Plan and configure your dynamic blacklisting profiles
four thresholds - for example, it’s quite common to stick to just one alarm threshold. Here’re
the commands you’d use to add an example downgrade threshold to one of the blacklisting
reasons:
downgrade-rate 2 per-second
downgrade-duration 5 minutes
The downgrade-duration command works just like ban-duration.

Making your own profile

So here’s how you can use our example to make and apply your own blacklisting profile:
1. Decide what type of traffic source you’re making the profile for - you’ll need to have an idea
of the amounts of traffic it sends under normal conditions.
2. Look through the table of blacklisting reasons in Blacklisting reasons on page 94 and
decide on your thresholds for each one. These should depend on what you expect to
be normal for the devices this profile applies to - but remember to leave some leeway for
periods of higher-than-average traffic!
3. Copy the example profile we gave you above into a text editor. Work through the different
reasons and edit the threshold commands to match what you need. Change peer250
to a descriptive name for your profile, and replace the description line with a short
description of what your profile is for.
4. When your new profile is ready, start up the CLI (on your SSC or ISC) and use these
commands to get into the right mode:
config
system
ip-access-control
blacklisting
5. Copy in your profile from your text editor.

Using pre-made profiles

Not everyone has the in-depth knowledge of expected network traffic they need to design their
own profiles - so if you don’t know where to start with deciding on your thresholds, don’t panic!
The various editions of the Perimeta Commissioning Guide provide sets of pre-made profiles
for various types of traffic source at different expected call loads, and a spreadsheet-based tool
for calculating suitable thresholds at other call loads is also available.

Task 2: Apply your profile to traffic sources

It might have seemed like a lot of effort to get to this point, but your blacklisting profile isn’t
actually doing anything yet! You need to actually apply it to some traffic sources, at one of the
scopes we described earlier. If you’re not sure which scope you’ll be applying your profile at,
here’s a quick cheat sheet summing up the scopes:

CONFIDENTIAL 99
Plan and configure your dynamic blacklisting profiles

1. Start up the CLI and use these commands to get into the correct mode for applying
blacklisting profiles:
config
system
ip-access-control
blacklisting
profile-usage
2. The next command will depend on your chosen scope - jump to the appropriate section:
Service network scope
• To apply your profile to a whole service network, use these commands:
scope service-network
service-network ID profile profileName
Replace ID with the service network ID and profileName with the name of your blacklisting
profile.

100 CONFIDENTIAL
 Plan and configure your dynamic blacklisting profiles
IP address scopes
• To apply your profile to a single IP address source, use these commands:
scope specified-address
service-network ID
ipv4 address profile profileName
Replace ID with the service network ID, address with the IP address, and profileName with
the name of your blacklisting profile.
• To apply separate instances of your profile to each IP address that connects on a particular
service network, use these commands:
scope per-address
service-network ID profile profileName
Replace ID with the service network ID and profileName with the name of your blacklisting
profile.
Port scopes
• To apply separate instances of your profile to each port source on a particular IP address,
use these commands:
scope per-port
service-network ID
ipv4 address profile profileName
Replace ID with the service network ID, address with the IP address, and profileName with
the name of your blacklisting profile.
• To apply separate instances of your profile to each port source that connects on a particular
service network, use these commands:
scope per-port
service-network ID
all-addresses profile profileName
Replace ID with the service network ID and profileName with the name of your blacklisting
profile.
Checkpoint: You have created and applied a dynamic blacklisting profile.

CONFIDENTIAL 101
 Plan and configure your dynamic blacklisting profiles

102
CONFIDENTIAL
 Configure DSCP packet marking
Configure DSCP packet marking
What is DSCP?
DSCP stands for DiffServ Code Point. It’s a system of marking IP packets, using their type-
of-service (TOS) header, to indicate their importance to maintaining quality of service (QoS).
Routers and switches can use the DSCP values of packets to prioritize them when forced to
queue or drop packets because the network is busy.
DSCP can be important for VoIP networks because you need to maintain QoS for media
packets to keep call quality up to scratch.
Perimeta lets you set DSCP values that it will use to mark signaling, voice, and video packets
on service networks. You can also set values for various kinds of packet on the management
network.

Perimeta DSCP configuration

There are two ways for you to configure DSCP marking on Perimeta. The first is to use a set
of global values, configured in the Craft Terminal. The other is to use QoS profiles, which are
CLI configuration objects that let you set specific DSCP values for Perimeta to use specific
adjacencies, but only apply to in-dialog SIP and media packets (i.e. they only apply to the
packets involved in ongoing calls).

Global values
You can set global values in the Craft Terminal for these types of packet, most of which Perimeta
only uses on the management network:
• Signaling. This is the only value that affects service networks instead of the management
network, and the only one Perimeta will add to packets by default, with the industry-
standard value of 24. It applies to all H.248 packets, all out-of-dialog SIP, and works as the
default for in-dialog SIP when there isn’t a QoS profile configured.
• SNMP
• DNS
• NTP
• SSH
• ICMP
You should set these values when you first set up Perimeta. Changing them while your system
is running involves a switch between your primary and backup Perimeta instances (a Software
Protection Switch or SPS), which interrupts dialing and ringing calls.

QoS profiles
A QoS profile is a CLI object that includes DSCP values for one of these types of packet (each
profile only applies to one type of packet):
• In-dialog SIP signaling. This overrides the global value for signaling in the Craft Terminal for
in-dialog messages only.

Note: In-dialog messages are part of an existing SIP exchange (usually a call or a registration
exchange).

• Voice.
• Video.

CONFIDENTIAL 103
Configure DSCP packet marking

The default values Perimeta uses are (industry standards) 24 for signaling, and 48 for voice
and video.
Both voice and video refer to media packets using the RTP protocol. Perimeta divides them
into voice and video based on the signaling used to set up the call; the SDP for the media
stream will include an m=audio or m=video line that Perimeta uses to classify the packets in
the stream.

Note: SDP is the Session Description Protocol. It’s used in the SIP messages that set up a call to
set up all the details of the media streams.

For voice and video, instead of setting a value, you can set the profile to pass through the
existing TOS values on the media packets. Use this when you want to respect values set by a
media gateway or other infrastructure device.
You apply QoS profiles to individual adjacencies; Perimeta marks the packets it sends out on
the adjacency according to its QoS profiles. Each adjacency can have one profile for each of
the three packet types.
You can also configure a default QoS profile for each type of packet, which applies to any
adjacencies without their own QoS profile for that type. Only use this if you want to replace
Perimeta’s default values.

Start here
In this section you will learn how to:
• Set the global values in the Craft Terminal.
• Create a QoS profile in the CLI, or edit the default QoS profiles.
• Apply a QoS profile to an adjacency.

Task 1: Configure global DSCP values

1. Start up the Craft Terminal and choose these options:
• Admin
• Network
• Management
• DSCP
2. Choose the packet type that you want to mark from the menu, and type in the DSCP value
when the Terminal prompts you to. Do this for each packet type you want to mark.
You’ll now need to reboot Perimeta. How you do this will depend on whether your system is
currently in service.
Out of service system (initial setup)
1. Type in = and press Enter to return to the start of the Craft Terminal menus.
2. Choose these options:
• Admin
• Reboot
3. When prompted, choose to reboot all instances (processor-blades, servers, etc.) of
Perimeta. You’ll lose your connection to Perimeta while they reboot.

104 CONFIDENTIAL
 Configure DSCP packet marking
In service system
On a system that’s currently in service, you’ll need to reboot your backup Perimeta instance,
then switch Perimeta to use it so you can reboot the other instance.

Note: A Perimeta instance is a processor blade in the chassis on CH6010 hardware, a separate
server on COTS hardware, or a single Virtual Machine.

You’ll need to know which instance, A or B, is the primary and which is the backup. You
should have connected to the Craft Terminal using your Perimeta system IP address, which will
connect you to whichever instance is currently primary. If you connected using an IP address
for one of the specific instances, you need to reconnect using the system IP.
Check the text at the top of the Craft Terminal menu to see whether the primary instance you’re
connected to is A or B. Here’s an example:

In this case, the primary instance would be processor-blade A. Make sure you note down
carefully which is which!
1. Type in = and press Enter to return to the start of the Craft Terminal menus.
2. Choose these options:
• Admin
• Reboot
3. When prompted, choose to reboot the instance that you noted down as the backup.
4. Back at the menu, wait a few minutes for the backup to fully reboot. You’ll know it’s ready
when it shows as contactable again, like it does in the screenshot above - you can
refresh the menu to check by pressing Enter.
5. Once the backup has rebooted, choose Reboot again. This time, choose the other
Perimeta instance (the primary).
Perimeta will switch over the backup and primary instances first, so that service continues
during the reboot. You’ll lose your connection to the Craft Terminal.
Checkpoint: You have now configured the global DSCP values.

Task 2: Create a QoS profile or edit the default profile

1. Start up the CLI and use these commands to get into the signaling mode:
config
sbc
signaling
2. Use one of these commands to create or select a QoS profile - choose the command for
the packet type you want the profile to apply to:
• qos sig-profile name
• qos video-profile name
• qos voice-profile name
Replace name with a name for your QoS profile, or with the word default if you want to
edit the default profile for that packet type.

CONFIDENTIAL 105
Configure DSCP packet marking

3. Use this command to set the DSCP value Perimeta should add to packets of your chosen
type when it applies this profile.
dscp value
Replace value with the DSCP value.

Note: If this is a voice or video profile and you want to pass through DSCP values instead of adding
them, use the command marking passthrough instead.

Checkpoint: You have now configured a QoS profile.

Task 3: Apply a QoS profile to an adjacency

1. Start up the CLI and use these commands to select the adjacency and get into its call
media policy configuration sub-mode:
config
sbc
signaling
adjacency sip name
call-media-policy
Replace name with the name of the adjacency.

Note: You can also apply a QoS profile to an account, which provides policy settings and limits for
a group of adjacencies; just replace the adjacency command with account name.

2. Use one of these commands to apply a profile to the adjacency, depending on which
packet type it’s for.
• qos sig-profile name
• qos video-profile name
• qos voice-profile name
Replace name with the name of the QoS profile. You can type in the part of the command
before Name and press ? to see a list of available profiles of that type.
Checkpoint: You have now applied a QoS profile to an adjacency.

106 CONFIDENTIAL
 Understand and configure DTMF interworking
Understand and configure DTMF interworking
What is DTMF?
DTMF stands for Dual-tone multi-frequency signaling. Historically, phones signaled button
presses by transmitting audio tones - those are DTMF tones. If you’ve heard those odd sounds
a phone makes when you press the keys during a call, you’ve heard DTMF!
Because IP phones need to work with old-style analog phones, and with devices like telephone
user interfaces (TUIs) that use DTMF tones, they need to support DTMF in some way - although
they obviously have better means of signaling than transmitting audio tones.
There are several different ways for SIP devices to use DTMF tones in a SIP call. Unfortunately,
different devices use different methods of signaling DTMF - and not every device supports
every method! Perimeta can help by switching the tones between different signaling methods
mid-call (interworking between them).

The different ways to signal DTMF in SIP calls

There are four different ways for SIP devices to signal DTMF tones. Two of them use SIP
signaling, and two of them use the media stream.
SIP signaling methods
• SIP INFO messages
• SIP NOTIFY messages
Media methods
• Sending tones in the audio stream, as in a non-IP phone call (we call these inband tones)
• Sending tones in a separate media stream using the RFC 2833 standard

Note: If your devices will be using RFC 2833 for DTMF, you’ll need to make sure that any codec
whitelists you use include the telephone-event codec - that’s the codec for the RFC
2833 streams.

DTMF interworking and Perimeta

If you have to handle calls between devices that don’t support the same method of signaling
DTMF, you can use Perimeta to interwork between the SIP INFO, SIP NOTIFY, and RFC 2833
methods (we’ll get to inband tones in a moment).
For this feature to work, the really important thing is that Perimeta has to know when the
device at one end of a call doesn’t support any of these methods. It can usually detect support
automatically, which is what it always tries to do by default. It’ll then automatically interwork
between methods if one device in a call is using a method Perimeta knows the other device
doesn’t support. So there’s nothing for you to worry about!
Sadly, it’s not always quite that easy, for a couple of reasons:
• Sometimes devices that support SIP INFO for DTMF signaling don’t actually signal their
support for it properly.
• Sometimes you won’t want to use one or more of the methods even when they are
supported - for example, in some scenarios you might want to enforce use of RFC 2833 to
make sure the DTMF tones are in sync with the media stream.
In these cases, you’ll have to set up some configuration on your adjacencies (either directly, or
using an adjacency interop profile to apply the same settings to multiple adjacencies). There
are several settings you can use.

CONFIDENTIAL 107
Understand and configure DTMF interworking

• You can configure Perimeta to assume that the devices on an adjacency support DTMF in
SIP INFO (whether they signal it or not). This gets around devices that support the method
not signaling their support.
• You can disable use of SIP INFO and/or SIP NOTIFY on an adjacency. Perimeta will treat
that adjacency as if endpoints on it didn’t support the disabled method/methods and
interwork to alternatives.
You can also choose which of SIP INFO and SIP NOTIFY Perimeta should prefer on each
adjacency. It’ll use the preferred method for calls where both are supported. By default,
Perimeta prefers SIP NOTIFY.

Inband interworking
Interworking with inband DTMF tones is much harder than with the other methods. Perimeta
has some limited support for it, but there are strict restrictions:
• Perimeta can only detect tones in the audio stream and duplicate them using one of the
other methods. It does not edit the audio stream to remove the tones, and it does not
support adding inband tones to the audio stream.
• Detecting inband DTMF tones is hard work. When it’s enabled for a call, that call will take up
5-6 times as much Perimeta capacity as a normal call, whether or not there are any actual
tones - Perimeta still has to pick through the audio stream looking for them.

Warning! So if you want to use this feature, make sure you have the spare capacity!
• Your Perimeta license has to include the media transcoding feature pack.
There are two situations in which you might want to use interworking for inband tones:
• If you’re using Perimeta’s transcoding option and you’re transcoding away from the high-
quality G.711 audio codec to a lower-quality codec that doesn’t accurately transmit the
tones. Perimeta supports a ‘G.711 transcoding calls only’ version of inband interworking
that you can use in this situation.
• If you’re dealing with a SIP application server or similar device that needs to know about
DTMF but can’t detect inband tones.
You have to explicitly enable this feature on the ISC or MSC that will handle the media, and on
the adjacencies you need to use it with. Because of the potential hit to Perimeta’s performance,
it’s important to make sure nobody turns this on by accident!

Start here
In this section you will learn how to:
• Configure standard DTMF interworking settings.
• Configure inband DTMF interworking.

Task 1: Configure standard DTMF interworking settings

You only need to do this if you expect problems with some devices signaling SIP INFO support,
if you want to disable use of SIP INFO and/or SIP NOTIFY for DTMF on an adjacency, or if you
want Perimeta to prefer one of SIP INFO or SIP NOTIFY when both are supported.
Otherwise, Perimeta’s default settings should be fine.
1. Start up the CLI and use these commands to select the interop mode for the adjacency
you want to configure:
config

108 CONFIDENTIAL
 Understand and configure DTMF interworking
sbc
signaling
adjacency sip name
interop

Replace name with the name of the adjacency.

Note: These steps show you how to configure DTMF settings directly for an adjacency. You can
use an adjacency interop profile instead if you need to apply the same settings to multiple
adjacencies - just select the interop profile instead of the adjacency, and the commands
after this point are exactly the same. If you need to refresh your memory about how to set
up and apply interoperability profiles, take a look back at Configure and apply an adjacency
interoperability profile on page 55.

2. Choose the settings you want to apply from this table to find the commands you should
use:

Setting Command
Assume that any device on this adjacency dtmf sip info always-supported
supports SIP INFO for DTMF, whether it
signals support or not.
Disable use of SIP INFO/NOTIFY for DTMF dtmf disable sip info
on this adjacency. dtmf disable sip notify
Prefer SIP NOTIFY to SIP INFO (this is the dtmf prefer sip notify
default) or vice versa. dtmf prefer sip info
Checkpoint: You have now configured DTMF interworking settings for an adjacency.

Task 2: Configure inband DTMF interworking

Enabling inband DTMF interworking for your ISC/MSC
You have to explicitly enable inband DTMF interworking as part of the media configuration for
any Perimeta MSCs or ISCs that will do it. Turning this setting on won’t do anything by itself -
you need the adjacency configuration as well to actually trigger interworking - but you need to
do it before you can use the feature.
1. Start up the CLI on your ISC/MSC and use these commands to enable inband DTMF
interworking.
config
sbc
media
inband-dtmf
Setting up inband DTMF interworking on your adjacencies
There are two media policy settings Perimeta uses to figure out when it should use inband
interworking.
• The inband-tones-present setting tells Perimeta that devices on an adjacency might
send inband tones.
• The inband-tone-interworking always or inband-tone-interworking
on-transcode settings tell Perimeta that the devices on an adjacency need it to do

CONFIDENTIAL 109
Understand and configure DTMF interworking

interworking for inband tones - either for any call containing the tones, or for transcoding
calls only.
Perimeta will only ever use inband DTMF interworking for calls that go between an adjacency
with the inband-tones-present setting and an adjacency with one of the two inband-
tone-interworking settings.
Here’s a diagram to give you a better idea how inband interworking works, using the all calls
option rather than the transcoding only option. Notice that Perimeta doesn’t add inband tones
to the call when it goes back in the reverse direction!

Here’s how you configure one of these settings for an adjacency:

1. Start up the CLI and use these commands to select the call media policy mode for the
adjacency:
config
sbc
signaling
adjacency sip name
call-media-policy
Replace name with the name of the adjacency.
2. Use the commands for whichever of the media policy settings fits with the devices in your
adjacency:
• inband-tones-present
• inband-tone-interworking always
• inband-tone-interworking on-transcode
Checkpoint: You have now configured inband DTMF interworking.

110 CONFIDENTIAL
 Set up Perimeta’s H.323 support
Set up Perimeta’s H.323 support
What is H.323?
If you don’t already know, you probably don’t need to!
H.323 is a protocol for call signaling, like SIP. It’s fairly outdated now, and most VoIP devices
will use SIP, but you might need to use H.323 to work with some older devices or networks.

Perimeta’s H.323 support

Perimeta is primarily a SIP product, but it does provide limited H.323 support. It only supports
trunks to individual H.323 gateways. You have to use a TCP connection to the gateway’s IP
address; you can’t use UDP or domain names.
To set up the connection to an H.323 gateway, you’ll need an H.323 adjacency, using a
unique IP address/port combination on Perimeta. You need a separate adjacency for each
H.323 gateway.
If calls go between an H.323 adjacency and a SIP adjacency, Perimeta will automatically
interwork between the two types of signaling.

Start here
In this section you will learn how to:
• Configure an H.323 adjacency to an H.323 gateway.
You’ll need to have configured the service interface that the adjacency will use, and configured
the local IP address it’ll use on that service interface. If you need a refresher on service interfaces,
take a look at Add a service interface on page 43. You’ll also need this information to hand.
• The service address name for the local Perimeta IP address (configured on the service
interface).
• The local Perimeta port you’re going to use for this connection.
• The IP address of the H.323 gateway, and the port it’ll use for this connection.

Task 1: Configure an H.323 adjacency

1. Start up the CLI and use these commands to create the adjacency:
config
sbc
signaling
adjacency h323 adjacencyName
Replace adjacencyName with a name for the adjacency.
2. Use this command to select the local IP address, using the service address name:
service-address addressName
Replace addressName with the service address name.

CONFIDENTIAL 111
Set up Perimeta’s H.323 support

Note: Remember, this is the name configured for the local IP address on the service interface
object. If you don’t know it, you can type show config to see all your configuration and look
for the service-interface commands to find the service interface objects. Then look for
the service-address commands indented beneath them to see which IP addresses have
which names.

3. Use this command to set the local port:

signaling-local-port portNumber
Replace portNumber with the local port you want to use.
4. Use this command to set the H.323 gateway IP address:
signaling-peer gateway ipv4 gatewayAddress
Replace gatewayAddress with the gateway IP address. If this is an open adjacency, replace
it with 0.0.0.0 instead.
5. Use this command to set the port used by the H.323 gateway:
signaling-peer-port portNumber
Replace portNumber with the port the gateway uses.
6. If this adjacency has a signaling peer, use this command to turn on traffic forcing:
force-signaling-peer all-requests
7. Type activate to activate the adjacency.
Checkpoint: You have now configured an H.323 adjacency.

112 CONFIDENTIAL
 Control the media codecs used in your network
Control the media codecs used in your network
When SIP devices set up a call, they negotiate which codecs to use for the media streams in
the calls. Because these messages pass through Perimeta, it can manipulate them and help
you control which codecs are used for calls.

Note: A codec is a method of encoding and compressing media. Different codecs provide different
tradeoffs between bandwidth use and media quality.

There are two ways you can control codecs:

• You can limit which codecs can be used for call with a codec whitelist. When a whitelist
applies, Perimeta only allows codecs that are on the list.
• You can stop short of preventing codecs being used, and just put them in order of preference
with a codec preference list.
You can use these features to limit bandwidth use by using lower-bandwidth codecs, or if you
need to use specific codecs for any other reason.
You apply the lists to adjacencies, not Perimeta as a whole, so you can use different lists with
different devices or networks, depending on what’s needed for your deployment.

How it works
Perimeta configuration
First you’ll need to create a codec list object in the CLI. A codec list is just what it sounds like.
You add some number of codecs to the list, and set priorities for them if you plan on using it
as a codec preference list.

Note: Codec lists are also used for a few other features, like transcoding.
To actually use your list, you have to apply it to an adjacency as a codec whitelist or codec
preference list. Once you have, Perimeta will start using it for new calls going through that
adjacency.

Media negotiation
SIP devices negotiate the codecs for a call by including a list of the codecs they support in the
SDP (session description protocol) part of the INVITE messages and responses they send to
set up the call. The codecs are represented by numbered codes.
When messages with SDP pass through adjacencies where you have a codec whitelist and/or
preference list in place, Perimeta manipulates the SDP:
• If there’s a codec whitelist in place, Perimeta checks the SDP for any codecs that aren’t in
the list and strips them out before sending the message on.
• If there’s a codec preference list in place, Perimeta re-orders the codecs in the SDP so that
the codec with the highest priority in your preference list comes first, the codec with the
second-highest priority comes second, and so on.
SIP devices usually give priority to codecs that come first in the SDP - so long as they
support the codec in the first place!

Start here
In this section you will learn how to:
• Configure a codec list.
• Apply your codec list to an adjacency as a codec whitelist or preference list.

CONFIDENTIAL 113
Control the media codecs used in your network

Warning! If you’re planning to use a codec whitelist on an adjacency where the phones use a separate
media stream for DTMF tones, make sure you include the telephone-event codec in your
codec list. No idea what DTMF tones or RFC 2833 are? Read up on them in Understand and
configure DTMF interworking on page 107.

Task 1: Configure a codec list

1. Start up the CLI and use these commands to create the codec list (or select an existing
one):
config
sbc
codec list name
Replace name with a name for the codec list.
2. Use this command to add a codec to the list:
codec-entry codec priority
Replace codec with the name of the codec, omitting any . characters. You must use lower
case! If you use upper-case letters you’ll just receive an error message.

Note: For the G.711 codecs, use pcmu and pcma.

If you’re planning to use this codec list as a preference list, you’ll need to replace priority
with a number. 1 is the highest - Perimeta will always move the priority 1 codec (if present)
to the front of the list in SDP, then the priority 2 codec, and so on. If you don’t plan to use
this list as a preference list, just miss out the priority parameter.
3. Add any more codecs to the list in the same way.
Checkpoint: You have now created a codec list.
Example codec list configuration
Here’s an example codec list, with priorities:
config
sbc
codec-list exampleList
codec-entry g722 2
codec-entry g729 3
codec-entry pcmu 1

Task 2: Apply a codec list to an adjacency

1. Start up the CLI and use these commands to get into the call media policy configuration
mode for your adjacency:
config
sbc
signaling
adjacency sip name
call-media-policy

114 CONFIDENTIAL
 Control the media codecs used in your network
Replace name with the name of your adjacency.
2. Use this command if you want to apply your codec list as a codec whitelist:
codec-list name
Replace name with the name of the codec list.
3. Use this command if you want to apply your codec list as a codec preference list:
codec-preference-list name
Replace name with the name of the codec list.

How it works in practice - examples

Here’s some full example configuration, with a couple of example codec lists - the one with
priorities we already gave you, and one without priorities, so it’s just to be used as a whitelist.
There’re also two adjacencies, one using the first list as a codec preference list and a codec
whitelist, and one using the second as a codec whitelist only.
config
sbc
codec-list priorityNoTE
codec-entry g722 2
codec-entry g729 3
codec-entry pcmu 1
codec-list whiteListOnlyWithTE
codec-entry g722
codec-entry g729
codec-entry pcmu
codec-entry telephone-event
signaling
adjacency sip coreOne
call-media-policy
codec-list priorityNoTE
codec-preference-list priorityNoTE
adjacency sip coreTwo
call-media-policy
codec-list whiteListOnlyWithTE

And here’s a diagram to show you just how this configuration works, with codecs removed by
the whitelists or re-ordered by the preference list.

CONFIDENTIAL 115
Control the media codecs used in your network

Notice that for the coreOne adjacency ‘telephone-event’ gets removed, since it’s not in the
whitelist. That means that RFC2833 streams for DTMF tones will never be possible for calls on
that adjacency, and the phone will have to signal tones using SIP or include them in the audio
stream.

116 CONFIDENTIAL
 Set up media transcoding
Set up media transcoding
In the world of VoIP, media codecs (standards for encoding audio and video) are like languages.
VoIP devices that speak at least one of the same languages can happily talk to each other, but
if they don’t share any, they’re going to need an interpreter. Perimeta can be that interpreter,
using its media transcoding feature to translate between different media codecs - allowing
the devices on either of a call to receive media in a language they understand.

Did you know? Getting translations wrong can be embarrassing. President Jimmy
Carter famously used a sub-par translator on a trip to communist Poland in 1973. When
he spoke of having left America that morning, it was translated as his having 'abandoned'
America, never to return!

To use this feature, your Perimeta license has to include a media-transcoding feature
pack - make sure you check whether your license includes transcoding before trying to use it!

Hardware and software transcoding

Perimeta transcoding comes in two flavours - hardware and software. Hardware transcoding is
only available on specific commercial off-the-shelf (COTS) hardware platforms using dedicated
expansion cards called ‘Digital Signal Processor’ (DSP) cards. Software transcoding just uses
the same hardware resources as the rest of Perimeta’s media handling.
The main difference between hardware and software is just capacity - transcoding is heavy-
duty work, and having dedicated hardware to use for it means Perimeta can do a lot more! But
there are also some differences in which codecs Perimeta can transcode - they’re labelled in
the list of codecs below.
Any one Perimeta ISC or MSC can only use software or hardware transcoding - you can’t use
both on the same system.

Supported codecs
No interpreter can speak every language, and Perimeta is no different. The codecs Perimeta
supports for transcoding vary between the different versions of Perimeta - to check which
codecs your version supports, see the section Media transcoding in the Perimeta Configuration
and Interoperability Guide.
Note: Perimeta can also perform fax transcoding between T.38 and G.711 to allow fax machines
and gateways that speak different protocols to work together. We won’t cover this here,
though. If you want to know more about fax transcoding, see the section Fax transcoding in
the Perimeta Configuration and Interoperability Guide.

How transcoding configuration works

To set up transcoding for your Session Controller, you’ll need to wrap your head around two
key bits of configuration - the transcoding trigger and the transcoding offer list. You’ll
need to configure both of these on your adjacencies before Perimeta will use transcoding.
Both sides of a call need to have these configured on the relevant adjacency for transcoding
to be allowed.
You’ll also need to turn transcoding on in the CLI for each ISC/MSC that’ll be doing it.

CONFIDENTIAL 117
Set up media transcoding

The transcoding offer list

The transcoding offer list is just a list of codecs Perimeta is allowed to transcode to on a
particular adjacency. You don’t need to use a transcoding offer list - if there isn’t one, Perimeta
will be ready to use any of the supported codecs from the list above. You can use an offer list
if you only want to support certain codecs (usually because you want to avoid high-bandwidth
ones).
This setting uses codec list objects in the Perimeta CLI. You use these to configure a list
of codecs for use with various different Perimeta features - you might remember them from
Control the media codecs used in your network on page 113.

The transcoding trigger

The transcoding trigger setting controls exactly when Perimeta will switch a call into transcoding
mode.
Once Perimeta is using transcoding mode for a call leg, it will edit the call request messages
(INVITEs) that are setting up the call. These messages include a list of supported codecs - if
necessary, Perimeta will add to it, giving the device receiving the option of using a codec
that Perimeta will have to transcode (because it wasn’t in the original list of codecs the caller
supported).
Just because a call is in transcoding mode doesn’t mean Perimeta will actually do transcoding!
The callee can still select one of the codecs the caller originally offered. Perimeta will only
transcode when the callee selects one of the codecs Perimeta added, as in this example:

You can see that Perimeta added ‘codec3’ to the offer - this is the point when transcoding
mode has been triggered, causing Perimeta to add an extra codec to the offer. The callee then
selected the extra codec, which means Perimeta will transcode for this call - but if the callee
had selected codec 1 or 2, there would be no need.
So what are the potential transcoding triggers? There are three to choose from . These all apply
when you’ve configured them on the adjacency that connects to the callee - the destination
adjacency for the call.
• retry-on-4xx triggers transcoding mode when Perimeta receives a 415 or 488 error
code from a callee. These codes mean that the callee doesn’t support any codecs in the
offer. If you use this setting, you’ll make sure transcoding mode is only triggered when the
callee doesn’t support any of the caller’s codec. However, it adds some extra SIP traffic,
since Perimeta has to re-send the offer after receiving the error code - if you know most
calls on an adjacency are going to need transcoding anyway, you might as well use one of
the other two trigger settings.
• include-all-of triggers transcoding mode if the original offer from the caller is missing
any of the codecs from the transcoding offer list - so any offer Perimeta sends out on
this adjacency will include all the codecs on the offer list. Obviously you have to have a
transcoding offer list for this setting to work!

118 CONFIDENTIAL
 Set up media transcoding
• always triggers transcoding mode for every call going into the adjacency.

Start here
In this section you will learn how to:
• Enable transcoding on an ISC or MSC.
• Set up a transcoding offer list and transcoding trigger for an adjacency.

Task 1: Enable transcoding on an ISC or MSC

1. Start up the CLI on your ISC/MSC and use these commands to enable transcoding:
config
sbc
media
transcoding
2. Repeat this step for any other ISCs or MSCs in your deployment that will do transcoding.
Checkpoint: You have now enabled transcoding on your ISCs/MSCs.

Task 2: Configure a codec list to use as a transcoding offer list (Optional)

We covered codec lists in Control the media codecs used in your network on page 113, but
here’s a reminder in case you haven’t committed every command to memory.
1. Start up the CLI on your SSC or ISC and use these commands to create the codec list (or
select an existing one):
config
sbc
codec list name
Replace name with a name for the codec list - note this down, you’ll need it in the next task!
2. Use this command to add a codec to the list:
codec-entry codec
Replace codec with the name of the codec, omitting any . characters. You must use lower
case! If you use upper-case letters you’ll just receive an error message.

Note: For the G.711 codecs, use pcmu and pcma.

Task 3: Set the transcoding offer list and transcoding trigger for an adjacency
You need to configure transcoding on the relevant adjacencies for both sides of a call. So if
necessary, repeat the steps in this task for all adjacencies that will be involved in transcoding
calls.
1. Start up the CLI on your SSC or ISC and use these commands to select the transcoding
configuration mode for your adjacency
config
sbc
signaling
adjacency sip name

CONFIDENTIAL 119
Set up media transcoding

call-media-policy
transcoding
Replace name with the name of your adjacency.
2. To set the transcoding offer list (remember, this is optional), use this command:
offer-generation codec-template list
Replace list with the name of the codec list you want to use as your transcoding offer list.
3. To set the transcoding trigger, use one of these three commands (if you need a reminder of
how each trigger works, look back at The transcoding trigger above).
• trigger retry-on-4xx
• trigger include-all-of
• trigger always
Checkpoint: You have now set up transcoding.

120 CONFIDENTIAL
 Set up media bypass
Set up media bypass
What is media bypass?
By now you should be pretty used to the idea that all your VoIP traffic goes through Perimeta
- nothing goes from access networks into your core, or vice versa, without passing under
Perimeta’s watchful eye.
For signaling, that’s just how it is. Perimeta should always be in the signaling path. But for
media, things aren’t always so simple.
Media is different because sometimes there’s no need for it to go from access to core. To see
why, let’s look at how a SIP call from one phone to another works when they’re registered on
the same softswitch, through the same Perimeta Session Controller.
• The caller’s phone makes a SIP call to its registrar, your softswitch - this goes through
Perimeta.
• The softswitch locates the registration record for the called number, which tells it where the
callee phone is - back through Perimeta! It makes a SIP call to that phone. Now there are
two SIP calls, caller -> softswitch and softswitch -> callee, but they’re really just two legs
of the same call.

Note: If you want to get really technical, there are actually four SIP calls. In SIP terms, Perimeta is
a back-to-back user agent (B2BUA), meaning that the call legs on each side of Perimeta are
actually separate SIP calls - but that doesn’t make any difference here, so don’t worry about
it!

Unless the softswitch needs to send the media for the call to a media gateway or other device
for transcoding, lawful interception, etc, it can and usually will ‘release’ the media by telling
the devices at the other end of its two SIP calls to send their media directly to each other’s IP
addresses. However, as far as the softswitch knows, the devices at the other end of its SIP
calls are just the Perimeta core adjacencies - your softswitch always talks to Perimeta, never
directly to the endpoints on the other side. So the media for the calls will actually loop through
Perimeta, like this:

CONFIDENTIAL 121
Set up media bypass

Now, there are a couple of reasons why you might want media for a call to loop through
Perimeta:
• If you want Perimeta to do something with the media, such as transcoding.
• If the two phones can’t reach each other directly (because they’re in different networks that
don’t connect directly or there’s NAT interfering) and you need Perimeta to route the media
between them.
Otherwise, having the media loop through Perimeta is just a waste of network bandwidth and
Perimeta processing power! What you want is for Perimeta to let the two phones just send
media directly to each other. Luckily Perimeta can do just that! We call this feature media
bypass.
Media bypass calls look more like this:

122 CONFIDENTIAL
 Set up media bypass
How does Perimeta know when it can use media bypass?
There are three key conditions that have to be met for Perimeta to use media bypass for a call.

Note: When we say ‘a call’ here, we mean (usually) a pair of SIP calls, one access -> core and one
core -> access, that Perimeta detects are two legs of the same phone-to-phone call. There
can actually be more than two pairs of SIP calls if the call is going through additional SIP
devices.

• Media bypass has to be enabled on all the adjacencies involved in the call (on both core
and access sides). It’s disabled by default - you have to explicitly enable it.
• The caller and callee phones can reach each other (and Perimeta knows it!).
• The call must not require media transcoding, or any other feature that requires Perimeta
having access to the media.
How does Perimeta decide whether two phones can reach other? Like most things with
Perimeta, it comes down to the adjacencies. It also depends on whether the phones are
behind network address traversal NAT. We went over the details of when Perimeta considers a
phone to be behind NAT in Set up NAT traversal on page 67 - it’s either because you configure
a setting on the adjacency to indicate all phones on that adjacency are behind NAT, or because
Perimeta detects that the individual phone is behind NAT.
Here are all the scenarios where Perimeta will consider two phones as being able to reach each
other:

CONFIDENTIAL 123
Set up media bypass

• The two phones are on the same adjacency and neither is behind NAT.
• The two phones are on the same adjacency and both behind the same NAT. To be behind
the same NAT they need to have registered from different ports on the same IP address.
• Neither phone is behind NAT, and the two phones are on different adjacencies, but the
adjacencies share a media bypass tag.

Media bypass tags

Media bypass tags on adjacencies let Perimeta know when two different adjacencies are
connected and phones using one can reach phones using the other.
If an adjacency doesn’t have any media bypass tags, Perimeta will automatically assign it one
based on the service interface it uses. So, by default, Perimeta assumes that all phones (with
no NAT) on the same service interface can reach each other.
If you want to use media bypass and you have adjacencies on the same service interface that
can’t reach each other, or you have adjacencies on different service interfaces that can reach
each other, you’ll have to configure custom media bypass tags. They’re just text strings - what
the text is doesn’t matter, just whether it matches the tags on other adjacencies.
Perimeta lets you configure multiple tags for an adjacency, but unless you’re dealing with very
unusual network layouts, you should only need one on each adjacency - each tag should be
for a group of adjacencies that can all reach each other.

Start here
In this section you will learn how to:
• Enable media bypass for an adjacency.
• Configure a media bypass tag for an adjacency.

Task 1: Enable media bypass for an adjacency

1. Start up the CLI and use these commands to enable media bypass tag for your adjacency
config
sbc
signaling
adjacency sip name
call-media-policy
media-bypass-policy allow
Replace name with the name of your adjacency.
Checkpoint: You have now enabled media bypass for an adjacency.

Task 2: Configure a media bypass tag for an adjacency

Warning! This will overwrite the default media bypass tag, shared with all other adjacencies on the
same service interface that don’t have custom tags. Media bypass will no longer be possible
with any other adjacencies except those that share the tag you configure.

1. Start up the CLI and use these commands to configure a media bypass tag for your
adjacency:

124 CONFIDENTIAL
 Set up media bypass
config
sbc
signaling
adjacency sip name
media-bypass-tags tag
Replace name with the name of your adjacency and tag with your custom media bypass
tag.
Checkpoint: You have now configured a custom media bypass tag for an adjacency.

CONFIDENTIAL 125
 Set up media bypass

126
CONFIDENTIAL
 Understand Perimeta’s redundancy features
Understand Perimeta’s redundancy features
Perimeta has two advanced redundancy features that go beyond the basic primary-backup
pair it uses for a single Session Controller. These features use different Session Controllers as
backups for each other in different ways.
These features have to be licensed and your deployment has to be set up from the start to
use them - you’ll know if they apply to your system. We’re not going to cover them in detail
here - they can be a bit complicated, and they’re irrelevant if your deployment isn’t set up to
use them. If you are using them and need to know all the details and configuration, there’s a
dedicated manual just for these features - the Perimeta Redundancy Solutions Guide.
What we will give you here is a quick summary of what each of the features are, so you know
what’s going on when they’re referred to elsewhere.

MSC emergency standalone

MSC emergency standalone or ESA allows MSCs in a distributed deployment to
automatically take over some basic signaling functions if they lose contact with their SSC -
either because of a problem with the connection or because the SSC is down.
Obviously an MSC that has to handle signaling as well as its normal media can’t provide the
same capacity as it would in normal circumstances with an SSC handling the signaling. ESA is
a best-effort service, but it’s much better than losing service altogether!

Geographic redundancy
Geographic redundancy provides even better protection against disasters than ESA, but it
requires more investment. To use it, you deploy multiple Perimeta SSCs or ISCs in different
locations, and configure them as part of a redundant group. Session Controllers in the same
group share most higher-level configuration - configure an adjacency on one Session Controller
in the group, and you configure it on all of them. That means a phone or device using one
Session Controller can switch over to another if the first goes down, and the second Session
Controller will already have the right configuration and be ready to go.
Because some CLI configuration applies to the whole group and some (like service interfaces
and their IP addresses) applies to the individual Session Controller, systems using geographic
redundancy have two versions of the CLI - ‘global’ and ‘local’. If you’re using this feature,
you’ll need to take a look through the Redundancy Solutions Guide to see which areas of
configuration go in which CLI.

CONFIDENTIAL 127
 Understand Perimeta’s redundancy features

128
CONFIDENTIAL
 Understand Perimeta’s advanced message editing features
Understand Perimeta’s advanced message editing features
SIP, the signaling protocol used for most signaling through Perimeta, can be pretty complicated.
In theory, any SIP device should be able to talk to any other SIP device, all using the same
standards and applying the same requirements. Sadly, reality doesn’t always live up to the
theory, and different SIP devices often struggle to understand each other.
Because all the SIP for calls goes through Perimeta, it’s in the perfect place to help fix these
problems. It can do all sorts of tweaking and editing to manipulate the SIP messages passing
through it and make sure they match what the devices on each side of a call expect. There are
three ways you can use these features.

Adjacency rules
Perimeta has a whole range of pre-set configuration rules designed to fix common problems.
This is the easiest way to use Perimeta’s message editing - there’ll be some specific CLI
commands for you to set on the adjacencies involved, and then Perimeta deals with all the
detailed message editing. But obviously you need to have one of the problems that there’s a
pre-set rule for!
We won’t list all the message editing rules and their commands here, since they’re all specific
to particular interworking problems - you don’t need to learn about them unless your system
needs one. If you do run into problems you think are caused by issues with devices processing
SIP messages, the Perimeta Configuration and Interoperability Guide covers all the different
adjacency rules.

The SIP Message Manipulation Framework (MMF)

When you have a SIP problem that there isn’t a pre-designed rule for, things get a bit trickier.
Perimeta provides a powerful tool, the SIP Message Manipulation Framework or MMF that
lets you define pretty much any rule you can think of for how to edit SIP messages. You create
a profile, which is just a set of editing rules, and apply it to an adjacency to tell Perimeta to
make those edits to messages passing over that adjacency.
To use the MMF, you’ll need to be pretty familiar with the innards of SIP messages, and be
ready to come up with a logical set of rules for the edits you need. Because it’s such a powerful,
flexible tool, the MMF can take some getting to grips with. If you’re ready to jump in, the
Perimeta Advanced Message Editing Guide has all the details, as well as example profiles you
can use and learn from.

CONFIDENTIAL 129
 Understand Perimeta’s advanced message editing features

130
CONFIDENTIAL
 Add a TLS certificate to Perimeta
Add a TLS certificate to Perimeta
What is TLS?
TLS (Transport Layer Security) is a protocol that allows two devices to communicate over
a network securely. That is to say, someone snooping on the traffic wouldn’t be able to make
sense of the content, because the content is encrypted. You’ll also hear a lot of people refer
to the predecessor of TLS, known as SSL (Secure Sockets Layer). Created in the 1990s,
SSL and TLS have become the most common method for encrypted communication over the
internet.

TLS uses security certificates to provide authentication of a network device’s identity. Each
device has a certificate signed by trusted Certificate Authorities (CAs). In a TLS connection,
devices send their certificate to each other and, because those certificates are signed by CAs,
the devices know that they can trust each other.

Note: This is obviously a massive simplification of how TLS authentication works. If you’re
interested in encryption, there are loads of resources on the internet that you can use to learn
more - Wikipedia’s a good start!

How Perimeta uses TLS

Perimeta encrypts its communications using TLS in two scenarios:
1. You can configure an adjacency to encrypt SIP signaling messages using TLS (and to
encrypt media using SRTP) to ensure the whole communication channel is secure. See
TLS Support in the Perimeta Configuration and Interoperability Guide for instructions on
configuring adjacencies to use TLS and SRTP.
2. You will set up encryped communication with MetaView Web, to make sure Perimeta can
only be configured by a trusted MetaView Web server. See Set up Perimeta to be managed
by MetaView Web on page 135 for how to set this up.

TLS certificate configuration overview

The process for setting up security certificates on Perimeta is as follows:
• Generate a certificate request (also known as a Certificate Signing Request)
• Send the request to a Certificate Authority of your choosing
• Receive a signed certificate back from the CA
• Import the signed certificate on Perimeta
• Import the CA’s certificates on Perimeta (we need this so we that we have the whole chain
of trust)
You carry out all of these steps using the CLI.

CONFIDENTIAL 131
Add a TLS certificate to Perimeta

Warning! For security reasons, Perimeta snapshots don’t contain information about certificates. If you
have to restore from a snapshot, you’ll need to set up a new security certificate.

Start here
In this section you will learn how to:
• Generate a certificate request
• Import the signed certificate onto Perimeta
• Import CA certificates onto Perimeta.

Task 1: Generate a certificate request

1. Start up the CLI and use these commands:
config
system
certificate
pending-request
2. Use the commands in the table below to fill in the details of your request.
3. Use the following commands to generate the certificate request.
actions
system
certificate
output-request
The contents of the request will be displayed in the CLI. Copy the contents of the request
into a file that you can send to a CA.
Checkpoint: You have generated a certificate request, and can now send it to a CA to get a
signed certificate.

Task 2: Import the certificate onto Perimeta

Once your CA has sent you a signed security certificate, you need to import the signed security
certificate onto Perimeta.
1. Use the following commands in the CLI:
adctions
system
certificate
input-signed-certificate
2. Follow the prompts on the screen, and paste in your signed security certificate. Note that
the CLI can become unresponsive for a few minutes after you hit paste.
Checkpoint: You have imported your certificate onto Perimeta.

132 CONFIDENTIAL
 Add a TLS certificate to Perimeta
Task 3: Importing the CA’s certificates
In addition to the security certificate for your Perimeta, you need to import the certificate of every
CA in your certificate’s chain up trust, up to and including the root CA’s certificate. For example,
if your certificate was signed by C, whose certificate was signed by B, whose certificate was
signed by the root CA A, then you’ll need to import the certificates of A, B and C.
You can usually find the public certificates of CAs on their websites.
1. Use the following commands in the CLI:
config
system
certificate
ca-public-certificate name
where name is name you choose for the CA certificate.
2. Follow the prompts in the CLI to paste in the CA’s certificate.
3. Repeat the above for each CA certificate you need to import.
Checkpoint: you have imported the necessary CA certificates, and Perimeta can now
communicate using TLS. You may now create an adjacency for secure communication as
described in TLS Support in the Perimeta Configuration and Interoperability Guide. You can
also now follow the steps in the next chapter, Set up Perimeta to be managed by MetaView
Web on page 135.

CONFIDENTIAL 133
 Add a TLS certificate to Perimeta

134
CONFIDENTIAL
 Set up Perimeta to be managed by MetaView Web
Set up Perimeta to be managed by MetaView Web
What is MetaView Web?
MetaView Web is a web-based application used for configuring and provisioning of a number
of Metaswitch network elements, including Perimeta. It provides a user-friendly Graphical User
Interface (GUI) with context-sensitive help, making it ideal for those new to Perimeta.
MetaView Web can be run on either a MetaView Server (MVS) or an Enhanced Application
Server (EAS). You’ll need to know which server in your deployment is running MetaView Web,
as the steps in this chapter differ depending on the answer.
Before you begin, you need to have configured Perimeta with a TLS certificate, as we saw in
Add a TLS certificate to Perimeta on page 131.

What Perimeta configuration can I manage with it?

There are two Perimeta user types in MetaView Web and they can manage different things:
• Perimeta Provisioners can create and manage access adjacencies. The Perimeta
Provisioner’s interface looks like this:

• Perimeta Expert Managers can manage the following more-fundamental Perimeta

configuration objects:
• Service interfaces
• Adjacencies of all types
• Media addresses
• Call policy sets
• Accounts
• Interop profiles
The Perimeta Expert Management interface looks like this:

You choose to set up both of these roles, or just one of them.

CONFIDENTIAL 135
Set up Perimeta to be managed by MetaView Web

Simple routing
When you create an new access or peer adjacency in MetaView Web, you can configure a
feature called simple routing. With simple routing turned on, all new SIP requests to the
adjacency are routed directly to the adjacency you specify in the Routing Adjacency field.
Therefore, with simple routing, you don’t need to make any changes to routing policy!

Coming soon..
In a future edition, this Learn How To guide will be updated to show you how to do common
Perimeta tasks in MetaView Web. Until then, you can find instructions in the special Perimeta
Configuration and Interoperability - MetaView Web Users guide in the Perimeta manual set.

Start here
In this section you will learn how to:
• Obtain the certificate of the MVS or EAS running MetaView Web
• Import the certificate of the server running MetaView Web onto Perimeta
• Enable adjacency management for Perimeta Provisioners in MetaView Web
• Enable management of Perimeta for Expert Managers in MetaView Web
• Add a source adjacency table to the active call policy set to enable simple routing

Task 1: Obtain the certificate of the server running MetaView Web

The steps for this task depend on whether you’re running MetaView Web on MVS or EAS.

If you’re running MetaView Web on MVS

1. On the MVS, open the Craft terminal choose these options:
• Admin
• Manage Certificates
• MetaView Server Certificates
• Display Certificate Details
2. The MVS’s certificate is displayed. Copy the text between the BEGIN CERTIFICATE line
and the END CERTIFICATE line into a text file.

If you’re running MetaView Web on EAS

1. On the EAS, open the Craft terminal choose these options:
• Web configuration
• SSO Certificates / Keystore
• Display Local SDC Public Service Provider Login Certificate
2. The EAS’s certificate is displayed. Copy the text between the BEGIN CERTIFICATE line
and the END CERTIFICATE line into a text file.
Checkpoint: You have now obtained the certificate of the MetaView Web host server.

136 CONFIDENTIAL
 Set up Perimeta to be managed by MetaView Web
Task 2: Import the certificate of the server running MetaView Web onto
Perimeta
1. On Perimeta, start up the CLI and use these commands:
config
system
certificate
mv-certificate name
where name is name you choose for this certificate (e.g. ‘MVSCert’).
2. Follow the prompts to paste in the certificate you copied earlier.
3. Enter the command api rest to enable management of Perimeta using MetaView Web.
Checkpoint: You have now imported the MetaView Web host’s certificate onto Perimeta.

Task 3: Enable adjacency management for Perimeta Provisioners in

MetaView Web
The steps for this task also depend on whether you’re running MetaView Web on MVS or EAS.

If you’re running MetaView Web on MVS

1. Open MetaView Explorer and navigate to the MetaView Server top-level object.
2. Under the MetaView Server object, select the child object MetaView Web.
3. In the MetaView Web at next restart section, add a line to the Perimeta IP address map
field consisting of the name of your Perimeta followed by its virtual management IP address.
For example,
MyPerimeta 127.0.1.2
If you’re setting up the connection to more than one Perimeta pair, you can add each
connection as subsequent lines.

CONFIDENTIAL 137
Set up Perimeta to be managed by MetaView Web

Warning! The following steps will temporarily stop access to the MetaView Server - you should perform
these steps in a maintenance window.

4. Stop the MVS by opening the Craft terminal and choosing these options:
• Admin
• Stop MetaView Server
5. Once the MVS has stopped, start it again by choosing these options:
• Admin
• Start MetaView Server

If you’re running MetaView Web on EAS

1. On the EAS, open the Craft terminal and choose these options:
• Configuration
• Network parameters
• External Servers
• Manage Perimeta Session Controllers configurable via MetaView
Web
• Add a Perimeta Session Controller
2. Follow the prompts and input the name and virtual management IP address of your
Perimeta when asked.
3. Press 0 three times.
4. Select Show Changes and confirm the changes look correct.
5. Select Apply change set and follow the prompts to apply the changes.
Checkpoint: You have now enabled the management of Perimeta by Provisioners in MetaView
Web.

Task 4: Enable management of Perimeta for Perimeta Expert Managers in

MetaView Web
For this task, carry out the same process regardless of whether MetaView Web is running on
MVS or EAS.
1. Open MetaView Explorer on the MetaView Server that will be managing Perimeta.
2. Create a Session Controller Connection object, and enter the virtual management IP of
Perimeta in the IP address field.
3. Set the field Session Controller configuration to Enabled.
4. Click Apply to create the object.

138 CONFIDENTIAL
 Set up Perimeta to be managed by MetaView Web
5. If you have multiple Perimetas running in a geo-redundant group, repeat the above steps
for each Perimeta pair.
Checkpoint: You have now enabled the management of Perimeta by Expert Managers in
MetaView Web.

Task 5: Add a source adjacency table to the active call policy set to enable
simple routing (Optional)
You only need to do this task if you’re planning to use simple routing. For this task, carry out the
same process regardless of whether MetaView Web is running on MVS or EAS.
In order to use simple routing for new adjacencies, your active call policy set must contain a
table with the name SourceAdjacency. If you don’t already have a table of that name, follow
the instructions for configuring routing policy tables in Design and configure routing policy
tables on page 81 to add a blank table called SourceAdjacency to your call policy set.
Checkpoint: You have now enabled the use of simple routing in MetaView Web.

CONFIDENTIAL 139
 Set up Perimeta to be managed by MetaView Web

140
CONFIDENTIAL
 Use the Service Assurance Server (SAS)
Use the Service Assurance Server (SAS)
What is SAS?
The MetaView Service Assurance Server (SAS) is a useful bit of kit. It allows you to:
• collect detailed call traces
• track and store diagnostics
• identify configuration, network and interoperability problems
• determine what issues are affecting your customer’s service.
Perimeta has dedicated support for SAS, which can show you a huge amount of information
about your Perimeta deployment, especially the SIP messages flowing to and from it, and how
Perimeta edits and routes them.

Note: SAS and MetaView are separate products from Perimeta, so your deployment won’t
necessarily include them. If it doesn’t, you’ll have to use other diagnostics like alarms and IP
packet capture.

SAS can run on standalone dedicated hardware, or it can be co-located with your MetaView
Server, if you’ve deployed one. The SAS user interface that looks like this:

Note: For more information on the MetaView Service Assurance Server, consult the MetaView
Service Assurance Server Guide: https://communities.metaswitch.com/docs/DOC-69335.

In recent years, network solutions have become increasingly sophisticated, incorporating more
layers and devices than ever before. SAS has an inherent ability to trace all calls over any
protocol at any time. In this environment, it is therefore an invaluable diagnostic tool. Let’s take
a look.

CONFIDENTIAL 141
Use the Service Assurance Server (SAS)

Start here
In this section you will learn how to:
• configure Perimeta to use SAS
• log in to SAS
• create a Service Assurance Server Administrator account
• identify the types of diagnostics searches you can carry out in SAS
• refine your troubleshooting search.

Task 2: Configure Perimeta to use the Service Assurance Server

Perimeta needs to know that you’re using SAS so it can log and send the information SAS
needs. You can use the CLI to set this up.
• Start up the CLI and use these commands to get into the diagnostics mode.
config sbc diagnostics
• Use this command to activate logging to SAS.
sas remote-address ipv4 SASAddress
Replace SASAddress with the SAS IP address.

Task 3: Log in to the Service Assurance Server

• Substitute the IP address of your Service Assurance Server into the following URL:
http:// <IP address> /serviceassurance/login/login
To gain access to the Service Assurance Server, you will be asked to log in. Enter your Service
Assurance Server login details.

Checkpoint: You have now logged into the Service Assurance Server.

Task 4: Create a SAS Administrator account

1. Log in to your Service Assurance Server.
2. Click Admin.

142 CONFIDENTIAL
 Use the Service Assurance Server (SAS)
3. Click Add user.

4. Fill out your User Details.

5. Click on the drop-down box next to Privilege level and select Admin.

6. Click Add User.

7. Click Logout in the top-right corner of the window.

8. Check you can log back into SAS using your own credentials.
Checkpoint: You have now set up your own SAS Administrator user account.

Task 5: Search for diagnostics in SAS

There are a lot of different searches you can do using SAS. Let’s take a look at the options
available.

CONFIDENTIAL 143
Use the Service Assurance Server (SAS)

Note: For more detailed instructions on using the SAS interface, consult the MetaView Service
Assurance Server Guide: https://communities.metaswitch.com/docs/DOC-69335.

• You can search for a subscriber’s phone number.

On the Number tab, enter the subscriber’s phone number in the Number field and click
Search.

If you are searching for NOTIFY or SUBSCRIBE messages, tick the Show advanced SIP
messages box when performing your search.

• You can specify the time period you would like to search within.
On each tab, there is a Date/Time range box. This allows you to specify the time period
you would like to display diagnostics for.

Choose a time period from the drop-down list or select Custom to specify your own time
window.
• You can search by the error types that the system has generated. This enables you to find
out more details about a particular error.
On each tab, there is an Error box. This allows you to refine the diagnostics search by
specifying an error source and the type of error you would like to search for.

Click on the drop-down lists to specify the error source and type of error.

144 CONFIDENTIAL
 Use the Service Assurance Server (SAS)
• You can search for calling number or called numbers.
On the Number tab, select the Calling/Called Number sub-tab.

Enter a phone number into the Calling number or Called number field and click
Search. This will perform a search for diagnostics relating to the calling number or called
number.
• You can search by SIP address.
Select the SIP URI, Peer IP or SIP Call ID tab, and use the search box to search by SIP
URI, Peer IP address or SIP Call ID.

• You can search by MAC address. This search doesn’t show calls like most of the other
calls do. Instead, it retrieves phone configuration and directory information for the SIP
Provisioning Server.
Select the MAC address tab.

Enter the MAC address in the search box and click Search.
Checkpoint: You are now familiar with the types of diagnostics search you can carry out in SAS.
• You can also import a call trace that you have already saved to your computer.
Click Import.

Click Browse and select the Trace File to import into SAS.

CONFIDENTIAL 145
Use the Service Assurance Server (SAS)

Click Import.

• Finally, once you have identified the diagnostic you want, you can export or print that
particular call record by clicking on Export or Print.

The Export function is essential if you want to pass information to other troubleshooters
or technical support, as providing good diagnostics will help them to troubleshoot the
problem.

Note: The Export and Print options will only be available once you have selected a specific call
record.

Checkpoint: You should now be more familiar with the SAS interface and the types of
diagnostics you can search for.

Task 6: Refine your troubleshooting search

Now that you are familiar with the types of diagnostics searches you can carry out, we will look
at how you can refine these searches to get more information out of them.
Once you have carried out a search in SAS, you will be shown a list of records that match your
search criteria.

• Click View to see a more detailed breakdown of information for each entry.

146 CONFIDENTIAL
 Use the Service Assurance Server (SAS)
You can then see a Summary of the entry, information about the User Experience, a
Detailed Timeline and Call Flow information by clicking on these tabs.

• Click on the Detailed Timeline tab.

This shows the sequence of events that occurred during the course of the call.
You can expand on the information shown for the series of events by clicking on the drop-
down box next to Event Summary and selecting the level of detail you would like to
display.

You can select from:

• High level events - this is the lowest level of detail, but it still covers most of the crucial
information for a call, and you often won’t need anything more for troubleshooting.
• High level events and protocol flows - this adds details of the contents of the
individual SIP message
• Detailed events - this displays further event details, showing each individual step
Perimeta takes in processing the call.
• Engineering level events - this is typically used by Metaswitch personnel and displays
a very detailed list of internal events.
Selecting an event will show more details in the lower panel:

CONFIDENTIAL 147
Use the Service Assurance Server (SAS)

There are a few key events you’ll often want to look at, all of which are visible as high level
events.
• As shown above, the initial ‘calling’ event will show you which adjacency the call arrived
on and whether an interoperability profile is active on that adjacency.
• The ‘routing succeeds’ or ‘routing fails’ event will show you exactly how Perimeta
worked through your routing tables for this call or registration, and which destination
adjacency Perimeta selected (if routing succeeded). This is very useful for seeing if your
routing tables are working as intended!
• The ‘one side of a media stream was latched’ event shows you when Perimeta starts
receiving media for a call and gives the remote address and port the media is coming
from, which Perimeta ‘latches’ to and sends media to.
• The ‘voice quality monitor statistics were determined’ event can show you voice quality
statistics for the call.
• Click on the Call Flow tab.

Here you can see a Call Flow diagram showing the SIP protocol flows for the call.

You can click on an arrow and click on the plus box to see options for an individual
message. Display Details will show you the full contents of the SIP message.

148 CONFIDENTIAL
 Use the Service Assurance Server (SAS)
You can also click on the Cog icon in the top right corner and select Protocols to display
additional protocols such as H.248 in the Call Flow diagram.

• Checkpoint: Now you know how to gain additional information from your Service Assurance
Server diagnostics.

CONFIDENTIAL 149
 Use the Service Assurance Server (SAS)

150
CONFIDENTIAL
 View Perimeta alarms and events
View Perimeta alarms and events
If something goes wrong with your Perimeta system, you need to know about it. That’s why
Perimeta alerts you to alarms and events. Hopefully you’ll never have to deal with any! But in
case you do, here’s what you need to know about them.
• Alarms and events are very similar. The difference is that alarms are ongoing - if you see
an alarm, it means that something is currently wrong, and the alarm will only disappear if
whatever is causing it gets fixed (or, if you’re lucky, just goes away). Events record some
one-off instance of something happening - they appear to let you know that it happened,
and disappear after a certain amount of time, depending on how important the event was
(at least four days).

Warning! This doesn’t mean that events aren’t important - some events can potentially be very serious
(particularly when repeated), such as hard disk read errors.

• You can view alarms and events in the Perimeta CLI using the show alarms command,
or you can use an external client in your management network (such as MetaView Server),
which Perimeta will send alarm information to using the SNMP protocol.
Here’s an example of an alarm as it appears in the Perimeta CLI (the same information is
available to external clients).
CRIT 04-Feb-2014 23:52:22 The “GenericAccess” adjacency has failed
as the listen socket for local address 53.53.53.10 Service Network
ID 0X00000002, with unsecure/secure local port 5060/0, could not
be created. Check for configuration mismatches with the associated
service interface. Once these are rectified, deactivate and reactivate
the adjacency. (ID=80,1)
Helpfully, it tells you what to do to fix it! Wherever possible, alarms will include this type of
information so you know what to do next.

Note: You can also use the alarm ID at the end (80, 1 in this example) to look up the alarm in the
list in the Perimeta Operations and Maintenance Guide, which may provide some additional
information or point you to helpful sections of the Perimeta manuals.

CONFIDENTIAL 151
 View Perimeta alarms and events

152
CONFIDENTIAL
 Configure Perimeta to work with an SNMP client
Configure Perimeta to work with an SNMP client
SNMP is the Simple Network Management Protocol. It’s a common protocol used for
management and diagnostics. Perimeta supports SNMP for diagnostics, letting you use an
external client (or even multiple clients) in your management network to monitor Perimeta in a
couple of different ways:
• Perimeta can send notifications of alarms to SNMP clients. The easiest one to use is
Metaswitch’s MetaView Server, which is already set up to understand Perimeta. If you want
to use another client, you’ll have to customize it with Perimeta MIB files.
• Perimeta can allow external clients to access the statistics it tracks, using SNMP. This
means you can use graphing software like Cacti to keep track of what your Perimeta
system is doing.
For alarm notifications, Perimeta can send either INFORM or TRAP messages. INFORMs
are more reliable, but some older clients might not support them, so try TRAPs if you have
problems with INFORMs.
If you’re sending notifications to a client that isn’t MetaView Server, you’ll have to configure
your client with Perimeta MIB definitions from the Perimeta SDK, which you can get from the
Innovators section of the Metaswitch Communities website at http://communities.metaswitch.
com/community/innovators/sdk.
If you’re using the CH6010 hardware platform, you can also choose to expose hardware alarms
and hardware sensor status to your SNMP client (if you’re using MetaView Server, Perimeta
handles this automatically and you don’t need to worry about it). These use a standard called
the Hardware Platform Interface or HPI, and will probably require some customization work for
your client to interpret them - you’ll find details in the SDK.

Start here
In this section you will learn how to:
• Configure Perimeta to work with an SNMP client, sending alarm notifications and/or
exposing statistics to the client.

Task 1: Configure the SNMP client details in the CLI

1. Start up the CLI and use these commands to create the SNMP client object:
config
sbc
diagnostics
snmp
snmp-client name
client-address ipv4 address
Replace name with a name for this client, and address with its IP address.
2. If you want to allow this client to access Perimeta’s statistics, use this command:
allow-stats-requests
3. If you want Perimeta to send alarm notifications to the client, use these commands:
notifications
general-notifications

CONFIDENTIAL 153
Configure Perimeta to work with an SNMP client

If you’ve had problems using INFORM messages and want to try TRAPs instead, use
general-notifications use-traps instead of just general-notifications.
4. If your client isn’t MetaView Server, you’re using the CH6010 Perimeta hardware platform,
and you want to expose HPI hardware information to the client, use these commands:
notifications
hardware-notifications

Checkpoint: You have now set up Perimeta to work with an external SNMP client.

154 CONFIDENTIAL
 Configure Perimeta to work with a Syslog server
Configure Perimeta to work with a Syslog server
Syslog is a widely-used protocol for communicating log information. You can configure
Perimeta to send a variety of diagnostic information as syslog messages to a remote logging
server in your network. This lets you neatly integrate Perimeta diagnostics with those from
other devices in your network, so you only have to look in one place!
Perimeta can send the following as syslog messages:
• Alarm logs
• Management audit logs
• Customer system and per-adjacency logs (related to configuration or operational events)
You can choose to send any combination of these three sets of diagnostics - by default,
Perimeta sends all of them. You can also choose to exclude logs below a certain severity level.
If you’re using MetaView Server to monitor Perimeta alarms, you can configure the MetaView
Server to send the alarm log diagnostics to the syslog server, along with diagnostics from other
systems it monitors. In this case you should not configure Perimeta to send the alarm logs to
the syslog server but rely on the MetaView Server to do this instead.

Start here
In this section you will learn how to:
• Configure Perimeta to send diagnostics as syslog messages to a remote logging server.
• Optionally, choose exactly which diagnostics to send to the remote logging server.

Task 1: Configure the Syslog server details in the CLI

1. Start up the CLI and use these commands to navigate to the relevant section:
config
sbc
diagnostics
remote-syslog
2. Add the remote syslog server with this command:
server ipv4 address
Replace address with the IP address of the syslog server.

Note: If you want Perimeta to send messages to a port other than the default of 514, you can
specify that here by using the command server ipv4 address port number, replacing
number with the port you want to use.

3. If you want to prevent Perimeta from sending one type of diagnostics, use the relevant
command below:
• exclude-alarms excludes the alarm logs.
• exclude-audits excludes the management audit logs.
• exclude-logs excludes the customer system and adjacency logs
4. If you want to exclude alarm logs below a certain severity level, use the command:
exclude-alarms below level

CONFIDENTIAL 155
Configure Perimeta to work with a Syslog server

Replace level with one of the following levels:

• critical
• major
• minor
• info
5. If you want to exclude customer system and per-adjacency logs below a certain severity
level, use the command:
exclude-logs below level
Replace level with one of the following levels:
• critical
• major
• minor
• info
Checkpoint: You have now set up Perimeta to send diagnostics as syslog to a remote logging
server.

156 CONFIDENTIAL
 Use packet capture and Wireshark to examine Perimeta traffic
Use packet capture and Wireshark to examine Perimeta
traffic
Perimeta provides a packet capture feature, allowing you to record all the contents of some
of the IP packets passing over a Perimeta interface. This can be useful for troubleshooting if
you don’t have a Service Assurance Server, or if you need to inspect the IP headers of packets.
Perimeta can save the capture as a series of .cap files, which you can examine in packet
analysis software - we’ll use Wireshark, a popular open-source program, as our example, but
you can use other software if you prefer.

Note: You can download Wireshark from http://www.wireshark.org

You won’t usually want to capture all the packets on an interface. That’d be a huge strain on
your Session Controller, and would usually give you more information than you could make
sense of! When you set up packet capture, you’ll set some filters to make sure Perimeta only
captures the packets you’re interested in.

Deciding which packets to capture

Before you use packet capture, you’ll need to decide how you’re going to filter the packets you
want to capture. Here’s a list of the different filters you can use (you can use more than one of
these):
• You always have to specify a Perimeta interface to capture packets on. This can be a
physical port (or aggregated port), or it can be a service interface. You’ll need to know the
name of the interface:
• For physical ports, the names are the names used in your port group schemes - RPG1,
• RPGX1, etc. for single ports, bond0, bond1, etc. for aggregated ports.
• For a service interface, the name is the one you used to create it in the CLI - serv1,
serv2, etc. You’ll also need the service network ID number. Remember, you can check
what these settings are in the CLI by using show config.

Note: If you choose a service interface, Perimeta will only capture signaling packets (SIP, H.248,
and H.323), not media or lower-level messages such as ARP probes. That’s usually a good
thing! Media packets aren’t human-readable, so capturing them isn’t normally useful, but
they are big and there are a lot of them - capturing them is likely to put some serious strain
on your Session Controller. If you do need to capture media packets, you’ll need to specify a
physical port.

• You can specify a remote IP address or domain name, so that Perimeta only captures
packets to and from that device.
• You can specify a local IP address, so that Perimeta only captures packets to and from that
local address. This lets you limit your packet capture to a specific adjacency.
• You can specify a port number, so that Perimeta will only capture packets using that port
on either the local or remote IP address (or both).
• You can specify a transport protocol, so that Perimeta will only capture UDP, TCP, or
UDP+TCP packets.

Note: There’s also an option for ESP packets - these are used in IPSec encryption, which you’ll only
be using if you’re using Perimeta in an IMS deployment, with IMS-AKA security. If that sounds
like gibberish, then you don’t need to worry about it!

CONFIDENTIAL 157
Use packet capture and Wireshark to examine Perimeta traffic

• You can specify a number or username for SIP packets, so that Perimeta will only capture
packets sent to or from that number or username. Applying this will automatically filter out
any non-SIP packets.

Warning! Be as specific as possible! The more packets you capture, the more strain the process puts
on your Session Controller - capturing all the packets on an interface can cause a big hit to
performance. You should almost always set at least a filter to a specific remote IP address.

Start here
In this section you will learn how to:
• Use packet capture to record packets on a Perimeta interface.
• Use Wireshark to examine the packets you’ve captured.
You’ll need an SFTP client to download the capture files from Perimeta, such as WinSCP or the
built-in command-line SFTP in a Linux operating system.

Task 1: Identify the port you want to capture packets on (captures including
media packets only)
If you want to capture media packets as well as signaling, you’ll need to specify a physical
port to capture on. Which port you need can depend on which is currently active for a service
interface; port groups often include redundant pairs of ports, with only one active at a time.
Here’s how you can check which port is active, so that you know which to use for the packet
capture.
1. Start up the CLI and use this command:
show system interface serv-if
You’ll see output that looks something like this:
Service interface summary
=========================
Slot Serv-If Active Device
-----------------------------
*1 serv1 RPG1
*1 serv2 RPG3
2 serv1 RPG2
2 serv2 RPG4
The Slot column shows which of the two Perimeta instances in the redundant pair each line
refers to. The lines marked with the \* are for the active instance - they’re the ones you need
to look at. Find the service interface (or interfaces) relevant to the captures you want to run, and
note down the active device, which is the port the interface is currently using.

Note: Instances are processor blades on CH6010 hardware, separate servers on COTS hardware
or a single Virtual Machine.

Task 2: Use packet capture

Warning! Whenever possible, make sure you do this at the least busy time for your Session Controller.
It’ll have less performance impact that way.

158 CONFIDENTIAL
 Use packet capture and Wireshark to examine Perimeta traffic
1. Start up the Craft Terminal and choose these options.
• Diagnostics
• Gather IP
2. You’ll see a prompt asking you to specify a filename. Choose whatever filename you like,
but make sure it ends in .cap.
3. You’ll see a set of prompts asking you to type in the filters you’ve decided to use. For each
one, either type in your filter if you’re using one, or just press Enter to skip to the next one.
4. Either do something to reproduce the problem you’re investigating (for example, try to
make a call), or wait a long enough time to have a good chance of recording the problem
naturally. When you’re finished, press Ctrl+C to stop the capture.
Checkpoint: You have now run a packet capture on a Perimeta interface.

Task 3: Retrieve the capture files using SFTP

1. Use your SFTP client to connect to the management IP address of your Session Controller.
That’s the same IP address you use to access the Craft Terminal - use the same username
and password as well.
2. Change to the /ftp directory and download the files. They’ll all have the filename you
chose when you set up the capture, with numbers added to the end of the file extension to
put them in order - for example, example.cap00, example.cap01, and so on.

Task 4: Examine the files in Wireshark

1. Start up Wireshark and select Open. Navigate to wherever you downloaded the capture
files and open one of them.
2. You’ll now see a display in three parts, looking something like this:

CONFIDENTIAL 159
Use packet capture and Wireshark to examine Perimeta traffic

3. Take a look through the information Wireshark gives you:

• The first section gives you a list of the packets recorded in the file, with timestamps,
source and destination, protocol, and some details of the contents. You can select
packets by clicking on them.
• The second section breaks down the contents of the selected packet. Wireshark can
understand a large number of protocols and give you helpful information; for example,
this section can give you details of the SIP headers in SIP messages You can open up
information on different parts of the packet by clicking on the + icons.
• The third section gives you the actual hex contents of the packet. This isn’t very human
readable - you can ignore it.
4. To make it easier to find the packets you need, you can apply a filter using this bar:

Typing in a protocol name, like sip in this image, and clicking Apply will filter the list of
packets to only include that protocol. You can also use more specific filters on things like
the contents of specific SIP headers - click on Expression to see what’s available.

Note: All the protocol filters use lower case - you can type sip but not SIP.

160 CONFIDENTIAL
 Use packet capture and Wireshark to examine Perimeta traffic
Here’s an example of a filtered list, and how you can display useful information about a SIP
REGISTER message.

CONFIDENTIAL 161
 Use packet capture and Wireshark to examine Perimeta traffic

162
CONFIDENTIAL
 Solve basic Perimeta problems
Solve basic Perimeta problems
We’re going to give you some basic troubleshooting tips for general Perimeta problems. The
world of VoIP is intricate and complicated, and we can’t cover everything that could possibly
go wrong, but these basic steps should get you started on investigating any sort of problems.

Using SAS
If you have a Service Assurance Server, it should be your first port of call for any problem with
calls or registrations through Perimeta. Use the search tabs to search for the number or IP
address of the device you’re having problems with and have a look at:
• whether the INVITE (for a call) or REGISTER (for registrations) arrives at Perimeta in the first
place - if it doesn’t appear in SAS at all, you’ll need to check whether the other device is
set up with the right address for Perimeta
• if the request did arrive, whether there are any errors or suspicious events recorded in the
Call Flow tab that give you a hint as to what the problem is.
Note: We covered setting up SAS to monitor Perimeta in Use the Service Assurance Server (SAS)
on page 141.

Using Ping and Traceroute

It’s often useful to check whether there’s any kind of network connection problem between
Perimeta and a device you’re having trouble with. You can use these tools to quickly figure out
whether that’s the problem:
• Ping sends a very simple message from Perimeta to any IP address you choose, and
checks whether Perimeta gets an answer. If it doesn’t, either something’s wrong with the
device at the other end or there’s a problem with the connection between the two.
• Traceroute is similar to Ping, but it shows you responses from each intermediate step
between Perimeta and the IP address - routers etc. If there is a network problem, this can
help you see exactly where it’s happening.

Management network
You can run Ping and Traceroute on your management network from the Craft Terminal. Just
log in and choose these options:
• Diagnostics
• IP diags
• Ping or Traceroute
You’ll be prompted to type in the IP address (or hostname) you want to test the connection to,
and for various other parameters, such as time-to-live and the packet size - the defaults should
be fine for these, unless your network has any special requirements.

Service networks
To use Ping and Traceroute on your service networks, you’ll need to use the CLI. Start it up and
use these commands to get to the right mode:
actions
system
service-network networkID

CONFIDENTIAL 163
Solve basic Perimeta problems

Replace networkID with the service network ID for the service interface you want to run Ping/
Traceroute on.
Note: If you don’t know the service network ID, run show config and have a look for the
service-network commands in your service interface configuration. Use the descriptions
or local IP addresses to figure out which is the right service interface.

From here, you can use these commands to run Ping and Traceroute:
• ping ipv4 address
• traceroute ipv4 address
Replace address with the IP address you want to check connectivity to.

Note: You can replace ipv4 with ipv6 if you’re using IPv6.

Checking information in the CLI

You can use CLI show commands to see all sorts of useful information; depending on the kind
of problem you’re troubleshooting, you might want to check some of these.
• show alarms is worth checking for almost any problem. Many Perimeta problems that
can affect your service will cause an alarm - loss of contact with a peer, blacklisting of an
IP address, failure of an adjacency, etc. The alarm text will usually give you some guidance
on what to do next as well.
• show system interface failures will show you any problems with Perimeta’s
network interfaces.
• show sbc subscriber filter number will show you details of all registered
phones with a number or username beginning with number. This gives you a quick way of
checking whether a phone has successfully registered through Perimeta.

Command Information
show alarms Shows any current software alarms.
Always worth checking for any kind of
problem.
show system hardware alarms Shows any current alarms for problems
with your Perimeta hardware - for
example, overheating. You can't use this
on a virtual machine - Perimeta won't
have access to information about the
underlying hardware.
show config warnings Shows any problems with invalid CLI
configuration.
show system interface failures Shows any failed network interfaces.
show system interface Shows whether the connectivity test
connectivity mgmt probes on the management network are
succeeding.
show system interface serv-if Shows all your service interfaces and
which physical ports they're currently
using.

164 CONFIDENTIAL
 Solve basic Perimeta problems
show sbc adjacency all Shows the current status of all
adjacencies. Particularly useful for
checking on adjacencies to specific peer
devices.
show system usage-stats Shows current memory and CPU usage,
which can be an indicator of your system
being overloaded. CPU usage over 70%
or Free Memory below 1500MB can
mean that your system is running close
to capacity.
show system service-traffic- Shows a large number of statistics about
stats the signaling and media traffic passing
through Perimeta, including reasons why
packets are being dropped.

CONFIDENTIAL 165
 Solve basic Perimeta problems

166
CONFIDENTIAL
 Investigate blacklisting
Investigate blacklisting
If you see alarms about Perimeta blacklisting sources, you’ll need to look into what’s causing it
- you’ll want to know whether it’s a temporary traffic spike you can safely ignore, over-sensitive
blacklisting rules that you need to change, or a genuine threat that you need to act against.
If you’re feeling unsure about what blacklisting is or how it works, take a look back at Plan and
configure your dynamic blacklisting profiles on page 93.

Start here
In this section you will learn how to:
• Check which sources are currently blacklisted by Perimeta, and at what level.
• Look at detailed information for a specific blacklisted source, to determine the cause of the
blacklisting.
• Take any further actions depending on what is causing the blacklisting.

Task 1: Check which sources are currently blacklisted

1. Start up the CLI and use this command to check which sources are currently blacklisted
(alarmed, downgraded, or banned).
show sbc blacklist all
You’ll see a list that looks something like this.
Banned sources:
No banned endpoints.
Downgraded sources:
No downgraded endpoints.
Alarmed sources:
Level SNet IP Port (type) Current (Max) Rate
----------------------------------------------------------------
Reason: Excess valid messages
Major 2 10.234.13.1 5060 (UDP) 123/hr (234/hr)
Minor 3 142.13.1.3 5060 (UDP) 123/hr (234/hr)
Reason: Authentication failure
Minor 2 10.234.15.2 5061 (TCP) 17/s (345/s)

This list will give you a lot of information. It tells you every single source Perimeta is currently
blacklisting and which blacklisting reason has triggered the blacklisting.

Task 2: Investigate the details of a blacklisted source

You’ll usually want to go a bit further and look at detailed information for a particular source,
using one of these commands (for a service network source, IP source, or port source,
respectively):
• show sbc blacklist source-state service-network service-network
ID verbose

CONFIDENTIAL 167
Investigate blacklisting

• show sbc blacklist source-state address service-network ID ipv4

address verbose
• show sbc blacklist source-state port service-network ID ipv4 address
portType port verbose
Replace ID with the service network ID, address with the IP address, portType with udp or tcp,
and port with the port number - you can find all this information in the output from show sbc
blacklist all.
These commands give you very detailed information on the blacklisting status of a particular
source. It looks like this:
Source is at minor alert due to Excess valid messages.
It reached this state 32 minutes ago.
Currently the events are occurring at 8 /second,
and the maximum since reaching this state is 12 /second.
The following reasons are in less or equally urgent states:
Reason State
--------------------------------------------
Authentication failure Minor alert
TCP abuse Minor alert
If you include verbose, output in the format of the following
example is displayed.
Profile: HPBX100
Reason: Corrupt message
Thresholds:
Blacklisting rate: 10 /second
Downgrade rate: 8 /second
Major alert rate: 7 /second
Minor alert rate: 4 /second
Trigger period: 30 seconds
State:
Alert level: Minor
Time entered: 2011-11-30T17:47:48+0000
Current rate: 5 /second
Max rate since level change: 6 /second
Reason: Authentication failure
Thresholds:
Blacklisting rate: 20 /second
Downgrade rate: None
Major alert rate: None
Minor alert rate: 10 /second

168 CONFIDENTIAL
 Investigate blacklisting
Trigger period: 30 seconds
State:
Alert level: Minor
Time entered: 2011-11-30T17:47:48+0000
Current rate: 11 /second
Max rate since level change: 16 /second
This shows you every blacklisting threshold the source has broken, when it did so, what the
thresholds applied to it are, and so on. This should tell you exactly what’s been going on with
this source.

Further investigations
Depending on the blacklisting reasons you see have breached thresholds, you can look at
some other diagnostics to figure out what’s going on.
• If you have deployed the Metaswitch Service Assurance Server, you can see the messages
that have actually triggered the change in blacklisting level by selecting Session Controller
Error and Blacklisting alert level change.
Be careful - there may not be anything illegitimate about the triggering message, since it’s
just the message that actually pushed the rate over the blacklisting threshold, and normal
messages can count towards many of the blacklisting reasons. For example, multiple
phones configured with the wrong password can cause ‘authentication error’ blacklisting -
but there is an authentication error involved in each normal registration, since registrations
start with an unauthenticated message and the phone only authenticates itself after the
registrar sends an error. So the phone that actually triggers the threshold may have the
correct password, even though the overall problem is caused by phones that don’t.

Note: This search will only find blacklisting events for the authentication failure, bad source address,
capacity limit exceeded, number validation failure, and routing failure blacklisting reasons.
Other blacklisting reasons are not logged by the Service Assurance Server.

• If you don’t have a Service Assurance Server, you can use Perimeta’s packet capture
feature and Wireshark if you want to inspect the messages triggering the blacklisting. Take
a look at Use packet capture and Wireshark to examine Perimeta traffic on page 157 for
instructions - you’ll want to set up your capture using a filter specific to the blacklisted
source.

Checking previous blacklisting events - logs

You might find it useful to look at logs of previous blacklisting events.

Task 3: Take further action (if you need to)

What you should do next depends on what you think the root cause of the problem is:
• If you know there’s a reason for a temporary, unusually large spike in normal traffic and the
blacklisting information you see matches that (i.e. the reasons for blacklisting are excess
messages etc. rather than, say, corrupt messages), you might want to monitor the situation
and see if it subsides.
• If you believe that the devices being blacklisted are sending normal levels of traffic and
shouldn’t be blacklisted, the thresholds in your blacklisting profiles might be too strict.
Check that the thresholds you have seem appropriate, and consider raising them - if you
need a reminder on how the configuration works, look at Plan and configure your dynamic
blacklisting profiles on page 93.

CONFIDENTIAL 169
Investigate blacklisting

• If you have access to the devices being blacklisted and you believe they are incorrectly
configured, fix their configuration and then monitor the situation to see if the blacklisting is
resolved or if it happens again.
• If the excess traffic is from devices you don’t control and you believe it may be due to a
malicious attack, you can set up specific blacklisting profiles to apply to those devices (by
their IP address or IP address and port). Use low ban thresholds and long ban durations to
keep the devices banned, so that Perimeta will efficiently drop their traffic.

Note: If you keep the devices banned in this way, Perimeta will continue to show blacklisting alarms
until the excess traffic stops.

170 CONFIDENTIAL
 View recent logs in the Craft Terminal
View recent logs in the Craft Terminal
Perimeta keeps track of all sorts of information in its log files. These can be worth checking
if you’re struggling to diagnose any problems with your Session Controller. You can browse
through recent log files in the Craft Terminal. There are a few different kinds of log file you can
access:
• System management (configuration logs)
• System (general Session Controller logs)
• Adjacency - these logs cover problems and events relating to specific adjacencies.
• Alarms - these are just logs of Perimeta alarms. You can refer to them if you want to check
the history of alarms after they’ve been resolved.
• Blacklisting - these logs keep track of when Perimeta applies dynamic blacklisting. You can
use them to check when and why Perimeta blacklisted particular sources of traffic.
• Hardware transcoding. These logs only exist if you have a system that does hardware
transcoding using dedicated Digital Signal Processor (DSP) boards - if you don’t, you can
ignore this one.
• Per-call. These are detailed logs on individual calls - Perimeta doesn’t collect them for all
calls, you’ll have to set them up when you want to diagnose specific problems. We’ll cover
these in more detail in Record per-call logs on page 173.

Start here
In this section you will learn how to:
• Use the Craft Terminal to browse through recent log files.

Task 1: View logs

1. Start up the Craft Terminal and choose these options:
• Diagnostics
• View current diagnostics
2. Choose the menu option for the type of logs you want to view.
3. You can use the Page Up and Page Down keys to page through the log file. Press g to
return to the start of the file or Shift + g to move to the end. Press q to stop viewing the
file and return to the menu.

Note: You might have noticed that there’s also a ‘Collect logs’ option. That’s for saving the logs
to Perimeta’s SFTP folders so you can download them as text files, instead of reading them
directly in the Craft Terminal.

CONFIDENTIAL 171
 View recent logs in the Craft Terminal

172
CONFIDENTIAL
 Record per-call logs
Record per-call logs
If you’re having problems with calls (or registrations), it can be helpful to have detailed information
about what happens during a call, letting you pinpoint exactly where the problem is - whether
the call request reaches Perimeta, whether it fails during routing, or after being sent to the
callee, etc. For this kind of information, you can look at per-call logs. Despite the name, these
logs can also cover registrations and other SIP transactions that go through Perimeta.

Warning! If you’ve deployed Metaswitch’s Service Assurance Server alongside Perimeta, you usually
won’t need per-call logs, since SAS will provide you with detailed information on individual
calls.

Keeping logs of this information for every single call would be a big strain on Perimeta, so it
doesn’t create these logs automatically. When you have a problem you want to diagnose, you’ll
need to configure some filters to tell Perimeta to record per-call logs.

Filters
Configuring a filter lets Perimeta know exactly which calls you want it to record logs for - for
example, you could configure a filter on a specific phone number, and Perimeta would record
per-call logs for any calls involving that phone number.
It’s best to use the most specific filter you can, to limit the load on Perimeta - and to keep you
from having to dig through too many walls of text to get to the information you need!
Here are the different things you can set a filter on:
• Phone number.
• SIP URI. Perimeta can match this earlier in call processing than the phone number, so use
this filter whenever you know the URI - the logs will have more information that way.
• Remote IP address. This filter will catch any call between Perimeta and a specific remote IP
address (you’ll also need to specify which service interface the IP address is on, using the
service network ID number). You can use it if you’re having problems with a single device
that represents multiple phones behind the same IP, such as a SIP PBX or a router with
NAT. This filter only works on calls, not registrations or other transactions.
• Adjacency name. This filter will catch any call or other transaction using a particular
adjacency.
• Service network ID. This filter will catch any call on a service interface with a particular
service network ID number.

Warning! Be very careful with adjacency or service network filters. They’ll usually catch a lot of calls,
which can be a big hit on Perimeta’s performance if it’s near full capacity.

Log levels
Once you’ve decided on a filter to apply, you’ll need to choose a log level. Different log levels
include different levels of detail - the more detailed the level you choose, the more information
you’ll get, but the bigger the performance hit. So if you’re using a filter that will match multiple
calls, try using a less detailed log level if you can.
Here are the log levels you can use:
• User experience. This is the least detailed level. It includes logging of basic call information
- call initiated, ringing, answered, on hold, hung up, etc. It also includes any triggering of
dynamic blacklisting thresholds, and voice-quality statistics for each call (such as latency
and jitter).

CONFIDENTIAL 173
Record per-call logs

• High level. This level includes additional information about Perimeta’s processing of a call,
logging routing of the call and media allocation. It includes various potential errors relating
to Perimeta’s call processing - for example, it will include logs when a call is rejected for
breaching a capacity control limit or because routing fails.
• Protocol level. This level includes logs for each individual SIP message sent or received by
Perimeta (that matches your filter).
• Detailed events. This level includes additional, more detailed logging of Perimeta call
processing. The events logged here are less likely to be relevant to troubleshooting than high
level events, but you do need to use this level if you want logs of any message manipulation
Perimeta applies to SIP messages.

Note: More detailed log levels include all the events covered by the less detailed levels - high level
includes all user experience logs, protocol level includes all user experience and high level
logs, and so on.

Start here
In this section you will learn how to:
• Configure a filter to record per-call logs.
• Retrieve the logs.
• Remove the filter once you’ve retrieved the logs.

Warning! You must remember to remove your filter after you’ve got the logs you need - don’t put
unnecessary strain on Perimeta!

You’ll need an SFTP client to retrieve the log files, such as WinSCP or the built-in command line
SFTP in Linux operating systems.

Task 1: Configure a filter

1. Start up the CLI and use these commands to get into the correct mode:
config
sbc
diagnostics
marker-diagnostics
2. Which commands you need to use next depends on which type of filter you’ve decided to
use. We’ll give you each set of commands in turn - just pick the correct one for your filter.
The parameters work the same way in each case, so we’ll explain them after going through
all five sets of filter commands.
For a phone number filter:
number-marker name
number filter
log-level level
For a SIP URI filter:
uri-marker name
uri filter
log-level level

174 CONFIDENTIAL
 Record per-call logs
For a remote IP address filter:
remote-ip-marker name
remote-ip ipv4 filter service-network SNID
log-level level

Note: You can change ipv4 to ipv6 if you’re using IPv6.

For an adjacency filter:
adjacency-marker name
adjacency filter
log-level level
For a service network filter:
service-network-marker name
service-network SNID
log-level level
3. Once you’ve got the right set of commands from the list above, replace name with a name
for your filter, filter with the actual filter (the phone number, URI, IP address or adjacency
name), SNID with the service network ID for an IP or service network filter, and level with
the name of the log level - these are the names the CLI uses for the log levels:
• user-experience
• high-level
• protocol-flow
• detailed-events
4. Make a note of the name you’ve used for your filter - you’ll need it later.
An example filter
Here’s an example. These commands would set up a filter called ‘myFilter’ on the IP address
145.43.2.1 on the service interface with service network ID number 3, using the protocol flow
log level.
config
sbc
diagnostics
marker-diags
remote-ip-marker myFilter
remote-ip ipv4 145.43.2.1 service-network 3
log-level protocol-flow
Checkpoint: You have now configured a filter for per-call logs.

Task 2: Retrieve your per-call logs

Before you do this task, you’ll need to either wait enough time for the calls/registrations you
want logs for to happen naturally, or actively make them happen.
1. Start up the Craft Terminal and choose these options:
• Diagnostics

CONFIDENTIAL 175
Record per-call logs

• Collect logs
• Collect per call logs
2. When prompted, type in the name of your filter - you should have noted this down during
the last task. Confirm the command.
3. The Craft Terminal will give you the directory path it’s stored the log files in - make a note
of it.
4. Use your SFTP client to connect to Perimeta, using the same IP address, username, and
password you use to connect to the Craft Terminal. Navigate to the directory you noted
down and download the ‘.log’ file or files from it.

Note: You can also use the Craft Terminal to view the logs directly, just like you can for other recent
logs. Take a look back at View recent logs in the Craft Terminal on page 171 if you need
instructions.

Task 3: Remove your filter

1. Start up the CLI and use these commands:
config
sbc
diagnostics
marker-diags
2. Use one of these commands, depending on which kind of filter you used:
• no number-marker name
• no uri-marker name
• no remote-ip-marker name
• no adjacency-marker name
• no service-network-marker name
Replace name with the name of your filter.
Checkpoint: You now know how to use - and remove - per-call logging filters.

176 CONFIDENTIAL
 Gather a diagnostics package
Gather a diagnostics package
If you have problems with your system that you can’t figure out using the normal diagnostics,
support might ask you to gather and download a diagnostics package. That’s a zip file
containing lots of detailed, engineering-level logs and statistics.
You can gather a ‘current’ diagnostics package with diagnostics running back to the most
recent restart or crash (or to the last time you gathered a package - doing this resets Perimeta’s
tracking). Or, if you’re investigating a crash or unexpected restart, you can step back in time
and gather a package leading up to the crash/restart.
Gathering a diagnostics package stores it as a zip file that you can download using an SFTP
client like PSCP or the built-in command-line SFTP in a Linux operating system.

Warning! Don’t gather a diagnostics package during busy periods when Perimeta might be overloaded
- it’s heavy work and could make the overload worse!

Start here
In this section you will learn how to:
• Gather a diagnostics package using the Craft Terminal.
• Retrieve the diagnostics package using SFTP.

Task 1: Gather the diagnostics package

1. Start up the Craft Terminal and choose these options to get to the diagnostic packages
menu.
• Diagnostics
• Diagnostic Packages
2. If you’re gathering current diagnostics, select that option. You’ll be prompted to choose
which blade/instance you want diagnostics for. Unless you know that the problem is with a
specific instance, just choose both.
3. If you’re gathering an older package, you need to do a bit more:
• Choose List diagnostic packages.
• Look through the list and find the package you want. Make a note of the three-digit
package number.
• Back at the menu, choose Gather specific diagnostics package. You’ll be
prompted to choose which blade/instance you want diagnostics for. Unless you know
that the problem is with a specific blade/instance, just choose both.
• When the prompt asks you to, type in the three-digit package number you made a note
of.
You’ll need to wait a few minutes while Perimeta gathers the package. When it’s finished,
it’ll tell you the filename, which you’ll need to note down.
Checkpoint: You have now gathered your diagnostics package.

Task 2: Retrieve the diagnostics package using SFTP

1. Use your SFTP client to connect to the management IP address of your Session Controller.
That’s the same IP address you use to access the Craft Terminal - use the same username
and password as well.

CONFIDENTIAL 177
Gather a diagnostics package

2. Change to the /ftp directory and download the file with the filename you noted down after
gathering the package.
Checkpoint: You now know how to gather and retrieve diagnostics packages.

178 CONFIDENTIAL
 Tell us what you think!

Metaswitch is interested to know what you think about this Learn How To Guide. If
you have any feedback, or you spot any inconsistencies while using it, please don’t
hesitate to contact us.

You can send any general comments or report any specific issues to:

[email protected].

Thanks for your time on this; your support will help us to make these guides better
and even more useful for you!

CONFIDENTIAL