Perimeta Network Integration Guide: PMC-008 - Version 4.7.20 - Issue 1-406

CONFIDENTIAL
Perimeta Network Integration Guide
PMC-008 - Version 4.7.20 - Issue 1-406
March 2020
Notices
Copyright © 2000-2020 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.
CONFIDENTIAL Perimeta Network Integration Guide (V4.7.20)
Contents
1 Introduction.............................................................................................................4
2 Perimeta in your network......................................................................................5
2.1 Management network and management interface................................................................6
2.2 Service networks................................................................................................................. 12
2.2.1 Ethernet ports and port groups............................................................................. 12
2.2.2 Port group schemes.............................................................................................. 14
2.2.3 Service networks and service interfaces............................................................... 23
2.2.4 VLAN support........................................................................................................ 27
2.2.5 Off-LAN IP addresses........................................................................................... 30
2.2.6 Latency added by Perimeta for signaling and media............................................ 30
2.2.7 Perimeta and congestion.......................................................................................31
2.3 Network infrastructure......................................................................................................... 34
2.3.1 IP addresses for Perimeta.....................................................................................34
2.3.2 DNS support.......................................................................................................... 35
2.3.3 ENUM support....................................................................................................... 42
2.3.4 Traffic information for firewall configuration...........................................................49
2.3.5 Network bandwidth requirements for Perimeta..................................................... 62
2.3.6 Switch and router configuration for Perimeta........................................................ 65
2.3.7 Traffic prioritization for quality of service...............................................................67
3 Example deployments......................................................................................... 69
3.1 Example Perimeta deployment: integrated signaling and media........................................ 69
3.2 Example Perimeta deployment: distributed signaling and media........................................73
Perimeta Network Integration Guide (V4.7.20) CONFIDENTIAL
1 Introduction
This is the Network Integration Guide for Perimeta, Metaswitch's family of carrier-class Session
Border Controller (SBC) products.
This document contains the information you will need to plan for integrating Perimeta into your
networks, including details of the following.
• The distinct interfaces over which your Session Controller connects to networks carrying
management and service traffic.
• Requirements and options for your Session Controller's Ethernet connections.
• Traffic that needs to pass to and from your Session Controller, including protocols and ports.
• Bandwidth and quality-of-service requirements.
• IP addresses needed for your Perimeta deployment.
The information in this document assumes a basic knowledge of what Perimeta is and does, including
the different Session Controller roles (SSC, MSC, and ISC). See the Introduction to Perimeta section
of the Perimeta Product Description for this information.
4 1 Introduction
2 Perimeta in your network
Details of how Perimeta connects to your network.
Perimeta has two separate sets of network connections that serve distinct purposes.
• A set of Ethernet ports on each instance provide connectivity for service traffic. This is the SIP
signaling and RTP media traffic used in calls, and also the H.248 signaling traffic used by SSCs
to control MSCs in distributed deployments. The number of Ethernet ports in this set depends
on the platform on which Perimeta is running. Traffic on these ports is segregated to distinguish
between service networks. You can configure a particular Ethernet connection (a single port,
an aggregated pair of ports, or a redundant group containing two ports/aggregated ports) as the
connection to a single service network, or you can segregate traffic further by using virtual local
area networks (VLANs) to connect to multiple service networks on a single Ethernet connection.
Service network connections can use IPv6 as well as IPv4, if your license includes the IPv6 feature
pack.
• One or two Ethernet ports provide connectivity to the management network. This is the set
of devices used to manage the Session Controller, such as SSH clients for configuration, NTP
servers, DNS servers, etc. The management network can be IPv4 or IPv6. The number of Ethernet
ports that provide connectivity to the management network depends on the platform on which
Perimeta is running.
Note:
Note that Session Controllers include a backup instance for redundancy. The backup instance will
automatically have its Ethernet connections configured to parallel those of the primary instance.
Your network should provide redundant routes for these connections so that the backup instance
can provide redundancy in case of switch failure.
See the following for more information:
• Ethernet ports and port groups on page 12 and Port group schemes on page 14 for
information on the different ways you can set up the Ethernet ports for service traffic, including
aggregated ports and options for redundancy.
• Service networks and service interfaces on page 23 for details of how Perimeta's connections
to service networks are defined.
• VLAN support on page 27 for information on how you can use VLANs with Perimeta.
• Management network and management interface on page 6 for detailed information on the
management network.
2 Perimeta in your network 5

Network planning considerations

To deploy Perimeta, you must decide how many service networks to use. Different service networks
either connect on different Ethernet ports or are separated by VLANs:
• You need at least two service networks, a protected 'core' network containing your own devices,
and a public-side 'access' network.
• You can add more service networks if you want to segregate traffic from different sources or of
different types (such as signaling and media).
You must also decide how to set up your Session Controller's Ethernet connections by selecting a
port group scheme, based on the following information.
• How many connections to different networks you plan to use.

• How much bandwidth they need; see Network bandwidth requirements for Perimeta on page
62 for help calculating bandwidth requirements. You will need to ensure that your network has
sufficient capacity to provide this bandwidth.
Port group schemes on page 14 explains the different port group schemes available and what you
can use them for.
The combination of the Ethernet scheme and the service networks you need to provide connections to
will determine the network switches you will need and how they need to be connected to the service
traffic Ethernet ports on the Session Controller. For information on how you will need to configure your
switches to work with Perimeta, see Switch and router configuration for Perimeta on page 65.
You may also find the following information useful.
• For information on the IP addresses you will need for your Session Controller, see IP addresses
for Perimeta on page 34.
• For information on which protocols and ports the Session Controller uses with different devices,
which you may need to configure your firewalls appropriately, see Traffic information for firewall
configuration on page 49.
• For information on traffic prioritization for Quality of Service, see Traffic prioritization for quality of
service on page 67.
Example deployments
See Example Perimeta deployment: integrated signaling and media on page 69 and Example
Perimeta deployment: distributed signaling and media on page 73 for example deployments.
2.1 Management network and management interface
You can use devices in the management network to manage your Session Controller, including
configuring your Session Controller, transferring files, and collecting diagnostics. The management
network carries management traffic only. The Session Controller connects to the management
6 2 Perimeta in your network

network over a dedicated management interface. The Session Controller monitors the status of the
management interface and its underlying ports.
Devices in the management network

The management network can provide connections between your Session Controller and the following
devices.
• User terminals used for access to the Craft Terminal, the command line interface, and SFTP file
transfer.
• NTP servers used for synchronizing your Session Controller with Universal Coordinated Time
(UTC).
• DNS servers used for DNS lookups, to resolve domain names into IP addresses.
• Remote file server for storage of billing information and configuration snapshots.
• Optionally, a remote logging server to which the Session Controller can send diagnostics as syslog
messages.
• Optionally, RADIUS servers used for central storage of Craft Terminal user credentials.
• Optionally, the Service Assurance Server.
• Optionally, a MetaView Server or MetaSphere Enhanced Applications Server running MetaView
Web to allow management of the Session Controller through this interface by Perimeta Expert
Management users or Provisioners. For more information, see the MetaView Web Guide. The
MetaView Server may also provide access to MetaView Explorer for the management of Perimeta
Session Controllers. For more information, see the MetaView Explorer User's Guide.
• Optionally, an SNMP agent for collecting diagnostics or statistics using a network management
system, such as MetaView Statistics Engine, MetaView Explorer or ServiceIQ Monitoring (SIMon).
• VPN servers hosted by Metaswitch support, used for remotely retrieving diagnostics information
from your Session Controller. For information on how to set up the connection to the Metaswitch
Support VPNs, see Connecting to Metaswitch Support VPNs in Perimeta Initial Setup Guide
(CH6000 Series Hardware).
Management traffic
The management network and the management interface carry the following types of traffic.
• SSH (Craft Terminal, CLI).

• SFTP (file transfer).
• SNMP (diagnostics output to a network management system).
• ICMP pings (connectivity testing).
• DNS, NTP and Service Assurance Server.
• HTTPS (MetaView Web and / or MetaView Explorer)
• RADIUS (external authentication of Craft Terminal users).
• Syslog.

Configuring management IP addresses

You must use the Craft Terminal to configure the following IP addresses used by the management
interface.
• The virtual management IP address and the fault-tolerant subnet mask you want to use for
your Session Controller. When the Session Controller is operating normally, it uses the virtual
management IP address for all management traffic, including command line interface traffic. You
can also use it for connecting to the Craft Terminal. The virtual management IP address floats
between the instances and is attached to the active instance in a high availability system.
• The IP address for the management network gateway router.
• For high availability systems where each Perimeta instance is running on a processor blade or on
a COTS server or VM with two management ports:
• The virtual management IP addresses you want to use for each of the Perimeta instances. You
can use these IP addresses to connect to the Craft Terminal on one instance only, so you can
collect diagnostics and do troubleshooting configuration independently of the other instance.
These virtual management IP addresses float between the two management ports on each
instance and are attached to the current primary port on each instance.
• The IP addresses you want to use for management ports 1 and 2 on each instance. These will
either be physical ports when an instance is running on a processor blade or COTS server,
or virtual ports when running in a virtualized environment. You can use these IP addresses to
send ICMP pings from your Session Controller's management interface to test the connectivity
of the instances. Note that an instance may only have one management port when running on
COTS hardware or in a virtualized environment.
• For high availability systems where each Perimeta instance is running on a COTS server or VM
with a single management port:
• The management IP addresses you want to use for each of the Perimeta instances. You can
use these IP addresses to connect to the Craft Terminal on one instance only, so you can
collect diagnostics and do troubleshooting configuration independently of the other instance.
• Optionally, any connectivity test IP addresses you want to use to test your Session Controller's
network connectivity. The Session Controller sends ping requests to the connectivity test
addresses to check if it has a reliable network connection. You can configure up to 3 target IP
addresses.
For more information on how to configure the IP addresses used by the management interface, see
Configuring management IP addresses in Perimeta Initial Setup Guide (CH6000 Series Hardware).

Example
Figure 1: Example Session Controller management network with IP addresses (on Metaswitch
CH6010 hardware)
On Metaswitch CH6010 hardware (for information on COTS hardware platforms and virtualized
environments, see the Perimeta Hardware Requirements Guide), you connect your Session Controller
to your management network through two ports on the exterior of the Session Controller, connecting
to two internal switches on the Shelf Manager. Each switch connects to one physical port on each
processor blade, providing redundancy. Although the four ports on the processor blades themselves
are not externally accessible, they do require their own IP addresses, as detailed above.
In this example, the Session Controller is configured to use the following IP addresses.
• The virtual management IP address is 198.2.1.249.

• The virtual management IP address for instance 1 is 198.2.1.251.
• The IP address for port 1 of instance 1 is 198.2.1.255.
• The virtual management IP address for instance 2 is 198.2.1.250.
• The IP address for the management network default gateway is 198.2.253.1.
In addition, you might configure the Session Controller to use the following IP addresses as
connectivity test IP addresses.
• The IP address for the CLI client is 198.2.254.1.

• The IP address for the Service Assurance Server is 198.2.255.1.

IP address conflicts
The Session Controller monitors the management network for IP address conflicts and will defend its
local IP addresses; for more information, see Duplicate IP address detection in Perimeta Operations
and Maintenance Guide.
Management interface requirements

You must design your management network so that it meets the requirements of the Session
Controller's management interface. The management network can use either 1 Gb/sec or 100 Mb/
sec links. No configuration is required on the Session Controller to set the link speed; it is sufficient to
configure your switches appropriately.
Attention:
If your management network includes a Service Assurance Server, 100 Mb/sec links will provide
insufficient capacity for a system load greater than 1800 SIP messages per second. If you are
unsure whether 100 Mb/sec links will be sufficient for your deployment, contact your customer
support representative.
• The Session Controller has two (or four on some COTS hardware and virtualized platforms)
Ethernet ports dedicated to management traffic. You must route all management traffic through
these ports. They must be connected to layer 2 ports that are in the same Ethernet subnet
(broadcast domain/VLAN).
• Traffic between the management ports and the switches connected to them must be untagged.
• There must be no single point of failure between your Session Controller and the default gateway
in your management network. The default gateway must be a redundant device.
• The management interface is not protected against DoS attacks. You must ensure that use a
firewall to protect your management network from public access, except for access from trusted
devices.
• Metaswitch Support can use VPNs to remotely retrieve diagnostic information from your Session
Controller. If you use this, you must provide the VPNs with access to your management network.
If you have deployed MetaView Server (Metaswitch's network management system) and have
existing VPN connections to it, connectivity between the Session Controller and MetaView Server
will be sufficient. Otherwise the Session Controller must be able to connect out to the VPNs over
the internet; for port and protocol details see Traffic information for firewall configuration on page
49.
• The management interface supports both IPv4 and IPv6. You can configure IPv4 management
addresses only, IPv6 management addresses only ("single stack" modes) or both IPv4 and IPv6
management addresses ("dual stack" mode).
When both IPv4 and IPv6 addresses are available for a management function, the Session
Controller will use the IPv4 address.
Note:

When deployed in an OpenStack environment, Perimeta supports DHCP for assigning IPv4
management addresses. It does not support DHCP for assigning IPv6 addresses.
Attention:
If you need to use MetaView Server, the Service Assurance Server, the Perimeta KPI Dashboard
or ServiceIQ Monitoring (SIMon) to monitor a Session Controller, the Session Controller must have
a (virtual) IPv4 management address. These systems do not support IPv6 on the management
network.
Session Controllers with only an IPv6 (virtual) management IP address cannot interoperate with
Session Controllers with only an IPv4 management address (which includes all Session Controllers
running Perimeta V4.1.40 or below).
Management interface monitoring and Ethernet switchover
Management interface monitoring
The Session Controller monitors the status and bandwidth of its ports on the management interface.
By default, the Session Controller considers ports to be live. If the port fails, the bandwidth falls, or
three consecutive probes fail, the Session Controller marks the port as dead. If at any point none of
these conditions apply to a dead port the Session Controller will mark it as live again.
You can configure the Session Controller to send ICMP pings over the management interface to help
monitor the status of the connection on each port to each instance. The default ping interval is 500ms.
For more information on configuring ping requests, see Configuring management IP addresses in
Perimeta Initial Setup Guide (CH6000 Series Hardware).
You can also manually test the connectivity between your Session Controller and the management
network by running ping requests and traceroutes using the Craft Terminal. For more information, see
Checking connectivity on the management network in Perimeta Operations and Maintenance Guide.
Ethernet switchover and software protection switch on high availability systems
If a port used by the management interface is marked as dead, the Session Controller performs
either Ethernet switchover or a software protection switch (SPS) to maintain its connection to the
management network.
• Ethernet switchover turns the backup port on the primary instance into the primary port so
that it takes control of the management interface. Ethernet switchover is only possible when
each Perimeta instance is running on a processor blade or on a COTS server or VM with two
management ports. On these platforms, the Session Controller will perform an Ethernet switchover
if the backup port on the primary instance is still live.
• An SPS turns the backup instance into the primary instance so that it takes control of the
management interface. The Session Controller will perform an SPS if the backup port on the
primary instance is also dead. For more information on software protection switches, see Software
protection switch in Perimeta Operations and Maintenance Guide.

2.2 Service networks
2.2.1 Ethernet ports and port groups
The Session Controller connects to service networks through Ethernet connections. Each service
network is associated with a particular group of Ethernet ports that provide the connection to that
network.
In the majority of cases, your Session Controller's connection to service networks (networks
carrying signaling and media traffic) is provided by a set of 1 Gb/sec Ethernet ports (six on standard
Metaswitch CH6010 hardware). If necessary for your deployment, you can use the ports for 100
Mb/sec links; for information on how to do this, see Setting the Ethernet link speed in Perimeta
Operations and Maintenance Guide. 100 Mb/sec links limit the capacity of your deployment to the
level of approximately 800 concurrent G.711 media streams. If you are unsure whether 100 Mb/sec
links will be sufficient for your deployment, contact your customer support representative.
Some COTS hardware platforms provide support for 10Gb/sec Ethernet ports. For more information
on these platforms, see the Perimeta Hardware Requirements Guide.
Each service network is associated with a port group through which it connects to the Session
Controller.
Ports
On Metaswitch CH6010 hardware, the Session Controller has six physical Ethernet ports on the Rear
Transition Module (RTM) of each processor blade that are used for service traffic. On commercial off-
the-shelf (COTS) hardware, the Session Controller has two, four, six, or eight physical ports. Pairs of
physical ports can be configured as aggregated ports. These are treated as a single port (with double
the bandwidth of a single physical port) for the purposes of connecting to service networks.
On virtualized platforms, the ports referenced in the port groups are the virtual ports as seen by
the guest, which will usually be SR-IOV virtual functions. Aggregated ports are not supported on
virtualized platforms. If you need to provide redundancy for links without an SPS, you must ensure
that the virtual functions used to form a redundant pair of links are on different physical ports.
The service Ethernet ports have fixed names. On the RE6310 RTM, the six copper Ethernet ports
are named RPG1 to RPG6. On the RE6344 RTM, the four optical Ethernet ports are named RPGX1 to
RPGX4, and the two usable copper Ethernet ports are named RPG1 and RPG2 (RPG3 and RPG4 are
also present but not used).
Aggregated ports are named bond0, bond1, and so on.
Note:
Aggregated port means the same as bonded port.

Aggregation protocols
By default, Perimeta uses static aggregation.
If you want to use LACP (link aggregation control protocol) on Metaswitch CH6010 or COTS
hardware, you can configure Perimeta to use either fast (LACP messages every second) or slow
(LACP messages every 30 seconds) LACP using the Craft Terminal. See Configuring LACP in
Perimeta Operations and Maintenance Guide for more information.
Link failure
If one Ethernet link in an aggregated pair fails, the Session Controller takes the following actions.
1. If there is a viable redundant link in the port group (see Port groups on page 13), it uses the
redundant link.
2. Otherwise, in a high availability system where the platform on which the backup instance is running
has all links available, it carries out a software protection switch (SPS) to the backup instance.
3. Otherwise, if it uses LACP, it uses the working link in the pair. It restricts traffic over this link to half
the original capacity of the aggregated link.
4. Otherwise, if it uses static aggregation, it tries to send traffic evenly over both links and drops 50%
of the traffic.
Port groups
On Metaswitch CH6010 hardware and commercial off-the-shelf (COTS) hardware, each port group
consists of either a pair of physical ports, a pair of aggregated ports, a single physical port, or a single
aggregated port. Port groups are sometimes referred to as redundant port groups (RPGs). These
terms have the same meaning.
On virtualized platforms, each port group consists of either a pair of virtual ports or a single virtual
port.
If a port group consists of a pair of (single or aggregated) ports, redundancy for failed connections
is possible without switching to the backup instance. For more information on service Ethernet
switchover, see Service networks and service interfaces on page 23.
Each service interface is configured with the name of a port group over which the Session Controller
will send and receive traffic for that service interface. For more information on service networks and
service interfaces, see Service networks and service interfaces on page 23.
Port group schemes
You configure port groups and aggregate ports on your Session Controller by using the Craft Terminal
to select a port group scheme. The scheme determines how many aggregated ports and single ports
there are, and how they are arranged into port groups. After selecting a scheme, you can specify
a name for each port group. For information on the available port group schemes, see Port group
schemes on page 14. For information on how to select schemes and name port groups, see
Configuring or viewing port groups in Perimeta Initial Setup Guide (CH6000 Series Hardware).

Requirements for local area networks
The following requirements apply to LANs connected to the service Ethernet ports on the Session
Controller, and must be taken into account when planning your deployment.
• To ensure that 99.999% reliability is achievable, a suitable redundancy scheme must be present
within the LAN. Wherever possible plan for a completely redundant path from each port on the
Session Controller to the gateways and other essential devices.
• On a high availability system, the ports on the platform on which the primary and backup instances
are running are configured so that each port used by the backup instance corresponds to a port
used by the primary instance and takes over its function (acting as part of the same port group,
associated with the same service interfaces) if an SPS occurs. You must link corresponding ports
for the two instances to different switches, to prevent the switch acting as a single point of failure.
• If you intend to use VLAN tags to segregate traffic, or to distinguish between different service
networks using the same local network, you must set aside specific tags or ranges for this
purpose, and configure network devices appropriately. For more information on these uses of
VLAN tags, see VLAN support on page 27.
2.2.2 Port group schemes
The port group scheme for your Session Controller determines how service Ethernet ports are
grouped for aggregation and/or redundancy.
The Ethernet ports your Session Controller uses for service traffic can be aggregated to provide
double speed links, and organized into port groups for redundancy. For more information on
aggregated ports and port groups, see Ethernet ports and port groups on page 12. You can
choose from various port group schemes that provide different combinations of aggregation and
redundancy, depending on the platform you are using. Choose the appropriate section for your
platform.
• Metaswitch CH6010 hardware on page 15

• Commercial off-the-shelf (COTS) hardware - two ports on page 18
• Commercial off-the-shelf (COTS) hardware - four ports on page 18
• Commercial off-the-shelf (COTS) hardware - six ports on page 19
• Commercial off-the-shelf (COTS) hardware - eight ports on page 19
• Perimeta in a virtualized environment - two virtual ports on page 21
• Perimeta in a virtualized environment - four virtual ports on page 21
• Perimeta in a virtualized environment - six virtual ports on page 22
• Perimeta in a virtualized environment - eight virtual ports on page 22
Note:
On Metaswitch CH6010 hardware and COTS hardware, Perimeta supports 100 Mb/s, 1Gb/s or
10Gb/s speeds for individual Ethernet links (10Gb/s is only supported on some COTS hardware

platforms). For information on how to set the link speed, see Setting the Ethernet link speed in
Perimeta Operations and Maintenance Guide.
For information on how to select a scheme for your Session Controller, see Configuring or viewing
port groups in Perimeta Initial Setup Guide (CH6000 Series Hardware).
Metaswitch CH6010 hardware
There are six port group schemes available on the standard Metaswitch Perimeta hardware, as shown
in the following diagram. The details of each scheme and example use cases follow the diagram.
Figure 2: Port group schemes for Metaswitch CH6010 hardware
The same schemes are available on the RE6310 and RE6344 Rear Transition Modules (RTMs),
with RPXG1-RPXG4 (the optical Ethernet ports) on the RE6344 corresponding to RPG1-RPG4 on the
RE6310. The RPG1 and RPG2 copper Ethernet ports on the RE6344 correspond to RPG5 and RPG6
on the RE6310. Both versions of each scheme are given below.
Note:
The RE6344 has an additional two copper Ethernet ports, RPG3 and RPG4. Perimeta does not use
these ports.

Six 1Gb/s links without on-instance redundancy
This scheme does not provide any aggregated ports or on-server link redundancy. Each port provides
a separate 1Gb/s link.
Aggregated ports
There are no aggregated ports in this scheme.
Port groups
There is a single port group for each usable Ethernet port on the RTM, containing just that port.
Example use
This is a flexible scheme and could be used in a deployment that requires a complex set of physical
links. It can also be used when only a single spare port is available on network switches. It provides
six normal links, but redundancy requires an SPS.
Three 1Gb/s links with on-instance redundancy
This scheme provides six 1Gb/s links in three redundant pairs. It provides lower total bandwidth than
three 2Gb/s aggregated links (2Gb/s compared to 4Gb/s) but adds full on-server link redundancy.
Aggregated ports
There are no aggregated ports in this scheme.
Port groups
There are three port groups.
• One contains RPG1 and RPG2 (RE6310) or RPGX1 and RPGX2 (RE6344) as a redundant pair.
• One contains RPG3 and RPG4 (RE6310) or RPGX3 and RPGX4 (RE6344) as a redundant pair.
• One contains RPG5 and RPG6 (RE6310) or RPG1 and RPG2 (RE6344) as a redundant pair.
Example use
This scheme could be used for a Session Controller that does not require double speed links for
media (particularly an SSC).
Three 2Gb/s aggregated links without on-instance redundancy
This scheme provides three 2Gb/s links. It does not provide any on-server link redundancy.
Aggregated ports
• RPG1 and RPG2 (RE6310) or RPGX1 and RPGX2 (RE6344) are aggregated as bond0.
• RPG5 and RPG6 (RE6310) or RPG1 and RPG2 (RE6344) are aggregated as bond2.
Port groups
• One contains bond0.


Example use
This scheme could be used for an MSC in a deployment in which double speed links are required
for media. It provides three of these links, but requires a software protection switch (SPS) to provide
redundancy in case of a connection failure.
Two 2Gb/s aggregated links and two 1Gb/s links, both without on-instance redundancy
This scheme provides two 2Gb/s links and two 1Gb/s links. It does not provide any on-server link
redundancy.
Aggregated ports
Port groups
There are four port groups.

• One contains RPG5 (RE6310) or RPG1 (RE6344).
• One contains RPG6 (RE6310) or RPG2 (RE6344).
Example use
This scheme could be used for an ISC in a deployment that uses separate physical links for signaling
and media. It provides two double speed links (for media throughput between core service networks
and access service networks) and two normal speed links (for signaling throughput between core
service networks and access service networks). Redundancy requires an SPS.
Two 2Gb/s aggregated links without on-instance redundancy and 1Gb/s link with on-instance
redundancy
This scheme provides two 2Gb/s links and one 1Gb/s link. There is on-server link redundancy for the
1Gb/s link, but not for the 2Gb/s links.
Aggregated ports
Port groups

Example use

This scheme could be used for MSCs in a distributed deployment in which H.248 traffic between the
MSC or MSCs and their controlling SSC is physically separated from media traffic. It provides two
double speed links (for media) and one normal speed link (for the H.248 connection to the controlling
SSC). Redundancy without an SPS is provided for the normal speed link but not for the double speed
links.
One 2Gb/s aggregated link and one 1Gb/s link, both with on-instance redundancy
This scheme provides one 2Gb/s link and one 1Gb/s link with on-server link redundancy.
Aggregated ports
Port groups
There are two port groups.
• One contains bond0 and bond1 as a redundant pair.

Example use
This scheme could be used in a deployment in which a high proportion of traffic passes directly
between access service networks without passing through core service networks. It provides one
double speed link and one single speed link. Redundancy without an SPS is provided for both links.
Commercial off-the-shelf (COTS) hardware - two ports
COTS hardware platforms with two service Ethernet ports can use the following schemes.
Two 1Gb/s or 10Gb/s links without on-instance redundancy
a separate 1Gb/s link or 10Gb/s link, depending on the COTS hardware platform and NICs used.
Aggregated ports
There are no aggregated ports.
Port groups
Each single port is in its own port group.
Commercial off-the-shelf (COTS) hardware - four ports
COTS hardware platforms with four service Ethernet ports can use the following schemes.
Four 1Gb/s or 10Gb/s links without on-instance redundancy
a separate 1Gb/s or 10Gb/s link.
Aggregated ports

Port groups
Two 1Gb/s or 10Gb/s links with on-instance redundancy
This scheme provides four 1Gb/s or 10Gb/s links in two redundant pairs. It provides lower total
bandwidth than two 2Gb/s or 20Gb/s aggregated links or four 1Gb/s or 10Gb/s links (2Gb/s or 20Gb/s
compared to 4Gb/s or 4Gb/s) but adds full on-server link redundancy.
Aggregated ports
Port groups
• One contains RPG1 and RPG2.

Two 2Gb/s or 20Gb/s aggregated links without on-instance redundancy
This scheme provides two 2Gb/s or 20Gb/s links (typically one for the core side and one for the
access side). It does not provide any on-server link redundancy.
Aggregated ports
• RPG1 and RPG2 are aggregated as bond0.

Port groups

Commercial off-the-shelf (COTS) hardware - six ports
The port group schemes for COTS hardware platforms with six service Ethernet ports are identical to
the schemes for Metaswitch CH6010 hardware, described above in Metaswitch CH6010 hardware on
page 15.
Commercial off-the-shelf (COTS) hardware - eight ports
COTS hardware platforms with eight service Ethernet ports can use the following schemes.
Eight 1Gb/s link without on-instance redundancy
a separate 1Gb/s link.
Aggregated ports

Port groups
Four 1Gb/s links with on-instance redundancy
This scheme does not provide any aggregated ports, but does provide full on-server link redundancy;
the 8 1Gb/s links are sorted into 4 redundant pairs.
Aggregated ports
Port groups

Four 2Gb/s aggregated links without on-instance redundancy
This scheme provides four distinct 2Gb/s links. It does not provide any on-server link redundancy.
Aggregated ports

Port groups

Two 2Gb/s aggregated links with on-instance redundancy
This scheme provides four 2Gb/s links in two redundant pairs. It provides lower total bandwidth than
two 4Gb/s aggregated links or four 2Gb/s aggregated links (4Gb/s compared to 8Gb/s) but adds full
on-server link redundancy.
Aggregated ports



Port groups
• One contains bond0 and bond1.

• One contains bond2 and bond3.
Two 4Gb/s aggregated links without on-instance redundancy
This scheme provides two 4Gb/s links (typically one for the core side and one for the access side). It
does not provide any on-server link redundancy.
Aggregated ports
• RPG1, RPG2, RPG3 and RPG4 are aggregated as bond0.

• RPG5, RPG6, RPG7, and RPG8 are aggregated as bond1.
Port groups

Perimeta in a virtualized environment - two virtual ports
Virtual machines with two virtual service Ethernet ports can use the following schemes. Note that
aggregated ports are not supported when Perimeta is operating in a virtualized environment.
Two links without on-instance redundancy
This scheme does not provide any on-VM link redundancy. Each port provides a separate link.
Port groups
Perimeta in a virtualized environment - four virtual ports
Virtual machines with four virtual service Ethernet ports can use the following schemes. Note that
Four links without on-instance redundancy
Port groups
Two links with on-instance redundancy
This scheme provides four links in two redundant pairs.

Port groups

Perimeta in a virtualized environment - six virtual ports
Virtual machines with six virtual service Ethernet ports can use the following schemes. Note that
Six links without on-instance redundancy
Port groups
Three links with on-instance redundancy
This scheme provides six links in three redundant pairs.
Port groups

Perimeta in a virtualized environment - eight virtual ports
Virtual machines with eight virtual service Ethernet ports can use the following schemes. Note that
Eight links without on-instance redundancy
Port groups
Four links with on-instance redundancy
This scheme provides 8 links in four redundant pairs.
Port groups


2.2.3 Service networks and service interfaces
Service networks carry signaling and media traffic. A Perimeta Session Controller connects to service
networks over service interfaces. The Session Controller monitors the status of service interfaces and
their underlying ports.
Service networks
A service network is an IP network connected to a Session Controller that carries service traffic.
Service traffic is signaling or media traffic (such as SIP or RTP) supported by the Session Controller.
An endpoint that makes a call through the Session Controller will connect to it over a service network,
as will any other devices that send and receive signaling or media traffic to and from the Session
Controller, such as a softswitch or media gateway. The following are examples of service networks.
• A private customer WAN (wide-area network) containing Communications over IP devices.

• Your own networks containing service-critical devices such as softswitches, media gateways, etc.
• The public internet, which would be a completely untrusted service network. For more information
on trust, see Security and trust in Perimeta Configuration and Interoperability Guide - CLI Users.
Service interface
A Session Controller connects to each service network over a service interface. A service interface
is a configuration object that represents how the Session Controller connects to the corresponding
service network. Service interfaces can be associated with VLAN tags so that the Session Controller
can distinguish between traffic to and from different service networks on the same physical port, and,
through local networks configured on redundant pairs of ports, allow the Session Controller to have
redundant connections to service networks in case of connectivity failures. The Session Controller
views all incoming and outgoing media and signaling traffic as travelling over a specific service
interface.
Service interfaces have the following configurable properties. For information on configuring a service
interface, see Configuring service interfaces in Perimeta Configuration and Interoperability Guide - CLI
Users.
• A name of the form servN, where N is a positive integer.

• A description.
• A service network ID representing the service network the interface is used to connect to. This
is a positive integer and must be the same integer used in the service interface's name. The
service network ID is used to apply configuration for the appropriate service network to the service
interface. Each service interface must have a unique service network ID.
• The name of the port group associated with this service interface (this determines which Ethernet
port on the Session Controller will be used for this interface). For more information on port groups,
see Ethernet ports and port groups on page 12.

• A VLAN tag that will distinguish traffic passing over the service interface from traffic passing over
other service interfaces on the same port group (this can be set to '0' for untagged traffic). Each
service interface associated with a given port group must have a unique VLAN tag. For more
information, see VLAN support on page 27.
• The method the Session Controller will use to make DNS queries for outgoing requests on the
service network associated with the service interface (unless adjacency or Rf configuration
overrides this setting). Your Session Controller can do one of the following.
• Make requests to DNS servers in the management network. This is the default behavior.
• Make requests to DNS servers in the service network associated with the service interface. You
can configure the Session Controller to send requests from a specific service address or from
an unspecified address (not recommended). You must also configure the service interface with
the details of between 1 and 16 DNS servers in this network.
• Make requests to between 1 and 16 DNS servers in the service network associated with
another service interface. You must configure the service interface to make requests from a
specific service address on the other service interface and configure the other service interface
with the details of between 1 and 16 DNS servers in this network.
• A Maximum Transmission Unit (MTU) that determines the largest frame payload that this service
interface can commit. You will only specify an MTU for a service interface if it will be used to
connect to a network which requires components to send Ethernet frames with a shorter payload
than the maximum of 1,500 bytes allowed by Ethernet at the network layer. Otherwise, the service
interface will inherit its MTU from the port group with which it is associated, up to a maximum of
1,500 bytes.
Note:
Perimeta does not support jumbo frames and you cannot configure an MTU greater than 1,500
bytes.
• For either or both of IPv4 and IPv6 (IPv6 requires a license with the IPv6 feature pack):
• The IP address of a default gateway. If there is no default gateway (because all devices in the
service network are in the same subnet as the local IP addresses), this must be set to the first
address in the subnet, and you must also configure an explicit ARP/NDP probe target (see
Configuring service interfaces in Perimeta Configuration and Interoperability Guide - CLI Users
for details).
• An IP address prefix length giving the length of the subnet that forms the implicit route
destination.
• One or more local IP addresses, each with a service address name, used to refer to the
address in other areas of configuration. Local IP addresses are normally configured as part of
the subnet, and there must be at least one local IP address configured as part of the subnet.
• There may be some rare circumstances which mean you need to configure a local IP address
that is not part of the subnet. On these occasions you can, optionally, configure an off-LAN
IP address. You should refer to Off-LAN IP addresses on page 30 if you are considering
configuring a local IP address that is not part of the subnet.

Note:
If you are using Perimeta's geographic redundancy feature, you must use matching service
address names for corresponding local addresses on different Session Controllers. Addresses
that support the same adjacencies on different ISCs/SSCs must have the same service address
name on each Session Controller. For more information, see Geographic redundancy in Perimeta
Product Description.
• A setting indicating whether the interface is trusted, untrusted, untrusted-priority or restricted.

For more information on these concepts, see Security and trust in Perimeta Configuration and
Interoperability Guide - CLI Users.
• A criticality setting indicating how important to your deployment the service interface is. The
Session Controller uses this in determining whether to do a software protection switch to allow
Ethernet switchover. For more information, see Service Ethernet switchover on page 26.
• If the interface is untrusted, untrusted-priority or restricted, a setting indicating whether the Session
Controller must block incoming ICMP echo requests received on the service interface. ICMP echo
requests can be used by attackers as a probing mechanism to look for vulnerabilities. We do not
expect any vulnerabilities in Perimeta to be exposed using this method, but blocking ICMP echo
requests on a service interface removes any risk.
Attention:
The Session Controller will always send ICMP responses to ICMP echo requests received from an
unrestricted source, even if ICMP echo requests are blocked on the service interface on which the
requests were received.
• Various settings for ARP/NDP probes, used to check the status of the service interface. For
a full list of these settings, see Configuring service interfaces in Perimeta Configuration and
IP address conflicts
The Session Controller monitors service interfaces for IP address conflicts and will defend its local
IP addresses; for more information, see Duplicate IP address detection in Perimeta Operations and
Maintenance Guide.
Service interface monitoring and service Ethernet switchover
Service interface monitoring
The Session Controller monitors the physical status and bandwidth of its ports. The Session Controller
can also be configured to send ARP/NDP probes over individual service interfaces to monitor the
status of the connection.
For information on configuring ARP/NDP probes, see Configuring service interfaces in Perimeta
Configuration and Interoperability Guide - CLI Users.

By default, the Session Controller considers ports to be live. If the physical port fails, the bandwidth
falls, or three consecutive probes fail, the Session Controller marks the port as dead. If at any point
none of these conditions apply to a dead port the Session Controller will mark it as live again. Whether
a port is marked as live or dead is specific to a service interface: three consecutive probes failing will
only cause the port to be marked as dead for the interface over which the probes were sent.
You can monitor the status of service interfaces using the CLI. For information on how to do this, see
Checking connectivity on a service network in Perimeta Configuration and Interoperability Guide - CLI
Users.
Service Ethernet switchover
If the port which a service interface uses is connected is marked as dead, the Session Controller can
perform one of two varieties of Ethernet switchover to maintain its connection to the service network.
Ethernet switchover is the reassignment of the IP address and MAC address of the service interface
to a new port.
If the port group associated with the service interface consists of a pair of ports on the local Session
Controller and the redundant port is still live, the Session Controller can perform an Ethernet
switchover by switching the service interface to use the redundant port. It does this without carrying
out without a software protection switch (SPS), in which the backup system takes over the service.
Note:
You can check which ports are being used by which service interfaces using the CLI; see Viewing
the active ports for service interfaces in Perimeta Operations and Maintenance Guide for details.
If you have a high availability system and the port group either only consists of a single port or if
the redundant port is also dead, the Session Controller might carry out an SPS, so that the backup
instance takes over the service. It does so if the sum of the criticality values for all the service
interfaces which are live on the backup instance is greater than the sum of the criticality values for
all the service interfaces which are live on the primary instance. For more information on software
protection switches, see Software protection switch in Perimeta Operations and Maintenance Guide.
Following an Ethernet switchover, the Session Controller sends out broadcast gratuitous ARP replies
and multiple unicast gratuitous ARP replies to the default gateway to make other devices on the
network aware of the switchover. In the case of an SPS, in which many service interfaces will change
state, these replies are staggered to avoid overloading the network.
Best effort service
If the configured port for a service interface is dead and Ethernet switchover is not performed, the
Session Controller will provide best effort service by attempting to continue sending and receiving
traffic on the underlying port that was most recently live.

2.2.4 VLAN support
Virtual Local Area Networks (VLANs) allow you to segregate packets of service traffic that pass to
and from the same physical port on your Session Controller. You can configure the Session Controller
to treat traffic with different VLAN tags as travelling over a different service network; the Session
Controller will determine the service network over which a packet arrives by the combination of the
physical port and VLAN tag. Similarly, the service network over which it sends a packet will determine
the VLAN tag the Session Controller sets on the packet, and the physical port the Session Controller
sends it from.
When running on CH6000 Series or COTS hardware or when running in a virtualized environment
without SR-IOV, Perimeta supports up to 4095 VLANs per Session Controller. For information on
how to configure a VLAN tag for a service interface, see Configuring service interfaces in Perimeta
Attention:
Using a very large number of VLANs may reduce the top-level capacity of your Session Controller,
depending on the details of your deployment. If you plan to use a large number of VLANs, consult
your Metaswitch Support representative about the impact on capacity.
When running on virtual machines, Perimeta supports up to 1024 VLANs per low capacity Session
Controller and 4095 VLANs per high capacity Session Controller in the following circumstances.
• It uses standard vSwitches (instead of SR-IOV or PCI passthrough) in a VMware environment.

• It uses Cisco NICs using the enic driver (for example, VIC 1340) for SR-IOV or PCI passthrough in
a OpenStack environment.
• It uses virtio NICs in an OpenStack environment. You must use orchestration to enable support for
VLANs (as described in Template format in Perimeta Automated Orchestration Guide (OpenStack
environments)) in addition to carrying out the configuration described below.
You must configure your hypervisor to allow Perimeta virtual machines to set VLAN tags on packets.
For more information, see your hypervisor's documentation. Once you have done this, you can
configure VLAN tagging directly on Perimeta, as described in Configuring service interfaces in
Perimeta Configuration and Interoperability Guide - CLI Users.
In any other virtualized deployment, Perimeta will not be able to set VLAN tags on packets. It is
still possible to configure the hypervisor to set VLAN tags on packets on a per interface basis. This
means that the number of VLANs that the Session Controller can support is limited by the number of
interfaces available to each virtual machine.
To use VLAN tags on any platform, you must also configure the VLANs on the routers in your
networks and enable VLAN trunking on your access switches. For more details, see Switch and router
configuration for Perimeta on page 65.

Uses of VLANs
Core service networks
You may wish to segregate signaling and media traffic and send them over different core service
networks (i.e. distinct VLANs within your main network), in order to make the different kinds of
traffic more easily manageable, or to improve security or reliability. The Session Controller can be
configured to send signaling and media over separate service interfaces, each with a different VLAN
tag, thereby separating the different kinds of traffic.
Access service networks
One primary use of VLAN tags is to distinguish between packets of service traffic from different
access service networks that arrive on the same physical port. The diagram below shows an example
of this use.

Figure 3: Example deployment scenario with segregated traffic
In this example, traffic arrives at the gateway from three different customer networks, over IPSec
tunnels. The gateway is configured to bridge each tunnel onto the corresponding VLAN (by tagging
incoming traffic and routing outgoing traffic based on its tag). Packets from all three customer
networks arrive at the same physical port on the Session Controller, which distinguishes between
them by checking their VLAN tag.
The diagram also shows separate VLANs for signaling and media in the service provider network.

2.2.5 Off-LAN IP addresses
The off-lan tag can be used to add an IP address to a service interface when the IP address is
outside of the subnet range.
Normally, local IP addresses cannot be added to the service interface unless they are on the subnet
(as defined by the gateway IP address and subnet prefix). However, a service interface can be
configured with an IP address outside of the subnet by adding the off-lan tag to the local-ip-
address command. For example:
local-ip-address IPAddress off-lan
IPv4 and IPv6 off-LAN IP addresses can be used by Perimeta for SIP signaling and media if desired.
However, you must configure your routers to route traffic for off-LAN IP addresses to Perimeta. See
Switch and router configuration for Perimeta on page 65 for more details.
Note:
The local-ip-address IPAddress off-lan command replaces the cluster-ip-address

IPAddress command. Configuration saved prior to the V3.7.20 release therefore cannot be cut and
pasted into the V3.7.20 CLI if it contains any cluster-ip-address entries.
2.2.6 Latency added by Perimeta for signaling and media
Sample measurements of latency added by Perimeta Session Controllers.
These sample measurements were taken on the following platforms:
• A commercial-off-the-shelf (COTS) Dell PowerEdge R640 running as an ISC, with two 8-core
CPUs with 3.2GHz clock speed and 10GbE network interface controllers (NICs). For more
information on this platform, see the Hardware Guide and performance and capacity data at
https://communities.metaswitch.com/community/support/kb/perimeta/perimeta_on_cots_hardware.
• A medium-capacity OpenStack Session Controller running as an ISC and an SSC, with 8 vCPUs
per instance. For more information on this platform, see the tables for Perimeta in VM resource
specification tables in the Metaswitch Products OpenStack Deployment Design Guide.
Both these platforms use DPDK for efficient media processing.
Signaling latency (per message)
Signaling latency is measured as the round-trip-time (RTT) between sending the INVITE from the
caller and receiving a 200 OK response. The latency for a single message, given below, is half of the
RTT minus latency introduced by the network.
Platform Average latency (per message)
Dell PowerEdge R640 ISC 2ms

Platform Average latency (per message)
OpenStack SSC 3.5ms
OpenStack ISC 3.5ms
Media latency
The following table gives the latency added by Perimeta for each media packet.
Platform Average latency Maximum latency
Dell PowerEdge R640 ISC 0.07ms 1.5ms
With SRTP interworking: 0.4ms With SRTP interworking: 8ms
OpenStack ISC 0.05ms 1.5ms
2.2.7 Perimeta and congestion
A Perimeta Session Controller experiences congestion when it cannot process all incoming out-
of-dialog SIP requests within 400ms. To reduce the disruption to end users caused by this form of
overload, a Session Controller prioritizes existing calls over new calls.
When traffic reaches your core network, your Session Controller immediately filters out traffic that
may harm your network and prioritizes incoming packets and messages based on their properties, as
described in Initial prioritization of incoming packets and messages on page 32.
Your Session Controller then prioritizes valid SIP messages as follows.
• In-dialog requests and responses destined for your network are processed immediately.
• Out-of-dialog messages are prioritized and placed on a congestion queue before further
processing. For more information, see SIP congestion queues on page 32.
If your Session Controller is operating within its rated load, the Session Controller should be able to
process all SIP messages within 400ms of receiving them.
Note:
Spikes in incoming traffic are unavoidable in SIP networks and are the typical causes of congestion
in a session border controller. These spikes could be caused by predictable events (for example,
television phone-ins) or unpredictable (for example, a power outage leading to many re-
registrations).
The Secure Distribution Engine (SDE) does not support prioritization if it becomes overloaded. If
you have deployed your Session Controllers with the SDE, calls dropped due to SDE overload will
not reach them to be prioritized.

Initial prioritization of incoming packets and messages
Your Session Controller analyzes incoming traffic to protect your network against malicious traffic and
overload. Its methods for this include:
• Rejecting traffic that does not come from a valid source IP address or is not targeted at a valid
destination.
• Capacity control limits and blacklisting. For more information, see Blacklisting and Capacity control
in Perimeta Configuration and Interoperability Guide - CLI Users.
• Categorizing packets based on their content and source, and rejecting lower-priority packets
when the Session Controller is experiencing heavy load. For example, SIP traffic from a registered
endpoint will never be rejected in favor of connectivity probe ICMP packets from an unknown
source (unless dynamic blacklisting has downgraded the registered endpoint). For more
information, see Traffic priority levels in Perimeta Configuration and Interoperability Guide - CLI
Users.
Perimeta also always prioritizes SUBSCRIBE messages for registered endpoints over new
registrations. This can reduce overall traffic, because a failing subscription will often cause an
endpoint to attempt to re-register.
SIP congestion queues
Congestion queues contain all valid SIP out-of-dialog messages. In-dialog messages are not placed
on congestion queues, because the Session Controller processes them immediately.
A Session Controller has multiple congestion queues, each with a priority between 0 (lowest priority)
and 15 (highest priority). Your Session Controller uses the following rules to assign a priority to a
message and place the message on the corresponding queue. If multiple rules apply, the Session
Controller assigns the highest priority from those rules.
• Incoming requests have a default priority of zero.

• If an INVITE has one or more Priority or Resource-Priority headers, it receives the highest priority
from those headers. By default, this applies only to INVITEs received on core-type adjacencies.
You can enable this for other adjacencies, as described in Categorizing calls as emergency or
high-priority calls in Perimeta Configuration and Interoperability Guide - CLI Users.
• If your Session Controller has priority categories that are applied by matching numbers or
usernames in the Request-URI of an INVITE, the INVITE receives the priority configured for the
category and matching criteria. For more information on this feature, see Emergency calls and
high-priority calls in Perimeta Configuration and Interoperability Guide - CLI Users.
• If the request was received on an authenticated TCP connection (that is, a REGISTER has been
received, passed through and accepted by your core network), the priority is one.
After processing all in-dialog messages, your Session Controller processes the messages on the
highest-priority congestion queue in the order in which it placed them on the queue. When that queue
is empty, the Session Controller processes the next highest-priority queue, and so on.

Occasionally, during periods of high load, your Session Controller may not be able to process a
message on a congestion queue within 400ms of placing on the queue and will reject it instead. This
is congestion.
During congestion, your Session Controller will:
• Raise a The inbound call queue is congested alarm.
Note:
Your Session Controller might, depending on its scale, have multiple sets of congestion queues
that can experience congestion independently. It will raise one alarm for each set that is
experiencing congestion.
• Continue to prioritize existing calls over new calls by handling in-dialog requests and responses
before INVITEs for new calls or other out-of-dialog requests on the congestion queues. This
ensures that calls already being processed by the network core continue to work and avoids
subscriber redials.
• Handle as many messages on the congestion queues that have not been queued for more than
400ms as possible after handling in-dialog requests and responses. This allows your Session
Controller to continue processing calls at its rated load.
• Reject requests that have been queued for longer than 400ms with a 503 Service Unavailable
message. The 503 message includes a Retry-After header with a value of 2-10 seconds. This
spreads re-transmissions by endpoints out, reducing the incoming rate of traffic and allowing the
congestion to clear.
Congestion in a geographically redundant deployment
In a geographically redundant deployment, you should ensure that each Session Controller can
handle the traffic that it normally receives and the traffic that other Session Controllers normally
receive. Otherwise, the failure of one site may cause congestion in the other Session Controller(s),
especially if you have an Active:Active model. When a site fails, all subscribers using that site will fall
back to another site, which can cause a high number of registrations and new calls, depending on
how endpoints are configured to handle 503 errors.
Diagnosing and troubleshooting congestion
To diagnose and troubleshoot congestion, take the following steps.
1. Check the statistics for incoming packets and calls and the number of active calls. For a short
list of statistics you can use to monitor load on your Session Controller and the commands to
view them in the CLI, see Monitoring load on your Session Controller in Perimeta Operations and
Maintenance Guide. You can also monitor these statistics over SNMP, using the SNMP names
given in Statistics monitored by Perimeta in Perimeta Operations and Maintenance Guide.
2. Compare the values of these statistics against the rated (maximum) load for your Session
Controller. If the values are more than 50% of the rated load, this may indicate congestion,
because the statistics collection interval (by default, 5 minutes) can conceal sudden spikes in
traffic.

Note:
Some Perimeta features reduce the maximum load that your Session Controller can handle (for
example, each call that is being recorded counts as 1.5 calls). You must take account of the
impact of these features when comparing the statistics you collect against the rated load. For
information on the impact of each feature, see the documentation for the feature or contact your
support representative.
3. Gather a diagnostics package as soon as possible after you experience congestion and send it
to your support representative. For instructions, see Retrieving diagnostics packages in Perimeta
Operations and Maintenance Guide.
4. If the congestion is happening regularly, carry out a packet capture and analyze the packets to
check for a spike in the amount of traffic. If possible, carry out the capture on another network
element (for example, on a switch connecting to your Session Controller) instead of on your
Session Controller itself.
5. Check the traffic profile and determine whether you can reduce any of the traffic. For example,
your softswitch or application servers may be sending SUBSCRIBE or NOTIFY messages for
subscribers that cannot use some of your call services.
2.3 Network infrastructure
2.3.1 IP addresses for Perimeta
Details of the various IP addresses you will need for Perimeta.
Management network
You will need to assign the following seven IP addresses to each Session Controller for use on its
management interfaces.
• The main management address for the Session Controller. This is taken on by whichever instance
is currently the primary, and used for the majority of management traffic.
• A management address for each of the two instances. This is used to access an instance when
it is acting as the backup (typically only required for diagnostics), and is used by the instance to
establish outbound connections.
• A unique address for each of the four management ports (two for each instance). The Session
Controller uses these to send ICMP pings from each port, allowing it to monitor connectivity for
individual ports.
Service networks
There is no fixed number of IP addresses that Perimeta uses on service networks. Each service
interface (the configuration object that governs the Session Controller's connection to a service
network) can be configured with multiple local IP addresses. Local IP addresses can be configured

on each of one IPv4 subnet and one IPv6 subnet, or as off-LAN IP addresses (outside of the subnet).
For more information on off-LAN IP addresses, see Off-LAN IP addresses on page 30. At least one
address in the subnet (either IPv4 or IPv6) must be configured on each service interface.
In some cases additional addresses will be required if you enable ARP/NDP probing to monitor the
connectivity of the service interface. On an IPv4 subnet, you will usually configure the probes to use
either the subnet IP address or an all-zero address as the source address; in this case, you will not
need additional addresses. However, if your network devices do not support this or you want to use
probes on an IPv6 subnet, you will need to assign additional addresses to use as sources for the
probes. If the service interface uses a port group with redundant ports, you will need four additional
addresses (one for each port on each instance); if it uses a port group without redundant ports, you
will need two additional addresses. For more information on port groups, see Ethernet ports and port
groups on page 12.
Note:
IPv6 for service networks requires a license with the IPv6 feature pack.
You can configure different service interfaces to use the same local IP addresses. The Session
Controller distinguishes between service networks by the combination of the physical port traffic
arrives on and its VLAN tag. Typically you would assign at least one IP address to each port group on
a Session Controller, so that service traffic can be effectively routed to the correct port; the number
of port groups depends on which of the configuration schemes in Port group schemes on page 14
you decide to use.
IP defense
The Session Controller monitors service interfaces and the management network for IP address
conflicts and will defend its local IP addresses; for more information, see Duplicate IP address
detection in Perimeta Operations and Maintenance Guide.
2.3.2 DNS support
You can configure Perimeta to query domain name system (DNS) servers to resolve domain names
to IP addresses. Perimeta can use A/AAAA, SRV, and NAPTR DNS lookups; a Session Controller
license including the advanced routing feature pack is required for SRV and NAPTR lookups.
Perimeta supports DNS queries over TCP and UDP. Perimeta will use UDP in normal circumstances,
falling back to TCP for large DNS responses. It is not possible to configure Perimeta to use either TCP
or UDP exclusively. Perimeta supports 100 entries per DNS record, with a maximum of 10,000 entries
across all DNS records.
You can configure your Perimeta Session Controller to query DNS servers located in the management
network. For configuration instructions, see Managing DNS Servers in Perimeta Initial Setup Guide
(CH6000 Series Hardware).

You can also configure your Perimeta Session Controller to connect to DNS servers located in
any of the service networks to which your Perimeta Session Controller connects. You will carry out
this configuration using the dns-servers command as part of creating the service interface over
which your Perimeta Session Controller will connect to the relevant service network, as described in
Configuring service interfaces in Perimeta Configuration and Interoperability Guide - CLI Users.
When you have done this, you can configure service interfaces or individual adjacencies and
CDFs (for Rf charging) on a service interface to use the DNS servers on a specific service network
(referenced by a service address) or on the management network when resolving an FQDN.
For service interfaces, the default behavior is to send queries over the management network.
You can send queries over a service network instead (either the one to which the service interface
connects or a different one) by specifying a service address as the source of queries with the
dns-source command described in Configuring service interfaces in Perimeta Configuration and
Interoperability Guide - CLI Users.. If you do this:
• The Session Controller will send requests from this address to the DNS servers configured on the
service interface on which the service address is configured.
• If the service interface has more than one DNS server, the Session Controller also uses its DNS
server selection method (see DNS server selection on page 39) to choose between them.
Note:
In versions of Perimeta earlier than V4.5, configuring a service interface with the dns-servers
command also configured the Session Controller to send DNS requests on that service interface
to the specified DNS servers. From Perimeta V4.5, you must set a service address as the source
of queries or use the legacy setting for dns-source. The legacy setting is not recommended
because you cannot specify the address that the Session Controller uses for queries.
Service interfaces created in earlier versions of Perimeta use the legacy setting when upgraded
to Perimeta V4.5 or above.
For adjacencies, the default behavior is to use the configuration of the service interface that the
Session Controller uses to connect to the remote device. You can override this by:
• Specifying a service address as the source of queries. The Session Controller will send requests
from this address to the DNS servers in the service network corresponding to the service interface
on which the service address is configured. This can be a different service network to the one used
by the Session Controller to connect to the Rx peer or the remote devices on the adjacency or
service interface.
If the service interface has more than one DNS server, the Session Controller also uses its DNS
server selection method (see DNS server selection on page 39) to choose between them.
• Specifying the management network as the source of queries.
For instructions on changing the DNS servers used by an adjacency, see Configuring a SIP adjacency
in Perimeta Configuration and Interoperability Guide - CLI Users.

For CDFs for Rf charging, the DNS servers that the Session Controller will use to resolve an FQDN
to retrieve CDF addresses depends on your configuration.
• If the Session Controller uses PCFA headers to retrieve CDF addresses and you have configured
the Session Controller to query DNS servers in the same service network over which it will connect
to the CDF(s), the Session Controller will query these DNS servers when resolving an FQDN.
Otherwise, the Session Controller will use the DNS servers in the management network.
• If the Session Controller retrieves CDF addresses from static configuration, the default behavior is
to use the configuration of the service interface that the Session Controller uses to connect to the
remote device. You can override this by:
• Specifying a service address as the source of queries. The Session Controller will send
requests from this address to the DNS servers in the service network corresponding to the
service interface on which the service address is configured. This can be a different service
network to the one used by the Session Controller to connect to the Rx peer or the remote
devices on the adjacency or service interface.
If the service interface has more than one DNS server, the Session Controller also uses its
DNS server selection method (see DNS server selection on page 39) to choose between
them.
• Specifying the management network as the source of queries.
For instructions on changing the DNS servers used by a CDF, see Enabling Rf charging in Perimeta
Operations and Maintenance Guide.
Note:
The following always use the management network.
• ENUM queries.
• Queries on H.323 adjacencies.
• Queries for a RADIUS server.
• Queries for api.push.apple.com when using the Apple Push Notification Service.
DNS lookups
If you have the advanced routing feature pack, you can configure which level of lookups your Session
Controller will use; A/AAAA only, SRV and A/AAAA, or NAPTR, SRV and A/AAAA (only A/AAAA is
supported without the advanced routing feature pack).
The Session Controller will perform lookups in the following order: NAPTR, SRV, A/AAAA. It performs
SRV lookups on the result of a NAPTR lookup if present, or on the original domain name (if it is not
configured to use NAPTR or if there were no results for the NAPTR query). Similarly, it will perform A/
AAAA lookups on the result of an SRV lookup or on the original domain name.
When Perimeta uses SRV lookups, it will load-balance between equal-priority records. For information
on how Perimeta performs SRV load-balancing, see SRV load-balancing in Perimeta Configuration
and Interoperability Guide - CLI Users.

For information on how to configure which level of lookups the Session Controller uses, see
Configuring which level of Domain Name System lookups the Session Controller uses in Perimeta
Initial Setup Guide (CH6000 Series Hardware).
Note:
If you want to change the level of lookups for DNS-configured peer groups, you must use peer
group configuration instead of the configuration in Configuring which level of Domain Name System
lookups the Session Controller uses in Perimeta Initial Setup Guide (CH6000 Series Hardware).
You can choose between using all three levels or using SRV and A/AAAA only. For instructions,
see Configuring a peer group in Perimeta Configuration and Interoperability Guide - CLI Users.
Example
The following is an example set of DNS records (one NAPTR record, two SRV records and two A
records corresponding to the SRV records) for the domain name ex.am.test.
ex.am.test. 30 NAPTR 0 0 "s" "SIP+D2U" ""
_sip._udp.ex.am.test.
_sip._udp.ex.am.test. 30 SRV 1 0 5060 server1.am.test.
_sip._udp.ex.am.test. 30 SRV 2 0 5060 server2.am.test.
server1.am.test. 86400 A 10.249.22.1
server2.am.test. 86400 A 10.249.25.23
Assuming that the Session Controller is configured to use all levels of lookups, it will perform
a NAPTR query on ex.am.test first, retrieving the two SRV records. It will then perform an
A/AAAA query on the domain name from the SRV record with the lowest priority value (1),
server1.am.test, resolving the domain name to the IP address 10.249.22.1.
If the Session Controller cannot contact the IP address for any reason, it can use the alternative,
lower-priority SRV record; this kind of DNS configuration can be used to provide backup connection
details for a device.
DNS hunting
If the Session Controller fails to contact the IP address to which the highest priority record resolves,
the Session Controller will hunt to the next highest priority record and attempt to contact the IP
address to which this record resolves. By default, Perimeta will attempt to hunt to a maximum of 6
records for the same domain name before dropping the request.
You can choose to change this limit for a particular adjacency. For example, you may choose to
increase this limit on adjacencies that will handle requests for domain names which resolve to several
instances of the same component for load balancing purposes. For more information, see Configuring
the DNS hunting limit for an adjacency in Perimeta Configuration and Interoperability Guide - CLI
Users.
CNAME records
A Canonical Name (CNAME) record indicates that the domain name queried is an alias for a
canonical domain name. Perimeta handles DNS responses containing CNAME records as follows.

• If the CNAME record is not the only record in the DNS response, Perimeta will ignore the CNAME
record and begin carrying out lookups for the other records.
• If the CNAME record is the only record in the DNS response, Perimeta will send another query to
the DNS server on the CNAME target indicated in the CNAME record.
Attention:
It is possible to form a chain by referring to one CNAME record from another CNAME record
(although this is not recommended in RFC 1034). Perimeta will send a maximum of 20 queries
to a DNS server for a single CNAME record chain. You must ensure that your DNS servers are
configured to prevent chains that require more queries than this maximum.
NS records
A Name Server (NS) record refers a query to another DNS server that is authoritative for a particular
zone. Perimeta does not support the use of NS records. If Perimeta receives a DNS response
containing an NS record, it will ignore this response. If there are other DNS servers left to query, it will
resend the original query to these servers according to the chosen selection method, as described
in DNS server selection on page 39. If there are no other DNS servers left to query, Perimeta will
treat the query as having failed.
DNS server selection
You can choose to configure your Session Controller with between 1 and 16 DNS servers to which
it can send DNS queries. If you decide to configure the Session Controller with more than one DNS
server, you must also configure the Session Controller with a selection method that it will use to
choose the DNS server to which it will send a particular query. You can use one of the following
selection methods.
• Hunt - The Session Controller starts with the first DNS server in the list, and if it cannot contact
that server, it attempts to contact the second server in the list, and so on. This selection method
is most suitable for deployments that require redundancy for DNS servers, but have a DNS query
load that can be handled by a single DNS server. You should configure your DNS servers in order
of priority if you decide to use this selection method.
• Round robin - The Session Controller sends each successive query to the next sequential
address in the list. The Session Controller will send the first query to the first DNS server in the
list, the second query to the second DNS server in the list, and so on. If the DNS query fails, the
Session Controller will try the next sequential DNS server in the list. This selection method is
suitable for deployments dealing with a large number of DNS queries that should be spread evenly
across a number of DNS servers.
For more information on changing the selection method, see Managing DNS Servers in Perimeta
Initial Setup Guide (CH6000 Series Hardware) for DNS servers in the management network and
Configuring service interfaces in Perimeta Configuration and Interoperability Guide - CLI Users for
DNS servers in service networks.

DNS cache
To avoid placing unnecessary load on the DNS server, the Session Controller maintains a cache
of DNS records. You can view cached records and clear them from the Session Controller using
the command line interface (CLI); for information on how to do this, see Managing the DNS cache
in Perimeta Initial Setup Guide (CH6000 Series Hardware). If you have configured the Session
Controller to contact DNS servers in one or more service networks, you can also view and clear
cached records from a particular service network.
DNS records include a time-to-live value that determines how long the Session Controller should
keep the record in its DNS cache. Once this time-to-live expires, the Session Controller will remove
the record from the DNS cache and will query the DNS server for a new record the next time that it
needs to resolve that domain name.
You can configure the Session Controller with a minimum acceptable time-to-live value that can be
returned for a DNS record. If a DNS server provides a time-to-live that is smaller that this value, the
Session Controller will apply the minimum value to the record instead. This guards against a name
server responding with unacceptably small time-to-live values, causing the Session Controller to flood
the network with constant DNS queries.
If the Session Controller caches a record that has been retrieved from a CNAME record chain, it
will use the shortest time-to-live value of all of the records in the chain (including the final NAPTR,
SRV or A/AAAA record to which the chain resolves), unless it is shorter than the configured minimum
acceptable time-to-live value, in which case the Session Controller will apply the configured minimum
value.
For information on how to change the minimum time-to-live values, see Changing the minimum time-
to-live for cached DNS records in Perimeta Initial Setup Guide (CH6000 Series Hardware).
Failed records
If the Session Controller cannot contact the IP address given for the highest priority record for a
particular device, the Session Controller will add this record to a list of failed records for a period of
time. During this period, the Session Controller will not use this record and will attempt to use lower
priority records for this device instead. By default, the period of time that the Session Controller will
keep a failed record on the list of failed records is 10 minutes. You can choose to change this using
the CLI, as described in Configuring the default failure timeout for a DNS record in Perimeta Initial
Setup Guide (CH6000 Series Hardware).
If all of the records for a particular device fail, the Session Controller will revert to trying the highest
priority record, regardless of whether it is on the list of failed records.
You can also choose to configure the Session Controller to not add DNS records to the list of failed
records on receipt of a 503 error response. You may want to do this to prevent peers from becoming
overloaded when load balancing. For example, if a set of equal-priority DNS records resolves to a
group of peers and the Session Controller stops diverting traffic towards one of these peers because
it responds with a single 503 error response, the remaining peers may not be able to handle the

additional traffic. For more information on how to change this setting, see Configuring 503 response
handling in Perimeta Initial Setup Guide (CH6000 Series Hardware).
DNS conflicts
If endpoints in access service networks use the same DNS infrastructure as Perimeta, conflicts can
arise when those devices need to resolve a domain name to a Perimeta IP address, but Perimeta
needs to resolve it to the address of another device.
For example, assume that a Perimeta deployment protects a softswitch associated with the domain
name softswitch.metaswitch.example. Endpoints sending registrations and new call requests
to that domain need to resolve it to a Perimeta IP address (service traffic must pass through a Session
Controller to reach the softswitch). However, the Session Controller must route the message on to the
IP address of the softswitch itself, based on the same domain name.
One solution to this problem is to use routing configuration on the Session Controller to force it to
route requests to particular IP addresses based on the domain name in the Request-URI, effectively
bypassing DNS. To do this, you must configure an adjacency on the Session Controller that forces
all requests to a particular signaling peer, and then configure routing policy to route requests
over that adjacency based on the destination domain name. For information on adjacencies, see
Adjacencies in Perimeta Configuration and Interoperability Guide - CLI Users. For information on
routing configuration, see Routing policy in Perimeta Configuration and Interoperability Guide - CLI
Users.
The above solution will prevent you from using any advanced DNS features, such as multiple SRV
records for load-balancing or redundancy, when routing requests from the Session Controller. If you
intend to use these features and need to prevent DNS conflicts, you will require a split-brain (also
known as split-horizon) DNS infrastructure that returns different records depending on the source of
the query. If this is the case, contact your Metaswitch customer support representative for advice.
DNS poisoning
DNS poisoning is a common attack by which a device imitates a DNS server and returns bad
responses to DNS queries, which are cached and used by the recipient. This can cause calls to be
routed to a malicious third party or to fail completely.
Perimeta polices against DNS poisoning by only accepting DNS records that are sent from a
configured DNS server in response to a query that Perimeta issued. It is possible that a malicious
unknown source could use IP spoofing to make a packet appear as if it was sent by a DNS server to
which Perimeta sends queries. However, even if the attacker was able to successfully spoof the DNS
server's IP address, the attacker would also have to know the correct query ID for the DNS record to
be accepted by Perimeta.
Attention:
If you do need to configure DNS servers on an untrusted service interface, you must ensure that
this service interface connects to a network that is protected against IP spoofing (for example,
through network ingress filtering methods such as an access control list configured on the router.

2.3.3 ENUM support
ENUM is a method of mapping E.164 telephone numbers to Uniform Resource Identifiers (URIs)
using DNS Naming Authority Pointers (NAPTR) records. Perimeta can be configured to carry out an
ENUM lookup on a telephone number included in a SIP request as part of its routing policy. The URIs
returned in the ENUM response contain information that Perimeta can use for further routing, such as
a destination domain name.
ENUM lookups
Perimeta's routing policy tables allow you to include ENUM lookup entries that instruct the Session
Controller to send an ENUM query on the current destination number to one of a pre-defined set of
ENUM servers. The ENUM lookup entry also defines the action the Session Controller should take
if the ENUM lookup is successful and the action it should take if it fails. For example, the entry may
instruct the Session Controller to continue routing with a specific routing table using the new URI if the
ENUM lookup is successful or reject the request if the ENUM lookup fails. For more information on
routing policy, see Routing policy in Perimeta Configuration and Interoperability Guide - CLI Users.
The following behavior is seen when the Session Controller initiates an ENUM lookup.
• The Session Controller will convert the current destination number into a DNS name by removing
the plus, reversing the digits, inserting a '.' between the digits and appending a pre-defined domain
name. In standard ENUM, this domain is e164.arpa, which is the internet domain used for ENUM
registrations. However, custom domain names may be used in private routing schemes.
• The Session Controller sends an ENUM query using this domain name to one of a pre-defined set
of ENUM servers.
If the Session Controller has been configured to do so, the Session Controller adds additional
information to the ENUM query to indicate the original source of the request, which an ENUM
server can use to recognize the location of the UE that initiated the call. The Session Controller
also adds an EDNS0 Option-Code to identify this source information to the ENUM server. For
details on this source information and where the Session Controller retrieves it, see Additional
source information on page 46.
• In most cases, the Session Controller receives a DNS response from the ENUM server containing
one or more candidate URIs. The Session Controller analyzes the response to ensure that it is of a
valid format.
• If the response is of a valid format and contains one or more valid URIs, the Session Controller
selects the most suitable URI in the response. If there is only one candidate URI in the
response, the Session Controller selects this URI. Otherwise, the Session Controller ranks the
candidate URIs using the method described in Multiple candidate URIs on page 44 to select
the most suitable URI.
Once a URI is selected, the Session Controller takes the action defined on the ENUM lookup
entry in the routing policy table for successful ENUM lookups.
• If the response is of a valid format but does not contain any valid URIs, the Session Controller
rejects it and takes the action specified on the ENUM lookup entry for lookup failures.

• If the response is malformed, the Session Controller rejects it and takes the action specified on
the ENUM lookup entry for lookup failures.
• In some cases, the ENUM server that the Session Controller attempts to contact may fail to
respond. If this situation, the Session Controller sends the ENUM query in turn to any other ENUM
servers that it has been configured to contact. If none of these servers respond, it treats the ENUM
lookup as having failed and takes the action defined on the ENUM lookup entry in the routing
policy table.
Example
The following is an example of the process of a successful ENUM lookup on a call to the number
+15163992968.
In this example, the Session Controller has the following routing policy configuration.
config
sbc
signaling
enum
adjacency sip Core
...
adjacency sip Access
...
adjacency sip Other
...
call-policy-set 1
first-call-routing-table table_1
rtg-src-adj-table table_1
entry 1
match-adjacency Access
enum-lookup
enum-success-action next-table table_2
enum-fail-action reject
entry 2
match-adjacency *
dst-adjacency Core
action complete
rtg-dst-domain-table table_2
entry 1
match-domain otherdomain.com
dst-adjacency Other
action complete
entry 2
match-domain *
dst-adjacency Core
action complete
complete
active-call-policy-set 1

Figure 4: ENUM lookup
• A user endpoint sends an SIP INVITE to sip:[email protected]. The Session Controller

receives this on the adjacency Access and begins routing the message.
• As the SIP INVITE was received on the adjacency Access, the Session Controller
matches it to entry 1 of the routing table table_1 and initiates an ENUM lookup.
The Session Controller converts the current destination number to the domain name
8.6.9.2.9.9.3.6.1.5.1.e164.arpa and sends an ENUM query to the ENUM server.
• The ENUM server sends a response to the Session Controller containing a NAPTR record that
maps the original telephone number to the new URI sip:[email protected];tgid.
• The Session Controller continues routing using the new URI with routing table table_2, as
specified on the original ENUM lookup entry in routing table table_1. The Session Controller
matches on the domain otherdomain.com and routes the request out of adjacency Other.
Multiple candidate URIs
The NAPTR result in an ENUM response may return more than one candidate URI. Perimeta will use
the information given in each NAPTR record to decide how to prioritize these URIs
The following is an example of a NAPTR result containing three NAPTR records.

$ORIGIN 0.9.8.7.6.5.4.3.2.1.4.4.e164.arpa.
; order pref flags service regexp replacement
IN NAPTR 10 100 "u" "E2U+sip" "!^.*$!
sip:[email protected]!" .
IN NAPTR 10 101 "u" "E2U+h323" "!^.*$!h323:[email protected]!" .
IN NAPTR 10 102 "u" "E2U+msg" "!^.*$!mailto:[email protected]!"
.
The following information is given for each NAPTR record.
• Order - This indicates the order in which the results should be used (lowest first).
• Preference - This gives a priority value for use of a record among others of equivalent order
(i.e. it can be used for load-balancing between 2 or more results). Again, a lower value is given
precedence.
• Flags - This defines the behavior of the record. For ENUM, this will either be u, indicating that the
entry is terminal and a valid URI for use as the destination, or p, indicating that the entry is non-
terminal and another ENUM lookup should be performed on the result.

• Service - This defines the specific application. The E2U+ prefix indicates ENUM and the remaining
part indicates the ENUM specific service.
• Regex / Replacement - These fields are used to specify either a replacement URI or a
transformation to a new URI based on the original E.164 URI (not the ENUM reversed E.164
number). These fields are mutually exclusive and only one will have a value in any response.
Perimeta will process NAPTR records where the Service field includes the E2U+ prefix and one of the
following among the ENUM specific services.
• tel
• sip
• sips
Perimeta will also process NAPTR records where the Service field includes the E2U+ prefix and an
ENUM specific service with tel, sip or sips as a subtype, such as pstn:sips. Perimeta will ignore any
other records.
Perimeta will then rank the NAPTR records that meet the above criteria as follows.
• If the original request was for a sips: URI, only NAPTR records with a Service field that includes
sips: among the ENUM specific services are considered, as a call that begins by requesting secure
communications cannot be downgraded to use unsecure communications.
• The Session Controller will ignore any non-terminal NAPTR record with an order and preference
value equal to or greater than a terminal NAPTR record.
• If the NAPTR record with the lowest order and preference values is non-terminal, it will be selected
by the Session Controller. The Session Controller will apply the replacement domain to the original
destination and then perform another ENUM lookup on this result.
• In all other cases, only terminal NAPTR records will remain. For each NAPTR record, the Session
Controller will either take the URI in the Replacement field, or it will use the value in the Regex
field to transform the original destination URI into a new URI. It will then sort these new URIs
into ascending order using the values in the Order and Preference fields. If more URIs have
been returned than the pre-configured maximum number of candidate URIs from a single ENUM
response on which the Session Controller will attempt to route, the Session Controller will discard
URIs from the bottom of the list until it has the correct number of candidate URIs.
The Session Controller will attempt to route on the first URI in the list using the action specified for
a successful ENUM lookup on the ENUM lookup entry. If the Session Controller fails to route the
first URI, it will try the second URI in the list and so on until routing is successful. If the Session
Controller cannot successfully route any of the candidate URIs, it will continue routing with the next
entry in the routing policy table using the URI that was provided on the original request.
Number portability parameters
The URIs in an ENUM response may have additional parameters which indicate number portability
information, as defined in RFC 4694. The Session Controller will continue to append these
parameters to the relevant URIs in future SIP messages. However, these parameters will not have
any influence on routing carried out by the Session Controller.

Bad or missing responses
Perimeta treats a query to an ENUM server as having failed if no response is received within 0.5
seconds or the ENUM response is malformed or faulty. If the initial query fails, Perimeta will attempt
to contact any other ENUM servers that have been configured in turn. If all of the configured ENUM
servers are uncontactable or no response is received from any of the servers within 5 seconds,
Perimeta treats the entire ENUM lookup as having failed.
Perimeta also treats a query to an ENUM server as having failed if the ENUM response is of a valid
format but does not contain any valid URIs. In this case, Perimeta does not attempt to contact any
other ENUM servers and treats the entire ENUM lookup as having failed.
Additional source information
Some ENUM servers can tailor responses to queries based on the source originating number or the
source originating domain of the SIP request so that calls can be routed appropriately. For example,
if an ENUM server identifies that an ENUM query originated from a number in the same local region
as the number being called, it may provide URIs that allow the call to be routed directly. Conversely,
if an ENUM query for the same number originated from a number in a different geographical region,
the ENUM server may provide a response containing URIs that route the call through other service
provider's networks for billing or legal reasons.
However, the ENUM server usually has no means of identifying the source of a SIP request, as the
ENUM query contains only the destination number. To address this issue, you can configure Perimeta
to include additional source information in ENUM queries to indicate the original source of the request
to the ENUM server. The Session Controller takes this information from a SIP header that you can
specify and adds it to the additional data section of the ENUM query as an Option resource record,
along with an EDNS0 option-code to identify this information to the ENUM server. The ENUM server
must be configured to recognize this information and tailor responses accordingly.
Attention:
An ENUM server must support Extension Mechanisms for DNS (EDNS) to receive additional
source information from Perimeta. You must not configure Perimeta to send additional source
information to an ENUM server that does not support EDNS.
If Perimeta sends additional source information to an ENUM server that does not support EDNS,
the ENUM server is likely to reject any ENUM queries including additional source information with
a 'Not Implemented', 'Format Error', or 'Server Fail' DNS return code. In this case, Perimeta will
resend the ENUM query without the additional source information. This will result in increased
network load and will impact on the performance of both the Session Controller and the ENUM
server.
Retrieving source information from the P-Asserted-Identity header
The following behaviour is seen if you configure the Session Controller to retrieve additional source
information from the P-Asserted-Identity header.

• If the adjacency on which the original SIP message was received is configured with a default P-
Asserted-Identity header, the Session Controller retrieves the additional source information from
this header.
• If the adjacency does not have a default P-Asserted-Identity header and the original SIP message
includes a P-Asserted-Identity header that the Session Controller can accept, the Session
Controller retrieves the source information from the P-Asserted-Identity header on the original SIP
message.
• If neither of the previous conditions are met, but the SIP message contains a P-Preferred-Identity
header, the Session Controller's behaviour depends on whether or not it can authenticate the
endpoint.
• If the Session Controller can authenticate the endpoint, the following behaviour applies.
• If a P-Preferred-Identity header is present on the original SIP message and it matches one
of the endpoint's public identities, the Session Controller will retrieve the source information
from the P-Preferred-Identity header.
• Otherwise, the Session Controller will use the primary public ID of the endpoint as the
source information.
• If the Session Controller cannot authenticate the endpoint, it will not include any source
information in the ENUM query.
Trunk group ID parameters
The Session Controller can append trunk group ID parameters to the additional source information in
the ENUM query as user parameters. The Session Controller handles trunk group ID parameters as
follows.
• If the Session Controller has not been configured to manipulate trunk group IDs as described
in Trunk groups in Perimeta Configuration and Interoperability Guide - CLI Users, the Session
Controller will retrieve any trunk group IDs from the SIP header that you have specified and include
them as user parameters in the ENUM query.
• If the Session Controller has been configured to manipulate trunk group IDs, it will carry out this
manipulation before adding any trunk group IDs to the ENUM query. For example, if the Session
Controller has been configured to strip the trunk group IDs and trunk group ID context from SIP
messages received on a specific adjacency, the Session Controller will strip these IDs before
forming the ENUM query.
Example
In the following example, the Session Controller is configured to retrieve source information from
the P-Asserted-Identity header when carrying out ENUM lookups for requests received on the
'ExamplePeering' adjacency and to identify this information on the ENUM request with the EDNS0
option-code 40. Additionally, there is trunk group ID manipulation configuration in place to add the
trunk group p1 and the trunk group context expeer to messages received on this adjacency.
The Session Controller receives the following SIP message.

INVITE sip:[email protected] SIP/2.0
To: <sip:[email protected]>

P-Asserted-Identity: "Test User" <sip:[email protected]>

The Session Controller retrieves the source information from the P-Asserted-Identity header and
sends the following ENUM query.
Query: 2.1.2.1.5.5.5.5.3.8.e164.arpa type NAPTR class IN
Additional Record:
Type OPT
OPTION-CODE: 40
OPTION-DATA: sip:8245556472;tgrp=p1;[email protected]
Configuring ENUM lookups
You can enable ENUM lookups using the CLI. You must configure Perimeta with the following default
settings to determine how the Session Controller will handle ENUM lookups.
• The default source from which the Session Controller sends ENUM requests. You can set this to
the configured management IP addresses, or to a service address of a service network configured
on your Session Controller. If not set, the Session Controller will default to sending ENUM requests
from your management network.
• The contact details of the servers to which the Session Controller will send ENUM requests. You
can either:
• Configure up to four dedicated ENUM servers. The Session Controller will select which of these
servers to contact using either a hunt or round-robin method.
• Use the DNS server(s) already configured on the network you choose to be the default source
of ENUM lookups. For more information on configuring DNS servers on management networks,
see Managing DNS Servers in Perimeta Initial Setup Guide (CH6000 Series Hardware). For
more information on configuring DNS servers on service networks, see Configuring service
interfaces in Perimeta Configuration and Interoperability Guide - CLI Users.
• The dial plan suffix that will be used by your ENUM servers when carrying out an ENUM lookup.
This will usually be e164.arpa, which is the top level domain designated for ENUM, but you may
decide to use a custom domain name for a private routing scheme.
• The maximum number of candidate URIs from a single ENUM response on which the Session
Controller will attempt to route.
If you want the Session Controller to include additional source information in ENUM queries, you must
also enable this feature and configure the Session Controller with the EDNS option-code that it should
use to identify the additional source information.
For full instructions on how to enable ENUM lookups on your Session Controller, Enabling ENUM
lookups in Perimeta Configuration and Interoperability Guide - CLI Users. Note that if you are
configuring the Session Controller to include additional source information in ENUM queries, you must
also specify the SIP header type that the Session Controller must retrieve this information from by
following the instructions given in Setting the source SIP header for additional source information for
ENUM lookups in Perimeta Configuration and Interoperability Guide - CLI Users.
Once you have enabled ENUM lookups on your Session Controller, you will need to add ENUM
lookup entries to your routing policy tables to ensure that ENUM lookups are carried out at the correct

point in your routing policy. For more information on ENUM lookup entries and routing policy tables,
see Routing policy tables in Perimeta Configuration and Interoperability Guide - CLI Users.
Attention:
ENUM lookups on SIP registration requests are not permitted. You must not configure your routing
policy tables to carry out an ENUM lookup on a SIP registration request.
ENUM profiles
There may be points in your routing policy where you require an ENUM lookup, but the behaviour
defined in your default ENUM settings is not appropriate. For example, you may want to send queries
to a different set of ENUM servers or use a different dial plan suffix. You can use ENUM profiles to
configure a separate set of ENUM settings that can be used for one or more specific ENUM lookup
entries in your routing policy where the default behaviour is not suitable.
For information on how to configure an ENUM profile, see Configuring an ENUM profile in Perimeta
2.3.4 Traffic information for firewall configuration
Overview of the various protocols and ports that Perimeta uses when it connects to various devices.
This information can help you correctly configure any firewalls in your network to permit legitimate
traffic to and from Perimeta.
Traffic summary tables
The following tables gives details of the traffic that you need to allow on connections to and from
particular Perimeta IP addresses, including protocol and port information. For information on the
different IP addresses that Perimeta uses, see IP addresses for Perimeta on page 34.
Note:
If you have a geographically redundant deployment, you must allow traffic on connections between
the management IP addresses of the Session Controllers in the geographically redundant group.
This traffic is not included in the table below. For more information on this traffic, see Planning a
geographically redundant deployment in Perimeta Redundancy Solutions Guide.
If you have enabled a co-resident DCM on your Session Controller, the Session Controller will
share its virtual management IP address with the co-resident DCM. You will need to allow some
additional traffic types on connections to and from the virtual management IP address to allow the
co-resident DCM to function. These are not described in the following table. Instead, you can find
them in Planning a Metaswitch Distributed Capacity Manager deployment in Metaswitch Distributed
Capacity Manager Initial Setup Guide.

Table 1: Perimeta traffic summary - management network
Source IP Destination IP Protocol Destination Transport Notes

address address port
Configuration Session SSH/SFTP 22 TCP

client IP Controller
addresses virtual
management
IP address /
instance
management
IP addresses
MetaView Session SSH 22 TCP Only required

Server Controller if connecting to
virtual Metaswitch support
management VPNs through MetaView
IP address Server.
SSC/ISC virtual SMTP email SMTP 25* TCP Only required if you
management server want to send email
IP address / notifications of XML
instance billing file uploads. 25 is
management the default port and can
IP addresses be changed when you
configure XML billing.
SSC/ISC virtual SSC/ISC virtual Proprietary 22, TCP Only required in

management management Metaswitch 60002-60010, geographically
IP address / IP address / protocol 60103-60110 redundant deployments.
instance instance For more information,
management management see Geographic
IP addresses IP addresses of redundancy in Perimeta
other Session Product Description.
Controllers
in the same
geographically
redundant
group
Session DNS server IP DNS 53 UDP / TCP

Controller address
virtual


management
IP address /
instance
management
IP addresses
Session NTP server IP NTP 123 UDP

Controller address
virtual
management
IP address /
instance
management
IP addresses
Session RADIUS server RADIUS 1812* UDP Only required if you

Controller IP address want to use external
virtual authentication (via
management RADIUS) for Craft
IP address / terminal users. 1812
instance is the default port and
management can be changed when
IP addresses you configure external
authentication.
Session Backup server FTP 21 TCP Necessary if you want

Controller IP address to store configuration
virtual snapshots and/or XML
Billing server IP
management billing files remotely
address
IP address / using FTP.
instance
management
IP addresses
Session Billing server IP SFTP 22 TCP Necessary if you want

Controller address to store XML billing files
virtual remotely using SFTP.
management
IP address /
instance


management
IP addresses
Session Upload server SFTP 22 TCP Necessary if you want

Controller to automatically upload
virtual CSV statistics files to
management an upload server. The
IP address / port can be changed
instance when configuring the
management connection to the upload
IP addresses server.
Session MetaView SCP 22 TCP Necessary if you want

Controller Install Server to store configuration
virtual IP address snapshots on MetaView
management (this is usually Install Server.
IP address / the MetaView
instance Server
management address)
IP addresses
Session Metaswitch Proprietary 1553 TCP Only required if the

Controller Distributed Metaswitch Session Controller uses
virtual Capacity protocol the solution licensing
management Manager model. You must allow
IP address / (DCM) IP a connection to each
instance address Metaswitch DCM in the
management DCM Group.
IP addresses
Session Remote Syslog 514* UDP Only required if you

Controller logging server want to send a subset of
virtual IP address the Session Controller's
management diagnostics as syslog
IP address / messages to a remote
instance server. 514 is the
management default port and can
IP addresses be changed when
you configure syslog
messaging.


Session Target IP ICMP N/A ICMP

Controller addresses
virtual for probing
management (configurable,
IP address / used to monitor
instance management
management network
IP addresses connectivity)
Session Any devices ICMP N/A ICMP

Controller you want to
virtual ping/traceroute
management from the
IP address / Session
instance Controller
management
IP addresses
Any devices Session ICMP N/A ICMP

from which Controller
you want to virtual
ping/traceroute management
the Session IP address /
Controller instance
management
IP addresses
Session SNMP Agent SNMP 162 (default) UDP Only required for SNMP
Controller (MetaView or another Agents receiving SNMP
virtual Server or port on your TRAPs or INFORMs.
management third-party) IP client
IP address address
SNMP Agent Session SNMP 161 UDP Only required for SNMP
(MetaView Controller Agents gathering SNMP
Server, virtual statistics.
MetaView management
Statistics IP address
Engine,
ServiceIQ
Monitoring


(SIMon) or
third-party) IP
address
Third-party Instance SNMP 161 (high UDP Only required for SNMP
SNMP Agent management availability Agents gathering SNMP
IP address IP addresses systems) / statistics or if you want
1161 to expose the system
(standalone information available
systems) through the Net-SNMP
MIBs to an SNMP
Agent.
Session Service Proprietary 6761 TCP

Controller Assurance
virtual Server(s)
management
IP address /
instance
management
IP addresses
MetaView Session HTTPS 443 TCP Only required if

Server/ Controller you want to allow
MetaSphere virtual management of
Enhanced management Perimeta configuration
Applications IP address using MetaView Web or
Server (EAS) MetaView Explorer over
management HTTPS.
IP address
Session HTTPS proxy Metaswitch HTTPS HTTPS Only required if you

Controller server address proprietary proxy server want to run a co-resident
virtual if using HTTPS protocol port if using Metaswitch Distributed
management proxy server; HTTPS Capacity Manager on
IP address Amazon S3 proxy server the same hardware as
cloud address (default one or both Perimeta
(variable, 8080); 443 instances.
resolved otherwise
using DNS)
otherwise


Replication IP Replication IP Proprietary 40499-40500 TCP Only required on

address address of the Metaswitch COTS and virtualized
other instance protocol high availability (HA)
deployments and if the
HA ports are firewalled
from each other.
Replication IP Replication IP Proprietary 36403-36404, UDP Only required on

address address of the Metaswitch COTS and virtualized
other instance protocol high availability (HA)
deployments and if the
HA ports are firewalled
from each other.
Session 192.91.191.13 VPN 22 TCP Connection to

Controller Metaswitch support
205.196.118.7
virtual VPNs, over the internet.
management 198.147.226.4 Only required if
IP address / connecting directly
instance from the Session
management Controller rather than via
IP addresses MetaView Server.
Session Virtual function HTTP / 80 (if using TCP Only required if you
Controller Event Stream HTTPS HTTP) / 443 want to send a report
virtual (VES) collector (if using statistics and alarms
management IP address HTTPS) * to an Virtual function
IP address / Event Stream (VES)
instance collector in a virtualized
management environment. 443 is
IP addresses the default port when
using HTTPS and can
be changed when you
configure VES reporting.
80 is the only available
port if using HTTP.
Session Metaswitch HTTPS 4000 TCP Only required if you

Controller Deployment are using Metaswitch
virtual Manager Deployment Manager
management (MDM) as part of


IP address / (MDM) IP orchestrating the

instance address Session Controller in an
management OpenStack environment.
IP addresses You must allow a
connection to each
MDM instance in the
MDM pool.
Session Vault cluster IP HTTPS 8200 TCP Only required if you

Controller address are using Metaswitch
virtual Deployment Manager
management (MDM) as part of
IP address / orchestrating the
instance Session Controller in an
IP addresses
Session Metaswitch RPC 8300 TCP Only required if you

management (MDM) IP (MDM) as part of
IP address / address orchestrating the
connection to each
MDM instance in the
MDM pool.
Metaswitch Session Serf 8301 UDP / TCP Only required if you

Deployment Controller are using Metaswitch
Manager virtual Deployment Manager
(MDM) IP management (MDM) as part of
address IP address / orchestrating the
connection from each
MDM instance in the
MDM pool.


Session Management Serf 8301 UDP / TCP Only required if you

Controller IP addresses are using Metaswitch
virtual of all other Deployment Manager
management Metaswitch (MDM) as part of
IP address / products in the orchestrating the
instance orchestrated Session Controller in an
management deployment OpenStack environment.
connection to each
instance of a Metaswitch
product.
Management Session Serf 8301 UDP / TCP Only required if you

IP addresses Controller are using Metaswitch
of all other virtual Deployment Manager
Metaswitch management (MDM) as part of
products in the IP address / orchestrating the
orchestrated instance Session Controller in an
deployment management OpenStack environment.
connection from each
instance of a Metaswitch
product.
Session Metaswitch Serf 8301-8302 UDP / TCP Only required if you

management (MDM) IP (MDM) as part of
IP address / address orchestrating the
connection to each
MDM instance in the
MDM pool.
Session Secure HTTPS 4005 TCP Configuration selection

Controller Distribution API. Only required when
virtual Engine service configuration
management etcd VMs automation (service
IP address / configuration pipeline)


instance management is in use. For more

management IP addresses information, see
IP addresses Overview of the
Perimeta configuration
pipeline in Perimeta
Service Configuration
Automation
(Configuration Pipeline)
Guide. You must allow a
connection to each etcd
instance.
Table 2: Perimeta traffic summary - service networks

ISC/SSC IP address/ SIP 5060* TCP/UDP This is the default port.

service address ranges The port Perimeta uses
interface local for endpoints/ for SIP can be changed
IP addresses peer devices by configuration.
on the service
network
IP address/ ISC/SSC SIP 5060* TCP/UDP This is the default

address ranges service port. The remote ports
for endpoints/ interface local Perimeta connects to for
peer devices IP addresses SIP can be changed by
on the service configuration.
network
ISC/SSC Remote SIP over 5061* TCP 5061 is the standard

service TLS peer IP TLS port, but this can vary
interface local address depending on the
IP address configuration of the peer
device
Remote ISC/SSC SIP over * TCP Each TLS connection

TLS peer IP service TLS must be set up using
address interface local a local IP address
IP address and port combination


that is unique to that

connection.
ISC/MSC IP address/ RTP/RTCP * UDP Perimeta can send/

service address ranges receive media to and
SRTP/
interface local for endpoints/ from any remote port.
SRTCP
IP addresses peer devices
on the service UDPTL
network
IP address/ ISC/MSC RTP/RTCP 16384-65535*UDP This is the default range

address ranges service of local ports used by
SRTP/
for endpoints/ interface local Perimeta for media
SRTCP
peer devices IP addresses streams. This can be
on the service UDPTL altered for specific local
network IP addresses or address
ranges to any range of
ports between 16384
and 65535.
SSC H.248 MSC local H.248 2944* UDP This is the default port.
control address H.248 address An alternative port can
be configured using
the CLI local-port
command in the vmsc
mode.
MSC local SSC H.248 H.248 2944* UDP This is the default port.
H.248 address control address An alternative port can
be configured.
Session Any devices ICMP N/A ICMP

Controller you want to
service ping/traceroute
interface local from the
IP addresses Session
Controller
Any devices Session ICMP N/A ICMP

from which Controller
you want to service
ping/traceroute


the Session interface local

Controller IP addresses
ISC/SSC Diameter peer Diameter 3868* TCP 3868 is the standard

service IP addresses port, but this can vary
interface local depending on the
IP addresses configuration of the
peer device. Diameter
connections can
optionally be set up
over the management
network instead of
service networks.
Only required for IMS
deployments using the
Rx reference point and /
or Rf charging.
ISC/SSC DNS server IP DNS 53 UDP / TCP

service address
interface local
IP addresses
ISC/SSC Apple Push HTTPS 443 TCP Only required if you

service Notifications need to use the Apple
interface local Service Push Notifications
IP addresses (APNs): Service to wake VoIP
api.push. iOS applications.
apple.com or
17.0.0.0/8
ISC/SSC Signing service HTTP / Depends UDP / TCP Only required if you
service IP addresses HTTPS on your need to configure
interface local configuration. Perimeta to support SIP
IP addresses Default request signing.
ports: 80
(HTTP)
or 443
(HTTPS)


ISC/SSC Verification HTTP / Depends UDP / TCP Only required if you

service service IP HTTPS on your need to configure
interface local addresses configuration. Perimeta to support SIP
IP addresses Default request verification.
ports: 80
(HTTP)
or 443
(HTTPS)
Session Any devices ESP N/A ESP This is only required if

Controller with which Perimeta will use IPsec
service you want
interface local the Session
IP addresses Controller to
have an IPsec
connection
Any devices Session ESP N/A ESP This is only required if

with which Controller Perimeta will use IPsec
you want service
the Session interface local
Controller to IP addresses
have an IPsec
connection
Secure SSC/ISC SIP 5060* TCP/UDP The port can vary

Distribution service depending on the
Engine internal interface local configuration of your
service network IP addresses SDE adjacency.
virtual IP used to
address connect to
the Secure
Distribution
Engine (on
an SDE
adjacency)
Perimeta SSC/ Secure SIP 5060* TCP/UDP 5060 is the default port.
ISC service Distribution The port is configurable.
interface local Engine internal
IP addresses service network


used to virtual IP
connect to SDE address
(on an SDE
adjacency)
2.3.5 Network bandwidth requirements for Perimeta
Information on calculating network bandwidth requirements for traffic to and from Perimeta.
Attention:
Message sizes in the following are given in bytes, following convention. However, all bandwidth
requirements are given in bit rates (Mbps, Gbps etc), assuming eight bits to a byte.
Management network
There are two significant bandwidth requirements on the management network:
• Monitoring traffic if you deploy a Metaswitch Service Assurance Server.

• XML billing file uploads if you are using the XML billing method and choose to regularly upload
XML billing files from the Session Controller to a file server.
The bandwidth required for connecting to a Service Assurance server depends on whether the
Session Controller is configured to compress events (data) before sending them to the Service
Assurance Server.
• If the Session Controller compresses events, the minimum bandwidth is approximately 2.9 Mbps
per 100,000 BHCA (27.78 calls per second).
• If the Session Controller does not compress events, the minimum bandwidth is approximately 4.3
Mbps per 100,000 BHCA.
• If you use any of the features in the following table, the minimum bandwidth required increases.
Perimeta feature Additional bandwidth required for the

connection to a Service Assurance Server per
100,000 BHCA
H.248 (used when SSCs or ISCs control MSCs) 1.3 Mbps
SIP Message Manipulation Framework (MMF) 0.75 Mbps
Support for the Rx interface 0.4 Mbps
Rf billing 0.55 Mbps

Note:
If you have Service Assurance Server V10.2 (in a virtualized environment) and V10.3 (on
commercial-off-the-shelf (COTS) hardware) or later, we recommend that your Session
Controller does not compress data, because the Service Assurance Server offers more powerful
compression.
If the first version of the Perimeta software installed on your Session Controller was V4.4 or above,
compression is disabled by default. Otherwise, compression is enabled by default.
For more information on configuring compression, see Connecting a Session Controller to a

Service Assurance Server in Perimeta Operations and Maintenance Guide.
The average packet rate can be derived from the bandwidth by dividing by the MTU of the intervening
network.
If the Session Controller is configured to send diagnostics to multiple Service Assurance Servers
in a federation, the Session Controller will evenly distribute the diagnostics between these Service
Assurance Servers and there are no additional bandwidth requirements.
If you choose to regularly upload XML billing files to a file server, we recommend that you provide at
least 10 Mbps of bandwidth for this purpose. Ideally, you should provide between 30 and 50 Mbps of
bandwidth. These recommendations still apply if you choose to configure the Session Controller to
transform XML billing files using an XSLT stylesheet before uploading them to a billing server.
You can choose to configure Perimeta to uncompress XML billing files before uploading them to your
billing system. If you plan to do this, you should provide bandwidth as close as possible to the high
end of the range given above.
Note:
Although the major bandwidth requirements apply specifically to ISCs and SSCs, be aware that
in a distributed deployment, MSCs will still require connectivity to the management network, for
configuration traffic, VPN connections, etc.
Service networks - signaling
Attention:
The following requirements are primarily intended for use on your secure, core service networks.
On the access side, we recommend that you provide the maximum bandwidth (1 Gbps or 10 Gbps
per service Ethernet port), to allow for overhead in case of denial of service attacks.
SIP traffic
The average size of a SIP message is approximately 1000 bytes (8000 bits). Assuming that each
call has seven SIP messages, SIP traffic needs a minimum bandwidth of approximately 1.6 Mbps

per 100,000 BHCA (27.78 calls per second). This excludes fast-registration traffic for subscribers
registering from behind NAT.
When subscribers register from behind NAT, Perimeta maintains NAT pinholes by instructing
the subscribers to rapidly renew their registration. The extra REGISTERs are not included in the
processing capacity limits of the Session Controllers, but do require bandwidth. This requirement is 17
Kbps per 1000 NATted subscribers.
H.248 traffic
In a distributed deployment, SSCs and MSCs communicate using H.248. The following bandwidth
requirements apply between an SSC and each of the MSCs it controls.
• Continuous bandwidth (typical): 6000 bytes total per call, 1.3 Mbps bandwidth per 100,000 BHCA.
• Burst bandwidth (for call audit - this is in addition to the continuous bandwidth): 60 Kbps per 100
active media sessions.
At maximum capacity, MSCs support 1,000,000 BHCA and 16000 concurrent sessions. This gives a
maximum H.248 bandwidth requirement of 23 Mbps (the corresponding packet switching requirement
is 11.5 kpps).
The maximum latency of the H.248 connection is 100ms.
Service networks - media
Attention:
The following requirements are primarily intended for use on your secure, core service networks.
On the access side, we recommend that you provide the maximum bandwidth (1 Gbps per service
Ethernet port), to allow for overhead in case of denial of service attacks.
The amount of bandwidth required for media depends on the maximum expected number of
concurrent media streams, the details of the codecs used, and whether you are using IPv4 or IPv6.
Example per-stream bandwidth - G.711
The following worked example demonstrates how to calculate the per-stream bandwidth requirement,
in one direction, for the popular G.711 codec at 64kbps bitrate, assuming a packetization delay of
20ms (i.e. 50 packets/second).
• Calculate the size of a single packet. A G.711 packet is composed of the following:
• The G.711 payload. The bitrate in bits per second (64000) divided by the number of packets per
second (50) gives the size of the payload for a single packet: 1280 bits.
• The RTP header. This is 96 bits.
• The UDP header. This is 64 bits.
• The IP header. Assuming IPv4, this is 160 bits (for IPv6 it would be 320 bits).
• The Ethernet frame (802.3 Ethernet). Including the full header, plus a 96 bit interframe gap, but
no VLAN tag (this would add an extra 32 bits), this is 302 bits.
• This gives a total packet size of 1904 bits.

• Calculate the bandwidth required for a single stream. This is the packet size (1904 bits) multiplied
by the number of packets per second (50): 95200 bits per second or 95.2 kbps.
Various additional factors can increase this requirement. IPv6 adds 160 bits per packet, VLAN tags
add 32 bits per packet, and RTCP adds an additional 5% to the total requirement.
You can use the above process to calculate the requirement for any codec, as long as you know the
bitrate and packetization delay. Alternatively, you can use the calculator at http://www.bandcalc.com.
This link is provided for reference only; Metaswitch is not responsible for the content of this (or any
other) external website.
Calculating requirements for deployments
The per-stream bandwidth given in the example above is required in both directions: i.e. full-duplex
links are required (note that a full duplex 1 Mbps Ethernet link provides 1 Mbps of bandwidth in each
direction). In addition, the bandwidth is required on each side of the call. A single G.711 call in which
the caller and callee connect to the Session Controller over different Ethernet ports would require 95.2
kbps of bandwidth on each link. A similar call in which the caller and callee connect to the Session
Controller over the same Ethernet port would require double the bandwidth on that link: 190.4 kbps.
A Perimeta 6320 MSC at full load, handling 16000 concurrent G.711 media streams, will require
approximately 1.6 Gbps of bandwidth on each side. A 6320 ISC at full load, handling 12000
concurrent streams, will require approximately 1.2 Gbps on each side.
Note:
Note that Perimeta's media bypass feature allows you to configure your Session Controller to let
media pass directly between endpoints when you know that the appropriate connectivity is present.
If you do this, the media bandwidth will only be required between the endpoints themselves,
and not between them and Perimeta. For more information on this feature, see Media bypass in
Packet rate
As well as bandwidth, network capacity is restrained by the number of packets routers can process
per second. This requirement can be calculated straightforwardly from the packetization delay used
for streams. For example, if the packetization delay is 20ms, each stream consists of 50 packets per
second (pps) in each direction, giving a per-stream requirement of 100pps.
2.3.6 Switch and router configuration for Perimeta
You will need to configure your network switches and routers to work with Perimeta.
Network switch configuration
General configuration
You must use the following configuration on the network switches that you connect to Perimeta.

• Session Controller ports (service and management) must be connected to layer 2 ports on your
switches (not layer 3). Corresponding ports used by each instance in a high availability system and
ports in the same port group must be connected to ports in the same Ethernet subnet (broadcast
domain).
• Enable auto-negotiation for link speed and direction.
• Disable GigE flow control.
• Disable switchport negotiation.
• Disable the error disable function. This is not mandatory, but if it is enabled there is a risk that the
switch will misinterpret legitimate traffic from the Session Controller as an error and disable the
connection.
• For quality of service (QoS), configure your switches to map DSCP to 802.1p.
Aggregated ports
If you have selected a port group scheme that includes aggregated ports, you will need to set up your
switches to support aggregation..
By default, Perimeta uses static 802.3ad aggregation rather than LACP (link aggregation control
protocol). If your switches are configured to use LACP, you can configure your Session Controller to
use it.
If you use the default static aggregation, you must configure the ports on the switch connected to
the aggregate link as channel-group n mode on. You must also configure your switches to use
802.3ad with a link selection policy that matches Perimeta's as closely as possible. Perimeta uses the
following link selection policy; ^ is bitwise exclusive-or (XOR), & is bitwise AND, >> is rightwards bit-
shift and % is modulo.
• Let src-ip and src-port be the IP address and port number of the source, and dest-ip and dest-
port be the IP address and port number of the destination.
• Define port-xor= ( src-port^ dest-port) >> 1
• Define final-xor= port-xor^ ( ( src-ip^ dest-ip) & 0xFFFF )
• The selected link is final-xor% 2
VLANs
If you intend to use VLANs in your deployment, you must configure the switches that will carry service
traffic to and from Perimeta to do the following.
• Support splitting traffic between VLANs.

• Trust VLAN tags set by the Session Controller.
• Support separate ARP tables for each VLAN.
• If your switches use rapid STP, you must configure them to use a form that supports multiple
VLANs, such as PVST, CST, or MST. You must also enable portfast to ensure seamless media.
Off-LAN IP Addresses
If you have configured any off-LAN IP addresses, you need to configure your routers to route traffic
for off-LAN IP addresses to Perimeta. To ensure that your traffic continues to flow after a Software

Protection Switch (SPS), you should configure the router to send off-LAN addressed traffic to the
MAC address associated with a regular, local IP address on the relevant service interface. This is
commonly referred to as a "static route" in router documentation.
Note:
For more information on off-LAN IP addresses, see Off-LAN IP addresses on page 30.
If you change the local IP address used by Perimeta on a subnet, you must also change any static
routes on your router that use the IP address. To do this without loss of traffic:
• add the new IP address to Perimeta

• update the router configuration
• remove the old IP address from Perimeta.
Additionally, your router must be configured to advertise a route to the off-LAN IP address. This can
involve setting the static configuration in another router, modifying BGP advertisement or configuring
other dynamic routing protocols; the way you approach this configuration is highly dependent on the
setup of your network, and is therefore beyond the scope of this Perimeta documentation.
Router configuration
We recommend the following configuration on routers that will route service traffic to and from
Perimeta.
• If possible, access control lists that only allow traffic to Perimeta from subnets that you know
contain peers, subscribers, etc.
• Reverse path forwarding to prevent IP spoofing.
• If you want traffic from specific remote subnets to be routed over different VLANs, you will need to
configure the gateway router or routers which route the traffic into your network to map it on to the
correct VLANs.
2.3.7 Traffic prioritization for quality of service
Information on how to prioritize signaling and media traffic in your network for the best quality of
service.
Perimeta uses Differentiated Services Code Point (DSCP) marking of IP packets to distinguish
between signaling and media for quality of service (QoS). You will need to configure devices that will
forward signaling and media traffic within your network to prioritize the traffic appropriately to achieve
the best QoS.
Media traffic needs low delay, low delay variation (jitter) and high reliability. Voice media traffic
has reasonably predictable bandwidth requirements based on the codecs used and the maximum
predicted number of concurrent calls. It does not make sense to queue media when traffic is
congested: much better to discard it (many media codecs can interpolate the media stream so that the
loss of small numbers of packets is not noticeable).

Signaling traffic can afford higher delay and delay variation but reliability is critical. A particular
signaling message not reaching its destination can prevent calls being successfully set up or torn
down. Queuing signaling packets is better than discarding them.
For these reasons, we recommend that you configure your network devices as follows.
• Forward media traffic with absolute priority up to a defined bandwidth allocation, with any
additional traffic discarded rather than queued.
• Allocate enough bandwidth for the maximum expected signaling traffic and allow it to be queued
with high priority.
As a rough guide to relative bandwidth requirements:
• When using a low-bandwidth media codec such as G.729 with a 20ms packetization interval,
SIP signaling is likely to represent less than 1% of all of your network traffic with media using the
remainder.
• When using a high-bandwidth codec such as G.711 with a 10ms packetization interval, the
proportion of traffic which will be signaling drops down to around 0.2%.
For more information on calculating the bandwidth requirements for your network, see Network
bandwidth requirements for Perimeta on page 62.
DSCP values
By default, Perimeta uses DSCP values of 24 for signaling and 46 for media, matching standard
industry practice. If you use different values in pre-existing network configuration, you can configure
your Session Controller to use different values. You can also configure it to use different values for
traffic to particular sets of endpoints, and to use different values for voice and video codecs; for more
information, see Packet marking in Perimeta Configuration and Interoperability Guide - CLI Users.

3 Example deployments
3.1 Example Perimeta deployment: integrated signaling and media
An example deployment including an ISC connected to various service networks.
This example deployment scenario for an ISC (a system with signaling and media functions integrated
in one Session Controller) is intended to illustrate some of the possible relationships between the
Session Controller and various service networks, as well as the management network. The structure
of the example deployment is shown in the diagram below.
3 Example deployments 69
Figure 5: Example integrated deployment
The ISC in this diagram is connected to the following six service networks (networks that carry
signaling and media traffic). It connects to some of these service networks over a local access
network, which is an Ethernet network connecting the ISC to gateways that route traffic between it and
the remote service networks.
• Two service networks within the network of the service provider (SP), one carrying signaling
traffic and one carrying media traffic. These are core service networks, containing service-critical
devices, such as a softswitch. These networks are trusted, unlike the customer service networks;
for information on the difference between trusted and untrusted networks, see Security and trust in
70 3 Example deployments
• The public internet, which is treated as a service network. Some customer Communications over
IP devices are located on the internet, and media traffic from customer 2 is sent directly over the
internet (rather than being tunneled).
• Customer 1 site A, which is a private WAN (wide area network) which connects directly to the local
access network via gateway 2, rather than through a tunnel over the internet.
• Customer 1 site B, which connects to the local access network over the internet using an IP tunnel.
• Customer 2, which uses an IP tunnel for signaling traffic, but uses the public internet service
network for media traffic.
Network details
IP addresses
In this deployment, the Session Controller exposes two IP addresses for service traffic, one public
address used for traffic to and from devices in the access service networks and one address used for
traffic to and from the softswitch. It also uses additional addresses in the management network; for
details see IP addresses for Perimeta on page 34.
Access service networks
The Session Controller exposes a public IP address, which is used by devices sending traffic directly
over the internet (in this case, media traffic from customer 2 in addition to traffic from the customer
Communications over IP devices located on the internet). It is also used by customer 1 for traffic from
site A, since that site has a direct connection to the Session Controller over the local access network.
The IP tunnels that carry all traffic to and from customer 1 site B and signaling traffic to and from
customer 2 terminate at the gateway to the local access network, which exposes it own public IP
address. Endpoints in the customer networks send packets to the Session Controller's public IP
address, and the gateways to those networks forward the packets over a tunnel to the gateway to
the local access network, by encapsulating them in packets sent to that gateway's IP address. The
gateway then removes the containers and forwards the original packets to the Session Controller's
public IP address over an individual VLAN (virtual local area network) for each service network (traffic
sent over the internet directly to the Session Controller's IP address is also assigned to a specific
VLAN). The use of VLANs allows the Session Controller to determine which service network traffic is
arriving from, and allows Gateway 2 to determine which service network outgoing traffic is intended
for. For more information on the use of VLANs, see VLAN support on page 27.
Customer 1 sites A and B are capable of communicating directly with each other, using NAT (Network
Address Translation) or IP tunneling. The Session Controller can be configured to perform media
bypass on calls between different endpoints within these sites, allowing media to travel directly
between the endpoints without passing through the Session Controller. This reduces latency and
network load. For more information on this feature, see Media bypass in Perimeta Configuration and
Core service networks
In this example, the service provider has chosen to segregate their signaling and media traffic onto
different core service networks. The Session Controller accomplishes this by sending signaling and
media traffic to the softswitch over different VLANs. This can make the different kinds of traffic more
easily manageable, and potentially improve security and reliability. For more information on this use of
VLANs, see VLAN support on page 27.
Management network
In addition to the six service networks, the Session Controller is connected to the management
network. This network carries management traffic only. The management network may contain
various management devices, including SSH clients used to configure the Session Controller, DNS
servers, and NTP servers. For more information on the management network, see Management
network and management interface on page 6.
Ethernet details
This section describes a possible Ethernet infrastructure (on Metaswitch CH6010 hardware) for the
service network connections in the deployment. The ISC is configured to use scheme 2 from Port
group schemes on page 14, which provides three redundant pairs of Ethernet ports for service traffic.
In this deployment, only two of these pairs are used; ports RPG5 and RPG6 are left as spares.
Figure 6: Service Ethernet connections
In total, four ports are connected on the access side and four on the core side. Note that only one
port on each side is in use at any one time: the currently active ports in the RPG1/RPG2 and RPG3/
RPG4 pairs on the processor blade on which the primary instance is running. The other ports provide
extensive redundancy in case of switch or processor blade failure.
3.2 Example Perimeta deployment: distributed signaling and media
An example deployment showing the potential uses of a distributed Perimeta installation.
This example deployment scenario for a distributed Perimeta system (a system using separate
devices for signaling and media functions) is intended to illustrate some of the possible uses of such
a system. This example has been simplified for that purpose, and does not include service networks
other than the public internet and core service networks containing the service provider's service-
critical devices. It also omits the management network. For a description of an example deployment
(using a combined system) that includes the management network and other kinds of service network,
see Example Perimeta deployment: integrated signaling and media on page 69.
The structure of the example deployment is shown in the diagram below.
Figure 7: Example Perimeta distributed deployment
In this example deployment, a single SSC controls two MSCs running as high availability systems.
The SSC deals with signaling traffic and the MSCs deal with media traffic. For more information on
the roles these devices play in a Perimeta deployment, see SSC, MSC, and ISC in Perimeta Product
Description.
Note:
In a virtualized environment or on a commercial off-the-shelf (COTS) hardware platform, it would

be possible to use MSCs running as standalone systems in place of the MSCs running as high
availability systems. In this case, the SP would need to deploy at least two standalone systems
in place of each high availability system to maintain redundancy in the deployment. For more
information on high availability and standalone systems, see High availability and standalone
systems in Perimeta Product Description.
It is also possible for a Perimeta SSC to control third-party MSCs. Perimeta MSCs must be
controlled by a Perimeta SSC.
This example deployment is designed for a service provider (SP) who has customers distributed
between two different cities (New York and Newark, in this case) and wants to avoid media streams
between endpoints in the same city being routed outside of the city, to reduce costs and latency.
The SP also wants to minimize costs by employing a single signaling device for their deployment, in
New York. Since SIP signaling has lower bandwidth and Quality-of-Service requirements than media
traffic, the benefits that apply to the distributed media system do not apply to signaling. The distributed
Perimeta system allows the SP to implement these different approaches to signaling and media.
Service providers may also use distributed deployments to make use of the scaling capability provided
by additional MSCs.
Network details
The SP has part of its wide area network at the exchange in each city. All SIP signaling traffic (used
to set up calls) passes over the internet and through the SSC to the softswitch in New York. The SSC
and the softswitch set up calls so as to minimize media traffic between the two cities. To do this, each
MSC is configured with a different media location. For information on media locations, see Media
locations in Perimeta Configuration and Interoperability Guide - CLI Users. For information on how
to configure media locations to control which MSCs are used for which traffic, see Configuring media
locations on an MSC and Configuring the media location for an adjacency or traffic group in Perimeta
In this example, the service provider network is split into three service networks (networks that carry
signaling or media traffic), one for SIP signaling traffic, one for media traffic, and one for H.248
signaling traffic. H.248 signaling is used by the SSC and MSCs to communicate with each other; only
SIP is supported for call setup. The segregation of traffic can make the different kinds of traffic more
easily manageable, and potentially improve security and reliability. In this deployment the different
kinds of traffic pass to and from the Session Controllers over separate physical links; see Ethernet
details on page 76 for details.
Note:
The segregation described above is not mandatory. You can choose to use a single service
network for all core traffic.
Once a call has been set up, media traffic passes from the endpoints to the core service network
at the local exchange (possibly over high-speed direct links between the exchange and the SP's
customers), through one of the MSCs. If both endpoints are in the same city, the media traffic does
not need to be passed through any of the devices located in the other city.
This example also includes media gateways in the core service networks, which are used by the
SP to allow lawful intercept to be performed on calls made through a Session Controller. A media
gateway in each city is required, so that media does not have to leave the city to be passed through
the gateway. In the New York exchange, the media gateway is integrated with the softswitch. If
provisions for lawful intercept were not required, the SSC could be configured to set up calls between
endpoints in the same city so that media was transmitted directly between the endpoints and did
not have to pass through the exchange. For more information on this feature, see Media bypass in
Ethernet details
This section describes a possible Ethernet infrastructure (on Metaswitch CH6010 hardware) for the
service network connections in the deployment.
SSC
The SSC in this deployment is configured to use scheme 2 from Port group schemes on page 14. This
provides three redundant pairs of non-aggregated ports. Two of these pairs are used for SIP traffic (on
the core and access sides) and one is used for H.248 traffic to control the MSCs.
Figure 8: SSC service Ethernet connections
Note that redundancy is provided in case of failure of both a switch and the platform on which an
instance is running.
MSCs
Both MSCs have equivalent Ethernet connections. They are configured to use scheme 6 from Port
group schemes on page 14, which provides two aggregated ports (RPG1/RPG2 as bond0 and RPG3/
RPG4 as bond1) and one redundant pair of single ports (RPG5 and RPG6). The aggregated ports are
used for media on the core and access sides and the pair of redundant ports are used for H.248.
Note:
The following diagram shows the MSC operating as a high availability system, but would apply
equally to two MSCs deployed as standalone systems.
Figure 9: MSC service Ethernet connections

Perimeta Network Integration Guide: PMC-008 - Version 4.7.20 - Issue 1-406

Uploaded by

Copyright:

Available Formats

Perimeta Network Integration Guide: PMC-008 - Version 4.7.20 - Issue 1-406

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Perimeta Network Integration Guide: PMC-008 - Version 4.7.20 - Issue 1-406

Uploaded by

Copyright:

Available Formats

CONFIDENTIAL

Perimeta Network Integration Guide

PMC-008 - Version 4.7.20 - Issue 1-406

2 Perimeta in your network

Details of how Perimeta connects to your network.

See the following for more information:

2 Perimeta in your network 5

Network planning considerations

• How many connections to different networks you plan to use.

You may also find the following information useful.

2.1 Management network and management interface

6 2 Perimeta in your network

Devices in the management network

• SSH (Craft Terminal, CLI).

2 Perimeta in your network 7

Configuring management IP addresses

8 2 Perimeta in your network

• The virtual management IP address is 198.2.1.249.

• The IP address for the CLI client is 198.2.254.1.

2 Perimeta in your network 9

Management interface requirements

10 2 Perimeta in your network

Management interface monitoring and Ethernet switchover

Management interface monitoring

Ethernet switchover and software protection switch on high availability systems

2 Perimeta in your network 11

2.2 Service networks

2.2.1 Ethernet ports and port groups

Aggregated ports are named bond0, bond1, and so on.

Aggregated port means the same as bonded port.

12 2 Perimeta in your network

By default, Perimeta uses static aggregation.

Port group schemes

2 Perimeta in your network 13

Requirements for local area networks

2.2.2 Port group schemes

• Metaswitch CH6010 hardware on page 15

14 2 Perimeta in your network

Metaswitch CH6010 hardware

Figure 2: Port group schemes for Metaswitch CH6010 hardware

2 Perimeta in your network 15

Six 1Gb/s links without on-instance redundancy

There are no aggregated ports in this scheme.

Three 1Gb/s links with on-instance redundancy

There are no aggregated ports in this scheme.

There are three port groups.

Three 2Gb/s aggregated links without on-instance redundancy

There are three port groups.

• One contains bond0.

16 2 Perimeta in your network

• One contains bond2.

There are four port groups.

• One contains bond0.

There are four port groups.

• One contains bond0.

2 Perimeta in your network 17

There are two port groups.

• One contains bond0 and bond1 as a redundant pair.

Commercial off-the-shelf (COTS) hardware - two ports