mvts pro operator's manual v.1.2.1.30 eng

© MERA Systems 2007-2009

MVTS Pro 1.2.1-30

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: 10/13/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.

111111111111111222222222222222222222222222222222222222222222222222222222

p. 3 of 179

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) .......................................................................................................................11 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.....................................................................................................21

3.5.1. Common sections.........................................................................................................................21 3.5.2. Registration-balancer configuration ...........................................................................................22 3.5.3. Scripting node configuration .......................................................................................................23 3.5.4. Signaling node configuration ......................................................................................................25 3.5.5. Media node configuration............................................................................................................26 3.5.6. Synchronization node configuration............................................................................................26

3.6. IP ZONES..............................................................................................................................................26 3.7. "LOCATION" SECTION...........................................................................................................................28 3.8. TS NOTIFICATION FUNCTION................................................................................................................29 3.9. SNMP DAEMON CONFIGURATION ........................................................................................................31 3.10. CONFIGURATION OF SCRIPTING NODE LOGGING...................................................................................33 3.11. CONFIGURATION OF DB INTEROPERATION ..........................................................................................34

4. TRAFFIC SWITCH ADMINISTRATION............................................................................................36 4.1. TRAFFIC SWITCH ADMINISTRATION CONSOLE ......................................................................................36 4.2. TROUBLESHOOTING .............................................................................................................................38

4.2.1. File phoenix.log...........................................................................................................................38 4.2.2. Files rtinfo ...................................................................................................................................38 4.2.3. Scripting node logs ......................................................................................................................39

4.3. MVTS3G-LOGEXTARCTOR UTILITY .......................................................................................................39 5. MVTS PRO WEB INTERFACE.............................................................................................................40

5.1. WHAT YOU SEE ON THE SCREEN...........................................................................................................40 5.2. STANDARD PROCEDURES .....................................................................................................................41

5.2.1. Accessing TM’s GUI....................................................................................................................41 5.2.2. Pop-up menu................................................................................................................................42 5.2.3. Use of filters ................................................................................................................................43 5.2.4. Sorting table data ........................................................................................................................50 5.2.5. Re-arranging table columns ........................................................................................................51 5.2.6. Editing multiple table records .....................................................................................................51 5.2.7. Data export..................................................................................................................................52 5.2.8. Component version view..............................................................................................................54

6. OPERATING TM.....................................................................................................................................55 6.1. ADMINISTRATION ................................................................................................................................55

6.1.1. System users.................................................................................................................................55

p. 4 of 179

6.1.2. Web authentication ......................................................................................................................56 6.1.3. Role assignment...........................................................................................................................57 6.1.4. Roles ............................................................................................................................................57 6.1.5. Role settings.................................................................................................................................58 6.1.6. System user creation wizard ........................................................................................................59 6.1.7. Web realms ..................................................................................................................................60

6.2. EQUIPMENT..........................................................................................................................................62 6.2.1. Equipment....................................................................................................................................62 6.2.2. Zones ...........................................................................................................................................73 6.2.3. Codec groups...............................................................................................................................74 6.2.4. Codec group setup .......................................................................................................................75

6.3. TERMINATION......................................................................................................................................77 6.3.1. Pre-routing translations ..............................................................................................................77 6.3.2. Dial peers ....................................................................................................................................79 6.3.3. Routing policies ...........................................................................................................................84

6.4. DEBUGGING.........................................................................................................................................86 6.4.1. Call simulation ............................................................................................................................87 6.4.2. Debug calls..................................................................................................................................88 6.4.3. Debug registrations .....................................................................................................................90 6.4.4. Debug call logs............................................................................................................................91

6.5. REAL-TIME INFORMATION ...................................................................................................................93 6.5.1. Active calls...................................................................................................................................93 6.5.2. Registrations................................................................................................................................93 6.5.3. Active nodes.................................................................................................................................94 6.5.4. Nodes ...........................................................................................................................................94

6.6. CDRS ..................................................................................................................................................96 6.6.1. CDRs scheduled export ...............................................................................................................99 6.6.2. Export interval...........................................................................................................................105

6.7. STATISTICS ........................................................................................................................................106 6.7.1. Reports.......................................................................................................................................106 6.7.2. Charts ........................................................................................................................................109

6.8. GLOBAL SETTINGS .............................................................................................................................111 6.8.1. System global settings................................................................................................................111 6.8.2. Web settings...............................................................................................................................114 6.8.3. Disconnect codes .......................................................................................................................115 6.8.4. RADIUS servers.........................................................................................................................116 6.8.5. ENUM servers ...........................................................................................................................120 6.8.6. DNS servers ...............................................................................................................................121 6.8.7. Areas..........................................................................................................................................121 6.8.8. Area specifics.............................................................................................................................122

6.9. LOGS..................................................................................................................................................123 6.9.1. Web authentication history ........................................................................................................123 6.9.2. Web activity log .........................................................................................................................123

7. MVTS PRO REDUNDANCY................................................................................................................125 7.1. MEDIA NODE REDUNDANCY ..............................................................................................................125 7.2. SIGNALING NODE REDUNDANCY ........................................................................................................126 7.3. BALANCER NODE REDUNDANCY ........................................................................................................127 7.4. SYNCHRO NODE REDUNDANCY ..........................................................................................................128 7.5. LICENSE MANAGEMENT NODE REDUNDANCY....................................................................................128 7.6. DB AND WEB INTERFACE SERVER REDUNDNACY .............................................................................130 7.7. CASE STUDY: TWO SERVER SYSTEM REDUNDANCY ...........................................................................130

7.7.1. Node distribution .......................................................................................................................130 7.7.2. Configuration files.....................................................................................................................131

7.7.2.1. Primary server configuration .............................................................................................132 7.7.2.2. Standby server configuration .............................................................................................140

7.8. REDUNDANCY USING LINUX HEARTBEAT..........................................................................................141 7.8.1. Configuration of TS and scripting node servers ........................................................................141 7.8.2. Configuration of WEB+DB servers...........................................................................................143

7.9. DB BACKUP AND RECOVERY..............................................................................................................144

p. 5 of 179

7.9.1. DB specifics affecting backup policy .........................................................................................144 7.9.2. Backup tools and utilities ..........................................................................................................145 7.9.3. Configuring SSH public key authentication...............................................................................145 7.9.4. Configuring DB backup.............................................................................................................146 7.9.5. Launching backup......................................................................................................................147 7.9.6. Unattended backup arrangements .............................................................................................147 7.9.7. DB recovery procedure .............................................................................................................147

7.10. DB REPLICATION...............................................................................................................................147 7.10.1. Replication types .......................................................................................................................148 7.10.2. Replication configuration ..........................................................................................................148

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

8.1. USE OF METACHARACTERS IN SEARCH...............................................................................................151 8.2. USE OF REGULAR EXPRESSIONS IN SEARCH........................................................................................151 8.3. NUMBER TRANSFORMATION ..............................................................................................................153 8.4. TIPS AND TRICKS FOR REGULAR EXPRESSIONS...................................................................................154

9. APPENDIX B. CODEC LIST GENERATION IN MVTS PRO ........................................................156 10. APPENDIX C. DEFAULT GATEWAYS.............................................................................................158 11. APPENDIX D. MVTS PRO – RADIUS INTERACTION ..................................................................159

11.1. REGISTERING ENDPOINT AUTHORIZATION .........................................................................................159 11.2. PRE-ROUTING CALL AUTHORIZATION.................................................................................................160 11.3. ACCOUNTING REQUEST......................................................................................................................162

11.3.1. Accounting Start record.............................................................................................................162 11.3.2. Accounting Stop record .............................................................................................................164

11.4. ACCESSREQUEST STRUCTURE FOR RADIUS-AIDED ROUTING...........................................................167 11.4.1. Field XPGK_XROUTING_ROUTING detailed.........................................................................170

11.5. AUTHENTICATION OF REGISTERING DEVICES ON A RADIUS-SERVER................................................170 11.5.1. H.323 ID-based authentication (standard RADIUS authentication) .........................................171 11.5.2. MD5 Authentication ..................................................................................................................171 11.5.3. CHAP Authentication ................................................................................................................172 11.5.4. Digest authentication.................................................................................................................173

12. APPENDIX E. REMOVING CDRS FROM THE DB ........................................................................174 13. APPENDIX F. CONFIGURING DISK SPACE MONITOR..............................................................175

Introduction

p. 6 of 179

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

p. 7 of 179

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) 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

p. 8 of 179

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

IVR Interactive Voice Response

LAN Local Area Network

MVTS Mera VoIP Tandem Softswitch

NAT Network Address Translation

NGN Next-Generation Networks

NIC Network-Interface Card

PDD Post Dial Delay, interval between dialing 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;

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

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.

SMTP Simple Mail Transfer Protocol

System The capitalized word System is used in this document to refer to the MVTS Pro as a whole.

Introduction

p. 9 of 179

TCD Total Calls Duration

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 overview

p. 10 of 179

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 and H.323)

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, 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).

System overview

p. 11 of 179

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.

2.1.2. TRAFFIC SWITCH (TS) Traffic Switch (TS) processes SIP and H.323 calls and performs two-way conversion of signaling protocols and voice codecs when necessary. Each TS is a full-featured session

System overview

p. 12 of 179

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

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 (RFC 2543 bis/3261)

• T.38

• SNMP

• RADIUS AAA

• RADIUS routing

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

• SIP/H.323 proxy

• SIP/H.323 interworking

System overview

p. 13 of 179

• Support for H.323 and SIP dialects

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

• T.38 fax pass-through

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

• Gateway/route traffic load

• Caller group ID

• Day of week/time of day

• Priority/accessibility of the destination GW

External routing

• RADIUS API for integration with external routing systems

• ENUM routing

Statistics and network analysis

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

• Statistics monitoring of selected gateways/routes

• CDR-based call analysis

• Handy CDR search and display capabilities

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

Billing

• Single CDR collection point

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

• RADIUS API for integration with external billing systems

• Cisco VSA

System overview

p. 14 of 179

• User 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 50,000 concurrent calls

• Call accretion rate (CPS): 300

• New registrations per second: up to 5000

Minimal configuration capacity (2 servers):

• Up to 1,000 concurrent calls (without codec conversion)

• Up to 5,000 concurrent calls (in signaling proxy mode)

Signaling node capacity:

• Up to 50,000 concurrent calls

Media node capacity without codec conversion

• Up to 1200 concurrent calls.

Media node codec conversion capability

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

• Up to 60 concurrent calls per processor core

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

• Up to 120 concurrent calls per processor core

Run-time logs

• Billing and debug logs

• System trace logs with selectable information detail level

• Call log extraction based on the call ID (log extractor script)

• Call log viewing through the web-interface

System overview

p. 15 of 179

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

System configuration

p. 16 of 179

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


p. 17 of 179

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.


p. 18 of 179

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:

• watchdog_timeout – define the timeout after the control link severance was detected. After the timeout is expired the System will try to restart the node with the severed link. Default value is 30 sec.

• 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:

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

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


p. 19 of 179

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

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.

Starting from TS version 3.10-4.x and on, it is necessary to specify the type of routing logic, the TS interoperates with. Enter or edit the following line in the beginning of the system.conf file:

use_scripting “yes|no|1|0|true|false”;

Set the use_scripting parameter to “yes|1|true”, for the TS to interact with the MVTS Pro type routing logic.

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

use_scripting "yes"; 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";

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


p. 20 of 179

Fig. 3 Configuration file system.conf

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 :

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"; }; };


p. 21 of 179

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 DB on 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.

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:

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] }; };

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

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


p. 22 of 179

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 the addresses “0.0.0.0” and “127.0.0.1” in the section ‘controllink’ to avoid troubles when configuring the TS. You should specify one real address.

3.5.2. REGISTRATION-BALANCER CONFIGURATION A configuration example of an arbitrary registration-balancer node for H.323 calls (H.323 gatekeeper):

• address — address or addresses, used by the node to listen for incoming requests

to the H.323 gatekeeper.

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

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

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

• balancer — section with the IP address and port for the incoming H.323 calls.

h323gatekeeper { h323gatekeeper "[node name]" { common ... controllink ... address { "0.0.0.0"; }; port "1719"; gkname "MVTS3G"; allow_md5 "yes"; allow_chap "yes"; allow_plain "yes"; }; balancer { address { "212.92.148.70"; }; port "1720"; }; };


p. 23 of 179

A configuration example of an arbitrary registration-balancer node for SIP calls (SIP registrar):

• proxying_balancing — parameter governing balancing of SIP calls, with

(“no”) or without redirection (302 message) (“yes”).

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

3.5.3. 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:

Parameters of the scripting section:

• loader_path – path to the starting script of the scripting node; • user_path – path to other scripts of the scripting node; • thread_pool – number of threads of the scripting node (10 by default);

sipregistrar { common ... controllink ... sipregistrar "[node name]" { proxying_balancing "yes"; address { "192.168.132.135"; }; port "5061"; }; };

scripting { scripting "scripting-1" { controllink { address { "0.0.0.0"; }; port "7710"; }; loader_path "/usr/share/mvts3g/python/loader/__proxyLoader__.py"; user_path "/usr/share/mvts3g/python/user/"; thread_pool "10"; environment { mailer_notifier_cfg "/etc/mvts3g/mvts3g-mail.conf"; mailer_path "/usr/sbin/mvts3g-mail"; dbms_type "MySQL"; dbms_name "localhost@rtu"; dbms_user "rtu"; dbms_pswd "rtu"; radius_dict_path "/usr/share/mvts3g/python/user/mrc/dict/"; }; }; };


p. 24 of 179

• mailer_notifier_cfg – path to the configuration file of the node, which configures operator’s notification about System faults by e-mail.

• mailer_path – path to the e-mail notification node.

Parameters of the subsection environment:

• mn_addresses – list of LMN addresses on the main and failover servers in the “address:port” format. For example:

mn_addresses "127.0.0.1:9000,192.168.130.10:9000"; • mvtssql_client_path – path to the TS access utility mvts3g-sqlclient on this

server, for example:

mvtssql_client_path "/usr/bin/mvts3g-sqlclient";

If either of the above two parameters is not specified, the settings of the mvtssql_client_cmd parameter apply to mvts3g-sqlclient. If both the mn_addresses and mvtssql_client_path parameters are defined, the mvtssql_client_cmd parameter is ignored and the settings of specified parameters apply.

• mvtssql_client_cmd — the command string used to start the sql-client.

mvtssql_client_cmd "/usr/bin/mvts3g-sqlclient -a 127.0.0.1:9000";

where:

- /usr/bin/mvts3g-sqlclient is the location of the TS access utility;

- 127.0.0.1:9000 - IP address and port of the license management node.

• registrar_name_list —list of names of all registration-balancer nodes. The list elements are delimited with commas. The convention is that names of SIP registrars start with ‘sip’, and those of H.323 gatekeepers – with ‘h323’.

registrar_name_list "sip-registrar-1,h323-registrar-1";

• signaling_name_list — comma-delimited namelist of all signaling nodes,

signaling_name_list "signaling-1";

• radius_dict_path – path to RADIUS dictionary. Starting from MVTS Pro version 1.2 on, this parameter should have the following value: /usr/share/mvts3g/python/user/mrc/dict/.

radius_dict_path "/usr/share/mvts3g/python/user/mrc/dict/";

• dbms_type — database type. Valid values are “MySQL” and “Oracle”.

dbms_type "MySQL";

• dbms_name — path to the database in the host@database format.

dbms_name "rtu2@rtu";

• dbms_user — name of database user account.

dbms_user "rtu";

• dbms_pswd — database user password.

dbms_pswd "rtu";

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

dbms_reconnect_timeout "1";


p. 25 of 179

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

trace_file "logic";

• thread_pool_size — the number of simultaneous calls waiting to be authorized by the RADIUS server.

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

signaling "signaling-1" { common ... controllink ... h323 { address { "0.0.0.0"; }; port "1721"; }; sip { address { "0.0.0.0"; }; port "5060"; }; synchro "synchro-1"; };


p. 26 of 179

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.

• synchro parameter defines the name of a synchronization node, associated with this signaling node.

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

• signaling — name of the signaling node, linked to this media node. This TS version allows connection of a media-node to one signaling node only.

3.5.6. 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]"; signaling "signaling-1"; }; };

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


p. 27 of 179

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:


p. 28 of 179

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.

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.


p. 29 of 179

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

Fig. 6 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

mailto:[email protected]




p. 30 of 179

2. List of alarms and alarm 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.

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.


p. 31 of 179

Below is an example of a properly configured alert:

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-snmp_<version_number>.deb from the directory /home/common/debian created by the TS installation script:

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/


p. 32 of 179

Fig. 7 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 libmvts.so, IP address of the TS License management node 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. 8 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'.


p. 33 of 179

Fig. 9 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 TS license management node.

.1.3.6.1.4.1.28029 – MVTS Pro enterprise OID.

Fig. 10 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 scripting node software, edit the mvts-pro file, located in the /etc/logrotate.d directory. The mvts-pro file contains configuration settings for scripting node logging. For example:


p. 34 of 179

Fig. 11 Configuration of scripting node logging

Create an individual section in the /etc/logrotate.d/mvts-pro file for each scripting node, running on the host,. The section layout is as follows:

Fig. 12 Scripting node logging configuration section

The name of the section comprises the path to and the name of the log file. The name of the log file (mvtsprologic.scripting-1.log in Fig. 11) 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 command 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 keyword logrotate.

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 logrotate manual, type:

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.

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

/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 }


p. 35 of 179

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

p. 36 of 179

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


p. 37 of 179

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


p. 38 of 179

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. 15 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 to 4Appendix A. Metacharacters, regular expressions and number transformation.

Fig. 15 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.

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


p. 39 of 179

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 A scripting node log contains runtime information about the scripting node operation. Scripting node logs are saved to the directory /var/log/mvts3g/.

The System keeps an individual log file on every scripting node with the name <prefix>.<node name>.log, where <prefix> is the value of the trace_file parameter (see section 3.5.3), and <node name> is the name of the node as 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

p. 40 of 179

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. 16 and Fig. 17) illustrate the web GUI elements and the terms used in this manual to refer to the objects that the TM software deals with.

Fig. 16 TM objects and GUI elements

Fig. 17 GUI elements

Dialog

Checkbox

Textbox

Listbox

Pop-up menu Object

categories

Object


p. 41 of 179

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. 18:

Fig. 18 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. 19 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/


p. 42 of 179

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


p. 43 of 179

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

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);

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 rights of 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 and select Filter. The system will display a filter dialog similar to the one shown in Fig. 21.


p. 44 of 179

Fig. 21 Filter construction dialog

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


p. 45 of 179

Control Description

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,

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

AND

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


p. 46 of 179

Fig. 22 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. 23).

Fig. 23 Filter construction. Step 1

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


p. 47 of 179


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

Fig. 25 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. 26).


p. 48 of 179


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.


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. 28).


p. 49 of 179


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


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.


p. 50 of 179

Fig. 30 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. 31). To delete the saved filter click Delete.

Fig. 31 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 ascending order with the sort order indicated by an up 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.


p. 51 of 179

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

Fig. 32 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. 33 illustrates such multiple-edit dialog box invoked from the table “Codec group setup”.


p. 52 of 179

Fig. 33 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.


p. 53 of 179

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.


p. 54 of 179

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.

Fig. 34 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.

РТУ – the System version.

Operating TM

p. 55 of 179

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. 35 Add-user dialog

Enter the following data in the displayed dialog (see Fig. 35). 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.

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) and assigning a role to the user (see section 6.1.3, 6.1.4 and 6.1.5)

Operating TM

p. 56 of 179

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

p. 57 of 179

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. ROLE ASSIGNMENT Use this object to assign roles to system users. Each role determines the list of GUI objects accessible to the user.

To assign a role to the user, invoke the pop-up menu and select Add.

In the displayed dialog box select the name of the user and the role with the help of the appropriate list boxes.

Fig. 37 Role assignment dialog box

For further information about role creation see Sections 6.1.4 and 6.1.5.

When done, click the OK button.

6.1.4. 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 a parent role for the role being created.

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

The role Administrator that comprises 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 rights to the role (see Section 6.1.5) and compile it.

Operating TM

p. 58 of 179

Role compilation is necessary every time you do changes in the role settings. During the role compilation process all GUI elements are updated in accordance with the new role profile, so that users assigned to this role have access to the right 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 display Yes in the Compiled column of the role line.

6.1.5. ROLE SETTINGS The Role settings dialog serves for making a list of rights characteristic of the created role. To make a set of rights for the role, invoke the pop-up menu and select the Add option.

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 shows a GUI element and all its child elements. This allows you to remove unwanted GUI objects (the access rights to which should be left unchanged) from the Object list.

* Object – select a category, object or parameter, to which the granted rights pertain. The list comprises the parent object and all its child elements (if any).

Names of GUI elements in the lists Filter and Object have the following designations:

• [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 selected GUI element, but also to all its child elements.

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

Operating TM

p. 59 of 179

• 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.4).

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

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. Click the Next button.

Fig. 43 Authentication dialogue box

Operating TM

p. 60 of 179

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.

Fig. 44 Roles dialogue box

In the Roles dialogue box assign the roles for the user. Refer to Section 6.1.2 for more information. When done, click the Next button.

Fig. 45 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.7. 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.

Operating TM

p. 61 of 179

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. 46 Realms table

The Realms table (see Fig. 46) 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.

Fig. 47 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. 48):

Operating TM

p. 62 of 179

Fig. 48 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).

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. 49 List of configured gateways

Operating TM

p. 63 of 179

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

Fig. 50 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.

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

Operating TM

p. 64 of 179

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

Is default gateway – select the checkbox to indicate that the gateway is used as a template gateway for the devices, not configured in MVTS Pro.

Is routing server – select this checkbox when the configured device is a routing server.

ENUM routing – select the checkbox if 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.

* Registration Type – choose if the gateway will be registered in MVTS Pro. If the Is default gateway checkbox is selected, only one option is available and the gateway will always be registered. Possible settings include:

- No registration

- Register gateway

* Protocol – specify the signaling protocol supported by the device.

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 statisctics 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 Is origination device 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.

Orig. port – specify the signaling port of the origination device for the purpose of caller identification.

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.

* 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).

Operating TM

p. 65 of 179

• 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);

• Do not proxy whenever possible, use first originator codec – proxy media initially. If the first codec of the originator matches any codec of the terminator after connect, do not proxy media and switch to direct media mode using this codec. Otherwise continue proxying media.

• Do not proxy whenever possible, use first common codec – proxy media initially. If the any codec of the originator matches any codec of the terminator after connect, do not proxy media and switch to direct media mode using this (first common) codec. Otherwise continue proxying media.

The latter two modes are used if the System requires to initiate a call with proxying and cancel proxying later, for example, when using equipment that does not supporting calls without initial proxying, or when originating calls without Faststart in H.323 or SDP in SIP.

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.

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.

Orig. capacity group – select the name of the capacity group from the drop-down list of this combo box or select the option ---Manual input--- and enter a new name. By "Capacity group" we shall mean a group of gateways with common capacity. In case gateways are associated with the same capacity group, the total amount of simultaneous calls originated by them will not exceed the value specified in the field Max. incoming calls.

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

Orig. groups – enter the names of gateway groups to which calls originated by the group devices are related. Group names thus configured can be later used in call routing and number translation when entered in the fields 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.

Operating TM

p. 66 of 179

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

Term. IP address – define the IP address used by the device for call termination (only one IP address is allowed).

Term. port H.323– define the port number to be used for call termination under H.323.

Term. port SIP – define the port number to be used for call termination under SIP.

* Term. zone – use the combo box to select the zone (see section 6.2.2) to be used for calls sent to the device

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



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



The latter two modes are used if the System requires to initiate a call with proxying and cancel proxying later, for example, when using equipment that does not supporting calls without initial proxying, or when originating calls without Faststart in H.323 or SDP in SIP.

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.

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.

* 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).

Operating TM

p. 67 of 179

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.

Term. capacity group – select the name of the capacity group from the drop-down list of this combo box or select the option Manual input and enter a new name. In case gateways are associated with the same capacity group, the total amount of simultaneous calls sent to them will not exceed the value specified in the field Max. outgoing calls.

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.

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

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


Operating TM

p. 68 of 179

Note: The parameters are valid only with the Is origination device 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 Is termination device checkbox selected.

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

Category Origination signalling 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 Is origination device 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.

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

Operating TM

p. 69 of 179

- Alerting/Progress

- Connect

Category Termination signalling 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 Is termination device checkbox selected.

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

* 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

* 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)

Operating TM

p. 70 of 179

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

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.

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

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

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

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

Operating TM

p. 71 of 179

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.

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.

Term. Enable LAR for MVTS codes – make a list of MVTS intrinsic disconnect codes that are expected to trigger look-ahead routing (LAR) for the call.

Term. Disable LAR for MVTS codes – make a list of disconnect codes that will prevent further routing for the call.

Category RADIUS

Enable RADIUS authentication – select the checkbox to send device authentication requests to the RADIUS-server.

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.

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.

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.

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

p. 72 of 179

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.

Term. redial codes – make a list of 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.

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 allows selecting a DST numbers source, associated with the termination equipment:

• RADIUS only – use 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 –,.use the numbers received from the equipment when no DST numbers are provided by the RADIUS server

• RADIUS if no numbers from equipment –. use the numbers received from the RADIUS server when no DST numbers come from the equipment

Category Miscellaneous

SIP Gateway query interval, sec – this parameter allows MVTS Pro to monitor the serviceability of SIP gateways by sending them the OPTIONS request at a specified time interval as long as the gateways are handling calls. Define the interval between repetitive requests (in seconds).

Operating TM

p. 73 of 179

SIP Gateway timeout, sec – define the wait period for responses from SIP gateways. In the lack of a response from the gateway within the specified period the gateway is treated as inaccessible.

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 0). 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 , 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 enabled only when the ENUM routing checkbox is selected.

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:

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

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

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

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

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

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

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

Use RFC 3555 for G.729B – select the checkbox, when the absence of the annexB field in the G.729 codec description, sent via SDP, should be interpreted according to RFC 3555 as the default “yes” which results in treating the G.729 codec as the G.729B codec. If the checkbox is clear, the absence of annexB is interpreted as “no” and the codec is treated as plain G.729. The parameter is valid only if the gateway operates under the SIP protocol.

Use IP address from ENUM server – select the checkbox, if the ENUM server responds not with an URI, but with an IP address. In such a case the System will not query a DNS server but will connect to the terminator immediately using the IP address supplied. If the ENUM server responds with an URI, deselect the checkbox. The parameter is valid only if the ENUM routing checkbox is selected.

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 zones” involved in TS call routing. For more detail on the intent of IP zones refer to section 3).

http://tools.ietf.org/html/rfc3555

Operating TM

p. 74 of 179

Fig. 51 Table of configured zones

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

Fig. 52 Add zone dialog box

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

* ID – enter the name of the IP zone being configured exactly as it is defined in the TS configuration file.

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

* 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. 53 Table “Codec groups”

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

Operating TM

p. 75 of 179

Fig. 54 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.

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

Fig. 55 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.

Operating TM

p. 76 of 179

Fig. 56 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

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.

Operating TM

p. 77 of 179

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.

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 field Allowed SRC numbers pattern or Allowed DST numbers pattern and Allowed SRC groups and mismatches the pattern defined in Exclude SRC numbers or Exclude DST numbers and Disallowed SRC groups.

In addition, the object Pre-routing number transformation is used to define name transformation rules for groups of registering gateways.

Fig. 57 Table of pre-routing number transformation rules

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

http://www.speex.org/docs/manual/speex-manual.pdf

Operating TM

p. 78 of 179

Fig. 58 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.

* 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 «|».

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 «|».

Operating TM

p. 79 of 179

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 «;».

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 transformation – enter a regular expression for transformation of the group name.

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

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. 59) 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.

Operating TM

p. 80 of 179

Fig. 59 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.

Fig. 60 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.

Operating TM

p. 81 of 179

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 dial peer configuration, the System forms a tree of destination number patterns. Each tree node is associated with dial peers, where this pattern is used. Suppose, there are 9 dial peers (dp0 - dp8) configured in the System. The tree of destination number prefix patterns may then look as shown in Fig. 61.

Fig. 61 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 «|».

* 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 selected 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.

Operating TM

p. 82 of 179

Note: When using the latter balancing method, explicitly specify the capacity in the Max. outgoing calls field of the gateways, among which the load is balanced. Otherwise the calls will be terminated with the ‘Traffic Manager Timeout’ code.

Capacity group – use this combo box to select a capacity group from the dropdown list or select the option ---Manual input--- and type in the capacity group name. When DPs belong to a capacity group the total of concurrent calls forwarded to them will never exceed the value entered in the field Capacity.

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

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 No 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 No 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 «|».

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.

Stop route hunting after this DP – select this checkbox to reduce the number of dial peers selected by exclusion of upper levels of regexp pattern tree from tree traversal.

Suppose, dp2 from Fig. 61 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 patterns not matching the number), but also dp0 (as a matching pattern on a preceding tree level).

Operating TM

p. 83 of 179

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:



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



If the empty line is selected, media proxy settings of the termination gateway will be applied.

* Call source category – select Same as for incoming leg to leave the category of subscriber unchanged when routing the call via the DP. To change the category when using the DP for call routing, select --- Manual input --- and enter a new category in the appearing field.

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:

Operating TM

p. 84 of 179

If the Time of day option is selected:

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.

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.

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. 62 Table with a list of available routing policies

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

Operating TM

p. 85 of 179

Table 6-1 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

To define a routing policy right-click the mouse to invoke the contextual menu and select Add. Fill out the displayed form (see Fig. 63) 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-1. 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.

Operating TM

p. 86 of 179

Fig. 63 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. 64 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. 65 Corrected expression after validity check

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.

Operating TM

p. 87 of 179

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. 66 Call simulation dialog

To simulate a call enter the following parameters in the Call simulation dialog (Fig. 66):

ANI number and * DNIS number - enter a calling and called number in respective edit boxes.

* SRC address - specify the IP address of the origination gateway.

NAT address - specify the NAT address, if the origination device sits behind NAT.

SRC protocol - select the signaling protocol from the dropdown list.

SRC codecs – by moving codec names from the left window to the right, define the list of codecs used by the call originator.

SRC subscriber category - enter the subscriber category as if it were present in INVITE message of the incoming leg.

Press OK.

Operating TM

p. 88 of 179

Fig. 67 Call simulation results

Results of the call simulation will be displayed in the field Routes (Fig. 67).

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.

Fig. 68 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.6).

Operating TM

p. 89 of 179

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 Appendix A. Metacharacters, regular expressions and number transformation).

Outgoing DST number – destination number after transformation according to the configured number translation rules (see Appendix A. Metacharacters, regular expressions and number transformation).

Remote SRC signalling address – signaling IP address and port of the call originator.

Remote DST signalling 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.

Fig. 69 Invoking the call log for viewing

You will be displayed the call log page that presents the call log header as in Fig. 68 followed by a table of packets exchanged during the call (see Fig. 70)

Operating TM

p. 90 of 179

Fig. 70 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. 71 Using partial expansion control for contents viewing

6.4.3. DEBUG REGISTRATIONS The table Debug registrations contains records about debug registrations of RAS clients.

Operating TM

p. 91 of 179

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.

Conference ID – conference ID (conference = incoming call leg + outgoing call leg).

6.4.4. DEBUG CALL LOGS The table Debug call logs provides information about processes that take place during call handling and can be used for administration and debugging purposes.

Operating TM

p. 92 of 179

Note: Call progress logging is done only when the appropriate checkboxes are selected in the gateway record (see Debug in section 6.2.1).

Fig. 72 Debug call log

Call progress logs may include all or part of the following data:

ID – unique record ID.

Timestamp – date and time the record was created.

Call ID – call identifier.

Conference ID – conference ID (conference = incoming call leg + outgoing call leg).

Direction – shows ingress or egress character of the message: IN for ingress messages and OUT for egress messages.

Protocol – protocol name.

Packet type – packet name.

Source – IP address and port of the message sender.

Destination – IP address and port of the message recipient.

Packet body – message text.

Operating TM

p. 93 of 179

6.5. REAL-TIME INFORMATION

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.

Remote SRC signaling address – signaling IP address and port of the call originator.

Incoming leg protocol – signaling protocol used on the incoming call leg.



Outgoing leg call ID – call ID on the outgoing leg.

Remote DST signaling address – signaling IP address and port of the call terminator.

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

p. 94 of 179

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

- Unregestering (gateway is unregestering).

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 an object IP zones, which provides information about the sockets that are open on the node. The specifics of the information include:

- Protocol shows the name of protocol under which the socket operates.

- Zone shows the name of IP zone to which the open socket belongs. Zones are configured in system.conf.

- Type is the type of socket:

Listener – local socket, waiting for an incoming connection.

Locally connected – local socket, which established the outgoing connection.

Remotedly connected – remote socket, receiving connection from the locally connected socket.

- Address is address of the socket (IP-address & port).

Operating TM

p. 95 of 179

<Management>

This sub-directory includes the object IP zones that delivers statistical information pertaining to the Management node.

<Signaling>

This object provides statistical information about the signaling node. In addition to information about protocols and IP zones as above (object IP zones) 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 table IP zones common for all objects in the category Nodes, 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 IP zones data, 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 one table only – IP zones.

<Scripting>

This folder contains operational statistics pertaining to the Scripting node and includes one table only – IP zones.

<Synchro>

This folder displays the Synchro node operational statistics contained in one table only – IP zones.

Operating TM

p. 96 of 179

6.6. CDRS

The subcategory CDRs includes six tables that display call detail records (CDRs) used in metering and billing.

The table Doubtful comprises CDRs with a missing or wrong date of creation.

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 D. MVTS Pro – RADIUS interaction.

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

Operating TM

p. 97 of 179

Fig. 73 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.

Signaling node – name of the signaling node that handled the call.

Remote orig. GK address – IP address of the originating gatekeeper.

Remote orig. signaling address – signaling IP address and port of the call originator.

Remote term. signaling address – signaling IP address and port of the call terminator.

Remote orig. media address – media IP address and port of the call originator.

Remote term. media address – media IP address and port of the call terminator.

Operating TM

p. 98 of 179

Local orig. signaling address – IP address and port of the signaling node used on the incoming leg.

Local term. signaling address – IP address and port of the signaling node used on the outgoing leg.

Local orig. media address – IP address and port of the media node used on the incoming leg.

Local term. 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.

Conference ID – unique identifier of the conference the call was a party to (conference = incoming call leg + outgoing call leg).

Incoming leg call ID – call ID on the incoming leg.

Outgoing leg call ID – call ID on the outgoing leg.

Orig. registration username – registration username of the call originator.

Term. registration username – registration 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.

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.

Operating TM

p. 99 of 179

Orig. media bytes in – number of ingress bytes received from the call originator.

Orig. media bytes out – number of egress bytes sent to the call originator.

Term. media bytes in – number of ingress bytes received from the call termination party.

Term. media bytes out – number of egress bytes sent to the call termination party.

Orig. media packets – quantity of media packets received from the call originator.

Term. media packets – quantity of media packets received from the call termination party.

Orig. media packets late – number of late packets received from the call originator.

Term. media packets late – number of late packets received from the call termination party.

Orig. media packets lost – amount of packets not received from the call originator.

Term. media packets lost – amount of packets not received from the call termination party.

Orig. min. jitter buffer size (packets) – minimum jitter buffer size when receiving packets from the call originator.

Orig. max. jitter buffer size (packets) – maximum jitter buffer size when receiving packets from the call originator.

Term. min. jitter buffer size (packets) – minimum jitter buffer size when receiving packets from the call termination party.

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

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.

6.6.1. CDRS SCHEDULED EXPORT The object Scheduled export in the category 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. 74).

Operating TM

p. 100 of 179

Fig. 74 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.

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.

Operating TM

p. 101 of 179

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. 75).

Fig. 75 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.

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

Operating TM

p. 102 of 179

* 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 combobox.

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.

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

Operating TM

p. 103 of 179

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 6-2 shows the list of allowed specifiers.

Table 6-2 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

P - character string entered in the field CDR filename prefix.

D - time stamp 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.

ftp://cdr.storage.machine/CDRs/export

Operating TM

p. 104 of 179

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 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:





Operating TM

p. 105 of 179

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

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

mailto:100c7ad8-8683a8c0-13c5-3e1243f1-78704c0b-3e1243f1@meranetworks.ru




Operating TM

p. 106 of 179

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.

Fig. 76 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 attribute position 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

Operating TM

p. 107 of 179

the list, then the records within the resulting groups are grouped by the second attribute in the list, and so on.

* Time unit – use this parameter to select a measure of time for record grouping. The process of report generation is described in detail below. 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.

Fig. 77 Tables Report contents and All reports

The report generation process 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, the name of originating or terminating gateway is 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 grouping attributes in the list. If the Grouping list includes Data, then the CDRs are additionally sub-grouped by date using

Operating TM

p. 108 of 179

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 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 call sessions of 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).

- 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 service, 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 service, 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

p. 109 of 179

Fig. 78 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 setiings -> Enable statistics = 0) the Enable statistics setting of individual gateways and dial peers is ignored.

Operating TM

p. 110 of 179

Fig. 79 Charts

To plot a statistics chart:

1. Select a parameter that will be plotted from the leftmost drop-down list

( ):

− ASR – Answer seizure ratio (MVTS-specific).

− ASR (std.) – Conventional ASR.

− ACD – Average call duration.

− PDD – Post-Dial Delay.

− SCD – SETUP-CONNECT Delay.

− CPS – Call arrival rate.

− QoS – Quality of Service.

2. From the drop down list next to the first one ( ) select an object, to which the plot pertains. The list options include:

− SRC – plot a curve for origination gateway.

− DST – plot a curve for termination gateway.

− GW – plot a curve for the gateway that is both originator and terminator.

− DP – plot a curve for the DP as a whole (including all gateways pertaining to it.

3. Type the name of the object, for which the plotting is done in the edit field Object name.

4. Set a desired chart update rate selecting a value from the drop-down list Refresh period.

5. In Systems with multiple scripting nodes, select the checkboxes of those scripting nodes that should be taken into account during graph plotting.

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.

Press OK to start the plotting.

Operating TM

p. 111 of 179

You will be displayed a new window with a real-time graph.

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 is the main chart parameter, the plotted value is just the sum of CPS values from all selected scripting nodes.

You can add new charts by entering new chart parameters and pressing OK. The number of graphs plotted simultaneously is limited by the computing power of your system only.

To remove the chart, click in the 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.

Operating TM

p. 112 of 179

Fig. 80 Table of global configuration parameters

The global configuration parameters currently accessible to the MVTS Pro administrator include:

Max. call duration – maximum call duration defined globally 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).

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.

Use H323_IVR_IN parameter in UserName field – “1” means putting the value of the H323_IVR_IN parameter, if it is received from the RADIUS server in case authorization or external routing is used, in the UserName field of the accounting packets.

External routing w/o authorization – “1” means that the System does not authorize all routes of a dial peer on the RADIUS server in case at least one route of the dial peer is generated with help of RADIUS-aided routing.

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.

Ignore RADIUS-supplied proxying mode – “1” means that the System ignores the proxying mode supplied by the RADIUS server.

http://rfc-ref.org/RFC-TEXTS/2865/chapter5.html#d4e447338

http://rfc-ref.org/RFC-TEXTS/2865/chapter5.html#d4e447765

Operating TM

p. 113 of 179

NAS-IP-Address parameter sent to RADIUS – value of NAS-IP-Address field in accounting packets, sent to the RADIUS server.

Path for saving RADIUS packets in case of offline DB - path to the directory for saving temporary files with RADIUS packets in case the DB is offline.

Prefix for saved RADIUS packet filenames – prefix for names of temporary files with RADIUS packets.

Max. number of RADIUS packets per backup file – maximum number of RADIUS packets saved in one temporary file.

Max. RADIUS packet queue length – maximum number of RADIUS packets awaiting to be saved to a file.

Timeout to flush CDR cache to DB – the period of storing CDRs in the memory (CDRs are saved to the DB after the keeping time expires), in sec.

TTL of the container for CDRs residing in memory – the time-to-live (in sec) of the container where CDRs awaiting to be saved reside. After this period the container is destroyed if it contains no CDRs.

Number of CDRs to write to DB at once – number of CDRs written into the DB at once.

Path for saving CDRs in case of offline DB – define the path to the directory where the CDRs are stored while the DB is offline.

Prefix for saved CDR filenames – specify the prefix for names of files with saved CDRs, which are written when the DB is offline. The filename pattern is as follows: <prefix for saved CDR filenames><scripting node name>.<random number>.

Max. number of CDRs per backup file – maximum number of CDRs saved in one temporary file.

Value for "Connect time" in CDR if no connect: 0 - blank, 1 - Disconnect time - determines the way of filling in the Connect time field in CDRs when there was no connect. 0 means the call connect time will be blank, 2 means the call disconnect time will be recorded.

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.

Path for saving registrations in case of offline DB - path to the directory for saving temporary files with registration data in case the DB is offline.

Prefix for saved registration filenames – prefix for names of temporary files with registration data.

Number of CDR files restored per check – number of temporary files with CDRs that are restored to the DB per check.

CDR file check timeout after a successful check – interval (in secs) between checking the directory used for temporary CDR files, if such files were found during previous checks.

CDR file check timeout after an unsuccessful check – interval (in secs) between checking the directory for temporary CDR files, if such files were not found during previous checks.

By this means, by default on start up, the System checks the directory specified in Path for saving CDRs in case of offline DB for temporary CDR files. If no temporary CDR files are found in the directory, the frequency of checks changes to the 6-minute interval set in the parameter CDR file check timeout after an unsuccessful check. If temporary CDR files are found in the directory during the check, the System inserts CDRs from the number of files set in the Number of CDR-files restored per check parameter in the DB and again checks the directory now after the short time specified by the parameter CDR file check timeout after a successful check. 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

Operating TM

p. 114 of 179

in the DB). The System then switches to less frequent checks with the between-checks interval set by the parameter CDR file check timeout after an unsuccessful 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.

Max. call TTL in control link – maximum time (in secs) for awaiting call handling. If the call is not collected from the control link before this period expires, it is discarded.

Timeout to flush debug data to DB – the period of storing debug data (calls and registrations) in the memory (debug data is saved to the DB after the keeping time expires), in secs.

Number of debug records to write to DB at once – number of debug records (calls and registrations) written to the DB at a time.

Debug level of scripting node log file – the detail level of the messages written to the scripting node log. The higher the value – the more detailed the log.

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:

Fig. 81 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,

Operating TM

p. 115 of 179

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, 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. 82 Setting the parameter Maximum number of rows displayed in GUI tables

Type the required parameter value in the edit field Value (see Fig. 82) 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.

Operating TM

p. 116 of 179

Fig. 83 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.

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

p. 117 of 179

Fig. 85 Adding a RADIUS server record

Fill out the displayed server configuration form (see Fig. 85) 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 and RAS users by the RADIUS server being configured.

Enable authorization – select the check box to enable authorization of calls from gateways and RAS users by the RADIUS server being configured.

Enable accounting – select the check box to enable accounting through the RADIUS server being configured.

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.

Operating TM

p. 118 of 179

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 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 scripting node host.

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

h323-remote-id ID of the origination gateway

h323-remote-address IP address of the origination gateway used for signaling

For the outgoing leg:

Operating TM

p. 119 of 179

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.

If you wish to modify the record, select the Edit item on the pop-up menu.

Operating TM

p. 120 of 179

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

p. 121 of 179

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

p. 122 of 179

Fig. 88 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. 89 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.

Operating TM

p. 123 of 179

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. 90) is designed to store the log of user authentication attempts.

Fig. 90 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. 91) presents an account of user access to database objects and actions that users performed.

Operating TM

p. 124 of 179

Fig. 91 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.

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

p. 125 of 179

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

Fig. 92 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.

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. 92).

MVTS Pro Redundancy

p. 126 of 179

When one of the MedNodes fails, (as MedNode1 in Fig. 93) 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. 93 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. 92).

When a SigNode fails (as for example SigNode1 in Fig. 94) 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

p. 127 of 179

Fig. 94 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. There are two possible BalNode redundancy configurations:

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. 95) is entered as that of the alternate SIP proxy/gatekeeper. If the primary BalNode fails (see BalNode1 in Fig. 95), the terminal equipment will forward arriving calls to the failover BalNode (BalNode2 in Fig. 95).

MVTS Pro Redundancy

p. 128 of 179

Fig. 95 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. 96).

Fig. 96 Entry point redundancy: router supporting Server Load Balancing

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.

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:

MVTS Pro Redundancy

p. 129 of 179

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:

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.

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

p. 130 of 179

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.

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 in Fig. 97.

MVTS Pro Redundancy

p. 131 of 179

Fig. 97 Nodes of primary and failover server

7.7.2. CONFIGURATION FILES Below are configuration files for the primary and failover servers of the System in Fig. 97. 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

p. 132 of 179

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

p. 133 of 179

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

p. 134 of 179

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

p. 135 of 179

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

p. 136 of 179

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

p. 137 of 179

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 138 of 179

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. 98 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 wether 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 untility 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:

[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

#> mysql mysql> stop slave; mysql> reset slave; mysql> reset master;

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:

[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

#> mysql mysql> show master status; mysql> show slave status;

#> mysql mysql> start slave;

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

Appendices


+ 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 {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.

Appendices


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 «\».

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.

Appendices


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.

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 keyword blank matches an empty SRC number. This keyword may be used in the search pattern only. For example, the rule b l a n k / 1 2 3 will translate all empty SRC numbers into number 123;

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

Appendices


• 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 dial peers.

• 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 whenever possible, use first originator codec

Do not proxy 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 3).

Table 3 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.

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

Appendices



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.

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 4 and Section 6.2.1).

Table 4 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.

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

11.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 5 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 regestering user RegistrationReject with the cause SecurityDenial.

11.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 6 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 Unqiue ID string M

26 xpgk-record-id 1 Unqiue 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 7 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).

11.3. ACCOUNTING REQUEST

11.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 8 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 whicj 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 Acc-tSession-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.

11.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 9 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

26 xpgk-record-id 1 Unique ID xpgk-record-id=<string>

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 Acc-tSession-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.

11.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 10 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 11 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

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

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

11.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. 99 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.

11.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. 100 MD5 authentication

11.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. 101 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


11.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. 102), the user is authenticated, otherwise the authentication fails.

Fig. 102 Digest authentication

Appendices


12. APPENDIX E. 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:

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

Appendices


13. APPENDIX F. CONFIGURING DISK SPACE MONITOR The Disk Space Monitor utility checks the specified directories for free disk space. If the amount of free disk space is less than defined in the configuration file, the System sends a notification to e-mail. To set up the utility do the following:

Make sure that you have mvts3g-mail installed (typically in /usr/sbin/mvts3g-mail).

Edit the mvts3g-mail configuration file (/etc/mvts3g/mvts3g-mail.conf):

a. Set up the "FROM" and "TO" parameters.

b. Add the "DISKSPACE" value to the parameter list "ALARM_ID".

c. Make sure that the "CRITICAL" value is specified in the "ALARM_SEVERITY" parameter.

Set up your Mail Transfer Agent (Sendmail, Exim, etc) to send e-mail notifications.

Test the Mail Transfer Agent by sending an e-mail using the command:

#> echo "Test mvts3g-mail." | mvts3g-mail /etc/mvts3g/mvts3g-mail.conf -a -iDISKSPACE -sCRITICAL

Specify the free disk space limit of the directories in the /etc/mvts3g/mvtspro-diskspace.conf configuration file.

Define the desired checking period in the /etc/cron.d/mvtspro-utils file.

The configuration file mvtspro-diskspace.conf for Disk Space Monitor is located in the directory /etc/mvts3g/. The parameters for the utility are specified on every line as follows:

<directory> <free space limit>

where:

<directory> - the directory check for free space.

<free space limit> - minimum amount of free disk space in the directory, in megabytes; if the amount of free disk space is less than specified, the System sends a e-mail notification.

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..................................................................................................................20 Fig. 4 Example of IP zoning................................................................................................................................27 Fig. 5 Configuring zones in the file system.conf.................................................................................................28 Fig. 6 Example of “location” section configuration ............................................................................................29 Fig. 7 Excerpt from the file snmpd.conf..............................................................................................................32 Fig. 8 Excerpt from the file snmpd.conf.sample .................................................................................................32 Fig. 9 Excerpt from the file etc/default/snmpd....................................................................................................33 Fig. 10 Excerpt from the output of the ‘snmpwalk’ command............................................................................33 Fig. 11 Configuration of scripting node logging .................................................................................................34 Fig. 12 Scripting node logging configuration section .........................................................................................34 Fig. 13 Traffic Switch administration console ....................................................................................................36 Fig. 14 Output of the show ca(lls) command ......................................................................................................37 Fig. 15 Using regular expressions to view information about system events......................................................38 Fig. 16 TM objects and GUI elements ................................................................................................................40 Fig. 17 GUI elements ..........................................................................................................................................40 Fig. 18 Logon dialog box ....................................................................................................................................41 Fig. 19 Web interface main view ........................................................................................................................41 Fig. 20 Pop-up menu ...........................................................................................................................................42 Fig. 21 Filter construction dialog ........................................................................................................................44 Fig. 22 Target filter .............................................................................................................................................46 Fig. 23 Filter construction. Step 1 .......................................................................................................................46 Fig. 24 Filter construction. Step 2 .......................................................................................................................47 Fig. 25 Filter construction. Step 3. Adding group ...............................................................................................47 Fig. 26 Filter construction. Step 4 .......................................................................................................................48 Fig. 27 Filter construction. Step 5 .......................................................................................................................48 Fig. 28 Filter construction. Step 6 .......................................................................................................................49 Fig. 29 Filter construction. Step 7 .......................................................................................................................49 Fig. 30 Saving a filter for future use....................................................................................................................50 Fig. 31 Selecting an earlier saved filter ...............................................................................................................50 Fig. 32 Re-arranging table columns ....................................................................................................................51 Fig. 33 Editing multiple table records .................................................................................................................52 Fig. 34 Viewing the System component versions in the web interface ...............................................................54 Fig. 35 Add-user dialog.......................................................................................................................................55 Fig. 36 Web authentication dialog box................................................................................................................56 Fig. 37 Role assignment dialog box ....................................................................................................................57



Fig. 38 Creating a new role .................................................................................................................................57 Fig. 39 The new role ready to be compiled .........................................................................................................58 Fig. 40 Role construction window.......................................................................................................................58 Fig. 41 Add User Wizard dialogue box...............................................................................................................59 Fig. 42 User account dialogue box ......................................................................................................................59 Fig. 43 Authentication dialogue box ...................................................................................................................59 Fig. 44 Roles dialogue box..................................................................................................................................60 Fig. 45 Create user final dialogue box.................................................................................................................60 Fig. 46 Realms table............................................................................................................................................61 Fig. 47 Adding a new realm ................................................................................................................................61 Fig. 48 Entering the ID of a new realm into Config.php.....................................................................................62 Fig. 49 List of configured gateways ....................................................................................................................62 Fig. 50 Configuring a gateway record.................................................................................................................63 Fig. 51 Table of configured zones.......................................................................................................................74 Fig. 52 Add zone dialog box ...............................................................................................................................74 Fig. 53 Table “Codec groups”.............................................................................................................................74 Fig. 54 Adding a codec group .............................................................................................................................75 Fig. 55 Table of codecs .......................................................................................................................................75 Fig. 56 Configuring codec groups .......................................................................................................................76 Fig. 57 Table of pre-routing number transformation rules ..................................................................................77 Fig. 58 Dialog box for pre-routing translation rules............................................................................................78 Fig. 59 Table of DPs ...........................................................................................................................................80 Fig. 60 Add dial peer dialog................................................................................................................................80 Fig. 61 Example of destination number regexp patterns tree ..............................................................................81 Fig. 62 Table with a list of available routing policies .........................................................................................84 Fig. 63 Routing policy form................................................................................................................................86 Fig. 64 Mistyped expression requiring a validity check......................................................................................86 Fig. 65 Corrected expression after validity check ...............................................................................................86 Fig. 66 Call simulation dialog .............................................................................................................................87 Fig. 67 Call simulation results.............................................................................................................................88 Fig. 68 Call progress log header when viewed from table Debug calls ..............................................................88 Fig. 69 Invoking the call log for viewing ............................................................................................................89 Fig. 70 Call progress log view.............................................................................................................................90 Fig. 71 Using partial expansion control for contents viewing.............................................................................90 Fig. 72 Debug call log .........................................................................................................................................92 Fig. 73 Viewing a CDR record............................................................................................................................97 Fig. 74 CDRs scheduled export form................................................................................................................100 Fig. 75 Making up a list of exported CDR data.................................................................................................101 Fig. 76 Creating a report....................................................................................................................................106



Fig. 77 Tables Report contents and All reports .................................................................................................107 Fig. 78 Viewing report contents ........................................................................................................................109 Fig. 79 Charts ....................................................................................................................................................110 Fig. 80 Table of global configuration parameters .............................................................................................112 Fig. 81 Table of GUI parameters.......................................................................................................................114 Fig. 82 Setting the parameter Maximum number of rows displayed in GUI tables ..........................................115 Fig. 83 Table of call disconnect codes ..............................................................................................................116 Fig. 84 Table of configured RADIUS servers...................................................................................................116 Fig. 85 Adding a RADIUS server record ..........................................................................................................117 Fig. 86 ENUM server properties form ..............................................................................................................120 Fig. 87 Entering DNS server data......................................................................................................................121 Fig. 88 Adding a new area record .....................................................................................................................122 Fig. 89 Area specifics dialog.............................................................................................................................122 Fig. 90 Authentication history table ..................................................................................................................123 Fig. 91 Page with user activity transcripts.........................................................................................................124 Fig. 92 Simplest MVTS Pro redundancy solution.............................................................................................125 Fig. 93 Diversion of media flows to healthy media node..................................................................................126 Fig. 94 Reassignment of new call arrivals after SigNode1 fails........................................................................127 Fig. 95 Signaling entry point redundancy: gateway supporting alternative SIP proxy/gatekeeper ...................128 Fig. 96 Entry point redundancy: router supporting Server Load Balancing......................................................128 Fig. 97 Nodes of primary and failover server....................................................................................................131 Fig. 98 Example of a redundant System layout using Linux Heartbeat ............................................................141 Fig. 99 Standard RADIUS authentication .........................................................................................................171 Fig. 100 MD5 authentication.............................................................................................................................172 Fig. 101 CHAP authentication ..........................................................................................................................172 Fig. 102 Digest authentication...........................................................................................................................173

List of Tables

p. 179 of 179

List of tables

Table 1 Syntax of the configuration file system.conf..........................................................................................16 Table 2 TS alarms ...............................................................................................................................................30 Table 3 CLI commands .......................................................................................................................................36 Table 4 CLI tools.................................................................................................................................................37 Table 5 Filter construction dialog controls..........................................................................................................44 Table 6-1 Symbolic representation of statistical data used in configuring routing policies. ...............................85 Table 6-2 Filename format specifiers................................................................................................................103 Table 3 Actions of the Traffic Manager with the originator codecs depending on the proxying mode ............156 Table 4 Actions of the Traffic Manager with the terminator codecs depending on the proxying mode ...........157 Table 5 AccessRequest structure in authorization request for a registering endpoint .......................................159 Table 6 AccessRequest structure in pre-routing call authorization ...................................................................160 Table 7 Content of AccessAccept response from RADIUS server in pre-routing call authorization................162 Table 8 Structure of Accounting Start record forwarded to RADIUS server....................................................162 Table 9 Structure of the Accounting Stop record sent to RADIUS server ........................................................165 Table 10 Structure of routing request sent to RADIUS server ..........................................................................168 Table 11 Structure of AccessAccept response from RADIUS server ...............................................................169

mvts pro operator's manual v.1.2.1.30 eng

Documents