MVTS Pro v.1.5.0.40 Operator's Manual

© MERA Systems 2007-2009

MVTS Pro 1.5.0-40

Operator's manual

© MERA Systems 2007-2009

MVTS Pro VoIP traffic management system

Document №: 1

Document type: Operator's manual

Document status: Released

Date of issue: 9/21/2009

Software product: MVTS Pro

Copyr ight © 2007-2009 MERA Systems Al l r ights reserved. MERA Systems reserves the r ight to change any informat ion contained in th is document wi thout pr ior not ice.

COPYRIGHT INFORMATION The informat ion contained in th is document is the property of MERA Systems No part of th is publ icat ion may be reproduced or copied in any form or by any means - graphic, e lectronic or mechanical including photocopying, recording, taping, or any other informat ion storage and retr ieval system - wi thout wr i t ten consent of MERA Systems No th ird party, organizat ion or individual, is author ized to grant such permission.

1. 111122222222222222222222222222222222222222222222222222222222222222222222222222222

MVTS Pro 1.5.0-40

p. 3 of 197

Contents

1. INTRODUCTION ......................................................................................................................................6 1.1. DOCUMENT PROFILE ..............................................................................................................................6 1.2. AUDIENCE..............................................................................................................................................6 1.3. NOTATIONAL CONVENTIONS..................................................................................................................6 1.4. DOCUMENT STRUCTURE ........................................................................................................................6 1.5. NAMES, PHONE NUMBERS AND NETWORK ADDRESSES.........................................................................7 1.6. TERMS AND ACRONYMS.........................................................................................................................7

2. SYSTEM OVERVIEW ............................................................................................................................10 2.1. SYSTEM MAKE-UP AND NETWORKING ARRANGEMENTS .......................................................................10

2.1.1. Traffic Manager (TM) .................................................................................................................11 2.1.2. Traffic switch (TS) .......................................................................................................................12 2.1.3. MVTS Pro technical data and specification ................................................................................12

3. SYSTEM CONFIGURATION ................................................................................................................16 3.1. TS CONFIGURATION ............................................................................................................................16 3.2. PHOENIX.CONF AND SYSTEM.CONF SYNTAX ........................................................................................16 3.3. DAEMON PROCESS ‘PHOENIX’ AND CONFIGURATION FILE PHOENIX.CONF............................................17 3.4. CONFIGURATION FILE SYSTEM.CONF ...................................................................................................19 3.5. INDIVIDUAL NODE CONFIGURATION.....................................................................................................20

3.5.1. Common sections.........................................................................................................................21 3.5.2. Registration-balancer configuration ...........................................................................................21 3.5.3. SIGTRAN interoperation node configuration..............................................................................23 3.5.4. Scripting node configuration .......................................................................................................31 3.5.5. Signaling node configuration ......................................................................................................34 3.5.6. Media node configuration............................................................................................................35 3.5.7. Synchronization node configuration............................................................................................35

3.6. IP ZONES..............................................................................................................................................35 3.6.1. SIGTRAN zones ...........................................................................................................................37

3.7. "LOCATION" SECTION...........................................................................................................................38 3.8. TS NOTIFICATION FUNCTION................................................................................................................39 3.9. SNMP DAEMON CONFIGURATION ........................................................................................................41 3.10. CONFIGURATION OF SCRIPTING NODE LOGGING...................................................................................43 3.11. CONFIGURATION OF DB INTEROPERATION ..........................................................................................44

4. TRAFFIC SWITCH ADMINISTRATION............................................................................................46 4.1. TRAFFIC SWITCH ADMINISTRATION CONSOLE ......................................................................................46 4.2. TROUBLESHOOTING .............................................................................................................................48

4.2.1. File phoenix.log...........................................................................................................................48 4.2.2. Files rtinfo ...................................................................................................................................49 4.2.3. Scripting node logs ......................................................................................................................49

4.3. MVTS3G-LOGEXTARCTOR UTILITY .......................................................................................................49 5. MVTS PRO WEB INTERFACE.............................................................................................................50

5.1. WHAT YOU SEE ON THE SCREEN...........................................................................................................50 5.2. STANDARD PROCEDURES .....................................................................................................................51

5.2.1. Accessing TM’s GUI....................................................................................................................51 5.2.2. Pop-up menu................................................................................................................................52 5.2.3. Use of filters ................................................................................................................................53 5.2.4. Sorting table data ........................................................................................................................60 5.2.5. Re-arranging table columns ........................................................................................................60 5.2.6. Editing multiple table records .....................................................................................................61 5.2.7. Data export..................................................................................................................................62 5.2.8. Component version view..............................................................................................................63

6. OPERATING TM.....................................................................................................................................65

MVTS Pro 1.5.0-40

p. 4 of 197

6.1. ADMINISTRATION ................................................................................................................................65 6.1.1. System users.................................................................................................................................65 6.1.2. Web authentication ......................................................................................................................66 6.1.3. Roles ............................................................................................................................................67 6.1.4. Role settings.................................................................................................................................67 6.1.5. System user creation wizard ........................................................................................................68 6.1.6. Web realms ..................................................................................................................................70

6.2. EQUIPMENT..........................................................................................................................................72 6.2.1. Equipment....................................................................................................................................72 6.2.2. Zones ...........................................................................................................................................84 6.2.3. Codec groups...............................................................................................................................85 6.2.4. Codec group setup .......................................................................................................................85

6.3. TERMINATION......................................................................................................................................87 6.3.1. Pre-routing translations ..............................................................................................................87 6.3.2. Dial peers ....................................................................................................................................90 6.3.3. Routing policies ...........................................................................................................................95

6.4. DEBUGGING.........................................................................................................................................98 6.4.1. Call simulation ............................................................................................................................98 6.4.2. Debug calls..................................................................................................................................99 6.4.3. Debug registrations ...................................................................................................................102

6.5. TRAFFIC SWITCH ...............................................................................................................................104 6.5.1. Active calls.................................................................................................................................104 6.5.2. Registrations..............................................................................................................................104 6.5.3. Active nodes...............................................................................................................................105 6.5.4. Nodes .........................................................................................................................................105 6.5.5. SS7 calls.....................................................................................................................................107 6.5.6. ISUP circuits .............................................................................................................................107 6.5.7. MGCP endpoints .......................................................................................................................109 6.5.8. M3UA edpoints ..........................................................................................................................109 6.5.9. M3UA associations....................................................................................................................110

6.6. CDRS ................................................................................................................................................110 6.6.1. CDRs scheduled export .............................................................................................................114 6.6.2. Export interval...........................................................................................................................120

6.7. STATISTICS ........................................................................................................................................120 6.7.1. Reports.......................................................................................................................................120 6.7.2. Charts ........................................................................................................................................124

6.8. GLOBAL SETTINGS .............................................................................................................................127 6.8.1. System global settings................................................................................................................127 6.8.2. Web settings...............................................................................................................................128 6.8.3. Disconnect codes .......................................................................................................................130 6.8.4. RADIUS servers.........................................................................................................................131 6.8.5. ENUM-servers...........................................................................................................................135 6.8.6. DNS servers ...............................................................................................................................136 6.8.7. Areas..........................................................................................................................................136 6.8.8. Area specifics.............................................................................................................................137 6.8.9. Calling party’s categories .........................................................................................................137 6.8.10. CPC translations .......................................................................................................................138 6.8.11. Capacity groups.........................................................................................................................139

6.9. LOGS..................................................................................................................................................140 6.9.1. Web authentication history ........................................................................................................140 6.9.2. Web activity log .........................................................................................................................141

7. MVTS PRO REDUNDANCY................................................................................................................143 7.1. MEDIA NODE REDUNDANCY ..............................................................................................................143 7.2. SIGNALING NODE REDUNDANCY ........................................................................................................144 7.3. BALANCER NODE REDUNDANCY ........................................................................................................145 7.4. SYNCHRO NODE REDUNDANCY ..........................................................................................................146 7.5. LICENSE MANAGEMENT NODE REDUNDANCY....................................................................................146 7.6. DB AND WEB INTERFACE SERVER REDUNDNACY .............................................................................148 7.7. CASE STUDY: TWO SERVER SYSTEM REDUNDANCY ...........................................................................148

MVTS Pro 1.5.0-40

p. 5 of 197

7.7.1. Node distribution .......................................................................................................................148 7.7.2. Configuration files.....................................................................................................................149

7.7.2.1. Primary server configuration .............................................................................................150 7.7.2.2. Standby server configuration .............................................................................................158

7.8. REDUNDANCY USING LINUX HEARTBEAT..........................................................................................159 7.8.1. configuration of TS and scripting node servers.........................................................................159 7.8.2. Configuration of WEB+DB servers...........................................................................................161

7.9. DB BACKUP AND RECOVERY..............................................................................................................162 7.9.1. DB specifics affecting backup policy .........................................................................................162 7.9.2. Backup tools and utilities ..........................................................................................................163 7.9.3. Configuring SSH public key authentication...............................................................................163 7.9.4. Configuring DB backup.............................................................................................................164 7.9.5. Launching backup......................................................................................................................165 7.9.6. Unattended backup arrangements .............................................................................................165 7.9.7. DB recovery procedure .............................................................................................................165

7.10. DB REPLICATION...............................................................................................................................165 7.10.1. Replication types .......................................................................................................................166 7.10.2. Replication configuration ..........................................................................................................166

8. APPENDIX A. METACHARACTERS, REGULAR EXPRESSIONS AND NUMBER TRANSFORMATION ...........................................................................................................................169

8.1. USE OF METACHARACTERS IN SEARCH...............................................................................................169 8.2. USE OF REGULAR EXPRESSIONS IN SEARCH........................................................................................169 8.3. NUMBER TRANSFORMATION ..............................................................................................................170 8.4. TIPS AND TRICKS FOR REGULAR EXPRESSIONS...................................................................................172

9. APPENDIX B. CODEC LIST GENERATION IN MVTS PRO ........................................................173 10. APPENDIX C. DEFAULT GATEWAYS.............................................................................................175 11. APPENDIX D. SIGTRAN NODE LIMITATIONS.............................................................................176 12. APPENDIX E. MVTS PRO – RADIUS INTERACTION...................................................................178

12.1. REGISTERING ENDPOINT AUTHORIZATION .........................................................................................178 12.2. PRE-ROUTING CALL AUTHORIZATION.................................................................................................179 12.3. ACCOUNTING REQUEST......................................................................................................................181

12.3.1. Accounting Start record.............................................................................................................181 12.3.2. Accounting Stop record .............................................................................................................183

12.4. ACCESSREQUEST STRUCTURE FOR RADIUS-AIDED ROUTING...........................................................186 12.4.1. Field XPGK_XROUTING_ROUTING detailed.........................................................................189

12.5. AUTHENTICATION OF REGISTERING DEVICES ON A RADIUS-SERVER................................................189 12.5.1. H.323 ID-based authentication (standard RADIUS authentication) .........................................190 12.5.2. MD5 Authentication ..................................................................................................................190 12.5.3. CHAP Authentication ................................................................................................................191 12.5.4. Digest authentication.................................................................................................................192

13. APPENDIX F. REMOVING CDRS FROM THE DB.........................................................................193

Introduction

MVTS Pro 1.5.0-40

p. 6 of 197

1. INTRODUCTION

1.1. DOCUMENT PROFILE This document provides a description of the MVTS Pro software, a carrier-grade VoIP switch for efficient policy routing and management of VoIP traffic.

1.2. AUDIENCE This document is intended for system administrators responsible for deployment, configuration, operation and maintenance of MVTS Pro. Readers of this document are expected to have knowledge of UNIX-like operating systems and be familiar with regular expressions.

1.3. NOTATIONAL CONVENTIONS The conventions used in this document are described in Table 1: Conventions below.

Table 1: Conventions

Example Convention Note: text of the note Important information deserving special attention [N] Reference to another document void Examples of source code, program output, contents of log and

configuration files. Ulimit File and directory names Registration Configuration parameters in MVTS Pro GUI

1.4. DOCUMENT STRUCTURE This document comprises the following sections:

Section 1 Introduction contains general information about this document, its structure and the conventions used in explanation.

Section 2 System overview provides a description of the system functionality, specifications, architecture, hardware and software requirements

Section 3 System configuration is focused on the System configuration procedures.

Section 4 Traffic Switch administration provides reference about commands of the Traffic Switch administration console.

Section 5 MVTS Pro Web interface describes the web interface of the System.

Section 6 Operating TM leads you through the particulars of Traffic Manager administration.

Section 7 MVTS Pro Redundancy contains information about the ways to ensure failsafe operation of the System.

Introduction

MVTS Pro 1.5.0-40

p. 7 of 197

1.5. NAMES, PHONE NUMBERS AND NETWORK ADDRESSES All IP addresses, user logins and phone numbers used for the purposes of the present document are fictitious and any resemblance or similarity to real-life objects and/or individuals is purely accidental.

1.6. TERMS AND ACRONYMS

ACD Average Call Duration. ACD is one of the operational parameters registered in MVTS Pro. ACD allows the evaluation of dial peer performance.

ASR (standard) Standard or conventional ASR (answer seizure ratio), calculated as:

ASR = total number of non-zero duration calls/total calls

ASR Answer Seizurе Ratio. ASR is one of the operational parameters registered in MVTS Pro, allowing the evaluation of dial peer performance. In MVTS Pro ASR is calculated in two ways: using the common method (see ASR (standard) and using the intrinsic MVTS Pro method (see ASR (MVTS Pro).

ASR (MVTS Pro) ASR calculated by the MVTS Pro intrinsic method. MVTS Pro ASR (answer seizure ratio) is calculated as:

ASR = successful calls/total calls * 100where a successful call is either a non-zero duration call or a call with a successful disconnect reason code.

CDR Call detail record. Set of data fields (call ID, call start and termination time, disconnect reason, etc) used for accounting and billing.

CHAP Challenge Handshake Authentication Protocol.

CPC Calling Party Category

CPS Calls Per Second or Call arrival rate expressed in calls per second.

CSV Comma Separated Values – text format used to represent data in tabular form. Each string in the file is a row of the table. The values of each column is separated by a delimiter, for example, a comma (,), semicolon (;) or a tab symbol. Text values are embraced in double quotes ("); if the text value itself contains double quotes – they are represented by two double quotes following each other.

DB Database

DBMS DataBase Management System

DNS Domain Name System

DP Dial peer. In terms of MVTS Pro a dial peer is a potential destination for the MVTS Pro’s egress traffic characterized by the equipment (gateways) that receives traffic from MVTS Pro, number transformation rules and some other data important for call routing

DTMF Dual Tone Multi-Frequency

DST Destination EMA Exponential Moving Average

ENUM TElephone NUmber Mapping. Protocol stack to link E.164 telephone numbering standard to DNS addressing system, used in Internet.

Introduction

MVTS Pro 1.5.0-40

p. 8 of 197

GK A gatekeeper is a hardware used for IP-telephony management. Zone controller managing calls in a VoIP network, ensuring number translation and network access.

GUI Graphical User Interface

GW Gateway

HTTPS HyperText Transfer Protocol, Secure

ITSP Internet Telephony Service Provider

LAN Local Area Network

MVTS Mera VoIP Tandem Softswitch

NAT Network Address Translation

Network indicator This indicator associates SS7 signaling points with different types of SS7 networks: national or international.

NGN Next-Generation Networks

NIC Network-Interface Card

Payload type An integer, identifying a codec or codec group. There are static payload types (with numbers from 0 to 95 inclusive) and dynamic payload types (with numbers from 96 to 127 inclusive). A static payload type is a number, which is defined in the standard and which identifies a codec or codec group for all calls. A dynamic payload type is a number, which identifies a codec for one particular call.

PDD Post Dial Delay, interval between dialling the last digit of the called number and hearing the ringback tone.

MVTS Pro registers PDD as an interval between the receipt of the CONNECT packet from the call originator and the receipt of the ALERT, CONNECT or ProgressIndicator with value 8 (ProgressInbandInformationAvailable) packets from the terminator. The calculation of PDD is EMA-based, measured in milliseconds;

Point code A unique address of a signalling point in the SS7 network.

PSTN Public Switched Telephone Network. This abbreviation is used to designate traditional legacy telephony and contrast it with VoIP telephony.

QoS Quality of Service. MVTS Pro calculates QoS as a ratio of packets lost to total packets transferred, i.e. the smaller is the calculated QoS value, the better is QoS.

RADIUS Remote Authentication Dial-In User Server/Service. Protocol of user authentication, authorization and accounting according to RFC 2138.

RAS Registration, Admission, Status. Protocol for interoperation with remote devices.

RAS user Registering device.

RBT Ring-Back Tone

RTP/RTCP Real-Time Protocol / Real-Time Control Protocol.

SBC Session Border Controller. A device used in some VoIP networks to exert control over the signaling and usually also the media streams involved in setting up, conducting, and tearing down calls. The word Border in Session Border Controller refers to a point of demarcation between one part of a network and another. As a simple example, at the edge of a corporate network, a firewall demarks the local network (inside the corporation) from the rest of the Internet (outside the corporation). It is the job of a Session Border Controller to assist policy administrators in managing the flow of session data across these borders.

Introduction

MVTS Pro 1.5.0-40

p. 9 of 197

SCD SETUP-CONNECT Delay. The stretch of time between the SETUP and CONNECT message or call teardown in the absence of CONNECT.

SIP Session Initiation Protocol.

Service indicator Service indicator is used to associate signalling data, exchanged through the SS7 network, with a user subsystem. For example, the value 5 (0101 in binary notation) means that the signaling data is intended for the ISUP user part.

Signaling data link Physical layer for transferring data (bitstream) between two SS7 signaling points. A signaling data link is made up of two channels, transmitting signaling together in opposite directions with the same speed. The signaling data link is controlled by the MTP1 layer protocol.

Signaling link An SS7 signaling link is a signaling data link (as a transmission medium) plus a signaling endpoint (as a controlling device). The signaling link ensures reliable exchange of signaling messages between two directly interconnected signaling points. The signaling link is controlled by the MTP2 layer protocol.

TM Traffic Manager

TNS Target NameSpace

TS Traffic Switch

TTL Time-To-Live, limit on the period of time or number of iterations or transmissions in computer and computer network technology that a unit of data (e.g. a packet) can experience before it should be discarded.

VoIP Voice over Internet Protocol (IP)

WAN Wide Area Network

System configuration

MVTS Pro 1.5.0-40

p. 10 of 197

2. SYSTEM OVERVIEW MVTS Pro is a system for comprehensive management of IP telephony traffic flowing across the ITSP’s network. MVTS Pro is designed to efficiently handle big amounts of simultaneous call sessions through application of adaptive call authorization and routing policies.

MVTS Pro integrates the functionality of a class 4 switch with the capability of a session border controller. The main intent of the MVTS Pro system is concentration and switching of VoIP streams for increased assurance of connectivity even between networks with different signaling standards (SIP, H.323 and ISUP-R/SIGTRAN).

MVTS Pro is designed for establishment of a highly efficient switching center on the carrier’s packet switching networks. MVTS Pro can bring connectivity to a patchwork collection of equipment both on the operator’s network and in trans-network operation. MVTS Pro assures network security, QoS control and provides a single point of user authorization, statistics and billing.

MVTS Pro is a next-generation tandem switch application that takes over from the legacy MVTS softswitch. The major strengths of MVTS Pro include kernel support of SIP and ISUP-R/SIGTRAN/MGCP, high rates of traffic handling and a modular architecture that allows for boundless enhancement of performance. The MVTS Pro modular design and geographical distribution of the system components add a lot to the system operational flexibility and reliability.

The ease of deployment and operation are additional merits of MVTS Pro.

2.1. SYSTEM MAKE-UP AND NETWORKING ARRANGEMENTS The MVTS Pro system includes two functional layers: a switching layer and management layer (see Fig. 1)

The switching layer is a collection of modules that perform signaling- and media-related functions, registration and traffic balancing.

The management layer is an integration of routing modules, a database and web-GUI server that allow configuration and operation of the system.

In what follows the traffic management layer for simplicity is referred to as Traffic Manager (TM) and the switching layer as Traffic Switch (TS).


MVTS Pro 1.5.0-40

p. 11 of 197

Fig. 1 MVTS Pro architecture

The distribution of operational functions among the MVTS Pro key components is as follows:

2.1.1. TRAFFIC MANAGER (TM) Traffic Manager (TM) is the core element of MVTS Pro, and the System’s artificial intelligence.

TM carries out authentication and authorization of VoIP endpoints, performs call routing, call analysis, validation and transformation of call numbers, traffic load balancing. In addition, TM performs QoS control functions and generates information required for external billing systems.

TM comprises three constituent parts:

• Scripting node – controls the operation of scripts that enable the System’s routing mechanism.

• Database is a repository of data necessary for call routing and analysis of statistics.

• Web server (WS) provides a convenient graphical interface for administration tasks.


MVTS Pro 1.5.0-40

p. 12 of 197

2.1.2. TRAFFIC SWITCH (TS) Traffic Switch (TS) processes SIP, H.323 and ISUP-R/SIGTRAN calls and performs two-way conversion of signaling protocols and voice codecs when necessary. Each TS is a full-featured session border controller (SBC) that provides a secure connectivity interface with end customers and peering partners, enables interoperability of multi-vendor equipment, conceals the network topology and assures protection from DoS attacks. Additionally, the TS is the primary source of call statistics analyzed by means of the TM.

Generally speaking, TS is a full-featured session border controller (SBC) that consists of the following functional modules (nodes), each being a standalone software application:

• License Management node keeps all configuration data, provides centralized control over other functional modules and serves as a collection point for traffic statistics.

• SIP registrar/balancer and Н.323 gatekeeper/balancer. These nodes handle registration requests and provide for load balancing between the signaling nodes. When a user (calling device) tries to register to the System, the relevant data is forwarded to the TM. Depending on the response received from the TM the registration request is either accepted or rejected. Load balancing is based on the current traffic load of each signaling node.

• Signaling node performs two-way conversion of SIP and H.323 signaling protocols and ensures traffic distribution between media nodes (load balancing). A single signaling node can interoperate with any number of media nodes.

• Media node – the job of a media node is to handle media flows, function as an RTP media proxy and perform conversion of voice codecs. The number of media nodes needed in an MVTS Pro system 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.

• Syncro node ensures synchronization of the System processes and control over the used resources. The synchro node interoperates with the signaling nodes.

• SIGTRAN interoperation node (SS7 node) – interoperation with gateways under SIGTRAN/MGCP.

Depending on the System capacity requirements TS components 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.

2.1.3. MVTS PRO TECHNICAL DATA AND SPECIFICATION Supported protocols:

• H.323 v.2 and later (including H.245 v.7, H.225 v.4)

• SIP v.2.0 (3261)

• T.38

• ISUP-R/SIGTRAN/MGCP

• SNMP

• RADIUS AAA and routing

• ENUM


MVTS Pro 1.5.0-40

p. 13 of 197

Carrier-to-Carrier/Carrier-to-Enterprise Interoperability:

• SIP / H.323 / ISUP-R/SIGTRAN proxy

• SIP / H.323 / ISUP-R/SIGTRAN interworking

• Support for H.323 and SIP dialects

• Conversion of media codecs (G.729, G.729A, G.729B, G.723.1, G711A-Law, G.711mU-Law, GSM FR, Speex, iLBC)

• T.38 fax pass-through

• SIP and H.323 video pass-through using H.261, H.263 codecs

Network security

• Traversal of NAT routers and firewalls

• Concealment of the owner's network topology

• Caller authentication by IP address or login and password based on:

o data stored in the DB

o data received from RADIUS servers

Call routing

Native routing capabilities

• Number of the calling/called party

• Route ASR

• Caller group ID

• Day of week/time of day

• Priority/accessibility of the destination GW

• Routing policies

• Gateway/route traffic load

External routing

• RADIUS -aided routing

• ENUM-aided routing

Statistics and network analysis

• Real-time monitoring of ASR, QoS, ACD, etc.

• Statistics monitoring of selected gateways/routes

• CDR-based report generation

• Handy CDR search and display capabilities

• Automated log file management: (archiving, file size and file rotation control)

• Automatic or manual export of CDRs into a text file


MVTS Pro 1.5.0-40

p. 14 of 197

Billing

• Single CDR collection point

• Exhaustive number of fields in CDRs for detailed analysis and debugging.

• Integration with external billing systems using RADIUS protocol

• Cisco VSA

• Subscriber authorization in billing systems based on data provided by MVTS Pro

Number translation

• Flexible number translation options based on regular expressions

• Concealment of the caller number

Operating systems

• Debian GNU/Linux Lenny

Capacity

• Up to 2 520 000 BHCA for one entry point

Minimal configuration capacity (2 eight-core servers):

• Up to 2,000 concurrent calls (with proxying, but without codec conversion)

• Up to 24,000 concurrent calls (without proxying)

Signaling node capacity:

• Up to 150 CPS

Media node capacity without codec conversion

• Up to 1000 concurrent calls.

Media node codec conversion capability

“Light” codec conversion (G.711<->ANY):

• Up to 200 concurrent calls per processor core

“Heavy” codec conversion (G.723<->G.729):

• Up to 100 concurrent calls per processor core

Logging and debugging

• Billing and debug logs

• System trace logs with selectable information detail level


MVTS Pro 1.5.0-40

p. 15 of 197

• Call log viewing through the web-interface

• Call simulation

Redundancy

• Redundancy of all key modules

• Various redundancy schemes in compliance with the network architecture and carrier’s needs

• Individual, comprehensive, multiple redundancy of business-critical modules

• Software updates and capacity increase without interruption of service


MVTS Pro 1.5.0-40

p. 16 of 197

3. SYSTEM CONFIGURATION

3.1. TS CONFIGURATION TS is configured by editing two plain text files: phoenix.conf and system.conf.

The configuration file phoenix.conf exists on every server with the TS software deployed. It describes what TS nodes run on this server.

The configuration file system.conf is located on the primary server with the license management node (LMN) and configures the connectivity parameters of the TS nodes.

Note: Prior to configuring the system insert the USB license dongle supplied with the installation package into the USB port of the license management node machine.

When all the TS functional nodes are installed on a single hardware platform, to configure the TS proceed as follows:

Edit the configuration file phoenix.conf and start the system.

Edit the configuration file system.conf and apply the settings with the help of the command line interface (CLI).

When TS nodes are installed on several individual servers, to configure the TS proceed as follows:

Edit the configuration file phoenix.conf and start the license management node and the command-line node on one of the servers.

Edit the configuration file system.conf and apply the settings using the CLI.

Edit the configuration file phoenix.conf on the rest of the system servers and start the system nodes installed on these servers.

Apply global configuration settings with the help of the CLI once again.

3.2. PHOENIX.CONF AND SYSTEM.CONF SYNTAX The configuration files phoenix.conf and system.conf are plain text files with configuration data arranged in the C-style layout.

The C-style layout of configuration data effectively means the following:

• Configuration parameters should be written as sections and subsections enclosed in opening and closing braces. The closing brace of a section and sub-section must be followed by a semicolon.

• Like in the C and C++ programming languages two types of comments are allowed: 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.

Table 1 describes the syntax of the configuration files system.conf and phoenix.conf.

Table 1 Syntax of the configuration file system.conf

Element Format Example


MVTS Pro 1.5.0-40

p. 17 of 197

Section/sub-section

name

{….

};

zone { zone "local" { "127.0.0.0/8"; "::1/128"; }; zone "intranet" { "194.112.160.0/24"; }; };

Parameter name “value” allow_chap "yes"

Value “char string” "127.0.0.0/8"; "::1/128";

Comment /*…

*/

/* Use this section to configure signaling nodes */

Include an external file

include “full filename”

include “/etc/mvts3g/system-1.zone.conf”

3.3. DAEMON PROCESS ‘PHOENIX’ AND CONFIGURATION FILE PHOENIX.CONF “phoenix” is a daemon that starts up the TS nodes installed on the server and lets them know the IP-address and port of the LMN. Another job of the “phoenix” daemon is to restart crashed nodes.

In multi-server layouts each server runs its own “phoenix” daemon the configuration parameters of which are stored in the file phoenix.conf located in the directory /etc/mvts3g.

The C-like syntax of the phoenix.conf file is identical to that of the configuration file system.conf (see Section 3.4). There are two more files in the directory /etc/mvts3g:

phoenix.conf.sample.local – a template for the phoenix.conf configuration file for servers on which the license management node is installed.

phoenix.conf.sample.remote – a template for the phoenix.conf configuration file used on servers that do not host the license management node.

The figure below shows an excerpt from the file phoenix.conf.sample.local.


MVTS Pro 1.5.0-40

p. 18 of 197

Fig. 2 Excerpt from the file phoenix.conf.sample.local.

For convenience the template files are explicitly commented.

The file phoenix.conf allows the following TS settings:

• name of the main license management node (first line in file):

management "[name_of_primary_Management_Node]"

• IP address and port of the primary LMN:

[listen|address] "[address:port]";

if the parameter is listen, it means that the primary LMN runs locally, i.e. on this server and has the specified address and port. The parameter option address means, that the primary LMN (as distinct from the failover LMN) runs on a remote server having the specified address and port.

• IP address and port of the failover LMN:

if the parameter is listen, it means that the failover LMN runs locally, i.e. on this server and has the specified address and port. The option address means, that the failover LMN runs on a remote server having the specified address and port

Note: The primary and failover LMNs cannot run on the same server, that is the configuration parameter cannot be set to the local location for both the primary and failover LMN.

For further information on LMN redundancy, see Section 7.5.

• commandline specifies the listening address and port combination for the CLI node:

• list of nodes that run on this server. The structure of the list is as follows:

management { [address|listen] "[address:port]"; };

commandline { listen "[address:port]"; };


MVTS Pro 1.5.0-40

p. 19 of 197

Use the appropriate template file (phoenix.conf.sample.local or phoenix.conf.sample.remote). Edit the template in any plain-text editor and copy the edited file to the file phoenix.conf. For the made changes to take effect, run the script /etc/init.d/mvts3g-server with the argument start:

#> /etc/init.d/mvts3g-server start

To re-read the configuration with the server currently running, use the argument restart.

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

Use the argument stop to stop the server.

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

3.4. CONFIGURATION FILE SYSTEM.CONF The configuration file /etc/mvts3g/system.conf is what you use to configure a variety of TS networking settings.

Fig. 3 presents an excerpt from the configuration file system.conf.

Fig. 3 Configuration file system.conf

media { rbtfilesdir "/etc/mvts3g"; media "media-1-1" { portrange "10000-14999"; signaling "signaling-1"; }; media "media-1-2" { portrange "15000-29999"; signaling "signaling-1"; }; media "media-2-1" { portrange "10000-14999"; signaling "signaling-2"; }; media "media-2-2" { portrange "15000-29999"; signaling "signaling-2"; }; };

[node type] { "name of the first node"; "name of the second node"; };


MVTS Pro 1.5.0-40

p. 20 of 197

The file system.conf is comprised of several sections, each one setting the parameters of some TS node.

Fig. 3 shows the section media that contains configuration data for four media nodes named “media-1-1”, “media-1-2”, “media-2-1” and “media-2-2”

The nodes “media-1-1” and “media-1-2” are configured to use ports in the range 10000 through 14999 and 15000 through 29999 respectively, and interoperate with the signaling node “signaling-1”. The nodes “media-2-1” and “media-2-2” are configured to use ports in the range 10000 through 14999 and 15000 through 29999 respectively, and interact with the signaling node “signaling-2”.

A parameter value defined within a section becomes the default setting for all subsections nested within the section. For example, see the parameter rbtfilesdir (the directory of the sound files used for ring back tone emulation) in Fig. 2 that sets the values for all the four media nodes.

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.

It is good practice to place configuration data for all nodes of the same type (signaling/scripting/media etc.) in a separate file (see Section 3.5). You can then use the keyword include to incorporate the contents of individual files into system.conf :

To apply the changes done in system.conf, connect to the command-line node (telnet [address] [port], specified in the section commandline of phoenix.conf) and carry out the config command supplying the full path to system.conf as the command argument:

This will make the CLI node write the configuration to the hard disk.

3.5. INDIVIDUAL NODE CONFIGURATION Configuration of nodes of the same type can be done in a common file. The general configuration file format is shown in the figure below:

where “node name” is the name of a node as specified in phoenix.conf.

include "/etc/mvts3g/system-1.zone.conf"; include "/etc/mvts3g/system-1.scripting.conf"; include "/etc/mvts3g/system-1.registrar.conf"; include "/etc/mvts3g/system-1.signaling.conf"; include "/etc/mvts3g/system-1.synchro.conf"; include "/etc/mvts3g/system-1.media.conf";

mvts3g|> config /etc/mvts3g/system.conf Step 1: Parsing a configuration file... Step 2: Configuring the system... Step 3: Done.

[node type] { [common parameters for this node or section] [node type] "[node name]" { [parameters and sections specific for this node] }; };

https://wiki.meranetworks.ru/wiki/Traffic_Switch:%D0%9A%D0%BE%D0%BD%D1%84%D0%B8%D0%B3%D1%83%D1%80%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5#.D0.A4.D0.B0.D0.B9.D0.BB_.D0.BA.D0.BE.D0.BD.D1.84.D0.B8.D0.B3.D1.83.D1.80.D0.B0.D1.86.D0.B8.D0.B8_phoenix.conf


MVTS Pro 1.5.0-40

p. 21 of 197

3.5.1. COMMON SECTIONS The configuration of any node, except the media node, includes at least two sections:

• an optional section ‘common’ and

• the required section ‘controllink’.

• the section ‘common’ is for settings that are common for all nodes of the type.

Presently the section includes only one variable – loglevel, with two possible values 0 (logging is off) and any non-zero integer (logging enabled which involves entering all SIP/H/323 signaling packets and message packets exchanged by nodes in the log).

Signaling and registration-balancer nodes can be additionally configured to disable logging after some time to prevent disk overflow situations owing to large volumes of log files. Add the following command to the section ‘common’ of the signaling or registration-balancer node configuration file:

loglevel_timeout “x”

where x is the logging period in minutes. By default, logging is disabled after 24 hours.

• the controllink section specifies the IP address and port combination for the node to open a socket for incoming connections from other nodes.

Note: You cannot use address “0.0.0.0” in the section ‘controllink’. You are also strongly advised against the use of address “127.0.0.1” in the controllink section to avoid troubles when configuring a multi-server TS. You should specify one real address.

3.5.2. REGISTRATION-BALANCER CONFIGURATION A configuration example of an arbitrary registration-balancer node:

common { loglevel "0"; }; controllink { address { "192.168.132.195"; }; port "7050"; };


MVTS Pro 1.5.0-40

p. 22 of 197

• Section ras governs the parameters, pertaining to the H.323 gatekeeper:

o address — address or addresses, used by the node to listen for incoming requests to the H.323 gatekeeper.

o port — port, used by the node to listen for incoming requests to the H.323 gatekeeper.

o gkname — gatekeeper name used to process LRQ/ARQ messages;

o allow_md5, allow_chap, allow_plain — allowed password encryption algorithms;

balancer { balancer "[node name]" { common ... controllink ... ras { address { "0.0.0.0"; }; port "1719"; gkname "MVTS3G"; allow_md5 "yes"; allow_chap "yes"; allow_plain "yes"; }; sip { address { "0.0.0.0"; }; port "5060"; max_invite_packets_rate "100"; proxying_balancing "yes"; }; h323 { address { "0.0.0.0"; }; port "1720"; max_h323_connection_rate "100"; }; call_rate_alarm_lifetime "60"; }; };


MVTS Pro 1.5.0-40

p. 23 of 197

• Section sip governs the parameters, pertaining to SIP calls:

o address/port — the IP address and port for the incoming SIP calls.

o proxying_balancing — parameter governing balancing of SIP calls, with (“no”) or without redirection (302 message) (“yes”).

o max_invite_packets_rate – the maximum allowed number of incoming INVITE messages for this node. Once the defined number is exceeded the System starts writing alarm messages to the file phoenix.log. Default value - 0 (disable monitoring).

• Section h323 governs the parameters, pertaining to H.323 calls:

o address/port — the IP address and port for the incoming H.323 calls.

o max_h323_connections_rate – the maximum allowed number of incoming H.323 connections for this node. Once the defined number is exceeded the System starts writing alarm messages to the file phoenix.log. Default value - 0 (disable monitoring).

• call_rate_alarm_lifetime – defines the life time of an alarm in seconds and 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).

3.5.3. SIGTRAN INTEROPERATION NODE CONFIGURATION A configuration example of an arbitrary SIGTRAN interoperation node:

The parameters of the callctr section:

ss7 { ss7 "[node name]" { common ... controllink ... callctr { ss7zone "[SS7 zone name]" { cid "0" }; }; isup { ... }; m3ua { ... }; mgcp { ... }; }; };


MVTS Pro 1.5.0-40

p. 24 of 197

• ss7sone – name of the SIGTRAN zone. In the callctr section define the number of ss7zone sections, equal to the number SIGTRAN zones, with which the System interoperates. See also 3.6.1.

• tmr – the value of the ‘Transmission medium requirement’ field sent in the IAM message. Valid values – 0-3.

Parameters of the ss7zone section:

• cid – the identifier of the media circuit group (defined in the circuit_group section) in one or several E1 trunks, belonging to this SIGTRAN zone. Only one media circuit group may belong to a single SIGTRAN zone.

To configure the parameters of the ISUP protocol, the isup section is used:

General parameters:

• tStopBlock – timeout after which the System stops retransmitting the BLO/CGB message in case a remote SS7 switch sends no answer. The default value – 3600000. The valid value range – 300000 – 60000000. The parameter value should be greater or equal the T19 timer value.

• tStopUnblock – timeout after which the System stops retransmitting the UBL/CGU message in case a remote SS7 switch sends no answer. The default value – 3600000. The valid value range – 300000 – 60000000. The parameter value should be greater or equal the T21 timer value.

• tStopRSC – timeout after which the System stops retransmitting the RSC message in case a remote SS7 switch sends no answer. The default value – 3600000. The valid value range – 300000 – 60000000. The parameter value should be greater or equal the T17 timer value.

isup { snode "[snode id]" { ... connection "[connection id]" { ... timers { ... }; span "[span id]" { ... ts_cic_mapping { ... }; }; }; }; circuit_group { ... circuit_group_elem { ... }; }; };


MVTS Pro 1.5.0-40

p. 25 of 197

• tStopGRS – timeout after which the System stops retransmitting the GRS message in case a remote SS7 switch sends no answer. The default value – 3600000. The valid value range – 300000 – 60000000. The parameter value should be greater or equal the T23 timer value;

The parameters of the snode section describe a SS7 signaling point with ISUP support:

• The SS7 signaling point identifier is specified in the section header. The valid value range – 0 through 100 incl.

• opc – signaling point code. Defined by a decimal number from 0 through 16383 incl.

• ni – network indicator code. Defined by a decimal number from 0 through 3 incl.

The parameters of the connection section describe a multitrunk connection to a remote SS7 switch:

• Identifier of the connection to the SS7 switch is specified in the section header. The valid value range – 0 through 100 incl.

• dpc – destination point code, i.e. point code of the switch. Defined by a decimal number from 0 through 16383 incl.

The parameters of the timers section describe the set of timers, used to connect to a SS7 network. For more information about the timers see Q.764. The valid timers are:

• T1 – timer for the RLC answer after emitting the REL message.

• T5 - timer for the RLC answer after emitting the first REL message.

• T6 – timer for the RES message (originated by the network) after the receipt of the SUS message (originated by the network).

• T7 – timer for the reply on the last emitted SAM message.

• T9 – timer for the CON or ANM message after the receipt of the ACM message.

• T16 – timer for acknowledgement of the emitted RSC message.

• T17- timer for acknowledgement of the first emitted RSC message.

• T18 - timer for acknowledgement of the emitted CGB message.

• T19 - timer for acknowledgement of the first emitted CGB message.

• T20 - timer for acknowledgement of the emitted CGU message.

• T21 - timer for acknowledgement of the first emitted CGU message.

• T22 - timer for acknowledgement of the emitted GRS message.

• T23 - timer for acknowledgement of the first emitted GRS message.

The parameters of the rtu_span section describe a single E1 trunk to a SS7 switch as part of the ISUP connection:

• Unique identifier of the E1 trunk to the SS7 switch is specified in the section header. The identifier uniqueness should be preserved even across different E1 trunks in different ISUP connections;

• hw_id – identifier of the media gateway (described in the respective mgcp_conf_mgw section), to which the media circuits of the E1 trunk are connected.

• out_mask – optional bitmask, defining the media circuits in the E1 trunk, which are used for outgoing calls from the System. Defined by a decimal or hexadecimal number.

http://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-Q.764-199912-I!!PDF-E&type=items


MVTS Pro 1.5.0-40

p. 26 of 197

• in_mask – optional bitmask, defining the media circuits in the E1 trunk, which are used for incoming calls to the System from the SS7 switch. Defined by a decimal or hexadecimal number.

• doInitReset – optional parameter. The “true” value means that media circuit state will be reset when a remote SS7 switch becomes available for the first time.

• isConsecutiveCicAlloc – the “true” value means that continuous numeration of media circuits is used. The “false” value means that arbitrary numeration is used. In any case the media circuit numbers should be unique within the ISUP connection and identical on the local and remote SS7 switch.

• cicBase – defines the number of the first media circuit, from which the number of media circuits starts, in case of consecutive numbering. If several E1 trunks are defined in the System, specify the cicBase parameter so that media circuit number ranges on each trunk do not overlap (e.g., for trunk 0 – cicBase = 0, for trunk 1 – cicBase = 32, etc).

• The ts_cic_mapping subsection is valid only if the isConsecutiveCicAlloc parameter is false. In this subsection the parameters ts0…ts31 define the numbers of media-circuits, specified in the out_mask и in_mask parameters. The valid value range for each parameter – from 0 to 4095 incl.

The parameters of the circuit_group section describe a group of media circuits in one or several E1 trunks. The number of circuit_group sections must be equal to the number of cid identifiers in the section/sections ss7zone:

• Identifier of the media circuit group is specified in the section header. Corresponds to the cid in the section ss7zone;

The parameters of the circuit_group_elem describe a set of media circuits in one E1 trunk. The maximum number of the circuit_group_elem sections in one circuit_group section can not exceed 50:

• span_idx – identifier of the E1 trunk (defined in the respective span section) to which this media circuit group belongs.

• out_mask – optional bitmask, defining the media circuits in the E1 trunk, which belong to this media circuit group. Defined by a decimal or hexadecimal value.

To configure the M3UA protocol the m3ua section is used:


MVTS Pro 1.5.0-40

p. 27 of 197

General parameters:

• assocEstablishInterval – the frequency of attempts to restore the SCTP association in case it is severed, in milliseconds. The default value – 1000. The valid value range – 1000 to 10000 incl;

• assocMaxInitAttempts – the maximum number of attempts to initially establish the SCTP association. The default value – 3. The valid value range – 1 to 10 incl;

• assocMaxInitTimeout – the maximum period for attempts to establish the SCTP association, in milliseconds. The default value – 300. The valid value range – 1000 to 10000 incl;

• assocGracefulClose – the “true” value means that to close the SCTP association the Shutdown Chuck is sent to the SIGTRAN gateway, the “false” value means sending the Abort Chunk. The default value – «false».

• daudPeriod – the frequency for checking availability of remote signaling points, in milliseconds. The default value – 6000. The valid value range – 1000 to 600000 incl;

Parameters of the AS section describe an Application Server, a logical entity which maps to

m3ua { ... AS "[AS identifier]" { ... }; ASP "[ASP identifier]" { ... }; SG "[SG identifier]" SGP "[SGP identifier]" { ... }; Association "[Association identifier]" { ... }; Endpoint "[Endpoint identifier]" { ... }; NetworkAppearance "[NetworkAppearence identifier]" { ... }; RoutingContext "[RoutingContext identifier]" { ... }; RoutingKey "[identifier RoutingKey]" { ... }; };


MVTS Pro 1.5.0-40

p. 28 of 197

one Routing Key. A Routing Key is a filter, made up of SS7 parameters, which determine the belonging of the signaling traffic to a certain AS. The Application Server hosts one or several Application Server Processes (ASP), which dispatch signaling traffic from one network into the other. One AS may correspond to several ASPs and vice versa.

• AS identifier is specified in the section header. The range of valid values - from 1 to 65535;

• rk – identifier of the Routing Key (RK) (described in the RoutingKey section), i.e. a filter which defines the appurtenance of traffic to this AS.

The parameters of the ASP section describe an Application Server Process (ASP), which handles traffic on the client (System) side:

• ASP identifier is specified in the section header. The range of valid values – from 1 to 65536;

• m3asp_id – the value of the “ASP Identifier” parameter.

The SG parameter describes the Signaling Gateway (SG), which resides on the border of IP and SS7 networks and performs signaling traffic transfer from one network into the other:

• SG identifier is specified in the section header. The range of valid values – from 65537 to 131070.

The parameters of the SGP section describe a Signaling Gateway Process (SGP), which handle traffic transfer on the Signaling Gateway:

• SGP identifier is specified in the section header. The range of valid values – from 65537 to 131070.

• sg – Signaling Gateway identifier (defined in the SG section), which hosts this SGP.

The parameters of the Association section describe a SCTP association between the ASP and the SGP:

• Identifier of the SCTP association is specified in the section header.

• lsp – identifier of the ASP (defined in the ASP section), with which the association was established.

• rsp – identifier of the SGP (defined in the SGP section), with which the connection was established.

• lep – the local SCTP endpoint identifier (defined in the Endpoint section) of the ASP. Valid values – 0 - 200.

• rep – the local SCTP endpoint identifier (defined in the Endpoint section) of the SGP. Valid values – 0 – 200.

• hbInterval – interval between sending heartbeat packets to check the connection validity. By default – 30 sec.

The parameters of the Endpoint section describe the SCTP endpoint:

• Identifier of SCTP endpoint is specified in the section header.

Endpoint "[Endpoint indentifier]" { ... Addresses { "192.168.131.100"; }; };


MVTS Pro 1.5.0-40

p. 29 of 197

• port – SCTP port of the endpoint. By default – 2905.

• The section Addresses contains a list of IP addresses, which correspond to the SCTP endpoint. Each address must be placed on a separate line.

The parameters of the NetworkAppearance section describe an SS7 network identifier, which, together with the origination point code, uniquely identifies the belonging of the signaling point to a certain SS7 node. This identifier is used, when the traffic belonging to different SS7 networks, are sent over one SCTP association between the AS and the SG:

• Internal identifier of this section is specified in the section header.

• value – the value of the SS7 Network Appearance identifier. Valid values – 0 to 4294967295.

• In the section SG_Ids the SG identifier (defined in the SG section) is specified.

• In the section AS_Ids the AS identifier (defined in the AS section) is specified.

The parameters the RoutingContext section describe a unique identifier of the Routing Key. This identifier is used when the traffic from one Signaling Gateway is transferred to several Application Servers:

• Internal identifier of this section is specified in the section header.

• value – the value of the SS7 Routing Context identifier. Valid values – 0 to 4294967295.

• In the section AS_Ids the AS (defined in the AS section) identifier specified.

• In the section Assoc_Ids the SCTP association identifier (defined by the Association section) is specified.

RoutingContext "[RoutingContext identifier]" { ... AS_Ids { "1"; }; Assoc_Ids { "1"; }; };

NetworkAppearance "[NetworkAppearence identifier]" { ... SG_Ids { "65537"; }; AS_Ids { "1"; }; };


MVTS Pro 1.5.0-40

p. 30 of 197

The parameters of the section RoutingKey describe the filter, which is used to refer traffic to one or another AS. The parameters of different should not overlap, that means that you should define filters so, that traffic may be unambiguously referred to one AS:

• Identifier of the filter is specified in the section header;

• In the section RoutingKeyEntry define the filter parameters;

o DPC – destination pint code (as regards to the SG);

o In the section OPCs define the origination point codes (as regards to the SG). Each point code should be placed on a new line.

o si – service indicator, defined by 16-bit bitmask. Setting the bit 5 to 1, means that ISUP service identifier.

o ni – network indicator. Defined by a decimal number from 0 through 3 incl.

To configure the MGCP protocol the mgcp section is used:

The section mgcp_conf_inst describes parameters of the media gateways, which this SIGTRAN interoperation node controls through MGCP messages:

• Section identifier is specified in the section header;

RoutingKey "[RoutingKey identifier]" { ... RoutingKeyEntry { ... OPCs { "300"; }; ... }; };

mgcp { mgcp_conf_inst "[section id]" { localAddr "192.168.129.127"; localPort "2727"; tHist "20000"; tRetransInit "200"; tRetransLong "400"; tRetransMax "4000"; maxRtxNum "200"; mgcp_conf_mgw "[section id]" { address "192.168.131.100"; port "2427"; outTidMin "2000"; outTidMax "99999999"; pattern "S0/DS1-${trunk}/${timeslot}@mediant3.meranetworks.ru"; mgcp_conf_trunk "0" }; };


MVTS Pro 1.5.0-40

p. 31 of 197

• localAddr – IP address of the SIGTRAN interoperation node, which will be used to receive and send MGCP messages in the IP network.

• localPort – IP port of the SIGTRAN interoperation node, which will be used to receive and send MGCP messages in the IP network. By default – 2727.

• tHist – the time-to-live of the transaction in milliseconds. When this time expires, the transaction is considered failed and is terminated. By default – 20000. Valid values – 1000 – 60000.

• tRetransInit – the starting period of MGCP message retransmission, in milliseconds. By default – 200. Valid values – 100 – 500.

• tRetransLong – the period of MGCP message retransmission in milliseconds, used when the media gateway receive a message from the TS but has not completed its processing. By default – 400. Valid values – 100 – 10000.

• tRetransMax – the maximum period of retransmission in seconds. By default – 4000. Valid values – 1000 – 10000.

• maxRtxNum – the maximum number of retransmissions, after which the transaction is considered to be failed and retransmission of this messages is aborted. By default – 200. Valid values – 5 – 1000.

The mgcp_conf_mgw section described the parameters of the media gateway, which transfers media traffic from the SS7 to the IP network and vice versa:

• Media gateway identifier is specified in the section header.

• address – IP address of the media gateway.

• port – IP port of the gateway.

• outTidMin – the lower border of the identifier value range that can be assigned to MGCP transactions, sent by the SIGTRAN interoperation node to the media gateway. By default – 2000. Valid values – 1 – 999999999.

• outTidMax – the upper border of the identifier value range that can be assigned to MGCP transactions, sent by the SIGTRAN interoperation node to the media gateway. By default – 999999999. Valid values – 1 – 999999999.

Note: Identifier ranges for incoming and outgoing MGCP transactions (as regards to the System) should not overlap.

• pattern – the template name of the MGCP endpoint, which is defined on the media gateway. The ${trunk} substring is substituted with the E1 trunk identifier (mgcp_conf_trunk parameter), the ${timeslot} substring is substituted with the timeslot number.

• mgcp_conf_trunk – identifier of the E1 trunk, connected to the media gateway. It is possible to list several E1 trunks, connected to this media gateway. Same ids for different E1 trunks even when connected to different media gateways are not valid. The id corresponds to the id of the respective span section.

• auditPeriod – the period of polling MGCP endpoint status. By default – 5000 milliseconds.

Note: Presently the functionality of the SIGTRAN interoperation node is limited. For further information see Appendix D. SIGTRAN node limitations.

3.5.4. SCRIPTING NODE CONFIGURATION Scripting node is configured in the same way as other functional nodes of the System. An example of a scripting node configuration is given below:


MVTS Pro 1.5.0-40

p. 32 of 197

Parameters of the scripting section:

• loader_path – path to the starting script of the scripting node;

Parameters of the environment subsection:

• cdr_data_expiration_timeout – the period of storing CDRs in the memory (CDRs are saved to the DB after the keeping time expires).

• cdr_count_in_transaction – per INSERT transaction number of CDRs during saving CDRs to the DB.

• cdr_backup_max_requests_in_file — maximum number of CDRs, stored in a temporary file when the System loses connection to the DB.

• cdr_backup_timeout - the time of keeping CDRs in the buffer (CDRs are saved to a temporary files afterwards).

• cdr_backup_path – path to the directory for keeping temporary files with CDRs.

• cdr_backup_restore_1 – interval between checking the directory used for temporary CDR files, if such files were found during previous checks. By default – 2 min.

• cdr_backup_restore_N – interval between checking the directory for temporary CDR files, if such files were not found during previous checks. By default – 1 hour..

By this means, by default on start up, the System checks the directory specified in cdr_backup_path for temporary CDR files. If no temporary CDR files are found in the directory, the frequency of checks changes to the 1-hour interval set in the parameter cdr_backup_restore_N. If temporary CDR files are found in the directory during the check, the System inserts CDRs from one file in the DB and again checks the directory now after the short time specified by the parameter cdr_backup_restore_1. The System repeats short-timed checks until no more CDR files are found in the directory during the next check (until all CDRs have been inserted in the DB). The System then switches to less frequent checks with the between-checks interval set by the parameter cdr_backup_restore_N.

scripting { scripting "scripting-1" { controllink { address { "0.0.0.0"; }; port "7710"; }; loader_path "voip2.loader"; environment { dbms_type_master "MySQL"; dbms_name_master "localhost@rtu"; dbms_user_master "rtu"; dbms_pswd_master "rtu"; dbms_type_slave "MySQL"; dbms_name_slave "localhost@rtu"; dbms_user_slave "rtu"; dbms_pswd_slave "rtu"; }; }; };


MVTS Pro 1.5.0-40

p. 33 of 197

• cdr_backup_template – name template for temporary CDR files.

• reg_backup_template – name template for temporary registration files.

• reg_backup_path – path to the directory for temporary registration files.

• radius_nas_ip_addr – value of NAS-IP-Address field in Accounting packets, sent to RADIUS server.

• dbms_type_master — type of the main database. Valid values are “MySQL” and “Oracle”.

dbms_type_master "MySQL";

• dbms_name_master — path to the main database in the host@database format.

dbms_name_master "rtu2@rtu";

• dbms_user_master — name of main database user account.

dbms_user_master "rtu";

• dbms_pswd_master — main database user password.

dbms_pswd_master "rtu";

• dbms_type_slave — type of the failover database. Valid values are “MySQL” and “Oracle”.

dbms_type_slave "MySQL";

• dbms_name_slave — path to the failover database in the host@database format.

dbms_name_slave "rtu2@rtu";

• dbms_user_slave — name of failover database user account.

dbms_user_slave "rtu";

• dbms_pswd_slave — failover database user password.

dbms_pswd_slave "rtu";

• dbms_reconnect_timeout — interval between attempts to reconnect to the DB, by default – 1 sec.

dbms_reconnect_timeout "1";

• dbms_reconnect_tries — number of repeated attempts to restore connection to the DB, by default – 3.

dbms_reconnect_tries "3";

• dbms_scan_period — period between updating TS data from the DB, in seconds.

dbms_scan_period "10";

• dbms_time_wait_for_connect — delay in seconds between attempts to reconnect to the DB, if the previous DB operation resulted in an error and the TS was unable to restore connection to the DB for specified number of attempts.

dbms_time_wait_for_connect "20";

• trace_file — the prefix for the log file of the scripting node. By default, the value is «mvtsprologic». For further information on logging refer to the sections 3.10 and 4.2.3.


MVTS Pro 1.5.0-40

p. 34 of 197

trace_file "logic";

3.5.5. SIGNALING NODE CONFIGURATION An example of an arbitrary signaling node configuration:

• Section h323 comprises address and port, used by this signaling node to receive H.323 calls.

• Section sip comprises address and port, used by this signaling node to receive SIP calls.

Note: When the no-message-302 call balancing method is selected for SIP traffic (proxy_balancing “yes” in the section sipregistrar), to ensure proper operation of the balancer - add an address, pertaining to the same IP zone as the server socket of the SIP balancer (sub-section controllink). Another way of configuring the no-message-302 balancing for SIP calls is entering address 0.0.0.0 in the same section. Entering other addresses is unnecessary in this case, as when address 0.0.0.0 is specified, the System opens sockets on all available network interfaces.

• Section synchro defines the address and port of the synchronization node, associated with this signaling node.

signaling "signaling-1" { common ... controllink ... h323 { address { "0.0.0.0"; }; port "1721"; }; sip { address { "0.0.0.0"; }; port "5060"; }; synchro { address { "192.168.131.13"; }; port "7711"; }; max_h323_connections_rate "100"; max_invite_packets_rate "100"; call_rate_alarm_lifetime "60"; };


MVTS Pro 1.5.0-40

p. 35 of 197

• max_h323_connections_rate – the maximum allowed number of incoming H.323 connections for this node. Once the defined number is exceeded the System starts writing alarm messages to the file phoenix.log. Default value - 0 (disable monitoring).

• max_invite_packets_rate – the maximum allowed number of incoming INVITE messages for this node. Once the defined number is exceeded the System starts writing alarm messages to the file phoenix.log. Default value - 0 (disable monitoring).

• call_rate_alarm_lifetime – defines the life time of an alarm in seconds and 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).

3.5.6. MEDIA NODE CONFIGURATION An example of an arbitrary media node configuration:

• portrange — the range of UDP ports, used by this media node.

• rbtfilesdir — the path to the directory with RBT emulation files and messages played after call clearing.

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

3.5.7. SYNCHRONIZATION NODE CONFIGURATION Presently the configuration of a synchronization node does not have any specific parameters and includes common sections only.

An example of an arbitrary synchronization node configuration follows:

3.6. IP ZONES One of the essential tasks when configuring the TS is defining IP zones. An IP zone is a collection of connected networks characterized by 1) configured routing between the IP

media { media "media-1" { portrange "15001-20000"; rbtfilesdir "[full path]"; }; };

synchro { controllink { address { "192.168.132.195"; }; port "7711"; }; synchro "synchro-1" { }; };


MVTS Pro 1.5.0-40

p. 36 of 197

addresses of member networks that comprise the zone and 2) the absence of traffic limiting devices (firewalls, NAT routers etc.) within the zone.

The figure below illustrates the concept of IP zoning. Let us assume there are three networking entities – an intranet, a border gateway with a firewall and the Internet. In view of the above mentioned second zone characteristic, i.e. the absence of traffic limiting devices within the zone it would be reasonable to state that we have two zones here (ZONE 1 and ZONE 2), with the boundary delimiting them running through the firewall gateway.

Fig. 4 Example of IP zoning

To configure IP zones means to make a list of member networks to which the IPs of TS nodes belong.

Suppose, IP addresses belonging to networks 212.92.148.0/24 and 195.98.135.0/24 are used to access the Internet. In this case you may wish to configure a networking zone named “internet” by mentioning the networks that make up the zone (see Fig. 5) Networking zones are defined both in configuration of the TM and TS. It is important that both the TM and TS zone definitions are identical.

Note: The configuration of any TS includes a preconfigured zone ‘Local’ that comprises addresses 127.0.0.1 and [::1]. 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.

Networking zones are defined in the section “zone” of the configuration file system.conf. Actually this section is a list of zones and networks that comprise them.

While configuring zones you can use the following notations to describe IPv4 networks:

1. 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.

2. 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.

Here is an example of correctly configured IP zones:


MVTS Pro 1.5.0-40

p. 37 of 197

Fig. 5 Configuring zones in the file system.conf

TS uses IP zones to determine the local IP address featuring as the source IP in communication with a remote address.

By way of example, suppose the signaling node is installed on a host operating the IPs 192.168.18.12 and 212.92.148.70 (it is assumed that IP zones are configured as shown in Fig. 5) and the node needs to send a call to the address 81.10.1.1 using the IP zone "internet". In this case the IP 212.92.148.70 will be selected as the call source address as an IP belonging to the zone “internet”.

IP zones can also be used for selection of uplink provider. In such a case each element of the cluster is assigned N amount of IPs (where N equals or exceeds the number of uplink providers) and IP zones are configured in such a way that these IPs belong to different IP zones. The border IP routers of the network are configured for source routing. Then by selecting an IP zone you select an uplink provider that will tend to traffic.

3.6.1. SIGTRAN ZONES To identify a remote SS7 switch a SIGTRAN zone is used. The SIGTRAN zone is a set of links, connected to an SS7 switch with a certain destination point code. Thus, a SIGTRAN zone unambiguously identifies a certain SS7 switch, connected to the mediant SIGTRAN gateway, and may be used to address the SS7 switch.

Fig. 6 SIGTRAN zones

While transferring data into the IP network and out of it different IP zones may be used, so it is required for the System to establish correspondences between the IP and SIGTRAN zones. In the section, describing an IP zone, use the alias parameter to specify the SS7 network,


MVTS Pro 1.5.0-40

p. 38 of 197

associated with this IP zone. One IP zone may have associations with several SIGTRAN zones.

Also see section 6.2.2.

3.7. "LOCATION" SECTION “Location” section is designed to simplify the provisioning of “hosted softswitch” service and deployment of geographically distributed Systems.

The “location” section comprises a list of locations, each of them associated with a certain list of TS nodes and IP zones.

Nodes, listed in different “location” sections, are unable to interoperate with each other.

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.

Location configuration rules:

1. Names of the TS nodes must be unique.

2. Each TS 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 all locations or to the so-called “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.

6. When configuring the media node belonging to location A it is not allowed to specify signaling nodes that do not belong to location A or the global location.

Each signaling node automatically connects to the SIP or Н.323 registration-balancer nodes that belong to the same location or to the global location.

Each signaling node automatically connects a scripting node, belonging to the same location. In case no such scripting node is found, the registration-balancer node connects to the scripting node, belonging to the implied global “location”.

Each signaling node automatically connects to a scripting node, belonging to the same location. In case no such scripting node is found, the signaling node connects to the scripting node, belonging to the implied global “location”.

zone { zone "voip" { "192.168.0.0/16"; "212.92.148.0/24"; alias "ss7-zone-1"; alias "ss7-zone-2"; }; };


MVTS Pro 1.5.0-40

p. 39 of 197

Fig. 7 Example of “location” section configuration

3.8. TS NOTIFICATION FUNCTION The TS notification function allows the operator to receive e-mail notifications in case of the System malfunctioning. The alerting is done by the script /usr/sbin/mvts3g-mail invoked when a trouble occurs. The script reads the file /etc/mvts3g/mvts3g-mail.conf and acts in accordance with the settings therein. E-mail notifications are periodic, the length of the notification period being configurable. The 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.

File /etc/mvts3g/mvts3g-mail.conf

The file /etc/mvts3g/mvts3g-mail.conf is a shell script. It comprises three groups of parameters that define contact data, a list of alarms to alert the operator to and delayed dispatch properties.

1. Contact data

FROM="mvts3g-notification <[email protected]>" – e-mail address from where notifications originate.

TO="user1 <[email protected]>, user2 <[email protected]>" – list of notification destination addresses

ALARM_SUBJECT="Notification" – subject of the message

2. List of alarms and severity degrees:

ALARM_ID="NODFLT001, SIG2MED001, MGMCFG001, MGMKEY001, MGMTCN001, SN001, MGMCFG010, COUNTER001, SCRPT_DBMSC_CONNECTION" – list of events to alert the operator to

ALARM_SEVERITY="CRITICAL, MAJOR, MINOR" – degrees of the alarm severity

3. Delayed dispatch settings

The majority of the delayed-dispatch parameters are for the System’s internal use. If the TS was installed by carrying out the standard installation procedure, there is no need to change the default settings. The only parameter that can be changed is SEND_MINUTE_INTERVAL that defines the time between periodic notifications in minutes.

mailto:[email protected]




MVTS Pro 1.5.0-40

p. 40 of 197

The table below presents a list of alarms currently available in the TS.

Table 2 TS alarms

Alarm Severity Origin Message SIG2MED001 Critical Signaling No registered media

nodes

NODFLT001 Major Any node Node crashed and was restarted

SN001 Critical Scripting The Scripting Node loader path misconfigured

MGMCFG010 Critical Management "Primary management node RESTORED" or "Primary management node LOST"

COUNTER001 Minor Any node Counter value ….

MGMCFG001 Critical Management System is not configured

MGMTCN001 Critical Management Trial period expired

MGMKEY001 Critical Management Failed to read hardware key

SCRPT_DBMSC_CONNECTION

Critical “Connection to data base was lost” or “Connection to data base was restored”

There is also a possibility to configure the system to dispatch notifications on critical changes in the values of TS counters. The feature is configured for each TS node in the section “common” of the TS global configuration file. To configure notification, define the following parameters:

• alert – name of alert. Alerting can be configured for several counters at a time.

• counter – counter name.

• type – nature of changes (increase or decrease). Valid values: type

"increment"/type "decrement".

• limit – defines the notification threshold.

• step – defines variation tolerance for the counter values to prevent the System from generation of repetitive notifications when the counter value vary about the threshold value.

Below is an example of a properly configured alert:


MVTS Pro 1.5.0-40

p. 41 of 197

In case the value of a counter drops below or exceeds the configured threshold the System sends a corresponding notification to the administrator.

Example:

ID: COUNTER001

SEVERITY: MINOR

NODE: MEDIA

COUNTER NAME: phoenix.restartcount

COUNTER VALUE: 5

DESCRIPTION: Restart count

Counter value more than 1

Note: The notification function requires installation of a mail transfer agent (MTA) supportive of the sendmail™ syntax (see http://www.sendmail.org/releases/).

3.9. SNMP DAEMON CONFIGURATION The TS SNMP daemon is a background process that allows monitoring of SNMP statistics of the TS counters.

To configure the TS SNMP daemon proceed as follows:

1. Install the packet mvts3g-server-pro-snmp_<version_number>.deb from the directory /home/common/debian created by the TS installation script:

aptitude install mvts3g-server-pro-snmp_3.6.1-14_i386.deb

2. In the file /etc/snmp/snmpd.conf define the IP addresses allowed for accessing the system and change the community name from “public” to some other secure name. Actually the community name is a password for accessing the System.

media { media "media-1" { signaling "signaling-1"; common { alert "node crashed" { counter "phoenix.restartcount" { type "increment"; limit "1"; }; }; }; }; };

http://www.sendmail.org/releases/


MVTS Pro 1.5.0-40

p. 42 of 197

Fig. 8 Excerpt from the file snmpd.conf

3. Open the file /usr/share/doc/mvts3g/examples/snmpd.conf.sample. This file contains the data required for configuring SMNP daemon: the path to the TS SNMP module libsnmpagent.so, IP address of the license management node (primary - mvtsPrimaryConnectAddress, redundant - mvtsBackupConnectAddress) and examples of configuring the system counters required for monitoring. Copy the contents of the file snmpd.conf.sample to the end of the file /etc/snmp/snmpd.conf:

Fig. 9 Excerpt from the file snmpd.conf.sample

Define the actual IP address of the license management node and, if necessary, define a list of System counters to be monitored. Note that if the list of counters is defined in the file /etc/snmp/snmpd.conf, you will be able to monitor statistics on the defined counters only. To have access to information about all system counters, leave the list empty.

4. In the file /etc/default/snmpd, comment the line SNMPDOPTS='-Lsd -Lf

/dev/null -u snmp -I -smux -p /var/run/snmpd.pid 127.0.0.1'. Then add the line SNMPDOPTS='-Lsd –Lf /var/log/snmpd.log -u snmp -I -smux -p /var/run/snmpd.pid'.


MVTS Pro 1.5.0-40

p. 43 of 197

Fig. 10 Excerpt from the file etc/default/snmpd

5. Start the SNMP daemon:

$ /etc/init.d/snmpd start

6. Check that the daemon is running correctly:

$ snmpwalk -v 2c -c <COMMUNITY> <IP_address> .1.3.6.1.4.1.28029

where

<COMMUNITY> – community name

<IP_address> – IP address of the license management node

.1.3.6.1.4.1.28029 – MVTS Pro enterprise OID

Fig. 11 Excerpt from the output of the ‘snmpwalk’ command

In case of errors, check the file /var/log/snmpd.log.

3.10. CONFIGURATION OF SCRIPTING NODE LOGGING After the installation of the Traffic Switch and the scripting node software, edit the mvts-pro file, located in the /etc/logrotate.d directory. The mvts-pro file contains the settings for the configuration of scripting node logging. For example:


MVTS Pro 1.5.0-40

p. 44 of 197

Fig. 12 Configuration of scripting node logging

For each scripting node, running on the host, create its own section in the /etc/logrotate.d/mvts-pro file. The general view of a section is as follows:

Fig. 13 General view of the section, configuring scripting node logging

The name of the section comprises the path to and name of the log file. The name of the log file (mvtsprologic.scripting-1.log on Fig. 12) should conform to the <prefix>.<node name>.log format, where

• <prefix> is defined by the value of the trace_file parameter (see section 3.5.3).

• <node name> is the name of the scripting node, specified in the scripting node configuration file (see section 3.5.3).

The postrotate section contains the full path to the mvts3g-sclient application and the arguments for this utility;

• The IP address and port of the scripting node (in the example - 127.0.0.1:7710 and 127.0.0.1:7711), as defined in the scripting node configuration file (see section 3.5.3);

• The logrotate keyword.

The purpose of other parameters in the /etc/logrotate.d/mvts-pro file is described in the manual to the logrotate command. To invoke the manual, use the following command:

man logrotate

3.11. CONFIGURATION OF DB INTEROPERATION MySQL name of MVTS Pro database is ‘mvtspro’. The installation script automatically creates a database user account rtu with the password rtu. The System will use the rights of this user account to interoperate with the DB.

/var/log/mvts3g/[name of the scripting node log] { [parameters] }

/var/log/mvts3g/mvtsprologic.scripting-1.log { rotate 10 daily size 64M nocompress postrotate /usr/bin/mvts3g-sclient 127.0.0.1:7710 logrotate endscript } /var/log/mvts3g/mvtsprologic.scripting-2.log { rotate 10 daily size 64M nocompress postrotate /usr/bin/mvts3g-sclient 127.0.0.1:7711 logrotate endscript }


MVTS Pro 1.5.0-40

p. 45 of 197

The GUI configuration is located in /var/www/rtu/Config.php file. The main parameters are comprised in data_sources section:

The main subsection comprises parameters governing connection with the DB:

type – data source or DBMS type, should be mysql.

host – name or IP address of DB server.

db – DB name (by default - mvtspro).

user – DB username (by default - rtu).

password – password of DB user (by default - rtu).

The mvts subsection comprises parameters for interoperation with the TS tabular interface (see Traffic Manager -> Real-time information) and call simulation service (see Traffic Manager -> Routing -> Call simulation):

type – data source of DBMS type, should be mvts. address – IP address and port of LMN node. timeout – waiting period for a reply from TS.

To access the web-interface of the System, open the web-browser and type following URL in the address line: https://server_ip, where server_ip is the IP address of the server with TM deployed. On the logon page enter admin/admin as login and password respectively. After logging into the System for the first time, change the administrator password in System users -> Authentication. (see Section 6.1.2).

$GLOBALS['cfg'] = array ( // Data sources 'data_sources' => array ( 'main' => array ( 'type' => 'mysql', 'host' => 'localhost', 'db' => 'mvtspro', 'user' => 'rtu', 'password' => 'rtu' ), 'mvts' => array ( 'type' => 'mvts', 'address' => '127.0.0.1:9000', 'timeout' => 3 ) ), 'main_data_source' => 'main' ... )

Traffic Switch administration

MVTS Pro 1.5.0-40

p. 46 of 197

4. TRAFFIC SWITCH ADMINISTRATION

4.1. TRAFFIC SWITCH ADMINISTRATION CONSOLE The administration console is an accessory application designed for the management and control of the Traffic Switch operation. The administration console allows the SysO to upload new configuration to the management node, view statistical and diagnostic information.

To access the administration console, run any telnet client and specify the IP-address of the server that hosts the command-line node and the port that the administration console runs on. You will see the TS command line interface as in the figure below. Several instances of the administration console can run simultaneously.

Fig. 14 Traffic Switch administration console

The administration console provides a suite of global commands and tools that enable interaction of the SysO with the system. Each tool has a set of commands.

Table 3 and Table 4 below explain the commands and tools of the administration console.

Table 3 CLI commands

Command Description config <filename> (Re)read the system configuration help Displays the help screen

logout

quit

Use these commands to close current session

show <argument> Displays pertinent system data

exit Use this command to quit the current tool


MVTS Pro 1.5.0-40

p. 47 of 197

Table 4 CLI tools

Tool Commands Description display

show

Use these commands to view information about call sessions currently in progress

calls

format <full/short>

Use this command to change the output format the information

display counters

show

Use this command to view information about system events

display zones

show

Use this command to view information about configured IP zones

Use this command to view information about:

calls call sessions in progress

counters system events

zones configured IP zones

endpoints or ep

equipment registered to the system

status system status

show

briefstatus status of the main nodes in brief

You can enter the commands and names of tools as shell shortcuts to save typing. For example, you can use “d” for “display”, or “ca” and “co” for “calls” and “counters”, respectively.

Fig. 15 Output of the show ca(lls) command

To switch between tools, simply enter the name of the required tool at the command prompt.

While working with the administration console you can carry out one and the same task in several ways. For example, to view information about active calls you can:

1. Invoke the tool calls and execute the command show or display

2. Start the tool show and execute the command calls


MVTS Pro 1.5.0-40

p. 48 of 197

3. Type the command show calls

The command show counters (the tool counters) allows you to use regular expressions to limit the amount of displayed information. Fig. 16 shows the output of the command show of the tool counters when used with the regular expression .*restart.* (display information about the TS nodes restart events). For more information on regular expressions refer to4Appendix A. Metacharacters, regular expressions and number transformation.

Fig. 16 Using regular expressions to view information about system events

4.2. TROUBLESHOOTING All log files are saved in the directory /var/log/mvts3g/.

4.2.1. FILE PHOENIX.LOG All events that occur in the system are logged to the file /var/log/mvts3g/phoenix.log. In case you encounter any problem with the TS operation, you can use this file to investigate what caused the trouble. The syslog utility is used to provide logging. You can learn more about the syslog by entering the following command: man syslogd


MVTS Pro 1.5.0-40

p. 49 of 197

4.2.2. FILES RTINFO RTINFO files are run-time logs that provide operational information about individual TS nodes. To view a log file, execute the command kill with the signal -USR1 specifying the pid for the node of interest. For example

#> ps grep mvts

#> kill –USR1 24342

The resulting rtinfo file with the name rtinfo-SIGUSR1-<node name>-<node pid>.log will comprise a binary dump of the latest packets processed by the node and detailed messages about system errors. The resulting run-time log for the node, is available for viewing in the directory to /var/log/mvts3g/, and can be easily identified by the node pid.

4.2.3. SCRIPTING NODE LOGS The scripting node log contains the information about the operation of the scripting node and is saved in the /var/log/mvts3g/ directory. The System creates an individual log for each scripting node with the name <prefix>.<node name>.log, where <prefix> is defined by the value of the trace_file parameter (see section 3.5.3), and <node name> is the name of the scripting node, specified in the scripting node configuration file (see section 3.5.3). For example, mvtspro.scripting-1.log. For information about configuration of scripting node logging refer to section 3.10.

4.3. MVTS3G-LOGEXTARCTOR UTILITY You can use the mvts3g-logextractor utility located in the directory /usr/bin to extract logs of call sessions from the global debug log file (/var/log/mvts3g/traffic.log) and save them to individual files that can be further used for troubleshooting.

To extract the call log, run the utility mvts3g-logextractor providing the ID of the call in question: #>./mvts3g-logextractor /var/log/mvts3g/traffic.log ‘call ID’> filename.log

where

call ID – call identifier obtained from the call CDR;

filename.log – 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 MERA Customer Support personnel.

MVTS Pro Web interface

MVTS Pro 1.5.0-40

p. 50 of 197

5. MVTS PRO WEB INTERFACE The web server provides a friendly graphic interface for convenient configuration and administration of TM.

5.1. WHAT YOU SEE ON THE SCREEN The screenshots below (Fig. 17 and Fig. 18) illustrate the web GUI elements and the terms used in this manual to refer to the objects that the TM software deals with.

Fig. 17 TM objects and GUI elements

Fig. 18 GUI elements

Dialog

Checkbox

Textbox

Listbox

Pop-up menu Object

categories

Object


MVTS Pro 1.5.0-40

p. 51 of 197

5.2. STANDARD PROCEDURES This chapter explains standard procedures that the user performs when working with the TM GUI.

5.2.1. ACCESSING TM’S GUI To establish a link with the web server, enter the IP address or DNS name of the host on the address line of the web browser you are using, for example, https://mvtspro-server.yourcompany.com. Note that the working protocol must be HTTPS (Hyper Text Transmission Protocol, Secure) The System will respond with a logon dialog similar to that shown in Fig. 19:

Fig. 19 Logon dialog box

Enter your login and password (note that the login and password check is case-sensitive), and click Login. In case you are using your IP address as the authentication parameter simply click Login. If the logon credentials provided by you are correct you will see the main window of the web interface.

The left part of the window shows the tree of object categories. The right pane is a working area which displays the information on the currently selected object.

Fig. 20 Web interface main view

Use the Rows on page combo box located below the table to control the number of rows displayed in the tables (10, 25, 50 or 100). Use the buttons / to view the next (or previous) portion of data. Use the buttons / to go to the last or first view.

https://mvtspro-server.yourcompany.com/

https://mvtspro-server.yourcompany.com/


MVTS Pro 1.5.0-40

p. 52 of 197

To quicken search of the necessary information you can use search filters. Refer to section 5.2.3 for information about the use of search filters.

5.2.2. POP-UP MENU Left-click the record of interest in the table you are viewing to invoke a pop-up menu that offers record handling options. The content of the pop-up menus is contextual, that is, differs from table to table and depends on the user’s permissions. The figure below presents an example of the pop-up menu invoked from the table Users.

Fig. 21 Pop-up menu

The full version of the contextual menu is comprised of the following items:

Add – this command allows you to add new records to the table;

Add from copy – this command is instrumental when you need to use a copy of the existing record to create a record that differs from the existing one just slightly.

View – opens a record viewing window. To return to the tabular view click the OK button;

Edit – opens a record editing dialog box. When you are through with editing the record parameters, click OK to confirm or Cancel to discard the changes;

Delete – use this command to delete the record you selected;

Edit marked – this command allows you to edit marked records. To mark the records, select the respective check boxes in the leftmost column of the table. To mark all records in the list, simply select the checkbox in the header of the table.

Delete marked – this command allows you to delete marked records. To mark the records, select the respective check boxes in the leftmost column of the table. To mark all the records in the list simply select the checkbox in the header of the table.

Edit all filtered – this command allows you to edit all records in the table you are working with. In case the table data has been filtered, only the records matching the filtering criteria will be edited (for more information about filters refer to section 5.2.3).


MVTS Pro 1.5.0-40

p. 53 of 197

Delete all filtered – this command allows you to delete all the records from the table you are working with. In case the table data has been filtered, only the records matching the filtering criteria will be removed (for more information about filters refer to section 5.2.3).

Filter – invokes a filter dialog box (for information how to use filters consult section 5.2.3), or quickly filters the table by the value of the selected or adds the value of the selected cell to the already applied filter;

Arrange columns – enables you to arrange the table columns according to your preference (see section 5.2.5);

Export data – use this command to unload data from the tables into CSV-files (for information about data export refer to section 5.2.7).

Related tables – a list of tables associated with the table you are working with. The table opened by this command contains information related only to the item selected in the source table. For example, left-click a record of interest in the System users table and select Authentication history on the pop-up menu. The system will display the Web authentication history table with information about the selected user only.

5.2.3. USE OF FILTERS The use of filters allows you to limit the amount of information displayed onscreen and view only the records that meet certain criteria.

The application allows for creation of complex filters that are helpful when there are several conditions that records of interest must meet. Filtering conditions (i.e. search criteria) can be combined with the help of the following logical operators:

AND – a search will return records that meet all the specified conditions only

OR – a search will return records that meet at least one of the specified conditions;

NOT (AND) – a search will return records that meet none of the specified conditions only;

NOT (OR) – a search will return records that do not meet at least one of the specified conditions;

To create a filter, invoke the pop-up menu, select Filter and Add to configured. The system will display a filter dialog similar to the one shown in Fig. 22.

Fig. 22 Filter construction dialog


MVTS Pro 1.5.0-40

p. 54 of 197

The displayed filter dialog has the following controls:

Table 5 Filter construction dialog controls

Control Description

This control applies the constructed filter to the table contents. The upper Apply button is used to apply the newly constructed filter while the lower button serves to apply filters saved earlier.

Use this button to delete saved filters

This control appears on the filter dialog after the application of the filter only. Use it to cancel the filter application

Use this control to save the constructed filter for future use.

Deletes a filtering condition

Adds a new line for filtering condition

A drop-down list of logical operators integrated with a menu for adding/deleting groups and conditions.

The look of this dynamic control element varies with the selected logical operator

Dynamic control element for selection of comparison operators. The make-up of this drop-down list varies with the selected logical operator. The operators Like and Not Like allow the use of meta-characters ‘%’ and ‘_’ in constructed search patterns. The operator “RegExp" shows that what follows is a regular expression. Refer to supplement A for detailed information about meta-characters and regular expressions.

Combo box with drop-down list of saved filters.

For a more illustrative explanation suppose you need to filter the contents of the table Gateways so that it includes records of active terminating gateways pertaining to networks 192.168.131.0/24 and 192.168.132.0/24 only.

When put into words the filter structure can be construed by the following table

The required records must… Remarks …be enabled, …represent termination gateways,


MVTS Pro 1.5.0-40

p. 55 of 197

…belonging to network 192.168.131.0/24 Use meta-characters in search

… belonging to network 192.168.132.0/24 Use meta-characters in search

By this means it is necessary to create a filter that includes:

two conditions and a group of conditions united by the operator “AND”.

two grouped conditions with the operator “OR”.

The resulting filter may look like the one shown below.

Fig. 23 Target filter

To construct the necessary filter, proceed as explained below:

1. Add the first filtering condition. To do it, click , next to the control *AND* or click *AND* and select Add Condition on the appearing pop-up menu. Select Enabled in the newly added combo box and select the check box to the right of the equal sign "=" (see Fig. 24).


MVTS Pro 1.5.0-40

p. 56 of 197

Fig. 24 Filter construction. Step 1

2. Repeat Step 1, to add another condition combo box. In the drop-down list of conditions select “Allow termination” and select the check box to the right of the equal sign "=" (see Fig. 25).


3. Add a group of conditions by clicking the control * AND * and selecting the Add group option in the appearing menu (see Fig. 26). Note, that *AND* is a default logical operator for groups of conditions.


MVTS Pro 1.5.0-40

p. 57 of 197

Fig. 26 Filter construction. Step 3. Adding group

4. Change the logical operator in the newly added group clicking the * AND * control and selecting OR in the appearing pop-up menu. (See Fig. 27).


5. Start adding conditions to the group. To add a condition, click , next to the control * OR * or click the * OR * control and select Add Condition on the appearing pop-up menu.


MVTS Pro 1.5.0-40

p. 58 of 197


6. Select Term. IP address for the condition. Click the control “=” and select the option Like on the drop-down menu. Enter network pattern 192.168.131.% in the rightmost field (see Fig. 29).


7. Repeat steps 5 and 6 to add a similar condition for gateways belonging to network 192.168.132.0/24. This step completes the filter creation procedure. To apply the filter to the contents of the table click the upper button Apply (see Fig. 33).


MVTS Pro 1.5.0-40

p. 59 of 197


With a filter applied the table displays the icon next to its heading to indicate that what you are viewing is not the complete table content. To cancel the filter, click the icon. For the user’s convenience the system remembers the filter applied last.

In addition the user can save created filters for future use. To save a handy filter, click the Save button on the filter, enter the filter’s name in the appearing dialog and click the OK button.

Fig. 31 Saving a filter for future use

To make use of an earlier saved filter, invoke the filter dialog, select the required filter in the combo box Saved filters and click the Apply button to the right of the combo box (see Fig. 32). To delete the saved filter click Delete.


MVTS Pro 1.5.0-40

p. 60 of 197

Fig. 32 Selecting an earlier saved filter

5.2.4. SORTING TABLE DATA The System allows you to sort the contents of the table columns. To sort data in a column, click the column header. The first click causes the column contents sorting in the descending order with the sort order indicated by a down arrow next to the column header. To reverse the sort order, click the column header once again. The third click clears the sort of the column contents.

The system also allows you to perform more complex types of sort affecting the contents of several columns. In this case the last sorting you apply becomes the main sorting criterion. The sort precedence is indicated by the number appearing next to the arrow sort indicator at the column header.

With data sorted in one or several columns, the sort indicator appears next to the table name. A click on this icon removes the sort from all columns.

5.2.5. RE-ARRANGING TABLE COLUMNS For the sake of convenience, the system allows you to display, conceal and re-arrange table columns according to your preference. Click Arrange columns on the pop-up menu. The system will display a dialog box similar to the one shown in Fig. 33.


MVTS Pro 1.5.0-40

p. 61 of 197

Fig. 33 Re-arranging table columns

The right box presents the list of the columns as they appear in the table from left to right. To conceal a column, select it and click the button. To display a column, select it in the

left box and click the button. Use the and buttons to move all the column names from the right box to the left and vice versa.

The and buttons allow you to move the columns in the table to the left or to the right, respectively.

Besides, you can make use of the table layout saved earlier, by selecting the name of the required layout in the drop-down list Saved layouts.

Click the Apply button when you are through with configuring the table. The new column layout will be applied to the table. You will also see the icon next to the table name.

To save the table layout you configured, use the Save button in the bottom part of the window. Enter the name of the layout in the invoked dialog window and press OK.

To delete the saved layout, select it in the drop-down list and press Delete.

If you do not save your settings, the system will still remember the table layout you configured and the next time you log in it will display the table in accordance with the changes you made.

To restore all the table columns in their initial layout, click the icon.

5.2.6. EDITING MULTIPLE TABLE RECORDS The button Switch to edit mode appearing over every table brings up a dialog box that allows you to edit all the records currently displayed simultaneously. Fig. 34 illustrates such multiple-edit dialog box invoked from the table “Codec group setup”.


MVTS Pro 1.5.0-40

p. 62 of 197

Fig. 34 Editing multiple table records

When through with record editing, click OK to confirm or Cancel to discard the made changes.

5.2.7. DATA EXPORT There is a possibility to export data from viewed tables to CSV files for use in other applications.

To export data proceed as follows:

Left-click the table you are working with and select the Export data option on the pop-up menu. In the invoked dialog box, click Save.


MVTS Pro 1.5.0-40

p. 63 of 197

You will see the Save as dialog box. Use the Save in combo box to indicate the device and folder where you want to save the file.

Enter the file name in the field File name.

In the Save as type combo box select Microsoft Office Excel Comma Separated Values File and click Save.

5.2.8. COMPONENT VERSION VIEW To view the versions of the System components in the web interface click the hyperlink with System name and version in the bottom right corner of the web interface window. A new dialog with the System component version will be displayed.


MVTS Pro 1.5.0-40

p. 64 of 197

Fig. 35 Viewing the System component versions in the web interface

The following designations are used:

Logic – the version number of the scripting node software.

TS – the Traffic Switch version number.

WEB+DB – the version number of the web interface and the database.

MVTS Pro – the System version.

Operating TM

MVTS Pro 1.5.0-40

p. 65 of 197

6. OPERATING TM

6.1. ADMINISTRATION

6.1.1. SYSTEM USERS The table of users (Administration → System users) presents information about personnel who have access to and operate the MVTS Pro system.

To add a new user account, left-click the mouse on the table to invoke the pop-up menu and select the option Add.

Fig. 36 Add-user dialog

Enter the following data in the displayed dialog (see Fig. 36). The fields marked with an asterisk are required fields:

* User name – type in the user’s name.

* Language – use this combo box to select the language that the user will use when working with the web interface.

* Role – from the combo box select the role to be assigned to the user. For the description of roles configuration see sections 6.1.3 and 6.1.4.

Enable – select the checkbox to make the record active.

When through with entering data, click OK to submit the newly made record. The program assigns the record an automatically generated ID and adds it to the table System users.

To edit, delete or view a record in an individual window select the appropriate item in the pop-up menu.

Your next step in configuring the user’s account in the System is entering the user’s authentication data that enables web access to the System (see section 6.1.2).

Operating TM

MVTS Pro 1.5.0-40

p. 66 of 197

6.1.2. WEB AUTHENTICATION This table presents user authentication and authorization data used during logon to the System.

TM can perform user authentication by any attribute defined in the authentication record – the login name, password or IP address – and any combination thereof.

There can be one or several authentication records configured for one user.

During authentication the System performs the AND operation on the authentication parameters configured in the user authentication record and uses the OR condition in case of multiple authentication records existing for the same user..

Let us explain how the System authentication process is organized using the following example.

Assume a user wants flexible access to the System information and wishes to be able to view traffic statistics both from the office tabletop computer with a trusted IP and any other IP (laptop) when on the move.

To ensure this, the user must have two authentication records – one configured for IP address authentication and another with just a login name and password. When accessing the system from the office computer the user will be granted access to the System even without having to enter the login name and password or with the login or password mistyped. (login/password verification will fail, but IP authentication will prove successful.)

Wishing to access the System from any other place the user will have to provide correct logon credentials (login name and password) as IP verification will fail.

To configure logon credentials for a new user, select ‘Add’ in the pop-up menu.

Fig. 37 Web authentication dialog box

Enter the user’s logon credentials filling out the fields of the brought up Web authentication dialog box. The fields marked with an asterisk are required fields.

* User – use the drop-down list to select the user whose logon credentials you are configuring.

* Realm – select the GUI realm, available to the user, from the drop-down list.

* Login – enter the user’s login name here. Note that all user logins configured in the DB must be unique.

Password, IP address – use these fields to enter respective user authentication attributes.

Operating TM

MVTS Pro 1.5.0-40

p. 67 of 197

Enabled – select the checkbox, to make the record active.

To submit the configured authentication record click OK. Click Cancel to discard the changes or abort the procedure.

6.1.3. ROLES The object Roles allows you to create and compile roles. To create a new role, invoke the pop-up menu and select the Add option.

Fig. 38 Creating a new role


* Parent role – select the parent role for the role being created in the combo box.

Note: The scope of GUI access rights of the child role cannot be greater than that of the parent role.

The role Administrator with the rights to view, modify and delete all GUI objects is created automatically during the software installation.

* Name – enter the name of the new role;

Description – enter any information relevant to the role.

When done, click the OK button.

Once the role is created, assign the rights to the role (see Section 6.1.4) and compile it.

Role compilation is also required every time any changes are done in the role settings. During the role compilation process all GUI elements are updated in accordance with new role settings, so that users assigned to this role could gain access to the GUI elements.

Fig. 39 The new role ready to be compiled

To compile the role press the button. If the role is compiled successfully, the System will show Yes in the Compiled column of the role record.

6.1.4. ROLE SETTINGS The Role settings dialog is used to make a list of rights characteristic of the created user role. To make a set of rights for the role, invoke the pop-up menu and select the Add option.

Operating TM

MVTS Pro 1.5.0-40

p. 68 of 197

Fig. 40 Role construction window


* Role – select the role, for which the set of rights is being built.

* Filter – select a category or an object, used as a filter. The Object list will show the GUI element itself and all its child elements. This allows you to discard unwanted GUI objects (the access rights to which should be left unchanged) from the Object list.

* Object – select a category, object or a parameter, to which the access rights are granted. The list comprises the GUI object itself (the root element) and its child elements (if any).

Both lists have the following designations in the names of the GUI elements:

• [M] – category;

• [Т] – object (table);

• [С] – parameter (table column).

Include all child objects – select the checkbox, if you want to assign the access rights not only to the GUI element, selected in the * Object combo box, but also to all its child elements.

Actions – select the checkboxes, corresponding to the actions, which the user may perform on the selected GUI elements.

• View – viewing elements.

• Update – modifying the element value.

• Insert – creating new element.

• Delete – deleting the element.

• Execute – executing the element (valid for wizards and procedures, such as call simulation and CDR scheduled export).

When done, click the OK button. After any changes in the role settings, the role should be re-compiled. (see Section 6.1.3).

6.1.5. SYSTEM USER CREATION WIZARD System user creation wizard allows you to facilitate the process of creating new user accounts in MVTS Pro. Click the System user creation wizard to start creating an account.

To navigate through the user creation steps, use Back and Next Buttons. The fields, marked with an asterisk, are required fields. The password is case-sensitive.

Operating TM

MVTS Pro 1.5.0-40

p. 69 of 197

Fig. 41 Add User Wizard dialogue box

Click Next button.

Fig. 42 User account dialogue box

In the User account dialogue box enter the name of the new user account in the field * User name. Select the GUI language from the drop-down list * Language. Select the role in the Role field. Click the Next button.

Fig. 43 Authentication dialogue box

Enter the following parameters in the Authentication dialogue box:

* Realm – select the GUI realm available for the user from the drop-down list.

* Login – enter the user’s login name here. Note that all user logins configured in the DB must be unique.

Password, IP address – use these fields to enter respective user authentication attributes (see Section 6.1.2).

Click Next.

Operating TM

MVTS Pro 1.5.0-40

p. 70 of 197

Fig. 44 Create user final dialogue box

Check the correctness of the specified data in the Create user dialogue box. Return to the previous stages, using the Back button, and revise the information if required. To complete user creation click Finish.

6.1.6. WEB REALMS The division of the GUI into distinct realms is a MVTS Pro security measure that provides for differentiation of user GUI access rights.

A realm is an isolated area of the web-interface. A user belonging to a specific realm has no access to authentication records of users associated with other realms.

The inaccessibility of authenification records of users belonging to a different realm prevents the possibility of password guessing and password hacking attacks.

Defining a realm is a must during configuration of any user authentication record.

Initially, TM has a single pre-configured public realm called Users with the unique ID “users”. By default, any newly added authentication record belongs to the realm “users”.

Fig. 45 Realms table

The Realms table (see Fig. 45) shows the realms configured in the system.

For better security, you may wish to create a private realm, accessible to the System administrators only.

To create a private realm, invoke the pop-up menu and select the ‘Add’ item.

Operating TM

MVTS Pro 1.5.0-40

p. 71 of 197

Fig. 46 Adding a new realm

Fill out the fields of the ‘Realms’ dialog box (the fields marked with an asterisk are required fields):

* ID – enter the unique ID of the realm, which can be any word of your choice, for example, “admin”.

Note: The unique ID of a web realm is one of the configuration parameters of the PHP-application (see below).

* Realm name – enter the name of the realm (for example, “admins”).

Description – you can enter any appropriate information in this text box.

When finished with filling out the configuration form, click OK. The newly configured record will be added to the table.

Then edit the configuration file Config.php, found in the directory /var/www/rtu, and specify the ID of the created private realm in it (see Fig. 47):

Fig. 47 Entering the ID of a new realm into Config.php

To enhance the system security, you can also use Apache server tools to configure the web interface so that it will listen only to intranetwork IP address (refer to the Listen directive of the Apache configuration), or deny or allow access from specified networks or IP addresses (refer to Allow from/Deny from directives of the Apache configuration).

Operating TM

MVTS Pro 1.5.0-40

p. 72 of 197

6.2. EQUIPMENT

The category equipment comprises information about the equipment, MVTS Pro interoperates with, zones and codecs.

6.2.1. EQUIPMENT The table Equipment displays information about the equipment that MVTS Pro interoperates with.

Fig. 48 List of configured gateways

To add a new record to the table, invoke the pop-up menu and select Add.

Operating TM

MVTS Pro 1.5.0-40

p. 73 of 197

Fig. 49 Configuring a gateway record

Fill out the fields of the displayed form. The fields marked with an asterisk are the required parameters.

Enabled – select the checkbox to make the record active.

* Name – enter the name of the device being configured.

Description – you can enter any descriptive information in this field.

* Equipment type – select the type of gateway from the combo box:

• Gateway / Endpoint – this gateway is a trunk gateway or an endpoint.

• Gatekeeper – this gateway acts as a gatekeeper.

• Default gateway – this gateway acts as a default template gateway, for the devices not configured in MVTS Pro.

• Routing server – this gateway acts as an external routing server.

• ENUM server - the device being configured is expected to use ENUM servers for external routing. Note that that ENUM-aided routing is possible for SIP devices only. To establish a connection, the system uses the SIP port specified in the parameter Term. port SIP.

Allow origination – select the checkbox to allow the device to operate as a call originator.

Allow termination – select the checkbox to allow the device to operate as a call terminator.

Operating TM

MVTS Pro 1.5.0-40

p. 74 of 197

* Registration mode – choose if the gateway will be registered in MVTS Pro. If the Default gateway is selected in the Equipment type list, only one option is available and the gateway will always be registered. Possible settings include:

• No registration – do not register the gateway with MVTS Pro.

• Register gateway – register the gateway with MVTS Pro as a single device, without differentiation between ports.

* Protocol – specify the signaling protocol supported by the device. If the option H.323 or SIP as for incoming leg was selected and the gateway acts as a terminator, the System will transmit data to this gateway under the protocol (H.323 or SIP), used by the originator. If the originator operated under a protocol, different from SIP or H.323, the SIP protocol will be used to transmit data to the terminator.

Max. call duration, sec. – define the maximum allowed duration of a call originated or terminated by the device.

Origination logging – select the check box to enable the debug logging functionality for situations when the device originates calls.

Termination logging – select the check box to enable the debug logging functionality for situations when the device terminates calls.

Note: It is not recommended to keep the latter two parameters active during normal System operation, as this may hinder its functionality.

Enable statistics – select the check box to enable statistics accumulation for this gateway, which will later be used to plot graphs.

Valid from/Valid till – use this controls to define the beginning and end of the record validity term.

Category Origination settings. This group of parameters is intended for configuration of origination devices. The parameters are valid only with the Allow origination checkbox selected.

Orig. IP address list – define the list IP addresses used by the device for call origination (you can use the CIDR format for IP addresses). MVTS Pro will receive calls from the specified addresses. In case the SS7 protocol is used, this parameter is invalid.

Orig. port – specify the signaling port of the origination device for the purpose of caller identification. In case the SS7 protocol is used, this parameter is invalid.

Note: It is important that you enter the number of the signaling port only when several gateways use the same IP address and the call originator can be distinguished solely by the signaling port number. Otherwise, leave this field empty.

Orig. NAT address – specify the address of the NAT device if the configured gateway is sitting behind a network address translator.

* Orig. Zone – use the combo box to select the zone (see section 6.2.2) to be used for calls originated by the device. In case the SS7 protocol is used, the SIGTRAN zone is used to address the gateway.

* Orig. proxy mode – define the media proxy mode to be used when the device acts as a call originator:

• Proxy media — always proxy media (the media stream will pass through the softswitch in any case).

• Do not proxy media whenever possible — do no proxy media when possible (otherwise allow proxy);

• Do not proxy media — disallow proxying (even if no common codecs are available);

Operating TM

MVTS Pro 1.5.0-40

p. 75 of 197

When media proxy settings for termination equipment disallow proxying while the originator’s settings require it, the TM discards this route (originator-terminator combination). If all routes are discarded, the call is cancelled.

Note: The “do not proxy media" mode has the highest priority, i.e. in case either of the call parties is configured for the “do not proxy media" mode, the System will not proxy media.

Orig. codec group – select the group of codecs allowed for the device when it acts as a call originator (for more information about codec groups refer to section 6.2.3).

Always discard non-matching codecs – select the checkbox for the codec lists of all routing paths (originator-terminator pairs) to include solely codecs common for the origination and termination parties. When this method of codec list generation is selected, all codec list preparation settings for the terminator are ignored. If the returned originator’s codec list is empty, the Traffic Switch returns the error onVoipCallBegin: there are no allowed codecs for srcIP. For further information about the actions of the System depending on the proxy mode and codec sorting settings, see Appendix B. Codec list generation in MVTS Pro.

SRC Capacity group – select the name of the common capacity group from the drop-down list. The gateway will belong to the selected capacity group. For more information about capacity groups see Section 6.8.11.

Max. incoming calls – the maximum number of incoming calls the device can handle simultaneously.

Orig. groups – enter the names of the gateway groups to which calls originated by the group devices are related. Such group names can be used for call routing and number translation process when entered in such fields as Allowed SRC groups and Disallowed SRC groups.

Orig. allowed SRC numbers – enter a regular expression that determines the pattern for allowed source numbers.

Note: To set up a device with several analog sockets (ports), create a gateway record for each socket and specify the respective socket (port) number, configured on the device, in the Orig. allowed SRC numbers parameter for each gateway.

Orig. allowed DST prefixes – enter a regular expression that determines the pattern for allowed destination numbers.

Orig. disallowed DST prefixes – enter a regular expression that determines the pattern for disallowed destination numbers. Disiallowed numbers override the allowed ones.

Category Termination settings. This group of parameters is intended for configuration of termination devices. The parameters are valid only with the Allow termination checkbox selected.

Term. IP address – define the IP address used by the device for call termination (only one IP address is allowed). In case the SS7 protocol is used, this parameter is invalid.

Term. port H.323– define the port number to be used for call termination under H.323. In case the SS7 protocol is used, this parameter is invalid.

Term. port SIP – define the port number to be used for call termination under SIP. In case the SS7 protocol is used, this parameter is invalid.

* Term. zone – use the combo box to select the zone (see section 6.2.2) to be used for calls sent to the device. In case the SS7 protocol is used, the SIGTRAN zone is used to address the gateway.

* Term. proxy mode – define the media proxy mode to be used when the device acts as a call terminator (see also the Note above):


Operating TM

MVTS Pro 1.5.0-40

p. 76 of 197



When media proxy settings for termination equipment disallow proxying while the originator’s settings require it, the TM discards this route (originator-terminator combination). If all routes are discarded, the call is canceled.

* Term. codec group – select the group of codecs allowed for the device when it acts as a call terminator (for more information about codec groups refer to section 6.2.3).

* Term. codec sorting – select a codec list generation method, which is used when the gateway is the call terminator. All codec list sorting methods apply to media codecs only, as data codecs are always placed after media codecs in the list in accordance with their precedence setting in the DB (except when the No sorting mode is selected). (see section 6.2.4).

No sorting – return the terminator’s list of codecs as it is in the DB without any modifications. The order of codecs in the list is determined by the codecs’ precedence settings. (see section 6.2.4).

Matching codecs first – sort the list moving terminator’s codecs matching those of the originator to the beginning of the list. The order of codecs in the subset of common codecs is defined by the order of the codecs, received from the originator. The order of the codecs outside the subset is determined by the attribute Precedence of each codec. (see section 6.2.4).

Non-matching codecs discarded – discard the terminator’s codecs that do not match the originator’s codecs from the list. The order of codecs in the resulting list is determined by the codec’s attribute Precedence. (see section 6.2.4).

Return first matching only – return the first terminator’s codec that matches the originator’s.

No matches – no sorting – sort using the Non-matching codecs discarded method. If the returned list is empty, the System returns the terminator’s codecs list as it is in the DB.

For further information about the actions of the System depending on the proxy mode and codec sorting settings, see Appendix B. Codec list generation in MVTS Pro.

DST capacity group – select the name of the common capacity group from the drop-down list. The gateway will belong to the selected capacity group. For more information about capacity groups see Section 6.8.11.

Max. outgoing calls – the capacity value is the maximum number of outgoing calls the device can handle simultaneously.

Cancel SRC number translations; Put Orig. address in "From" – select the checkbox, if you need to place the IP address and port of the originator into the “From” field of the INVITE message sent to the terminator. This cancels the number translation rules of the SRC number. If the caller ID is blocked, the System substitutes the name/telephone number in the “From” field with the word “anonymous”, e.g.

From: <sip:[email protected]:2345;user=phone>

Category Registration settings

This group of parameters is intended for configuration of registering gateways. The parameters are valid only if Register gateway option is selected from the Registration type list.

Operating TM

MVTS Pro 1.5.0-40

p. 77 of 197

Registration username – enter a registration name, received from the device (do not fill this field when the Is default gateway checkbox is selected). Refer to page 83 for information about the Is default gateway flag.

Registration password – specify a registration password (do not fill this field when the Is default gateway checkbox is selected). Refer to page 83 for information about the Is default gateway flag.

Max registration time, sec – set the interval between full re-registration of the device in seconds.

Registration keep-alive time, sec – set the registration updates interval for the RAS-users registered with MVTS Pro, in seconds.

Registration address list – enter a list of IP addresses allowed for registration with MVTS Pro delimiting them with semicolons. Leave the field blank to allow the device to register from any IP address.

NAT keepalive time, sec – sets a keepalive interval for NAT devices.

Registration logging – select the checkbox to record registration attempts into the Debug registration log.

Category Number translation rules

Orig. SRC number translation – enter a regular expression that determines source number modification rules for the cases when the device is the call originator (for detailed information about number regular expressions and translation rules refer to 5Appendix A. Metacharacters, regular expressions and number transformation).

Orig. DST number translation – enter a regular expression that determines destination number modification rules for the cases when the device is the call originator.

Note: The parameters are valid only with the Allow origination checkbox selected.

Term. SRC number translation – enter a regular expression that determines source number transformation rules for the cases when the gateway is a termination device.

Term. DST number translation – enter a regular expression that determines destination number modification rules for the cases when the gateway is a termination device.

Note: The parameters are valid only with the Allow termination checkbox selected.

Note: The above configured number transformation rules will be applied to the numbers before the call routing procedure starts.

Category Origination signaling settings

This group of parameters is intended for configuration of the gateway properties when the gateway is an origination device. The parameters are valid only with the Allow origination checkbox selected.

Orig. force alerting timeout, sec – use this parameter to set a time interval (in milliseconds), after which the system will send a neutral Alerting message to the origination gateway.

Orig. enable RBT – select the checkbox to enable the RBT (ring-back tone) emulation function when proxying media-traffic.

Orig. RBT timeout, sec – define the wait period (in seconds) before the Systems starts RBT emulation in the absence of RBT from the call terminator.

Orig. RBT file – enter the name of the audio file (.wav file) to be used for RBT emulation. The path to the audio file is configured in the settings of the media-node.

Orig. RTP timeout, sec – define wait period for RTP traffic in seconds. If the specified time expires and there is no RTP traffic in either direction the system aborts the call.

Operating TM

MVTS Pro 1.5.0-40

p. 78 of 197

Orig. CallProceeding timeout, msec – set the packet forwarding delay in milliseconds, during which the call setup packets exchange with the origination device is suspended. During call setup packets arriving from the termination device are stored in the TS buffer, whose content will be forwarded further to the call originator only when the delay time specified in this field is over. Such organization of the call setup and look-ahead routing procedure is needed for devices that can handle one CallProceeding message only. Hence, if a CallProceeding message is occasionally followed by a Release_Complete message, further interoperation (call setup and call rerouting) with such a device intolerable to repeated CallProceeding messages may become impossible.

The next five parameters are valid only if the H.323 protocol is selected in the Protocol combobox.

Orig. allow media channels update – select the checkbox if the device being configured is capable of receiving repeated FastStart messages.

Orig. faststart – select this checkbox if the device is FastStart capable.

Orig. response FastStart in messages – select the appropriate checkbox to define which message will include the FastStart packet. The possible options include:

- Call Proceeding,

- Alerting/Progress,

- Connect;

Orig. tunneling – select this checkbox if the device is supportive of Tunneling (H.245 encapsulation).

Orig. start H.245 after – use this combo box to define the message, upon receipt of which the H.245 control channel is opened:

- Call proceeding

- Alerting/Progress

- Connect

SRC Calling party’s category – to save the calling party’s category, received from the originator unmodified, select the blank option. To change the calling party’s category select the desired category from the list.

Category Termination signaling settings

This group of parameters is intended for configuration of the gateway properties when the gateway is a termination device. The parameters are valid only with the Allow termination checkbox selected.

The following parameters are valid only if the H.323 protocol is selected in the Protocol combo box.

* Term. SRC type of number – specify the type of source numbers supported by the device using the drop-down list of this combo box:

Same as on the incoming leg

Unknown

International number

National numer

Network specific number

Subscriber number

Abbreviated number

Operating TM

MVTS Pro 1.5.0-40

p. 79 of 197

* Term. SRC numbering plan – define the numbering plan supported by the device using the drop-down list of this combo box:


Unknown

ISDN telephony numbering plan (Recommendation E.164)

Data numbering plan (Recommendation X.121)

Telex numbering plan ((Recommendation F.69)

National standard numbering plan

Private numbering plan

* Term. DST type of number – specify the type of destination numbers supported by the device using the drop-down list of this combo box:


Unknown

International number

National numer

Network specific number

Subscriber number

Abbreviated number

* Term. DST numbering plan – define the numbering plan supported by the device using the drop-down list of this combo box:


Unknown

ISDN telephony numbering plan (Recommendation E.164)

Data numbering plan (Recommendation X.121)

Telex numbering plan ((Recommendation F.69)

National standard numbering plan

Private numbering plan

Term. faststart – select this checkbox if the device is FastStart capable.

Term. tunneling – select this checkbox if the device is supportive of Tunneling (H.245 encapsulation).

Term. start H.245 after – use this combo box to define the message, upon receipt of which the H.245 control channel is opened:

- Call proceeding

- Alerting/Progress

- Connect

* Term. SRC Presentation indicator – select the value of the presentationIndicator field in the SETUP packet. For more information on presentationIndicator field see Q.931 and Q.951. Select the value from the drop-down listbox:

Same as for the incoming leg

Octet 3a not present

Presentation allowed

Presentation restricted


http://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-Q.951.4-199303-I!!PDF-E&type=items

Operating TM

MVTS Pro 1.5.0-40

p. 80 of 197

Number not available due to interworking

* Term. SRC Screening indicator – select the value of the screeningIndicator field in the SETUP packet. For more information on screeningIndicator field see Q.931 and Q.951. Select the value from the drop-down listbox:

Same as for the incoming leg

Not screened

User-provided, not screened

User-provided, verified and passed

User-provided, verified and failed

Network provided

The following three parameters are valid only if the SIP protocol is selected in the Protocol combobox.

* Term. SIP report original destination – this combo box includes the following options:

- No;

- Yes – in case the INVITE message on the incoming leg did not include the “Diversion” field (or in case of a H.323 to SIP call) the TS adds this field with the unchanged URI/destination number to the INVITE message sent to the call terminator.

- The same as on the incoming leg: In case the INVITE message on the incoming leg featured the “Diversion” field, it is included unchanged in the INVITE message sent to the call terminator.

Note: In case of a H.323 to H.323 call the confID received on the incoming leg is sent unchanged to the call terminator.

Note: In case of a H.323 to SIP call the TS adds the “Cisco-Guid” field to the INVITE message sent to the call terminator. The field comprises the same confID as on the incoming leg (in the format used by the Cisco IOS).

Note: If in case of a SIP to H.323 call, the INVITE message on the incoming leg comprised the "Cisco-Guid” field, the confID sent to the call terminator is the same as in this field.

* Term. SIP privacy method – use this combo box to select the privacy method to be used when the SIP protocol is involved:

- Cisco RemotePartyID (for more information about this method refer to http://www.cisco.com/en/US/products/sw/iosswrel/ps1839/products_feature_guide09186a0080110bfb.html#wp1050768).

- RFC 3325 PAssertedID (for more information about this method refer to http://www.ietf.org/rfc/rfc3325.txt).

Term. SIP redirect address list – enter masks of networks where call forwarding is allowed when the equipment operates as a termination endpoint. On receipt of a call forwarding request the System checks if the IP where the call is forwarded belongs to the network allowed for call forwarding and if not the call is rejected. When making a list, delimit the masks you are entering with semicolons without spaces.

Term. H.323 First answer timeout, sec – define the wait period for the SETUP message answer in seconds. If the specified time expires and the termination device has not answered to the SETUP message, the system aborts the call.

Term. SIP First answer timeout, sec – define the wait period for the INVITE message answer in seconds. If the specified time expires and the termination device has not answered to the INVITE message, the system aborts the call.


http://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-Q.951.4-199303-I!!PDF-E&type=items

http://www.cisco.com/en/US/products/sw/iosswrel/ps1839/products_feature_guide09186a0080110bfb.html#wp1050768

http://www.cisco.com/en/US/products/sw/iosswrel/ps1839/products_feature_guide09186a0080110bfb.html#wp1050768

http://www.ietf.org/rfc/rfc3325.txt

Operating TM

MVTS Pro 1.5.0-40

p. 81 of 197

Term. Connect message timeout, sec – define the wait period for the Connect message answer in seconds. If the specified time expires and the termination device has not answered to the Connect message, the system aborts the call.

Term. RTP timeout, sec – define the wait period for RTP traffic in seconds. If the specified time expires and there is no RTP traffic in either direction the system aborts the call.

DST Match CPC for translation – make the list of calling party’s categories to be translated. If the gateway receives the call with a CPC from the list, this CPC will be translated into a CPC, defined in the DST Translation for matched CPC parameter.

Select the desired CPC and move it to the right window by clicking the right-arrow button . To remove a category from the list in the right-hand window, select the appropriate

category and click the left-arrow button . Holding down a Shift or a Ctrl key allows you to select several categories at once. Use the and buttons to move all categories from the right box to the left one and vice versa.

DST Translation for matched CPC – select the category, which will substitute the categories from the DST Match CPC for translation list. If you want to leave the category unchanged, select the blank option.

* DST CPC method – select the method used to transmit the calling party’s category to the terminator.

• None – calling party’s category is not transmitted to the terminator. This option must be used for the H.323 protocol (as the H.323 protocol does not support CPC) or the SS7 protocol (as the CPC is transmitted under SS7 in any case).

• SIP ISUP OLI – the category is transmitted via SIP in the “isup-oli” parameter of the “From” field. The category is transmitted according to the OLI standard.

• SIP CPC – the category is transmitted via SIP in the “cpc” parameter of the “From” field. The category is transmitted according to the OLI standard. For further information see The Calling Party's Category tel URI Parameter.

• SIP Category – the category is transmitted via SIP in a separate header “Category”. The category is transmitted according to the CPC standard.

Category LAR settings

LAR allow (H.323) – make a list of H.323 disconnect codes that are expected to trigger further routing for the call to the next availbale route. Codes are defined individually or in ranges, and are delimited with “;”.

LAR deny (H.323) – make a list of H.323 disconnect codes that will prevent further routing for the call. Codecs are defined individually or in ranges, and are delimited with “;”. Disallowed codes override the allowed ones.

LAR allow (SIP) – make a list of SIP disconnect codes that are expected to trigger further routing for the call to the next availbale route. Codes are defined individually or in ranges, and are delimited with “;”.

LAR deny (SIP) – make a list of SIP disconnect codes that will prevent further routing for the call. Codes are defined individually or in ranges, and are delimited with “;”. Disallowed codes override the allowed ones.

LAR allow (TS) – make a list of TS disconnect codes that are expected to trigger further routing for the call to the next availbale route. Codes are defined individually or in ranges, and are delimited with “;”.

LAR deny (TS) – make a list of TS disconnect codes that will prevent further routing for the call. Codes are defined individually or in ranges, and are delimited with “;”. Disallowed codes override the allowed ones.

http://tools.ietf.org/html/draft-mahy-iptel-cpc-06

Operating TM

MVTS Pro 1.5.0-40

p. 82 of 197

LAR allow (TM) – make a list of TM disconnect codes that are expected to trigger further routing for the call to the next availbale route. Codes are defined individually or in ranges, and are delimited with “;”.

LAR deny (TM) – make a list of TM disconnect codes that will prevent further routing for the call. Codes are defined individually or in ranges, and are delimited with “;”. Disallowed codes override the allowed ones.

Category RADIUS

RADIUS username – enter the username to be included into the packets sent to the RADIUS server in cases when the device being configured originates calls. By default for static gateways MVTS Pro uses the IP address of the call origin. The string $ani$ in the field is replaced with the outgoing SRC number. The $ani$ metasymbol is invalid, if the gateway registers with the System.

RADIUS password – enter the password to be included into the packets sent to the RADIUS server in cases when the device being configured originates calls. By default for static gateways MVTS Pro uses the “xpgk” string.

Enable RADIUS authentication – select the checkbox to send device authentication requests to the RADIUS-server. The checkbox is invalid if the gateway does not register with the System.

Enable RADIUS authorization – select the checkbox to send call authorization requests to the RADIUS-server.

Enable RADIUS accounting – select the checkbox to send billing and accounting information to RADIUS-server.

Category Redial settings

Term. call retries – define the maximum number of redial attempts.

Term. retry interval, sec – define the interval between redial attempts in second.

Redial codes (H.323) – make a list of H.323 disconnect codes that will cause the redial procedure.

Redial codes (SIP) – make a list of SIP disconnect codes that will cause the redial procedure.

Redial codes (TM) – make a list of TM disconnect codes that will cause the redial procedure.

Redial codes (TS) – make a list of TS disconnect codes that will cause the redial procedure.

Category Gatekeeper settings

The following parameters should be used in case the device being configured is a remote gatekeeper:

Use GK – select the checkbox in case the device being configured is a gatekeeper. MVTS Pro interoperates with remote gatekeepers with the help of the ARQ/LRQ requests.

GK ID – enter the gatekeeper ID that will be used in the ARQ/LRQ requests.

GK IP address – enter the gatekeeper IP address.

Use GK alias – select the checkbox to allow the System to use the aliases received from the gatekeeper in case they differ from those sent to the gatekeeper by the System.

Use GK IP address for billing – in case you select this checkbox CDR records will include the IP address of the gatekeeper and not of the gateway through which the call was actually terminated.

Operating TM

MVTS Pro 1.5.0-40

p. 83 of 197

Category Default gateway settings

The parameters are valid only if the Default gateway option is selected in the Equipment type combobox. For further information about the default gateways see Appendix C. Default gateways.

Default gateway precedence – a positive integer that defines the default gateway preference over the other default gateways configured in the System. At every instance of time the System interoperates with one default gateway of the highest priority only. Should such gateway be inaccessible, the System switches to the default gateway with the next preference value. (the greater the precedence integer is, the greater is preference).

Allowed registration username patterns – regular expression, that defines registration names of devices allowed to register to the System through the default gateway. Use semicolons to delimiter individual elements if you enter a list of regexp name patterns.

Disallowed registration username patterns – regular expression, that sets a pattern for names of devices disallowed to register to the System through the default gateway. Use semicolons to delimiter individual elements if you enter a list of regexp name patterns

* Phone numbers source – select the source of DST numbers, associated with the termination equipment:

• RADIUS only – use the DST numbers received from the RADIUS server. The numbers received from the equipment as part of the registration request are ignored.

• Equipment if no numbers from RADIUS – if the System does not receive the DST numbers from the equipment, use the numbers received from the RADIUS server.

• RADIUS if no numbers from equipment – if the System does not receive the DST numbers from the RADIUS server, use the numbers received from the equipment.

Category Miscellaneous

ACM No Indication reaction – defines the System reaction on receipt of the ACM message with DC=00 and I=1. The parameter is valid if the gateway uses the SS7 protocol.

Common capacity for incom. and outgoing calls – select the checkbox to sum the maximum possible incoming and outgoing calls when calculating the available capacity of the gateway. If the checkbox is deselected, the available capacity of the gateway is calculated separately for incoming and outgoing calls.

SIP Query gateway – select the checkbox to allow MVTS Pro to monitor the serviceability of SIP gateways by periodically sending them the OPTIONS request as long as the gateways are handling calls.

SIP Gateway query interval, msec – define the interval between repetitive OPTIONS requests (in milliseconds).

H.323 TCP connect timeout, sec – use this parameter to set tcp-connect wait time. A failure to establish an H.225 session within the specified time results in call disconnection.

ENUM - The list of configured ENUM servers is in the left window (see section 6.8.5). Select an ENUM server intended for use as an external routing means and move the selection to the right window by clicking the right-arrow button . To remove a server from the list of ENUM routers in the right-hand window, select the appropriate server name and click the left-arrow button . Holding down a Shift or a Ctrl key allows you to select

several servers at once. Use the and buttons to move all records from the right box to the left one and vice versa.

By shifting the servers names up and down in the list, using the and ,

Operating TM

MVTS Pro 1.5.0-40

p. 84 of 197

buttons, you can change the ENUM-server query order. If the first server in the list is not available, the next server will be queried, till the system finds an available server to be used for external routing.

The ENUM server selection tool is valid only when the ENUM server option is selected from the Equipment type combobox.

Flags – this parameter allows configuration of the gateway functional peculiarities. The parameter value is a bit mask defined by a hexadecimal number. Possible values include:

- 0x0001 – always send SIP response 180, as the device is incapable of digesting SIP response 183.

- 0x0002 – send DTMF as INFO rather than according to RFC2833.

- 0x0004 – device is capable of fax transmission under the codec G.711.

- 0x0008 – obsolete H.323 device (Vocaltec) requiring CISCO behavior emulation.

- 0x0010 – forcefully disable RBT emulation after the receipt of repeated Alerting.

- 0x0020 – send SDP in SIP response 180, not 183.

- 0x0040 – forcefully repacketize media to ensure the required frame-per-packet ratio even if the codecs coincide on both call legs.

When through with filling out the form, click the OK button to add the new record to the table. To edit or delete a record from the table, select the appropriate command on the pop-up menu.

6.2.2. ZONES The table Zones presents information about IP and SIGTRAN zones involved in TS call routing. For more detail on the intent of IP zones refer to section 3).

Fig. 50 Table of configured zones

To add a new zone record, invoke the pop-up menu and select Add.

Fig. 51 Add zone dialog box

Enter the following data in the displayed dialog. The fields marked with an asterisk are required fields.

Operating TM

MVTS Pro 1.5.0-40

p. 85 of 197

* ID – enter the name of the IP zone as it is defined in the TS configuration file, section zones, or enter the name of the SIGTRAN zone as it is defined in the SIGTRAN interoperation node configuration file, section ss7zone.

Note: It is mandatory that the IDs of zones in the web-interface are identical to their names in the system configuration files.

* Zone name – type in the zone’s name that will be displayed in other GUI objects, for example, in the object Equipment.

Description – you can use this text box to enter whatever explanatory information you find appropriate.

Click OK to add the record to the table. To edit or delete a record, invoke the pop-up menu and select the necessary command.

6.2.3. CODEC GROUPS The table Codec groups keeps information about codec groups configured in the DB. This information is used for configuration of equipment the System interoperates with.

Fig. 52 Table “Codec groups”

To create a new group, invoke the pop-up menu and select Add.

Fig. 53 Adding a codec group

Enter the following data in the displayed dialog. The fields marked with an asterisk are required fields.

* Codec group name – enter the name of the group.

Description – you can enter any information pertaining to the group being configured in this field.

When done, click the OK button. The newly added record is assigned an automatically generated ID. To edit or delete a record, invoke the pop-up menu and select the necessary option.

Your next step is to configure codecs that make up the group (see section 6.2.4)

6.2.4. CODEC GROUP SETUP The table Codec group setup presents a general view of available codec groups and their make up.

Operating TM

MVTS Pro 1.5.0-40

p. 86 of 197

Use this table to change codec groups make up and configure other codecs’ essential parameters.

Fig. 54 Table of codecs

To add a codec to the group, left-click the mouse on a table record and select Add in the pop-up menu.

Fig. 55 Configuring codec groups

Enter the following data in the displayed dialog (the fields marked with an asterisk are required fields):

* Codec group – specify the group the codec will be related to using the drop-down list of this combo box (the drop-down list is populated with the names of groups from the table Codec groups, see 6.2.3).

* Codec – specify the codec using the drop-down list of this combo box.

Voice auto detection – select this check box if the codec provides built-in voice activity detection (VAD).

Precedence in group – this parameter allows the operator to define the codec precedence in the list of codecs sent to Traffic Switch. By default all codecs are assigned the precedence value “1”. The greater the precedence value is the higher is precedence.

Category Advanced settings

Operating TM

MVTS Pro 1.5.0-40

p. 87 of 197

Frames per packet – specify the number of frames per packet transmitted when the codec is in use.

Preferred dynamic payload type – specify a preferred payload type by entering a positive integer in the range of 96 through 127.

Flags – this parameter helps configure operation when the Speex codec is used. The parameter value is a bit mask of the following structure:

Modes

scmMode_1 = 0x0001, scmMode_2 = 0x0002, scmMode_3 = 0x0003, scmMode_4 = 0x0004, scmMode_5 = 0x0005, scmMode_6 = 0x0006, scmMode_any = 0x0007, Penh. scmPenh_0 = 0x0000, scmPenh_1 = 0x0008, // bin 00001000 Cng. scmCng_off = 0x0000, scmCng_on = 0x0010, // bin 00010000 Vbr. scmVbr_off = 0x0000, // bin 00000000 scmVbr_on = 0x0020, // bin 00100000

For additional information on Speex parameters refer to The Speex Codec Manual.

When through with entering data, click OK to add the record to the table.

To edit or delete a record, invoke the pop-up menu and select the necessary option. In a similar fashion you can add other codecs to the groups.

6.3. TERMINATION

6.3.1. PRE-ROUTING TRANSLATIONS The object Pre-routing number transformation serves to configure number transformation rules that allow number modification with the end to assure dial peer search and route hunting.

Number transformation may involve several steps (removal of the prefix, city code etc.) which may require a number of successively applied rules. The order in which number transformation rules are applied is determined by the rule precedence.

To see if the number needs transformation, it is checked against regular expression patterns. The number is subject to transformation if it matches the pattern defined in the fields Allowed SRC numbers pattern, Allowed DST numbers pattern, Allowed SRC groups and Allowed CPC and mismatches the pattern defined in Exclude SRC numbers, Exclude DST numbers, Disallowed SRC groups and Disallowed CPC.

In addition, the object Pre-routing number transformation is used to define name transformation rules for groups of registering gateways.

http://www.speex.org/docs/manual/speex-manual.pdf

Operating TM

MVTS Pro 1.5.0-40

p. 88 of 197

Fig. 56 Table of pre-routing number transformation rules

To create a new rule, invoke the pop-up menu and select Add.

Fig. 57 Dialog box for pre-routing translation rules

Enter the following information in the displayed dialog (the parameters marked by the asterisk symbol «*», are required fields):

* Rule name – enter the rule name.

Description – you can use this text box to enter whatever information you deem pertinent.

Enable – select the check box to make the rule effective.

Operating TM

MVTS Pro 1.5.0-40

p. 89 of 197

* Precedence – specify the rule precedence entering a positive integer in this field. The greater the entered value, the more precedence the configured rule takes. The precedence of rules defines the order in which number transformation rules are applied. Rules with a greater Precedence value are applied earlier. The list of configured rules is browsed by the system successively which means that prior to performing a DP search (route hunting) the system applies the number transformation rules one by one in the order of their precedence.

Allowed SRC numbers pattern – enter a regular expression that determines what calling numbers require transformation. You can enter several regular expressions delimiting them with «|».

Allowed DST numbers pattern – enter a regular expression that determines what called numbers require transformation. You can enter several regular expressions delimiting them with «|».

Exclude SRC numbers – enter a regular expression that determines what calling numbers do not require transformation. You can enter several regular expressions delimiting them with «|». Disallowed numbers override the allowed ones.

Exclude DST numbers – enter a regular expression that determines what called numbers do not require transformation. You can enter several regular expressions delimiting them with «|». Disallowed numbers override the allowed ones.

Allowed SRC groups – enter the name of the call origination RAS-user group that needs transformation. You can enter several names delimiting them with «;».

Disallowed SRC groups – enter the name of the call origination RAS-user group not subject to transformation. You can enter several names delimiting them with «;». Disallowed groups override the allowed ones.

SRC number translation – enter a regular expression for transformation of the calling number.

SRC number translation (billing) – enter regular expressions for modification of calling numbers as required for the purposes of billing.

DST number translation – enter a regular expression allowing the transformation of the called number.

DST number translation (billing) – enter regular expressions for modification of called numbers as required for the purposes of billing.

SRC number translation (SORM) – enter a regular expression pattern for transformation of the calling number to be sent to a SORM-gateway.

DST number translation (SORM) - enter a regular expression for transformation of the called number to be sent to a SORM-gateway.

Group name translation – enter a regular expression for transformation of the group name.

Allowed CPC - enter a list of calling party’s categories that determines what calls require transformation.

Disallowed CPC – enter a list of calling party’s categories that determines what calls do not require transformation. Disallowed categories override the allowed ones.

CPC translation – select the category which replaces the CPC in the call, if the call matches this translation rule. If you want to leave the CPC unchanged, select the blank option.

* Action – use the combo box to select a required post-transformation action:

Next. Next means a transition to the next number transformation rule if any.

Stop. Stop means stoppage of the transformation process and call abortion with the local disconnect code configured in the field Quit with disconnect code. If no code is selected in the field Quit with disconnect code, the translation process stops, though the call handling process continues.

Operating TM

MVTS Pro 1.5.0-40

p. 90 of 197

Again. Again means re-start of the same transformation but applied to the number or group name obtained as the result of the just performed transformation. The re-started transformation is a recursive procedure applied to the result of the previous iteration.

Quit with disconnect code – use this combo box to select a disconnect code that the System will provide when aborting a call in response to the * Action option Stop.

Note: This parameter is valid only when the option Stop is selected in the field * Action

When done with entering data, press the button OK to add the configured record to the table. The System will generate a unique ID for the record displaying it in the respective column of the table.

To view, edit or delete a table record, select the appropriate item on the pop-up menu.

6.3.2. DIAL PEERS In terms of MVTS Pro a dial peer is an addressable object characterized by the name of termination gateway, operating time, and number transformation rules.

Therefore, the table of dial peers (see Fig. 58) can be regarded as a dial plan comprised of records with information about possible routing paths for calls originated by static gateways and RAS users.

Fig. 58 Table of DPs

While handling a call, the system searches for the best routing path taking into account the length of the matching number prefix and the dial peer precedence. The record of the dial peer selected during route hunting provides information necessary for call set up.

Of two dial peers with equal length of the matching calling number prefix the one with a greater value of the parameter * Precedence takes precedence over the other. If the values of the parameter Precedence for the two DPs are equal as well, the dial peer is selected at random.

To add a dial peer record, invoke the pop-up menu and select Add.

Operating TM

MVTS Pro 1.5.0-40

p. 91 of 197

Fig. 59 Add dial peer dialog

Enter the necessary data in the fields of the displayed form (the asterisk symbol marks the required parameters):

Enabled – select the checkbox to make the record valid.

* Name – enter the DP name.

Description – use this text box to provide whatever information or comments concerning the record that you believe pertinent.

Precedence – enter a positive integer that determines the DP precedence over other suitable for the call. The integer may be any number in the range of 0 through 65535. A greater number means greater precedence.

Routing policy – select the routing policy applied to the dial peer. For further information on routing policies see Section 6.3.3.

* DST prefix allow patterns – use a regular expression to enter a pattern for destination number prefixes allowed for the DP. When entering several expressions delimit them with semicolons.

Upon completion of the dial peer configuration, the System forms a tree of destination number patterns. Each pattern node of the tree is associated with dial peers, where this pattern is used. Suppose 9 dial peers (dp0 - dp8) are configured in the System. The tree of destination number prefix patterns may then look as shown in Fig. 60.

Operating TM

MVTS Pro 1.5.0-40

p. 92 of 197

Fig. 60 Example of destination number regexp patterns tree

DST prefix deny patterns – use these fields to enter regular expressions that define called numbers disallowed to use the DP. You can enter several expressions delimiting them with «|». Disallowed numbers override the allowed ones.

* Equipment list – make a list of gateways available for use when the DP is selected for call termination. To add a gateway to the list, select its name in the left window pane and click

to move the GW name to the right window. To remove a gateway from the list,

highlight its name in the right window pane and click . The buttons and

serve to move all records between the windows in one click. Use the buttons

and to move the gateway name one line up or down in the list.

If the Balancing method parameter is set to No balancing, MVTS Pro attempts to set up a call sequentially starting with the first gateway on the list during routing procedure. Otherwise, the order, in which the System establishes a connection with the gateways, is determined by the Balancing method.

Balancing method – use the combo box to select a method of load balancing that the System will use when distributing traffic between multiple gateways of the dial peer being configured. The available options include:

- No balancing means no call balancing by whatever criterion.

- Round-robin balancing means that every new call is forwarded to the next gateway in turn.

- Balancing by absolute load means that every new call is forwarded to the gateway that currently handles the least number of calls.

- Balancing by load-to-capacity ratio means that every new call will be sent to the gateway that currently displays the least ratio of ongoing calls to gateway capacity.

Capacity group – select the name of the common capacity group from the drop-down list. The gateway will belong to the selected capacity group. For more information about capacity groups see Section 6.8.11.

Capacity – specify the maximum number of simultaneous calls that the DP can handle.

Enable statistics – when selected, this checkbox enables call statistics keeping for the DP, the data of which can be later used in graph plotting.

Valid from – specify a start date of the record validity period.

Valid till – specify an end date of the record validity period.

Category Number translation rules

Operating TM

MVTS Pro 1.5.0-40

p. 93 of 197

SRC number translation/DST number translation – enter regular expressions for desired modification of calling and called numbers respectively.

SRC number translation (billing)/DST number translation (billing) – enter regular expressions for modification of calling and called numbers as required for the purposes of billing.

Category Advanced settings

Allowed SRC number patterns – use a regular expression to enter a pattern for calling number prefixes suitable for this DP. You can enter several expressions delimiting them with «|».

Denied SRC number patterns – use these fields to enter regular expressions that define calling numbers disallowed to use the DP. You can enter several expressions delimiting them with «|». Disallowed numbers override the allowed ones.

Allowed SRC groups – enter names of the gateway groups that are allowed call origination.

Disallowed SRC groups – enter names of the gateway groups that are disallowed call origination. Disallowed groups override the allowed ones.

Stop route hunting after this DP – set the checkbox to reduce the number dial peers selected through exclusion of upper levels of regexp pattern tree from tree traversal.

Suppose, a dp2 from Fig. 60 has the Stop route hunting after this DP checkbox selected. In situations when the call destination number is, say, 7910792543, the System will exclude from the route hunting procedure not only dp5, dp7 and dp8 (as regexp number patterns not matching the number), but also dp0 (as a matching pattern on a preceding tree level).

Override equipment proxy mode – this combo box allows you to override the proxying settings of the terminator for situations when MVTS Pro interoperates with the DP being configured. The available media proxy options include:




If the empty line is selected, media proxy settings of the termination gateway will be applied.

Allowed CPC - enter a list of calling party’s categories that determines what calls will be routed to this DP.

Disallowed CPC – enter a list of calling party’s categories that determines what calls will not be routed to this DP. Disallowed categories override the allowed ones.

Operating TM

MVTS Pro 1.5.0-40

p. 94 of 197

CPC translation – select the category which replaces the CPC in the call, if the call is routed to this DP. If you want to leave the CPC unchanged, select the blank option.

Override report original destination – select the method of reporting the original DST number for this dial peer. If you do not want to override the method, select the blank option.

Allowed SRC types of numbers – enter a list of SRC number types (NAI) that determines what calls will be routed to this DP.

Disallowed SRC types of numbers – enter a list of SRC number types that determines what calls will not be routed to this DP. Disallowed categories override the allowed ones.

Allowed DST types of numbers – enter a list of DST number types (NAI) that determines what calls will be routed to this DP.

Disallowed DST types of numbers – enter a list of DST number types that determines what calls will not be routed to this DP. Disallowed categories override the allowed ones.

Override equipment SRC type of number – select the type of number which replaces the SRC number type of the call, if the call is routed to this DP. If you want to leave the SRC number type unchanged, select the blank option.

Allowed SRC screening indicators – enter a list of SRC screening indicators that determines what calls will be routed to this DP.

Disallowed SRC screening indicators – enter a list of SRC screening indicators that determines what calls will not be routed to this DP. Disallowed categories override the allowed ones.

Override equipment SRC screening indicator – select the screening indicator value which replaces the SRC screening indicator of the call, if the call is routed to this DP. If you want to leave the SRC screening indicator unchanged, select the blank option.

Override equipment SRC numbering plan – select the numbering plan which replaces the SRC numbering plan of the call, if the call is routed to this DP. If you want to leave the SRC numbering plan unchanged, select the blank option.

Override equipment DST numbering plan – select the numbering plan which replaces the DST numbering plan of the call, if the call is routed to this DP. If you want to leave the DST numbering plan unchanged, select the blank option.

Override equipment SRC presentation indicator – select the presentation indicator value which replaces the SRC presentation indicator of the call, if the call is routed to this DP. If you want to leave the SRC presentation indicator unchanged, select the blank option.

Category Schedule

* Scheduling – specify the DP’s activity period. Possible options include:

No schedule – disables the DP availability scheduling.

Time of day - schedule the DP according the time of day.

Mon-Fri – the DP is active on workdays only.

Sat-Sun - the DP is active on weekends only.

Day of week - schedule the DP according to the time of day and day of the week.

Day of month - schedule the DP according to the time of day and day of the month.

Day of year - schedule the DP according to the time of day and day of year.

When the Time of day, Day of week or Day of year options are selected, the following parameters come into effect:

If the Time of day option is selected:

Operating TM

MVTS Pro 1.5.0-40

p. 95 of 197

Time of day – on – specifies the starting time of the DP activity period.

Time of day – off – specifies the ending time of the DP activity period.

If the Day of week option is selected:

Day of week – on – specifies the day of the week and time when the DP activity period starts.

Day of week – off – specifies the day of the week and time when the DP activity period ends.

If the Day of month option is selected:

Day of month – on – specifies the day of the month and time when the DP activity period starts.

Day of month – off – specifies the day of the month and time when the DP activity period ends.

When the Day of year option is selected:

Day of year - on - specify the starting date and time of the DP activity period.

Day of year - off - specify the ending date and time of the DP activity period.

If you enter some values in the Hour online and Hour offline parameters, but select an option other than Daily in the Scheduling combobox, the Hour online and Hour offline parameters will define the period of the DP intraday activity. In this case only overlapping intraday intervals are considered. For example, with the following parameters specified:

Scheduling Weekly

Hour online 9:00

Hour offline 21:00

DoW online Mon 10:00

DoW offline Thu 22:00

The dial peer will be active every day from Monday till Thursday from 10:00 till 21:00.

Press the ОК button, when through with data entering,. The newly configured DP record will be added to the table of DPs with a unique ID generated by the System and the record creation date displayed in the column Timestamp.

To edit, view or delete a record, select the respective item in the pop-up menu.

6.3.3. ROUTING POLICIES The table “Routing policies” presents a list of route hunting policies based on statistical data for dial peers.

Fig. 61 Table with a list of available routing policies

Operating TM

MVTS Pro 1.5.0-40

p. 96 of 197

Policy routing, as implemented in the MVTS Pro system, is based on statistical data that characterize the path the call will take to get to its final destination.

The MVTS Pro standard route hunting is based on the destination number of the call. The softswitch selects several dial peers the regexp destination number patterns of which match the destination number of the routed call and sorts the selected path alternatives by the degree to which the destination number pattern matches the called number. As a result DPs with the destination number pattern best matching the destination number of the call are in the beginning of the sorted list.

When it is necessary to take into account additional properties of a potential route the list of selected dial peers is additionally sorted by the numerical value that reflects the statistics taken into account (ASR or PDD, for example).

Therefore, to define a statistics-based routing policy means to define a statistical parameter by which the list of potential routing paths will be additionally sorted.

The list of statistical parameters that can be used in policy routing and their symbolic representations is given in Table 6.

Table 6 Symbolic representation of statistical data used in configuring routing policies.

Symbolic representation Parameter

priority DP precedence setting

qos Quality of service. MVTS Pro calculates QoS as a ratio of packets lost to total packets transferred, i.e. the smaller is the calculated QoS value, the better is QoS.

pdd Post Dial Delay. MVTS Pro calculates PDD as the time interval between the receipt of SETUP from the originator and the moment the ALERT, CONNECT or ProgressIndicator = 8 (i.e. ProgressInbandInformationAvailable) is received from the terminating party.

asr Standard or conventional ASR (answer seizure ratio). The standard ASR is calculated as the ratio of the total number of non-zero duration calls to total number of calls

acd Average Call Duration.

scd SETUP-CONNECT Delay. The stretch of time between the SETUP and CONNECT message or call teardown in the absence of CONNECT.

cps Calls per Second..

maxActCalls Peak number of active calls

totalCallsDuration Aggregate duration of all calls

normalCalls Number of successful calls

failedCalls Number of failed calls

totalCalls Aggregate number of all calls

outBytes Total number of bytes sent during all calls

inBytes Total number of bytes received during all calls

actCalls Number of active calls

Operating TM

MVTS Pro 1.5.0-40

p. 97 of 197

To define a routing policy right-click the mouse to invoke the contextual menu and select Add. Fill out the displayed form (see Fig. 62) entering the policy name in the edit box * Name and an expression that returns a numerical value for the policy in the edit box * Expression.

The values that you enter in the field * Expression must conform to the format <dp.parameter_name> where parameter_name is one of the symbolic representations from Table 6. Expressions enterd in the field * Expression must be a valid expression of the programming language Python. For example, the ASR-based rouing policy is defined by entering dp.asr in the field * Expression while the routing policy based on total number of sent and received bytes for all calls can be defined by the expression dp.inBytes + dp.outBytes.

Fig. 62 Routing policy form

The table “Routing policies” allows verification of entered expressions. Press the Check expression button appearing to the right of the just entered value to see if the expression is a valid one. A successful validation results in the the expression font changing to green and the validity flag Yes appearing next to the expression.

Fig. 63 Mistyped expression requiring a validity check

To correct a mistyped expression switch to edit mode, make the necessary correction and press the Check expression button again.

Fig. 64 Corrected expression after validity check

Operating TM

MVTS Pro 1.5.0-40

p. 98 of 197

6.4. DEBUGGING

The category of objects Debugging comprises four tables – the table Call simulation, the table Debug registration, the table Debug calls and the table Debug call logs.

6.4.1. CALL SIMULATION The object Call simulation allows you to simulate calls with the end to check the System configuration and during troubleshooting in situations when customers or partners complain of improper System functioning.

Fig. 65 Call simulation dialog

To simulate a call enter the following parameters in the Call simulation dialog (Fig. 65):

* Scripting node – select the scripting node, which will be used to simulate the call.

Zone – if the SS7 protocol is used to simulate the call, select the zone which acts as an originator’s address. In case of other protocols this combo box is invalid.

Operating TM

MVTS Pro 1.5.0-40

p. 99 of 197

SRC protocol - select the signaling protocol from the dropdown list.

* Orig. IP address - specify the IP address of the origination gateway.

SRC number and * DST number - enter a calling and called number in respective edit boxes.

Orig. NAT address - specify the NAT address, if the origination device sits behind NAT.

SRC codecs – by moving codec names from the left window to the right, define the list of codecs used by the call originator.

Calling party’s category – select the calling party’s category as if it were present in the incoming leg.

Press OK.

Fig. 66 Call simulation results

Results of the call simulation will be displayed in the field Routes (Fig. 66).

6.4.2. DEBUG CALLS

The table Debug calls presents a list of call logs for origination or termination gateways that had the debug logging checkbox selected during configuration.

To view an individual call log record, select the View item on the pop-up menu.

Operating TM

MVTS Pro 1.5.0-40

p. 100 of 197

Fig. 67 Call progress log header when viewed from table Debug calls

The parameters of the debug call are identical to those present in the CDR table (see Section 6.5.4).

ID – unique ID of the record.

Incoming SRC number – calling number as received from the call source.

Incoming DST number – destination number as received from the call source.

Outgoing SRC number – calling number after transformation according to the configured number translation rules (see 5Appendix A. Metacharacters, regular expressions and number transformation).

Outgoing DST number – destination number after transformation according to the configured number translation rules (see 5Appendix A. Metacharacters, regular expressions and number transformation).

Remote SRC signaling address – signaling IP address and port of the call originator.

Remote DST signaling address – signaling IP address and port of the call terminator.

Setup time – timestamp of the call setup.

Conference ID – unique identifier of the conference the call was a party to. (conference = incoming call leg + outgoing call leg).

To view the call log of interest invoke the pop-up menu and select the Get call log item in the Special function section.

Operating TM

MVTS Pro 1.5.0-40

p. 101 of 197

Fig. 68 Invoking the call log for viewing

You will be displayed the call log page that presents the call log header as in Fig. 67 followed by a table of packets exchanged during the call (see Fig. 69)

Operating TM

MVTS Pro 1.5.0-40

p. 102 of 197

Fig. 69 Call progress log view

Click the Expand all control to spread out the list of packets and examine their contents in

detail. Use the partial expansion control when you intend to view a small portion of the packet rather than spread out the entire packet.

Fig. 70 Using partial expansion control for contents viewing

6.4.3. DEBUG REGISTRATIONS The table Debug registrations contains records about debug registrations of regestering equipment.

Operating TM

MVTS Pro 1.5.0-40

p. 103 of 197

The maximum number of records in the tables is defined by the global setting Max. debug call/registration sessions (см.6.8.1)

If the number of entries is large, use a filter to find necessary records.

ID – unique ID of the record.

Registration username – login of the registered device.

Phone number – name/number/alias of the registered device.

Signaling address – originator’s IP address, used for signaling.

Signaling protocol - protocol used by the registered device.

Registration time – date and time of the registration.

Registration ID – TS registration ID.

Operating TM

MVTS Pro 1.5.0-40

p. 104 of 197

6.5. TRAFFIC SWITCH

This subcategory of objects allows real-time monitoring of the System operation and provides information about equipment registrations, currently handled calls, system sockets, etc. The operator can view summarized information or detailed information about the operation status of every System component.

6.5.1. ACTIVE CALLS The table Active calls contains information about calls currently handled by the system.

Each record provides the following data:

Connect time – timestamp of the call connect.

In-call time – call duration in milliseconds.

Incoming leg call ID – call ID on the incoming leg.


Incoming leg protocol – signaling protocol used on the incoming call leg.



Outgoing leg call ID – call ID on the outgoing leg.


Outgoing leg protocol – signaling protocol used on the outgoing call leg.

Outgoing SRC number – calling number after transformation according to the configured number translation rules.

Outgoing DST number – destination number after transformation done according to the configured number translation rules.

6.5.2. REGISTRATIONS

This table displays data on equipment registered with MVTS Pro.

Operating TM

MVTS Pro 1.5.0-40

p. 105 of 197

The records in the table Registrations include the following data:

Username – name of the registered device.

Address – IP address of the registered device.

State – registration status:

- Initial (the registration process has started, but not yet completed).

- Passed (registration completed, the gateway is registered).

- Suspended (complete re-registration of the devices is pending).

- Unknown (gateway registration status is unknown).

- Unregistering (gateway is unregistering).

TTL, sec – interval between complete re-registrations (time-to-live).

Aliases – names/numbers received in registration data.

Expiration – time of registration expiration.

Registration ID – the unique registration ID assigned by the TS.

6.5.3. ACTIVE NODES The table Active nodes comprises the names of all active nodes in the system (column Name) and their uptime (column Uptime).

6.5.4. NODES This subcategory provides detailed information about operation status of the TS nodes distributed by separate subcategories. The number of subcategories depends on the number of the running nodes. The names of the subcategories correspond to the names of the nodes configured in the TS configuration file(-s).

For brevity sake let us consider a system with one module of each type running (imaginary names of modules are in angle brackets). All modules have the following objects:

• IP zones - sockets that are open on the node.

• Protocols - protocols used to connect this node with others.

• Counters – information about system counters.

The object IP zones includes the following information:

• Remote node – name of the remote node, to which this node is connected.

• Zone - shows the name of IP zone to which the open socket belongs. Zones are configured in system.conf.

• Local address – IP address of the local socket, which establishes a remote connection.

Operating TM

MVTS Pro 1.5.0-40

p. 106 of 197

• Remote address – IP address of the remote socket, receiving connection from the locally connected socket. If the remote address is 0.0.0.0, this means that the local socket is waiting for an incoming connection.

The object Protocols includes the following information:

• Protocol - the name of protocol under which the node operates

• Local address – IP address of the local socket, which establishes a remote connection.

• Remote address – IP address of the remote socket, receiving connection from the locally connected socket. If the remote address is 0.0.0.0, this means that the local socket is waiting for an incoming connection.

The object Counters includes the following information:

• Name – the name of the system counter.

• Value – the value of the system counter.

<Management>

This sub-directory includes the objects IP zones, Protocols and Counters that deliver statistical information pertaining to the Management node.

<Signaling>

This object provides statistical information about the signaling node. In addition to the common objects IP zones, Protocols and Counters it shows data about calls handled by the node (in the table Calls).

<H323_GK>

This object is a repository of statistical information about the Н.323 gatekeeper/balancer module. Apart from the common objects IP zones, Protocols and Counters, the object includes the table Registrations showing information about registered devices.

<SIP_registrar>

This object is a repository of statistical information about the SIP registrar/balancer module. Apart from the common objects IP zones, Protocols and Counters, the object includes the table Registrations showing information about registered SIP devices.

<Media>

This folder contains operational statistics pertaining to the Media node and includes the objects IP zones, Protocols and Counters.

<Scripting>

This folder contains operational statistics pertaining to the Scripting node and includes the objects IP zones, Protocols and Counters.

<Synchro>

This folder displays the Synchro node operational statistics contained in the objects IP zones, Protocols and Counters.

Operating TM

MVTS Pro 1.5.0-40

p. 107 of 197

<SS7-node>

This folder contains operational statistics pertaining to the SIGTRAN interoperation node and includes the common objects IP zones, Protocols and Counters.

6.5.5. SS7 CALLS This table comprises the information about the SS7 calls, passing through a SIGTRAN interoperation node.

Each record includes the following fields:

Fig. 71 SS7 calls

Call ID – unique identifier of the call.

Conference ID – unique identifier of the conference the call was a party to (conference = incoming call leg + outgoing call leg).

Calling Party ID – ID of the calling party.

Called Party ID – ID of the called party.

Circuit ID – ID of the media circuit in an E1 trunk in the form of <hw_id>-<span_id>-<timeslot>, where <hw_id> - media gateway ID, to which the E1 circuits are connected, <span_id> - ID of an E1 trunk as part of the ISUP connection, <timeslot> - timeslot of in the E1 trunk.

Circuit group ID – ID of a circuit group, to which the current media circuit belongs.

SIGTRAN zone – a SIGTRAN zone to which the call (call leg) belongs.

6.5.6. ISUP CIRCUITS This table comprises the information about the state of media circuit, which a part of an ISUP connection.


Operating TM

MVTS Pro 1.5.0-40

p. 108 of 197

Fig. 72 ISUP circuits



Circuit ID – ID of the media circuit in an E1 trunk in the form of <hw_id>-<span_id>-<timeslot>, where <hw_id> - media gateway ID, to which the E1 circuits are connected, <span_id> - ID of an E1 trunk as part of the ISUP connection, <timeslot> - timeslot of in the E1 trunk.

Circuit group ID – ID of a circuit group, to which the current media circuit belongs.

ISUP circuit label – circuit label in the form <LPC>-<RPC>-<cic>-<ni>, where <LPC> - local point code, <RPC> - remote point code, <cic> - media circuit code, <ni> - network indicator code.

Incoming connection – shows if the circuit is used for incoming traffic.

Outgoing connection – shows if the circuit is used for outgoing traffic.

Circuit state – current state of the circuit.

Local circuit block state (maintenance) – state of the local media circuit block of type maintenance oriented.

Local circuit block state (hardware) – state of the local media circuit block of type hardware oriented.

Remote circuit block state (maintenance) – state of the remote media circuit block of type maintenance oriented.

Remote circuit block state (maintenance) – state of the remote media circuit block of type hardware oriented.

To change the state of the circuit invoke the pop-up menu on the required record and select the desired procedure. Available procedures:

• Block – locally blocks the circuit using the maintenance oriented block type.

• Unblock – locally unblocks the circuit using the maintenance oriented block type.

Operating TM

MVTS Pro 1.5.0-40

p. 109 of 197

• Reset state – sets the circuit state to Idle and sends to a remote SS7 switch a Reset Circuits messages.

6.5.7. MGCP ENDPOINTS This table comprises the information about the MGCP endpoints.


Fig. 73 MGCP endpoints

SIGTRAN media gateway ID – ID of the MGCP gateway.

E1 trunk ID – ID of the E1 trunk, connected to the media gateway.

Endpoint ID – ID of the MGCP endpoint.

Endpoint state – state of the MGCP endpoint.

Endpoint name – name of the MGCP endpoint.


6.5.8. M3UA EDPOINTS This table comprises the information about the MGCP endpoints.


Fig. 74 M3UA endpoints

Endpoint ID – ID of the SCTP endpoint.

IP addresses – a list of IP addresses associated with the SCTP endpoint.

Port – port of the SCTP endpoint.

Endpoint type – type of the endpoint;

Operating TM

MVTS Pro 1.5.0-40

p. 110 of 197

6.5.9. M3UA ASSOCIATIONS This table comprises the information about the M3UA SCTP associations.


Fig. 75 M3UA associations

M3UA association ID – ID of the M3UA SCTP association.

Association status – status of the SCTP-association.

Local endpoint ID – ID of the local SCTP endpoint.

Remote endpoint ID – ID of the remote SCTP-endpoint.

Number of incoming SCTP-streams – number of incoming SCTP streams.

Number of outgoing SCTP-streams – number of outgoing SCTP streams.

6.6. CDRS

The subcategory CDRs includes six tables that display call detail records (CDRs) used in metering and billing.

In the table Last 1000 CDRs only the last 1000 call detail records are stored, which can decrease interface latency in case of a large DB.

The table Doubtful comprises CDRs with a missing or wrong date of creation.

Operating TM

MVTS Pro 1.5.0-40

p. 111 of 197

Note: When the free space in the DB and on the local HDD is exhausted, the System stops handling calls. To avoid such a situation, remove obsolete CDRs from the DB. A method to remove CDRs from the database is described in Appendix F. Removing CDRs from the DB.

Select View from the pop-up menu to conveniently view the required CDR. You can also use the pop-up menu to export the table data into a CSV-file (see section 5.2.7).

Fig. 76 Viewing a CDR record

CDRs may contain the following information:

ID – the unique identifier of the record.

CDR date – date of the record creation.

Note: The value of CDR date field depends on the Value for "Date" field in CDR: 1 - Setup time, 2 - Disconnect time parameter in the Global settings object. If the parameter is equal to 1, then value of CDR date means the setup time of the call; if it is equal to 2, the value of CDR date means the disconnect time of the call.



Outgoing SRC number – calling number after transformation according to the configured number translation rules.

Outgoing DST number – destination number after transformation according to the configured number translation rules.

Billing SRC number – calling number used for the purposes of billing.

Billing DST number – destination number used for the purposes of billing.

Signalling node – name of the signaling node that handled the call.

Remote SRC gatekeeper address – IP address of the originating gatekeeper.

Operating TM

MVTS Pro 1.5.0-40

p. 112 of 197



Remote SRC media address – media IP address and port of the call originator.

Remote DST media address – media IP address and port of the call terminator.

Local SRC signaling address – IP address and port of the signaling node used on the incoming leg.

Local DST signaling address – IP address and port of the signaling node used on the outgoing leg.

Local SRC media address – IP address and port of the media node used on the incoming leg.

Local DST media address – IP address and port of the media node used on the outgoing leg.

Incoming leg protocol – signaling protocol of the incoming leg.

Outgoing leg protocol – signaling protocol of the outgoing leg.


Incoming leg call ID – call ID on the incoming leg.

Outgoing leg call ID – call ID on the outgoing leg.

SRC RAS username – RAS username of the call originator.

DST RAS username – RAS username of the call terminator.

RADIUS username – username sent to the external RADIUS server.

Origination gateway – name of the origination gateway.

Termination gateway – name of the termination gateway.

Dial peer – name of the dial peer.

In-call time, msec – call duration in milliseconds.

Setup time – timestamp of the call setup.

Connect time – timestamp of the call connect.

Disconnect time – timestamp of the call disconnect.

Disconnect code – call disconnect code.

Incoming leg codecs – list of codecs received from the call originator.

Outgoing leg codecs – list of codecs received from the call terminator.

SRC Faststart present - “Yes” indicates that the origination gateway declared the use of the FastStart mechanism.

DST Faststart present – “Yes” indicates that the termination gateway accepted the use of the FastStart mechanism.

SRC Tunneling present – “Yes” indicates that the origination gateway declared the use of the tunneling mechanism.

DST Tunneling present – “Yes” indicates that the termination gateway accepted the use of the tunneling mechanism.

Proxy mode – media proxy mode.

LAR fault reason – reason for call routing interruption.

Routing retries – number of routing retries.

Operating TM

MVTS Pro 1.5.0-40

p. 113 of 197

SCD, msec – time in milliseconds that elapsed between the receipt of SETUP and CONNECT or between SETUP and ReleaseComplete (if no CONNECT was received).

PDD, msec – time interval between receipt of SETUP from the call originator and receipt of Alert or Connect or ProgressIndicator=8 (ProgressInbandInformationAvailable) from the terminating party.

SRC media bytes in – number of ingress bytes received from the call originator.

SRC media bytes out – number of egress bytes sent to the call originator.

DST media bytes in – number of ingress bytes received from the call termination party.

DST media bytes out – number of egress bytes sent to the call termination party.

SRC media packets – quantity of media packets received from the call originator.

DST media packets – quantity of media packets received from the call termination party.

SRC media packets late – number of late packets received from the call originator.

DST media packets late – number of late packets received from the call termination party.

SRC media packets lost – amount of packets not received from the call originator.

DST media packets lost – amount of packets not received from the call termination party.

SRC min. jitter buffer size (packets) – minimum jitter buffer size when receiving packets from the call originator.

SRC max. jitter buffer size (packets) – maximum jitter buffer size when receiving packets from the call originator.

DST min. jitter buffer size (packets) – minimum jitter buffer size when receiving packets from the call termination party.

DST max. jitter buffer size (packets) – maximum jitter buffer size when receiving packets from the call termination party.

Last CDR – «Yes» in this field means that this record is the last one among all records associated with the specific call.

Note: CDRs are written for all call attempts irrespective of their success, and the state of this flag gives a possibility to determine if this record should be fed into the billing system.

Q.850 Reason – disconnect reason code from the SIP Reason header. The code is received from a H.323 gateway, sitting behind a SIP device.

Incoming leg CPC – the calling party category as received by the System from the calling gateway.

Outgoing leg CPC -the calling party category sent by the System to the called gateway.

Note: When transforming the calling party category from one standard into another (e.g. CPC into OLI or vice versa), this parameter stores the category before such transformation occurs.

Pass “From” to Term. GW – the flag showing that the System sent IP address and port of the originator in the “From” field of the INVITE message. For further information see the Cancel SRC number translations; Put Orig. address in "From" parameter.

Orig. SIGTRAN zone – SIGTRAN zone from which the call originated under the SS7 protocol.

Term. SIGTRAN zone – SIGTRAN zone where the call was terminated under the SS7 protocol.

Disconnect initiator – the party which initiated call disconnect.

Diversion – the value of the diversion/RedirectingNumber field from the incoming call leg.

Operating TM

MVTS Pro 1.5.0-40

p. 114 of 197

Incoming SRC number type – incoming type of the SRC number.

Incoming DST number type – incoming type of the DST number.

Outgoing SRC number type – outgoing type of the SRC number.

Outgoing DST number type – outgoing type of the DST number.

6.6.1. CDRS SCHEDULED EXPORT The object Scheduled export in the category Export CDRs allows you to configure unattended export of call detail records by means of the cron scheduler. CDR export is possible in a plain-text and CSV file.

To configure unattended export of CDRs, open the Export CDRs form (CDRs → Scheduled export) and enter the parameters necessary for creation of a cron job (see Fig. 77).

Fig. 77 CDRs scheduled export form

The configuration parameters on the Export CDRs form have the following intent and particulars:

Enable – use this checkbox to enable/disable the scheduled CDR export function

* Export period – frequency of CDRs export. This parameter also determines the size of periodic CDRs selection for export.

* Timezone – choose the desired time zone that will be used for CDR selection during scheduled export. The System selects CDRs for export by the DB date, which may not coincide with the System date in the web-interface.

Note: Default DB time zone is UTC.

Starting date – the starting date of export.

Operating TM

MVTS Pro 1.5.0-40

p. 115 of 197

Min. age of export CDRs – shows the age of CDRs intended for export. In other words, this field shows the time difference between the cron job start time and the time indicated by the time stamp of the exported CDR in the HH::MM::SS notation.

Note: Indication of minimum CDR age is necessary to avoid export of incomplete CDRs for calls that are still under way at the time of the cron job start.

By this means, the System launches auto export with the frequency, determined by the Export period parameter, and exports non-exported CDRs, belonging to previous periods (the length of which is again determined by the same Export period parameter). CDRs with the date earlier than the value of the Date begin parameter, and CDRs falling in the interval that is fully or partially covered by the period set in the Min. age of export CDRs are not exported. If the scheduled export is configured in the following way:

Interval size = 1 hour.

Date begin = 9:00.

Min. age of export CDRs = 00:30:00 (30 minutes),

and the cron job starts at 12:00, then cron exports CDRs, starting from 10:00 till 11:00, and the non-exported CDRs from the 9:00-10:00 period. CDRs in the interval 11:00-12:00 are not exported, as this interval is within the range set by the Min. age of export CDRs parameter. Later, at 13:00 cron exports CDRs fitting within the 11:00-12:00 interval, as well as non-exported CDRs with the timestamp earlier than 11:00.

Note: If the interval size is set to a value less than 1 hour, the System exports CDRs within some interval at the end of the next interval.

Export fields – windows that allow you to change the content of export CDRs and the arrangement of data in them (see Fig. 78).

Fig. 78 Making up a list of exported CDR data

The right window displays all data fields and their arrangement in a CDR (top lines data appear in the beginning of the CDR). If you wish to customize the makeup and arrangement of information in exported CDRs, select the necessary data and click the left-arrow button to transfer the selected items to the left window. The double-arrow button serves to move all

items indiscriminately between the windows. The and buttons allow arrangement of data items in CDRs. Moving an item one line up corresponds to moving the data item one position closer to the start of the CDR. Conversely, moving a data item one line down means moving the data piece one position closer to the end of the record.

* Save to – indicates the location where exported CDR files will be saved. Two possible options include:

- file system locally. This option allows file saving to the HDD or external media mounted on the file system of the DB server.

Operating TM

MVTS Pro 1.5.0-40

p. 116 of 197

- FTP server. This option provides for saving exported CDRs to a remote FTP machine.

Export directory – sets a directory where CDR files will be saved.

Note: When specifying a directory for CDR files the administrator must remember that the www-data user in the name of which file saving is done must possess writing rights for that directory

* Export format – allows you to control the format of exported CDRs. Two possible options include:

- MVTS-1. When this export format is selected CDRs are written to a plain text file as a set of several lines (1 CDR per a line) formatted like (FIELD_NAME_IN_CAPITALS1=data1[delimiter]FIELD_NAME_IN_CAPITALS2=data2[delimiter]... etc.).

- CSV. With this data export format selected, CDRs will be written to a conventional CSV file viewable in Microsoft Excel™.

Category General settings

Date format – defines format for dates. Entries should be done in MySQL notation, for example, the entry «%Y-%m-%d %H:%i:%s» corresponds to a date of the type «YYYY-MM-DD HH:MM:SS».

* Delimiter – specifies a separator symbol for data fields in export CDRs. Each CDR starts on a new line.

Export zero duration CDRs – select the checkbox to export CDRs representing zero duration calls.

* Show call duration in – select a method of presenting call duration in exported CDRs from the combo box.

Max. number of CDRs per file – sets maximum permissible quantity of CDRs per file.

Note: If actual values happen to be in excess of those defined in the fields Max. number of CDRs per file the system creates additional export files with index _1,_2 etc in the filename. For example, [filename]_1.csv(or .txt), [filename]_2.csv(or .txt);

Export IP addresses with ports – select the checkbox to export IP addresses of the originator and terminator with ports used for signaling.

Category MVTS-1 format settings

MVTS-1. Leading distinguisher – this field allows you to enter a distinctive character string that will precede all CDRs in the export file (MVTS 1 format).

MVTS-1. Put date in the beginning – activate the checkbox to export CDRs with the date in the beginning (MVTS-1 format).

Category CSV format settings

Include headers in CSV file – selection of this checkbox causes inclusion of data fields headers in exported CDRs.

Note: This setting is valid only when CSV is selected as the export format, that is the parameter Export format is set to CSV.

CSV. Quotation marks – allows selection of single or double quotes (or none at all) that enclose CDR data in the export file.

CSV. Use for empty fields – sets a string used in export CDRs to identify empty data fields.

Operating TM

MVTS Pro 1.5.0-40

p. 117 of 197

Category Substitution settings

Find in fields – specify the string to be searched for in the exported CDR fields. This string will be replaced by the value of the Replace with parameter.

Replace with – specify the string which will replace the string of the Find in fields parameter.

Category File settings

* Compression – allows the choice of compression methods (bzip2 or gzip) for export CDR files.

Save empty files – with this check box selected an empty file will be saved if no new CDRs have been generated since the latest launch of the cron export job.

CDR filename prefix – a character string used for generation of filenames for export CDRs files.

CDR filename postfix – a string of characters that will be concatenated to the filename, extension included.

Add sequence number – select the checkbox to add a unique sequence number to the file name. The sequence number is incremented even when the checkbox is deselected. When the number exceeds 999999 it is reset to 000000 and the incrementation process starts anew. The sequence number is inserted between the postfix and the timestamp of the file.

For filename use timestamp of – allows selection of a time stamp for generation of the export file name (see below). Two available options include:

- first CDR. Use the time stamp of the first CDR in the file in filename generation.

- last CDR. Use the time stamp of the last CDR in the file in filename generation.

Filename template– defines the template of filenames for exported CDRs. Entries should be done in the MySQL notation, for example, the entry “%Y-%m-%d %H:%i:%s” corresponds to a date of the type “YYYY-MM-DD HH:MM:SS”. By default, the value is “%Y%m%d_%H%i%s”. Table 7 shows the list of allowed specifiers.

Table 7 Filename format specifiers

Specifier Description

%d Day of the month, numeric (00..31)

%H Hour (00..23)

%i Minutes, numeric (00..59)

%j Day of year (001..366)

%k Hour (0..23)

%m Month, numeric (00..12)

%s Seconds (00..59)

%u Week (00..53), where Monday is the first day of the week

%w Day of the week (0=Sunday..6=Saturday)

%Y Year, numeric, four digits

%y Year, numeric (two digits)

The name of the file to which exported CDRs are saved is generated in the format PDS, where

Operating TM

MVTS Pro 1.5.0-40

p. 118 of 197

P - character string entered in the field CDR filename prefix.

D - timestamp of export, formatted in keeping with Filename template field.

S - character string, entered in the field CDR filename postfix.

When no new CDRs have appeared since the latest cron job execution and the checkbox Save empty files is selected, the time stamp for the D part of the file name is the server’s system time.

File mask – file access rights, specified as 4 octal digits.

Category FTP settings

FTP server: address – name of FTP server and directory for saving CDR files (e.g. ftp://cdr.storage.machine/CDRs/export).

FTP server: login – login name for access to the FTP server.

FTP server: password – access password for the FTP server.

FTP passive mode – select this checkbox to enable interworking with the FTP server in the passive mode.

Note: All FTP server related settings will be valid only when the FTP server export option is selected in the Save to combo box

When through with filling out the form click OK to create a cron job. The newly created cron job is actually a crontab for the user www-data.

Below are the examples of CDRs exported in MVTS-1 and CSV format (one of each):

MVTS-1 format CDR

CDR export settings:

Filename prefix = prefix_

Quotation marks = “

Mark empty fields = \N

Delimiter = ‘,’

Export format = MVTS-1

======= Start of file prefix_20080118_095202.txt ========

CDR_ID="200801000000001028",CDR_DATE="2008-01-18 09:52:02",IN_ANI="3",IN_DNIS="999",OUT_ANI="9004",OUT_DNIS="9595",BILL_ANI="9004",BILL_DNIS="9005",SIG_NODE_NAME="\N",REMOTE_SRC_SIG_ADDRESS="192.168.130.149:5060",REMOTE_DST_SIG_ADDRESS="192.168.130.47:1720",REMOTE_SRC_MEDIA_ADDRESS="192.168.130.149:16386",REMOTE_DST_MEDIA_ADDRESS="\N",LOCAL_SRC_SIG_ADDRESS="192.168.131.12:5060",LOCAL_DST_SIG_ADDRESS="192.168.131.12:35765",LOCAL_SRC_MEDIA_ADDRESS="192.168.131.12:12088",LOCAL_DST_MEDIA_ADDRESS="\N",IN_LEG_PROTO="sip", OUT_LEG_PROTO="h323",CONF_ID="[email protected]",IN_LEG_CALL_ID="e58871

[email protected]",OUT_LEG_CALL_ID="b4805c00bc76901080000017a48b7a95",SRC_USER="", DST_USER="\N",RADIUS_USER="\N",SRC_NAME="tel_linksys",DST_NAME="tel_panasonic",DP_NAME="9005",ELAPSED_TIME="\N",SETUP_TIME="2008-01-18

ftp://cdr.storage.machine/CDRs/export





Operating TM

MVTS Pro 1.5.0-40

p. 119 of 197

09:51:49",CONNECT_TIME="2008-01-18 09:52:02",DISCONNECT_TIME="2008-01-18 09:

52:02",DISCONNECT_CODE="262631",IN_LEG_CODECS="PCMU (type=[audio],transport=[rtp],vad=[disable],fpp=[0],flags=[0x0]);PCMU (type=[audio],transport=[rtp],vad=[disable],fpp=[20],flags=[0x0]);",OUT_LEG_CODECS="\N",SRC_FASTSTART_PRESENT="0",DST_FASTSTART_PRESENT="\N",SRC_TUNNELING_PRESENT="1",DST_TUNNELING_PRESENT="\N",PROXY_MODE="1",LAR_FAULT_REASON="\N",ROUTE_RETRIES="2",SCD="\N",PDD="\N",PDD_REASON="\N",SRC_MEDIA_BYTES_IN="10568",SRC_MEDIA_BYTES_OUT="90123",DST_MEDIA_BYTES_IN="90123",DST_MEDIA_BYTES_OUT="9160",SRC_MEDIA_PACKETS="65",DST_MEDIA_PACKETS="453",SRC_MEDIA_PACKETS_LATE="0",DST_MEDIA_PACKETS_LATE="0",SRC_MEDIA_PACKETS_LOST="0",DST_MEDIA_PACKETS_LOST="0",SRC_MIN_JITTER_SIZE="0",SRC_MAX_JITTER_SIZE="0",DST_MIN_JITTER_SIZE="0",DST_MAX_JITTER_SIZE="0",SRC_CENTREX_ID="3",DST_CENTREX_ID="3",COOKIE="84168533",DVO="0",CALL_TYPE="\N",USER_BILLING_ID="29",USER_LINE_NAME="office phone"

======= End of file prefix_20080118_095202.txt =========

CDR exported to a CSV file:

CDR export settings:

Filename prefix = prefix_

Quotation marks =

Mark empty fields = \N

Delimiter = ‘,’

Export format = CSV

======= Start of file prefix_20080117_134728.csv =========

cdr_id,cdr_date,in_ani,in_dnis,out_ani,out_dnis,bill_ani,bill_dnis,sig_node_name,remote_src_sig_address,remote_dst_sig_address,remote_src_media_address,remot

e_dst_media_address,local_src_sig_address,local_dst_sig_address,local_src_media_address,local_dst_media_address,in_leg_proto,out_leg_proto,conf_id,in_leg_cal

l_id,out_leg_call_id,src_user,dst_user,radius_user,src_name,dst_name,dp_name,elapsed_time,setup_time,connect_time,disconnect_time,disconnect_code,in_leg_code

cs,out_leg_codecs,src_faststart_present,dst_faststart_present,src_tunneling_present,dst_tunneling_present,proxy_mode,lar_fault_reason,route_retries,scd,pdd,p

dd_reason,src_media_bytes_in,src_media_bytes_out,dst_media_bytes_in,dst_media_bytes_out,src_media_packets,dst_media_packets,src_media_packets_late,dst_media_

packets_late,src_media_packets_lost,dst_media_packets_lost,src_min_jitter_size,src_max_jitter_size,dst_min_jitter_size,dst_max_jitter_size,src_centrex_id,dst

_centrex_id,cookie,dvo,call_type,user_billing_id,user_line_nam

200801000000000527,2008-01-17

13:47:28,5488,5223,5222,5489,5222,5223,\N,192.168.131.134:5061,192.168.131.135:5061,192.168.131.134:5004,192.168.131.135:41000,

192.168.131.12:5060,192.168.131.12:5060,192.168.131.12:10048,192.168.131.12:10060,sip,sip,100c7ad8-8683a8c0-13c5-3e1243f1-78704c0b-3e1243f1@meranetworks.ru,1

mailto:100c7ad8-8683a8c0-13c5-3e1243f1-78704c0b-3e1243f1@meranetworks.ru

Operating TM

MVTS Pro 1.5.0-40

p. 120 of 197

[email protected],[email protected],,\N,\N,Moolio's

AudioCodec,Moolio's D-Link,5 223,50631,2008-01-17 13:47:05,2008-01-17

13:47:08,2008-01-17 13:47:59,65546,PCMA (type=[audio], transport=[rtp],

vad=[disable], fpp=[0], flags=[0x0]);PCMA (t

ype=[audio], transport=[rtp], vad=[disable], fpp=[20], flags=[0x0]);,PCMA

(type=[audio], transport=[rtp], vad=[disable], fpp=[0], flags=[0x0]);PCMA

(type=[audio], transport=[rtp], vad=[disable], fpp=[20],

flags=[0x0]);,0,0,1,1,1,\N,0,1043,449,\N,185204,115200,35324,49800,997,590,0,0,163,10,0,74,0,5,3,3,19199054,0

,\N,8,Moolio 5222 UL

======= End of file prefix_20080117_134728.csv =========

6.6.2. EXPORT INTERVAL The object Export interval in the category Export CDRs allows you to perform immediate export of call detail records matching the specified interval.

In the * Starting date and * Ending date parameters specify the time frame, to which the exported CDRs pertain. In the * Export period combobox select the period, into which the exported CDRs will be subdivied. Each period is saved into a separate file, unless the * Save parameter = with browser. In the latter case a single file is generated. All othe parametes correspond to the parameters of the Scheduled export object (see section 6.6.1).

To invoke the export procedure click OK.

6.7. STATISTICS

The category of objects Statistics allows generation of area traffic reports.

6.7.1. REPORTS The object Reports is a GUI page that allows to create and view DP traffic transit reports.

To create a report, in the dialog Create report (Statistics → Reports) enter a name for the future report, type a regular expression in the field Pattern for DP name (LIKE) that defines a name(s) for DPs, and in the Grouping list select the criteria for grouping CDRs.




Operating TM

MVTS Pro 1.5.0-40

p. 121 of 197

Fig. 79 Creating a report

Grouping – move attributes, by which CDRs will be grouped during report generation, from the left to the right box. The precedence of grouping is determined by the position of the grouping attribute in the list. Change the order of grouping by moving grouping attributes in

the list up and down using and buttons. Initially, CDRs are grouped by the topmost attribute on the list, then the records within the resulting groups are grouped by the second attribute in the list, and so on.

* Time unit – this parameter selects a measure of time used in record grouping. The process of report creation is described below in detail. The parameter is valid if the Grouping list contains Date.

* From date/To date – set the date range used to select CRDs for the report.

Pattern for SRC GW name (LIKE) – enter the originating gateway name pattern to include data pertaining to the specified originating gateway only.

Pattern for DP name (LIKE) – enter the DP name pattern to include data pertaining to the specified DP only.

Pattern for DST GW name (LIKE) – enter the termination gateway name pattern to include data pertaining to the specified termination gateway only.

Note: LIKE operator indicates that mySQL syntax is used for name patterns.

Disconnect code – enter a disconnect code to include the calls with the specified disconnect code only.

Area – select the prefix from the dropdown list to include those calls into the report that have the specified prefix in the telephone number.

The newly generated report will be added to the table Report contents and to the table All reports to complement earlier generated reports.

Operating TM

MVTS Pro 1.5.0-40

p. 122 of 197

Fig. 80 Tables Report contents and All reports

Report generation unfolds as follows:

1. CDRs are selected by the date that fits in the date range defined in the Create report dialog.

Note: The CDR date value depends on the Value for "Date" field in CDR: 1 - Setup time, 2 - Disconnect time parameter.

2. When a regexp pattern for the DP name, name of the originating or terminating gateway are available, the CDRs are additionally filtered by the name matching the regexp entered in the field Pattern for DP name (LIKE), Pattern for SRC GW name (LIKE) or Pattern for DST GW name (LIKE).

3. The selected CDRs are then grouped by attributes specified in the Grouping list. The order of grouping is determined by the precedence of the grouping attributes in the list. If the Grouping list includes Data, then the CDRs are additionally sub-grouped by date using the time option selected in the Time unit combo box. By way of example, if the Grouping list includes two attributes – Region and Date, where Region is the first attribute and Date is the second, the CDRs will be first grouped by Region, and then by Date. Suppose, the Time unit parameter is set to Hour, then report records in region groups within the defined date range are further grouped in hourly sub-groups. When a created subgroup contains no calls - it is discarded; otherwise it occupies a line in the generated report.

4. The statistical data calculated for each group of CDRs are as follows:

- Total minutes – total duration of all calls in minutes (taking into account all records in the group), rounded up or down to the nearest whole minute.

- Total calls – total number of call arrivals (that is the number of connections between the originator and the System). In other words – the number of CDRs with the Last CDR parameter equal to “Yes”.

- Successful calls – number of successful calls.

Note: Successful calls are calls completed with call disconnect reason codes marked as Successful (see 6.8.2) or with non-zero duration.

- Connected calls – number of calls with a voice session (that is calls of non-zero duration).

- Total attempts – total number of attempts to establish a call (number of the System connection attempts to the terminator).

Operating TM

MVTS Pro 1.5.0-40

p. 123 of 197

- Successful attempts – successful number of attempts to establish a call.

- Connected attempts – number of attempts with a voice session (that is attempts of non-zero duration).

Note: The data on the number of calls (total, successful and with voice sessions) is necessary to assess the quality of services, provided by the terminating operator. The data on the number of attempts (total, successful and with voice sessions) is necessary to assess the quality of termination services, provided to MVTS Pro operator by other operators.

- ASR (calls), % – answer seizure ratio calculated by the MVTS Pro intrinsic method. (see ASR(MVTS)).

- Std. ASR (calls), % – standard answer seizure ratio calculated conventionally (see ASR(std)).

- ASR (attempts), % - answer seizure ratio for calls forwarded for termination by other operators; the ratio is calculated by MVTS Pro intrinsic method (see ASR(MVTS)).

- Std. ASR (attempts), % - answer seizure ratio for calls forwarded for termination by other operators; calculated conventionally (i.e. ASR = total number of non-zero duration calls/total calls).

- ACD, sec – average call duration for non-zero length calls.

- Avg. PDD, sec – average post dial delay, calculated for calls with PDD > 0.

- Avg. SCD, sec – SCD average, calculated for calls with SCD > 0.

- First CDR date – SETUP time of the earliest call in the group.

- Last CDR date – SETUP time of the latest call in the group.

- First CDR ID – the CDR unique ID of the first call in the specified period.

- Last CDR ID – the CDR unique ID of the last call in the specified period.

To view a report, invoke the pop-up menu and select View.

Operating TM

MVTS Pro 1.5.0-40

p. 124 of 197

Fig. 81 Viewing report contents

You cannot remove individual CDRs from a report; you can only remove the entire report form the table All reports.

6.7.2. CHARTS The object Charts allows an illustrative representation of the System statistics in real-time. To enable statistics collection globally, set the Enable statistics (Global settings -> System global settings) parameter to 1. To include data about individual gateways and dial peers into the statistics, select the checkbox Enable statistics in configuration forms of respective GWs or DPs. If statistics collection is disabled globally (Global settings -> System global settings -> Enable statistics = 0) the Enable statistics setting of individual gateways and dial peers is ignored.

Operating TM

MVTS Pro 1.5.0-40

p. 125 of 197

Fig. 82 Charts

To add a new chart click .

A new dialog will appear where you can configure the parameters of the chart being created.

Fig. 83 Creating a new chart

From the drop down list Object type select an object, to which the chart pertains. The list options include:

− Originator – plot a chart for origination gateway.

− Terminator – plot a chart for termination gateway.

− Gateway – plot a chart for the gateway that is both originator and terminator.

− Dialpeer – plot a chart for the DP as a whole (including all gateways pertaining to it.

In the Object name field type the first characters of the object to be monitored and the select the object from the drop-down list.

In Systems with multiple scripting nodes, select the checkboxes of those scripting nodes that should be taken into account during graph plotting.

To create a new chart click OK.

The screen will show a new chart area. To add a new curve for a specific parameter to the chart, on the right panel select the checkbox next to the parameter name (Fig. 82). You can monitor the following parameters, calculated as exponential moving average. To plot a statistics chart:

− ASR – Answer seizure ratio (MVTS-specific).

Operating TM

MVTS Pro 1.5.0-40

p. 126 of 197

− ASR (std.) – Conventional ASR.

− ACD – Average call duration.

− PDD – Post-Dial Delay.

− SCD – SETUP-CONNECT Delay.

− QoS – Quality of Service.

− CPS – Call arrival rate

− Calls – total number of calls being handled

To change the curve options for each parameter, click on the parameter name on the right panel.

Fig. 84 Configuring a curve

To select the curve color, click on the field next to the Line color label.

Select the desired curve thickness in pixels from the Line weight combo box.

Select the desired curve form from the Line type combo box – Spline and Polygon.

To apply new parameters, click OK.

Set a desired chart update rate selecting a value from the drop-down list Refresh period.

Define the chart horizontal scale using the Scale slider.

To stop plotting of all curves press . To edit the chart parameters press .

When several scripting nodes are selected, the plot value is calculated as a weighted average with regard to the CPS value for every selected node.

Suppose, you want to display an ASR chart for the dial peer DP1 and your System has two scripting nodes – ScrN1 and ScrN2. The ASR statistics for ScrN1 is 80 and 40 for ScrN2. Simultaneously, the CPS data for ScrN1 equals 15 calls per second and is 5 calls/sec. for ScrN2. The weighted average ASRavg is then calculated as:

ASRavg = (ASRScrN1 * CPS ScrN1 + ASR ScrN2 * CPS ScrN2)/(CPS ScrN1 + CPS ScrN2),

that is

ASRavg = (80*15 + 40*5)/(15 + 5) = 70.

If CPS or Calls are the main chart parameter, the plotted value is just the sum of CPS or Calls values respectively from all selected scripting nodes.

Operating TM

MVTS Pro 1.5.0-40

p. 127 of 197

You can add new charts by pressing . The new chart will appear at the top of the chart list window.

To remove the chart, click in its right-upper corner.

6.8. GLOBAL SETTINGS

The subcategory Global settings comprises objects pertaining to system global settings, web settings, call disconnect codes and interoperation with RADIUS, ENUM and DNS servers.

6.8.1. SYSTEM GLOBAL SETTINGS The view System global settings displays a list of the system global parameters.

Fig. 85 Table of global configuration parameters

The global configuration parameters currently accessible to the MVTS Pro administrator include:

Operating TM

MVTS Pro 1.5.0-40

p. 128 of 197

Max. call duration – maximum call duration for all calls. Among the parameters limiting maximum call duration, defined on the originator, terminator, RADIUS-server and in the global settings, the parameter with the lowest value is selected (Zero means no limitation).

Number of routes sent to TS at a time – number routes selected by the scripting node that are sent to the TS at a time. This parameter allows you not send all routes simultaneously, thus enhancing the performance.

MVTS name – the name identifying the MVTS Pro to interoperating devices.

Enable statistics – toggle collection of statistical data, which is used to plot charts.

Number of calls for EMA calculation – defines the number calls used for calculation of exponential moving average of the following parameters: ASR (MVTS), ASR (std), ACD, PDD, SCD, CPS и QoS.

Encrypt H.323 plain text password – toggles encryption of the plain text password from an H.323 device, when the password is sent to a RADIUS server. The password is encrypted, when the device registers through a default gateway or has RADIUS password set to ‘*’. The System uses the secret key of the RADIUS server, to which the password is sent, for encryption.

‘Service-Type’ attribute value – specify the value of the Service-Type attribute to be sent to the RADIUS server. If no value is 0, the attribute is not included into the packets. For further information refer to RFC 2865.

‘Framed-Protocol’ attribute value – specify the value of the Framed-Protocol attribute to be sent to the RADIUS server. If no value is 0, the attribute is not included into the packets. For further information refer to RFC 2865.

Value for "Date" field in CDR: 1 - Setup time, 2 - Disconnect time – determines the way of filling in the Date field in CDRs. 1 means the call setup time will be recorded, 2 means the call disconnect time will be recorded.

Number of CDR files restored per check – number of temporary files with CDRs that are restored to the DB per check.

Max. debug call/registration sessions sets the maximum number of debug records allowed in the tables “Debug registrations” and “Debug calls”.

Debug data lifetime (days) defines the maximum retention time for debug call and debug registration data. As the size of debug data files may grow prohibitively large, set this parameter so as to prevent hard disk overflow.

Enable logging for unknown calls – determines if the System should log calls from unknown gateways (i.e. gateways with no record in the DB, including records of default gateways).

Enable logging for unknown registrations – determines if the System should log registrations from unknown gateways (i.e. gateways with no record in the DB, including records of default gateways).

Click the button Switch to edit mode to configure the parameters of the Traffic Manager.

6.8.2. WEB SETTINGS The table Web settings includes parameters essential for GUI management, which are as follows:

http://rfc-ref.org/RFC-TEXTS/2865/chapter5.html#d4e447338

http://rfc-ref.org/RFC-TEXTS/2865/chapter5.html#d4e447765

Operating TM

MVTS Pro 1.5.0-40

p. 129 of 197

Fig. 86 Table of GUI parameters

Default GUI Language - sets the GUI default language: 1 for English, 2 – for Russian.

Possible number of rows on page – use this parameter to define the size of a table page expressing it in a number of rows per page. A list of decimal numbers delimited with commas. For example, 10, 20, 30, 50.

Default number of rows on page – use this parameter to define the default table page size, i.e. the number of rows a table will display when first accessed for viewing.

Maximum number of rows displayed in GUI tables – use this parameter define the maximum number of table records displayed in GUI. Should the actual number of records in the DB exceed the specified table size limit apply a filter to view the table data. The parameter serves to expedite the display of tables with large amounts of data (for example, tables of CDRs). If the parameter is not defined, the error “General error: 126 Incorrect key file for table” may occur, when trying to display a table with a large number of entries.

CSV date format – this parameter allows the user to define a date format applied to exported data.

CSV fields delimiter – you can use this parameter to select a symbol to be used to delimit data fields in data export files, for example “,” or “;”.

CSV fields quote – serves to define a symbol to enclose data fields in data export files, for example, quotes.

CSV null value – serves to define a symbol or symbols that will be used to fill empty data fields in data export files.

Default time zone – use this parameter to specify the default time zone for the GUI objects (objects CDRs, Reports, Debug calls and Debug registrations). The default SYSTEM value indicates that the time zone, used to display dates in the abovementioned objects, is the time zone of the server running the DB.

Enable/disable logging of user activity – two possible values for this parameter are 0 and 1. 1 enables user GUI activity logging, 0 disables user activity logging.

Enable/disable logging of view actions – allows two values 0 and 1. 0 disallows logging of user viewing activity. 1 enables logging of all user actions, including object viewing . If Enable/disable logging of user activity = 0, the view activity logging parameter is ignored.

Maximum storage time for user activity log (days) - sets a retention time for web activity log records (days). Records, the age of which exceeds the value defined by this parameter,

Operating TM

MVTS Pro 1.5.0-40

p. 130 of 197

are subject to deletion form the log. Note that to avoid excessive server load records will be deleted with some delay.

Enable/disable authentication history – allows two possible values - 0 and 1. 0 disables user authentication logging, 1 enables authentication logging.

Maximum storage time for authentication history (days) - sets a retention time for authentication history records (days). Records the age of which exceeds the value defined by this parameter are subject to deletion form the log. Note that to avoid excessive server load records will be deleted with some delay.

To configure a parameter point the mouse to the desired record in the table. Left-click to invoke the pop-up menu and select Edit.

Fig. 87 Setting the parameter Maximum number of rows displayed in GUI tables

Type the required parameter value in the edit field Value (see Fig. 87) and click the OK button. To discard the made changes click Cancel.

6.8.3. DISCONNECT CODES The table Disconnect codes presents a listing of call disconnect codes. To quicken search of the necessary information you can use search filters. Refer to section 5.2.3 for information about the use of search filters.

Fig. 88 Table of call disconnect codes

The table presents the following information:

Universal code – the disconnect code number used in communication between the TS and the TM.

Namespace – type of the disconnect code:

H.323.

Operating TM

MVTS Pro 1.5.0-40

p. 131 of 197

SIP.

TS (Traffic switch).

TM (Traffic Manager).

Code – call disconnect code.

H.323/SIP code mapping – this columns present the disconnect codes, which will be sent to the calling and called parties, instead of local TS and TM disconnect codes. The equipment supportive of H.323 protocol will receive the code from the column H.323 code mapping, the SIP endpoints will receive the code from the column SIP code mapping.

Reason – disconnect reason that corresponds to the code.

Successful – when selected this checkbox indicates that the calls completed with this disconnect reason code should be considered successful during ASR evaluation. To set the parameter to “Yes” place the cursor over the record of interest, left-click to invoke the pop-up menu and select Edit. Select the respective checkbox in the displayed dialog box and click the OK button.

6.8.4. RADIUS SERVERS The table RADIUS servers presents information about configured RADIUS servers used as external authentication, accounting and/or routing means.

Fig. 89 Table of configured RADIUS servers

To add a RADIUS server record, left click the mouse over the table and select Add on the pop-up menu.

Operating TM

MVTS Pro 1.5.0-40

p. 132 of 197

Fig. 90 Adding a RADIUS server record

Fill out the displayed server configuration form (see Fig. 90) The fields marked with an asterisk are required fields.

* RADIUS server name – enter the name of the RADIUS server.

Description – you can enter any information pertaining to the record being configured in this field.

Enable – select the checkbox to make the record active.

* Precedence – use this parameter to define the server precedence. The higher the value – the higher the precedence (that is 2 has higher precedence than 1). At each instance of time MVTS Pro interacts with one server only, with the highest precedence. If the system detects a failure of the RADIUS server it is currently connected to, it will switch to the next configured server with the lower precedence value.

Enable authentication – select the check box to enable authentication of gateways by the RADIUS server being configured.

Enable authorization – select the check box to enable authorization of calls from gateways by the RADIUS server being configured.

Note: When the Enable authorization checkbox is selected and at least one route of a dial peer is generated with help of external routing feature, all routes of the dial peer do not undergo authorization on the RADIUS server. This relieves the load from the System and the RADIUS server.

Enable accounting – select the check box to enable accounting through the RADIUS server being configured.

Operating TM

MVTS Pro 1.5.0-40

p. 133 of 197

Enable external routing – select the check box to if you are planning to use the RADIUS server for external routing.

Secret key – enter a coding key (according to the ‘shared secret’ standard) for communication with the RADIUS server.

Retry number – use this parameter to specify the number of send attempts for the packets destined for the RADIUS server.

Retry period – use this parameter to set the interval (in seconds) between consecutive send attempts.

* Time format (billing) – choose a time format for the RADIUS packets from the combo box. Select the “UTC” option, to present the packet date in the UTC time zone. Select the “Local time” option, to present the date as local time, configured on the host with the scripting node.

Category Authentication – these parameters are valid only with the selected Enable authentication checkbox:

Authentication address – enter the IP address of the RADIUS server used for authentication.

Authentication port – enter the port for authentication on the RADIUS server.

Category Accounting – these parameters are valid only with the selected Enable accounting checkbox:

Accounting address – enter the IP address of the RADIUS server to be used for accounting purposes.

Accounting port – enter the port of the RADIUS server to be used for accounting purposes.

Use old CISCO format – the flag that indicates the preferred accounting format. Select the checkbox to use old CISCO format (overloaded attribute 44). The cleared checkbox means that the used format is CISCO VSA.

* Send ACCT. START/STOP packets – defines an accounting method through the choice of packets used for accounting and billing. Select the required option from the drop-down list.

of the incoming leg – when selected makes the System send the RADIUS-server ACCT. START/STOP packets, pertaining to the incoming leg.

of the outgoing leg – when selected makes the System send ACCT. START/STOP packets, pertaining to the outgoing leg.

of both legs – when selected makes the System send ACCT. START/STOP packets, pertaining both to the incoming and outgoing legs.

of both legs with field substitution – when selected makes the System send ACCT. START/STOP packets, pertaining to both call legs, and performs the following substitutions in packet fields:

For the incoming leg:

Field name Substituted value

h323-gw-id ID of the termination gateway

h323-gw-address IP address of the termination gateway or gatekeeper used for signaling

Operating TM

MVTS Pro 1.5.0-40

p. 134 of 197

h323-remote-id ID of the origination gateway

h323-remote-address IP address of the origination gateway used for signaling

For the outgoing leg:

Field name Substituted value

h323-gw-id ID of the origination gateway

h323-gw-address IP address of the origination gateway or gatekeeper used for signaling

h323-remote-id ID of the termination gateway

h323-remote-address IP address of the termination gateway used for signaling

of both legs for each rerouting attempt – with this option selected the System sends only one pair of ACCT. START/STOP packets pertaining to the incoming leg.

For example, if the call was rerouted three times, the set of the packets sent to the RADIUS-server will be as follows:

Accounting START record for the answer leg

originate leg Accounting START record 1

originate leg Accounting STOP record 1





Accounting STOP record for the answer leg

of the outgoing leg is the default setting.

Send Accounting STOP only – enables/disables sending of Accounting STOP packets only. Select the checkbox to have the System send accounting STOP packets only.

Category External routing – these parameters are valid only with the selected Enable external routing checkbox:

External routing address – enter the IP address of the RADIUS server to be used for purposes of external routing.

External routing port – enter the port of the RADIUS server to be used for purposes of external routing.

Note: It is possible to use the same IP addresses and ports for different functions of the RADIUS server; you can specify the same IP address and port for authentication and accounting, for example.

When done with entering data, click OK to add the record to the table.

Operating TM

MVTS Pro 1.5.0-40

p. 135 of 197

If you wish to modify the record, select the Edit item on the pop-up menu.

Note: On changes in the active RADIUS server parameters as well as on changes of the active RADIUS server (e.g. in case the System switches to a redundant RADIUS server), the new RADIUS server parameters apply to the unterminated calls (e.g. when deselecting the Use old CISCO format checkbox the System will start sending billing packets in CISCO VSA format for all active calls).

6.8.5. ENUM-SERVERS The table «ENUM-servers» displays information about ENUM servers configured in the system.

The object ENUM servers is intended for configuring connection with ENUM servers that allow conversion of conventional E.164 telephone numbers into URLs by means of the DDDS (Dynamic Delegation Discovery System) algorithm and further into IP addresses which makes such servers especially fit for external routing. Refer to RFC 3761 for a more detailed explanation of ENUM.

Note: External routing by means of ENUM servers is possible under SIP signaling only.

To add a ENUM server, invoke the pop-up menu and select Add.

Fig. 91 ENUM server properties form

In the dialog that opens enter the following data (the parameters marked with an asterisk character are required parameters):

* Name – name that identifies the ENUM server.

Description – you can enter any descriptive information or comments pertaining to the record being created in this field.

Enable – select this checkbox to envalidate the record.

* Address – specify the IP address in this edit box.

Domains – define the domain where the ENUM server belongs.

http://www.ietf.org/rfc/rfc3761.txt

Operating TM

MVTS Pro 1.5.0-40

p. 136 of 197

When through with filling out the ENUM servers form, click OK to add the newly configured record. You can specify the configured ENUM server as an external routing means when configuring gateways.

If you wish to modify the record, select the Edit item on the pop-up menu.

6.8.6. DNS SERVERS The table “DNS servers” allows you to overview the domain name servers used for resolution of URIs received from ENUM servers.

To add a DNS server, invoke the pop-up menu and select Add.

Fig. 92 Entering DNS server data

Fill out the DNS servers form and click OK to add the newly configured record. The required fields on the form are marked by an asterisk ’*’.

The required fields on the DNS servers form are *Name (the server name assigned by the administrator) and *Address (the server’s IP) only.

The parameter Precedence shows the DNS server preference. The greater the parameter value the greater the server’s preference.

Select the Enable checkbox to validate the record.

If you wish to modify a record select the Edit item on the pop-up menu.

6.8.7. AREAS The table Areas presents information about geographical names for traffic transfer locations.

Operating TM

MVTS Pro 1.5.0-40

p. 137 of 197

Fig. 93 Adding a new area record

To add a new record to the table, invoke the pop-up menu and click the Add item. Enter the name of the area in the * Name edit field and click the OK button.

A unique ID for the record will be generated automatically.

6.8.8. AREA SPECIFICS The table Area specifics displays information about area number prefixes and minimum or/and maximum lengths of numbers in areas.

Invoke the pop-up menu and select Add, to add another record to the table.

Fig. 94 Area specifics dialog

Enter the following data in the displayed dialog (the required fields are those marked with asterisk ‘*’):

* Area – select the area name from the dropdown list of this combo box.

* Prefix – enter the telephone number prefix for the area.

Min. number length – enter the decimal integer showing the minimum length of telephone numbers in the area.

Max. number length – enter the decimal integer showing the maximum length of telephone numbers in the area.

Click OK to add the record to the table.

6.8.9. CALLING PARTY’S CATEGORIES The table Calling party’s category contains reference information about the calling party’s categories.

Operating TM

MVTS Pro 1.5.0-40

p. 138 of 197

Fig. 95 Table "Calling party's category"

The table presents the following data:

CPC type – name of the standard, which defines the category.

Namespace – shows belonging to the international (CPC) or American (OLI) standard.

Code – code of the category.

Description – description of the category.

6.8.10. CPC TRANSLATIONS The table CPC translations presents information about correspondences between the international (CPC) and American (OLI) calling party’s categories.

Fig. 96 Table "CPC translations"

The table presents the following information:

Namespace – shows belonging to the international (CPC) or American (OLI) standard.

Code – code of the category.

CPC code mapping – if the category belongs to the OLI standard, this field shows the corresponding code in the CPC standard.

OLI code mapping – if the category belongs to the CPC standard, this field shows the corresponding code in the OLI standard.

The System translates calling party’s categories automatically, if the CPC in the incoming leg (or after translations on DPs, gateways, etc.) is defined in one standard (for example, CPC), but should be sent to the outgoing leg in the other standard (for example, OLI).

Operating TM

MVTS Pro 1.5.0-40

p. 139 of 197

6.8.11. CAPACITY GROUPS To control the softswitch capacity the System enables assorting calls into capacity groups.

Fig. 97 Table "Capacity groups"

Grouping by capacity aims at flexible management of individual and aggregate capacity of gateways and dial peers. Capacity management allows you to limit the number of calls not only for each stand-alone gateway, but also for a group of gateways, if necessary.

For example, the individual capacity of the terminators A and B is 10 and 10 calls respectively, but you want to limit the total capacity of both gateways to 15 calls. You can fulfill this task by assigning the gateways A and B to an A_B group and limiting the group capacity to 15 concurrent calls.

In such a case when a new call arrives to the A gateway, the System checks if the capacity of the gateway A is not exceeded, as well as if the capacity of the group A_B (to which the gateway A belongs) is not exceeded.

Capacity groups may become members of other capacity groups, thus creating a group hierarchy.

In such a case when a call arrives to the A gateway, the System checks the capacity of the gateway, the capacity of the group A_B to which the gateway is a member, the capacity of the group A_B_C to which the group A_B is a member, and further up the group hierarchy.

To add a new capacity group invoke the pop-up menu and select the Add option.

https://wiki.meranetworks.ru/wiki/%D0%98%D0%B7%D0%BE%D0%B1%D1%80%D0%B0%D0%B6%D0%B5%D0%BD%D0%B8%D0%B5:Capacity_groups_2.gif

https://wiki.meranetworks.ru/wiki/%D0%98%D0%B7%D0%BE%D0%B1%D1%80%D0%B0%D0%B6%D0%B5%D0%BD%D0%B8%D0%B5:Capacity_groups_2.gif

Operating TM

MVTS Pro 1.5.0-40

p. 140 of 197

Fig. 98 Adding a capacity group

Enter the following data in the displayed dialog (the required fields are those marked with asterisk ‘*’):

* Name – name that identifies the capacity group.

Description – you can enter any descriptive information or comments pertaining to the record being created in this field.

Parent group – the parent group of this capacity group.

Capacity – the number of concurrent calls that can pass through the group.

When done, press OK.

6.9. LOGS

The category Logs comprises objects, which record all authentication attempts and actions of users in the GUI.

6.9.1. WEB AUTHENTICATION HISTORY The object Authentication history (see Fig. 99) is designed to store the log of user authentication attempts.

Operating TM

MVTS Pro 1.5.0-40

p. 141 of 197

Fig. 99 Authentication history table

The following table presents the authentication history record parameters:

Session ID – ID number of the user logon session.

Date – date and time of the registered authentication attempt.

User – user account used for authentication.

Realm – realm of the user.

Login – login of the user used for authentication.

IP address – IP address, of the computer which requested authentication.

Login successful – shows if the login attempt was successful or not.

To view all logged user actions during the selected session, invoke the pop-up menu and select Web activity log. This will open Web activity log filtered by the selected session ID.

6.9.2. WEB ACTIVITY LOG Web activity log is accessible n the category of objects GUI. The table Web activity log (see Fig. 100) presents an account of user access to database objects and actions that users performed.

Fig. 100 Page with user activity transcripts

An individual user activity record provides the following information presented in table columns:

ID – record identifier.

Session ID – ID of the session, during which the record was created.

Logging time – date and time of record creation.

Operating TM

MVTS Pro 1.5.0-40

p. 142 of 197

User – actor’s account name.

Object – name of the object that was accessed.

Action – nature of the action done by the actor.

Data – detailed account of the action effect.

Filter – filter used while accessing data.

Row count – number of processed lines.

MVTS Pro Redundancy

MVTS Pro 1.5.0-40

p. 143 of 197

7. MVTS PRO REDUNDANCY The MVTS Pro system has a modular architecture. In addition to the ease of scalability the System’s modular design allows the efficient use of equipment as redundant modules are involved in traffic processing instead of idling in the standby operation. A System redundancy layout is illustrated in Fig. 101.

Fig. 101 Simplest MVTS Pro redundancy solution

In the diagram:

• BalNode1, BalNode2 – primary and failover registration and balancer nodes.

• SigNode1, SigNode2 – primary and failover signaling nodes.

• MedNode1, MedNode2, MedNode3, MedNode4 – media nodes;.

• ScriptNode1, ScriptNode2 – primary and failover call routing nodes (Scripting Nodes).

• LMN1, LMN2 – primary and failover license management nodes.

• SynchNode – synchronization node.

• Dongle1, Dongle2 – primary and backup USB dongles.

7.1. MEDIA NODE REDUNDANCY MedNodes enable media processing (RTP/RTCP) that is media proxy function and codec conversion. The number of MedNodes required in a MVTS Pro is determined based on the expected workload. When the System starts every MedNode connects to a SigNode.

One SigNode is capable of interoperating with several MedNodes simultaneously and allows traffic balancing among them.

MVTS Pro Redundancy

MVTS Pro 1.5.0-40

p. 144 of 197

MedNode redundancy is achieved by adding another MedNode. If there are at least two MedNodes in the System one may speak of MedNode redundancy (see Fig. 101).

When one of the MedNodes fails, (as MedNode1 in Fig. 102) the subscribers, whose talk was enabled by the faulty node, will probably (if the workload is large) hear voice distortion for a while (some seconds) or silence in the receiver until the phoenix process automatically restarts the crashed node. The conversation will continue after the MedNode is restarted and its pre-failure state is restored. If the faulty MedNode restart turns out impossible for some reason or there is no access to the server on which the faulty MedNode1 is installed, voice sessions of new arriving calls are established through MedNode2.

Fig. 102 Diversion of media flows to healthy media node

As soon as MedNode1 is alive again (its serviceability is manifested by a restored link to the SigNode) SigNode1 resumes traffic balancing between MedNode1 and MedNode 2.

7.2. SIGNALING NODE REDUNDANCY SigNodes allow setup of SIP and H.323 calls. The number of SigNodes in a System depends on the volume of traffic.

When the System starts each SigNode connects to one ScriptNode, one SynchroNode and all BalNodes of the System. Balancer nodes distribute arriving calls among the SigNodes, with regard to the ASR data of the latter.

If there are at least 2 SigNodes in the System and all of them are connected to all available balancer nodes, it is safe to refer to such system as a system with SigNode redundancy. (See Fig. 101).

When a SigNode fails (as for example SigNode1 in Fig. 103) all H.323 calls handled by the crashed node get terminated, as well as all non-finalized SIP calls (i.e. calls in the process of being set up or a change of state). Established SIP calls are saved and restored, when the SigNode recovers. The calls that could not be restored get terminated correctly.

MVTS Pro Redundancy

MVTS Pro 1.5.0-40

p. 145 of 197

Fig. 103 Reassignment of new call arrivals after SigNode1 fails

All new arriving calls will be forwarded to SN2 while SN1 remains inoperative. As soon as SN1 resumes functioning, the balancer nodes BN1 and BN2 will again include the SigNodes SN1 and SN2 in load balancing.

7.3. BALANCER NODE REDUNDANCY BalNode operates as an entry point for signaling. When the System starts, the BalNode connects to one LMN. Then, the BalNode sends the LMN all arriving equipment registration requests and performs load balancing between SigNodes.

BalNode redundancy is achieved by adding another BalNode to the System. The following BalNode redundancy configurations are possible:

1. The first configuration is feasible when terminal equipment is capable of interoperation with the main and an alternate SIP proxy/gatekeeper. In this case the IP address of the backup BalNode (BalNode2 in Fig. 104) is entered as that of the alternate SIP proxy/gatekeeper. If the primary BalNode fails (see BalNode1 in Fig. 104), the terminal equipment will forward arriving calls to the failover BalNode (BalNode2 in Fig. 104).

MVTS Pro Redundancy

MVTS Pro 1.5.0-40

p. 146 of 197

Fig. 104 Signaling entry point redundancy: gateway supporting alternative SIP

proxy/gatekeeper

2. The second variant involves connection of both the primary and failover BalNode to a router supportive of Server Load Balancing (for example, CISCO Catalyst 4840G. See Fig. 105).

Fig. 105 Entry point redundancy: router supporting Server Load Balancing

3. The thrid variant is implemented by hosting the BalNodes on the servers, backed up using the Linux Heartbeat system. For further information see Section 7.8.

If one of the BalNode fails, all H.323 calls, set up through the faulty BalNode, will be terminated, and all SIP/H.323 registration data, associated with this BalNode, will be lost.

7.4. SYNCHRO NODE REDUNDANCY SyncNode serves to keep record of the equipment capacity. There may be only one SyncNode in each System, and it requires no backups. If the SyncNode fails, all set-up calls continue and the System accepts newly arriving calls, though without regard to the existing origination and termination equipment capacity limitations.

7.5. LICENSE MANAGEMENT NODE REDUNDANCY The LMN serves for software license management (that is it reads the USB dongle) and for disseminates configuration data among other MVTS Pro nodes.

When the System starts, the LMN is the first module launched. As other nodes start up, they connect to the LMN and receive configuration files.

LMN redundancy is achieved by adding a stand-by LMN with a copy of the USB dongle.

MVTS Pro Redundancy

MVTS Pro 1.5.0-40

p. 147 of 197

When there is a failover LMN, enter its IP address in the phoenix.conf file placing it immediately after the line with the IP-address of the primary LMN:

The parameter listen indicates that the server is the host where the standby LMN runs. This server must have the copy USB dongle inserted.

Example of phoenix.conf configuration file:

This example illustrates that the main LMN with the name SYSTEM-1 runs on the server with IP-address 192.168.132.1:9000, while the system with IP 192.168.132.2:9500 hosts the failover LMN.

Note: Deployment of the main and failover LMNs on the same host is not allowed!

The name of the failover LMN should comply with the following format: <name_of_the_main_node>-backup

Example:

SYSTEM-1-backup

In other words, if the primary LMN has the name SYSTEM-1, then the stand-by LMN will be SYSTEM-1-backup

You can display the name of the System’s LMN by carrying out the “show status” (“sh st”) command in the console terminal.

Failover and failback events in the System with Management Node redundancy unfold as follows:

management

{

address|listen "IP address:port_of_the_backup_MN"; };

management "SYSTEM-1"

{

address "192.168.132.1:9000";

management

{

listen "192.168.132.2:9500";

};

// other nodes

}; management "SYSTEM-1"

{

address "192.168.132.1:9000";

management

{

listen "192.168.132.2:9500";

};

// other nodes };

MVTS Pro Redundancy

MVTS Pro 1.5.0-40

p. 148 of 197

1. When the System starts, the primary LMN is the first to start up. The main USB dongle should be inserted into the server beforehand.

2. The failover LMN starts on the failover server with the duplicate USB dongle inserted. Once started the failover LMN establishes a link with the primary LMN and switches to standby operation where it does not interoperate with other functional nodes and does not read the USB dongle.

3. If the main LMN fails (the System alerts the operator to the event by an e-mail notification), the failover LMN switches to “active” mode which means:

• It reads the USB dongle.

• accepts connections from other nodes of the System.

• performs periodic checks if the link to the primary LMN server is restored.

4. All functional nodes of the System switch to interoperation with the failover LMN within 60 seconds. Meanwhile all set-up connections are preserved and newly arriving calls are processed.

5. Once the main LMN is alive again (this indicated by restored accessibility of the primary server), the failover LMN restores the link with the main LMN, stops interplay with other System nodes and returns to the standby mode.

6. All System nodes switch to interoperation the main LMN. All set-up connections are preserved and all newly arriving calls are processed.

7.6. DB AND WEB INTERFACE SERVER REDUNDNACY Owing to the MVTS Pro architecture specifics the DB unit is not a critical component and its failure does not affect the System overall operation.

When the System starts, the ScriptNode reads the entire DB, and further just keeps track of updates.

If the DB host fails, the System continues call handling, based on data as of the moment of the DB latest update. CDRs get saved to temporary files and pertinent data are later entered in the DB, when the connection is restored. Debug calls are not saved. To ensure data retention, unattended DB backup may be used.

However, to ensure additional reliability the user has an option to configure DB redundancy. To do this, fill in the proper settings for the failover database in the scripting node configuration file (parameters like dbms_*_slave, see 3.5.4) and set up the DB replication (see 7.10).

In a layout with a redundant DB, if the main DB fails, the scripting node switches over to the failover DB until the connection the main one is restored. CDR records will be entered into the failover DB. Meanwhile, the System will successively try to restore connection to the main DB. When the connection is restored, the scripting node switches over to the main database.

7.7. CASE STUDY: TWO SERVER SYSTEM REDUNDANCY

7.7.1. NODE DISTRIBUTION See an example of the two server redundancy configuration of MVTS Pro on Fig. 106.

MVTS Pro Redundancy

MVTS Pro 1.5.0-40

p. 149 of 197

Fig. 106 Nodes of primary and failover server

7.7.2. CONFIGURATION FILES Below are configuration files for the primary and failover servers of the System on Fig. 106. The IP-address of the main server is 192.168.132.1; the IP-address of the standby server is 192.168.132.2.

MVTS Pro Redundancy

MVTS Pro 1.5.0-40

p. 150 of 197

7.7.2.1. Primary server configuration 7.7.2.1.1. Configuration file phoenix.conf

database "/var/db/mvts3g/phoenix.db"; management "MVTS3G" {

listen "192.168.132.1:9000"; management { address "192.168.132.2:9000"; }; commandline { listen "0.0.0.0:7000"; }; h323gatekeeper {

"h323-gatekeeper-1"; };

sipregistrar {

"sip-registrar-1"; };

signaling { "signaling-1"; }; media { "media-1"; }; media { "media-2"; };

media { "media-3"; }; scripting { "scripting-1"; }; synchro { "synchro-1"; };

};

MVTS Pro Redundancy

MVTS Pro 1.5.0-40

p. 151 of 197

7.7.2.1.2. File system -1.conf

include "/etc/mvts3g/system-1.zone.conf"; include "/etc/mvts3g/system-1.registrar.conf"; include "/etc/mvts3g/system-1.signaling.conf"; include "/etc/mvts3g/system-1.scripting.conf"; include "/etc/mvts3g/system-1.media.conf"; include "/etc/mvts3g/system-1.synchro.conf";

MVTS Pro Redundancy

MVTS Pro 1.5.0-40

p. 152 of 197

7.7.2.1.3. Configuration file system-1.registrar.conf

h323gatekeeper {

common { loglevel "1"; }; h323gatekeeper "h323-gatekeeper-1" { scripting "scripting-1"; controllink { address { "192.168.132.1"; }; port "7101"; }; h323gatekeeper { address { "0.0.0.0"; }; port "1719"; gkname "MVTS3G"; allow_md5 "yes"; allow_chap "yes"; allow_plain "yes"; }; balancer { address { "0.0.0.0"; }; port "1720"; }; }; h323gatekeeper "h323-gatekeeper-2" { scripting "scripting-2"; controllink { address { "192.168.132.2"; }; port "7101"; };

h323gatekeeper { address { "0.0.0.0"; }; port "1719"; gkname "MVTS3G"; allow_md5 "yes"; allow_chap "yes"; allow_plain "yes"; };

MVTS Pro Redundancy

MVTS Pro 1.5.0-40

p. 153 of 197

h323gatekeeper { address { "0.0.0.0"; }; port "1719"; gkname "MVTS3G"; allow_md5 "yes"; allow_chap "yes"; allow_plain "yes"; }; balancer { address { "0.0.0.0"; }; port "1720"; }; };

};

sipregistrar {

common { loglevel "1"; }; address { "0.0.0.0"; }; port "5060"; expiration "1800"; sipregistrar "sip-registrar-1" { scripting "scripting-1"; controllink { address { "192.168.132.1"; }; port "7200"; }; }; sipregistrar "sip-registrar-2" { scripting "scripting-2"; controllink { address { "192.168.132.2"; }; port "7200"; }; };

};

MVTS Pro Redundancy

MVTS Pro 1.5.0-40

p. 154 of 197

7.7.2.1.4. Configuration file system-1.signaling.conf

signaling { synchro "synchro-1"; common { loglevel "1"; }; h323 { address { "0.0.0.0"; }; port "1721"; }; sip { address { "0.0.0.0"; }; port "5061"; }; signaling "signaling-1" { scripting "scripting-1"; controllink { address { "192.168.132.1"; }; port "7050"; }; }; signaling "signaling-2" { scripting "scripting-2";

controllink { address { "192.168.132.2"; }; port "7050"; };

}; };

MVTS Pro Redundancy

MVTS Pro 1.5.0-40

p. 155 of 197

7.7.2.1.5. Configuration file system-1.scripting.conf

scripting { common { loglevel "1"; }; environment { dbms_name "192.168.132.1@mvtspro"; dbms_user "rtu"; dbms_pswd "rtu"; }; scripting "scripting-1" { controllink { address { "192.168.132.1"; }; port "7710"; }; }; scripting "scripting-2" { controllink { address { "192.168.132.2"; }; port "7710"; }; }; };

MVTS Pro Redundancy

MVTS Pro page 156 of 197

7.7.2.1.6. Configuration file system-1.media.conf

media {

media "media-1" { signaling "signaling-1"; portrange "10000-19999"; }; media "media-2" { signaling "signaling-1"; portrange "20000-29999"; }; media "media-6" { signaling "signaling-1"; portrange "30000-39999"; }; media "media-4" { signaling "signaling-2"; portrange "10000-19999"; }; media "media-5" { signaling "signaling-2"; portrange "20000-29999"; };

media "media-3" { signaling "signaling-2"; portrange "30000-39999"; }; };

MVTS Pro Redundancy


7.7.2.1.7. Configuration file system-1.syncro.conf

7.7.2.1.8. Configuration file system-1.zone.conf

synchro { controllink { address { "192.168.132.1"; }; port "7711"; }; synchro "synchro-1" { }; };

zone {

zone "voip" {

"192.168.132.0/24"; }; };

MVTS Pro Redundancy


7.7.2.2. Standby server configuration 7.7.2.2.1. Configuration file phoenix.config

database "/var/db/mvts3g/phoenix.db"; management "MVTS3G" { address "192.168.132.1:9000"; management { listen "192.168.132.2:9000"; }; commandline { listen "0.0.0.0:7000"; }; h323gatekeeper { "h323-gatekeeper-2"; }; sipregistrar { "sip-registrar-2"; }; signaling { "signaling-2"; }; media { "media-4"; }; media { "media-5"; };

media { "media-6"; }; scripting { "scripting-2"; }; };

MVTS Pro Redundancy


7.8. REDUNDANCY USING LINUX HEARTBEAT The Linux Heartbeat software enables the deployment of the redundant System with the help of ‘shared IP’ mechanism. In the layout with Linux Heartbeat installed the software programmatically brings up the so-called “floating” IP address on the main server, where the SIP and H.323 registration-balancer nodes receive incoming calls. The Linux Heartbeat software checks the availability of the main and redundant servers, and in case the main server is offline, brings up the “floating IP” on the redundant server. This means that the calls will be transferred to the registration-balancer node on the redundant server. Once the main server is online again, the Linux Heartbeat software takes down the “floating” IP address on the redundant server and bring it up on the main one. The traffic once again goes trough the main server.

By way of example let’s take the following System configuration:

Fig. 107 Example of a redundant System layout using Linux Heartbeat

There are four servers present in this System layout:

1. The main and redundant TS coupled with the scripting node software (TS_master и TS_slave respectively).

2. The main and redundant server with the web-interface and DB modules (webdb_master и webdb_slave respectively).

7.8.1. CONFIGURATION OF TS AND SCRIPTING NODE SERVERS 1. Make sure that the TS configuration files are identical on the main and redundant

servers.

MVTS Pro Redundancy


2. Install the Linux Heartbeat software on the main and redundant servers using the following command: aptitude install heartbeat-2

3. Configure the Linux Heartbeat software as follows:

On the main TS server:

File /etc/ha.d/ha.cf

File /etc/ha.d/haresources

On the redundant TS server:



Create the /etc/ha.d/authkeys file on the main and redundant server as follows:

4. Create the file mvts3g-server-pro_reconfig in the /etc/init.d/ directory

on the main and redundant servers:

auth 1 1 sha1 strong-password

TS_master IPaddr::192.168.131.245/24/eth0 mvts3g-server-pro_config

udpport 1659 ucast eth0 192.168.131.60 node ts_master node ts_slave logfacility local7# syslogfacility logfile /var/log/ha-log debugfile /var/log/ha-debug keepalive 1 warntime 2 deadtime 5 initdead 15 auto_failback on

TS_master IPaddr::192.168.131.245/24/eth0 mvts3g-server-pro_config

udpport 1659 // the port to query the Heartbeat state on the // main and redundant TS servers (the port number // must be the save on both servers) ucast eth0 192.168.131.242 node ts_master node ts_slave logfacility local7# syslogfacility logfile /var/log/ha-log debugfile /var/log/ha-debug keepalive 1 warntime 2 deadtime 5 initdead 15 auto_failback on

MVTS Pro Redundancy


On transfer of IP address to another server the Linux Heartbeat software invokes re-configuration of TS modules, so that the registration-balancer nodes reconnected to the new address.

7.8.2. CONFIGURATION OF WEB+DB SERVERS 1. Install Linux Heartbeat software on the main (webdb-master) and redundant (webdb-

slave) server using the command: aptitude install heartbeat-2

2. Configure the Linux Heartbeat as follows:

On the main WEB+DB server:



#!/bin/sh start () { KIND=” mvts3g-server-pro_reconfig” echo “Start” spawn telnet localhost 7000 expect {*mvts3g|> } send "config /etc/mvts3g/system-1.conf\r" expect {*mvts3g|> } send "quit\r" } stop(){ KIND=” mvts3g-server-pro_reconfig” echo “Done” } restart(){ stop start } case “$1” in start) start ;; stop) stop ;; restart) restart ;; esac exit $?

udpport 1680 // the port to query the Heartbeat state on the // main and redundant WEB+DB servers (the port // number must be the save on both servers) ucast eth0 192.168.131.243 node webdb-master node webdb-slave logfacility local7# syslogfacility logfile /var/log/ha-log debugfile /var/log/ha-debug keepalive 1 warntime 2 deadtime 5 initdead 15 auto_failback onwebdb-master

MVTS Pro Redundancy


On the redundant WEB+DB server:



Create the /etc/ha.d/authkeys file on the main and redundant server as follows:

3. Add the IP addresses of both servers to the /etc/hosts file an each server:

4. Configure database replication. For further information about replication see section

7.10.

7.9. DB BACKUP AND RECOVERY DB backup ensures data retention and database structure preservation and allows recovery from bad situations caused by a corrupted file system, server HDD crash or accidental clearing of information from the DB.

7.9.1. DB SPECIFICS AFFECTING BACKUP POLICY The MVTS Pro DB consists of a multitude of tables that include:

1. GUI tables.

2. TM object properties (configuration) tables (gateways, dial peers, user tables etc.).

3. Call log and report tables.

4. CDR tables with monthly call data.

5. The mvts_cdr table, which does not contain data but integrates all monthly CDR tables.

Tables mentioned in items 1 and 2 are InnoDB tables of the so-called transaction-safe type typical for MySQL. Data from tables of such type are stored in one or several InnoDB data files. The backup of such tables is carried out with the help of the mysqldump utility organic to the MySQL database software. When run, the mysqldump utility creates an SQL

auth 1 1 sha1 strong-password

127.0.0.1 localhost 192.168.131.61 webdb-master 192.168.131.243 webdb-slave

webdb-master IPaddr::192.168.131.66/24/eth0

udpport 1680 // the port to query the Heartbeat state on the // main and redundant WEB+DB servers (the port // number must be the save on both servers) ucast eth0 192.168.131.61 node webdb-master node webdb-slave logfacility local7# syslogfacility logfile /var/log/ha-log debugfile /var/log/ha-debug keepalive 1 warntime 2 deadtime 5 initdead 15 auto_failback onwebdb-master

webdb-master IPaddr::192.168.131.66/24/eth0

MVTS Pro Redundancy


script for replication of the database structure or its individual tables and filling them with pertinent data.

The nature of data stored in tables of items 3 and 4 does not require “transaction safety”, therefore this data is stored in the tables of myISAM type (ISAM = indexed sequential access method). Data from such tables are saved to special files. Backup of myISAM tables can be performed both by means of the mysqldump utility and through simple replication of structure, data and index files in the file system. As CDR tables are the only ever growing in size tables and the resulting size of data retention files may prove to be formidable it is reasonable to use the “replicate-in-the-file-system” method of backup for CDR tables.

Call log tables contain no critical data and information from them is not saved during a backup.

The mvts_cdr table is of the special type MERGE. It incorporates no data and only provides a convenient data handling interface for monthly CDR tables. To put it plainly, this table allows retrieval of data according to any criteria for whatever period of time regardless of in which CDR table and for what month the necessary information is actually located. During a backup only the mvts_cdr table structure is preserved.

In addition to the tables the DB includes several views and stored procedures also backed up with the help of the mysqldump utility.

7.9.2. BACKUP TOOLS AND UTILITIES Database maintenance utilities are stored on the DB server in the directory /usr/local/lib/mvtspro. The same directory contains files pertaining to DB backup:

backupdb.conf – is the DB backup procedure configuration file.

backupdb-cron – an example cron job (for cron configuration directories /etc/cron.daily, /etc/cron.hourly, etc. determining cron scheduling).

backupdb.php – is the DB backup script.

restoredb.sh – is a script for DB restoration from a backup copy. ssh_auth_keys.sh is a script for SSH authentication keys generation and installation of the open key on a remote server. Installation of the key on the remote server allows setting up SSH for password-free access to the server.

7.9.3. CONFIGURING SSH PUBLIC KEY AUTHENTICATION The DB backup copying can be done both to the local disk drive and to a remote server (over ssh or scp). For the sake of a greater safety it is strongly recommended that a remote server backup method be used. If you still opt to save backup copies on the DB server it is advisable to add a special purpose hard disk drive to the server.

For unattended DB backup by means of the cron utility with saving the backup copy to a remote server password-protected access to the remote server is impossible, therefore it is necessary to set up SSH for open-key authorization. To enable open-key authorization, working as root, launch the ssh_auth_keys.sh script.

./ssh_auth_keys.sh

The system will display a message saying that the script was started by the root user.

Local user: root

If RSA keys had not been created for the root user yet, the script will generate them:

Generating public/private rsa key pair.

Your identification has been saved in /root/.ssh/id_rsa.

Your public key has been saved in /root/.ssh/id_rsa.pub.

The key fingerprint is:

MVTS Pro Redundancy


aa:bb:cc:dd:ee:ff:aa:bb::cc:dd:ee:ff:aa:bb:cc root@db-server

Further you will be prompted to enter the name or IP address of the remote server and logon name and password for the user account in the name of which backup copy files will be saved on the remote server:

Enter remote host: backup-server

Enter remote user: root

Copy public key to remote host

(Enter password for user spatar@ora-testing1 when asked)

...

Password:

To see if the open-key authentication functions after the script execution is completed, type at the command prompt:

ssh root@db-server

For the arguments of the ssh command, type user name in lieu of “root” and provide the remote server name or IP address in lieu of “db-server”. If you are not prompted for a password and an access session starts, the open key authentication functions properly.

7.9.4. CONFIGURING DB BACKUP Open the backupdb.conf configuration file for editing and enter the following data:

host= name or IP address of the DB server (always use the name “localhost”).

user= DB user.

password= DB user password.

db= DB name.

tmpdir= directory for temporary files. The directory must have enough free space to accommodate the DB backup of a forecasted size (to be more specific, there should be enough free space to accommodate all files of a one-time DB backup).

desthost= name or IP address of the remote server intended for DB backup storing. If there is no remote server and it is planned to save DB backup files locally, i.e. to the DB server, delete this line or comment it as shown below:

#desthost=

destuser= user name on the remote server.

destdir= target directory for DB backup on the remote or local server (depending on the value of the parameter desthost). This directory must be accessible for writing to the user who performs the DB backup (the user whose name is entered in the parameter destuser, when a remote server is used to accommodate the backup). If there is no such a directory it will be created automatically.

rotate – the number of directories with latest DB backups in the directory destdir. Count starts from 1 and all subsequent backup copies will be written to the directory with the next number. As soon as the number of folders equals the value of the parameter rotate, the least numbered directory is removed.

backup_prefix – prefix for names of folders with DB backup copies (for example, backup).

backup_cdrs – flag that can be 1 or 0. The flag determines whether monthly CDRs will be backed up. When the flag is set to 1 monthly CDRs are backed up, when set to 0, there will be no CDR backups.

tables_no_data is a comma-separated list of tables that should not be included in backup copies. The table mvts_cdr is the one that needs to be included in the list.

MVTS Pro Redundancy


7.9.5. LAUNCHING BACKUP The script backupdb.php, that performs the DB backup procedure, should be launched by the user root or a member user of the group mysql, as the correct performance of the script requires the mysql group rights.

When run, the utility backupdb.php creates the files tab1.sql and tab2.sql with tables and other DB objects except the monthly CDR tables. The script makes copies of structure files, data files and index files for monthly CDR tables that have changed since the time of previous execution. In addition the utility creates the file cdr.info with information about the status of saved CDR tables.

7.9.6. UNATTENDED BACKUP ARRANGEMENTS DB backup automation arrangements involve the use of the Linux standard cron daemon. For example, if you wish to perform the backup procedure hourly copy the file backupdb-cron to the directory /etc/cron.hourly or create a symbolic link to backupdb-cron there:

cp /usr/local/lib/mvtspro/backupdb-cron /etc/cron.hourly/

or ln -s /usr/local/lib/mvtspro/backupdb-cron /etc/cron.hourly/backupdb-cron

7.9.7. DB RECOVERY PROCEDURE The script restoredb.sh performs restoration of the DB from a backup copy. The script should be launched by the user root or a member user of the group mysql, as the correct functioning of the script requires the mysql group rights.

For a DB recovery:

1. Copy the DB backup files to the DB server.

2. Copy the restoredb.sh script to the same directory with the backup files. Run the script entering the name of the recovery DB as the command argument:

./restoredb.sh rtu_restored

Note: Remember the entered recovery DB name must not coincide with the name of the operational DB. This requirement is explained by the necessity to protect the operational DB from accidental damage.

Note: When launched the restoredb.sh script causes the DB engine restart

You can launch the restoredb.sh script from any working directory if you indicate the file path to the backup copy directory in the second command argument, for example:

./restoredb.sh rtu_restored /path/to/backup

7.10. DB REPLICATION Replication is a process of backing up information by transferring it from the main server (master replication server) to one or several slave servers to ensure consistency between the DB replicas.

In MVTS Pro, replication is used to provide additional fault-tolerance when interoperating with the DB. In case the main server fails, the System switches to the slave server with the redundant DB.

MVTS Pro Redundancy


7.10.1. REPLICATION TYPES Replication can be classified in a variety of ways:

1. By the direction of replication:

o Master-slave replication — one-way replication when changes in the master DB are transmitted to the slave DB only.

o Master-master replication — two-way replication when two databases are synchronized with each other.

2. By synchronism:

o Synchronous replication — the DBMS replicates modified data within the same transaction. The changes take no effect until acknowledged by both the local and the remote server. In other words, there is only one version of data at every instance of time.

o Asynchronous replication — the DBMS replicates the modified data after some time, rather than within a transaction. When asynchronous replication takes place, the databases may not be identical for some time.

3. By replication formats:

o Row-based replication — the database management systems share and apply modified rows of the table.

o Statement-based replication — the database management systems share and execute SQL operators.

MVTS Pro uses two-way master-master asynchronous row-based replication. To arrange for mutual master-master replication, the user should configure a one-way master-salve replication on each of two MySQL servers.

7.10.2. REPLICATION CONFIGURATION Before configuring replication, make sure that the databases on both servers are identical. The easiest way to synchronize data is to copy one DB to the other server entirely. Disconnect all applications from the databases so that the DBs remain unchanged during the configuration process. Additionally, halt the TS while you are setting up replication.

1. Make a snapshot of the main DB using mysqldump:

#> mysqldump --allow-keywords --triggers --routines --opt --hex-blob --databases mvtspro >mvtspro.sql

2. If the DB on the second server already exists, make a back-up copy of it first, using the command from step 1. Remove the existing DB from the second server:

3. Copy the mvtspro.sql file, created after step 1, to the second host and create a DB from the SQL script:

#> mysql <mvtspro.sql

4. Create a repl user for both databases:

5. Stop the slave process of both DBs (no error will occur even if no such process exists) and reset the binary logs:

#> mysql mysql> grant replication slave on *.* TO 'repl'@'%' identified by 'slavepass';

#> mysql mysql> drop database mvtspro;

MVTS Pro Redundancy


6. Stop both DBs:

#> invoke-rc.d mysql stop

7. Create a configuration file /etc/mysql/conf.d/mvtspro-repl.cnf on one of the hosts. The contents of the file should be as follows:

8. Create a configuration file /etc/mysql/conf.d/mvtspro-repl.cnf on the other host. The contents of the file should be as follows:

#> mysql mysql> stop slave; mysql> reset slave; mysql> reset master;

[mysqld] # # * Logging and Replication # server-id = 10 #binlog-format = row log_bin = /var/log/mysql/mysql-bin.log expire_logs_days = 30 log-slave-updates auto-increment-increment = 10 auto-increment-offset = 1 replicate-same-server-id = 0 report-host = name-of-this-host replicate-do-db = mvtspro replicate-ignore-table = mvtspro.mvts_debug_call replicate-ignore-table = mvtspro.mvts_debug_call_log replicate-ignore-table = mvtspro.mvts_debug_registration master-host = name-of-the-other-host master-user = repl master-password = slavepass sync_binlog = 1

MVTS Pro Redundancy


The distinctions between the two files are in italics.

9. Start both databases:

#> invoke-rc.d mysql start

10. Start the slave process in both databases:

11. Use the following MySQL commands to monitor the state of the replication process:

#> mysql mysql> show master status; mysql> show slave status;

#> mysql mysql> start slave;

[mysqld] # # * Logging and Replication # server-id = 20 #binlog-format = row log_bin = /var/log/mysql/mysql-bin.log expire_logs_days = 30 log-slave-updates auto-increment-increment = 10 auto-increment-offset = 2 replicate-same-server-id = 0 report-host = name-of-this-host replicate-do-db = mvtspro replicate-ignore-table = mvtspro.mvts_debug_call replicate-ignore-table = mvtspro.mvts_debug_call_log replicate-ignore-table = mvtspro.mvts_debug_registration master-host = name-of-the-other-host master-user = repl master-password = slavepass sync_binlog = 1

Appendices


8. APPENDIX A. METACHARACTERS, REGULAR EXPRESSIONS AND NUMBER TRANSFORMATION

8.1. USE OF METACHARACTERS IN SEARCH The comparison operators Like and Not like allow the use of patterns in search. Search patterns may include metacharacters ‘%’ and ‘_’.

The character ‘%’ is used to denote any character string including an empty string that is a zero-length string. For example, the search pattern ‘123%’ corresponds to character strings starting with ‘123’. The pattern ‘%123’ corresponds to all character strings that end with ‘123’. The pattern ‘%123%’ corresponds to character strings that include the sub-string ‘123’. The meta-symbol ‘%’ used individually corresponds to all character strings including empty strings.

The underlining sign ‘_’ is used to mean a single arbitrary character. Therefore, the pattern ‘_123’ corresponds to all character strings starting with an arbitrary character followed by ‘123’ (for example, ‘0123’, ‘1123’ and so on.) The same meta-symbol can be used with reference to string inclusions that occur in strings that start and end with definite characters and include an indefinite one, for example ‘1_23’. A search pattern can comprise any number of metacharacters. For example, the search pattern %1_23% corresponds to character strings ‘04513234’, ‘1823’, ‘11123456’ etc.

When you use the comparison operator Like the System will display all data that correspond to the search pattern. With the operator Not like the System will output all data that do not correspond to the search pattern.

8.2. USE OF REGULAR EXPRESSIONS IN SEARCH Regular expressions provide a powerful tool for defining information search criteria. Regular expressions used in search consist of alphanumeric characters and metacharacters the description of which follows

Metacharacters Description Character match . Any character

[] Any characters matching those in square brackets

Location ^ Beginning of character string (string head) $ End of character string (string tail)

Quantity matching ? Matches zero or one occurrence of the previous expression * Matches zero or more occurrences of the previous expression + Matches one or more occurrences of the previous expression {x} x occurrences of the previous expression {x,} x or more occurrences of the previous expression

Appendices


{x,y} At least x occurrences, but not more than y occurrences of the previous expression

Alternation | The alteration operator that matches either the expression before or

the expression after the operator

Grouping ( ) Logical grouping

To instruct the system to treat a metacharacter as an ordinary character, precede the metacharacter with a backslash (“\”).

Examples

Suppose, you are looking for CDRs involving numbers beginning with “7095123”or “7095124” or “7095125” and ending in any 4 digits. In this case you should use the following regular expression pattern.

^7095(123|124|125).{4}$

As a result, the system will display all the records related to calls involving numbers 70951231234, 70951243333, 70951254567, 70951255678, etc.

Suppose you are looking for all numbers that begin with “7095” and end in either 1, 2, or 3. You can use the following regular expression pattern for the search.

^7095.*[123]$

As a result, this pattern will match “70951111111,” “709500002,” “70951234563”, etc.

In case you want the system to display all the records involving numbers beginning with "345" and followed by at least 1 but not more than 6 digits. Use the following regular expression pattern.

^345.{1,6}$

As a result, this pattern will match "3450," "3451111," "345888888", etc.

8.3. NUMBER TRANSFORMATION The purpose of number transformation is bringing the calling or called telephone number to the necessary format. Setting number transformation rules involve the use of regular expressions. As a rule a transformation expression consists of two parts – a search pattern and a replacement string delimited by the slash «/» character.

Use the brackets «( )» to create separate sections within the search pattern. The replacement string can include a replacement sub-string for a section. The replacement substring can be preceded by the search pattern section number followed by the backslash symbol «\».

Appendices


The most common number transformation tasks are removal, addition and replacement of number prefixes.

Examples Goal:

Remove prefix 1234 from number 123456789

Transformation pattern:

^1234(.*)/\1

(remove prefix 1234, that precedes the first section, i.e. \1)

Result:

123456789 → 56789

Goal:

Remove prefix 1234# form number 1234#123456 and replace it with prefix 0000#


^1234#(.*)/0000#\1

(replace prefix 1234# that precedes the first section with prefix 0000#)

Result:

1234#1234567 → 0000#1234567

Goal:

Add prefix 0000# to all numbers


^(.*)/0000#\1

(append prefix 0000# to the beginning of any string, i.e. before section 1)

Result:

1234567 → 0000#1234567

7654321 → 0000#7654321, etc.

If it is necessary to separate the replacement sub-string from the following symbols, use the following notation: \g<#>, where # is the number of the section in the search pattern.

Goal:

Add postfix #5555 to all numbers


^(.*)/\g<1>#5555

(append postfix 0000# to the ending of any string, i.e. after section 1)

Result:

1234567 → 1234567#5555

7654321 → 7654321#5555, etc.

Appendices


The same goal can be attained through the use of different translation patterns:

translation pattern ^ 1 2 3 4 # / 0 0 0 0 # is equal in effect to pattern ^ 1 2 3 4 # ( . * ) / 0 0 0 0 # \ 1 (replace prefix 1234# with prefix 0000#).

translation pattern ^ / 0 0 0 0 # is equal to pattern ^ ( . * ) / 0 0 0 0 # \ 1 (add prefix 0000# to all numbers).

One string can include several translation expressions delimited by semicolons (;). Of all available expressions in the string the first that matches the number is used for transformation.

To explain this, consider the following number transformation rules:

^ 7 8 3 1 2 / 0 1 # (add prefix 01# to numbers beginning with 78312).

^ 7 8 3 1 / 0 2 # (add prefix 02# to numbers beginning with 7831).

Such number transformation expression can be written as follows:

^ 7 8 3 1 2 / 0 1 # ; ^ 7 8 3 1 / 0 2 #

For the number 78312555555 the application will apply the first pattern and as a result prefix 01# will be added to the number (01#78312555555). At the same time the second expression will be used for transformation of the number 78315555555, and the prefix 02# will be added to the number (02#78315555555).

Along with the patterns based on regular expressions you can use several additional keywords:

the keyword rand(n) replaces itself with a random n-digit number. n may take values from 0 to 99. For example, any number in the rule ^ ( . * ) / ( 1 2 3 ) r a n d ( 2 ) is translated into such numbers as 12389 or 12322, where the last two digits are random.

the pattern ^$ matches an empty SRC number. This pattern may be used in the search pattern only. For example, the rule ^ $ / 1 2 3 will translate all empty SRC numbers into number 123. Replaces the obsolete blank keyword.

8.4. TIPS AND TRICKS FOR REGULAR EXPRESSIONS To speed up regexp processing and, consequentially, the overall System performance the System administrator is encouraged to adhere to the following rules:

• Do not indiscriminately use the braces “()” in regexp patterns without number translation (e.g. in Orig. allowed SRC numbers). By way of example, use ^123456.* instead of ^123456(.*).

• Delimit several regexp patterns with “|”, not with “;” in all cases but for the DP DST prefix allow patterns parameter. By way of example, use ^123.*|^456.*|789.* instead of ^123.*;456.*;^789.*.

• Delimit the regexps with semicolons “;” only in the DP DST prefix allow patterns parameter, as it is only valid way to supply DST numbers to the dialpeers.

• When limiting the maximum number length, use a pattern like xxx.{n} in the allowed numbers field, where xxx is the initial digits of the number and n is the maximum number length minus the number of initial digits. For example, to limit the number starting with 1234 with 12 digits use the following pattern: ^1234.{8}.

Appendices


9. APPENDIX B. CODEC LIST GENERATION IN MVTS PRO To ensure maximum flexibility of media transit through the Traffic Switch, the System provides for setting individual media proxy modes for each dial peer. The procedure is as follows:

1. It is possible to select media proxy mode for each dial peer individually from the drop-down list Override equipment proxy mode in the dial peer properties form (Termination → Dial peers → Advanced settings). The dial peer setting overrides similar setting of the terminator.

2. If the parameter is not defined, the System checks the compatibility of media proxy modes configured for the originator and terminator. To determine the resulting proxying mode the following rules are used:

• The proxying mode of the dial peer overrides the proxying mode of terminator.

• If the proxying mode of the dial peer is not defined (a blank option is selected), the valid settings for the terminator are those, specified during the configuration of the terminator.

• The list of proxying modes sorted in descending order of precedence is shown below. Of two modes, the System chooses the mode with higher precedence as the resulting mode.

Proxy media

Do not proxy media whenever possible, use first originator codec

Do not proxy media whenever possible, use first common codec

Do not proxy media whenever possible

• The Do not proxy media mode is compatible with the Do not proxy media и Do not proxy media whenever possible modes only.

• If proxying modes are incompatible (for example, the Proxy media mode is selected for the originator, and the Do not proxy media – for the terminator, or vice versa), then this route (gateway combination) is discarded.

• If all routes are discarded due to proxying mode incompatibility, the call is canceled.

3. Otherwise Traffic Manger generates a list of codecs for the originator based on the proxy mode and codec list generation settings, configured for the gateways (see Table 8). The list of audio codecs (for an audio call) is generated separately from the list of video codecs (for a video call).

Table 8 Actions of the Traffic Manager with the originator codecs depending on the proxying mode

Media proxy mode Traffic Manager actions

Proxy media




Traffic Manager returns a list of codecs where codecs reported by the originator matching those configured for the originator in the DB are moved to the beginning of the list. Non-matching codecs, configured in the DB, are placed at the end of the list. Non-matching codecs reported by the originator, are discarded. Codecs in the sub-set of common codecs are ordered in the same way as they were arranged in the codec list received from the originator. The order of codecs beyond the sub-set of common codecs is determined by the precedence value configured for each codec.

Appendices



Do not proxy media Traffic Manager returns a list of codecs reported by the originator, matching the originator’s codecs, configured in the DB. The order of codecs in the list is the same as the order of codecs reported by the originator. In case no matching codecs are found, the call is terminated with the error addRoute> No matching media codecs.

Note: Codec conversion for video codecs (H.261, H.263) is not implemented, that’s why the list of video codecs is always generated as if “Do not proxy media” is selected.

4. The System checks if the checkbox Always discard non-matching codecs is selected.

4.1. If the checkbox is selected, the System re-generates the list accordingly (see Section 6.2.1), and the codec list preparation settings of the terminator are ignored.

4.2. If the checkbox is not selected, the System applies the codec list preparation method selected for the terminator, in keeping with the current proxy mode (see Table 9 and Section 6.2.1).

Table 9 Actions of the Traffic Manager with the terminator codecs depending on the proxying mode


Proxy media



Available methods of codec list generation:

• No sorting

• Matching codecs first

• Non-matching codecs discarded

• Return first matching only

• No matches — no sorting

Do not proxy media Available methods of codec list generation:

• Non-matching codecs discarded (for all cases except Return first matching only)

• Return first matching only


The codec list generation settings of the terminator are invalid.

Note: The list of video codecs is always generated using the method Non-matching codecs discarded.

5. If no codecs common for originator and terminator are found and media proxying is enabled, codec conversion takes place.

Appendices


10. APPENDIX C. DEFAULT GATEWAYS When several subscribers connect to the System, their gateway settings differ only in billing parameters. To ease the configuration of such gateway, MVTS Pro features default gateways, i.e. separate template gateways with all-in-one settings, through which the devices register. In such layout the billing information (registration username, password, etc. pertaining to each subscriber) is stored on the RADIUS server, preventing the duplication of the data in the System. The System operation procedure in such a case unfolds as follows:

• System administrator creates a default gateway (object Equipment), selects Default gateway in the Equipment type combo box and selects the Enable RADIUS authentication checkbox. To complete the configuration, the administrator also needs to specify the allowed and disallowed registration username patterns (the Allowed registration username patterns/Disallowed registration username patterns parameter) and the precedence of the default gateway (the Default gateway precedence parameter).

• On arrival of a registration request the System first checks if the name of the registering device matches any of the names (Registration username parameter) of configured gateways. If not, the System draws up a list of default gateways, sorted by precedence (the value of the Default gateway precedence parameter). If the registration name of the device, which issued the request, matches any pattern defined in the Allowed registration username patterns, and does not match any patterns defined in the Disallowed registration username patterns, then such gateway is included into the list of default gateways. If the list is not empty, the registering device is authenticated through the RADIUS server using the data of the first appropriate default gateway on the list and the device’s registration name.

• The System supports the receipt of the registration usernames and passwords under the following methods:

o For the SIP-equipment the registration username and password is authenticated using Digest Authentication.

o For the H.323-equipment the following authentication methods are available:

The H.323-gateway sends the registration username and password in plain text. The System may forward them to the RADIUS server in plain text (if the parameter System global settings -> Encrypt H.323 plain text password = 0), or may first encrypt it with the secret key (the Secret key parameter), defined in the RADIUS server settings. In the latter case the Encrypt H.323 plain text password parameter should be equal to 1. By default the Encrypt H.323 plain text password parameter is 1.

The H.323-gateway sends the registration username and password encrypted using md5. The System forwards them to the RADIUS server unmodified.

The H.323-gateway sends the registration username and password encrypted using Cisco CHAP. The System forwards them to the RADIUS server unmodified.

• The System creates a virtual gateway inheriting all the settings of the default gateway. If the gateway is a terminator, the System additionally creates a dial peer with the virtual gateway included into the dial peer’s Equipment list. For the terminator it is also possible to specify the DST numbers source in the Phone numbers source parameter.

• The call handling procedure for the virtual gateway, cloned from the default gateway, does no differ from the call handling for the gateways, entered into the DB regularly.

Appendices


11. APPENDIX D. SIGTRAN NODE LIMITATIONS At the moment the SIGTRAN interoperation node has the following limitations:

Limitation Possible effects

M3UA

The ‘Network Appearance’ and ‘Routing Context’ parameters are mandatory

1) This limitation does not conform to the RFC4666 specification. As per the specification the ‘Routing Context’ and ‘Network Appearance’ parameters are optional.

2) AS the AS properties on the ASP and SGP side should be the same, and the configuration capabilities of the SGW equipment may be restricted, it may limit the overall number of available System configurations.

For example, on the SIGTRAN gateway the AS and its Routing Key are not configured explicitly, and there is no option to set the Routing Context and Network Appearance.

The ‘Network Indicator’ parameter is not used for routing

May cause routing errors when different signaling points have the same point codes.

The node does not support several local (logical) signaling points

The concept of logical signaling points is a basis for supporting complex configurations by the SIGTRAN interoperation node. For example, when one node is connected to several SS7 switches (using one or several SGWs) and may look for them as one or several SS7 switches, depending on the configuration.

Presently the support of several SS7 switches within one TS is implemented by setting up several SIGTRAN interoperation nodes, one node for each local SS7 switch.

ISUP-R

The overlap signaling is not supported

May cause call routing errors.

Message segmentation is not supported

May cause problems with calls where segmented messages are used. However, segmented messages are rarely applicable, so the problems are unlikely.

Continuity testing is not supported May cause problems when continuity testing is used by the remote switch. For example, the switch may stop using the circuits, which failed the test, and eventually decrease the trunk capacity to zero.

Call suspend and resume (SUS/RES) is not supported

The features basing on this functionality are not supported.

Signal propagation delay detection is not supported


Automatic reconnect is not supported


Unrecognized data processing is not supported


Unexpected data handling is not supported


MTP congestion control is not supported


Automatic Congestion Control is not supported


Appendices


User subsystem readiness management is not supported


Redundancy

A case of SIGTRAN gateway failure was not tested. It is strongly recommended to set up a redundant gateway and configure the SIGTRAN interoperation node accordingly.

The failure of a non-redundant SIGTRAN gateway will most like cause problems.

Initialization of the SIGTRAN interoperation nodes and switching between them requires some time for exchanging messages with MGW, SGW and a remote SS7 switch.

Usually the message exchange time is little, when there are no problems in the network. Generally it is defined by the delays in responses from gateways and remote signaling points, as well as the scale and complexity of configuration. Calls, active at the time of the switch, are terminated.

Configuration

Changing configuration of the SIGTRAN interoperation node ‘on the fly’ (without node restarting) is not supported

To change the SIGTRAN interoperation node configuration stop the node and start it with the new configuration applied. All current calls get terminated and no calls may pass through the System until the node is online with the new configuration.

Appendices


12. APPENDIX E. MVTS PRO – RADIUS INTERACTION The three types of services that the MVTS Pro may request from a RADIUS server are authorization, accounting and routing.

In all the three cases the request initiator is the MVTS Pro session controller. The RADIUS server may initiate a communication exchange with the MVTS Pro server in one situation only: when it requires of the MVTS Pro to terminate a call due to depletion of the account balance.

With the authorization and routing service the MVTS Pro sends the RADIUS server an AccessRequest of the appropriate type and receives either an AccessAccept or AccessReject. During an accounting exchange the MVTS Pro originates an AccountingRequest (Code 4) while the RADIUS server replies with AccountingResponse.

When the exchange initiator is the RADIUS server, it sends the MVTS Pro DisconnectRequest (type 40), and the MVTS Pro responds with DisconnectAck(type41) for session termination or with DisconnectNack(type 42) for the request rejection.

Below is a detailed description of the MVTS Pro-RADIUS server exchange content.

12.1. REGISTERING ENDPOINT AUTHORIZATION The MVTS Pro sends the RADIUS server this type of authorization request on arrival of RegistrationRequest received by the MVTS Pro from the registering endpoint.

Table 10 AccessRequest structure in authorization request for a registering endpoint

IETF attr. No.

Attribute name VSA attr. No.

Description Data format Mandatory/Optional

(M/O)

4 NAS-IP-Address Local MVTS Pro address Defined by the «radius_nas_ip_addr» parameter from the config file, by default - «127.0.0.1»

M

5 NAS-Port-Type Local port type always 0 M

6 Service-Type Service type always 1 M

26 xpgk-request-type 1 Authorization request type

always «user» M

1 User-Name User name string M

2 User-Password Password encrypted through MD5 or in the plain form

BYTE[16] or string O

26 xpgk-md5-auth 1 Password encrypted through MD5


3 CHAP-Password CHAP-encrypted password

string O

60 CHAP-Challenge Unique CHAP identifier string O

104 Digest-Realm Describes a component of protected RADIUS server realm

string O

Appendices


IETF attr. No.


Description Data format Mandatory/Optional

(M/O)

105 Digest-Nonce Used as a component for Digest authorization scenario

string O

109 Digest-URI Unique URI for Digest authorization scenario

string O

108 Digest-Method Method type for Digest authorization scenario

string O

103 Digest-Response Used as a component for Digest authorization scenario

string O

115 Digest-Username User name string M

Expected responses are AccessAccept and AccessReject

On receipt of AccessReject the authorization is deemed rejected and the MVTS Pro sends the registering user RegistrationReject with the cause SecurityDenial.

12.2. PRE-ROUTING CALL AUTHORIZATION The MVTS Pro sends the RADIUS server this type of authorization request before forwarding the call to destination along the selected path.

Table 11 AccessRequest structure in pre-routing call authorization

IETF attr. No.


Description Data format Mandatory/

Optional (M/O)

1 User-Name User name string, If the username contains the «$ani$» metasymbol, the metasymbol is replaced with an outgoing SRC number

M

2 User-Password Password encrypted using MD5, or in the plain form

BYTE[16] or string M


M

5 NAS-Port Local MVTS Pro port always 0 M



7 Framed-Protocol This attribute indicates the framing to be used for framed access.

always 1 M

Appendices


IETF attr. No.



Optional (M/O)


always "number" M

30 Calling-Station-Id SRC number string M

31 Called-Station-Id DST number string M

26 h323-conf-id 24 Conference ID h323-conf-id=<HEX[16]>

M

26 h323-call-id 1 Call ID h323-call-id=<HEX[16]>

M

26 h323-gw-id 33 Originator ID for the RADIUS server

h323-gw-id=<string> M

26 h323-gw-address 23 Originator IP address h323-gw-address=<IP-address>

M

26 xpgk-src-number-in

1 SRC number, received in a SETUP packet

xpgk-src-number-in=<number>

M

26 xpgk-src-number-out

1 SRC number, sent to the terminator

xpgk-src-number-out=<number>

M

26 xpgk-dst-number-in

1 DST number, received in a SETUP packet

xpgk-dst-number-in=<number>

M

26 xpgk-dst-number-out

1 DST number, sent to the terminator

xpgk-dst-number-out=<number>

M

44 Acct-Session-Id Unique ID string M

26 xpgk-record-id 1 Unique ID xpgk-record-id=<string>

M

26 xpgk-route-retries 1 Current retry number always 1 M

26 h323-remote-id 1 Terminator ID for the RADIUS server

h323-remote-id=<string>

M

26 h323-remote-address

23 Terminator IP address h323-remote-address=<ip-address>

M

26 xpgk-md5-auth 1 MD5 password taken from SETUP registrationRequest

xpgk-md5-auth=<username/<timestamp>>/HEX[16]

O


string O



string O


string O


string O

108 Digest-Method Method type for Digest string O

Appendices


IETF attr. No.



Optional (M/O)

authorization scenario


string O

115 Digest-Username User name string O

Expected responses are AccessAccept and AccessReject

Table 12 Content of AccessAccept response from RADIUS server in pre-routing call authorization

IETF attr. No.



Optional (M/O)

26 h323-credit-time 102 Session max length h323-credit-time=<time, sec>

O

26 h323-return-code 103 h323-return-code (if the field is not present or its value is 0, 13, 51 or 52, the authorization is considered successful, otherwise the call will be finished)

h323-return-code=<number>

M

27 Session-Timeout Session max length integer O

26 h323-ivr-in 1 Used as User-Name in Accounting packets

string O

A receipt of AccessReject means a negated authorization and the route is rejected with the appropriate local disconnect code (LDC).

12.3. ACCOUNTING REQUEST

12.3.1. ACCOUNTING START RECORD The MVTS Pro sends the RADIUS server the Accounting Start record upon arrival of a call (incoming leg) or on sending SETUP to the destination gateway (outgoing leg).

Request type – AccountingRequest (Code 4)

Table 13 Structure of Accounting Start record forwarded to RADIUS server

IETF attr. No.



Optional (M/O)

1 User-Name User name string, If the username contains the «$ani$» metasymbol, the metasymbol is

M

Appendices


IETF attr. No.



Optional (M/O)

replaced with an outgoing SRC number


M



41 Acct-Delay-Time Time (in sec), during which the client will try to send Accounting packet

always 0 M



26 h323-setup-time 25 SETUP receipt time h323-setup-time=< hh:mm:ss.uuu t www MMM dd yyyy>

M

26 h323-connect-time 28 Connect time h323-connect-time=< hh:mm:ss.uuu t www MMM dd yyyy>

M


M


M




M




M




M




M


M

26 xpgk-route-retries 1 Current retry number xpgk-route-retries=<number>

M

26 h323-call-type 27 Call type always “h323-call-type=VoIP”

M

26 h323-call-origin 26 Call leg, to which the packet pertains

For the originating leg always “h323-call-origin=answer”, for the terminating leg always “h323-call-origin=originate”

M

Appendices


IETF attr. No.



Optional (M/O)

44 Acct-Session-Id ID for Start-Stop pair of Accounting packets

Format detailed after the table

M




M

26 h323-remote-id 1 Terminator ID h323-remote-id=<string>

M


23 Terminator IP address h323-remote-address=<IP-address>

M

40 Acct-Status-Type Type of Accounting packet

always «1» M

26 xpgk_centrex_cookie

1 Unique session ID xpgk_centrex_cookie=<number>

O

26 xpgk_centrex_dvo 1 VAS services indicator (1 - used, 0 - not used)

xpgk_centrex_dvo=<number>

O

26 xpgk_centrex_calltype

1 Call type xpgk_centrex_calltype=<number>

O

26 xpgk_centrex_source

1 Centrex source ID xpgk_centrex_source=<number>

O

26 xpgk_centrex_destination

1 Centrex destination ID xpgk_centrex_destination=<number>

O

26 xpgk_centrex_billing_id

1 Billing ID xpgk_centrex_billing_id=<number>

O

26 xpgk_centrex_line_name

1 Subscriber line name xpgk_centrex_line_name=<line name>

O

26 xpgk-src-codec 1 Originator codec list xpgk-src-codec=<codecs' list>

O

26 xpgk-dst-codec 1 Terminator codec list xpgk-dst-codec=<codecs' list>

O

In the Acct-Session-Id field information is presented as follows: <prefix>-<leg type><route number>

where

<prefix> is a random 8-digit hexadecimal number, delimited with "-".

<leg type> - AV for the incoming leg and OV for the outgoing leg.

<route number> is the current call termination attempt number.

Expected response is AccountingResponse.

12.3.2. ACCOUNTING STOP RECORD The MVTS Pro sends the RADIUS server the Accounting Stop record on call termination. Request type – AccountingRequest (Code 4).

Appendices


Table 14 Structure of the Accounting Stop record sent to RADIUS server

IETF attr. No.



Optional (M/O)

1 User-Name User name string, If the username contains the «$ani$» metasymbol, the metasymbol is replaced with an outgoing SRC number

M


M



41 Acct-Delay-Time Time (in sec), during which the client will attempt to send Accounting packet

always 0 M



26 h323-setup-time 25 SETUP receipt time h323-setup-time=< hh:mm:ss.uuu t www MMM dd yyyy>

M

26 h323-connect-time 28 Connect time h323-connect-time=< hh:mm:ss.uuu t www MMM dd yyyy>

M

26 h323-disconnect-time

29 Disconnect time h323-disconnect-time=< hh:mm:ss.uuu t www MMM dd yyyy>

M


M


M




O




M




O




M


M

Appendices


IETF attr. No.



Optional (M/O)


M

26 h323-call-type 27 Call type: "Conference"; "Forward", "FollowMe", "CallTransfer", "GroupCall", "AutoDial", "AlarmCall", "AutoDialCBCallTerminator", "AutoDialCBCallOriginator", "PickUp", "CallWaiting", "VoiceMail";

always “h323-call-type=VoIP”

M

26 h323-call-origin 26 Call leg, to which the packet pertains

For the originating leg always “h323-call-origin=answer”, for the terminating leg always “h323-call-origin=originate”

M



M




M

26 h323-remote-id 1 Terminator ID h323-remote-id=<string>

M


23 Terminator IP address h323-remote-address=<IP-address>

M

40 Acct-Status-Type Type of Accounting packet

always “2” O

26 xpgk-scd-time 1 Interval between the SETUP and CONNECT message or call teardown in the absence of CONNECT

xpgk-scd-time=<number>

O

26 xpgk-pdd-time 1 Interval between dialing the last digit and hearing the RBT

xpgk-pdd-time=<number>

O

26 h323-disconnect-cause

30 Disconnect cause code h323-disconnect-cause=<number>

M

26 xpgk-local-disconnect-cause

1 Local call disconnect code

xpgk-local-disconnect-cause=<number>

O

26 xpgk-source-rtp-address

1 Media source IP address xpgk-source-rtp-address=<IP-address>

O

26 xpgk-dest-rtp- 1 Media destination IP xpgk-dest-rtp- O

Appendices


IETF attr. No.



Optional (M/O)

address address address=<IP-address>

26 xpgk-source-faststart

1 Source Faststart capability

xpgk-source-faststart=<number>

O

26 xpgk-destination-faststart

1 Destination Faststart capability

xpgk-destination-faststart=<number>

O

26 xpgk_centrex_cookie

1 Unique session ID xpgk_centrex_cookie=<number>

O

26 xpgk_centrex_dvo 1 VAS services indicator (1 - used, 0 - not used)

xpgk_centrex_dvo=<number>

O

26 xpgk_centrex_calltype

1 Call type: "Conference"; "Forward", "FollowMe", "CallTransfer", "GroupCall", "AutoDial", "AlarmCall", "AutoDialCBCallTerminator", "AutoDialCBCallOriginator", "PickUp", "CallWaiting", "VoiceMail";

xpgk_centrex_calltype=<number>

O

26 xpgk_centrex_source

1 Centrex source ID xpgk_centrex_source=<number>

O

26 xpgk_centrex_destination

1 Centrex destination ID xpgk_centrex_destination=<number>

O

26 xpgk_centrex_billing_id

1 Billing ID xpgk_centrex_billing_id=<number>

O

26 xpgk_centrex_line_name

1 Subscriber line name xpgk_centrex_line_name=<line name>

O

26 xpgk-src-codec 1 Originator codec list xpgk-src-codec=<codecs' list>

O

26 xpgk-dst-codec 1 Terminator codec list xpgk-dst-codec=<codecs' list>

O

In the Acct-Session-Id field information is presented as follows: <prefix>-<leg type><route number>

where

<prefix> is a random 8-digit hexadecimal number, delimited with “-”.

<leg type> - AV for the incoming leg and OV for the outgoing leg.


Expected response – AccountingResponse.

12.4. ACCESSREQUEST STRUCTURE FOR RADIUS-AIDED ROUTING The MVTS Pro sends the RADIUS server a routing AccessRequest when gateway, acting as a terminator, is marked as Routing server.

Appendices


The MVTS Pro’s request is aimed at getting a list of routing options for termination of the call at its destination point. In addition the MVTS Pro affords the possibility to change the username and password for the call in question.

The MVTS Pro can handle several route options sequentially attempting every next route after a successful call termination through the previous one proves impossible.

The type of request is AccessRequest (Code 1).

Table 15 Structure of routing request sent to RADIUS server

IETF attr. No.



Optional (M/O)

1 User name Username String M

2 User passwd Password encrypted using MD5, or in the plain form BYTE[16] or string M



M

1 User-Name User name string M


BYTE[16] or string M


M




always "route" M




M


M




M




M




M




M


M


M

Appendices


IETF attr. No.



Optional (M/O)




M



26 xpgk-md5-auth 1 Password encrypted using MD5



string O



string O


string O


string O

108 Digest-Method Method type for Digest authorization scenario

string O


string O

115 Digest-Username User name string O

In the Acct-Session-Id field information is presented as follows: <prefix>-<route number>

where

<prefix> is a random 8-digit hexadecimal number, delimited with "-".


Expected response – AccessAccept, AccessReject.

Table 16 Structure of AccessAccept response from RADIUS server

IETF attr. No.



Optional (M/O)

26 h323-return-code

103 h323-return-code (if the field is not present or its value is 0, 13, 51 or 52, the authorization is considered successful, otherwise the call will be finished)

h323-return-code=<number>

M

Appendices


IETF attr. No.



Optional (M/O)

26 xpgk-xrouting-routing

252 Set of routes for termination of the call (can be several ones, in that case they will be handled in the same order as they go in the packet)


O

26 xpgk-xrouting-username

251 Translation of username and password for the session (only one field in packet)

<username>/<password>

O

26 h323-ivr-in 1 Used as User-Name in Accounting packets

string O

12.4.1. FIELD XPGK_XROUTING_ROUTING DETAILED gateway/proxy_mode/source/dest/src_bill/dst_bill/ip-address[:port]/converter/extra

where:

gateway – GW name from the Equipment record;

proxy_mode – mode of proxy operation:

• 0 – media proxying disabled.

• 1 – media proxying enabled.

• 2 – use proxying mode of originating gateway.

• 3 - use proxying mode of terminating gateway.

source – calling number (src_number).

dest – called party number that will be sent to the terminating gateway (dst_number).

src_bill – calling number for the billing system.

dst_bill – called number for the billing system.

ip-address[:port] – IP address for connection (port number is optional).

converter – name of the record for the converter through which the call is to be terminated.

extra – extra parameters.

AccessReject – route authorization failed and the route is rejected with the appropriate local disconnect code.

12.5. AUTHENTICATION OF REGISTERING DEVICES ON A RADIUS-SERVER There are several RADIUS authentication scenarios depending on the authentication types supported by the registering equipment.

• H.323 ID-based authentication (standard RADIUS authentication)

• MD5 hash password authentication

• Chap authentication

Appendices


• Digest authentication

12.5.1. H.323 ID-BASED AUTHENTICATION (STANDARD RADIUS AUTHENTICATION) During standard RADIUS authentication the registering endpoint sends the MVTS Pro an AccessRequest packet with the user’s ID in the field terminalAlias (marked with the red ellipse in the figure below). The user’s ID consists of the user’s name and password delimited by one of the following symbols: «|», «:», «!» or «%».

Upon receipt of the packet, the MVTS Pro forwards to the RADIUS server an access request (marked with the red rectangle) with the user’s name, password, the MVTS Pro identifier and port the registering endpoint attempts to access. The password undergoes MD5 hash encryption and is obtained from: UserPassword = MD5Hash(Shared Secret, RemoteAuthenticator) XOR password,

where

Shared Secret is the value of the parameter Secret key in the RADIUS server settings.

RemoteAuthenticator is a pseudorandom number present in the header of the AccessRequest packet received from the registering endpoint.

password denotes the user’s password available from the MVTS Pro database.

Fig. 108 Standard RADIUS authentication

Based on the received data and the shared secret established between the MVTS Pro and the RADIUS server, the RADIUS server generates an MD5 hash and if the newly generated hash matches the one received from the MVTS Pro, the RADIUS server responds with AccessAccept, otherwise the server’s reply is AccessReject.

12.5.2. MD5 AUTHENTICATION With this type of authentication involved the GatekeeperRequest that the MVTS Pro receives from the registering endpoint contains the information that the endpoint is supportive of this authentication method. Upon receipt of the GatekeeperConfirm packet from the MVTS Pro, the endpoint responds with a registration request containing the user’s alias, time stamp, MD5 hash password and data about the parameters used for the hash generation (marked with the red ellipse in the figure below). As the MVTS Pro is unaware of the user’s true password, it sends the hashed password in the field xpgk-md5-auth (marked with the red rectangle) together with the parameters used for its generation rather than in the field password. The RADIUS server must possess the capability to read the field xpgk-md5-auth.

Appendices


.

Fig. 109 MD5 authentication

12.5.3. CHAP AUTHENTICATION With CHAP authentication the GatekeeperRequest that the MVTS Pro receives from the registering endpoint contains the information that the endpoint is supportive of this authentication method. The MVTS Pro responds with a GatekeeperConfirm packet that includes the ‘challenge’ (a pseudorandom hexadecimal number). The registering user sends the MVTS Pro a registration request the field tokens of which contains the challenge and the hashed password generated using the challenge, the user’s password and identifier. Following this the MVTS Pro sends the RADIUS server a registration request with the data as below:

CHAP-Password – the hashed password generated by the user;

CHAP-Challenge – the challenge;

User-Name - the user’s name.

The figure below shows an example of the MVTS Pro registration request.

Fig. 110 CHAP authentication

The RADIUS server reads the fields CHAP-Password, CHAP-Challenge and searches its database for the user’s password using the user’s name for the search argument. Based on the found password, the user’s name and the challenge the RADIUS server is expected to generate an identical hash. If the hash generated by the RADIUS server does not match the hash received from the MVTS Pro, the authentication attempt is rejected.

Appendices


12.5.4. DIGEST AUTHENTICATION Digest authentication is used for authorization of SIP endpoints. A digest authentication procedure includes the following steps:

• The registering endpoint sends the registration-balancer node a registration request (the packet “REGISTER”)

• The registration-balancer node responds to the request with packet 401 containing the so-called “nonce”, i.e. a pseudorandom number.

• Using the received “nonce” and some other data the registering user generates an MD5 hash (DigestResponse) and sends it back along with the data used for its generation in the REGISTER response packet.

• The registration-balancer node forwards to the MVTS Pro a registration request containing in the field tokens a certificate comprised of the user generated MD5 hash and the data used for its generation.

• The MVTS Pro uses an AccessRequest packet to provide the RADIUS server with the user’s MD5 hash and the hash generation data.

• Based on the received data and the user’s password stored in the database the RADIUS server is supposed generate an identical MD5 hash. In case the hash generated by the RADIUS server coincides with the hash received from the MVTS in the Digest-Response attribute (marked with the red ellipse in Fig. 111), the user is authenticated, otherwise the authentication fails.

Fig. 111 Digest authentication

Appendices


13. APPENDIX F. REMOVING CDRS FROM THE DB To remove CDRs from the DB do the following:

Note: Removing CDRs is irreversible.

1. In the MySQL console enter the command:

alter table mvts_cdr union=(mvts_cdr_model);

2. Remove all unnecessary CDR tables in the MySQL console. For example:

drop table mvts_cdr_200801 drop table mvts_cdr_200801 drop table mvts_cdr_200801

3. In the shell execute the following command:

/usr/local/lib/mvtspro/mvtsprodb.py --user=rtu --pass=rtu --db=mvtspro update_merge_cdr

Table of Illustrations


Illustrations

Fig. 1 MVTS Pro architecture .............................................................................................................................11 Fig. 2 Excerpt from the file phoenix.conf.sample.local. .....................................................................................18 Fig. 3 Configuration file system.conf..................................................................................................................19 Fig. 4 Example of IP zoning................................................................................................................................36 Fig. 5 Configuring zones in the file system.conf.................................................................................................37 Fig. 6 SIGTRAN zones .......................................................................................................................................37 Fig. 7 Example of “location” section configuration ............................................................................................39 Fig. 8 Excerpt from the file snmpd.conf..............................................................................................................42 Fig. 9 Excerpt from the file snmpd.conf.sample .................................................................................................42 Fig. 10 Excerpt from the file etc/default/snmpd..................................................................................................43 Fig. 11 Excerpt from the output of the ‘snmpwalk’ command............................................................................43 Fig. 12 Configuration of scripting node logging .................................................................................................44 Fig. 13 General view of the section, configuring scripting node logging............................................................44 Fig. 14 Traffic Switch administration console ....................................................................................................46 Fig. 15 Output of the show ca(lls) command ......................................................................................................47 Fig. 16 Using regular expressions to view information about system events......................................................48 Fig. 17 TM objects and GUI elements ................................................................................................................50 Fig. 18 GUI elements ..........................................................................................................................................50 Fig. 19 Logon dialog box ....................................................................................................................................51 Fig. 20 Web interface main view ........................................................................................................................51 Fig. 21 Pop-up menu ...........................................................................................................................................52 Fig. 22 Filter construction dialog ........................................................................................................................53 Fig. 23 Target filter .............................................................................................................................................55 Fig. 24 Filter construction. Step 1 .......................................................................................................................56 Fig. 25 Filter construction. Step 2 .......................................................................................................................56 Fig. 26 Filter construction. Step 3. Adding group ...............................................................................................57 Fig. 27 Filter construction. Step 4 .......................................................................................................................57 Fig. 28 Filter construction. Step 5 .......................................................................................................................58 Fig. 29 Filter construction. Step 6 .......................................................................................................................58 Fig. 30 Filter construction. Step 7 .......................................................................................................................59 Fig. 31 Saving a filter for future use....................................................................................................................59 Fig. 32 Selecting an earlier saved filter ...............................................................................................................60 Fig. 33 Re-arranging table columns ....................................................................................................................61 Fig. 34 Editing multiple table records .................................................................................................................62 Fig. 35 Viewing the System component versions in the web interface ...............................................................64 Fig. 36 Add-user dialog.......................................................................................................................................65 Fig. 37 Web authentication dialog box................................................................................................................66



Fig. 38 Creating a new role .................................................................................................................................67 Fig. 39 The new role ready to be compiled .........................................................................................................67 Fig. 40 Role construction window.......................................................................................................................68 Fig. 41 Add User Wizard dialogue box...............................................................................................................69 Fig. 42 User account dialogue box ......................................................................................................................69 Fig. 43 Authentication dialogue box ...................................................................................................................69 Fig. 44 Create user final dialogue box.................................................................................................................70 Fig. 45 Realms table............................................................................................................................................70 Fig. 46 Adding a new realm ................................................................................................................................71 Fig. 47 Entering the ID of a new realm into Config.php.....................................................................................71 Fig. 48 List of configured gateways ....................................................................................................................72 Fig. 49 Configuring a gateway record.................................................................................................................73 Fig. 50 Table of configured zones.......................................................................................................................84 Fig. 51 Add zone dialog box ...............................................................................................................................84 Fig. 52 Table “Codec groups”.............................................................................................................................85 Fig. 53 Adding a codec group .............................................................................................................................85 Fig. 54 Table of codecs .......................................................................................................................................86 Fig. 55 Configuring codec groups .......................................................................................................................86 Fig. 56 Table of pre-routing number transformation rules ..................................................................................88 Fig. 57 Dialog box for pre-routing translation rules............................................................................................88 Fig. 58 Table of DPs ...........................................................................................................................................90 Fig. 59 Add dial peer dialog................................................................................................................................91 Fig. 60 Example of destination number regexp patterns tree ..............................................................................92 Fig. 61 Table with a list of available routing policies .........................................................................................95 Fig. 62 Routing policy form................................................................................................................................97 Fig. 63 Mistyped expression requiring a validity check......................................................................................97 Fig. 64 Corrected expression after validity check ...............................................................................................97 Fig. 65 Call simulation dialog .............................................................................................................................98 Fig. 66 Call simulation results.............................................................................................................................99 Fig. 67 Call progress log header when viewed from table Debug calls ............................................................100 Fig. 68 Invoking the call log for viewing ..........................................................................................................101 Fig. 69 Call progress log view...........................................................................................................................102 Fig. 70 Using partial expansion control for contents viewing...........................................................................102 Fig. 71 SS7 calls................................................................................................................................................107 Fig. 72 ISUP circuits .........................................................................................................................................108 Fig. 73 MGCP endpoints...................................................................................................................................109 Fig. 74 M3UA endpoints...................................................................................................................................109 Fig. 75 M3UA associations ...............................................................................................................................110 Fig. 76 Viewing a CDR record..........................................................................................................................111



Fig. 77 CDRs scheduled export form................................................................................................................114 Fig. 78 Making up a list of exported CDR data.................................................................................................115 Fig. 79 Creating a report....................................................................................................................................121 Fig. 80 Tables Report contents and All reports .................................................................................................122 Fig. 81 Viewing report contents ........................................................................................................................124 Fig. 82 Charts ....................................................................................................................................................125 Fig. 83 Creating a new chart .............................................................................................................................125 Fig. 84 Configuring a curve ..............................................................................................................................126 Fig. 85 Table of global configuration parameters .............................................................................................127 Fig. 86 Table of GUI parameters.......................................................................................................................129 Fig. 87 Setting the parameter Maximum number of rows displayed in GUI tables ..........................................130 Fig. 88 Table of call disconnect codes ..............................................................................................................130 Fig. 89 Table of configured RADIUS servers...................................................................................................131 Fig. 90 Adding a RADIUS server record ..........................................................................................................132 Fig. 91 ENUM server properties form ..............................................................................................................135 Fig. 92 Entering DNS server data......................................................................................................................136 Fig. 93 Adding a new area record .....................................................................................................................137 Fig. 94 Area specifics dialog.............................................................................................................................137 Fig. 95 Table "Calling party's category" ...........................................................................................................138 Fig. 96 Table "CPC translations" ......................................................................................................................138 Fig. 97 Table "Capacity groups" .......................................................................................................................139 Fig. 98 Adding a capacity group .......................................................................................................................140 Fig. 99 Authentication history table ..................................................................................................................141 Fig. 100 Page with user activity transcripts.......................................................................................................141 Fig. 101 Simplest MVTS Pro redundancy solution...........................................................................................143 Fig. 102 Diversion of media flows to healthy media node................................................................................144 Fig. 103 Reassignment of new call arrivals after SigNode1 fails......................................................................145 Fig. 104 Signaling entry point redundancy: gateway supporting alternative SIP proxy/gatekeeper .................146 Fig. 105 Entry point redundancy: router supporting Server Load Balancing....................................................146 Fig. 106 Nodes of primary and failover server..................................................................................................149 Fig. 107 Example of a redundant System layout using Linux Heartbeat ..........................................................159 Fig. 108 Standard RADIUS authentication .......................................................................................................190 Fig. 109 MD5 authentication.............................................................................................................................191 Fig. 110 CHAP authentication ..........................................................................................................................191 Fig. 111 Digest authentication...........................................................................................................................192

List of Tables

p. 197 of 197

List of tables

Table 1 Syntax of the configuration file system.conf..........................................................................................16 Table 2 TS alarms ...............................................................................................................................................40 Table 3 CLI commands .......................................................................................................................................46 Table 4 CLI tools.................................................................................................................................................47 Table 5 Filter construction dialog controls..........................................................................................................54 Table 6 Symbolic representation of statistical data used in configuring routing policies. ..................................96 Table 7 Filename format specifiers ...................................................................................................................117 Table 8 Actions of the Traffic Manager with the originator codecs depending on the proxying mode ............173 Table 9 Actions of the Traffic Manager with the terminator codecs depending on the proxying mode ...........174 Table 10 AccessRequest structure in authorization request for a registering endpoint .....................................178 Table 11 AccessRequest structure in pre-routing call authorization .................................................................179 Table 12 Content of AccessAccept response from RADIUS server in pre-routing call authorization..............181 Table 13 Structure of Accounting Start record forwarded to RADIUS server..................................................181 Table 14 Structure of the Accounting Stop record sent to RADIUS server ......................................................184 Table 15 Structure of routing request sent to RADIUS server ..........................................................................187 Table 16 Structure of AccessAccept response from RADIUS server ...............................................................188

Documents

MVTS Pro v.1.5.0.40 Operator's Manual