You are on page 1of 87

SR-S4500 v.1.5.

4
Traffic Switch administration

2015 SwitchRay Inc.

SR-S4500
VoIP traffic management system

Document type

Traffic Switch administration

Software version

1.5.4

Release date

09.02.2015

Department

Documentation Dept.

SwitchRay Inc. reserves the right to change any information contained in this document
without prior notice.

COPYRIGHT INFORMATION

The information contained in this document is the property of SwitchRay Inc.


All rights reserved. No parts of this work may be reproduced in any form or by any means - graphic,
electronic, or mechanical, including photocopying, recording, taping, or information storage and retrieval
systems - without the written permission of SwitchRay Inc.
No third party, organization or individual, is authorized to grant such permission.
Products that are referred to in this document may be either trademark s and/or registered trademark s of
the respective owners. The publisher and SwitchRay Inc. mak e no claim to these trademark s.
While every precaution has been tak en in the preparation of this document, the publisher and the author
assume no responsibility for errors or omissions, or for damages resulting from the use of information
contained in this document or from the use of programs and source code that may accompany it. In no
event shall the publisher and the author be liable for any loss of profit or any other commercial damage
caused or alleged to have been caused directly or indirectly by this document.

Connecting the World for a Brighter Future


25910 Acero, Ste 240, Mission Viejo, CA USA 92691 www.switchray.com

Traffic Switch administration

Table of Contents
1
Introduction

1.1

Document
...................................................................................................................................
profile
7

1.2

Audience
................................................................................................................................... 7

1.3

Notational
...................................................................................................................................
conventions
7

1.4

Names,
...................................................................................................................................
phone numbers and network addresses
8

1.5

List of...................................................................................................................................
acronyms
8

1.6

Related
...................................................................................................................................
documents
9

2 notes
Important

10

3 considerations
Security

11

3.1

List of
...................................................................................................................................
open ports
11

Traffic 4
Switch overview

12

4.1

Traffic
...................................................................................................................................
Switch functions
12

4.2

Traffic
...................................................................................................................................
Switch nodes
12

4.3

Architecture
................................................................................................................................... 13

4.4

Fault...................................................................................................................................
tolerance
13

4.5

Hardware
...................................................................................................................................
and software requirements
14

4.6

Phoenix
...................................................................................................................................
process
14

4.7

StateStore
...................................................................................................................................
process
14

5 Traffic Switch
Installing
5.1

15

Before
...................................................................................................................................
installation
15

15
5.1.1 Updating .....................................................................................................................................................................
Linux Kernel
15
5.1.2 Working .....................................................................................................................................................................
w ith MTA
16
5.1.3 Checking.....................................................................................................................................................................
repositories
..................................................................................................................................................................... 16
5.1.4 Tim e synchronization
17
5.1.5 Ensuring.....................................................................................................................................................................
system security
.....................................................................................................................................................................
17
5.1.6 Other preparation
steps in OS

5.2

How ...................................................................................................................................
to install Traffic Switch
18

How to 6start, stop or restart Traffic Switch

19

7
Configuring
Traffic Switch

20

7.1

How ...................................................................................................................................
to work with phoenix.conf
20

20
7.1.1 m anagem.....................................................................................................................................................................
ent com m and
.....................................................................................................................................................................
20
7.1.2 phoenix com
m and

2015 SwitchRay Inc.

Traffic Switch administration

.....................................................................................................................................................................
21
7.1.3 statestore
com m and
21
7.1.4 load com.....................................................................................................................................................................
m and

7.2

How ...................................................................................................................................
to work with system.conf
22

.....................................................................................................................................................................
22
7.2.1 system .conf
syntax
.....................................................................................................................................................................
23
7.2.2 Configuring
IP zones
7.2.2.1 What
...........................................................................................................................................................................
is an IP zone?
23
7.2.2.2 How
...........................................................................................................................................................................
to configure IP zones
24
.....................................................................................................................................................................
25
7.2.3 Configuring
locations
7.2.3.1 What
...........................................................................................................................................................................
is a location?
25
7.2.3.2 How
...........................................................................................................................................................................
to configure locations
26
.....................................................................................................................................................................
26
7.2.4 Configuring
nodes
7.2.4.1 Common
...........................................................................................................................................................................
sections
27
.........................................................................................................................................................
27
Section
"common"
.........................................................................................................................................................
28
Section
"controllink"
7.2.4.2 H.323
...........................................................................................................................................................................
balancer node
29
7.2.4.3 Signaling
...........................................................................................................................................................................
node
30
7.2.4.4 Media
...........................................................................................................................................................................
node
31
7.2.4.5 trafficmanager
...........................................................................................................................................................................
node
32
7.2.4.6 Synchro
...........................................................................................................................................................................
node
33
7.2.4.7 TS...........................................................................................................................................................................
configurator
34
7.2.4.8 SIP
...........................................................................................................................................................................
proxy node
35

7.3

How ...................................................................................................................................
to configure SIP sockets
35

.....................................................................................................................................................................
35
7.3.1 Using internal
netw ork
.....................................................................................................................................................................
37
7.3.2 Using external
netw orks
38
7.3.3 Using one.....................................................................................................................................................................
external address

8 Traffic Switch administration console


Accessing
8.1

Administration
...................................................................................................................................
console commands
40

9
Load balancing
9.1

40
41

How ...................................................................................................................................
TS balances load
41

.....................................................................................................................................................................
41
9.1.1 How TS balances
incom ing SIP and H.323 calls
42
9.1.2 What are .....................................................................................................................................................................
load balancing groups?
9.1.2.1 How
...........................................................................................................................................................................
TS balances incoming SIP and H.323 traffic
42
9.1.2.2 How
...........................................................................................................................................................................
TS balances outgoing SIP traffic
42
.....................................................................................................................................................................
42
9.1.3 How TS balances
m edia

9.2

How ...................................................................................................................................
to configure balancing of incoming traffic
43

9.3

How ...................................................................................................................................
to configure balancing of outgoing SIP traffic
45

9.4

Using
...................................................................................................................................
optional media balancing method
46

Traffic10
limitation
10.1

48

SIP traffic
...................................................................................................................................
limitation
48

.....................................................................................................................................................................
48
10.1.1 How Traffic
Sw itch lim its SIP traffic
10.1.1.1 What
...........................................................................................................................................................................
is a realm?
48
10.1.1.2 How
...........................................................................................................................................................................
TS limits CPS/RPS/OoDRPS
49
10.1.1.3 What
...........................................................................................................................................................................
is a queue?
49
10.1.1.4 How
...........................................................................................................................................................................
TS selects a queue for requests from a realm
49
10.1.1.5 How
...........................................................................................................................................................................
TS limits requests on queues
50

2015 SwitchRay Inc.

Traffic Switch administration

.....................................................................................................................................................................
50
10.1.2 How to configure
realm s
.....................................................................................................................................................................
52
10.1.3 How to lim
it CPS/RPS/OoDRPS for SIP traffic
.....................................................................................................................................................................
53
10.1.4 How to lim
it requests on queues
10.1.4.1 How
...........................................................................................................................................................................
to configure selection of queue on a realm
53
54
Queue.........................................................................................................................................................
type selection parameters
10.1.4.2 How
...........................................................................................................................................................................
to limit requests on queues
54
.....................................................................................................................................................................
55
10.1.5 Changing
interval for EMA calculation of average values

10.2

H.323...................................................................................................................................
traffic limitation
55

.....................................................................................................................................................................
56
10.2.1 How Traffic
Sw itch lim its H.323 traffic
.....................................................................................................................................................................
56
10.2.2 How to lim
it CPS/RPS for H.323 traffic
.....................................................................................................................................................................
56
10.2.3 Changing
interval for EMA calculation of CPS/RPS

11 with nodes
Working

58

11.1

How ...................................................................................................................................
to add new nodes
58

11.2

How ...................................................................................................................................
to change node configuration
59

11.3

How ...................................................................................................................................
to restart nodes
59

11.4

How ...................................................................................................................................
to remove nodes
59

12
Monitoring
and notification
12.1

61

Monitoring
................................................................................................................................... 61

.....................................................................................................................................................................
61
12.1.1 CLI m onitoring
tools
12.1.1.1 List
...........................................................................................................................................................................
of CLI monitoring tools and commands
61
12.1.1.2 Using
...........................................................................................................................................................................
shortcuts
62
12.1.1.3 Sw
...........................................................................................................................................................................
itching betw een tools
63
12.1.1.4 Using
...........................................................................................................................................................................
regular expressions
63
.....................................................................................................................................................................
65
12.1.2 TS counters
12.1.2.1 What
...........................................................................................................................................................................
are TS counters?
65
12.1.2.2 List
...........................................................................................................................................................................
of TS counters
65
12.1.2.3 How
...........................................................................................................................................................................
to monitor TS counters
66

12.2

Notification
...................................................................................................................................
sending
66

67
12.2.1 TS alarm.....................................................................................................................................................................
s
12.2.1.1 Common
...........................................................................................................................................................................
alarms
67
12.2.1.2 Management
...........................................................................................................................................................................
node alarms
67
12.2.1.3 Signaling
...........................................................................................................................................................................
node alarms
68
12.2.1.4 H.323
...........................................................................................................................................................................
balancer node alarms
68
12.2.1.5 SIP
...........................................................................................................................................................................
proxy node alarms
68
12.2.1.6 Media
...........................................................................................................................................................................
node alarms
69
12.2.1.7 trafficmanager
...........................................................................................................................................................................
node alarms
69
69
12.2.2 Sending.....................................................................................................................................................................
em ail notifications
12.2.2.1 How
...........................................................................................................................................................................
to notify about changes in TS counters
70
12.2.2.2 How
...........................................................................................................................................................................
to avoid repetitive notifications
71

12.3

Working
...................................................................................................................................
with SNMP
71

.....................................................................................................................................................................
71
12.3.1 How Traffic
Sw itch w orks w ith SNMP
.....................................................................................................................................................................
72
12.3.2 TS private
enterprise MIB file
.....................................................................................................................................................................
72
12.3.3 How to configure
SNMP agent
.....................................................................................................................................................................
73
12.3.4 How to define
list of counters to be m onitored via SNMP
.....................................................................................................................................................................
74
12.3.5 How to send
SNMP traps
12.3.5.1 How
...........................................................................................................................................................................
to configure snmptrapd
74

2015 SwitchRay Inc.

Traffic Switch administration

12.3.5.2 How
...........................................................................................................................................................................
to configure mvts3g-mail for SNMP traps sending
75

13logging
System
13.1

76

Phoenix
...................................................................................................................................
logging
76

.....................................................................................................................................................................
76
13.1.1 How to change
phoenix.log filenam e or location
.....................................................................................................................................................................
76
13.1.2 How to disable
TS logging in /var/log/syslog
.....................................................................................................................................................................
77
13.1.3 How to get
separate logs for TS nodes

13.2

TS nodes
...................................................................................................................................
logging
77

.....................................................................................................................................................................
78
13.2.1 How to control
logging in the section com m on
.....................................................................................................................................................................
78
13.2.2 How to control
logging of TS configurator
.....................................................................................................................................................................
79
13.2.3 How to extract
logs of individual call sessions

13.3

How ...................................................................................................................................
to get runtime information of TS nodes
79

13.4

How ...................................................................................................................................
to configure rotation of logs
79

.....................................................................................................................................................................
80
13.4.1 Configuring
rotation of traffic.log and phoenix.log
.....................................................................................................................................................................
80
13.4.2 Configuring
rotation of TS configurator logs
81
13.4.3 Rotating.....................................................................................................................................................................
logs every X m inutes
.....................................................................................................................................................................
81
13.4.4 traffic.log
rotation periods
81
13.4.5 Rotating.....................................................................................................................................................................
RTINFO and dum p files

14 A. Example of TS configuration files


Appendix

83

2015 SwitchRay Inc.

Introduction | 7

1 Introduction
1.1 Document profile
This document provides an overview of the SR-S4500 component Traffic Switch, describes how it works and
gives instructions on its configuration.

1.2 Audience
This document is intended for Internet telephony service providers interested in finding a resolution to
complex transit problems and administrators responsible for deployment, operation and maintenance of SRS4500 systems. Readers of this document are expected to have knowledge of UNIX-like operating systems
and network protocols.

1.3 Notational conventions


Example

Convention

Text
Important information requiring special attention.

Reference information and additional details.

Note: text

#> /etc/init.d/mvts3g-server-pro
restart

OS Linux console commands.

local5.*

Examples of Traffic
configuration files.

-/var/log/mvts3g/phoenix.log

Switch

and

OS

Linux

Example:
Examples which help understand the matter.

Text

Traffic Switch > TS configuration

Name

2015 SwitchRay Inc.

Web interface objects or categories using which you


can configure a feature described in the section of
the manual, or web interface objects or categories
described in the section of the manual.
Names of web interface parameters, controls,
objects, system files or folders.

8 | Traffic Switch administration

1.4 Names, phone numbers and network addresses


All IP addresses, domains, user login names and phone numbers used for the purposes of this document are
fictitious and any resemblance or similarity to real-life objects and/or individuals is purely accidental.

1.5 List of acronyms


Term

Explanation

ARQ

Admission Request.

ASR

Answer Seizure Ratio.

CIDR

Classless Inter-Domain Routing.

CLI

Command Line Interface.

CPS

Calls per second.

DBMS

Database management system.

EMA

Exponential moving average.

ENUM

Telephone Number Mapping (from TElephone NUmber Mapping).

H.323

An ITU-T recommendation that defines the protocols to provide audio-visual


communication sessions on any packet network.

LDC

Local disconnect code.

LRQ

Location Request.

MTA

Mail Transfer Agent.

OoDRPS

Out-of-dialog requests per second.

RAS

Registration, Admission and Status.

RBT

Ring-back Tone.

RFC

Request For Comments.

RPS

Registrations per second.

RTP

Real-time Transport Protocol.

SIP

Session Initiation Protocol.

SNMP

Simple Network Management Protocol.

TMngr

Traffic Manager, the SR-S4500 core element designed for call routing, analysis of data
streams passage along the routing paths with allowance made for QoS and profitability
and ensuing optimization of traffic distribution among the route alternatives.

TS

Traffic Switch, an application functioning as a session border controller that handles calls
under the control of TMngr.

VoIP

Voice over Internet Protocol.

2015 SwitchRay Inc.

Introduction | 9

1.6 Related documents


The supporting documentation for SR-S4500 1.5.4 includes the following documents:
Document title

2015 SwitchRay Inc.

Description

API for external applications

Contains the detailed instruction on how to configure external


applications interacting with the System.

Disk space monitoring

Describes how to configure the utilities for monitoring of free


disk space on servers hosting SR-S4500.

Functional Specification

Describes the SR-S4500 functional specification, i.e. general


overview of the System, its hardware and software
requirements, supported codecs, protocols and standards, etc.

How tos

Presents tips and real-life instructions on how to accomplish


business-critical tasks in SR-S4500. The instructions are
illustrated with real-life examples.

Local Disconnect codes

Describes local disconnect codes (LDCs) generated by the


System. Using this document you will know why a particular
code appears and what you can do to optimize your network. It
will help you to quickly identify and solve problems with your
traffic and to increase the amount of successful calls handled
by your System.

Operator's manual

Provides the complete overview of the SR-S4500 application, a


carrier-grade solution for efficient policy routing of VoIP
traffic.

Quick Start Guide

Explains how to set up SR-S4500 for initial use and how to


begin using the System. The content of this document
presumes that SR-S4500 has been properly installed and
deployed on the user network. The document covers only
essential features.

Traffic Switch administration

This document provides the complete overview of the SRS4500 component Traffic Switch.

10 | Traffic Switch administration

2 Important notes
If you are going to change time on the server hosting the trafficmanger node, change the value of
the node_id parameter in the configuration of the node and reconfigure Traffic Switch. Otherwise,
identifiers of CDRs will be no longer unique.

2015 SwitchRay Inc.

Security considerations | 11

3 Security considerations
To prevent unauthorized access, restrict availability of the System from all IP addresses, but for those
required for System functioning. Use your firewall to block access to:
control link sockets of all TS nodes from all addresses, except those that are required for the nodes to
interoperate with each other. It is recommended to use private IP addresses when configuring control
links
the H.323 balancer node from all addresses, except those from which the System receives and where the
System sends traffic
the SIP proxy node from all addresses, except those from which the System receives and where the
System sends traffic
the management node TCP port (9000) from external networks
the command line node over the telnet protocol from all addresses, except trusted (SwitchRay Inc.
technical support and the System owner)
the System servers over the SSH protocol from all addresses, but for required (for SwitchRay Inc.
technical support and the System owner)

3.1 List of open ports


The table below presents the list of ports to be open on the servers hosting TS (in its minimum configuration
layout, without additional signaling and H.323 balancer nodes).
Protocol

Port

TCP

22

TCP

1720

TCP

Description

Notes

SSH connection

The default port that can be changed to any other.

H.323, H.225
signaling

The default port as defined in the H.323 balancer node


configuration file. Can be changed to any other.

The range from


H.323, H.245
1024 through
signaling
65535

Used if the H.245 Tunneling is disabled.

UDP

1719

RAS messages

The default port as defined in the H.323 balancer node


configuration file. Can be changed to any other.

UDP

5060

SIP signaling

The default ports as defined in the SIP proxy node


configuration. Can be changed to any other.

UDP

The range from


1024 through RTP, media traffic
65535

It is highly recommended to open the port range


defined in the media node configuration file only.
Please verify that the range begins with an even
number and ends with an odd number. Otherwise it may
cause periodic errors when opening media addresses.

It is strictly advised to use TCP ports different from those provided in configuration examples
found in this document.

2015 SwitchRay Inc.

12 | Traffic Switch administration

4 Traffic Switch overview


Traffic Switch is the switching layer of the SR-S4500 system. Traffic Switch handles SIP and H.323 calls and
perform two-way conversion of signaling protocols and voice codecs when necessary. Additionally, Traffic
Switch is the primary source of call statistics that is analyzed and visualized by means of Traffic Manager.

4.1 Traffic Switch functions


Below is an overview of TS functionalities:
SIP (RFC 3261) and H.323 v2-v4 call handling, two-way conversion of the signaling protocols
SIP-T/SIP-I pass-through
Conversion of voice codecs (G.729, G723.1, G.711A/U, GSM FR, Speex, iLBC, AMR NB, G.726)
RTP media proxy options (full proxy and signaling proxy operation only)
SIP and H.323 video pass-through using H.261, H.263, H.264 codecs
Fully distributed architecture (assures enhanced dependability and almost unlimited scalability of the
System)
Command-line interface for system administration
SNMP monitoring and SNMP traps sending
Email notification
The full list of TS functions and supported protocols can be found in the SR-S4500 v.1.5.4 Functional
specification.

4.2 Traffic Switch nodes


Traffic Switch comprises the following functional nodes, each one being an individual process:
Management node ensures distribution of configuration data between other TS nodes, provides
centralized control over them and serves as a collection point for the System statistics.
H.323 Balancer node serves as the entry point for H.323 traffic. The node handles H.323 registration
(RAS) requests and provides load balancing between the signaling nodes. When a user (calling device)
tries to register with the System, the H.323 balancer node forwards relevant data to Traffic Manager.
Depending on the response received, the registration request is either accepted or rejected. Load
balancing is based on the current ASR value of each signaling node (see also How TS balances
incoming SIP and H.323 calls).
SIP proxy node serves as the entry and exit point for SIP traffic. The node does not store any of the call
states and simply balances arriving SIP calls/registrations between the signaling nodes.
Signaling node provides two-way conversion of SIP/H.323 signaling protocols and traffic distribution
(load balancing) between media nodes (based on the current CPU load of each media node). Also, the
signaling node handles SIP registrations.
Media node handles media flows, functions as an RTP media proxy and performs conversion of voice
codecs. The number of media nodes needed in SR-S4500 depends on the anticipated number of
concurrent call sessions that involve RTP media proxy operation.
Command line node is a telnet server that allows users to log on to a switching host using any telnet
client.
trafficmanager node ensures interaction between TS and TMngr by means of DBMS clients. It is also
responsible for interaction with external billing systems and ENUM registers, codec sorting and
distributing calls between termination devices within equipment groups.
TS configurator transfers configuration data from DB to TS internal tables and vice versa. On the DB
side the configurator-related settings are located in the category of objects Traffic Switch. The TS
configurator interacts only with two DBs (primary and failover).
Synchro node ensures control over the used resources.

2015 SwitchRay Inc.

Traffic Switch overview | 13

The capacity of Traffic Switch can be scaled up by adding more nodes. Additional nodes can be installed on
any number of servers.

4.3 Architecture
The picture below shows the general Traffic Switch layout.

Traffic Switch architecture


Depending on the System capacity requirements Traffic Switch nodes can run on dedicated servers or share
a single hardware platform. For instance, with the traffic load of several dozens simultaneous call sessions a
single-server installation will perfectly do the job. In case of larger traffic loads, you can allocate individual
servers for, say, media nodes, the most demanding application in terms of computing power.

4.4 Fault tolerance


The fault tolerance of Traffic Switch is ensured by the possibility to start and run several nodes of identical
functionality (signaling and media nodes). In addition, Traffic Switch features a background autorecovery
service called Phoenix, designed to restore the node serviceability in case of a failure.
The fault tolerance of the traffic entry point is ensured by running two H.323 balancer / two SIP proxy nodes
on different IP addresses.

2015 SwitchRay Inc.

14 | Traffic Switch administration

4.5 Hardware and software requirements


Traffic Switch is designed to run on Debian GNU/Linux 6.x (Squeeze) and 7.x (Wheezy) with 64-bit kernel and
32-bit operating environment. Owing to the distributed architecture of Traffic Switch the hardware
requirements for the platform intended to host the system fully depend on the projected system performance
and the selected method of redundancy. For more information about TS hardware requirements, refer to the
SR-S4500 v.1.5.4 Functional specification.

4.6 Phoenix process


Phoenix is a functional process included in Traffic Switch. In distributed multi-server layouts each Traffic
Switch server runs its own Phoenix.
Phoenix performs the following functions:
starts up the nodes installed on the Traffic Switch server;
lets the nodes know the IP address and port of the management node to connect to;
restarts crashed nodes;
launches the so-called StateStore process.

4.7 StateStore process


StateStore is a process that serves as a storage of working data from the TS nodes. For instance, the
signaling and media nodes use this process to keep information that might be necessary for recovery or
proper completion of calls in case of failures; the management node uses StateStore to keep the TS
configuration in binary form. The process runs on each server hosting TS components.

2015 SwitchRay Inc.

Installing Traffic Switch | 15

5 Installing Traffic Switch


5.1 Before installation
Before installing Traffic Switch:
1. Update Linux kernel.
2. Configure the Exim 4 mail transfer agent.
3. Check lists of repositories.
4. Configure time synchronization.
5. Ensure system security.
6. Perform other actions in OS.
See also Hardware and software requirements.

5.1.1 Updating Linux Kernel


As the default Linux kernel allows using only 3.6 Gb RAM, we recommend to replace it with 64 bit kernel on
servers with 64 bit CPUs.
To check if your CPU is 64 bit, run the following command:
#> sudo cat /proc/cpuinfo

The command output should contain the lm flag.


After that do the following:
1. Install 64 bit kernel:
#> sudo aptitude install linux-image-amd64 irqbalance

Upon the prompt saying "Would you like to balance the IRQs once?" answer "No".
2. Reboot the server:
#> reboot

3. If necessary, choose the proper kernel (installed in Step 1) in boot loader.

5.1.2 Working with MTA


TS notification function requires a mail transfer agent (MTA) which supports the sendmail syntax (see http://
www.sendmail.org/releases/).
It is recommended to use MTA Exim 4 on all TS servers, even if you are not planning to send
notifications. If, for any reason, you prefer some other MTA, it should be installed prior to Traffic
Switch installation. In this case, you are fully responsible for correct functioning of your SMTP
server and the notification function.
To install Exim 4, run:
#> aptitude install exim4

To configure Exim, run:

2015 SwitchRay Inc.

16 | Traffic Switch administration

#> dpkg-reconfigure exim4-config

Follow the instructions onscreen. In the most common scenario, you may simply press Enter 7 times to get
the SNMP server working only on the local address and receiving emails only from applications which run on
this server. After the configuration, Exim will start automatically.
To cancel email notification, disable Exim in OS Debian startup:
#> update-rc.d -f exim4 remove

To stop the MTA service without rebooting the System:


#> /etc/init.d/exim4 stop

To activate the Exim process:


#> update-rc.d -f exim4 enable

For more information about configuring notifications, refer to the section of Notification sending.

5.1.3 Checking repositories


Before installing Traffic Switch, open the following plain-text files:
/etc/apt/source.list
/etc/apt/sources.list.d/*.list
Make sure that in each of these files all addresses are from official Debian mirrors (http://www.debian.org/
mirror/list) and all distros match the distro of the OS. If it is not so, delete such lines or add them to the list of
exceptions. If a repository address will not be present in the list of exceptions or in the official Debian mirrors,
the installation script will display an error and will stop.
The list of exceptions is written in a plain-text file, where each line is a repository address. For example:
http://ftp.debian.org/debian
http://http.debian.net/debian
ftp://ftp.us.debian.org/debian

Save the file anywhere you wish and complete other preparation steps. Then, during the installation you will
just have to run the installation script with the extended-list-rep key:
#> ./mvtsii_ts_and_logic-1.5.x-yyz_4.w.x-yyz_os_arch.sh extended-list-rep <the
absolute path to the file of the list of exceptions>

For example:
#> ./mvtsii_ts_and_logic-1.5.4-20j_4.6.0-12a_squeeze_i386.sh extended-list-rep /
tmp/ext_rep.txt

5.1.4 Time synchronization


To avoid call routing problems, configure regular time synchronization and one and the same time zone on all
TS servers (run the commands below as root):
1. Make the one-time synchronization:
#> ntpdate pool.ntp.org

2015 SwitchRay Inc.

Installing Traffic Switch | 17

2. Restart the ntpd service:


#> /etc/init.d/ntp restart

Time synchronization is performed by the ntpd service only. Do not run the ntpdate command after
the Traffic Switch installation.
If you configured time synchronization after installation of Traffic Switch, restart it (see How to
start, stop or restart Traffic Switch).

5.1.5 Ensuring system security


1. Block access to TCP port 9000 from external networks. This port should be available only for TS nodes and
the DB. For this add the following lines in the /etc/network/interfaces file:
pre-up /sbin/iptables -A INPUT -s [ IP_address ] -p tcp -m tcp --dport 9000 -j
ACCEPT
pre-up /sbin/iptables -A INPUT -p tcp -m tcp --dport 9000 -j REJECT
pre-down /sbin/iptables -D INPUT -s [ IP_address ] -p tcp -m tcp --dport 9000 j ACCEPT
pre-down /sbin/iptables -D INPUT -p tcp -m tcp --dport 9000 -j REJECT

2. Edit the /etc/ssh/sshd_config file, specifying only trusted IP addresses:


AllowUsers support@192.162.88.128/26

support@192.162.89.0/24 customer@0.0.0.0

Instead of customer@0.0.0.0 add users of this server with network addresses that will be
used to access the system.
3. Block SSH access for root:
# Authentication
#LoginGraceTime 2m
PermitRootLogin no
#StrictModes yes
#MaxAuthTries 6

4. Restart the SSH server:


#> /etc/init.d/sshd restart

5.1.6 Other preparation steps in OS


1. Change the hostname (for example, if the hostname is localhost):
#>
#>
#>
#>

nano /etc/hostname
nano /etc/hosts
/etc/init.d/hostname.sh start
reboot

2. Add the support user (if not yet created) that will be used by the SwitchRay Inc. technical support
engineers:
#> adduser support

3. Edit the sudoers file (requires the installed sudo packet):

2015 SwitchRay Inc.

18 | Traffic Switch administration

#> visudo -f /etc/sudoers

Add into this file the following line:


support ALL=(ALL) ALL

4. Add the customer user that will be used by the system administrator and/or operator:
#> adduser customer

5.2 How to install Traffic Switch


The TS software is supplied as an installation package mvtsii_ts_and_logic-1.5.x-yyz_4.w.x-yyz_os_arch.sh,
where:
1.5.x-yyz DB version number;
4.w.x-yyz TS version number;
os_arch Linux OS version and kernel architecture.
For example, mvtsii_ts_and_logic-1.5.4-20j_4.6.0-12a_squeeze_i386.sh.
The installation of the supplied package is standard and does not require any special knowledge (refer to the
Debian documentation for information about package management procedures). If you plan to deploy the
system on multiple servers, install the TS software on all the servers involved.
To install Traffic Switch:
1. Make the installation script executable:
#> chmod +x mvtsii_ts_and_logic-1.5.x-yyz_4.w.x-yyz_os_arch.sh

2. Run the installation:


#> ./mvtsii_ts_and_logic-1.5.x-yyz_4.w.x-yyz_os_arch.sh

If you created a file with repository exceptions, add to the end of this command the extended-listrep key with the path to this file (see Checking repositories).
Answer "yes" to any prompts during installation. Cancel the citadel-server configuration.
3. In any plain-text editor, open the file /etc/default/mvts3g-server-pro.
4. Change the value of the parameter AUTOSTART from no to yes:
DAEMON_OPTS="-f -c /etc/mvts3g/phoenix.conf"
AUTOSTART=yes

This will allow you to launch/stop/restart Traffic Switch and enable its automatic start up on OS boot.
5. Save the file /etc/default/mvts3g-server-pro.
6. To enable TS logging, restart rsyslogd:
#> service rsyslog restart

The installation is complete. You may now process to the configuration step.

2015 SwitchRay Inc.

How to start, stop or restart Traffic Switch | 19

6 How to start, stop or restart Traffic Switch


The Traffic Switch software deployed on a particular server is represented as the process called mvts3gserver-pro.
To start Traffic Switch, use the command:
#> /etc/init.d/mvts3g-server-pro start

To stop Traffic Switch, use the command:


#> /etc/init.d/mvts3g-server-pro stop

To restart Traffic Switch, use the command:


#> /etc/init.d/mvts3g-server-pro restart

Note: To run the commands above, in the file "/etc/default/mvts3g-server-pro", the value of the parameter
'AUTOSTART' should be switched to 'yes'.

2015 SwitchRay Inc.

20 | Traffic Switch administration

7 Configuring Traffic Switch


To configure Traffic Switch:
1. Insert the USB license dongles supplied with the installation package into USB ports of the servers
hosting TS:
the primary USB license dongle: the server with the primary management node.
the backup USB license dongle: the server with the backup management node.
2. On every TS server, create the file phoenix.conf, specifying load commands for all nodes which will run
on this server.
3. On the primary TS server, create the file system.conf with configuration of all nodes which will run on
all TS servers.
4. Start TS on every server.
5. On the primary TS server, access the TS console.
6. Run the config command (see Administration console commands).

7.1 How to work with phoenix.conf


The file /etc/mvts3g/phoenix.conf is a collection of commands, each line being a separate command. Phoenix
reads this file and functions according to the commands described there.
The example of the file phoenix.conf can be found in the Appendix A. Example of TS configuration files, as
well as in the /etc/mvts3g/examples directory.
You may edit these templates and save them as the regular file phoenix.conf.
To apply the changes made in the file, (re)start Traffic Switch (see How to start, stop or restart Traffic
Switch).

7.1.1 management command


This command defines IP addresses and ports of the primary and backup management nodes:
management primary=192.168.133.113:9000 backup=192.168.34.53:9001

If the management node runs locally, it will open a connection socket at the specified address and port. Other
nodes will expect to find the management node at the specified address.
Note: the command management must precede all load commands.
The primary and backup management nodes cannot run on the same server. Make sure that IP
addresses of the primary and backup management nodes are different. In case there is only one TS
server, omit the argument backup.

7.1.2 phoenix command


This command configures the behavior of the Phoenix process:
phoenix address=127.0.0.1:5000

Mandatory argument:

2015 SwitchRay Inc.

Configuring Traffic Switch | 21

address IP address and port of the Phoenix console.

Optional arguments:
timeout, count and sleep these parameters determine the restart behavior of crashed nodes and
have the following meaning: if a node crashes count times within timeout milliseconds, Phoenix
waits sleep milliseconds before restarting the crashed node. Default values: 7000 (timeout), 5
(count), 2000 (sleep).
cstimeout timeout in msec upon completion of which Phoenix performs non-graceful termination of

those nodes which failed be unloaded after the expiry of a specified graceful shutdown period. Default
value: 21000.
wdtimeout is-alive response time in msec. for nodes. The node is considered crashed, if it fails to
respond to challenges from Phoenix within the wdtimeout time. Default value: 30000.

Note: if any module stops responding to queries from Phoenix (as, for example, the trafficmanager
node does during a changeover from the primary to the backup DB), Phoenix keeps trying to restart
the non-responsive node again and again every time the wdtimeout period lapses. To avoid this,
increase the wdtimeout value to 40000 and above.
wdsleep length of the pause in msec. that Phoenix makes after sending a SIGSEGV to the inactive
node. If after the wdsleep timeout the faulty node still is not stopped, Phoenix sends it a SIGKILL

signal. Default value: 10000.


Please note that the value of the argument wdsleep must not be higher than the value of the
argument wdtimeout.
Note: the command phoenix must precede all load commands.

7.1.3 statestore command


This command determines the parameters of the StateStore process:
statestore db=/var/log/mvts3g/phoenix.db trafficlog=traffic.log

Both arguments are optional:


db specifies a path to the phoenix.db file which contains information necessary for nodes. Do not

touch.
trafficlog sets the path to the traffic.log file.

If all arguments are set to their default values, you may omit the statestore command altogether.
Note: the command statestore must precede all load commands.

7.1.4 load command


This command is an instruction to load a node of the type <node type> and having the name <node
name>:
load type=<node type> name=<node name>

For example:
load type=signaling name=signaling-1

There are arguments of the load command which are unique for some of the nodes:
Management node:

2015 SwitchRay Inc.

22 | Traffic Switch administration

mode the loaded management node is primary (mode=main) or failover (mode=backup).

Command line node:


address=127.0.0.1:7000

where 127.0.0.1:7000 is the IP address and port used by the command line node for incoming telnet
connections (see Accessing Traffic Switch administration console).
TS configurator:
capability=config (mandatory, do not touch)

7.2 How to work with system.conf


The file /etc/mvts3g/system.conf contains configuration data of:
IP zones (the section zone);
locations (the section location);
nodes of the same type (the sections media, signaling, balancer, etc.);
signaling balancing groups (the section balancing).
For more information about the layout of the file, see system.conf syntax. The example of the file system.conf
can be found in the Appendix A. Example of TS configuration files, as well as in the /etc/mvts3g/examples
directory.
Please note that there should be only one system.conf located on the server with the primary management
node.
To apply the changes made in the file, run the config command in the Traffic Switch administration console
(for more information, refer to the section Administration console commands).

7.2.1 system.conf syntax


Configuration data in the file system.conf is arranged in the following layout:
Configuration parameters should be written as sections and subsections enclosed in opening and
closing braces. The closing brace of a section and subsection must be followed by a semicolon (;).
A parameter value defined within a section becomes the default setting for all subsections nested
within the section. A parameter with the same name defined within a subsection overrides the general
setting configured outside the subsection and becomes a local setting valid for this subsection only.
You may use two types of comments: one-line comments, starting anywhere in a line with '//' characters
and extending to the end of the line, and multi-line comments starting with /* spanning several lines
and ending at the next */.
It is possible to include text from external files by means of the include keyword. This allows you to
place configuration data in a separate file. Please note that the include keyword allows you only to
divide the system.conf file into sections and to collect the sections into one configuration file when
configuring. The include keyword does not work when placed inside a section. For example, you may
create the file system-1.conf:
include
include
include
include
...

"/etc/mvts3g/system-1.zone.conf";
"/etc/mvts3g/system-1.balancer.conf";
"/etc/mvts3g/system-1.signaling.conf";
"/etc/mvts3g/system-1.media.conf";

The table below describes the syntax of the configuration file system.conf.

2015 SwitchRay Inc.

Configuring Traffic Switch | 23

Element
Section/
subsection

Format
name
{.
};

Example
zone
{
zone "local"
{
"127.0.0.0/8";
};
zone "intranet"
{
"194.112.160.0/24";
};
};

Parameter

name "value";

allow_chap "yes";

Value

"char string";

"127.0.0.0/8";

Comment

/*
*/

/* Use this section to configure signaling nodes */

Include an
external file

include "full
filename";

include "/etc/mvts3g/system-1.zone.conf";

7.2.2 Configuring IP zones


This section describes:
What is an IP zone?
How to configure IP zones

7.2.2.1 What is an IP zone?


An IP zone is a list of IP networks available in the Traffic Switch cluster. SR-S4500 uses IP zones:
to authenticate customers' equipment
to select source IP addresses when sending traffic to call termination equipment
for connection between TS nodes (control link zones)
to separate users of "hosted softswitch"
as part of the realm notion in the SIP proxy configuration
In the simplest configuration, there is one global IP zone which includes all available networks used for VoIP
traffic.
In a more complex scenario several zones can be defined. Assume that we have two TS servers and the
following zone configuration:

2015 SwitchRay Inc.

24 | Traffic Switch administration

Example of zone configuration


In this case, we use:
zone_ext1 for interworking with external equipment;
zone_hosted for authentication of users of "hosted softswitch";
internal for control link sockets;
zone_ustelecom for selection of the specific provider.

By way of example, suppose the signaling node on the TS-1 server needs to send a call to the address
81.10.1.1 using the IP zone "zone_ext1". In this case the IP 212.173.72.34 will be selected as the call source
address, because this IP belongs to the zone "zone_ext1".
A collection of networks in a zone is characterized by:
configured routing between the IP addresses of member networks that comprise the zone;
the absence of traffic limiting devices (firewalls, NAT routers etc.) within the zone.
Please note that each TS node should be able to work in every TS zone where legs of the same call exist.

7.2.2.2 How to configure IP zones


To configure IP zones:
1. Edit the zone section in the system.conf file. This section is a list of zones and networks that comprise
them. While adding zones you can use the following notations to describe IPv4 networks:
CIDR notation, i.e. xx.xx.xx.xx/yy, where xx.xx.xx.xx stands for the network address, and yy denotes
the number of bits in the network mask.
Common dot-separated method of writing IP addresses for IPv4 networks xx.xx.xx.xx/yy.yy.yy.yy,
where xx.xx.xx.xx stands for the network address, and yy.yy.yy.yy represents the network mask.
Make sure that each network belongs to one zone only.

Here is an example of correctly configured IP zones:

2015 SwitchRay Inc.

Configuring Traffic Switch | 25

zone
{
zone "local"
{
"127.0.0.0/8";
}
zone "internet"
{
"212.192.0.0/16";
};
zone "intranet"
{
"192.168.0.0/16";
};
};

Note: The configuration of any Traffic Switch server includes a pre-configured zone Local that
comprises the address 127.0.0.1, even if this is not defined explicitly in the 'zone' section. It makes
sense to reconfigure the zone Local only when you wish to expand the list of local addresses or
explicitly disallow local addresses altogether.
2. Save the file.
3. Access the TS console.
4. Run the config command (see Administration console commands).
5. Add the names of the zones you configured in Step 1 into the web interface table Equipment > Zones.
6. To make it possible assign IP zones when configuring SIP proxy nodes, add the names of the zones
you configured in Step 1 into the web interface table Traffic Switch > Traffic Switch configuration >
Zones.
The configuration is complete.

7.2.3 Configuring locations


This section describes:
What is a location?
How to configure locations

7.2.3.1 What is a location?


Locations are designed to simplify the provisioning of the "hosted softswitch" service and deployment of
geographically distributed Systems.
A typical use-case for the "locations" functionality is geographically distributed System, for example with
two Traffic Switch servers. One server is located in New York, the other is in Moscow, Russia. To avoid
situations when a half of NY-destined traffic is handled by the Moscow server and vice versa, we should
create two location sections in the configuration. In such a case NY-destined calls (both signaling and media)
will be handled by Traffic Switch located in NY, while Moscow-destined calls by the Moscow server. If we
decide to locate one more Traffic Switch server in another city, we will have to add the third location section
to the configuration file.

2015 SwitchRay Inc.

26 | Traffic Switch administration

7.2.3.2 How to configure locations


To configure Traffic Switch locations edit the "location" section of the file system.conf. The "location"
section comprises a list of locations, each of them associated with a certain list of Traffic Switch nodes and IP
zones:
location
{
location "location_name"
{
zones
{
// list of zones belonging to this location
"zone-1";
"zone-2";
};
nodes
{
// names of the nodes belonging to this location
"media-1";
"signaling-1";
};
}
};

TS nodes listed in different "location" sections are unable to interwork.

If no "location" sections are configured, it is implied that the System is not subdivided into separate localities
and all nodes belong to one implicit global "location" section.
When configuring locations, please pay special attention to the following rules:
1. Names of the Traffic Switch nodes must be unique.
2. Each Traffic Switch node can belong to one location only.
3. If a node name does not belong to any specific location, it is considered to belong to the "global"
location.
4. Each IP zone may belong to one location only.
5. If the location is not associated with any IP zone, the nodes, configured in this location, have access to
all IP zones defined in the configuration file.
When done, save the configuration file and apply the changes by running the config command in the
Traffic Switch administration console (for more information, refer to the section Administration console
commands).
As the result, TS will automatically establish control link connections between nodes (see Architecture)
which belong to one and the same location or to the "global" location.

7.2.4 Configuring nodes


The file system.conf allows configuration of TS nodes in the following sections:
balancer H.323 balancer node.
common all node types.
controllink all node types, except for signaling.
media media node.
scripting TS configurator.

2015 SwitchRay Inc.

Configuring Traffic Switch | 27

signaling signaling node.


sipproxy SIP proxy node.
synchro synchro node.
trafficmanager trafficmanager node.
Configuration of nodes of the same type can be done in a common file (for example, system-1.signaling.conf).
The general configuration file format is shown in the figure below:
[node type]
{
[common parameters for nodes of this type]
[node type] "[node name]"
{
[parameters and sections specific for this node]
};
};

where "[node name]" is the name of the node specified in the load command of the file phoenix.conf. All
configuration parameters in system.conf belonging to TS nodes are described further in this section of the
document.

7.2.4.1 Common sections


The configuration of any node includes at least two sections: an optional section common and the required
section controllink*.
common
{
loglevel "0";
};
controllink
{
zone "test";
port "7050";
};

Note: Configuration of the signaling node has no "controllink" section.


7.2.4.1.1

Section "common"
The section common is for settings that are common for all nodes of the type. The following parameters are
available:
Parameter

2015 SwitchRay Inc.

Description

Default value

loglevel

Controls logging of a signaling node, H.323 balancer 0


node (for details, refer to the section TS nodes logging).

link_send_timeout

Interval between sending activity packets from a node 10000 ms.


to another node along the control link, in ms. The value
should be multiple of 100.

link_recv_timeout

Timeout for receiving any packet from a remote packet 20000 ms.
along the control link, after which the TCP connection
between modules is considered severed, in ms. The
value should be multiple of 100.

28 | Traffic Switch administration

Parameter
link_restore_timeout

Description

Default value

Timeout that starts after TCP connection failure is 30000 ms.


detected. After the timeout the control link is considered
completely severed, in ms. The value should be multiple
of 100.

link_reconnect_interval Interval between attempts to restore the TCP connection 3000 ms.
within the link_restore_timeout period, in ms. The

value should be multiple of 100.


link_connect_interval

Interval between attempts to establish a TCP connection 3000 ms.


initially or after the control link is completely severed, in
ms. The value should be multiple of 100.

Note: The link_send_timeout value must be less than link_recv_timeout, otherwise TCP connections in
control links will constantly fail.
If all parameters are set to their default values, you may omit the common section altogether.
To define the above-mentioned intervals for all nodes (except for the command line node) create a global
common section in the configuration file. The contents of this section will automatically apply to all nodes.
In the section common, you can also configure nodes to dispatch email notifications on critical changes in
values of TS counters. For more information, please refer to the How to notify about changes in TS counters
section.
7.2.4.1.2

Section "controllink"
The controllink section specifies the zone and port combination for the node to open a socket for
incoming connections from other nodes. By default and if not defined, the port parameter is 0, which means
that the OS Linux assigns the port number.

2015 SwitchRay Inc.

Configuring Traffic Switch | 29

7.2.4.2 H.323 balancer node


A configuration example of an H.323 balancer node:
balancer
{
balancer "balancer-1"
{
common
{
loglevel "0";
};
controllink
{
zone "test";
port "7202";
};
ras
{
address
{
"0.0.0.0";
};
port
"1719";
gkname
"MVTS3G";
allow_md5
"yes";
allow_chap "yes";
allow_plain "yes";
};
h323
{
address
{
"0.0.0.0";
};
port "1720";
};
ema_avg_time "10";
call_rate_alarm_lifetime "60";
};
};

Section ras contains parameters controlling H.323 registrations:


address section contains IP address or addresses, used by the node to listen for incoming RAS

requests. See also How TS balances incoming SIP and H.323 calls.
port port, used by the node to listen for incoming RAS requests.
gkname gatekeeper name used to process LRQ/ARQ messages.
allow_md5, allow_chap, allow_plain allowed password encryption algorithms.
Section h323 contains parameters controlling H.323 calls:
address section contains IP address or addresses, used by the node to listen for incoming H.323

calls. See also How TS balances incoming SIP and H.323 calls.
port port, used by the node to listen for incoming H.323 calls.

2015 SwitchRay Inc.

30 | Traffic Switch administration

The next two parameters are used to configure CPS limits on the node:
ema_avg_time interval for EMA calculation of CPS. Default value: 10 (seconds).
call_rate_alarm_lifetime lifetime of the CPS_<network_address> alarm in seconds. The

parameter serves to avoid repetitive alarms when the rates vary around the threshold. The default value
is 60 (i.e. the alarm will be cleared only if the threshold is not exceeded for 60 seconds).
Note: CPS limits are configured in the web interface object Traffic Switch > Traffic Switch configuration >
H.323 limits > CPS limitation. For details, refer to How to limit CPS/RPS for H.323 traffic. Once the
defined CPS threshold is exceeded, Traffic Switch starts rejecting calls and sending TS alarm messages
CPS_<network_address> (if the notification function has been properly configured).

7.2.4.3 Signaling node


A configuration example of a signaling node:
signaling "signaling-1"
{
common
{
loglevel "0";
};
h323
{
address
{
"0.0.0.0";
};
port "1721";
};
sip
{
address
{
"0.0.0.0";
};
port "5061";
secret "NewSecret";
};
cdr_recovery "yes";
max_calls_rate "100";
call_rate_alarm_lifetime "60";
};

Section h323 contains parameters controlling H.323 calls:


address section contains IP address or addresses, used by the node to listen for incoming H.323

calls. The IP address "0.0.0.0" opens H.323 listener sockets on all available network interfaces. See also
How TS balances incoming SIP and H.323 calls.
port port, used by the node to listen for incoming H.323 calls.
Section sip contains parameters controlling SIP calls:
address section contains IP address or addresses, used by the node to listen for incoming SIP calls.

The IP address "0.0.0.0" opens SIP listener sockets on all available network interfaces. See also How TS
balances incoming SIP and H.323 calls.
port port, used by the node to listen for incoming SIP calls.

2015 SwitchRay Inc.

Configuring Traffic Switch | 31

secret key used by signaling and SIP proxy nodes for en- and decryption of signatures in some SIP

header fields. These signatures are generated and used by TS only (for example, for routing). The
length of the string should be of 4 to 56 characters. The secret key should be globally unique. For
example, it can be your company name or some abstract string generated with a special utility like
pwgen or the following command:
#> dd if=/dev/urandom bs=12 count=1 2>/dev/null | base64

The key should be the same on all SIP proxy and signaling nodes within a system. Secret keys for SIP
proxy nodes are defined in the web interface object Traffic Switch > Traffic Switch configuration >
[SIP proxy node] > Proxy global configuration, with the help of the Secret key parameter.
user_agent with the help of this arbitrary parameter you can define the contents of the SIP header

fields "User-Agent" and "Server". By default (if the parameter is not written), TS writes its version in
this field. If the value of this parameter is empty (user_agent "";), SIP header fields "User-Agent"
and "Server" are not written whatsoever.
The parameter cdr_recovery enables/disables the CDR restoration mechanism. Valid values: "yes" or "no".
For more information about CDR restoration, refer to the SR-S4500 v.1.5.4 Operator's manual (13.9 "How to
restore CDRs").
The next two parameters are used to configure CPS limits on the node:
max_calls_rate CPS value on the signaling node, required for generation of the alarm SIGMIPR001

(assuming that the notification function has been properly configured).


call_rate_alarm_lifetime lifetime of the SIGMIPR001 alarm in seconds. Use this parameter to
avoid repetitive notifications when CPS values vary around the max_calls_rate threshold. The
default value is 60 (SIGMIPR001 will be disabled only if CPS values are not exceeding the threshold for
60 seconds).

7.2.4.4 Media node


A configuration example of a media node:
media
{
media "media-1"
{
controllink
{
zone "test";
port "7800";
};
portrange "10000-14999";
};
};
portrange range of UDP ports, used by the media node.

Please verify that the range begins with an even number and ends with an odd number.
Otherwise the media node will fail.
rbtfilesdir path to the directory with RBT emulation files and messages played after call clearing.

By default and if not defined, it is /etc/mvts3g/.


Note: Audio files must have the following characteristics: WAV format, 8 kHz, 16 bit, mono and
PCMA/PCMU/PCM codec.

2015 SwitchRay Inc.

32 | Traffic Switch administration

advanced_load_measurement enables the alternative balancing method (valid values are "yes"

and "no"). For details, see How TS balances media.

7.2.4.5 trafficmanager node


A configuration example of a trafficmanager node:
trafficmanager
{
trafficmanager "trafficmanager-1"
{
controllink
{
zone "test";
port "7755";
};
sessions "10";
node_id "1";
servicelink "198.162.31.160:7890";
wdTimeout "30000";
wdSleep "10000";
databases
{
database "db-1"
{
address "198.162.31.21:1521";
login "VOIP_DEV";
password "9x87JuiAh0";
sid "RS";
role "routing;billing;logging";
};
database "db-2"
{
address "192.167.15.94:1521";
login "VOIP_DEV";
password "0s44SuAff7";
sid "RS";
role "routing_reserve;billing;logging";
};
};
};
};
sessions number of DBMS processes launched by the node. The parameter can be defined globally

in the common section or individually for each trafficmanager node. Recommended value is 10 (5
processes per each DB).
node_id identifier of the node used during generation of CDR IDs. In relation to one and the same

DB these identifiers should be unique, even if the nodes belong to different TS servers.
serviceLink IP address and port of the trafficmanager node, also specified in the parameter

Trafficmanager node service IP address:port (the web interface table System global settings).
Using the next two parameters you configure the restart of the hung dbms processes:
wdTimeout the trafficmanager-phoenix tries to restart a dbmsclient process, if it fails to respond

2015 SwitchRay Inc.

Configuring Traffic Switch | 33

within the time (in ms), defined in this parameter.


wdSleep length of the pause (in ms). If after the wdSleep timeout the faulty dbmsclient process still

is not stopped, the trafficmanager-phoenix sends it a SIGKILL signal.


wdSleep must not be higher than wdTimeout.

If the dbmsclient process stops responding to queries, the trafficmanager-phoenix keeps trying to restart it
again and again every time the wdTimeout period lapses. To avoid this, increase the wdTimeout value to
40000 and above.
Section databases describes the databases TS interoperates with. It includes the following parameters:
address IP address and port for connection.
login DB scheme name (usually, VOIP_DEV).
password DB password.
sid the Oracle SID (RS). Do not change.
role string with DB roles delimited by semicolons. Available roles:

routing (main DB) or routing_reserve (backup DB) DB performs call routing;


billing DB is used for billing;
logging DB writes CDRs;
media_log DB writes media CDRs (the parameter Write media statistics located in the web

interface table Global settings > Trafficmanager node settings should be enabled).
DO NOT include data about the DB allocated for the data warehouse in the trafficmanager node
configuration.

7.2.4.6 Synchro node


Presently the configuration of the synchro node does not have any specific parameters and includes common
sections only ("common" and "controllink"):
synchro
{
synchro "synchro-1"
{
controllink
{
zone "test";
port "7711";
};
};
};

2015 SwitchRay Inc.

34 | Traffic Switch administration

7.2.4.7 TS configurator
A configuration example of the TS configurator:
scripting
{
scripting "configurator-1"
{
controllink
{
zone "test";
port "7710";
};
loader_path "tsconfigurator";
environment
{
trace_level "7";
dbms_type_master
"Oracle";
dbms_name_master
"//198.162.31.21/RS";
dbms_user_master
"VOIP_DEV";
dbms_pswd_master
"9x87JuiAh0";
dbms_type_slave
"Oracle";
dbms_name_slave
"//192.167.15.94/RS";
dbms_user_slave
"VOIP_DEV";
dbms_pswd_slave
"0s44SuAff7";
};
};
};
loader_path path to the starting script of the TS configurator. Do not change.

Parameters of the environment subsection:


trace_level level of details in logs (for details, see How to control logging of TS configurator).

Recommended value is 7.
trace_file prefix for a log file of the TS configurator. By default and if not defined, the value is
mvtsprologic (for details, see How to control logging of TS configurator).
Using the next four parameters configure connection to the main database:
dbms_type_master type of the main database (always "Oracle", do not touch).
dbms_name_master path to the main database in the "//<IP address>/RS" format.
dbms_user_master name of the main database user account (usually, VOIP_DEV).
dbms_pswd_master main database user password.

Using the next four parameters configure connection to the backup database (if you do not have one,
use the values valid for your main DB):
dbms_type_slave type of the failover database (always "Oracle", do not touch).
dbms_name_slave path to the failover database in the "//<IP address>/RS" format.
dbms_user_slave name of the failover database user account (usually, VOIP_DEV).
dbms_pswd_slave failover database user password.

TS configurator should run on the same server with the TS management node. There should be only one TS
configurator in the System.
After changing DB access parameters you need to run the config command in TS console and
restart the node.

2015 SwitchRay Inc.

Configuring Traffic Switch | 35

7.2.4.8 SIP proxy node


The configuration of the SIP proxy node in the file system.conf does not have any specific parameters and
includes common sections only ("common" and "controllink"):
sipproxy
{
sipproxy "sipproxy-1"
{
controllink
{
zone "test";
port "7900";
};
};
};

The SIP proxy node and all signaling nodes connected with it should have open SIP sockets in the control
link zone. See also How TS balances incoming SIP and H.323 calls.
To configure the SIP proxy node, use the web interface category of objects Traffic switch:
How to configure SIP sockets
How to configure balancing of incoming traffic
How to configure balancing of outgoing SIP traffic
SIP traffic limitation

7.3 How to configure SIP sockets


There are three variants of configuration of SIP listening sockets:
Using internal network (recommended)
Using external networks (workaround for problem equipment)
Using one external address (minimum workaround)

7.3.1 Using internal network


In this variant of configuration you add two internal IP addresses per each TS server hosting signaling and
SIP proxy nodes. The signaling node operates the internal network only, whereas the SIP proxy node listens
for incoming connections from signaling nodes and external networks:
1. Add two IP addresses to the internal TS zone, for example:
zone
{
...
zone "internal"
{
...
"192.168.12.12";
"192.168.12.13";
};
};

For details, refer to the How to configure IP zones section.

2015 SwitchRay Inc.

36 | Traffic Switch administration

2. Open the configuration file of the signaling node(-s).


3. In the address section, open only one SIP listening socket from the internal TS zone:
signaling "signaling-1"
{
common
{
};
sip
{
address
{
"192.168.12.12";
{
...
}
...
};

4. Save the file.


5. Open the configuration file of the SIP proxy node(-s).
6. In the controllink section, specify the internal TS zone:
sipproxy "sipproxy-1"
{
common
{
};
controllink
{
zone "internal";
port "7900";
};
};

7. Save the file.


8. Access the TS console.
9. Run the config command (see Administration console commands).
10.Open the web interface category of the desired SIP proxy node (Traffic Switch > Traffic Switch
configuration > [node name]).
11.Switch to the Listeners object.
12.In the Listeners ([node name]) table, add the other IP address from the internal TS zone. In our
example, it is 192.168.12.13.
13.In the Listeners ([node name]) table, add one or more external IP addresses.
14.Repeat Steps 10-13 for other SIP proxy nodes.
The configuration is complete.

2015 SwitchRay Inc.

Configuring Traffic Switch | 37

7.3.2 Using external networks


Use this variant of configuration to support interaction with equipment which, for some reasons, cannot
correctly work with the SIP proxy node. Create a new IP zone consisting of two IP addresses of your client.
Signaling and SIP proxy nodes will communicate through this IP zone, and in case of problems the
incompatible device will try to connect directly to the signaling node:
1. Add a new zone, specifying two external IP addresses of your client:
zone
{
...
zone "proxy-service"
{
"196.162.11.40";
"192.162.11.41";
};
};

For details, refer to the How to configure IP zones section.


2. Open the configuration file of the signaling node(-s).
3. In the address section, open one SIP listening socket from the IP zone you configured in Step 1:
signaling "signaling-1"
{
common
{
};
sip
{
address
{
"196.162.11.40";
{
...
}
...
};

4. Save the file.


5. Open the configuration file of the SIP proxy node(-s).
6. In the controllink section, specify the IP zone you configured in Step 1:
sipproxy "sipproxy-1"
{
common
{
};
controllink
{
zone "proxy-service";
port "7900";
};
};

2015 SwitchRay Inc.

38 | Traffic Switch administration

7. Save the file.


8. Access the TS console.
9. Run the config command (see Administration console commands).
10.Open the web interface category of the desired SIP proxy node (Traffic Switch > Traffic Switch
configuration > [node name]).
11.Switch to the Listeners object.
12.In the Listeners ([node name]) table, add the other internal IP address from the zone you configured in
Step 1. In our example, it is 192.162.11.41.
13.In the Listeners ([node name]) table, add one or more external IP addresses.
14.Repeat Steps 10-13 for other SIP proxy nodes.
The configuration is complete.

7.3.3 Using one external address


With no reasonable possibility to using one of the above variants, you can try to add only one external IP
address into a separate IP zone. Signaling and SIP proxy nodes will communicate through this zone. Please
note that all external traffic arriving at this zone should comply with RFC 3261 regarding routing.
1. Add a new zone, consisting of one external IP address of your client:
zone
{
...
zone "external_x"
{
"196.162.11.40";
};
};

For details, refer to the How to configure IP zones section.


2. Open the configuration file of the signaling node(-s).
3. In the address section, open a SIP listening socket from the IP zone you configured in Step 1:
signaling "signaling-1"
{
common
{
};
sip
{
address
{
"196.162.11.40";
{
...
}
...
};

4. Save the file.

2015 SwitchRay Inc.

Configuring Traffic Switch | 39

5. Open the configuration file of the SIP proxy node(-s).


6. In the controllink section, specify the IP zone you configured in Step 1:
sipproxy "sipproxy-1"
{
common
{
};
controllink
{
zone "external_x";
port "7900";
};
};

7. Save the file.


8. Access the TS console.
9. Run the config command (see Administration console commands).
10.Open the web interface category of the desired SIP proxy node (Traffic Switch > Traffic Switch
configuration > [node name]).
11.Switch to the Listeners object.
12.In the Listeners ([node name]) table, add 0.0.0.0.
13.Repeat Steps 10-12 for other SIP proxy nodes.
The configuration is complete.

2015 SwitchRay Inc.

40 | Traffic Switch administration

8 Accessing Traffic Switch administration console


To manage and control Traffic Switch operation, use the administration console. It allows you to upload new
configuration, view statistical information and control logging of some of the TS nodes.
To access the administration console:
1. Connect to the primary TS server via SSH.
2. In the phoenix.conf file, check the load command for the command line node:
load type=commandline name=commandline-1 address=127.0.0.1:7000

where commandline-1 is the name of the command line node and 127.0.0.1:7000 is the IP address
and port used by the command line node to listen for incoming telnet connections.
3. Connect to the IP address and port you defined in Step 2, for example:
#> telnet 0 7000

You will see the Traffic Switch command line interface. It is allowed to run several instances of the
administration console simultaneously. For example, two or more administrators may access and work in the
TS console at the same time.

8.1 Administration console commands


The administration console provides a suite of commands that enable interaction of the operator with the
system:
config <filename> re-reads the TS configuration. The <filename> argument of this command is

the full path to the system.conf file. For example:


mvts3g|> config /etc/mvts3g/system-1.conf

Note: The <filename> argument allows only the main configuration file (for example, "system1.conf"), not "system-1.signaling.conf" and the like.
The output of this command will be:
Step 1: Parsing a configuration file...
Step 2: Configuring the system...
Step 3: Done.
log[level] <enable|disable> <node name> [timeout] enables or disables logging of H.323

balancer or signaling nodes (for details, see TS nodes logging):


<node name> is a name of the node to be logged (the argument allows regular expressions).
<timeout> is a time interval (in minutes) after which the logging will be disabled. If the argument is
not set, logging will be enabled for 24 hours after executing the command.
For example:
mvts3g|> log enable signaling-1 30
help displays the help screen.
logout or quit closes current session in the console.
exit closes current tool.

2015 SwitchRay Inc.

Load balancing | 41

9 Load balancing
How TS balances load
How to configure balancing of incoming traffic
How to configure balancing of outgoing SIP traffic
Using optional media balancing method

9.1 How TS balances load


Load balancing on TS is performed by the following entities:
the H.323 balancer node (balancing of ingress H.323 traffic between signaling nodes). See also How TS
balances incoming SIP and H.323 calls
the SIP proxy node (balancing of arriving SIP calls/registrations between signaling nodes). See also
How TS balances incoming SIP and H.323 calls
the signaling node (load balancing between media nodes)
balancing groups (see What are load balancing groups?)

9.1.1 How TS balances incoming SIP and H.323 calls


The balancer node and SIP proxy node distribute incoming calls between signaling nodes. The signaling
nodes are selected on the basis of the current ASR value of each signaling node. The method of distribution
depends on the protocol governing the call (see the table below).
Balancing type

Description

Conditions

H.323
Balancing upon
arrival of LRQ and
ARQ

The balancer node sends the address of the least loaded


signaling node in response to LCF/ACF.

All signaling nodes


should have open
H.323 sockets (the
section h323) in the
same zones as RAS
sockets in the
balancer node (the
section ras).

Balancing with
proxying

This mode is used when a call arrives directly at the balancer


node. All signaling messages between initiating equipment
and selected signaling node are passed through the balancer
node.

All signaling nodes


should have open
H.323 sockets (the
section h323) in the
same zones as H.323
sockets in the
balancer node (the
section h.323).

SIP
Balancing with
proxying

2015 SwitchRay Inc.

Upon arrival of the INVITE message the SIP proxy node will
select a signaling node and proxy all messages between the
signaling node and the device.

The SIP proxy node


and all signaling
nodes connected
with it should have
open SIP sockets
(the section sip) in
the control link zone.

42 | Traffic Switch administration

9.1.2 What are load balancing groups?


SR-S4500 allows you to configure balancing groups. The System distributes (or balances) workload between
the nodes belonging to one and the same balancing group. Calls which come to the entry point (the H.323
balancer or SIP proxy node) of a certain balancing group are handled only by the nodes of this group.
Signaling balancing groups help the System balance incoming H.323/SIP calls/registrations between
signaling nodes. You configure signaling balancing groups in the section balancing of the
system.conf file and in the web interface. For details, see How TS balances incoming SIP and H.323
traffic.
Proxy balancing groups are designed to distribute outgoing SIP calls between SIP proxy nodes. You
configure proxy balancing groups using the web interface only. For details, see How TS balances
outgoing SIP traffic.
By default, all TS nodes belong to the one common balancing group.

9.1.2.1 How TS balances incoming SIP and H.323 traffic


The balancing of an incoming SIP call/registration is the following:
1. The SIP call/registration is received by a SIP proxy node.
2. This SIP proxy node passes the call/registration to the signaling node, which is:
located in the signaling balancing group, defined in the configuration of this SIP proxy node;
the least loaded node of this group.
3. This signaling node passes the call/registration to the trafficmanager node, which is:
located in the same signaling balancing group, as this signaling node;
the least loaded node of this group.
The balancing of incoming H.323 calls is practically the same as that of SIP calls. The difference is that the
call is received by the H.323 balancer node, and the following balancing is performed within its own signaling
balancing group.

9.1.2.2 How TS balances outgoing SIP traffic


To place outgoing SIP calls, Traffic Switch will use the SIP proxy node, which is:
located in the same proxy balancing group, as the SIP proxy node, with which the corresponding piece
of equipment was registered. If the piece of equipment was not registered, the System will use the proxy
balancing group defined in the configuration of this piece of equipment;
the least loaded node of this group.

9.1.3 How TS balances media


By default, the signaling node distributes traffic between media nodes according to average load of the
server hosting these media nodes.
The optional balancing method is based on monitoring of current CPU usage by each media node. With this
method enabled, the media node stops handling new calls when it exceeds its CPU usage limit and resumes
handling new calls only after the CPU usage level on this node drops back to normal.
For configuration instructions, refer to Using optional media balancing method.

2015 SwitchRay Inc.

Load balancing | 43

9.2 How to configure balancing of incoming traffic


To configure balancing of incoming traffic:
1. Ensure that you added all necessary signaling, trafficmanager and H.323 balancer nodes to the system
configuration files system.conf and phoenix.conf. See also How to add new nodes.
2. Group these nodes using the section balancing in the system.conf configuration file:
balancing
{
balancing "<group_name>" // balancing group name
{
"<signaling_node_name>"; // node of this group
"<trafficmanager_node_name>"; // node of this group
"<balancer_node_name>"; // node of this group
};
};

Make sure that each node belongs only to one group. Check, that each signaling balancing group
contains at least one signaling node, one H.323 balancer node and one trafficmanager node. Example of
properly configured balancing groups:
balancing
{
balancing "balancing-group-1"
{
"signaling-1";
"signaling-2";
"signaling-6";
"balancer-1";
"trafficmanager-2";
};
balancing "balancing-group-2"
{
"signaling-4";
"signaling-5";
"signaling-3";
"balancer-2";
"trafficmanager-1";
};
};

3. When done, save the file.


4. Access the TS console.
5. Run the config command (see Administration console commands).
6. In the web interface table Traffic Switch > Traffic Switch configuration > Balancing groups >
Signaling balancing groups, add all the signaling balancing groups you mentioned in Step 2:

2015 SwitchRay Inc.

44 | Traffic Switch administration

7. For balancing of incoming SIP traffic, you also need to specify the balancing group, between signaling
nodes of which the specific SIP proxy node will balance incoming SIP calls/registrations:
1) Add all the SIP proxy nodes you need (see How to add new nodes).
2) Open the web interface category of the desired SIP proxy node (Traffic Switch > Traffic Switch
configuration > [node name]).
3) In the object TS routing > TS routing configuration, click Switch to edit mode.
4) In the Remote balancing group drop-down list, select a signaling balancing group. If you do not
define any balancing group, the SIP proxy node will use the default one (an empty string of the
drop-down list):

5) Click OK.
The configuration is complete.

2015 SwitchRay Inc.

Load balancing | 45

9.3 How to configure balancing of outgoing SIP traffic


To configure balancing of outgoing SIP traffic:
1. Add all the SIP proxy nodes you need (see How to add new nodes).
2. In the web interface table Traffic Switch > Traffic Switch configuration > Balancing groups > Proxy
balancing groups, add balancing groups for SIP proxy nodes:

3. Specify to which balancing group each SIP proxy node should belong:
1) Open the web interface category of the desired SIP proxy node (Traffic Switch > Traffic Switch
configuration > [node name]).
2) In the object TS routing > TS routing configuration, click Switch to edit mode.
3) In the Local balancing group drop-down list, select a SIP proxy balancing group. If you do not
define any balancing group for the SIP proxy node, it is included into the default one (an empty
string of the drop-down list):

4) Click OK.
5) Repeat Steps 1)-4) to add other SIP proxy nodes to balancing groups.
Leave at least one SIP proxy node in the default balancing group. Otherwise TS will
probably reject some of the calls with LDC TS 158 "SIP proxy node is not available". You
may assign some other non-default group to the node after completing Step 4.
4. Define the balancing group, between SIP proxy nodes of which the System will balance outgoing SIP
calls to equipment, not registered with the System:

2015 SwitchRay Inc.

46 | Traffic Switch administration

1) Open to the object Equipment > Equipment.


2) Invoke the edit-record dialog box of the desired piece of equipment.
3) In the SIP settings group of parameters, in the SIP proxy balancing group drop-down list, select
the required balancing group. The "undefined" balancing group is the default one:

Note: to initiate SIP calls to the registered equipment, the System will use the same SIP proxy node,
with which this equipment was registered, irrespective of the parameter "SIP proxy balancing
group".
4) Click OK.
5) Repeat Steps 2)-4) to configure other equipment records. Use group editing to save time.
The configuration is complete.

9.4 Using optional media balancing method


To switch to the optional method of balancing media traffic:
1. Open the configuration file of the media node (for example, system-1.media.conf).
2. In the beginning of the media section, add the line advanced_load_measurement "yes";:
media
{
advanced_load_measurement "yes";
...

To avoid balancing problems, do not use the advanced_load_measurement parameter


inside the configuration of individual nodes.
3. Inside the configuration of individual media nodes, add and define the following parameters:
unsafe_load_level maximum CPU usage limit in percent. When this limit is exceeded, the media

node stops handling new calls. Valid values: from 0 through 100. The default limit (and if not
defined) is 95.
safe_load_level tolerable CPU usage expressed in percent. When the CPU usage of a

temporary blocked node drops to this level, the node resumes handling new calls. Valid values: from
0 through 100. The default limit is 90.
Note: For debugging or other purposes, make the value of the "unsafe_load_level" parameter
smaller than that of the "safe_load_level" parameter. The protection against excessive traffic will
not operate, while the feature itself will still be considered enabled, and you avoid serious
changes in the configuration.

2015 SwitchRay Inc.

Load balancing | 47

overload_alarm_delay interval in seconds after overloading of the node and before triggering

of the MEDLOAD001 alarm. Valid values: from 0 through 32767. The default delay is 5 seconds. If
the value is 0, the alarm triggers immediately after the media node is overloaded.
The example of the correct configuration:
media
{
advanced_load_measurement "yes";
media "media-1"
{
controllink
{
zone "test";
port "7800";
};
portrange "10000-12999";
unsafe_load_level "95";
safe_load_level "90";
overload_alarm_delay "5";
};
media "media-2"
{
controllink
{
zone "test";
port "7801";
};
portrange "13000-14999";
unsafe_load_level "95";
safe_load_level "90";
overload_alarm_delay "5";
};
};

4. Save the configuration file (in our example, system-1.media.conf).


5. Access the TS console.
6. Run the config command (see Administration console commands).
The configuration is complete. Below are examples of records written to the phoenix.log file:
If the advanced_load_measurement parameter is set to "yes", the following record appears:
media-1: Advanced load measurement: unsafe_load_level=95, safe_load_level=90,
overload_alarm_delay=5

The following record appears when overload protection triggers:


media-1: Overload detected (load: 98.9017, idle: 51.9324). Excluding from
balancing

When an overload lasts longer than it is defined by the overload_alarm_delay parameter, the
following record is added:
media-1: ALARM RAISED: MEDLOAD001: MAJOR: media-1 is overloaded for more than
5 seconds

2015 SwitchRay Inc.

48 | Traffic Switch administration

10 Traffic limitation
Unlike the possibility of limiting traffic on the equipment level, the feature described in this section rejects
excessive calls immediately on Traffic Switch without sending queries to the DB because information about
restrictions is written to the TS cache.
SIP traffic limitation
H.323 traffic limitation

10.1 SIP traffic limitation


How Traffic Switch limits SIP traffic
How to configure realms
How to limit CPS/RPS/OoDRPS for SIP traffic
How to limit requests on queues
Changing interval for EMA calculation of average values

10.1.1 How Traffic Switch limits SIP traffic


The load control is performed by the SIP proxy node. Before you move on, make sure that you added SIP
proxy nodes (see How to add new nodes). The load control configuration is done individually for each SIP
proxy node. Thus, if you want to set a limit on traffic coming from a specific network to all of your SIP proxy
nodes, you should repeat configuration steps for all these nodes.
When a request arrives, the SIP proxy node does the following:
1. Selects a realm based on the network where the request has come from and on the destination TS zone
(see What is a realm?).
2. Checks CPS/RPS/OoDRPS limits defined in the load control configuration of this realm (see How TS
limits CPS/RPS/OoDRPS).
3. Selects a queue based on the load configuration of this realm (see How TS selects a queue for requests
from a realm).
4. Checks requests per second limits on this queue (see How TS limits requests on queues).
The following requests do not affect the load control function:
Requests which persist inside the Dialog (with the signature in the Route header field, or received from
the signaling nodes).
CANCELs, if there were no preceding INVITEs for more than 3 minutes.
For every limit you define a SIP disconnect code, and a Q.850 code to be included in the Reason header field.
With SIP 480 TS will add the "Retry-After: 180" header field. If no SIP disconnect code is defined, the SIP
proxy node will ignore excessive requests.

10.1.1.1 What is a realm?


A realm is a logical definition of a network, a collection of networks, or a set of addresses bound up with
internal TS zones. Realms provide configuration support for traffic limitation and load control within the SIP
proxy node. Each SIP proxy node references its own set of realms.
From a perspective of traffic source, realms can be trusted and untrusted:
Trusted realms are made up of IP addresses of SwitchRay Inc. products (currently only TS signaling
nodes). Each SIP proxy node includes a predefined trusted realm named "_TSSignalingNodes_", which

2015 SwitchRay Inc.

Traffic limitation | 49

incorporates IP addresses of all SIP sockets opened on all signaling nodes running in the System. TS
updates this realm automatically upon loading/unloading of signaling nodes. The
"_TSSignalingNodes_" realm is used for limiting outgoing traffic.
Untrusted realms comprise networks of your customers. As registration requests may include the Path
header field (RFC 3327), you may enable the support for this standard in the configuration of the
untrusted realm where such registrations are coming from. Also, each SIP proxy node includes a
predefined untrusted realm named "_undefined_", which serves as the entry point for all inbound
requests. This realm does not support the Path extension.
From a configuration perspective, a realm is defined as a set of unique pairs, each one being an IP network
and internal TS zone. Thus, requests coming from one and the same subnet to different TS zones may belong
to separate realms. Please note that when determining a realm where a request is coming from, TS searches for
the subnet with the least host address range. Suppose that we have the two following realms:
Example:
realm Common: 192.168.128.0/24 - zone Internal,
realm Specific: 192.168.128.100/32 - zone Internal.
In such a case:
for the address 192.168.128.100 the "Specific" realm will be used;
for the addresses 192.168.128.* the "Common" realm will be used;
for all other addresses the "_undefined_" realm will be used.

10.1.1.2 How TS limits CPS/RPS/OoDRPS


The SIP proxy node allows limiting the number of new calls (SIP dialogs) per second (CPS), the number of
new registrations per second (RPS) and the number of out-of-dialog requests per second (OoDRPS) on a
specific realm. Out-of-dialog requests are:
all new requests except INVITEs and REGISTERs;
requests with no tag in the To header field.
For example, OPTIONS is generally considered to be an out-of-dialog request. However, received within an
already established dialog it does not take part in the OoDRPS limitation.

10.1.1.3 What is a queue?


A queue is a list of requests successively processed by the SIP proxy node. Queues are used for
classification, control and limitation of traffic.
Each SIP proxy node operates two queues: one trusted (for privileged sources of traffic) and one untrusted
(for non-privileged sources of traffic). Discrimination of traffic between these two queues is done in the load
control configuration of a realm. By default, all traffic from a realm passes through the untrusted queue.
The minimum guaranteed quality of service on a queue can be determined by configuring requests per
second limits on that queue. TS calculates current average requests per second values separately for each
queue using EMA.

10.1.1.4 How TS selects a queue for requests from a realm


When a request arrives from a realm, the SIP proxy node checks the load control configuration of this realm.
Depending on the settings therein, the request passes through the trusted or untrusted queue. The queue
type selection largely depends on a trust level of the realm:
none the realm always uses the untrusted queue;

2015 SwitchRay Inc.

50 | Traffic Switch administration

low dynamic selection, stop-listing is allowed (see below);


medium dynamic selection, stop-listing is not allowed (see below);
high the realm always uses the trusted queue.
The dynamic queue type selection mechanism employs a number of successful requests received from a
realm per second, along with a number of rejected requests received from a realm per second. If these
numbers exceed or drop below configured limits within a specified timeout, the queue type of the realm is
changed from untrusted to trusted (the realm is promoted) or vice versa (the realm is demoted). When an
already demoted realm violates a limit, it can be temporarily placed in the stop list (if the trust level of this
realm is low). This means that the SIP proxy node will reject requests from this realm with a disconnect code
or ignore them, if the code is not set. If configured, TS also sends notifications about stop-listing of realms
(see SIP proxy node alarms).

10.1.1.5 How TS limits requests on queues


To help you understand how the queue limiting mechanism works, refer to the following diagram.

For both queues you configure hard limits, upon violation of which the SIP proxy node will reject (if a SIP
disconnect code is defined) or ignore (if the code is not set) excessive requests.
For the untrusted queue you can configure the minimum guaranteed number of requests per second limit. The
number of requests per second in the untrusted queue never drops below this line.
For the trusted queue you can configure the soft maximum number of requests per second. Once the number
of requests per second exceeds this limit (t1 and t2 on the diagram), the SIP proxy node scales down the hard
limit for the untrusted queue by the amount of this excess. As the hard limit for the untrusted queue can
never be lower than its minimum guaranteed quality, the reduction of the hard limit can at most make the
untrusted queue limits equal (as at the t2 moment).

10.1.2 How to configure realms


To add and configure realms:
1. Configure internal IP zones.

2015 SwitchRay Inc.

Traffic limitation | 51

2. Add the names of the zones you configured in Step 1 in the web interface table Traffic Switch >
Traffic Switch configuration > Zones:

3. Open the web interface category of a desired SIP proxy node (Traffic Switch > Traffic Switch
configuration > [node name]).
4. Open the Realms object.
5. Invoke the add-record dialog box.
6. In the Name text box, enter any convenient name for the realm. For example, it can be your customer's
name or a subnet mask.
7. Select the Path (RFC 3327) support check box if you want to enable correct interaction with pieces of
equipment which insert the Path header field into REGISTERs.
8. Optionally, write any descriptive information in the Description text box.
9. Click OK. A new record will appear in the table of Realms:

10.Switch to the Networks object.


11.Invoke the add-record dialog box.
12.In the Network text box, enter a network or IP address in the CIDR notation.
13.In the Zone drop-down list, select the IP zone you added in the Step 2.
14.In the Realm drop-down list, select a name of the realm you added in Step 6.
15.Click OK. A new record will appear in the table of Networks.
16.Repeat Steps 11-15 to add other desired Network-Zone pairs to the realm, for example:

17.Repeat Steps 4-16 to add and configure other realms for the SIP proxy node, if necessary.
18.Repeat Steps 3-17 to add and configure realms for other SIP proxy nodes, where necessary.
The configuration is complete.

2015 SwitchRay Inc.

52 | Traffic Switch administration

10.1.3 How to limit CPS/RPS/OoDRPS for SIP traffic


To configure incoming CPS/RPS/OoDRPS limits:
1. Open the web interface category of a desired SIP proxy node (Traffic Switch > Traffic Switch
configuration > [node name]).
2. Open the Load control > Load control realms settings object.
3. Invoke the add-record dialog box.
4. In the Realm drop-down list, select a desired realm.
5. Define limits and disconnect codes in the respective text boxes shown in the following picture:

An empty text box of a limit means there is no restriction.


6. Click OK, leaving all other parameters unchanged. A new record will appear in the table of Load control
realms settings ([node name]):

7. Repeat Steps 3-6 to add restrictions for requests from other realms, if necessary.
8. Repeat Steps 1-7 to add restrictions for requests from realms of other SIP proxy nodes, if necessary.

2015 SwitchRay Inc.

Traffic limitation | 53

The configuration is complete.

10.1.4 How to limit requests on queues


This section describes:
How to configure selection of queue on a realm
How to limit requests on queues

10.1.4.1 How to configure selection of queue on a realm


To configure selection of a queue used for requests from a realm:
1. Configure realms, if required.
2. Open the web interface category of a desired SIP proxy node (Traffic Switch > Traffic Switch
configuration > [node name]).
3. Open the Load control > Load control realms settings object.
4. Invoke the add-record dialog box, or select an existing realm and invoke the edit-record dialog box.
5. If you are adding a new record, in the Realm drop-down list, select a desired realm.
6. In the Trust level drop-down list, define a queue which will be used for requests from the realm (see
How TS selects a queue for requests from a realm).
7. For dynamic selection of a queue (if the trust level is low or medium), define the following parameters:

For more information, refer to Queue type selection parameters.


8. Click OK.
The configuration is complete.

2015 SwitchRay Inc.

54 | Traffic Switch administration

10.1.4.1.1

Queue type selection parameters


Traffic Switch > Traffic Switch configuration > [SIP proxy node] > Load control > Load control
realms settings
The following parameters are used for dynamic selection of a queue and temporal blocking of a realm:
Parameter

Description

Tolerance window

Interval in seconds for which TS tracks requests per second


values (see below).

Deny period

Period in seconds during which the realm stays in the stop list.
When the time is over, the realm is promoted. The field is
mandatory if the trust level of the realm is low.

Max request per seconds threshold

Number of requests per second used for promotion and


demotion of the realm:
The realm is demoted if the number of requests per second
keeps above the predefined threshold within the Tolerance
window interval.
The realm is promoted if the number of requests per
second keeps below the predefined threshold within the
Tolerance window interval.

Max request per seconds threshold for


untrusted queue

Number of requests per second used for stop-listing the realm


which operates the untrusted queue. When this number keeps to
be exceeded during the Tolerance window interval, TS stop-lists
the realm for the Deny period.

Max threshold for rejected request per


second

Number of non-successful requests per second (including


requests without any response sent to a call originator) used for
promotion and demotion of the realm:
When the threshold keeps to be exceeded during the
Tolerance window interval, TS demotes the realm.
When the number of such requests keeps below the
threshold during the Tolerance window interval, TS
promotes the realm.

SIP reject code for denied realm list

SIP disconnect code used for rejection of requests from a stoplisted realm.

Q.850 reject code for denied realm list

Additional Q.850 disconnect code used for rejection of requests


from a stop-listed realm. The code is written in the Reason header
field.

10.1.4.2 How to limit requests on queues


To configure limits on the queues:
1. Open the web interface category of a desired SIP proxy node (Traffic Switch > Traffic Switch
configuration > [node name]).
2. Open the Load control > Load control global settings object.
3. Click Switch to edit mode:

2015 SwitchRay Inc.

Traffic limitation | 55

4. Define the limits and disconnect codes (see How TS limits requests on queues).
Check that the following inequalities are not violated:
Soft max num. of requests per second in trusted queue Hard max num. of requests per
second in trusted queue
Min num. of requests per seconds in untrusted queue Max num. of requests per seconds in
untrusted queue
5. Click OK.
6. Repeat Steps 1-5 for queues of other SIP proxy nodes, if required.
The configuration is complete.

10.1.5 Changing interval for EMA calculation of average values


Optionally, you may define the interval used for EMA calculation of current average requests/calls per
second values. The lower is the interval, the more promptly the SIP proxy node reacts to changes in these
values. On the other hand, the bigger interval allows avoiding momentary traffic bursts.
To configure the EMA interval:
1. Open the web interface category of a desired SIP proxy node (Traffic Switch > Traffic Switch
configuration > [node name]).
2. Open the Proxy global configuration object.
3. Click Switch to edit mode:

4. In the EMA factor text box, define the required interval (in seconds) and click OK.
5. Repeat Steps 1-4 for other SIP proxy nodes, if required.
The configuration is complete.

10.2 H.323 traffic limitation


How Traffic Switch limits H.323 traffic
How to limit CPS/RPS for H.323 traffic
Changing interval for EMA calculation of CPS/RPS

2015 SwitchRay Inc.

56 | Traffic Switch administration

10.2.1 How Traffic Switch limits H.323 traffic


The load control is performed by the H.323 balancer node. Upon violation of a CPS limit, TS will reject H.323
calls by closing TCP connections. When an RPS limit is exceeded, TS will not respond to new registration
requests. You can also configure sending of notifications upon violation of limits (see H.323 balancer node
alarms).
Keep in mind that subnets can overlap. During call processing, TS searches for the subnet with the least host
address range. Suppose the following limits have been defined for two subnets:
Example:
1.2.0.0/16 limit = 200
1.2.3.0/24 limit = 500
In such a case for the address 1.2.3.4 the limit is 500 and for the address 1.2.15.3 the limit is 200.
0.0.0.0/0 is used to limit H.323 traffic globally.

10.2.2 How to limit CPS/RPS for H.323 traffic


To configure CPS/RPS limits for a network/subnet/IP address, where H.323 traffic comes from:
1. Proceed to the category of objects Traffic Switch > Traffic Switch configuration > H.323 limits.
2. Open the CPS limitation or RPS limitation table.
3. Invoke the add-record dialog box.
4. In the Subnetwork address text box, define a network or IP address (in the CIDR notation).
5. In the Max CPS or Max RPS text box, define a maximum allowed CPS/RPS rate value.
6. In the RPS limitation table, leave the value of the Drop method parameter to "drop".
7. In the Description text box, enter any descriptive information, if necessary.
8. Click OK.
The configuration is complete.

10.2.3 Changing interval for EMA calculation of CPS/RPS


Optionally, you may define the interval used for EMA calculation of CPS/RPS. This configuration is done
individually for each H.323 balancer node in the system.conf file (see H.323 balancer node):
1. Open the configuration file of the H.323 balancer node(-s).
2. Define the value (in sec.) of the ema_avg_time parameter:
balancer
{
balancer "balancer-1"
{
...
ema_avg_time "10";
call_rate_alarm_lifetime "60";
};
};

The default value is 10 seconds. The acceptable value range is 1 through 60.

2015 SwitchRay Inc.

Traffic limitation | 57

3. Save the file.


4. Access the TS console.
5. Run the config command (see Administration console commands).
The configuration is complete.

2015 SwitchRay Inc.

58 | Traffic Switch administration

11 Working with nodes


This section describes:
How to add new nodes
How to change node configuration
How to restart nodes
How to remove nodes

11.1 How to add new nodes


To add a new TS node:
1. At the end of the phoenix.conf file, add the load command specifying the node type and name. For
example:
load type=signaling name=signaling-1

2. Configure the node in the file system.conf (see Configuring nodes). The name of the node should be
the same as you specified in Step 1 (in our example, signaling-1).
3. Access the TS console.
4. Run the config command (see Administration console commands).
5. Restart Traffic Switch. Alternatively, if you do not wish to restart TS:
1) Run the following Linux command:
#> telnet 0 5000

where 0 and 5000 are the address and port defined in the phoenix command of the phoenix.conf
file.
2) In the console, run the load command as defined in Step 1, for example:
load type=signaling name=signaling-1

6. If the node is of the type SIP proxy, in the web interface table Traffic Switch > Traffic Switch
configuration > Traffic Switch nodes, add the record with the node name defined in Step 1. A new
record in this table creates a corresponding subcategory with the same name, as shown in the picture
below.

2015 SwitchRay Inc.

Working with nodes | 59

11.2 How to change node configuration


To change configuration of an existing node:
1. Make all required changes in the node configuration.
2. Access the TS console.
3. Run the config command (see Administration console commands).
4. If the node is the TS configurator and you changed DB access parameters, restart the node:
#> kill -9

`ps ax | awk '/configurator-1/ && $0 !~/awk/ {print $1}'`

where configurator-1 is the node name defined in the load command of the phoenix.conf file.

11.3 How to restart nodes


To restart a node, use the following command:
#> kill -9

`ps ax | awk '/signaling-1/ && $0 !~/awk/ {print $1}'`

where signaling-1 is the node name specified in the load command of the phoenix.conf file. Instead of
writing a specific node name, you can define a pattern. For instance, write media for restarting all media
nodes ("media-1", "media-2", etc.)
To make sure that the node was restarted, run the sh bs command in the TS administration console.
Note: If the notification function was properly configured, you will receive the TS alarm NODFLT001.

11.4 How to remove nodes


To remove a TS node:
1. Run the following Linux command:
#> telnet 0 5000

where 0 and 5000 are the address and port defined in the phoenix command of the phoenix.conf file.
2. In the console, run:
unload name=signaling-1 method=grace

where signaling-1 is the node name specified in the load command of the phoenix.conf file.
Phoenix will wait until the node finishes its tasks (active calls first of all) and will unload it. To limit the
waiting period, use the timeout parameter, for example:
unload name=signaling-1 method=grace timeout=123

Phoenix will grant the signaling node 123 seconds to finish its tasks and then will unload it, whether
these tasks are finished or not. In case of the signaling node this means forced termination of all
remaining active calls. If on the expiry of this timeout the node is not unloaded within 21 seconds (by
default, see phoenix command), Phoenix will immediately terminate the node. If the timeout is not set or
equals zero, TS will not unload the node until all its tasks are completed.
3. Delete all the configuration data of the node from the files system.conf and phoenix.conf.
4. Access the TS console.

2015 SwitchRay Inc.

60 | Traffic Switch administration

5. Run the config command (see Administration console commands).

2015 SwitchRay Inc.

Monitoring and notification | 61

12 Monitoring and notification


12.1 Monitoring
To monitor Traffic Switch operation:
use the web interface objects Statistics > Current statistics, Equipment > Registrations, CDRs >
Connected calls and others. For details, refer to SR-S4500 v.1.5.4 Operator's manual.
use CLI monitoring tools.
use TS counters.

12.1.1 CLI monitoring tools


Please note that using the administration console for anything else but TS configuration is not
recommended. Run any of the CLI monitoring tools at your own risk.
List of CLI monitoring tools and commands
Using shortcuts
Switching between tools
Using regular expressions

12.1.1.1 List of CLI monitoring tools and commands


Monitoring tools of the TS administration console are listed in the table below.
Tool

Commands

calls

display
show
format full
format short

counte
rs

display
show

Description
The commands display information about call sessions currently in
progress.
The commands change the output format of the information.
The tool displays the list of TS counters. You can limit the output to
show information about a specific counter only, for example:
mvts3g|> counters display node.calls.rate.peak

The tool also allows regular expressions.


zones

display

The tool displays information about configured IP zones.


show

The tool displays information about:

show
calls
counters

call sessions in progress.


TS counters. The command allows limiting the output to show
information about a specific counter only, for example:
mvts3g|> show counters node.legs.started

The command also allows regular expressions.


zones

2015 SwitchRay Inc.

configured IP zones.

62 | Traffic Switch administration

endpoints
status

equipment registered to the system.


all configured TS nodes. The command allows limiting the output to
show information about a specific node only, for example:
mvts3g|> show status signaling-1

The command also allows regular expressions.


briefstatus

status of TS nodes in brief.

As you can see, you can carry out one and the same task in several ways. For example, to view information
about active calls you can do one of the following:
Invoke the tool calls and execute the command show or display:
mvts3g|calls|> show

Start the tool show and execute the command calls:


mvts3g|show|> calls

Type the command show calls:


mvts3g|> show calls

12.1.1.2 Using shortcuts


You can enter commands and names of tools as shell shortcuts to save typing:
Tool / Command

Shortcut

briefstatus

bs

calls

ca

counters

co

display

endpoints

ep

show

sh

status

st

zones

zo

For example:
mvts3g|> sh ca
Active calls on signaling-1:
-----------------------------------------------------------------------------------From
Proto SrcNum
DstNum
To
Proto SrcNum
DstNum
-----------------------------------------------------------------------------------From 192.168.132.1
H323 112
300
To
192.168.132.15 H323 112
300

2015 SwitchRay Inc.

Monitoring and notification | 63

-----------------------------------------------------------------------------------Total for signaling-1: 1

12.1.1.3 Switching between tools


To switch between tools, simply enter the name of the required tool at the command prompt, for example:
mvts3g|> calls
mvts3g|calls|> counters
mvts3g|calls|counters|>
mvts3g|calls|counters|> zones

To switch on a level higher, type exit. For example:


mvts3g|calls|counters|> exit
mvts3g|calls|>

12.1.1.4 Using regular expressions


The show counters command (the counters tool) and the show status command can include regular
expressions to limit the amount of displayed information. For this, use the case-sensitive regexp syntax of the
Perl programming language. For details, see:
http://perldoc.perl.org/perlre.html
http://www.boost.org/doc/libs/1_49_0/libs/regex/doc/html/boost_regex/syntax/perl_syntax.html
Below are the examples of regular expressions in the CLI monitoring tools:
The status command of the show tool when used with the media-[1,2] regular expression shows
status information only about the "media-1" and "media-2" nodes:
mvts3g|> sh st media-[1,2]
MEDIA "media-1"
Node:
Status: ONLINE
System:
Version: 4.6.0
UpTime: 00:21:12 (User: 00:00:17; Sys: 00:00:01)
...
MEDIA "media-2"
Node:
Status: ONLINE
System:
Version: 4.6.0
UpTime: 00:21:12 (User: 00:00:17; Sys: 00:00:02)
...

The status command of the show tool when used with the signaling.*|media.* regular
expression shows status information only about all media and signaling nodes:
mvts3g|> sh st signaling.*|media.*

2015 SwitchRay Inc.

64 | Traffic Switch administration

SIGNALING "signaling-1"
Node:
Status: ONLINE
System:
Version: 4.6.0
UpTime: 00:05:10 (User: 00:00:05; Sys: 00:00:00)
...
SIGNALING "signaling-2"
Node:
Status: ONLINE
System:
Version: 4.6.0
UpTime: 00:05:10 (User: 00:00:05; Sys: 00:00:00)
...
MEDIA "media-1"
Node:
Status: ONLINE
System:
Version: 4.6.0
UpTime: 00:21:12 (User: 00:00:17; Sys: 00:00:01)
...

The show command of the counters tool when used with the .*restart.* regular expression
displays information about the TS nodes restart events only:
mvts3g|counters|> show .*restart.*
MANAGEMENT:
phoenix.restartcount

SCRIPTING SERVER "configurator"


phoenix.restartcount

SIGNALING "signaling-1"
phoenix.restartcount

SIPPROXY SERVER "sipproxy"


phoenix.restartcount

SYNCHRO SERVER "synchro"


phoenix.restartcount

The show command of the counters tool when used with the media.* regular expression displays
information about counters of media nodes only:
mvts3g|> sh co media.*
MEDIA "media-1"
media.channels

MEDIA "media-2"
media.channels

MEDIA "media-4"

2015 SwitchRay Inc.

Monitoring and notification | 65

media.channels
media.channels.converting

10
5

12.1.2 TS counters
What are TS counters?
List of TS counters
How to monitor TS counters

12.1.2.1 What are TS counters?


A TS counter is a named value. Each TS node has its own set of counters. There are also counters, which are
valid for all TS nodes without exception.
Functionally, there are two types of counters:
counters, whose values only increase (increment)
counters, whose values may either decrease or increase (increment/decrement)
Counters activate automatically when TS starts and reset when it reboots. When a node crashes, TS counters
are included into the runtime info file of the node (see How to get runtime information of TS nodes).

12.1.2.2 List of TS counters


The list of TS counters is in the table below.
Counter

Type

Description

Any node
phoenix.signal.<UNIX signal>, for example:
phoenix.signal.SIGSEGV
phoenix.signal.SIGABRT

Increment

Number of UNIX signals (according


to POSIX standard), which caused
the restart of the node. Some of the
signals (like SIGSEGV or SIGABRT)
may indicate that the node has
crashed.

phoenix.restartcount

Increment

Number of times Phoenix restarted


the node.

Signaling node

2015 SwitchRay Inc.

node.calls.rate.current

Increment/
decrement

Current CPS value.

node.calls.rate.peak

Increment

Peak CPS value.

node.legs.active.current

Increment/
decrement

Number of all currently active call


legs (including internal protocol),
handled by the node.

node.legs.active.licensed

Increment/
decrement

Number of currently licensed call


legs (only SIP, H.323), handled by
the node.

node.legs.active.peak

Increment

Number of all active call legs,


handled by the node at the peak of
traffic.

66 | Traffic Switch administration

Counter

Type

Description

node.legs.started

Increment

Number of all call legs, started by


the node

node.legs.terminated

Increment

Number of all call legs, terminated


by the node

node.legs.terminate.reason.<DC>, for example: Increment


node.legs.terminate.reason.sip.busy_her
e
node.legs.terminate.reason.sip.decline

Number of call legs, terminated by


the node with the disconnect code
<DC>. Rapid increment of counter
values with unsuccessful
disconnect codes may point to
corresponding problems in TS
functioning. The following groups
of codes are used:
SIP
Q.850 (for H.323)
local (TS)
mvtsiidb (Database)
mvtsiitm (trafficmanager node)

Media node
media.channels

Increment/
decrement

Number of currently active media


channels.

media.channels.converting

Increment/
decrement

Number of currently active media


channels with conversion of voice
codecs.

12.1.2.3 How to monitor TS counters


To get TS counters once, use the CLI tools show counters, counters display or counters show.
To monitor TS counters via SNMP applications:
1. Configure the SNMP agent on the server hosting Traffic Switch.
2. Define a list of counters to be monitored:
by loading the MIB file into your monitoring system (default list), or
in the file /etc/snmp/snmpd.conf (see How to define list of counters to be monitored via SNMP).
You may also send notifications on critical changes in values of TS counters (for details, see How to notify
about changes in TS counters).

12.2 Notification sending


Traffic Switch can notify you about problems in TS nodes operation. When a trouble occurs, the script /usr/
sbin/mvts3g-mail reads the file /etc/mvts3g/mvts3g-mail.conf* and performs alerting in accordance with the
settings therein. These alerting messages are called TS alarms.
You may wish to configure sending of TS alarms:
to email addresses
as SNMP traps
One of the TS alarms (COUNTER001) allows you to dispatch email notifications on critical changes in values

2015 SwitchRay Inc.

Monitoring and notification | 67

of TS counters. For more information, refer to the section How to notify about changes in TS counters.
To prevent overwhelming flow of notifications, refer to the section How to avoid repetitive notifications.
Note: The configuration file allows one-line comments, starting anywhere in a line with the '#' character
and extending to the end of the line.

12.2.1 TS alarms
TS alarms are warning messages sent to the operator or administrator in case of TS nodes malfunctioning.
They can be emailed or sent as SNMP traps. When a trouble occurs, TS alarms are automatically written to
the phoenix.log file.
The section presents a list of TS alarms:
Common alarms
Management node alarms
Signaling node alarms
H.323 balancer node alarms
SIP proxy node alarms
Media node alarms
trafficmanager node alarms

12.2.1.1 Common alarms


The alarms common for all TS nodes are listed in the table below.
Alarm

Severity

Message

Notes

COUNTER001

Minor

Counter value <value> more than


<value>
Counter value increased on <step
value>

See How to notify about changes in


TS counters.

NODFLT001

Major

Node '<node name>' crashed and was See also How to restart nodes.
restarted. Please contact customer
support

12.2.1.2 Management node alarms


Alarm

Severity

Message

MGMCFG001

Critical

System is unconfigured
<description>

MGMCFG010

Critical

Connection to primary management


node was LOST!!!
Connection to primary management
node was RESTORED!!!
Failed to create connection to primary
management node

2015 SwitchRay Inc.

MGMTCN001

Critical

Trial period has expired

MGMTCN002

Minor

Left 3 days before trial expiration of

Notes

The alarm is actual for the backup


management node.

68 | Traffic Switch administration

Alarm

Severity

Message

Notes

the dongle with id <key id>


MGMKEY001

Critical

Failed to read hardware key

MGMKEY002

Major

Using backup dongle for primary


management node

12.2.1.3 Signaling node alarms


Alarm

Severity

Message

Notes

NODLOG001

Minor

Logs are on

Logging for a node was enabled


(see TS nodes logging).

SIGMIPR001

Major

Critical call rate exceeded! Current


rate: <value>

The max_calls_rate threshold


defined in the signaling node
configuration was violated.

12.2.1.4 H.323 balancer node alarms


Alarm
NODLOG001

Severity
Minor

Message

Notes

Logs are on

Logging for a node was enabled


(see TS nodes logging).

CPS_<network_ Major
address>

Max CPS rate for this network


exceeded!

CPS limits for H.323 are configured


in the web interface object Traffic
Switch > Traffic Switch
configuration > H.323 limits > CPS
limitation. For details, see How to
limit CPS/RPS for H.323 traffic.

RPS_<network_ Major
address>

Max RPS rate for this network


exceeded!

RPS limits for H.323 are configured


in the web interface object Traffic
Switch > Traffic Switch
configuration > H.323 limits > RPS
limitation. For details, see How to
limit CPS/RPS for H.323 traffic.

12.2.1.5 SIP proxy node alarms


Alarm
<realm name>

Severity
Major

Message

Notes

<realm> realm placed in STOP-LIST!

The realm <realm name> got into the


stop-list due to traffic restrictions
(configured in the web interface
object Traffic Switch > Traffic
Switch configuration > [SIP proxy
node] > Load control > Load control
realms settings). For details, see
How TS selects a queue for requests
from a realm.

2015 SwitchRay Inc.

Monitoring and notification | 69

12.2.1.6 Media node alarms


Alarm
MEDLOAD001

Severity
Major

Message

Notes

<node name> is overloaded for more


than <count> seconds

Optional balancing method is


enabled. See also How TS balances
media.

12.2.1.7 trafficmanager node alarms


Alarm

Severity

Message

Notes

CCH001

Major

Cache failure

CCH002

Major

Cannot find data in cache

DB001

Critical

TS-DB interaction failure

DB002

Critical

Not enough DBMS clients

DB003

Major

Too many requests to DB

DB004

Minor

Interaction with DB temporary


interrupted

For about 10 sec.

LOG001

Minor

Logging temporary interrupted

Logging temporarily discontinued


due to a buffer overflow (to many
logging requests).

TMGN001

Critical

Management node unavailable

The trafficmanager node failed to


connect to the management node
within 30 min.

TMGN002

Critical

Configure SIP extensions notification The trafficmanager node failed to


wasn't delivered
send a list of supported SIP
extensions to a signaling node.

TMG001

Critical

DBMS client trafficmanager node


connection failure

DBS001

Critical

TCP connection to DB failed

DBS002

Critical

Cannot create DB session

There should be at least two DBMS


clients for each DB.

12.2.2 Sending email notifications


To send email notifications:
1. Make sure an MTA is installed and running on the server hosting Traffic Switch (see Working with
MTA).
2. In any plain-text editor, open the file /etc/mvts3g/mvts3g-mail.conf.
3. Define TS alarms and their severity degrees to alert about:
ALARM_ID="NODFLT001, SIG2MED001" // list of events to alert the operator to
ALARM_SEVERITY="CRITICAL, MAJOR, MINOR" // degrees of the alarm severity

4. Configure email messages settings:

2015 SwitchRay Inc.

70 | Traffic Switch administration

FROM="mvts3g-notification <username@hostname.com>" // email address from


where notifications originate
TO="user1 <user1@hostname.com>, user2 <user2@hostname.com>" // list of email
addresses of notification recipients
ALARM_SUBJECT="Notification" // subject of a notification message
...
MSG_APPENDIX="Best regards, SR-S4500." // any text added to the end of a
notification message

5. Save the file mvts3g-mail.conf.


The configuration is complete.

12.2.2.1 How to notify about changes in TS counters


To notify about changes in TS counters:
1. Enable email notification sending.
2. In any plain-text editor, open the file /etc/mvts3g/mvts3g-mail.conf.
3. Add COUNTER001 to the list of alarms (ALARM_ID).
4. Add MINOR to the list of severity degrees (ALARM_SEVERITY).
5. Save the file mvts3g-mail.conf.
6. Open the configuration file of a desired TS node type (for example, system-1.media.conf).
7. In the common section, define the following parameters:
common
{
alert "<alert>" // any name of the alert you find appropriate
{
counter "<counter>" // counter name
{
type "<type>"; // nature of changes (valid values: "increment"
and "decrement")
limit "<limit>"; // counter value violation which causes sending
of a notification
step "<step>"; // variation tolerance for the counter values to
avoid repetitive notifications.
};
};
};

Below is an example of a properly configured notification:


common
{
alert "New channel with transcoding"
{
counter "media.channels.converting"
{
type "increment";
step "100";
};
};

2015 SwitchRay Inc.

Monitoring and notification | 71

};

If you have several nodes of the same type and want to receive separate notifications about alerts on
each node, you should configure alerts individually in the configuration section of each node. To
discriminate between nodes in notifications, add the name of the node to the alert name. For example,
alert "New channel with transcoding (media-1)", alert
"New channel with
transcoding (media-2)", etc.
8. Access the TS console.
9. Run the config command (see Administration console commands).
In case the value of a counter drops below or exceeds the configured threshold, Traffic Switch sends a
corresponding notification.
Below is the result of a properly configured alert:
ID:
COUNTER001
SEVERITY:
MINOR
NODE:
MEDIA
COUNTER NAME: media.channels.converting
COUNTER VALUE: 5
DESCRIPTION:
New channel with transcoding
Counter value more than 1

12.2.2.2 How to avoid repetitive notifications


To avoid repetitive notifications:
1. In any plain-text editor, open the file /etc/mvts3g/mvts3g-mail.conf.
2. In the SEND_MINUTE_INTERVAL parameter, define a time interval between periodic notifications in
minutes:
SEND_MINUTE_INTERVAL="10"

3. Save the file mvts3g-mail.conf.


The configuration is complete. Alert messages that occur within the configured period are included in one
letter to avoid an overwhelming flow of notifications when the status of an alert rapidly changes.

12.3 Working with SNMP


This section describes:
How Traffic Switch works with SNMP
TS private enterprise MIB file
How to configure SNMP agent
How to define list of counters to be monitored via SNMP
How to send SNMP traps

12.3.1 How Traffic Switch works with SNMP


To interact with SNMP applications, Traffic Switch employs a popular software suite Net-SNMP. Having
configured the net-snmp packet and Traffic Switch, you will be able to get TS counters and dispatch TS
alarms as SNMP traps to your monitoring system.
SNMP uses a Management Information Base (MIB) file for managing the entities in a communications

2015 SwitchRay Inc.

72 | Traffic Switch administration

network. The database is hierarchical (tree-structured) and each entry is addressed through an object
identifier (OID). Traffic Switch has its own Private Enterprise Number (PEN) 28029 to use it in its own MIB
file. Thus, branch .1.3.6.1.4.1.28029 may be used for TS counters and TS alarms.
Currently, you may use the GET, GETNEXT and GETBULK requests on your monitoring server. The SET
request is not supported.

12.3.2 TS private enterprise MIB file


Traffic Switch provides the private enterprise MIB file /usr/share/snmp/mibs/mvtsii.mib. You may load it to
your monitoring server to monitor TS counters. OIDs will be displayed as text values.
The table below describes OID branches and their objects defined in the MIB file by default. In the last
column there are parameters you may use in the snmpd.conf file to substitute the default lists of counters. For
details, refer to the section How to define list of counters to be monitored via SNMP.
OID branch

Objects

.1.3.6.1.4.1.28029.11.1

A list with names of TS nodes


(regardless of the SNMP configuration
in TS)

.1.3.6.1.4.1.28029.11.2

The common counter

snmpd.conf parameter

mvtsCommonCounter

phoenix.restartcount

.1.3.6.1.4.1.28029.11.3

The counters of signaling nodes:

mvtsSignalingCounter

node.legs.active.current
node.legs.active.peak
node.legs.started
node.legs.terminated
node.calls.rate.current
node.calls.rate.peak

.1.3.6.1.4.1.28029.11.4

The counter of media nodes

mvtsMediaCounter

media.channels

Note: when changing the default lists, default text values specified in the MIB file become incorrect in the
whole OID branch.

12.3.3 How to configure SNMP agent


Configure an SNMP agent (the snmpd daemon) on the server hosting Traffic Switch. The SNMP agent
responds to SNMP requests from a monitoring server, i.e. returns values of TS counters. Also, the SNMP
agent sends TS alarms as SNMP traps.
To configure the snmpd daemon:
1. In any plain-text editor, open the file /etc/snmp/snmpd.conf.
2. Delete the contents of this file.
3. Add the following lines, defining your own values:
agentaddress udp:192.168.127.113
com2sec readonly default community
group redonly v2c readonly
view all
included .1
access redonly "" any noauth exact all none none
dlmod mvts /usr/lib/mvts3g/libsnmpagent.so

2015 SwitchRay Inc.

Monitoring and notification | 73

mvtsPrimaryConnectAddress 192.168.127.113:9000
mvtsBackupConnectAddress 192.168.34.53:9001

where:
agentaddress IP address of an SNMP agent or agents, which will listen for SNMP requests from
a monitoring server. Use comma (,) as the delimiter (for example, udp:192.168.127.113,
udp:192.168.34.52).
com2sec readonly default community access rights (read only). Change the word default

(access from all IP addresses) to the IP address of your monitoring system. Change the word
community to some other secure string.
mvtsPrimaryConnectAddress IP address and port of the primary management node (as defined
in the management command of the phoenix.conf file).
mvtsBackupConnectAddress IP address and port of the backup management node (as defined
in the management command of the phoenix.conf file).
4. Save the file /etc/snmp/snmpd.conf.
5. Start the SNMP daemon:
#> /etc/init.d/snmpd start

6. Check that the daemon is running correctly:


#> snmpwalk -v 2c -c community 192.168.127.113 .1.3.6.1.4.1.28029

where:
community secure name you defined in Step 3;
192.168.127.113 IP address of the management node (as defined in the management command

of the phoenix.conf file);


.1.3.6.1.4.1.28029 SR-S4500 enterprise OID.
If this command does not work, make sure that you have installed the snmp packet (see Updating
Linux Kernel). The output of this command will be in the following format:
iso.3.6.1.4.1.28029.11.1.1 = STRING: "management-1"
iso.3.6.1.4.1.28029.11.1.2 = STRING: "signaling-1"
iso.3.6.1.4.1.28029.11.1.3 = STRING: "signaling-2"
iso.3.6.1.4.1.28029.11.1.4 = STRING: "balancer-1"
...
iso.3.6.1.4.1.28029.11.2.1.2.1 = INTEGER: 0
iso.3.6.1.4.1.28029.11.2.1.2.2 = INTEGER: 0
iso.3.6.1.4.1.28029.11.2.1.2.3 = INTEGER: 0
iso.3.6.1.4.1.28029.11.2.1.2.4 = INTEGER: 0
...

This is the default list of counters as defined in the TS MIB file. See also How to define list of counters
to be monitored via SNMP.
The configuration is complete.

12.3.4 How to define list of counters to be monitored via SNMP


To create a custom list of TS counters to be monitored via SNMP:
1. In any plain-text editor, open the file /etc/snmp/snmpd.conf.
2. Determine what counters you want to monitor. For this, refer to the TS counters section or use the sh

2015 SwitchRay Inc.

74 | Traffic Switch administration

co monitoring tool in the TS administration console.


3. At the end of the file, add desired counters with a node type identifier. For example:
mvtsSignalingCounter node.legs.active.licensed
mvtsCommonCounter phoenix.signal.SIGSEGV
mvtsMediaCounter media.channels.converting

You can use the following identifiers:


mvtsCommonCounter for counters common for all nodes;
mvtsSignalingCounter for signaling node counters;
mvtsMediaCounter for media node counters.

Please note that when you define custom counters, the default list specified in the MIB file is replaced.
4. Restart the SNMP daemon:
#> /etc/init.d/snmpd restart

5. Check that the daemon is running correctly (see How to configure SNMP agent, Step 6). The example
of the output for the signaling node counter node.legs.active.licensed:
iso.3.6.1.4.1.28029.11.3.1.1.1
iso.3.6.1.4.1.28029.11.3.1.1.2
iso.3.6.1.4.1.28029.11.3.1.2.1
iso.3.6.1.4.1.28029.11.3.1.2.2

=
=
=
=

STRING: "signaling-1"
STRING: "signaling-2"
INTEGER: 10
INTEGER: 14

The value .11.3.1.2.1 is for the node "signaling-1", whereas .11.3.1.2.2 is for "signaling-2".
Counter names are sorted in alphabetical order.

12.3.5 How to send SNMP traps


To send TS alarms as SNMP traps:
1. Configure SNMP agent.
2. Configure snmptrapd daemon.
3. Configure mvts3g-mail.

12.3.5.1 How to configure snmptrapd


Receiving SNMP traps requires properly configured snmptrapd daemon running on the monitoring server.
To configure snmptrapd:
1. In the file /etc/snmp/snmptrapd.conf, add the following line:
authCommunity log,execute,net community

where community is the community name defined in the SNMP agent configuration.
2. Save the file /etc/snmp/snmptrapd.conf.
3. Restart the SNMP agent on the server hosting Traffic Switch:
#> /etc/init.d/snmpd start

The configuration is complete.

2015 SwitchRay Inc.

Monitoring and notification | 75

12.3.5.2 How to configure mvts3g-mail for SNMP traps sending


Should a TS alarm trigger, the mvts3g-mail script converts this alarm to the SNMP OID and runs an SNMP
trap command. The command generates a trap to report an event to the SNMP manager.
To configure mvts3g-mail for SNMP traps sending:
1. In any plain-text editor, open the file /etc/mvts3g/mvts3g-mail.conf.
2. Make sure that all required alarm IDs are listed in the ALARM_ID parameter.
3. Make sure that severity levels of required alarms are listed in the ALARM_SEVERITY parameter.
4. Add the parameter SNMP_OIDS with any SNMP OID for each ALARM_ID. For example:
SNMP_OIDS="NODFLT001:1.2.3.4.7, MGMCFG001:1.2.3.4.8"

Note: the COUNTER001 alarm is not supported.


5. Add the parameter SNMP_CMD with a path to the snmptrap command with required arguments:
SNMP_CMD="/usr/bin/snmptrap -v1 -c community destination_IP OID agent_IP 6 0
''"

where:
community is the community name defined in the SNMP agent configuration,
destination_IP is the target IP address of the monitoring server to which the trap message will

be sent,
agent_IP is the IP address of the server hosting the SNMP agent,
OID is the OID to be excluded.

6. Save the file mvts3g-mail.conf.


The configuration is complete.

2015 SwitchRay Inc.

76 | Traffic Switch administration

13 System logging
Traffic Switch log files are stored in the directory /var/log/mvts3g/.
Note that the use of the logging functionality can adversely affect the operation of the TS nodes
in terms of CPU resources. Moreover logging requires sufficient free disk space. Running low of
free disk space may result in System failures. Please consider this fact when allocating disk space
for the /var directory.
There are two main log files: phoenix.log and traffic.log.

13.1 Phoenix logging


In case you encounter any problem with Traffic Switch operation, use the file /var/log/mvts3g/phoenix.log to
investigate what caused the trouble. This log contains the messages about:
Traffic Switch starting,
TS configuration changing,
Traffic Switch malfunctioning (TS alarms),
operation of Traffic Switch nodes,
Traffic Switch console logons and executed console commands,
changes on a network interface (such as changing/adding/removing IP addresses, plugging/
unplugging Ethernet cables, etc.).
The phoenix.log file is written by the default Debian utility/daemon rsyslogd (use the command man
rsyslogd to get more information). Using its configuration file (/etc/rsyslogd.conf), you may wish to:
change the phoenix.log filename or its location;
disable logging of TS messages into the file /var/log/syslog;
split phoenix.log to get separate logs for TS nodes.
After making any changes in the file /etc/rsyslogd.conf, do not forget to restart rsyslogd:
#> service rsyslog restart

13.1.1 How to change phoenix.log filename or location


By default, TS sends its messages to facility local5 of the rsyslogd utility. To change the facility, filename of
the log or its location, use the following parameter in the file /etc/rsyslogd.conf:
local5.*

-/var/log/mvts3g/phoenix.log

After that, restart rsyslogd:


#> service rsyslog restart

13.1.2 How to disable TS logging in /var/log/syslog


Due to default rsyslogd settings, this utility also saves all TS messages into the file /var/log/syslog. To
disable such behavior, add local5.none into the following line of the file /etc/rsyslogd.conf:
*.*;auth,authpriv.none;local5.none

-/var/log/syslog

After that, restart rsyslogd:

2015 SwitchRay Inc.

System logging | 77

#> service rsyslog restart

13.1.3 How to get separate logs for TS nodes


Operation of individual Traffic Switch nodes can be logged to separate files to decrease the phoenix.log file
size and to make troubleshooting easier. To enable this:
1. Choose one of the unallocated facilities of the utility rsyslogd. Do not use such facilities as kern,
mark, security, syslog or local5. Use a separate facility for each node. To view the whole list of all
facilities run the command:
#> man syslog.conf

2. In the file phoenix.conf, in the load command of the desired node, define the facility you chose in Step
1. For example:
load type=signaling name=signaling-1 facility=local0

3. Define the log file which should be used for this facility. For this, edit the file /etc/rsyslogd.conf. In
our example it would be the following line:
local0.*

-/var/log/mvts3g/phoenix_signaling.log

4. Restart Traffic Switch.


5. Restart rsyslogd:
#> service rsyslog restart

Events related to the node "signaling-1" will be logged only to the file phoenix_signaling.log.

13.2 TS nodes logging


Traffic Switch can write all SIP/H.323 signaling packets, as well as message packets exchanged by nodes to
the global debug file /var/log/mvts3g/traffic.log.
Below is the table demonstrating how you can control logging of nodes:
Node type

How to control
logging

Notes

H.323 balancer, signaling

In the section common

TS configurator

In the configuration file of the


node

The log is written into the separate


file (for example,
mvtsprologic.configurator-1.log)

H.323 balancer, signaling

Using the loglevel or log


command in the TS console

See Administration console


commands

When examining the resulting traffic.log file, you may save logs of individual call session to separate files.
For details, refer to the section How to extract logs of individual call sessions.
To change the name of the log file or its location, edit the parameter trafficlog of the statestore command
in the phoenix.conf file and restart TS.

2015 SwitchRay Inc.

78 | Traffic Switch administration

13.2.1 How to control logging in the section common


Enabling logging in the Traffic Switch configuration files is not recommended as it largely affects
the System performance. Use this parameter only if you want to get the full traffic log. To get logs
of specific call sessions, gateways or routes use the logging feature configured through the web
interface. For details, please refer to SR-S4500 v.1.5.4 Operator's manual.
To control logging with the help of configuration files:
1. Open the configuration file of a desired TS node type (for example, system-1.signaling.conf).
2. In the common section, define a value of the parameter loglevel (0 disables logging and any nonzero integer value enables it).
3. Optionally, to prevent disk overflow situations owing to large volumes of log files, you may configure
logging timeout for signaling and H.323 balancer nodes. For this, in the common section, add the
following parameter:
loglevel_timeout "x"

where x is the logging period in minutes. By default, logging is disabled after 24 hours.
4. Save the file.
5. Access the TS console.
6. Run the config command (see Administration console commands).
The configuration is complete.

13.2.2 How to control logging of TS configurator


To control logging of the TS configurator:
1. Open the configuration file of the TS configurator (for example, system-1.scripting.conf).
2. In the trace_level parameter, define the level of details in logs. Possible values (in brackets are
shown how you can identify the messages in log files):

0 no logging;
1 critical errors (CRITICAL);
2 all errors (ERROR);
3 warning messages (WARNING);
4 information messages (INFO);
5 debug messages (DEBUG);
6 extra debug messages (DEBUG2);
7 additional debug messages (DEBUG2C).

3. Optionally, in the trace_file parameter, you may change the prefix used in the log filename. For
example, if the value of this parameter is mvtsprologic (default) and the node name is "configurator1", the log filename will be mvtsprologic.configurator-1.log.
4. Save the file.
5. Access the TS console.
6. Run the config command (see Administration console commands).
The configuration is complete. See also Configuring rotation of TS configurator logs.

2015 SwitchRay Inc.

System logging | 79

13.2.3 How to extract logs of individual call sessions


To extract logs of call sessions from the file traffic.log, use the /usr/bin/mvts3g-logextractor utility. Run the
following command:
#> ./mvts3g-logextractor /var/log/mvts3g/traffic.log CONF_ID> filename.log

where CONF_ID is the field Conference ID (TS) obtained from a desired CDR and filename.log is a name
of the file to which the call data will be written.
You can use the resulting log to examine the call session or submit it for analysis by our technical support
team.

13.3 How to get runtime information of TS nodes


Runtime information (RTINFO) files are logs that provide operational information about individual TS nodes.
Traffic Switch creates such log files automatically after each crash of the process.
To force generation of an RTINFO log file without crashing or stopping the node, execute the command kill
with the signal -USR1 specifying the node of interest. For example:
#> kill -USR1

`ps ax | awk '/signaling-1/ && $0 !~/awk/ {print $1}'`

where signaling-1 is the node name specified in the load command of the phoenix.conf file. Instead of
writing a specific node name, you can define a pattern. For instance, write media for getting RTINFO of all
media nodes ("media-1", "media-2", etc.)
The resulting RTINFO file will be /var/log/mvts3g/rtinfo-SIGUSR1-signaling-1-18278-31640.log, where:
signaling-1 is the node name;
18278 is the pid of the node;
31640 is the pid of the process which created the RTINFO file.
The file will comprise a binary dump of the latest packets processed by the node and detailed messages
about system errors. The log will also contain the values of the counters of this node.

13.4 How to configure rotation of logs


Traffic Switch uses the default Debian utility called logrotate for rotation of TS log files. The utility
automatically splits logs into several files and deletes obsolete files so that the total size of logs does not
exceed a specified value.
Depending on the amount of traffic some settings of log rotation may require changes. You may wish to
configure rotation of:
traffic.log
phoenix.log
TS configurator log files
The purpose of parameters you may find while configuring rotation is described in the manual to the
logrotate command. To invoke the manual, run:
#> man logrotate

After making any changes to a logrotate configuration file, execute the following command to force rotation
of all logs:
#> logrotate -fv /etc/logrotate.conf

2015 SwitchRay Inc.

80 | Traffic Switch administration

You may also wish to configure more frequent rotation of traffic.log and phoenix.log. For details, refer to the
section Rotating logs every X minutes.

13.4.1 Configuring rotation of traffic.log and phoenix.log


Traffic Switch applies default settings for rotation of logs traffic.log and phoenix.log automatically once TS
installation is completed. You may find and edit these settings in the file /etc/logrotate.d/mvts3g-server-pro:
/var/log/mvts3g/phoenix.log {
rotate 10
daily
size 1M
nocompress
postrotate
/usr/bin/killall -HUP -r r?syslogd
endscript
}
/var/log/mvts3g/traffic.log {
rotate 5
daily
size 64M
nocompress
postrotate
/usr/bin/killall -HUP mvts3g-server
endscript
}

13.4.2 Configuring rotation of TS configurator logs


To configure rotation of TS configurator logs, find and edit the file /etc/logrotate.d/mvts-config-logic.
Below is an example of this file:
/var/log/mvts3g/mvtsprologic.configurator-1.log {
rotate 10
daily
size 64M
nocompress
postrotate
/usr/bin/mvts3g-sclient 127.0.0.1:7710 logrotate
endscript
}

The name of the section (the first line) is the path to and name of the log file. The name of the log file
(mvtsprologic.configurator-1.log) should conform to the <prefix>.<node name>.log format, where:
<prefix> is the value of the trace_file parameter from the TS configurator configuration;
<node name> is the name of the TS configurator, specified in the load command of the file

phoenix.conf.
The postrotate section contains:
the full path to the mvts3g-sclient application;
the IP address of the server hosting the TS configurator (127.0.0.1, if running on the same server as TS)
with the port defined in the controllink section in the TS configurator configuration;

2015 SwitchRay Inc.

System logging | 81

the logrotate keyword.


When done, execute the following command to force rotation of all logs:
#> logrotate -fv /etc/logrotate.conf

13.4.3 Rotating logs every X minutes


By default, logrotate handles your logs daily. However, under heavy loads daily rotation of traffic.log and
phoenix.log might not be enough. Resulting log files grow too large, which makes it problematic to
investigate a problem.
In this case, it is recommended to enable more frequent launching of the logrotate utility. For this, in the file /
etc/cron.d/mvts3g-server-pro uncomment the following line:
*/30 * * * * root test -x /usr/sbin/logrotate && /usr/sbin/logrotate /etc/
logrotate.d/mvts3g-server-pro

where instead of 30 write the required frequency of launching the utility (for example, 15 for each 15 minutes).
The recommended minimal rotation period is every 10 minutes.

Note: this configuration is not applied to the TS configurator logs.

13.4.4 traffic.log rotation periods


The table below shows recommended rotation periods (in min.) to get traffic.log of a specific size under
different traffic intensity.
2 GB

4 GB

6 GB

8 GB

10 GB

<10 CPS

12

20

30

30

30

10-20 CPS

12

20

20

30

20-30 CPS

12

15

20

30-40 CPS

12

15

40-50 CPS

10

12

50-60 CPS

10

60-70 CPS

70-80 CPS

80-90 CPS

90-100 CPS

For example, when rotating traffic.log every 12 minutes under 10-20 CPS we will get this file 4 GB in size.

13.4.5 Rotating RTINFO and dump files


To configuration automatic deletion of obsolete RTINFO and memory dump files:
1. Create the shell script /usr/local/log_purge.sh with the following contents:

2015 SwitchRay Inc.

82 | Traffic Switch administration

#/bin/sh
find /var/log/mvts3g/*.core -mtime +15 -exec rm {} \;
find /var/log/mvts3g/rtin*.log -mtime +15 -exec rm {} \;

where 15 is the number of days for one rotation cycle. The period is estimated with respect to the free
disk space. 15 is the recommended value.
2. Make the script executable:
#> chmod +x /usr/local/log_purge.sh

3. Add a crontab task for the script:


#> echo "10 1

* * *

root

/usr/local/log_purge.sh" >> /etc/crontab

The configuration is complete.

2015 SwitchRay Inc.

Appendix A. Example of TS configuration files | 83

14 Appendix A. Example of TS configuration files


phoenix.conf
management primary=192.168.133.113:9000 backup=192.168.34.53:9001
phoenix address=127.0.0.1:5000
statestore db=/var/log/mvts3g/phoenix.db trafficlog=traffic.log
load type=management name=management-1 mode=main
load type=balancer name=balancer-1
load type=signaling name=signaling-1
load type=media name=media-1
load type=commandline name=commandline-1 address=127.0.0.1:7000
load type=synchro name=synchro-1
load type=trafficmanager name=trafficmanager-1
load type=sipproxy name=sipproxy-1
load type=scripting name=configurator-1 capability=config

system-1.conf
include
include
include
include
include
include
include
include
include

"/etc/mvts3g/system-1.zone.conf";
"/etc/mvts3g/system-1.balancer.conf";
"/etc/mvts3g/system-1.signaling.conf";
"/etc/mvts3g/system-1.media.conf";
"/etc/mvts3g/system-1.trafficmanager.conf";
"/etc/mvts3g/system-1.synchro.conf";
"/etc/mvts3g/system-1.scripting.conf";
"/etc/mvts3g/system-1.sipproxy.conf";
"/etc/mvts3g/system-1.balancing.conf";

system-1.balancer.conf
balancer
{
balancer "balancer-1"
{
common
{
loglevel "0";
};
controllink
{
zone "test";
port "7202";
};
ras
{
address
{
"0.0.0.0";
};
port
"1719";
gkname
"MVTS3G";
allow_md5
"yes";
allow_chap "yes";

2015 SwitchRay Inc.

84 | Traffic Switch administration

allow_plain "yes";
};
h323
{
address
{
"0.0.0.0";
};
port "1720";
};
ema_avg_time "10";
call_rate_alarm_lifetime "10";
};
};

system-1.signaling.conf
signaling
{
signaling "signaling-1"
{
common
{
loglevel "0";
};
h323
{
address
{
"0.0.0.0";
};
port "1721";
};
sip
{
address
{
"0.0.0.0";
};
port "5061";
secret "NewSecret";
};
cdr_recovery "yes";
max_calls_rate "100";
call_rate_alarm_lifetime "60";
};
};

system-1.media.conf
media
{
media "media-1"
{
controllink
{

2015 SwitchRay Inc.

Appendix A. Example of TS configuration files | 85

zone "test";
port "7800";
};
portrange "10000-14999";
};
};

system-1.zone.conf
zone
{
zone "test"
{
"192.168.0.0/16";
"212.0.0.0/8";
};
};

system-1.synchro.conf
synchro
{
synchro "synchro-1"
{
controllink
{
zone "test";
port "7711";
};
};
};

system.trafficmanager.conf
trafficmanager
{
trafficmanager "trafficmanager-1"
{
controllink
{
zone "test";
port "7755";
};
sessions "10";
node_id "1";
servicelink "198.162.31.160:7890";
wdTimeout "30000";
wdSleep "10000";
databases
{
database "db-1"
{
address "198.162.31.21:1521";
login "VOIP_DEV";
password "9x87JuiAh0";

2015 SwitchRay Inc.

86 | Traffic Switch administration

sid "RS";
role "routing;billing;logging";
};
database "db-2"
{
address "192.167.15.94:1521";
login "VOIP_DEV";
password "0s44SuAff7";
sid "RS";
role "routing_reserve;billing;logging";
};
};
};
};

system-1.scripting.conf
scripting
{
scripting "configurator-1"
{
controllink
{
zone "test";
port "7710";
};
loader_path "tsconfigurator";
environment
{
trace_level "7";
dbms_type_master
"Oracle";
dbms_name_master
"//198.162.31.21/RS";
dbms_user_master
"VOIP_DEV";
dbms_pswd_master
"9x87JuiAh0";
dbms_type_slave
"Oracle";
dbms_name_slave
"//192.167.15.94/RS";
dbms_user_slave
"VOIP_DEV";
dbms_pswd_slave
"0s44SuAff7";
};
};
};

system-1.sipproxy.conf
sipproxy
{
sipproxy "sipproxy-1"
{
controllink
{
zone "test";
port "7900";
};
};
};

2015 SwitchRay Inc.

Appendix A. Example of TS configuration files | 87

system-1.balancing.conf
balancing
{
balancing "group-1"
{
"signaling-1";
"balancer-1";
"trafficmanager-1";
};
};

2015 SwitchRay Inc.