MVTS Pro Eng

© MFI soft 2007

MVTS Pro

Operator's manual

MVTS Pro VoIP traffic management system

Document №: 1

Document type: Operator's manual

Document status: Draft

Date of issue: 23.04.2008

Software product: MVTS Pro

Copyr ight © 2007-2008 MFI sof t Al l r ights reserved. MFI soft 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 MFI sof t . No part of th is publ icat ion may be reproduced or copied in any form or by any means – graphic, electronic or mechanical including photocopying, recording, taping, or any other informat ion storage and retr ieval system – wi thout wr i t ten consent of MFI soft No th ird party, organizat ion or individual, is author ized to grant such permission.

History of changes

Date Version Description 01.02.2008 Tech.writer

draft 1. Description of section 7.1.3 changed (made in more detail) 2. Added description of parameter gui.default_tz to section

7.2.1 3. Replaced name of parameter Max.DNIS call duplication

with Max. same DNIS calls (see 7.3.1.1) 29.02.2008 Tech.writer

draft 1. Section 9.2 DB backup, retention and re… added

Contents

1. INTRODUCTION ....................................................................................................................................11 1.1. DOCUMENT PROFILE ............................................................................................................................11 1.2. AUDIENCE............................................................................................................................................11 1.3. NOTATIONAL CONVENTIONS................................................................................................................11 1.4. DOCUMENT STRUCTURE ......................................................................................................................11

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

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

3. TRAFFIC SWITCH: INSTALLATION AND CONFIGURATION ...................................................18 3.1. TS INSTALLATION................................................................................................................................18 3.2. PHOENIX AND CONFIGURATION FILE PHOENIX.CONF............................................................................18 3.3. OVERVIEW OF THE CONFIGURATION FILE SYSTEM.CONF......................................................................19 3.4. IP ZONES..............................................................................................................................................22 3.5. TS NOTIFICATION FUNCTION................................................................................................................23 3.6. TS REDUNDANCY.................................................................................................................................26 3.7. SNMP DAEMON CONFIGURATION ........................................................................................................29

4. TM INSTALLATION AND CONFIGURATION .................................................................................32 5. TRAFFIC SWITCH ADMINISTRATION............................................................................................33

5.1. TRAFFIC SWITCH ADMINISTRATION CONSOLE ......................................................................................33 5.2. TROUBLESHOOTING .............................................................................................................................35

5.2.1. File phoenix.log...........................................................................................................................35 5.2.2. Files rtinfo ...................................................................................................................................35 5.2.3. mvts3g-logextarctor utility...........................................................................................................36

6. WEB-INTERFACE ..................................................................................................................................37 6.1. WHAT YOU SEE ON THE SCREEN...........................................................................................................37 6.2. STANDARD PROCEDURES .....................................................................................................................37

6.2.1. Accessing TM through web-server ..............................................................................................38 6.2.2. Pop-up menu................................................................................................................................39 6.2.3. Use of filters ................................................................................................................................40 6.2.4. Sorting table data ........................................................................................................................46 6.2.5. Re-arranging table columns ........................................................................................................47 6.2.6. Editing multiple table records .....................................................................................................48 6.2.7. Data export..................................................................................................................................48

7. OPERATING TM.....................................................................................................................................50 7.1. SYSTEM USERS.....................................................................................................................................50

7.1.1. System users.................................................................................................................................50 7.1.2. User roles ....................................................................................................................................51 7.1.3. Authentication..............................................................................................................................51

7.2. GUI MANAGEMENT..............................................................................................................................52 7.2.1. Configuration ..............................................................................................................................52

7.3. CATEGORY OF OBJECTS MVTS PRO ....................................................................................................54 7.3.1. Configuration ..............................................................................................................................54 7.3.2. Equipment....................................................................................................................................59 7.3.3. Routing ........................................................................................................................................70 7.3.4. CDRs ...........................................................................................................................................76 7.3.5. CDRs scheduled export ...............................................................................................................79 7.3.6. Statistics.......................................................................................................................................85 7.3.7. This instant information...............................................................................................................88

9.1.2. Debugging ...................................................................................................................................91 9.2. DB BACKUP, RETENTION AND RECOVERY ............................................................................................95

9.2.1. DB specifics affecting backup policy ...........................................................................................95 9.2.2. Backup tools and utilities ............................................................................................................96 9.2.3. Configuring SSH public key authentication.................................................................................96 9.2.4. Configuring DB backup...............................................................................................................97 9.2.5. Launching backup........................................................................................................................97 9.2.6. Unattended backup arrangements ...............................................................................................98 9.2.7. DB recovery procedure ...............................................................................................................98

10. APPENDIX A. METACHARACTERS, REGULAR EXPRESSIONS AND NUMBER TRANSFORMATION .............................................................................................................................99

10.1. USE OF METACHARACTERS IN SEARCH.................................................................................................99 10.2. USE OF REGULAR EXPRESSIONS IN SEARCH..........................................................................................99 10.3. NUMBER TRANSFORMATION ..............................................................................................................101

11. APPENDIX B. MVTS PRO DISCONNECT CODES.........................................................................103 11.1. TS LOCAL DISCONNECT CODES ..........................................................................................................103 11.2. TM DISCONNECT CODES ....................................................................................................................104

Illustrations

Fig. 1 MVTS Pro architecture .............................................................................................................................13 Fig. 2 Excerpt from the file phoenix.conf.sample.local. .....................................................................................19 Fig. 3 Configuration file system.conf..................................................................................................................20 Fig. 4 Example of IP zoning................................................................................................................................22 Fig. 5 The 'mated-pair-start.sh’ script.............................................................................................................26 Fig. 6 The 'mated-pair-stop.sh’ script .............................................................................................................26 Fig. 7 Excerpt from the file phoenix.conf of the master server ...........................................................................26 Fig. 8 Excerpt from the file system.conf .............................................................................................................27 Fig. 9 Output of the ifconfig command ...............................................................................................................28 Fig. 10 Excerpt from the file phoenix.conf of the slave server ...........................................................................28 Fig. 11 Excerpt from the file phoenix.log on slave server...................................................................................28 Fig. 12 Excerpt from the file snmpd.conf............................................................................................................29 Fig. 13 Excerpt from the file snmpd.conf.sample ...............................................................................................30 Fig. 14 Excerpt from the file etc/default/snmpd..................................................................................................30 Fig. 15 Excerpt from the output of the snmpwalk command .............................................................................31 Fig. 16 Traffic Switch administration console ....................................................................................................33 Fig. 17 Output of the show ca(lls) command ......................................................................................................34 Fig. 18 Using regular expressions to view information about system events......................................................35 Fig. 19 TM objects and GUI elements ................................................................................................................37 Fig. 20 GUI elements ..........................................................................................................................................37 Fig. 21 Logon dialog box ....................................................................................................................................38 Fig. 22 Web interface main view ........................................................................................................................38 Fig. 23 Pop-up menu ...........................................................................................................................................39 Fig. 24 Filter construction dialog ........................................................................................................................40 Fig. 25 Target filter .............................................................................................................................................42 Fig. 26 Filter construction. Step 1 .......................................................................................................................42 Fig. 27 Filter construction. Step 2 .......................................................................................................................43 Fig. 28 Filter construction. Step 3. Adding group ...............................................................................................43 Fig. 29 Filter construction. Step 4 .......................................................................................................................44 Fig. 30 Filter construction. Step 5 .......................................................................................................................44 Fig. 31 Filter construction. Step 6 .......................................................................................................................45 Fig. 32 Filter construction. Step 7 .......................................................................................................................45 Fig. 33 Saving a filter for future use....................................................................................................................46 Fig. 34 Selecting an earlier saved filter ...............................................................................................................46 Fig. 35 Re-arranging table columns ....................................................................................................................47 Fig. 36 Editing multiple table records .................................................................................................................48 Fig. 37 Add-user dialog box................................................................................................................................50

Fig. 38 Role assignment dialog box ....................................................................................................................51 Fig. 39 Web authentication dialog box................................................................................................................52 Fig. 40 .................................................................................................................................................................52 Fig. 41 Configuring the gui.max_table_size parameter.......................................................................................53 Fig. 42 Table of global parameters......................................................................................................................54 Fig. 43 Table of call disconnect codes ................................................................................................................55 Fig. 44 Table of configured RADIUS servers.....................................................................................................56 Fig. 45 Adding a RADIUS server record ............................................................................................................56 Fig. 46 ENUM server properties form ................................................................................................................58 Fig. 47 .................................................................................................................................................................59 Fig. 48 List of configured gateways ....................................................................................................................60 Fig. 49 Configuring a gateway record.................................................................................................................60 Fig. 50 Table of configured zones.......................................................................................................................67 Fig. 51 Add zone dialog box ...............................................................................................................................67 Fig. 52 Table “Codec groups”.............................................................................................................................68 Fig. 53 Adding a codec group .............................................................................................................................68 Fig. 54 Table of codecs .......................................................................................................................................69 Fig. 55 Configuring codec groups .......................................................................................................................69 Fig. 56 Table of pre-routing number transformation rules ..................................................................................71 Fig. 57 Dialog box for pre-routing translation rules............................................................................................71 Fig. 58 Table of DPs ...........................................................................................................................................73 Fig. 59 Add dial peer dialog................................................................................................................................73 Fig. 60 Call simulation ........................................................................................................................................76 Fig. 61 Viewing a CDR record............................................................................................................................77 Fig. 62 CDRs scheduled export form..................................................................................................................80 Fig. 63 Making up a list of exported CDR data...................................................................................................80 Fig. 64 Area specifics dialog...............................................................................................................................85 Fig. 65 Reports page............................................................................................................................................86 Fig. 66 Creating a report for all DPs whose names start with toSQ ....................................................................86 Fig. 67 Tables Report contents and All reports ...................................................................................................87 Fig. 68 Viewing report contents ..........................................................................................................................88 Fig. 69 Call progress log header when viewed from table Debug calls ..............................................................92 Fig. 70Invoking the call log for viewing .............................................................................................................93 Fig. 71 Call progress log view.............................................................................................................................94 Fig. 72 Using partial expansion control for contents viewing.............................................................................94

List of tables

Table 1 Syntax of the configuration file system.conf..........................................................................................20 Table 2 TS alarms ...............................................................................................................................................24 Table 3 CLI commands .......................................................................................................................................33 Table 4 CLI tools.................................................................................................................................................34 Table 5 Filter construction dialog controls..........................................................................................................40

Terms and acronyms

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

ASR (std) 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

ASR (MVTS) ASR calculated by the MVTS intrinsic method. The MVTS ASR represents a ratio of total number of successful calls to calls total multiplied by 100. The MVTS ASR equation is: ASR (MVTS) = successful calls /total calls*100

BS Billing scheme CDR Call detail record CHAP Challenge Handshake Authentication Protocol CPC Calling party category CSV Comma separated values 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’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

DST Destination DTMF Dual Tone Multi-Frequency EMA Exponential moving average ENUM tElephone NUmber Mapping GK Gatekeeper GUI Graphical User Interface GW Gateway HC Hierarchic classifier HTTPS HyperText Transfer Protocol, Secure ITSP Internet telephony service provider IVR Interactive Voice Response LAR Look Ahead Routing MVTS Mera VoIP Tandem Softswitch NAT Network Address Translation NGN Next-Generation Networks NIC Network Interface Card PDD Post Dial Delay PSTN Public Switched Telephone Network 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 RAS Registration, Admission, Status RBT Ring-Back Tone RG Routing group

RTP/RTCP Real-Time Protocol/ Real-Time Control Protocol SBC Session Border Controller SCD SETUP-CONNECT Delay 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 tandem

softswitch as a whole TCD Total Calls Duration TM Traffic Manager TNS Target namespace TS Traffic Switch TTL Time-To-Live VoIP Voice over Internet Protocol WAN Wide Area Network

MVTS Pro page 11 of 105

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 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 Traffic Switch: installation and configuration is focused on the TS installation and configuration procedures.

Section 4 TM installation and configuration details TM installation and configuration procedures.

Section 5 Traffic Switch administration provides reference about commands of the TS administration console

Section 6 Web-interface provides overview of the TM web-interface and details standard operation procedures.

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


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)


Fig. 1 MVTS Pro architecture

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

The TM’s job is to keep and furnish data about available routing paths and provide for traffic balancing between termination equipment. Traffic switches perform all information processing and call handling.

2.1.1. TRAFFIC SWITCH (TS) Traffic Switch (TS) handles SIP and H.323 calls and performs two-way conversion of signaling protocols and voice codecs when necessary. By this means the TS 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.

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

Management node keeps all configuration data, provides centralized control over other functional modules and serves as a collection point for the System 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 endpoint) 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 provides two-way conversion of SIP/H.323 signaling protocols and traffic distribution (load balancing) between media nodes. One signaling node can work 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.

Traffic Manager node ensures interaction between the TS and TM by means of DBMS clients. It is also responsible for interaction with external billing systems and ENUM registers, codec sorting and distributing calls between termination endpoints within equipment groups.

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.2. 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, does call routing, call analysis, validation and transformation of call numbers, traffic load balancing. In addition, TM performs QoS control functions and generates of information required for external billing systems.

TM comprises three constituents:

Routing node – controls the operation of scripts ensuring the System routing mechanisms;

Database – 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.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

• 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

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

Capacity

• Up to 50,000 concurrent calls

• Call accretion rate (CPS): 300

• New registrations per second: до 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

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


3. TRAFFIC SWITCH: INSTALLATION AND CONFIGURATION

3.1. TS INSTALLATION The TS software is supplied as a dpkg installation package for the Debian Etch OS.

The installation of the supplied package is standard and does not require any special knowledge (refer to the Debian documentation for information about package management procedures). If you plan to deploy the system on multiple servers, install the TS software on all the servers involved.

During the installation process the package manager creates some new directories and installs the software constituents as follows:

/usr/sbin/mvts3g-server the TS executable; /etc/mvts3g the directory for configuration files; /var/log/mvts3g the directory for system logs; /etc/init.d/mvts3g-server the TS startup script.

Post-installation configuration procedures vary with the selected deployment scenario. When all the TS functional modules are installed on a shared hardware platform, 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 modules are installed on individual servers, complete the following steps:

Edit the configuration file phoenix.conf and start the management node and the command-line node.

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

Edit the configuration file phoenix.conf on the rest of the systems and start them.

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

Note: Prior to configuring the system insert the hardware key supplied with the installation package into the USB port of the server that hosts the management node.

The configuration files phoenix.conf and system.conf are explained in details below.

3.2. PHOENIX AND CONFIGURATION FILE PHOENIX.CONF “Phoenix” is a background process that starts up the functional modules on servers and informs them about the IP-address and port of the management node. Another job of the “phoenix” daemon is to resurrect the TS’s functional modules in case of a failure.

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 below). There are two more files in the directory /etc/mvts3g:

phoenix.conf.sample.local – a template for the configuration file phoenix.conf used on servers hosting the management node;

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

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

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

For convenience the template files are explicitly commented.

Edit the appropriate template file in any plain-text editor and copy it 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.3. OVERVIEW OF THE CONFIGURATION FILE SYSTEM.CONF The global settings of the switching system are stored in the configuration file /etc/mvts3g/system.conf, which is a plain text file written in the C-style format.

The expression ‘C-style format’ means that comments in the configuration file should be marked with the opening and closing /*…..*/ delimiters like in the C programming language.

Sections and subsections of configuration parameters are enclosed in opening and closing braces. The closing brace of sections and sub-sections must be followed by a semicolon.

Table 1 describes the syntax of the configuration file system.conf.


Table 1 Syntax of the configuration file system.conf

Element Format Example 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 */

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

Fig. 3 Configuration file system.conf


The file system.conf comprises several sections with the configuration parameters of TS modules. 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 the subsections nested within that section. For example, see the parameters rtptimeout (the maximum acceptable no-voice time in seconds) and rbtfilesdir (the directory of the sound files used for ring back tone emulation) in Fig. 2 that set 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. In the example below the no-voice time setting rtptimeout “150” for the media node ‘media-1-2” overrides the global (default) setting “90” shown in Fig. 3)

To perform general configuration of the TS system, edit the configuration file system.conf, upload it to the server with the command-line node and carry out the following command on the CLI node server:

The command execution will make the CLI node write the configuration to the hard drive.

There is also a possibility to describe the configuration of all or some TS nodes in separate files. When doing so, you should specify the file paths and the names of such files in the configuration file system.conf using the instruction ‘include’ as shown below:

The configuration procedure in this case remains the same.


3.4. IP ZONES One of the essential tasks when configuring the TS is defining IP zones. An IP zone is a set of connected networks characterized by configured routing between the IP addresses of the comprising networks and the absence of connectivity restricting devices (for example, firewalls, NAT routers etc.) within the zone.

The figure below is intended to illustrate the concept of IP zoning. Let us assume there are two networks – an intranet and the Internet with the intranet connected to the Internet through a border gateway with a firewall.

Fig. 4 Example of IP zoning

It is logical to assume that the border delimiting these two networks runs through the connectivity restricting device that is the firewall gateway on the Intranet border. To configure IP zones means to make a list of networks to which the IPs of the TS nodes belong. Suppose, the TS nodes of your system use the IPs belonging to networks 212.92.148.0/24 and 195.98.135.0/24 to connect to the Internet. In this case you configure a zone named “Internet” by drawing up a list of networks that the zone includes.

Here is an example of correctly configured IP zones:


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.

IP zoning is useful in the configuration file of the traffic switch. It is mandatory that zone descriptions in both configurations are absolutely identical.

Use the section ‘zone’ to establish a connection to configure IP 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

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

For example, suppose the signaling node is installed on a host having the IPs 192.168.18.12 and 212.92.148.70 (see the IP zoning described above) and the node needs to make a call to the address 81.10.1.1 using the IP zone named "Internet". In this case the signaling node will select the IP 212.92.148.70 for the call source address because the IP 212.92.148.70 belongs to the zone “Internet”.

IP zones can also be used for uplink selection. In such a case each element of the cluster is assigned N amount of IPs (where N equals or exceeds the number of uplinks) and IP zones are configured in such a way that the 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 for traffic.

3.5. 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]�




2. List of alarms and severity degrees:

ALARM_ID="SIG2MED001, NODFLT001, DBMS001, TM001, TM002, TM003, TM004, TM005, MGMKEY001, MGMTCN001, MP001" – 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 DBMS001 Critical DBMS client DBMS not connected TM001 Critical TrafficManager Unknown TM002 Critical TrafficManager Disallowed DBMS

version TM003 Minor TrafficManager Allowed DBMS version

mismatch TM004 Major TrafficManager Wrong DNS address TM005 Critical TrafficManager No link to DBMS TM006 Critical TrafficManager DBMS overload, calls are

missing TM007 Critical TrafficManager Link to DBMS not ready TM010 Minor TrafficManager Wrong ENUM Allow

Regex TM011 Minor TrafficManager Wrong ENUM Deny

Regex MGMCFG001 Critical Management System is not configured MGMTCN001 Critical Management Trial period expired MGMKEY001 Critical Management Failed to read hardware

key

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 global TS configuration file. To configure notification, define the following parameters:

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

• counter – counter name

• type – nature of changes (increase or decrease). Valid values: type "increment"/type "decrement"

• limit – defines the notification threshold


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

Below is an example of a properly configured alert:

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

COUNTER NAME: rsappng.dbmsclient.average_query_time

COUNTER VALUE: 259

DESCRIPTION: Average query time

Counter value more than 100

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

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


3.6. TS REDUNDANCY The operational dependability of the servers hosting TS nodes is achieved through mirroring key System components. Mirror servers function as hot-standby platforms continuously ready to take over from primary servers (master servers) should any of them fail.

The TS failover-failback is ensured by scripts installed on both master and slave servers: the script /usr/libexec/mvts/mated-pair-start.sh gets up the defined public IP address (i.e. the IP address used for traffic handling), while the script /usr/libexec/mvts/mated-pair-stop.sh gets the defined public IP address down.

The figures below present two screenshots of the failover scripts with IP address 192.168.132.240 configured as public.

Fig. 5 The 'mated-pair-start.sh’ script

Fig. 6 The 'mated-pair-stop.sh’ script

Configuring master server

To configure the master server for redundancy proceed as follows:

1. Add the section ‘master’ to the configuration file phoenix.conf and specify the public IP address and an arbitrary unused port in it as shown in the figure below (for more information about phoenix.conf refer to section 3.2).

Fig. 7 Excerpt from the file phoenix.conf of the master server

2. Enter the public IP in the configuration file system.conf as shown in the figure below:


Fig. 8 Excerpt from the file system.conf

3. When done, restart the application:

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

4. Upon restart the System re-reads the configuration files and gets the public IP address up.


Fig. 9 Output of the ifconfig command

Configuring slave server

Configuration of the slave server is almost identical to the configuration of the master server except for the file phoenix.conf, which includes the section ‘slave’ instead of the section ‘master’ but with the same public IP address (see the figure below).

Fig. 10 Excerpt from the file phoenix.conf of the slave server

Should the master server fail the script on the failover server gets the public IP addresses up on its NIC, switches to operating as the master server and starts handling traffic. The file /var/log/mvts3g/phoenix.log will include the following messages:

Fig. 11 Excerpt from the file phoenix.log on slave server


When the problem is eliminated and the master server is ready for operation run the /usr/libexec/mvts3g/mated-pair-stop script to get the public IP down and return the fail-over server to the slave mode.

Management node redundancy

To ensure redundancy of the machine hosting the TS’s management node you will need to plug in a backup hardware key into the USB port of the slave server. Note that the backup key is programmed for a limited time agreed upon in the sales contract.

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

Fig. 12 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 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. 13 Excerpt from the file snmpd.conf.sample

Define the actual IP address of the TS Management node and, if necessary, define the list of the System counters to be monitored. Note that if the list of system 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 on 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'".

Fig. 14 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 Management node

.1.3.6.1.4.1.28029 – MVTS Pro enterprise OID

Fig. 15 Excerpt from the output of the snmpwalk command

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


4. TM INSTALLATION AND CONFIGURATION Currently the components of TM are installed and configured by the engineers of MFI soft.


5. TRAFFIC SWITCH ADMINISTRATION

5.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. 16 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 5 and Table 6 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


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

Use this command to view information about:

calls call sessions in progress

counters system events endpoints or ep equipment registered to the

system

show

status system status

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

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

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

5.2. TROUBLESHOOTING

5.2.1. FILE PHOENIX.LOG All the 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 find out the cause of the trouble.

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

#> ps grep mvts

#> kill –USR1 24342

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


5.2.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 a 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.


6. WEB-INTERFACE The web server provides a friendly graphic interface for convenient configuration and administration of TM.

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

Fig. 19 TM objects and GUI elements

Fig. 20 GUI elements

6.2. STANDARD PROCEDURES This chapter covers standard procedures used when working with the TM GUI.


6.2.1. ACCESSING TM THROUGH WEB-SERVER To establish a link with the web server, enter the IP address or DNS name of the web server on the address line of the web browser you are using. for example https://192.168.1.101. 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. 21

Fig. 21 Logon dialog box

Enter your login and password (note that the login and password check in the system is case-sensitive), and click Login. In case you are using your IP address as the authentication parameter simply click Login. If the user 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 in tabular representation.

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

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

https://192.168.1.72.158.23/�


6.2.2. POP-UP MENU Right-click the record of interest in the table you are viewing to invoke a pop-up menu that offers record manipulation options. The content of the pop-up menus is contextual, that is, differ from table to table and depends on the user permissions. The figure below presents an example of the pop-up menu that you invoke to work with records of the table.

Fig. 23 Pop-up menu

Typically a pop-up menu contains the following commands:

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

Add from copy – this command may be instrumental when you need to create a copy of an existing record or a record that differs from the existing one in the values of one or two parameters.

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.

Delete all filtered – this command allows you to delete all the records form 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 6.2.3).

Filter – invokes a filter dialog box (for information how to use filters consult section 6.2.3);

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

Export data – use this command to unload data from the tables into CSV-files (for information about data export refer to section 6.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 Users table and select User rights on the pop-up menu. The system will display the User rights table with information about the rights of the selected user only.

6.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 system allows 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 filte, invoke the pop-up menu and select Filter. The system will display a filter dialog similar to the one shown in Fig. 24.

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


Control Description

This control appears on the filter dialog after the application of the filter only. Use it to cancel th 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 appearance of this dynamic control element varies with the selected logical operator

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

Combo box with drop-down list of saved filters.

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

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

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

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

Fig. 25 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 Enable in the newly added combo box and select the check box to the right of the equal sign "=" (see Fig. 26).

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


3. Add a group of conditions by clicking the control * AND * and selecting the Add group option in the appearing menu (see Fig. 28). Обратите внимание, что по умолчанию для создаваемых групп устанавливается логический оператор “И”.

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



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



7. Repeat steps 5 and 6 to add a similar condition ofr 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 ).


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

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


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

Fig. 34 Selecting an earlier saved filter

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

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

Fig. 35 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 Up and Down buttons allows you to move the columns to the left or to the right, respectively. 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.

The system will remember the table layout 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.


6.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. 36 illustrates such multiple-edit dialog box invoked from the table ‘Gateways’.

Fig. 36 Editing multiple table records

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

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


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.


7. OPERATING TM

7.1. SYSTEM USERS

7.1.1. SYSTEM USERS The table of System users (System users → User accounts) presents information about organization personnel who perform system administration tasks.

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

Fig. 37 Add-user dialog box

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

*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 assigning the user a role (see section 7.1.2) and entering the user’s authentication data that enables web access to the System (see section 0)


7.1.2. USER ROLES 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 combo boxes.

Fig. 38 Role assignment dialog box

Note: Currently there exists only one role in the System, the role Administrator. Users assigned the role Administrator have access to all GUI objects

When done, click the OK button.

7.1.3. AUTHENTICATION This table presents user authentication and authorization data used during logon for web access 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. 39 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

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

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.

7.2. GUI MANAGEMENT

7.2.1. CONFIGURATION The table GUI configuration includes parameters essential for GUI management, which are as follows:

Fig. 40

gui.table.page_sizes – use this parameter to define the size of a table page expressing it in a number of rows per page. Entering a list, delimit the list element with commas. For example, 10, 20, 30, 50.

gui.table.default_page_size – 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.


gui.table.max_size – use this parameter define the maximum number of table records displayed in GUI. Should the actual number of records in the DB exceed the specified table size limit apply a filter to view the table data. The parameter serves to expedite the display of tables with large amounts of data (for example, tables of CDRs).

gui.csv.date_format – this parameter allows the user to define a date format applied to exported data;

gui.csv.delimiter – you can use this parameter to select a symbol to be used to delimit data fields in data export files, for example “,” or “;”.

gui.csv.quote – serves to define a symbol to enclose data fields in data export files, for example, quotes.

gui.csv.null – serves to define a symbol or symbols that will be used to fill empty data fields in data export files.

gui.default_tz – use this parameter to specify the default time zone for the GUI

To configure a parameter point the mouse to the desired record in the table. Right-click to invoke the pop-up menu and select Edit.

Fig. 41 Configuring the gui.max_table_size parameter

Type the required parameter value in the edit field Value (see Fig. 41) and click the OK button. To discard the made changes click Cancel.


7.3. CATEGORY OF OBJECTS MVTS PRO

This is the essential object category of the system GUI embracing the subcategories of objects intended for configuration of the main system functionalities.

7.3.1. CONFIGURATION The subcategory Configuration comprises the objects pertaining to system global settings, call disconnect codes and interoperation with RADIUS, ENUM and DNS servers.

7.3.1.1. Global settings The view Global settings displays a list of the system global parameters.

Fig. 42 Table of global parameters

Currently MVTS name is the only configuration parameter accessible to the MVTS Pro administrator for editing. Click the button Switch to edit mode to change the name of the configured control subsystem.


7.3.1.2. 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 6.2.3 for information about the use of search filters.

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

7.3.1.3. RADIUS servers The table RADIUS servers presents information about configured RADIUS servers used as external authentication, accounting and/or routing means.


Fig. 44 Table of configured RADIUS servers

To add a RADIUS server record, right click the mouse over the table and select Add on the pop-up menu.

Fig. 45 Adding a RADIUS server record

Fill out the displayed server configuration form (see Fig. 45.) 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. At each instance of time MVTS Pro interacts with one server only. If the system detects a failure of the RADIUS server it is currently connected to, it will switch to the next configured server according to the specified 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.

*Zone – select a zone to be used for communication with the RADIUS server;

*Secret key – enter a coding key (according to the ‘shared secret’ standard) for communication with the RADIUS server.

Retry number – use this parameter to specify the number of send attempts for the packets destined for the RADIUS server.

Retry period – use this parameter to set the interval (in seconds) between consecutive send attempts.

Enable debug – select the check box to enable logging of the system interoperation with the server.

Authentication – these parameters are valid only with the selected Enable authentication checkbox:

Authentication address – enter the IP address for authentication on the RADIUS server.

Authentication port – enter the port for authentication on the RADIUS server

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.

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.


7.3.1.4. 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 another ENUM server, invoke the pop-up menu and select Add.

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

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.

http://www.ietf.org/rfc/rfc3761.txt�


7.3.1.5. DNS-cерверы The table “DNS servers” allows an overview of 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. 47

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.

Select the Enable checkbox to validate the record.

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

7.3.2. EQUIPMENT 7.3.2.1. Gateways

The table Gateways displays information about the equipment that MVS Pro interoperates with.


Fig. 48 List of configured gateways

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

Fig. 49 Configuring a gateway record

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

*Gateway name – enter the name of the device being configured;

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


Enable – select the checkbox to make the record active

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

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

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

Is registering device – select the checkbox to indicate that the device is a registering gateway

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 will use the SIP port specified in the parameter DST SIP port.

*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

Category Location

* SRC Zone – use the combo box to select the zone (see section 7.3.2.2) to be used for calls originated by the device

SRC Address list – define the list IP addresses used by the device for call origination (you can use the CIDR format for IP addresses)

SRC 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 have the same IP address and the call originator can be distinguished solely by the singnaling port number. Otherwise, leave this field empty.

* DST Zone – use the combo box to select the zone (see section 7.3.2.2) to be used for calls sent to the device

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

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

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

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

DST Use gatekeeper – 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.

DST Use gatekeeper 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.

DST Use gatekeeper 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.

DST Gatekeeper id – enter the gatekeeper ID that will be used in the ARQ/LRQ requests.


DST Gatekeeper address – enter the gatekeeper IP address

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

Category SRC capabilities. This group of parameters is intended for configuration of origination devices. The parameters are valid only with the Is origination device checkbox selected.

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

SRC Capacity – the capacity value is the maximum number calls the device can handle simultaneously

* SRC Proxy type – define the media proxy mode to be used when the device acts as a call originator:

Force proxy

Non-proxy recommended

Force non-proxy

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

* SRC Allowed codecs – 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 7.3.2.3)

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

DST Resource name – select the name of the resource 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 resource, the total amount of simultaneous calls sent to them will not exceed the value specified in the field SRC Capacity.

DST Capacity – the capacity value is the maximum number of calls the device can handle simultaneously

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

Force proxy

Non-proxy recommended

Force non-proxy

* DST Allowed codecs – 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 7.3.2.3)

Category SRC routing. This group of parameters allows the configuration of properties important for routing when the device is the call source. The parameters are valid only with the Is origination device checkbox selected.


SRC Groups – enter the name of the gateway groups that will be used for routing of calls originated by the device.

SRC ANI 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). Note that this rule will be applied to the numbers before routing procedure starts.

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

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

SRC Allowed ANIs – enter a regular expression that determines the pattern for allowed source numbers;

SRC Allowed DNIS prefixes – enter a regular expression that determines the pattern for allowed destination numbers;

SRC Disallowed DNIS prefixes – enter a regular expression that determines the pattern for disallowed destination numbers.

Category DST routing. This group of parameters allows the configuration of properties important for routing when the device is the call destination. The parameters are valid only with the Is termination device checkbox selected.

DST ANI translation – enter a regular expression that determines calling number transformation rules for the cases when the gateway is a termination device;

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

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

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

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

Category SRC packet management. 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.

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

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

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

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

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


SRC Validation gap, 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.

Category DST packet management. This group of parameters is intended for configuration of the gateway properties when the gateway is a termination devices. The parameters are valid only with the Is termination device checkbox selected.

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

DST Call retries – define the maximum number of redial attempts

DST Retry interval, sec – define the interval between redial attempts in second

DST Redial codes – make a list of disconnect codes that will cause the redial procedure.

Category SRC settings under H.323 – this group of parameters is intended for the configuration of H.323 properties of the origination gateway. The parameters are valid only with the Is origination device checkbox selected.

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

SRC Faststart – select this checkbox if the device is FastStart capable

SRC Response FastStart – select the appropriate checkbox to define which message will include the FastStart packet. The possible options include

- in Call Proceeding,

- in Alerting/Progress,

- in Connect;

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

SRC 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

Category DST settings under H.323. This group of parameters is intended for the configuration of H.323 properties of the termination gateway. The parameters are valid only with the Is termination device checkbox selected.

* DST ANI Type of number – specify the type of source numbers supported by the device using the drop-down list of this combo box.

* DST ANI Numbering plan – define the numbering plan supported by the device using the drop-down list of this combo box

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


* DST DNIS Numbering plan – define the numbering plan supported by the device using the drop-down list of this combo box

*DST ANI Presentation indicator – define the value of the presentationIndicator element of the SETUP message using the drop-down list of this combo box.

* DST ANI Screening indicator –define the value of the screeningIndicator element of the SETUP message using the drop-down list of this combo box.

DST Faststart – select this checkbox if the device is FastStart capable

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

DST 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

Category DST settings under SIP. This group of parameters is intended for configuration SIP properties of the gateway operating as a termination device. The parameters are valid only with the Is termination device checkbox selected.

* DST Report original destination – this combo box includes the following options:

- No

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

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

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

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

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

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

DST 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

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�


forwarding and if not the call is rejected. When making a list, delimit the masks you are entering with semicolons without spaces.

Category Network

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

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.

Debug

SRC Enable logging – select the check box to enable the debug logging functionality for situations when the device originates calls;

DST Enable logging – select the check box to enable the debug logging functionality for situations when the device terminates calls;

RAS – this group of parameters is intended for configuration of registering gateways. The parameters are valid only with the Acts as RAS user checkbox selected.

Registration username – enter a registration name for the device;

Registration password – specify a registration password;

Registration TTL, sec – set a registration update interval (in seconds) for RAS users registered with the MVTS Pro

Registration address list – enter a list of IP addresses allowed for registration with MVTS delimiting them with semicolons;

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

RADIUS

RADIUS username – enter the username to be included into the packets sent to the RADIUS server in cases when the device being configured originates calls. By default for static gateways MVTS Pro uses the IP address of the call origin.

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.

ENUM

The list of configured ENUM servers is in the left window (see section 7.3.1.4). 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. The ENUM server selection tool is enabled only when the ENUM routing checkbox is selected.


Miscellaneous

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

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

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

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

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

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

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.

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

Fig. 50 Table of configured zones

Note: It is mandatory that the description of IP zones on the web-interface is identical to their description in the configuration file of the Traffic Switch.

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

Fig. 51 Add zone dialog box

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


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

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

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.

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

Fig. 52 Table “Codec groups”

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

Fig. 53 Adding a codec group

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

*Codec group name – enter the name of the group

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

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

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

7.3.2.4. Codecs The table Codecs 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. 54 Table of codecs

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

Fig. 55 Configuring codec groups

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

*Codec group – specify the group the codec will be related to using the drop-down list of this combo box (the drop-down list is populated with the names of groups from the table Codec groups, see 7.3.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);

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

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

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

Modes


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

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 operator can change this value. The greater the precedence value is the higher is precedence.

When through with entering data, click OK to add the record to the table.

To edit or delete a record, invoke the pop-up menu and select the necessary option. In a similar fashion you can add other codecs to the groups.

7.3.3. ROUTING

7.3.3.1. Transformation of calling and called numbers 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 ANI pattern or DNIS pattern and Allowed SRC groups and mismatches the pattern defined in ANI exclude or DNIS exclude and Disallowed SRC groups.

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


Fig. 56 Table of pre-routing number transformation rules

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

Fig. 57 Dialog box for pre-routing translation rules

Enter the following information in the displayed dialog (the parameters marked by the asterisk symbol «*», are required fields):

*Rule name – enter the rule name

Description – you can use this text box to enter whatever information you deem pertinent

Enable – select the check box to make the rule effective;


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

ANI pattern – enter a regular expression that determines what calling numbers require transformation. You can enter several regular expressions delimiting them with semicolons.

DNIS pattern – enter a regular expression that determines what called numbers require transformation. You can enter several regular expressions delimiting them with semicolons.;

ANI exclude – enter a regular expression that determines what calling numbers do not require transformation. You can enter several regular expressions delimiting them with semicolons.

DNIS exclude – enter a regular expression that determines what called numbers do not require transformation. You can enter several regular expressions delimiting them with semicolons.;

Allowed SRC groups – enter the name of the call origination RAS-user group that needs transformation. You can enter several names delimiting them with semicolons.

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

ANI transformation – enter a regular expression for transformation of the calling number;

DNIS transformation – enter a regular expression allowing the transformation of the called number;

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 cessation of the transformation process and call abortion with the local disconnect code configured in the field Quit with disconnect code;

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.

7.3.3.2. Dial peers In terms of MVTS Pro a dial peer is an addressable object characterized by the name of termination gateway, operating time, and number transformation rules.

Therefore, the table of dial peers (see Fig. 58) can be regarded as a dial plan comprised of records with information about possible routing paths for calls originated by static gateways and RAS users.


Fig. 58 Table of DPs

While handling a call the system searches for the best routing path taking into account the length of the matching number prefix and the dial peer precedence. The record of the dial peer selected during route hunting provides information necessary for call set up.

Of two dial peers with equal length of the matching calling number prefix the one with a greater value of the parameter * Precedence takes precedence over the other. When both lengths of the calling number prefix and values of the parameter Precedence are equal, the dial peer is selected at random.

To add a dial peer record, invoke the pop-up menu and select Add.

Fig. 59 Add dial peer dialog

Enter the necessary data in the fields of the displayed form (the asterisk symbol marks the required parameters):


* Dial peer name – enter the DP name

Description – use this text box to provide whatever information or comments concerning the record that you believe pertinent.

Enable – select the checkbox to make the record valid;

Valid from… – specify a start date of the record validity period;

Valid till... – specify an end date of the record validity period;

Filtering

ANI pattern – use a regular expression to enter a pattern for calling number prefixes suitable for this DP. When entering several expressions delimit them with semicolons.

*DNIS pattern – use a regular expression to enter a pattern for destination number prefixes allowed for this DP. When entering several expressions delimit them with semicolons.

ANI exclude/DNIS exclude – use these fields to enter regular expressions that define calling and called numbers disallowed to use the DP. You can enter several expressions delimiting them with semicolons.

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;

Capacity – specify the maximum number of simultaneous calls that the DP can handle;

Resource name – use this combo box to select a resource name from the dropdown list or select the option Manual input and type in the resource name. The resource is a group of termination gateways with a totaled capacity. When DPs belong to a resource group the total of concurrent calls forwarded to them will never exceed the value entered in the field

Number transformation

ANI transformation/DNIS transformation – enter regular expressions for desired modification of calling and called numbers respectively;

ANI transformation (billing)/DNIS transformation (billing) – enter regular expressions for modification of calling and called numbers as required for the purposes of billing;

Routing

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.

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 gateway selection 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 “ongoing-calls-to-the-gateway-capacity” ratio

Stop routing – set this flag (select the checkbox) to stop further dial peer search in situations when the gateway servicing the selected call path is inaccessible or busy.

*Gateway list – make a list of gateways available for use when the DP is selected for call termination. To add a gateway to the list, highlight its name in the left window pane and click

to move the GW name to the right window. To remove a gateway from the list

highlight its name in the right window pane and click . The buttons and serve to move all records in one click between the windows. Use the buttons Up and Down to move the gateway name one line up or down in the list.

During routing MVTS Pro attempts to set up a call sequentially starting with the first gateway on the list. The order in which the DP termination gateways are arranged in the right window represents the order in which the call termination options will be communicated to the TS.

Miscellaneous

Override default proxy mode and – this combo box allows you to override the global setting Default proxy mode and set individual proxy mode for situations when MVTS Pro interoperates with the DP being configured. The available modes of proxy operation include:

- Proxy media. During this proxy mode MVTS Pro functions as a proxy for both signaling and media.

- Do not proxy media whenever possible. This operation mode means proxy operation for media only when it is absolutely necessary.

- Do not proxy media. In this proxy mode MVTS Pro operates as a proxy for signaling only.

Originator category – this version of software disallows modification, and the parameter is always set to “Same as for the incoming leg”

When through with entering data, press the ОК button. 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.

7.3.3.3. Call simulation The object Call simulation serves to check the System configuration during troubleshooting and in situations when customers complain of improper System functioning.

To simulate a call enter a calling and called number in the fields ANI number and DNIS number respectively. Specify the IP address of the origination gateway in the field *SRC address (a required parameter). Select the signaling protocol from the dropdown list SRC protocol, and press OK.

The field DNIS number is a required parameter.

Results of the call simulation will be displayed in the field Routes.


Fig. 60 Call simulation

7.3.4. CDRS

The subcategory CDRs includes six tables that display call detail records (CDRs) used in metering and billing. CDRs are generated according to the ‘one call – one record’ principle.

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


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

Fig. 61 Viewing a CDR record

CDRs may contain the following information:

ID – the unique identifier of the record

CDR date – date of the record creation

Incoming ANI number – calling number as received from the call source

Incoming DNIS number – destination number as received from the call source

Outgoing ANI number – calling number after transformation according to the configured number translation rules

Outgoing DNIS number – destination number after transformation according to the configured number translation rules

Billing ANI number – calling number used for the purposes of billing

Billing DNIS number – destination number used for the purposes of billing

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

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

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

Remote SRC media address – media IP address and port of the call originator

Remote DST media address – media IP address and port of the call originator

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


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

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

Local DST media address – IP address and port of the media node used on the outgoing leg

Incoming leg protocol – signaling protocol of the incoming leg

Outgoing leg protocol – signaling protocol of the outgoing leg

Conference ID – unique identifier of the conference the call was a party to

Incoming leg call ID – call ID on the incoming leg

Outgoing leg call ID – call ID on the outgoing leg

SRC RAS username – RAS username of the call originator

DST RAS username – RAS username of the call terminator

RADIUS username – username sent to the external RADIUS server

Origination gateway – name of the origination gateway

Termination gateway – name of the termination gateway

Dial peer – name of the dial peer

In-call time, msec – call duration in milliseconds

Setup time – timestamp of the call setup

Connect time – timestamp of the call connect

Disconnect time – timestamp of the call disconnect

Disconnect code – call disconnect code

Incoming leg codecs – list of codecs received from the call originator

Outgoing leg codecs – list of codecs received from the call terminator

SRC Faststart present -“Yes” indicates that the origination gateway declared the use of the FastStart mechanism

DST Faststart present – “Yes” indicates that the termination gateway accepted the use of the FastStart mechanism

SRC Tunneling present – “Yes” indicates that the origination gateway declared the use of the tunneling mechanism

DST Tunneling present – “Yes” indicates that the termination gateway accepted the use of the tunneling mechanism

Proxy mode – media proxy mode

LAR fault reason – reason for call routing interruption.

Routing retries – number of routing retries

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

PDD reason – type of the message, which ends the PDD time interval

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

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

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

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


SRC media packets – quantity of packets sent to and received from the call originator

DST media packets – quantity of packets sent to and received from the call termination party

SRC media packets late – number of late packets received from the call originator

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

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

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

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

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

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

DST max. jitter buffer (packets) – maximum jitter buffer size when receiving packets from the call termination party

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

The name of the file to which exported CDRs are saved is generated in the following way. The character string entered in the field CDR filename prefix is concatenated by addition of the date-time string resulting from the time stamp of the first or last exported CDR and addition of the .csv extension to CSV data files or .txt extension to plain-text files.

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 YYYYMMDD_HHMMSS part of the file name is the server’s system time.

To configure unattended export of CDRs, open the Scheduled export form (CDRs → Export → Scheduled export) and enter the parameters necessary for creation of a cron job (see Fig. 62.)


Fig. 62 CDRs scheduled export form

The list and arrangement of exported data fields can be configured with the help of the Export fields windows (see Fig. 63.)

Fig. 63 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 Up and Down 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.

The configuration parameters on the Scheduled export form have the following intent and particulars:

Enable – use this checkbox to enable/disable the scheduled CDR export function

Launch CDR export (cron job) at – is an entry in cron made up of a series of fields separated by a space. There are normally five fields in one entry. The fields are:

[minute] [hour] [day of month] [month] [day of week],

Place an asterisk (*) in the field, if you don't wish to specify a value for it. An asterisk indicates that all values in the range are acceptable.

Field entries allow:

- Lists of numbers, for example 1,2,3,5 or 1,2,5-7

- Ranges of numbers, for example, 1-5 is the same as 1,2,3,4,5

- Range entries with step values specified after a slash, for example, 1-9/2 stands for a range of values from 1 through 9, step 2, that is 1,3,5,7,9.

Valid values for days of week (the fifth data field in the string) are digits 0 through 7, where both 0 and 7 stand for Sunday.

Examples:

a. 1-59/10 * * * * (see Fig. 62) start the cron job (CDR export) at 1 through 59 minute past hour in 10 minute intervals;

b. 0 18 * * 3 – start the cron job (CDR export) every Wednesday at 18:00; c. 0 0 */2 2,4,9-12 * – start the cron job (CDR export) every other day in February, April

and in the period from September through December.

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 first exported CDR in the HH::MM::SS notation. This means that if cron is configured to start at 12:00 (0 12 * * *), and the entry in the field Min. age of export CDRs is one hour, i.e. 01:00:00, then only one-hour old and earlier CDRs will be exported, that is those that were generated before 11:00.

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

Export for the period – sets a time span for exported CDRs in the HH:MM:SS notation, that is, if the entry in the field Export for the period is 01:00:00 (one hour) then CDRs will be exported in one-hour lots. To put it differently, the time difference between the first and the last CDR in the file will be 1 hour only.

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 Export for the period or 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);

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

* Delimiter – specifies a separator symbol for data fields in export CDRs. Each CDR starts on a new line.

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

Quotation marks – allows selection of single or double quotes (or none at all) that enclose CDR data in the export file;

Use for empty fields – sets a string used in export CDRs to identify empty data fields.

Export fields – windows that allow you to change the content of export CDRs and the arrangement of data in them (see Fig. 63)

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

* Compression – allows the choice of compression methods (bzip2 or gzip) for export CDR files;

CDR filename prefix – a character string used for generation of filenames for export CDRs files;

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

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 –

Note: All FTP server related settings will be valid only when the FTP server export option is selected in the Save to combo box

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.

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

For filename use timestamp of – allows selection of a time stamp for generation of the export file name (see above). Two available options include:

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


- 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

Leading distinguisher – this field allows you to enter a distinctive character string that will precede all CDRs in the export file.

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:

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

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





7.3.6. STATISTICS The category of objects Statistics allows configuration of traffic termination areas and generation of area traffic reports.

7.3.6.1. Areas The table Areas presents information about geographical names for traffic transfer locations.

To add a record, click Add on the pop-up menu.

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.

7.3.6.2. 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. 64 Area specifics dialog

Enter the following data in the displayed dialog (the required fields are those marked инфт 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

.


7.3.6.3. Reports The object Reports is a GUI page that allows to create and view DP traffic transit reports (see Fig. 65.)

Fig. 65 Reports page

To create a report, in the dialog Create report (MVTS Pro → Statistics → Reports) enter a name for the future report, type in the name of DP in the field DP name pattern or a regular expression that defines a name pattern for several DPs, set the report period in the fields *From date and * To date and click the OK button.

Fig. 66 Creating a report for all DPs whose names start with toSQ

The newly generated report will be added to the table Report contents and to the table All reports to complement earlier generated reports.


Fig. 67 Tables Report contents and All reports

Report generation is carried out 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 is normally the call disconnect time. If there was no connect, the CDR date is the time of call setup.

2. If a DP name pattern is specified the selected CDRs are additionally filtered by the name matching the regular expression entered in the field DP name pattern.

3. For every selected CDR, the destination area is determined by max. length prefix matching the billing called number with allowance for the max. and min. number length for the area identified by the number prefix.

4. The selected CDRs are then grouped by the DP name and destination area, every group occupies a line in the generated report.

5. The statistical data calculated for each group of CDRs are as follows:

- Total minutes – суммарная продолжительность всех вызовов в минутах (по записям в группе), округлённая до целой минуты

- Total calls – общее число вызовов (число записей CDR в группе)

- Successful calls – число успешных вызовов.

Note: Successful calls are calls completed with call disconnect reason codes marked as Successful (see 7.3.1.2) or with duration in excess of 16 seconds

- ASR% – answer seizure ratio calculated by the MVTS Pro intrinsic method.

- ASR, std. – standard answer seizure ratio calculated conventionally

- ACD – average call duration for non-zero length calls

- Avg. PDD – average post dial delay, calculated for calls with PDD > 0

- Avg. SCD – SCD average, calculated for calls with SCD > 0

- First call – SETUP time of the earliest call in the group

- Last call – SETUP time of the lates call in the group

Note: First call and Last call values may happen to be earlier than the specified report interval as CDRs are filtered by the record date which normally coincides with the call Disconnect time whereas First call and Last call – are Setup time values.


To view a report, invoke the pop-up menu and select View.

Fig. 68 Viewing report contents

You cannot remove individual CDRs from a report, you can only remove the entire report form the table All reports

7.3.7. THIS INSTANT INFORMATION

This subcategory of objects allows real-time monitoring of the System operation and provides information about equipment registrations, currently handled calls, system counters, etc. The operator can view summarized information or detailed information about the operation status of every System component.


7.3.7.1. Summary This subcategory of objects Summary provides information about registrations and calls currently handled by the System.

8. Registrations This table displays data on equipment registered with MVTS Pro.

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

Under SIP possible states include:

- initial (registration started and still under way)

- active (registration completed, device is registered)

- cached (device is registered, though no keepalive received yet)

- inactive (device unregistered)

under H.323 possible states include:

- H323

- ABORTING

- AUTHORIZING

- AUTHORIZED

ID – H.323 gateway identifier

Country code

Extension H.323 vendor specific data, identifying the device manufacturer

Manufacturer code

Product ID – registered device identifier

Version – version of the registered device

TTL, sec – time to complete re-registration (time-to-live)

Aliases – names/numbers received in registration data

URL – under SIP shows the URL of the registered gateway. Under H.323 remain empty

Contacts – in case of a SIP registration shows the content of the field Contact

Expiration – time remaining till next keepalive.

9. Calls The table 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

Incoming ANI number – calling number as received from the call source

Incoming DNIS number – destination number as received from the call source

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 ANI number – calling number after transformation according to the configured number translation rules

Outgoing DNIS number – destination number after transformation done according to the configured number translation rules

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

<Management>

This sub-directory includes two objects Counters and IP zones that deliver statistical information pertaining to the Management node. The table Counters shows the state of the node counters. The table IP zones provides information about 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

- Type is the type of socket

- Address is self-explanatory.

<Signaling>

This object provides statistical information about the signaling node. In addition to information about protocols and IP zones as above 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 tables Counters and 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 Counters and 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 two tables only – Counters and IP zones.

<Scripting>

This folder contains operational statistics pertaining to the Scripting node and includes two tables only – Counters and IP zones.

<Synchro>

This folder dispalys the Synchro node operational statistics contained in two tables only – Counters and IP zones.

9.1.2. DEBUGGING The category of objects Debugging comprises three tables – the table Debug registration, the table Debug calls and the table Debug call logs.

9.1.2.1. Debug registrations


9.1.2.2. Debug calls

The table Debug calls presents a list of call progress logs for origination or termination gateways that had the debug logging checkbox selected during configuration.

To view an individual call log record in a more compact form, select the View item on the pop-up menu.

Fig. 69 Call progress log header when viewed from table Debug calls

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. 70Invoking the call log for viewing

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


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


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

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

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

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.

9.2. DB BACKUP, RETENTION AND RECOVERY DB backup ensures data retention and database structure preservation and allows recovery from bad situations caused by a corrupted file system or server HDD crash.

9.2.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 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 form 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.

9.2.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.cdrs – is created on first successful execution of the backupdb.php utility and contains information about unloaded CDR tables

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.

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

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.

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

9.2.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 running the utility backupdb.php creates the files tab1.sql and tab2.sql with tables and other DB objects except CDR tables and makes copies of structure files, data files and index files for CDR monthly tables that have changed since the previous run. Information about the status of saved CDR tables is written to the file backupdb.cdrs.


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

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


10. APPENDIX A. METACHARACTERS, REGULAR EXPRESSIONS AND NUMBER TRANSFORMATION

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

10.2. USE OF REGULAR EXPRESSIONS IN SEARCH Regular expressions provide a powerful tool for defining information search criteria. Regular expressions used in search consist of alphanumeric characters and metacharacters the description of which follows

Metacharacters Description Character match . Any character

[] Any characters matching those in square brackets

Location ^ Beginning of character string (string head) $ End of character string (string tail)

Quantity matching ? Matches zero or one occurrence of the previous expression * Matches zero or more occurrences of the previous expression


+ Matches one or more occurrences of the previous expression {x} x occurrences of the previous expression {x,} x or more occurrences of the previous expression {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.


10.3. NUMBER TRANSFORMATION The purpose of number transformation is bringing the calling or called telephone number to the necessary format. Number translation involves the use of regular expressions. A translation expression consists of two parts a search pattern and a replacement string delimited by the symbol «/».

Use the brackets «( )» to create separate sections in a search pattern. The replacement string can include a replacement sub-string for a section. The replacement substring can be preceded by the number of the search pattern section 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# Transformation pattern:

^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 Transformation pattern:

^(.*)/0000#\1

(append prefix 0000# to the beginning of any string, i.e. before section 1)

Result: 1234567 → 0000#1234567

7654321 → 0000#7654321, etc.


One and the same goal can be achieved using different translation patterns:

translation pattern ^ 1 2 3 4 # / 0 0 0 0 # is equal 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 contain several translation patterns delimited by semicolons (;). The first pattern in the string that matches the number will be used for number translation.

To explain this let us take the following translation patterns:

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

For number 78312555555 from string ^ 7 8 3 1 2 / 0 1 # ; ^ 7 8 3 1 / 0 2 # TM will choose the first pattern and as a result prefix 01# will be added to the number (01#78312555555). At the same time, for number 78315555555 TM will choose the second pattern. As a result prefix 02# will be added to the number (02#78315555555).

Note: The use of number translation should be judicious as numerous regexp-based number translations affect the System performance, and technical prefixes are removed anyway requiring no special configuration effort.

Along with the patterns based on regular expressions you can use several additional patterns intended for translation of “empty” numbers:

the pattern src replaces the “empty” destination number with the source number;

the pattern dst replaces the “empty” source number with the destination number;

the pattern rand(n) replaces the “empty” number with a random n-digit number;

the pattern <arbitrary number> replaces the “empty” number with the number specified as a translation pattern.

Examples:

The string of patterns d s t ; r a n d ( 8 ) ; ^ / 0 0 0 0 # means “replace the “empty” source number with the destination number; in case the number remained “empty”, generate a random 8-digit number; add prefix 0000#”.

The string of patterns d s t ; 1 2 3 4 5 6 7 8 means “replace the “empty” source number with the destination number; in case the number remained “empty”, replace it with number 12345678”.


11. APPENDIX B. MVTS PRO DISCONNECT CODES

11.1. TS LOCAL DISCONNECT CODES

Code Reason 0 Unknown internal error 1 No compatible codecs 2 Signaling channel disconnect (H.323) 3 Control channel disconnect (H.323) 4 Failure to open signaling channel (H.323) 5 Failure to establish connection at the transport level (H.323) 6 H.245 control channel error 7 H.323 socket error 8 TCS/MSD procedure error (H.323) 9 Failure to receive ACK message 10 Normal call completion. BYE received 11 Error during sending CallBegin message to TM 12 TM response timeout 13 Failure to open sockets for RTP stream 14 Normal system shut-down 15 All routes failed 16 Call impossible without media proxy 17 Failure to decode signaling packet 18 Maximum call time exceeded 19 SIP gateway stopped responding 20 Error when processing INVITE without SDP, ACK received

without SDP 33 DBMS overload 34 DBMS query processing error 35 DBMS query failed 36 DBMS query forcefully aborted 37 Failure to send DBMS query to TM 38 License number of concurrent calls exceeded. 39 SIP request timeout 40 TM responded with unsupported signaling protocol 41 No routes available 42 The list of codecs received from the call originator does not

match the list configured in the DB 43 All routing options rejected due to mismatching codec capability

of the call originator 44 Signaling node crashed 45 SIP socket error 46 Time reserved for the call exceeded (displayed in the TS CLI)


47 Incompatible media proxy modes set for originator and terminator

48 Failure to resolve domain name 49 Slow Start is not supported in non-proxy operation 50 Redial timeout 51 Failure to create SIP socket 52 Failure to transform received calling number, name etc. into valid

SIP URI 53 Time reserved for the call exceeded (displayed in the TM web-

interface)

11.2. TM DISCONNECT CODES

Code Description 0 Normal call completion 100 Internal System error 101 Not used 102 Invalid format or size of received data. For example, dialed

number is too long. 104 Data caching error in DB contexts 200 Authentication error 201 Full authentication by parameters received from caller failed. 202 Failed fast authentication by authentication record ID found

during registration. 203 Origination equipment blocked (chek up the field Origination

blockings of the table Equipment) 204 Customer authentication record blocked (check up field

Restraints in the table Customer authentication data). The record could be blocked due to low balance in the customer’s account.

205 Maximum number of concurrent calls for the origination EP exceeded. (check up the fields Incoming calls and Max incoming calls in the table Equipment.

206 Maximum allowed number of concurrent calls defined in the customer authentication record exceeded (check up the fields Incoming calls and Max incoming calls in the table Customer authentication data).

207 Registration failed 208 Diasbled Customer record (check up the Enabled field in the

table Customers/Vendors)

209 Disallowed caller CPC (calling party category) for the selected rate plan (check up the table Rate plan in the object Calling party category (category of objects Configuration).

210 Disabled equipment record is (check up the field Enabled in the table Equipment).

300 Not used 400 Authorization error


401 Customer’s rate plan does not cover requested destination. 402 The requested destination is disallowed (check up the field

‘Deny’ in the table of destinations). 500 Routing error 501 No available routing options (both in DPs and ENUM registry) 600 Error occurred when processing billing data 601 Error occurred when processing billing data for the customer 602 Error occurred when processing billing data for the vendor 701 Not used 702 Not used 703 All routes failed 704 Statistics calculation error 705 Call aborted prior to Call_Begin processing completion 799 This code is automatically generated for dangling calls

terminated in the DB by a special background process after the maximum call duration is exceeded.

Documents

MVTS Pro Eng