MVTS Pro & RTU 1.5.3-60 Admin Guide

© 2010 ALOE Systems

Administrator's manual

RTU 1.5.3-60

Copyright © 2007-2010 ALOE SystemsAll rights reserved.

ALOE Systems reserves the right to change any information contained in this document without prior notice.

COPYRIGHT INFORMATIONThe information contained in this document is the property of ALOE Systems. No part of this publication may bereproduced or copied in any form or by any means - graphic, electronic or mechanical including photocopying,recording, taping, or any other information storage and retrieval system - without written consent of ALOE Systems.No third party, organization or individual, is authorized to grant such permission.

Document type:

Release date:

Administrator's manual

11.17.2010

Document status:

Document version

Released

1.5.3-60

3Contents

Page 3

Contents

1 Intoduction 9........................................................................................................................ 91.1 Document profile

........................................................................................................................ 91.2 Audience

........................................................................................................................ 91.3 Notational conventions

........................................................................................................................ 91.4 Documentation

........................................................................................................................ 91.5 Document structure

........................................................................................................................ 101.6 Names, Phone Numbers and Network Addresses

........................................................................................................................ 101.7 Terms and acronyms

2 System overview 14........................................................................................................................ 142.1 System make-up and networking arrangements

........................................................................................................................ 142.2 API for external applications

3 System configuration 15........................................................................................................................ 153.1 Security considerations

........................................................................................................................ 153.2 TS Configuration

........................................................................................................................ 163.3 System.conf syntax

........................................................................................................................ 163.4 Daemon process ‘phoenix’ and phoenix.conf configuration file

........................................................................................................................ 183.5 Configuration file system.conf

........................................................................................................................ 193.6 Individual node configuration

.......................................................................................................................................................... 19Common sections 3.6.1

.......................................................................................................................................................... 20Registration-balancer configuration 3.6.2

.......................................................................................................................................................... 22SS7 Call Agent node configuration 3.6.3

.......................................................................................................................................................... 30Scripting node configuration 3.6.4

.......................................................................................................................................................... 32Signaling node configuration 3.6.5

.......................................................................................................................................................... 33Media node configuration 3.6.6

.......................................................................................................................................................... 34Synchronization node configuration 3.6.7

.......................................................................................................................................................... 34Configuring node generic 3.6.8

........................................................................................................................ 353.7 IP zones

.......................................................................................................................................................... 36SS7 zones 3.7.1

........................................................................................................................ 373.8 Section "location"

........................................................................................................................ 383.9 Balancing groups

........................................................................................................................ 383.10 TS notification function

........................................................................................................................ 413.11 SNMP daemon configuration

........................................................................................................................ 433.12 Configuration of scripting node logging

........................................................................................................................ 443.13 Configuration of DB interoperation

........................................................................................................................ 453.14 Traffic switch administration console

........................................................................................................................ 473.15 Troubleshooting

4Administrator's manual

Page 4

.......................................................................................................................................................... 47File phoenix.log 3.15.1

.......................................................................................................................................................... 48Files rtinfo 3.15.2

.......................................................................................................................................................... 48Scripting node logs 3.15.3

........................................................................................................................ 483.16 mvts3g-logextarctor utility

4 RTU Web interface 49........................................................................................................................ 494.1 What you see on the screen

........................................................................................................................ 494.2 Standard procedures

.......................................................................................................................................................... 49Accessing TM’s GUI 4.2.1

.......................................................................................................................................................... 50Pop-up menu 4.2.2

.......................................................................................................................................................... 52Use of filters 4.2.3

.......................................................................................................................................................... 58Sorting table data 4.2.4

.......................................................................................................................................................... 58Re-arranging table columns 4.2.5

.......................................................................................................................................................... 59Table autorefresh 4.2.6

.......................................................................................................................................................... 59Editing multiple table records 4.2.7

.......................................................................................................................................................... 60Data export 4.2.8

.......................................................................................................................................................... 61Component version view 4.2.9

5 Operating TM 63........................................................................................................................ 635.1 Administration

.......................................................................................................................................................... 63System users 5.1.1

.......................................................................................................................................................... 64Web authentication 5.1.2

.......................................................................................................................................................... 65Roles 5.1.3

.......................................................................................................................................................... 65Role settings 5.1.4

.......................................................................................................................................................... 66System user creation wizard 5.1.5

.......................................................................................................................................................... 68Web realms 5.1.6

........................................................................................................................ 695.2 Equipment

.......................................................................................................................................................... 69Equipment 5.2.1

.......................................................................................................................................................... 84Default gateway endpoints 5.2.2

.......................................................................................................................................................... 85Zones 5.2.3

.......................................................................................................................................................... 86Codecs 5.2.4

.......................................................................................................................................................... 88Codec groups 5.2.5

.......................................................................................................................................................... 88Codec group setup 5.2.6

.......................................................................................................................................................... 90CPS limitation 5.2.7

.......................................................................................................................................................... 91Balancing groups 5.2.8

........................................................................................................................ 915.3 Termination

.......................................................................................................................................................... 91Pre-routing translations 5.3.1

.......................................................................................................................................................... 94Dial peers 5.3.2

.......................................................................................................................................................... 99Routing policies 5.3.3

.......................................................................................................................................................... 101Tree of Dial Peers (DPs) 5.3.4

........................................................................................................................ 1035.4 Debugging

.......................................................................................................................................................... 103Call simulation 5.4.1

.......................................................................................................................................................... 105Debug calls 5.4.2

5Contents

Page 5

.......................................................................................................................................................... 108Debug registrations 5.4.3

........................................................................................................................ 1085.5 Traffic Switch

.......................................................................................................................................................... 109TS CLASS 4 conferences 5.5.1

.......................................................................................................................................................... 109TM CLASS 4 calls 5.5.2

.......................................................................................................................................................... 110TS CLASS 5 legs 5.5.3

.......................................................................................................................................................... 111TS incoming registrations 5.5.4

.......................................................................................................................................................... 111TM incoming registrations 5.5.5

.......................................................................................................................................................... 112Nodes 5.5.6

.......................................................................................................................................................... 113Active nodes 5.5.7

.......................................................................................................................................................... 113SS7 calls 5.5.8

.......................................................................................................................................................... 114ISUP circuits 5.5.9

.......................................................................................................................................................... 115MGCP endpoints 5.5.10

.......................................................................................................................................................... 115M3UA associations 5.5.11

.......................................................................................................................................................... 116Reserved circuit groups 5.5.12

........................................................................................................................ 1165.6 CDRs

.......................................................................................................................................................... 120CDRs scheduled export 5.6.1

.......................................................................................................................................................... 130Export interval 5.6.2

.......................................................................................................................................................... 131CDR post-processing 5.6.3

........................................................................................................................ 1315.7 Statistics

.......................................................................................................................................................... 131Reports 5.7.1

.......................................................................................................................................................... 135Charts 5.7.2

........................................................................................................................ 1385.8 Global settings

.......................................................................................................................................................... 138System global settings 5.8.1

.......................................................................................................................................................... 140Web settings 5.8.2

.......................................................................................................................................................... 142Disconnect codes 5.8.3

.......................................................................................................................................................... 143ENUM-servers 5.8.4

.......................................................................................................................................................... 144DNS servers 5.8.5

.......................................................................................................................................................... 144Areas 5.8.6

.......................................................................................................................................................... 145Area specifics 5.8.7

.......................................................................................................................................................... 145Calling party’s categories 5.8.8

.......................................................................................................................................................... 146CPC translations 5.8.9

.......................................................................................................................................................... 146Capacity groups 5.8.10

.......................................................................................................................................................... 148Number capacity groups 5.8.11

.......................................................................................................................................................... 148Models codecs 5.8.12

.......................................................................................................................................................... 149Model RADIUS attributes 5.8.13

.......................................................................................................................................................... 150CDR tables 5.8.14

.......................................................................................................................................................... 150Custom views 5.8.15

........................................................................................................................ 1515.9 Logs

.......................................................................................................................................................... 152Web authentication history 5.9.1

.......................................................................................................................................................... 152Web activity log 5.9.2

........................................................................................................................ 1535.10 Import

........................................................................................................................ 1575.11 RADIUS settings


Page 6

.......................................................................................................................................................... 157RADIUS global settings 5.11.1

.......................................................................................................................................................... 158RADIUS servers 5.11.2

.......................................................................................................................................................... 161RADIUS attributes 5.11.3

.......................................................................................................................................................... 166RADIUS accounting packets 5.11.4

.......................................................................................................................................................... 167RADIUS accounting profiles 5.11.5

.......................................................................................................................................................... 170An example of RADIUS accounting configuration 5.11.6

..................................................................................................................................................................... 170RADIUS server declaration5.11.6.1

..................................................................................................................................................................... 171Using predefined or custom profiles5.11.6.2

..................................................................................................................................................................... 171RADIUS attributes configuration5.11.6.3

..................................................................................................................................................................... 172RADIUS packet configuration5.11.6.4

..................................................................................................................................................................... 172RADIUS profile configuration5.11.6.5

6 RTU Redundancy 174........................................................................................................................ 1746.1 Continuous services and correct entry of CDRs

........................................................................................................................ 1746.2 Two-server redundancy configuration

........................................................................................................................ 1756.3 Four-server redundancy configuration

........................................................................................................................ 1766.4 Control links interval settings

.......................................................................................................................................................... 177Media Node 6.4.1

.......................................................................................................................................................... 177Signaling node 6.4.2

.......................................................................................................................................................... 178Scripting node 6.4.3

.......................................................................................................................................................... 178Balancer node 6.4.4

.......................................................................................................................................................... 178SS7 Call Agent node 6.4.5

.......................................................................................................................................................... 179Synchro node 6.4.6

........................................................................................................................ 1796.5 License Management node redundancy

........................................................................................................................ 1806.6 DB and WEB interface server redundnacy

........................................................................................................................ 1806.7 Case study: two server System redundancy

.......................................................................................................................................................... 181Node distribution 6.7.1

.......................................................................................................................................................... 181Configuration files 6.7.2

..................................................................................................................................................................... 181Primary server configuration6.7.2.1

......................................................................................................................................... 181Configuration f ile phoenix.conf6.7.2.1.1

......................................................................................................................................... 182File system-1.conf6.7.2.1.2

......................................................................................................................................... 182Configuration f ile system-1.balancer.conf6.7.2.1.3

......................................................................................................................................... 184Configuration f ile system-1.signaling.conf6.7.2.1.4

......................................................................................................................................... 185Configuration f ile system-1.scripting.conf6.7.2.1.5

......................................................................................................................................... 186Configuration f ile system-1.media.conf6.7.2.1.6

......................................................................................................................................... 187Configuration f ile system-1.syncro.conf6.7.2.1.7

......................................................................................................................................... 188Configuration f ile system-1.zone.conf6.7.2.1.8

..................................................................................................................................................................... 188Standby server configuration6.7.2.2

......................................................................................................................................... 188Configuration f ile phoenix.config6.7.2.2.1

........................................................................................................................ 1886.8 Redundancy using Linux Heartbeat

........................................................................................................................ 1906.9 DB backup and recovery

.......................................................................................................................................................... 190DB specifics affecting backup policy 6.9.1

.......................................................................................................................................................... 190Backup tools and utilities 6.9.2

7Contents

Page 7

.......................................................................................................................................................... 191Configuring SSH public key authentication 6.9.3

.......................................................................................................................................................... 191Configuring DB backup 6.9.4

.......................................................................................................................................................... 192Launching backup 6.9.5

.......................................................................................................................................................... 192Unattended backup arrangements 6.9.6

.......................................................................................................................................................... 192DB recovery procedure 6.9.7

........................................................................................................................ 1936.10 DB Replication

.......................................................................................................................................................... 193Replication types 6.10.1

.......................................................................................................................................................... 193Replication configuration 6.10.2

7 Appendix A. Metacharacters, regular expressions andnumber transformation 196

........................................................................................................................ 1967.1 Use of metacharacters in search

........................................................................................................................ 1967.2 Use of regular expressions in search

........................................................................................................................ 1977.3 Number transformation

........................................................................................................................ 1997.4 Tips and tricks for regular expressions

8 Appendix B. Codec list generation in RTU 200........................................................................................................................ 2008.1 Codec matching rules

........................................................................................................................ 2028.2 Proxy policies

9 Appendix C. Default gateways 204

10 Appendix D. SS7 Call Agent node limitations 205

11 Appendix E. RTU – RADIUS interaction 207........................................................................................................................ 20711.1 Registering endpoint authorization

........................................................................................................................ 20811.2 Pre-routing call authorization

.......................................................................................................................................................... 212Accounting Start record 11.2.1

.......................................................................................................................................................... 215Accounting Stop record 11.2.2

........................................................................................................................ 21811.3 AccessRequest structure for RADIUS-aided routing

.......................................................................................................................................................... 221Field XPGK_XROUTING_ROUTING detailed 11.3.1

........................................................................................................................ 22111.4 Authentication of registering devices on a RADIUS-server

.......................................................................................................................................................... 222H.323 ID-based authentication (standard RADIUS authentication) 11.4.1

.......................................................................................................................................................... 222MD5 Authentication 11.4.2

.......................................................................................................................................................... 223CHAP Authentication 11.4.3

.......................................................................................................................................................... 223Digest authentication 11.4.4

........................................................................................................................ 22411.5 Call disconnect upon Packet of Disconnect arrival

12 Appendix F. Removing CDRs from the DB 226

13 Appendix G. RTU utilities 227........................................................................................................................ 22713.1 The mvtspro-checker utility

........................................................................................................................ 22813.2 The mvtspro-cdr-restorer utility

........................................................................................................................ 22813.3 The mvtspro-acc-restorer utility

........................................................................................................................ 22913.4 The Disk Space Monitor utility


Page 8

14 Appendix H. Balancing SIP and H.323 calls 231........................................................................................................................ 23114.1 H.323

........................................................................................................................ 23114.2 SIP

15 Appendix I. NAT router traversal 232

16 Appendix J. Managing endpoints in RTU 233

17 Appendix K. External routing over SIP/H.323 234........................................................................................................................ 23417.1 H.323

........................................................................................................................ 23417.2 SIP

18 Appendix L. Confiiguration of IPSP 235

Intoduction

Page 9

Intoduction1

Document profile1.1

This document provides a description of the RTU software, a carrier-grade VoIP switch for efficientpolicy routing and management of VoIP traffic.

Audience1.2

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

Notational conventions1.3

The conventions used in this document are described in the table below.

Conventions

Example Convention

Text of 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 RTU GUI

Documentation1.4

The complete set of documents for RTU comprises the following documents.

List of documents

Ref. No. Document title

[1] RTU. Administrator’s manual. (this document)

[2] RTU Class 5. Administrator’s manual.

[3] RTU Class 5. User’s manual.

Document structure1.5

This document comprises the following sections:

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

Intoduction

Page 10

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

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

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

Section 5 RTU Web interface describes the web interface of the System.

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

Section 7 RTU Redundancy contains information about the ways to ensure failsafe operation of theSystem.

Names, Phone Numbers and Network Addresses1.6

All IP addresses, user logins and phone numbers used for the purposes of the present document arefictitious and any resemblance or similarity to real-life objects and/or individuals is purely accidental.

Terms and acronyms1.7

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

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

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

ASR Answer Seizure Ratio. ASR is one of the operational parameters registered inRTU, allowing the evaluation of dial peer performance. In RTU ASR iscalculated in two ways: using the common method (see ASR (standard) andusing the intrinsic RTU method (see ASR (RTU)).

ASR (RTU) ASR calculated by the RTU intrinsic method. RTU ASR (answer seizure ratio) iscalculated as:

ASR = successful calls/total calls * 100

where a successful call is either a non-zero duration call or a call with asuccessful disconnect reason code.

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

CHAP Challenge Handshake Authentication Protocol.

CPC Calling Party Category

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

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

DB Database

DBMS DataBase Management System

Intoduction

Page 11

DNS Domain Name System

DP Dial peer. In terms of RTU a dial peer is a potential destination for the RTU’segress traffic characterized by the equipment (gateways) that receives trafficfrom RTU, number transformation rules and some other data important for callrouting

DTMF Dual Tone Multi-Frequency

DST Destination

EMA Exponential Moving Average

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

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

GUI Graphical User Interface

GW Gateway

HTTPS HyperText Transfer Protocol, Secure

ITSP Internet Telephony Service Provider

LAN Local Area Network

MVTS Multiprotocol VoIP Tandem Softswitch

NAT Network Address Translation

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

NGN Next-Generation Networks

NIC Network-Interface Card

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

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

RTU registers PDD as an interval between the receipt of the CONNECT packetfrom the call originator and the receipt of the ALERT, CONNECT orProgressIndicator with value 8 (ProgressInbandInformationAvailable) packetsfrom the terminator. The calculation of PDD is EMA-based, measured inmilliseconds;

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

Intoduction

Page 12

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

QoS Quality of Service. RTU calculates QoS as a ratio of packets lost to totalpackets transferred, i.e. the smaller is the calculated QoS value, the better isQoS.

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

RAS Registration, Admission, Status. Protocol for interoperation with remotedevices.

RAS user Registering device.

RBT Ring-Back Tone

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

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

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

SIP Session Initiation Protocol.

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

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

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

TM Traffic Manager

TNS Target NameSpace

TS Traffic Switch

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

VoIP Voice over Internet Protocol (IP)

Intoduction

Page 13

WAN Wide Area Network

System overview

Page 14

System overview2

RTU is a system for comprehensive management of IP telephony traffic flowing across the ITSP’snetwork. RTU is designed to efficiently handle big amounts of simultaneous call sessions throughapplication of adaptive call authorization and routing policies.

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

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

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

The ease of deployment and operation are additional merits of RTU.

System make-up and networking arrangements2.1

The information on the RTU make-up is included into the Functional specification for the system.

API for external applications2.2

The API is an interface that enables gathering data about the System settings and allows the externalapplications to dispatch requests to the System over various protocols.

For further information about the API see the “RTU. API for external applications ENG” document.

System configuration

Page 15

System configuration3

Security considerations3.1

To protect the System from unauthorized access it is advisable to block access to the System from allIP addresses, but for those required for System functioning, with the help of the firewall.

Specifically it is advisable to:

Restrict access to control link sockets of all TS nodes from all addresses, but for those that arerequired for the nodes to interoperate with each other.

Restrict access to the balancer node from the external network from all addresses, except thosefrom which the System receives and where the System sends traffic.

Restrict availability of the MySQL TCP port 3306 from the external net. The access to the portis required only to the scripting node/logic Class 5, web interface.

Allow access to the TCP port 443 (web interface) only from the required IPs only (for ALOESystems technical support and the System owner).

Allow access to the command line node over the telnet protocol only from the required IPs (forALOE Systems technical support and the System owner).

Allow access over ssh to the System servers only from the required IPs (for ALOE Systemstechnical support and the System owner).

Change the default web password after the first access to the web interface.

TS Configuration3.2

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

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

The configuration file system.conf is located on the server with the сommandline node andconfigures the connectivity parameters of the TS nodes.

Prior to configuring the system insert the USB license dongle supplied with the installationpackage into the USB port of the license management node machine.

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

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

Edit the configuration file system.conf and apply the settings with the help of the

command line interface (CLI).

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

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

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

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

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


Page 16

System.conf syntax3.3

The configuration file system.conf is a plain text file with configuration data arranged in the C-style layout.

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

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

Like in the C and C++ programming languages two types of comments are allowed: one-linecomments, starting anywhere in a line with '//' characters and extending to the end of the line,and multi-line comments starting with /* spanning several lines and ending at the next */.

It is possible to include text from external files by means of the include keyword.

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

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 configuresignaling nodes */

Include anexternalfile

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

Daemon process ‘phoenix’ and phoenix.conf configuration file3.4

“phoenix” is a daemon that starts up the TS nodes installed on the server and lets them know the IP-address and port of the LMN. Another job of the “phoenix” daemon is to restart crashed nodes.

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

The directory /etc/mvts3g comprises two additional files:

phoenix.conf.sample.local – a template for the phoenix.conf configuration filefor servers on which the license management node (LMN) is installed.;

phoenix.conf.sample.remote – a template for the phoenix.conf configuration fileused on servers that do not have a license management node (LMN) installed.

The file phoenix.conf is a collection of commands that start functional components of the System


Page 17

at its start.

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

Excerpt from the file phoenix.conf.sample.local

The commands comprised in the file have the following format:

<command> [<parameter1>[=<value1>][, <parameter2>[=<value2>][, …]]]

The parameters in square brackets are optional.

The file phoenix.conf may comprise the following commands:

management primary=<IP:port of main LMN > [backup=<IP:port offailover LMN>]

This command must precede all ‘load’ commands. It defines the IP address of the LMN. If theLMN runs on the same server, it will open a connection socket at the specified address andport. Other nodes will expect to find the LMN at the specified address.

The primary and failover LMNs cannot run on the same server, that is IP addresses of the primaryand failover LMNs should be different.

For further information on LMN redundancy, see section License management noderedundancy.

phoenix [address=<ip:port>] [sodir=<path to directory with .somodules>] [timeout=<period>] [count=<how many>] [sleep=<pausetime>] [wdtimeout=<no answer period>] [wdsleep=<wait-for-response pause>]

The command phoenix configures the behavior of the phoenix daemon and must precede allthe load commands.

address=<ip:port> - IP address and port of the interface used to control the phoenix.Process.

sodir=<path to .so directory > – determines the path to the directory with .somodule files.

The parameters [timeout=<period>] [count=<how many>] [sleep=<pausetime>] determine the restart behavior of crashed nodes and have the following meaning:should a node crash [count=<so many>] times within the [timeout=<period>], wait for the [sleep=<pause time>] before restarting the crashed node.

The parameter [wdtimeout=<no answer period>] specifies the is-alive responsetime for nodes. The node is considered crashed, if it fails to respond to challenges from thephoenix daemon within the wdtimeout time.

The parameter wdsleep determines the length of the pause that the phoenix daemon makesafter sending a SIGSEGV to the inactive node. If after the wdsleep timeout the faulty node stillis not stopped/ the phoenix sends it a SIGKILL signal.

statestore [db=<path to DB>] [trafficlog=<path to traffic.log>]

Determines the parameters of the statestore process, which should be launched prior to allother processes. The parameter db is used to specify a path to the DB which retains theinformation necessary for nodes. The parameter trafficlog sets the path to the traffic.log log file. The statestore command must be executed prior to all load commands. If allparameters are set to their default values the command may be omitted altogether.

load type=<node type> name=<node name> [file=<path>] [<params>]


Page 18

The command “load” is the instruction to load a node of the type type and the name name. Thetype and name command arguments are required. The required parameters of the command mayvary with the type of node.

The optional parameter file determines the path to the .so file of the loaded node. In theabsence of the parameter file, the path is as specified in the parameter sodir of the commandphoenix.

To start the management node as a primary one, add mode=main argument to the loadtype=management command. To start the management node as a backup one, addmode=backup.

The parameter lic= serves to specify the file path to the directory containing the license filefor the RTU class 5 component.

load type=management name=management-1 lic=/etc/mvts3g/licenses

Use the appropriate template (phoenix.conf.sample.local or phoenix.conf.sample.remote).

Edit the template in any plain-text editor and copy the edited file to the file phoenix.conf.

For the made changes to take effect, run the script /etc/init.d/mvts3g-server-pro withthe argument start:

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

To restart the currently running server, use the argument restart.

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

Use the argument stop to stop the server.

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

Configuration file system.conf3.5

The configuration file /etc/mvts3g/system.conf is what you use to configure a variety of TSnetworking settings.

Figure below presents an excerpt from the configuration file system.conf.

media{ rbtfilesdir "/etc/mvts3g";

media "media-1-1" { portrange "10000-14999"; };



media "media-2-2" { portrange "15000-29999"; };};

Configuration file system.conf


Page 19

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

The figure 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 14999and 15000 through 29999 respectively. The nodes “media-2-1” and “media-2-2” are configured to useports in the range 10000 through 14999 and 15000 through 29999 respectively.

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

A parameter with the same name defined within a subsection overrides the general setting configuredoutside the subsection and becomes a local setting valid for this subsection only.

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

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

To apply the changes done in system.conf, connect to the command-line node (telnet [address]

[port], specified in the section commandline of phoenix.conf) and carry out the configcommand supplying the full path to system.conf as the command argument:

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

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

Individual node configuration3.6

Configuration of nodes of the same type can be done in a common file. The general configuration fileformat is shown in the figure below:

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

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

Common sections3.6.1

The configuration of any node, except the media node, includes at least two sections:

an optional section ‘common’ and

the required section ‘controllink’.

common{ loglevel "0"; ...};


Page 20

controllink{ address { "192.168.132.195"; }; port "7050";};

The section ‘common’ is for settings that are common for all nodes of the type. The followingparameters are available:

loglevel – controls the packet logging level with two possible values 0 (logging is off) andany non-zero integer (logging enabled which involves entering all SIP/H/323 signaling packetsand message packets exchanged by nodes in the log).

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

loglevel_timeout “x”

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

link_send_timeout – interval between sending activity packets from a module to othermodulea along the control link, in ms.

link_recv_timeout – timeout for receiving any packet from a remote packet along thecontrol link, after which the TCP connection between modules is considered severed, in ms.

link_restore_timeout – timeout that starts after TCP connection failure is detected.After the timeout the control link is considered completely severed, in ms.

link_reconnect_interval – interval between attempts to restore the TCP connectionwithin the link_restore_timeout period, in ms.

link_connect_interval – interval between attempts to establish a TCP connectioninitially or after the control link is completely severed, in ms.

The link_send_timeout value must be less than link_recv_timeout, otherwise TCPconnections in control links will constantly fail.

To define the abovementioned intervals for all nodes (but for statestore and commandlinenodes) create a global common section in the configuration file. The contents of this sectionwill automatically apply to all nodes.

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

You cannot use the addresses “0.0.0.0” and “127.0.0.1” in the section ‘controllink’ to avoidtroubles when configuring the TS. You should specify one real address.

Registration-balancer configuration3.6.2

A configuration example of an arbitrary registration-balancer node:

balancer{ balancer "[node name]" { common ... controllink ...

ras {


Page 21

address { "0.0.0.0"; }; port "1719"; gkname "MVTS3G"; allow_md5 "yes"; allow_chap "yes"; allow_plain "yes"; };

sip { address { "0.0.0.0"; }; port "5060"; proxying_balancing "yes"; external_autorization "no"; };

h323 { address { "0.0.0.0"; }; port "1720"; }; };};

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

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

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

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

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

Section sip governs the parameters, pertaining to SIP calls:

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

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

o external_authorization – is a parameter that controls the involvement of thescripting node or CLASS 5 component in remote authentication. Set the parameter to ‘no’ ordo not specify it for the balancer node belonging to CLASS 4 balancing group (see sectionBalancing groups). The default value is “no”.

o realm – the value of the “realm” parameter in SIP messages. Available values (casesensitive):

"HOSTNAME" – the default value. In the 401 response to the registration request the“realm” field will comprise the host name.

"HOSTADDR" – in the 401 response the “realm” field will comprise the IP address of thehost. If the System has opened SIP sockets on several network interfaces, the System willselect the actual address, on which the REGISTER request was received.

Any other string (embraced in quotes) will be send unchanged (but without quotes) in the


Page 22

“realm” field.

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

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

SS7 Call Agent node configuration3.6.3

A configuration example of an arbitrary SS7 Call Agent node:

ss7{ ss7 "[node name]" { common ... controllink ...

callctr { ss7zone "[SS7 zone name]" { cid "0" }; };

isup { ... };

m3ua { ... };

mgcp { ... }; };};

The parameters of the callctr section:

ss7sone – name of the SS7 zone. In the callctr section define the number of ss7zonesections, equal to the number SS7 zones, with which the System interoperates. See also SS7zones.

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

Parameters of the ss7zone section:

cid – the identifier of the media circuit group (defined in the circuit_group section) in one orseveral E1 trunks, belonging to this SS7 zone. Only one media circuit group may belong to asingle SS7 zone.

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

isup

{

snode "[snode id]"

{

...


Page 23

connection "[connection id]"

{

...

timers

{

...

};

span "[span id]"

{

...

ts_cic_mapping

{

...

};

};

};

};

circuit_group

{

...

circuit_group_elem

{

...

};

};

};

General parameters:

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

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

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

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

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

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

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

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

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

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

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


Page 24

behav_mask – flags used for connection configuration. Set by a decimal value:

o 0x0001 – initially block circuits using hardware oriented blocking type. Otherwisemaintenance oriented blocking type is used. See the doInitBlock parameter.

o 0x0002 – reset circuits whenever a remote SS7 switch for this ISUP connection becomesavailable.

o 0x0004 – respond with an UCIC message upon receipt of a message on unequipped circuits.

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

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

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

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

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

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

T16 – timer for acknowledgement of the emitted RSC message.

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

T18 - timer for acknowledgement of the emitted CGB message.

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

T20 - timer for acknowledgement of the emitted CGU message.

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

T22 - timer for acknowledgement of the emitted GRS message.

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

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

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

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

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

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

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

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

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

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

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


Page 25

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

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

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

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

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

To configure the M3UA protocol the m3ua section is used:

m3ua{ ...

AS "[AS identifier]" { ... };

ASP "[ASP identifier]" { ... };

LIPSP "[LIPSP identifier]" { ... };

RIPSP "[RIPSP identifier]"

SG "[SG identifier]"

SGP "[SGP identifier]" { ... };

Association "[Association identifier]" { ... };

LocalEndpoint "[идентификатор Endpoint]" { ... };

RemoteEndpoint "[идентификатор Endpoint]" { ... };

NetworkAppearance "[NetworkAppearence identifier]"


Page 26

{ ... };

RoutingContext "[RoutingContext identifier]" { ... };

RoutingKey "[identifier RoutingKey]" { ... };};

General parameters:

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

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

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

assocGracefulClose – the “true” value means that to close the SCTP association theShutdown Chuck is sent to the signaling gateway, the “false” value means sending the AbortChunk. The default value – «false».

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

Parameters of the AS section describe an Application Server, a logical entity which maps to oneRouting Key. A Routing Key is a filter, made up of SS7 parameters, which determine the belonging ofthe signaling traffic to a certain AS. The Application Server hosts one or several Application ServerProcesses (ASP), which dispatch signaling traffic from one network into the other. One AS maycorrespond to several ASPs and vice versa.

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

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

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

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

m3asp_id – the value of the “ASP Identifier” parameter. Range of values – 1-1000.

Parameters of LIPSP section describe the local IP signaling point (IP Signaling Point, IPSP). Thesesection is used when the node works in IPSP mode only.

Local IPSP identifier is defined in the section header. Range of valid values – 1-65534.

m3asp_id – the value of the “ASP Identifier” parameter, used in ASPUP message. Rangeof values – 1-100.

The RIPSP parameter describes a remote IPSP. The parameter defines a remote IPSP identifier. Therange of valid values – 1-65534. These section is used when the node works in IPSP mode only.

The SG parameter describes the Signaling Gateway (SG), which resides on the border of IP and SS7networks and performs signaling traffic transfer from one network into the other. The parameterdefines a SG identifier. The range of valid values – from 65537 to 131070.

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


Page 27

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

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

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

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

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

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

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

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

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

role - optional parameter that defines the party to establish the association. If the value is"Client", ASP/LIPSP establish the association,if the value is "Server" ASP/LIPSP waitsfor incoming association. The default value is "Client".

LocalEndpoint "[LocalEndpoint identifier]"{ ...

Addresses { "192.168.131.100"; };};

The parameters of the LocalEndpoint section describe a local SCTP endpoint:

Identifier of SCTP endpoint is specified in the section header.

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

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

RemoteEndpoint "[RemoteEndpoint identifier]"{ ...

Addresses { "192.168.131.100"; };};

The parameters of the RemoteEndpoint section describe a remote SCTP endpoint:

Identifier of SCTP endpoint is specified in the section header.

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

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

NetworkAppearance "[NetworkAppearence identifier]"{ ...


Page 28

SG_Ids { "65537"; };

AS_Ids { "1"; };

};

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

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

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

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

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

RoutingContext "[RoutingContext identifier]"{ ...

AS_Ids { "1"; };

Assoc_Ids { "1"; };

};

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

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

value – the value of the SS7 Routing Context identifier. Valid values – 0 to 4294967295. Theparameter has two special (case-sensitive) values:

o None - Routing Context will not be included into DATA messages. it is possible to use this value ifthe association, defined in this Routing Context, will use the AS, defined in this Routing Context,only. In all other cases such configuration is invalid.

o Dynamic - the Routing Context value will obtained from the gateway using the Routing Keydynamic registration procedure. In this case it is not necessary to specify the Routing Contextvalue. If the gateway does not support the procedure, the AS will not be activated.

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

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

direction - optional parameter that defines the local process type. If the value is "Outgoing", the process is ASP; "Incoming" - SGP; "Both" - IPSP.

RoutingKey "[RoutingKey identifier]"


Page 29

{

...

RoutingKeyEntry

{

...

OPCs

{

"300";

};

...

};

};

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

Identifier of the filter is specified in the section header;

In the section RoutingKeyEntry define the filter parameters;

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

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

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

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

To configure the MGCP protocol the mgcp section is used:

mgcp{ mgcp_conf_inst "[section id]" { localAddr "192.168.129.127"; localPort "2727"; tHist "20000"; tRetransInit "200"; tRetransLong "400"; tRetransMax "4000"; maxRtxNum "200";

mgcp_conf_mgw "[section id]" { address "192.168.131.100"; port "2427"; outTidMin "2000"; outTidMax "99999999"; pattern "S0/DS1-${trunk}/${timeslot}@mediant3.aloenetworks.ru";

mgcp_conf_trunk "0" };};

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

Section identifier is specified in the section header;

localAddr – IP address of the SS7 Call Agent node, which will be used to receive and sendMGCP messages in the IP network.


Page 30

localPort – IP port of the SS7 Call Agent node, which will be used to receive and sendMGCP messages in the IP network. By default – 2727.

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

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

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

tRetransMax – the maximum period of retransmission in seconds. By default – 4000. Validvalues – 1000 – 10000.

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

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

Media gateway identifier is specified in the section header.

address – IP address of the media gateway.

port – IP port of the gateway.

outTidMin – the lower border of the identifier value range that can be assigned to MGCPtransactions, sent by the SS7 Call Agent node to the media gateway. By default – 2000. Validvalues – 1 – 999999999.

outTidMax – the upper border of the identifier value range that can be assigned to MGCPtransactions, sent by the SS7 Call Agent node to the media gateway. By default – 999999999.Valid values – 1 – 999999999.

Identifier ranges for incoming and outgoing MGCP transactions (as regards to the System) shouldnot overlap.

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

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

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

echoCanceller – flag, controlling the “Echo control device” parameter in the outgoingIAM, ACM, CON, CPG messages. Valid values – “true” or “false”, by default «true». The valueof this parameter should be the same as the value of the analogous parameter on the mediagateway.

Presently the functionality of the SS7 Call Agent node is limited. For further information seeAppendix D.

Scripting node configuration3.6.4

Scripting node is configured in the same way as other functional nodes of the System. An example ofa scripting node configuration is given below:

scripting{ scripting "scripting-1" {


Page 31

controllink { address { "0.0.0.0"; }; port "7710"; }; loader_path "voip2.loader"; environment { dbms_type_master "MySQL"; dbms_name_master "localhost@rtu"; dbms_user_master "rtu"; dbms_pswd_master "rtu";

dbms_type_slave "MySQL"; dbms_name_slave "localhost@rtu"; dbms_user_slave "rtu"; dbms_pswd_slave "rtu"; }; };};

Parameters of the scripting section:

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

Parameters of the environment subsection:

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

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

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

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

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

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

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

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

cdr_backup_template – name template for temporary CDR files.

reg_backup_template – name template for temporary registration files.

reg_backup_path – path to the directory for temporary registration files.

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


Page 32

dbms_type_master "MySQL";

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

dbms_name_master "rtu2@rtu";

dbms_user_master — name of main database user account.

dbms_user_master "rtu";

dbms_pswd_master — main database user password.

dbms_pswd_master "rtu";

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

dbms_type_slave "MySQL";

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

dbms_name_slave "rtu2@rtu";

dbms_user_slave — name of failover database user account.

dbms_user_slave "rtu";

dbms_pswd_slave — failover database user password.

dbms_pswd_slave "rtu";

dbms_reconnect_timeout — interval between attempts to reconnect to the DB, bydefault – 1 sec.

dbms_reconnect_timeout "1";

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

dbms_reconnect_tries "3";

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

dbms_scan_period "10";

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

dbms_time_wait_for_connect "20";

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

trace_file "logic";

radius_local_socket_address — local IP address/port which the System uses tointeroperate with the RADIUS servers. By default – 0.0.0.0:0.

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

The parameters radius_local_socket_address and radius_nas_ip_addr aremandatory for billing configuration.

Signaling node configuration3.6.5

A configuration example for an arbitrary signaling node:

signaling{ signaling "signaling-1" - модуль для транзитной части { cdr_recovery "no";


Page 33

h323 { address { "192.168.131.13"; }; port "1721"; };

sip { address { "192.168.131.13"; }; port "5061"; }; };};

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

The section sip comprises address and port, used by this signaling node to handle SIP traffic

cdr_recovery - enables/disables the CDR recovery procedure. Valid values - "yes" and"no". By default the value is "no". This parameter is not used for RTU.

To ensure the internal protocol exchange of traffic between the transit and the class-5components of the System the subsection address of the section sip must comprise not onlythe IP address of the signaling node, but also the IP of the scripting node or of the class 5component depending on what balancing group the signaling node belongs to (see sectionBalancing groups).

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

Media node configuration3.6.6

A configuration example for an arbitrary media node:

media{ media "media-1" { controllink { address { "192.168.131.13"; }; port "7760"; }; portrange "15001-20000"; rbtfilesdir "[full path]"; };};


Page 34

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

rbtfilesdir — the path to the directory with RBT emulation files and messages playedafter call clearing.

g729mixing - a flag that enables/disables mixing of G.729 media streams. Valid values are"yes" and "no". The default value is "no".

In addition the configuration of every media node must include a section controllink.

Audio files must meet the following requirements: WAV format, mono, 8 kHz and PCMA/PCMU/PCMcodec.

Synchronization node configuration3.6.7

Presently the configuration of a synchronization node does not have any specific parameters andincludes common sections only.

An example of an arbitrary synchronization node configuration follows:

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

Configuring node generic3.6.8

The node “generic” serves to maintain a link with the RTU class 5 component. Currently the node hasno specific configuration parameters. An example illustrating the configuration of the node “generic”is presented below.

generic{ generic "Centrex" { controllink { ... }; port "9966"; }; generic "LicenseInterlayerServer" { controllink { ... }; port "9977"; };};


Page 35

IP zones3.7

One of the essential tasks when configuring the TS is defining IP zones. An IP zone is a collection ofconnected networks characterized by 1) configured routing between the IP addresses of membernetworks that comprise the zone and 2) the absence of traffic limiting devices (firewalls, NAT routersetc.) within the zone.

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

Example of IP zoning

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

Suppose, IP addresses belonging to networks 212.92.148.0/24 and 195.98.135.0/24 are used to accessthe Internet. In this case you may wish to configure a networking zone named “internet” bymentioning the networks that make up the zone. Networking zones are defined both in configurationof the TM and TS. It is important that both the TM and TS zone definitions are identical.

The configuration of any TS includes a preconfigured zone ‘Local’ that comprises addresses127.0.0.1 and [::1]. It makes sense to reconfigure the zone ‘Local’ only when you wish to expandthe list of local addresses or explicitly disallow local addresses altogether.

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

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

1. CIDR notation, i.e. xx.xx.xx.xx/yy, where xx.xx.xx.xx stands for the network address, and yydenotes 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 networkmask.

Here is an example of correctly configured IP zones:


Page 36

Configuring zones in the file system.conf

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

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

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

SS7 zones3.7.1

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

SS7 zones

While transferring data into the IP network and out of it different IP zones may be used, so it isrequired for the System to establish correspondences between the IP and SS7 zones. In the section,describing an IP zone, use the alias parameter to specify the SS7 network, associated with this IP zone.One IP zone may have associations with several SS7 zones.

zone{ zone "voip"


Page 37

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

Also see section Zones.

Section "location"3.8

The section “location” is designed to simplify the provisioning of “hosted softswitch” service anddeployment of geographically distributed Systems featuring geographic redundancy.

The section “location” is a listing of TS nodes and IP zones, which by this means associates the listednodes with a certain locality.

Nodes, declared in different sections “location” cannot interoperate with each other.

If there is no section “location” in the configuration file, it means that there exists a common territorialassociation and all the TS nodes belong to an implied global section “location”.

Configuration rules for the section “location” are as follows:

1. TS node names must be unique.

2. Every TS node can belong to one section “location” only.

3. If a node is not mentioned in none of the existing sections “location”, it is regarded asbelonging to all sections “location” or to the implied global section “location”.

4. Each IP zone may be mentioned in one section “location” only.

5. If the section “location” includes no IP zone, all the nodes listed in the section are consideredto have access to all configured IP zones.

6. When configuring a media node declared, by way of example, in the section “location A”, it isnot allowed to enter the name of the signaling node that neither belongs to the section“location A” nor to the implied global “section location”.

Every signaling node is automatically connected to the SIP and H.323 registration-balancer nodes andSS7 Call Agent nodes, which belong to the same section “location” or to the implied global section“location.”

Each signaling node automatically gets connected to all the scripting nodes, which belong to thesame section “location” or to the implied global section “location.”

Each media node automatically becomes connected to all signaling nodes, which belong to the samesection “location” or to the imaginary global section “location.”

Each registration-balancer node automatically connects to all the scripting nodes, which belong to thesame section “location” or to the implied global section “location.”

Here is a typical case study of the section’s practical application. In a geographically distributedSystem, comprised of two TS servers, one server is located in New York and the other in Moscow,Russia. To avoid situations when half of NY traffic is handled by the Moscow server and vice versa, itis necessary to create two sections “location”. In such a case, American traffic will be handled by theNY TS server, and Russian traffic – by the Moscow server.

Every section “location” allows the inclusion of only one synchro node. If a synchro node belongs tothe global section, there should be no mention of it in all other sections “location”.


Page 38

Example of “location” section configuration

Balancing groups3.9

It is possible to group System nodes (balancer, signaling, scripting and SS7 Call Agent nodes) so thatcalls coming to the access point (balancer or SS7 Call Agent nodes) of a certain groups are handledonly by the nodes pertaining to the group. Balancing groups are used to group nodes in such a way.

In RTU the purpose of balancing grouping is to discriminate between the signaling, scripting andbalancing nodes that handle transit traffic and those engaged in processing subscriber calls, whichfrequently involve value-added services.

To define balancing groups the balancing section is introduced:

balancing{ balancing "class-4" // group name { // names of nodes belonging to this group "scripting-1"; "balancer-1"; "signaling-1"; };

balancing "class-5" { // names of nodes belonging to this group "centrex"; "balancer-2"; "signaling-1"; };};

By default all nodes belong to the empty balancing group.

TS notification function3.10

The TS notification function allows the operator to receive e-mail notifications in case of the Systemmalfunctioning. The alerting is done by the script /usr/sbin/mvts3g-mail invoked when a


Page 39

trouble occurs. The script reads the file /etc/mvts3g/mvts3g-mail.conf and acts inaccordance with the settings therein. E-mail notifications are periodic, the length of the notificationperiod being configurable. The alert messages that occur within the configured period are included inone 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 ofparameters that define contact data, a list of alarms to alert the operator to and delayed dispatchproperties.

1. Contact data

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

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

ALARM_SUBJECT="Notification" – subject of the message

2. List of alarms and severity degrees:

ALARM_ID="NODFLT001, SIG2MED001, MGMCFG001, MGMKEY001, MGMTCN001, SN001,MGMCFG010, COUNTER001, SCRPT_DBMSC_CONNECTION, CENTREXWEBACCESS" – list ofevents to alert the operator.

ID of type BLOCK_NODE<N1>_RPC<N2>_CIC<N3> means sending notifications on ISUP circuitblocking. In the notification ID define the SS7 signaling point ID (snode parameter in SS7 Call Agentnode configuration file) <N1>, destination point code (dpc parameter in SS7 Call Agent nodeconfiguration file) <N2> and media circuit number <N3>. The System will send notification uponblocking of those ISUP circuits that conform to the specified notification parameters.

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 wasinstalled by carrying out the standard installation procedure, there is no need to change the defaultsettings. The only parameter that can be changed is SEND_MINUTE_INTERVAL that defines thetime between periodic notifications in minutes.

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

TS alarms

Alarm Severity Origin Message

SIG2MED001 Critical Signaling No registered medianodes

NODFLT001 Major Any node Node crashed and wasrestarted

SN001 Critical Scripting The Scripting Nodeloader pathmisconfigured

MGMCFG010 Critical Management "Primary managementnode RESTORED" or"Primary managementnode LOST"

COUNTER001 Minor Any node Counter value ….

MGMCFG001 Critical Management System is notconfigured


Page 40

Alarm Severity Origin Message

MGMTCN001 Critical Management Trial period expired

MGMKEY001 Critical Management Failed to read hardwarekey

SCRPT_DBMSC_CONNECTION

Critical “Connection to database lost” or“Connection to database restored”

DISKSPACE Critical LOW DISK SPACE!

<…>

RADIUS_CONNECT Critical Scripting RADIUS changed to aRADIUS <RADIUSserver name> (IP=<IPaddress>:<port>),Connection to RADIUS< RADIUS server name>(IP=<IP address>:<port>) lost orConnection to RADIUS< RADIUS server name> (IP=<IP address>:<port>) restored

CDR_UPDATER Critical Scripting CDR Queue max limitexceeded or CDR Queuelimit came to normal

There is a possibility to configure the system to notify critical changes in the values of TS counters.The feature is configured for each TS node in the section “common” of the TS global configurationfile. 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 generationof repetitive notifications when the counter value vary about the threshold value.

Below is an example of a properly configured alert:

media{

media "media-1"{

signaling "signaling-1";common{

alert "node crashed"{

counter "phoenix.restartcount"{

type "increment";limit "1";


Page 41

};};

}; };};

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

Example:

ID: COUNTER001

SEVERITY: MINOR

NODE: MEDIA

COUNTER NAME: phoenix.restartcount

COUNTER VALUE: 5

DESCRIPTION: Restart count

Counter value more than 1

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

SNMP daemon configuration3.11

The TS SNMP daemon is a background process that allows monitoring of SNMP statistics of the TScounters.

To configure the TS SNMP daemon proceed as follows:

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

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

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

Excerpt from the file snmpd.conf

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

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


Page 42

Excerpt from the file snmpd.conf.sample

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

4. In the file /etc/default/snmpd, comment the line SNMPDOPTS='-Lsd -Lf /dev/null -usnmp -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'.

Excerpt from the file etc/default/snmpd

5. Start the SNMP daemon:

$ /etc/init.d/snmpd start

6. Check that the daemon is running correctly:

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

where

<COMMUNITY> – community name

<IP_address> – IP address of the license management node

.1.3.6.1.4.1.28029 – RTU enterprise OID


Page 43

Excerpt from the output of the ‘snmpwalk’ command

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

Configuration of scripting node logging3.12

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

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

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

Configuration of scripting node logging

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

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

General view of the section, configuring scripting node logging

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

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


Page 44

<node name> is the name of the scripting node, specified in the scripting node configurationfile (see section Scripting node configuration).

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

The IP address and port of the scripting node (in the example - 127.0.0.1:7710 and127.0.0.1:7711), as defined in the scripting node configuration file (see section Scripting nodeconfiguration);

The logrotate keyword.

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

man logrotate

Configuration of DB interoperation3.13

MySQL name of RTU database is ‘rtu’. The installation script automatically creates a database useraccount rtu with the password rtu. The System will use the rights of this user account to interoperatewith the DB.

Availability of the MySQL TCP port 3306 from the external net is a threat to the System security asit can lead to unauthorized System access. It is highly advisable to block access to the port from theexternal network.

Besides, it is recommended to allow access to TCP port 443 (web interface) only from the requiredIPs only.

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

$GLOBALS['cfg'] = array( // Data sources

'data_sources' => array ( 'main' => array ( 'type' => 'mysql', 'host' => 'localhost', 'db' => 'mvtspro', 'user' => 'rtu', 'password' => 'rtu' ), 'mvts' => array ( 'type' => 'mvts', 'address' => '127.0.0.1:9000', 'timeout' => 3 ) ), 'main_data_source' => 'main' ...)

The main subsection comprises parameters governing connection with the DB:

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

host – name or IP address of DB server.

db – DB name (by default - mvtspro).


Page 45

user – DB username (by default - rtu).

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

The mvts subsection comprises parameters for interoperation with the TS tabular interface (seeTraffic Switch) and call simulation service (see Debugging -> Call simulation):

type – data source of DBMS type, should be mvts.

address – IP address and port of LMN node.

timeout – waiting period for a reply from TS.

To access the web-interface of the System, open the web-browser and type following URL in theaddress line: https://server_ip, where server_ip is the IP address of the server with TMdeployed. On the logon page enter admin/admin as login and password respectively. After logginginto the System for the first time, change the administrator password in System users -> Webauthentication. (see section Web authentication).

Traffic switch administration console3.14

The administration console is an accessory application designed for the management and control ofthe Traffic Switch operation. The administration console allows the SysO to upload new configurationto the management node, view statistical and diagnostic information.

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

Traffic Switch administration console

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

The tables below explain the commands and tools of the administration console.

CLI commands

Command Description

config<filename>

(Re)read the system configuration

help Displays the help screen

logout Use these commands to close current session

quit


Page 46

Command Description

show<argument>

Displays pertinent system data

exit Use this command to quit the current tool

CLI tools

Tool Commands Description

calls display Use these commands to view informationabout call sessions currently inprogressshow

format <full/short>

Use this command to change the outputformat the information

counters display Use this command to view informationabout system events

show

zones display Use this command to view information about configured IPzones

show

show Use this command to view informationabout:

calls call sessions in progress

counters system events

zones configured IP zones

endpoints orep

equipment registered to the system

status system status

briefstatus status of the main nodes in brief

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

Output of the show ca(lls) commandTo switch between tools, simply enter the name of the required tool at the command prompt.


Page 47

While working with the administration console you can carry out one and the same task in severalways. 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 theamount of displayed information. The figure below shows the output of the command show of thetool counters when used with the regular expression .*restart.* (display information about the TSnodes restart events). For more information on regular expressions refer toAppendix A.Metacharacters, regular expressions and number transformation.

Using regular expressions to view information about system events

Troubleshooting3.15

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

File phoenix.log3.15.1

All events that occur in the system are logged to the file /var/log/mvts3g/phoenix.log. Incase you encounter any problem with the TS operation, you can use this file to investigate whatcaused the trouble. The syslog utility is used to provide logging. You can learn more about thesyslog by entering the following command:

man syslogd


Page 48

Files rtinfo3.15.2

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

#> ps grep mvts

#> kill –USR1 24342

The resulting rtinfo file with the name rtinfo-SIGUSR1-<node name>-<node pid>.logwill comprise a binary dump of the latest packets processed by the node and detailed messages aboutsystem 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.

Scripting node logs3.15.3

The scripting node log contains the information about the operation of the scripting node and issaved in the /var/log/mvts3g/ directory. The System creates an individual log for eachscripting node with the name <prefix>.<node name>.log, where <prefix> is defined by thevalue of the trace_file parameter (see section Scripting node configuration), and <node name> isthe name of the scripting node, specified in the scripting node configuration file. For example,mvtspro.scripting-1.log. For information about configuration of scripting node loggingrefer to section Configuration of scripting node logging.

mvts3g-logextarctor utility3.16

You can use the mvts3g-logextractor utility located in the directory /usr/bin to extractlogs of call sessions from the global debug log file (/var/log/mvts3g/traffic.log) andsave them to individual files that can be further used for troubleshooting.

To extract the call log, run the utility mvts3g-logextractor providing the ID of the call inquestion:

#>./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 Aloe CustomerSupport personnel.

RTU Web interface

Page 49

RTU Web interface4

The web server provides a friendly graphic interface for convenient configuration and administrationof TM.

What you see on the screen4.1

The screenshots below illustrate the web GUI elements and the terms used in this manual to refer tothe objects that the TM software deals with.

TM objects and GUI elements

GUI elements

Standard procedures4.2

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

Accessing TM’s GUI4.2.1

To establish a link with the web server, enter the IP address or DNS name of the host on the addressline of the web browser you are using, for example, https://mvtspro-server.yourcompany.com. Note

RTU Web interface

Page 50

that the working protocol must be HTTPS (Hyper Text Transmission Protocol, Secure) The Systemwill respond with a logon dialog similar to that shown in the figure below:

Logon dialog box

Enter your login and password (note that the login and password check is case-sensitive), and clickLogin. In case you are using your IP address as the authentication parameter simply click Login. If thelogon 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 areawhich displays the information on the currently selected object.

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

Pop-up menu4.2.2

The pop-up menu comprises a list of control options used in administration of the RTU system.

Left-click on the record of interest in the table you are viewing, to invoke a pop-up menu. The contentof the pop-up menus is contextual, that is, differs from table to table and depends on the user’spermissions. The figure below presents an example of the pop-up menu invoked from the table Users.

RTU Web interface

Page 51

Pop-up menu

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

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

It is advisable not to use string 'Null' as record names.

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

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

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

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

Marked – this command allows you to perform operations over the selected records. When hoveringthe mouse over the options, a new menu will be displayed with two commands - Edit and Delete.

The Edit command allows you to edit marked records. Mark the required records and click Marked ->Edit. You will see a dialog comprising an additional column with checkboxes for each field unlike thedialog invoked by a simple Edit command. Activate the checkbox for the fields that requiremodification, alter the field values and click OK. The changes will be applied to all marked records.

The Delete command allows you to delete marked records. To mark the records, select the respectivecheck boxes in the leftmost column of the table. To mark all the records in the list simply select thecheckbox in the header of the table. When the required records are marked, invoke the pop-up menuand click Marked -> Edit.

Filter - invokes a filter dialog box (for information how to use filters consult section Use of filters).When the button is clicked, and new menu will be shown with two commands – By cell (filter the tableby the value of the selected cell) and By cell (add to existing filter) (add the value of the selected cellto the existing filter).

Filtered – this command allows you to perform operations over the filtered records. When hoveringthe mouse over the options, a new menu will be displayed with two commands - Edit and Delete.

The Edit command allows you to edit all or several records. If a filter was applied to the table, only therecords satisfying the filter criteria will be changed. Mark the required records and click Marked ->Edit. You will see a dialog comprising an additional column with checkboxes for each field unlike thedialog invoked by a simple Edit command. Activate the checkbox for the fields that requiremodification, alter the field values and click OK. The changes will be applied to the filtered records.

The Delete command allows you to delete all records from the table. If a filter was applied to the table,only the records satisfying the filter criteria will be deleted.

RTU Web interface

Page 52

Arrange columns – enables you to arrange the table columns according to your preference (seesection Re-arranging table columns);

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

Filter related tables – a list of tables associated with the table you are working with. The table openedby this command contains information related only to the item selected in the source table. Forexample, left-click a record of interest in the System users table and select Authentication history onthe pop-up menu. The system will display the Web authentication history table with informationabout the selected user only.

Use of filters4.2.3

The use of filters allows you to limit the amount of information displayed onscreen and view only therecords that meet certain criteria.

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

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

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

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

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

To create a filter, invoke the pop-up menu, select Filter and Add to configured. The system willdisplay a filter dialog similar to the one shown in figure below.

Filter construction dialog

The displayed filter dialog has the following controls:

Filter construction dialog controls

Control Description

This control applies the constructed filter to the table contents. Theupper Apply button is used to apply the newly constructed filter while

RTU Web interface

Page 53

Control Description

the lower button serves to apply filters saved earlier.

Use this button to delete saved filters

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

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

Deletes a filtering condition

Adds a new line for filtering condition

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

The look of this dynamic control element varies with the selectedlogical operator

Dynamic control element for selection of comparison operators. Themake-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 regularexpression.

Refer to supplement A for detailed information about meta-charactersand 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 sothat it includes records of active terminating gateways pertaining to networks 192.168.131.0/24 and192.168.132.0/24 only.

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

The required records must… Remarks

AND

…be enabled,

…represent termination gateways,

OR

…belonging to network192.168.131.0/24

Use meta-characters in search

… belonging to network192.168.132.0/24

Use meta-characters in search

RTU Web interface

Page 54

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.

Target filter

To construct the necessary filter, proceed as explained below:

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

Filter construction. Step 1

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

RTU Web interface

Page 55


3. Add a group of conditions by clicking the control * AND * and selecting the Add groupoption in the appearing menu . Note, that *AND* is a default logical operator for groups ofconditions.

Filter construction. Step 3. Adding group

4. Change the logical operator in the newly added group clicking the * AND * control andselecting OR in the appearing pop-up menu.

RTU Web interface

Page 56


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


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

RTU Web interface

Page 57


7. Repeat steps 5 and 6 to add a similar condition for gateways belonging to network192.168.132.0/24. This step completes the filter creation procedure. To apply the filter to thecontents of the table click the upper button Apply.


With a filter applied the table displays the icon next to its heading to indicate that what you areviewing is not the complete table content. To cancel the filter, click the icon. For the user’sconvenience 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 buttonon the filter, enter the filter’s name in the appearing dialog and click the OK button.

Saving a filter for future use

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

RTU Web interface

Page 58

Selecting an earlier saved filter

Sorting table data4.2.4

The System allows you to sort the contents of the table columns. To sort data in a column, click thecolumn header. The first click causes the column contents sorting in the descending order with thesort order indicated by a down arrow next to the column header. To reverse the sort order, click thecolumn 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 severalcolumns. In this case the last sorting you apply becomes the main sorting criterion. The sortprecedence is indicated by the number appearing next to the arrow sort indicator at the columnheader.

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

Re-arranging table columns4.2.5

For the sake of convenience, the system allows you to display, conceal and re-arrange table columnsaccording to your preference. Click Arrange columns on the pop-up menu. The system will display adialog box similar to the one shown in the figure below.

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

RTU Web interface

Page 59

right box to the left and vice versa.

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

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

Click the Apply button when you are through with configuring the table. The new column layout will

be applied to the table. You will also see the icon next to the table name.

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

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

If you do not save your settings, the system will still remember the table layout you configured andthe 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.

Table autorefresh4.2.6

The RTU’s web interface allows you to configure periodic updating of the data in the table.

To configure the table contents updating, invoke the pop-up menu and select the item Configureautorefresh. The appearing autorefresh dialog allows the selection of auto updating frequency.

Selecting auto update period

To start periodic updating, click on the Start button. The ongoing periodic updating is indicated by

the autorefresh icon , appearing next to the table name.

To stop periodic updating, click on the autorefresh icon or invoke the pop-up menu, select theConfigure autorefresh option and press the Stop button on the autorefresh dialog.

Editing multiple table records4.2.7

The button Switch to edit mode appearing over every table brings up a dialog box that allows you toedit all the records currently displayed simultaneously. The figure below illustrates such multiple-editdialog box invoked from the table “Codec group setup”.

RTU Web interface

Page 60

Editing multiple table records

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

Data export4.2.8

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.

RTU Web interface

Page 61

You will see the Save as dialog box. Use the Save in combo box to indicate the device and folderwhere 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 Fileand click Save.

Component version view4.2.9

To view the versions of the System components in the web interface click the hyperlink with Systemname and version in the bottom right corner of the web interface window. A new dialog with theSystem component version will be displayed.

RTU Web interface

Page 62

Viewing the System component versions in the web interface

The following designations are used:

Centrex - the version of the RTU Class 5 component.

Logic – the version number of the scripting node software.

TS – the Traffic Switch version number.

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

RTU – the System version.

Operating TM

Page 63

Operating TM5

Administration5.1

System users5.1.1

The table of users (Administration > System users) presents information about personnel who haveaccess to and operate the RTU system.

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

Add-user dialog

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

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

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

* Role – from the combo box select the role to be assigned to the user. For the description of rolesconfiguration see sections Roles and Role settings.

Enable – select the checkbox to make the record active.

When through with entering data, click OK to submit the newly made record. The program assignsthe 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-upmenu.

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

Operating TM

Page 64

Web authentication5.1.2

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

TM can perform user authentication by any attribute defined in the authentication record – the loginname, 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 parametersconfigured in the user authentication record and uses the OR condition in case of multipleauthentication 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 trafficstatistics both from the office tabletop computer with a trusted IP and any other IP (laptop) when onthe move.

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

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

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

Web authentication dialog box

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

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

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

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

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 abortthe procedure.

Operating TM

Page 65

Roles5.1.3

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

Creating a new role

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

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

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

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

* Name – enter the name of the new role;

Description – enter any information relevant to the role.

When done, click the OK button.

Once the role is created, assign the rights to the role (see section Role settings) and compile it.

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

The new role ready to be compiled

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

Role settings5.1.4

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

Operating TM

Page 66

Role construction window

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

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

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

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

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

[M] – category;

[T] – object (table);

[C] – parameter (table column).

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

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

View – viewing elements.

Update – modifying the element value.

Insert – creating new element.

Delete – deleting the element.

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

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

System user creation wizard5.1.5

System user creation wizard allows you to facilitate the process of creating new user accounts in RTU.Click the System user creation wizard to start creating an account.

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

Add User Wizard dialogue box

Click Next button.

Operating TM

Page 67

User account dialogue box

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

Authentication dialogue box

Enter the following parameters in the Authentication dialogue box:

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

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

Password, IP address – use these fields to enter respective user authentication attributes (seesection Web authentication).

Click Next.

Create user final dialogue box

Operating TM

Page 68

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

Web realms5.1.6

The division of the GUI into distinct realms is an RTU security measure that provides fordifferentiation of user GUI access rights.

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

The inaccessibility of authentication records of users belonging to a different realm prevents thepossibility of password guessing and password hacking attacks.

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

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

Realms table

The Realms table shows the realms configured in the system.

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

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

Adding a new realm

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

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

The unique ID of a web realm is one of the configuration parameters of the PHP-application (seebelow).

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

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

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

Then edit the configuration file Config.php, found in the directory /var/www/rtu, and specify the ID ofthe created private realm in it:

Operating TM

Page 69

Entering the ID of a new realm into Config.php

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

Equipment5.2

The category equipment comprises information about the equipment, RTU interoperates with, zonesand codecs.

Equipment5.2.1

The table Equipment displays information about the equipment that RTU interoperates with.

List of configured gateways

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

Operating TM

Page 70

Configuring a gateway record

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

Enabled – select the checkbox to make the record active.

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

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

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

Gateway – this gateway is a trunk gateway.

Gatekeeper – this gateway acts as a gatekeeper.

Default gateway – this gateway acts as a default template gateway, for the devices notconfigured in RTU.

RADIUS routing server – this gateway acts as an external routing server over RADIUSprotocol.

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

Endpoint – this object is an individual piece of equipment (a subscriber’s terminal) with aphone number assigned to it. For each endpoint the System implicitly creates a dial peer withthe name <endpoint name>-epdp. (see Appendix J).

When adding an object of Endpoint type the System automatically creates an implicit dial peer for itthat doe not show up in the Dial peers table. To see the dial peer for such an object open the Dialpeers tree (section Tree of dial peers).

SIP routing server – this gateway acts as an external routing server over SIP protocol with thehelp of 30x messages (for more details see section Appendix K).

Operating TM

Page 71

* Endpoint number – the phone number of the endpoint that is sent by the endpoint equipment. Thisparameter is valid, if the Endpoint option is selected from the Equipment type.

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

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

* Protocol – specify the signaling protocol supported by the device. If the option H.323 or SIP wasselected and the gateway acts as a terminator, the System will transmit data to this gateway under theprotocol (H.323 or SIP), used by the originator. If the originator operated under a protocol, differentfrom SIP or H.323, the SIP protocol will be used to transmit data to the terminator. If it is necessary toreceive a call from another balancing group (see section Balancing groups) or transfer a call to anotherbalancing group, select the Internal option.

Register equipment – select the checkbox to register the equipment with RTU. If the Default gatewayis selected in the Equipment type list, the gateway will always be registered.

* Term. default protocol – the signaling protocol for communicating with the terminator, if theoriginator used protocol other than H.323 or SIP. The parameter is valid if the H.323 and SIP optionwas selected in the Protocol parameter and the equipment acts as a terminator.

Balancing group – select the balancing group from the list box (see section Balancing groups) fromwhich the call comes or where it goes to. The parameter is displayed when the Internal option isselected in the Protocol parameter.

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

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

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

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

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

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

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

Orig. IP address list – define the list IP addresses used by the device for call origination (you can usethe CIDR format for IP addresses). RTU will receive calls from the specified addresses. In case the SS7protocol is used or the equipment does not register with the System, this parameter is invalid.

Orig. port – specify the signaling port of the origination device for the purpose of caller identification.In case the SS7 protocol is used or the equipment does not register with the System, this parameter isinvalid.

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

Orig. NAT address – specify the address of the NAT device if the configured gateway is sittingbehind a network address translator. In case the SS7 protocol is used or the equipment does notregister with the System, this parameter is invalid.

* Orig. Zone – use the combo box to select the zone (see section Zones) to be used for callsoriginated by the device. In case the SS7 protocol is used, the SS7 zone is used to address thegateway.

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

Use terminator's proxy mode — use the policy that was established on the terminator;

Proxy media — always proxy media.

Operating TM

Page 72

Do not proxy media — disallow proxying;

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

The codec group for the originator should comprise not more than 1 video codec, otherwise theSystem will be unable to handle calls from such originator.

SRC Capacity group – select the name of the common capacity group from the drop-down list. Thegateway will belong to the selected capacity group. For more information about capacity groups seesection Capacity groups.

Max. incoming calls – the maximum number of incoming calls the device can handle simultaneously. Ifthe field is empty or zero is entered, the number of calls is unlimited.

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

Orig. allowed SRC numbers – enter a regular expression that determines the pattern for allowedsource numbers. This parameter is invalid if the Default gateway is selected in the Equipment typeparameter.

To set up a device with several analog sockets (FXS ports), create a gateway record for each socketand specify the respective socket (port) number, configured on the device, in the Orig. allowed SRCnumbers parameter for each gateway.

Orig. allowed DST prefixes – enter a regular expression that determines the pattern for alloweddestination numbers. This parameter is invalid if the Default gateway is selected in the Equipment typeparameter.

Orig. disallowed DST prefixes – enter a regular expression that determines the pattern for disalloweddestination numbers. Disiallowed numbers override the allowed ones. This parameter is invalid if theDefault gateway is selected in the Equipment type parameter.

SRC Codec change policy – from the drop-down list select the policy for transmitting changes incodecs, used by the originator:

Do not pass changes – the changes in codecs on one leg (incoming) are not transmitted to theother leg. Thus, different codecs may be used on the two legs. In case the codecs do notcoincide, codec conversion takes place if possible.

Pass changes of media type – the System passes changes in type of media used from one leg(incoming) into the other (for example, when the originator switches from audio to fax). If thechanges in codecs are restricted to one media type and the System is able to convert thesecodecs (for example, when switching from one audio codec to another), then the changes arenot communicated to the other leg. If the other party is unable to support the changes, the calllegs revert to the original state.

Pass changes for G.711 – same as Pass changes of media type, but besides changes arecommunicated to the other leg if one of the parties tries to switch to or from the G.711 codec.The G.711 codec may be used to transmit faxes and establish modem connections.

Pass all changes – all changes in codecs are communicated from one leg into the other.

These politics are applied during call setup, when the System receives information about codecsavailable to the originator and terminator, as well as during the call itself, when the equipment tries tochange the codec used. For further information about codec policies see Appendix B.

SRC Number capacity group – select the number capacity group for the SRC numbers. For furtherinformation about number capacity groups see section Number capacity groups.

Always use TS ConfID instead of Protocol ConfID – select the checkbox to use Conf ID generated bythe TS instead of the Conf ID taken from the signaling protocol. This Conf ID will be displayed inProtocol conference ID CDR parameter.

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

Operating TM

Page 73

Term. IP address – define the IP address used by the device for call termination (only one IP addressis allowed). In case the SS7 protocol is used or the equipment registers with the System, thisparameter is invalid.

Term. port H.323 – define the port number to be used for call termination under H.323. In case the SS7protocol is used or the equipment registers with the System, this parameter is invalid.

Term. port SIP – define the port number to be used for call termination under SIP. In case the SS7protocol is used or the equipment registers with the System, this parameter is invalid.

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

* Proxy policy – define the media proxy policy to be used when the device acts as a call terminator.For further information about proxy policies see section Proxy policies.

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

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

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

Matching codecs first – sort the list moving terminator’s codecs matching those of theoriginator to the beginning of the list. The order of codecs in the subset of common codecs isdefined by the order of the codecs, received from the originator. The order of the codecsoutside the subset is determined by the attribute Precedence of each codec.

For further information about the actions of the System depending on the proxy mode and codecsorting settings, see Appendix B.

DST capacity group – select the name of the common capacity group from the drop-down list. Thegateway will belong to the selected capacity group. For more information about capacity groups seesection Capacity groups.

Max. outgoing calls – the capacity value is the maximum number of outgoing calls the device canhandle simultaneously. If the field is empty or zero is entered, the number of calls is unlimited.

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

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

The parameter is valid if the SIP or H.323 and SIP options are selected in the Protocol parameter.

DST Codec change policy – from the drop-down list select the policy for transmitting changes incodecs, used by the originator:

Do not pass changes – the changes in codecs on one leg (outgoing) are not transmitted to theother leg. Thus, different codecs may be used on the two legs. In case the codecs do notcoincide, codec conversion takes place if possible.

Pass changes of media type – the System passes changes in type of media used from one leg(outgoing) into the other (for example, when the originator switches from audio to fax). If thechanges in codecs are restricted to one media type and the System is able to convert thesecodecs (for example, when switching from one audio codec to another), then the changes arenot communicated to the other leg. If the other party is unable to support the changes, the calllegs revert to the original state.

Pass changes for G.711 – same as Pass changes of media type, but besides changes arecommunicated to the other leg if one of the parties tries to switch to or from the G.711 codec.The G.711 codec may be used to transmit faxes and establish modem connections.

Pass all changes – all changes in codecs are communicated from one leg into the other.

These politics are applied during call setup, when the System receives information about codecs

Operating TM

Page 74

available to the originator and terminator, as well as during the call itself, when the equipment tries tochange the codec used. For further information about codec policies see section Codec matchingrules.

DST Number capacity group – select the number capacity group for the DST numbers. For furtherinformation about number capacity groups see section Number capacity groups.

Category Registration settings

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

Registration username – enter a registration name, received from the device. This parameter is invalidif the Default gateway options was selected in the Equipment type list.

Registration password – specify a registration password. This parameter is invalid if the Defaultgateway options was selected in the Equipment type list.

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

Registration keep-alive time, sec – set the registration updates interval for the RAS-users registeredwith RTU, in seconds.

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

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

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

Use port from registration request as Orig. port – when the gateway registers with the System,select the checkbox to use the port from registration request as the Orig. port. This allows the Systemto differentiate between the among several SIP terminals behind a NAT device. This means that theINVITE message must originate from the same port as the REGISTER message, otherwise the call willbe rejected. If the checkbox is deselected, the INVITE after registration may originate from any port.The parameter is valid if the Register equipment checkbox is activated and SIP, SIP-T or H.323 andSIP protocol are selected.

When several registrations arrive they are sorted by arrival time and only the last one is consideredactive. After the expiry of the last registration the previous registration becomes active (if it has notexpired by that time) etc.

Category Number translation rules

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

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

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

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

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

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

The above configured number transformation rules will be applied to the numbers before the callrouting procedure starts.

Category Origination signaling settings

This group of parameters is intended for configuration of the gateway properties when the gateway is

Operating TM

Page 75

an origination device. The parameters are valid only with the Allow origination checkbox selected.

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

Orig. drop call on alerting timeout - select the checkbox to drop calls when the timeout, after whichthe ALERTING message should come from the originator, expires.

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

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

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

Orig. RTP timeout, sec – serves to set the length of a time interval for checking the established linkfor the presence of RTP packets from the call originator. The first check interval starts upon the arrivalof CONNECT. After the defined period lapses, the System checks if there were RTP packetsexchanged during the period. The call is aborted if no RTP packets came from the originator during thetime.

Orig. CallProceeding timeout, msec – set the packet forwarding delay in milliseconds, during whichthe call setup packets exchange with the origination device is suspended. During call setup packetsarriving from the termination device are stored in the TS buffer, whose content will be forwardedfurther to the call originator only when the delay time specified in this field is over. Such organizationof the call setup and look-ahead routing procedure is needed for devices that can handle oneCallProceeding message only. Hence, if a CallProceeding message is occasionally followed by aRelease_Complete message, further interoperation (call setup and call rerouting) with such a deviceintolerable to repeated CallProceeding messages may become impossible. This parameter is invalid ifthe ENUM server option was selected in the Equipment type parameter.

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

Orig. allow media channels update – select the checkbox if the device being configured is capable ofreceiving repeated FastStart messages. This parameter is invalid if the ENUM server option wasselected in the Equipment type parameter.

Orig. Method of sending DTMF over H.323 – select the method of transmitting DTMF over H.323.This parameter is valid, if H.323 or SIP and H.323 options are selected in the Protocol parameter.

Orig. faststart – from the drop-down list select the applicable mode of using FastStart procedure forthe originator:

Disabled – do not use the FastStart procedure;

Enabled – use the FastStart procedure;

This parameter is invalid if the ENUM server option was selected in the Equipment type parameter.

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

Call Proceeding,

Alerting/Progress,

Connect;


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

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

Call proceeding

Alerting/Progress

Connect


SRC Calling party’s category – to save the calling party’s category, received from the originator

Operating TM

Page 76

unmodified, select the blank option. To change the calling party’s category select the desiredcategory from the list.

Orig. use SRC number from encl. ISUP packet – select the checkbox to use the “SRC alias”parameter from the ISUP, but not SIP headers. The checkbox is valid only if the SIP-T protocol wasselected in the Protocol combobox.

Orig. use DST number from encl. ISUP packet – select the checkbox to use the “DST alias”parameter from the ISUP, but not SIP headers. The checkbox is valid only if the SIP-T protocol wasselected in the Protocol combobox.

Orig. use original DST number from encl. ISUP packet – select the checkbox to use the “Diversion”parameter from the ISUP, but not SIP headers. The checkbox is valid only if the SIP-T protocol wasselected in the Protocol combobox.

Orig. use CPC from encl. ISUP packet – select the checkbox to use the “CPC” parameter from theISUP, but not SIP headers. The checkbox is valid only if the SIP-T protocol was selected in theProtocol combobox.

Early ACM timeout – defines a timeout after which the System sends ACM message. The parameteris defined in milliseconds. The range of available values - from 20000 to 30000 milliseconds (by default– 30000 ms). The parameter is valid only if the SIP-T protocol was selected in the Protocol combobox.

Echo control device – the checkbox governing the “Echo control device” parameter in the outgoingIAM, ACM, CPG and CON messages. By default, the checkbox is deselected, which means that theparameter is “false”. The parameter should have the same value as the parameter on the mediagateway. The checkbox is valid only if the SIP-T protocol was selected in the Protocol combobox.

Category Termination signaling settings

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

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

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

Same as on the incoming leg

Unknown

International number

National numer

Network specific number

Subscriber number

Abbreviated number

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


Unknown

ISDN telephony numbering plan (Recommendation E.164)

Data numbering plan (Recommendation X.121)

Telex numbering plan ((Recommendation F.69)

National standard numbering plan

Private numbering plan

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


Unknown

Operating TM

Page 77

International number

National numer

Network specific number

Subscriber number

Abbreviated number

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


Unknown

ISDN telephony numbering plan (Recommendation E.164)

Data numbering plan (Recommendation X.121)

Telex numbering plan ((Recommendation F.69)

National standard numbering plan

Private numbering plan

Term. method of sending DTMF over H.323 – select the method of transmitting DTMF over H.323.This parameter is valid, if H.323 or SIP and H.323 options are selected in the Protocol parameter.

Term. faststart – from the drop-down list select the applicable mode of using FastStart procedure forthe originator:

Disabled – do not use the FastStart procedure;

Enabled – use the FastStart procedure;

Enabled whenever possible – use the FastStart procedure if possible, if not - use slow startwithout switching into proxy mode;

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

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

Call proceeding

Alerting/Progress

Connect

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

Same as for the incoming leg

Octet 3a not present

Presentation allowed

Presentation restricted

Number not available due to interworking

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

Same as for the incoming leg

Not screened

User-provided, not screened

User-provided, verified and passed

User-provided, verified and failed

Network provided


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


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

Operating TM

Page 78

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

* Term. report original destination – this combo box determines if the System should pass thenumber of original terminator to the outgoing leg:

No

Yes

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

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

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

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

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

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

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

Term. RTP timeout, sec – serves to set the length of a time interval for checking the established linkfor the presence of RTP packets from the call terminator. The first check interval starts upon the arrivalof CONNECT. After the defined period lapses, the System checks if there were RTP packetsexchanged during the period. The call is aborted if no RTP packets came from the termination partyduring the time. This parameter is valid, if the Allow origination checkbox is selected and any optionother than Do not proxy media is selected in the Proxy policy parameter.

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

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

the left-arrow button . Holding down a Shift or a Ctrl key allows you to select several

categories at once. Use the and buttons to move all categories from the right boxto the left one and vice versa.

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

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

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

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

SIP CPC – the category is transmitted via SIP in the “cpc” parameter of the “From” field. The

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

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

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


Operating TM

Page 79

category is transmitted according to the OLI standard. For further information see The CallingParty's Category tel URI Parameter.

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

SIP CPC-RUS – the category is transmitted via SIP in a “cpc-rus” parameter of the “From”field.

SIP CPC-NUM - the calling party's category is sent as a number substituted in the SIP Fromfield. The CPC standard is used.

Term. use display name of incoming leg – select the checkbox to pass the ‘Display-Name’ parameterfrom the incoming leg to the outgoing leg.

* ACM No indication reaction – the parameter defines the System’s reaction to the receipt of an ACMwith DC=00 and I=1. This parameter is valid only when using the SS7 protocol.

Do not require SIP-T support – select the checkbox if the terminator does not support SIP-T. In sucha way the System will be able to operate over SIP-T with an equipment supporting SIP only. Thecheckbox is valid only if the SIP-T protocol was selected in the Protocol combobox.

Transmission Medium Requirement – the value sent in the “Transmission medium requirement” fieldin the IAM message. Valid values – 0-3 (by default - 0). The checkbox is valid only if the SIP-Tprotocol was selected in the Protocol combobox.

Add end of dialing symbol to the DST number – select the checkbox to add the ST symbol (#, code0x0f) to the DST number, if the DST number comprises no such symbol. The checkbox is valid only ifthe SIP-T protocol was selected in the Protocol combobox.

Category LAR settings

LAR allow (H.323) – make a list of H.323 disconnect codes that are expected to trigger rerouting forthe call. The codes are delimited trough “;”.

LAR deny (H.323) – make a list of H.323 disconnect codes that will prevent further routing for the call.The codes are delimited trough “;”.

LAR allow (SIP) – make a list of SIP disconnect codes that are expected to trigger rerouting for thecall. The codes are delimited trough “;”.

LAR deny (SIP) – make a list of SIP disconnect codes that will prevent further routing for the call. Thecodes are delimited trough “;”.

LAR allow (TS) – make a list of TS disconnect codes that are expected to trigger rerouting for the call.The codes are delimited trough “;”.

LAR deny (TS) – make a list of TS disconnect codes that will prevent further routing for the call. Thecodes are delimited trough “;”.

LAR allow (TM) – make a list of TM disconnect codes that are expected to trigger rerouting for thecall. The codes are delimited trough “;”.

LAR deny (TM) – make a list of TM disconnect codes that will prevent further routing for the call. Thecodes are delimited trough “;”.

LAR allow (RTU Class 5) – make a list of RTU Class 5 disconnect codes that are expected to triggerrerouting for the call. The codes are delimited trough “;”.

LAR deny (RTU Class 5) – make a list of RTU Class 5 disconnect codes that will prevent furtherrouting for the call. The codes are delimited trough “;”.

Category RADIUS

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

Enable RADIUS authorization – select the checkbox to send call authorization requests to theRADIUS-server. RADIUS authorization is valid only for the call originator. The System sendsauthorization requests only for the first route in the dial peer.

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

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







Operating TM

Page 80

RADIUS-server.

RADIUS username – enter the username to be included into the packets sent to the RADIUS serverin cases when the device being configured originates calls. By default for static gateways RTU usesthe IP address of the call origin. The string $ani$ in the field is replaced with the outgoing SRCnumber. The $ani$ metasymbol is invalid, if the gateway registers with the System. The parameter isvalid if the gateway uses RADIUS authentication, authorization or accounting.

RADIUS password – enter the password to be included into the packets sent to the RADIUS server incases when the device being configured originates calls. By default for static gateways RTU uses the“xpgk” string. The parameter is valid if the gateway uses RADIUS authentication, authorization oraccounting.

Filling out User-Name and User-Password fields sent to the RADIUS server

Values of RADIUS usernameand RADIUS password

System reaction

The equipment registers with the System

RADIUS username = notdefined

The User-Name and User-Password fields are filled out withRegistration username and Registration password valuesrespectively.

RADIUS username = $ani$ The User-Name and User-Password fields are filled out withRegistration username and Registration password valuesrespectively.

RADIUS password = notdefined

The User-Password is set to the xpgk string.

RADIUS username = $ani$IP The User-Name is set to the IP string.

RADIUS username = IP The User-Name is filled out with the IP address of the equipment.

RADIUS username = anyother value

RADIUS password = *

The User-Name is filled out with the RADIUS username value. TheUser-Password is filled out with registration data (tokens), receivedby the System upon the equipment’s registration.

In case of SIP the User-Password is not sent to the RADIUS server;instead the Digest-Realm, Digest-Nonce, Digest-URI, Digest-Method, Digest-Response attributes are sent, together with theDigest-Username that holds the User-Name value.

In case of H.323 and CHAP authentication the User-Password is notsent to the RADIUS server; instead the CHAP-Password andCHAP-Challenge fields are sent.


RADIUS password = anyother value

The User-Name and User-Password are filled out with RADIUSusername and RADIUS password values respectively.

The equipment does not register with the System

RADIUS username = notdefined

The User-Name is filled out with the IP address of the equipment.

RADIUS password = notdefined

The User-Password is set to the xpgk string.

RADIUS username = IP The User-Name is filled out with the IP address of the equipment.

Operating TM

Page 81

Values of RADIUS usernameand RADIUS password

System reaction

RADIUS username comprisesthe $ani$ string

The User-Name is filled out with the RADIUS username value, the$ani$ string is replaced with the SRC number after the gateway SRCnumber translation is applied (defined by the Orig. SRC numbertranslation).

RADIUS username = $ani$IP The User-Name is filled out with the RADIUS username value, the$ani$ string is replaced with the SRC number after the gateway SRCnumber translation is applied (defined by the Orig. SRC numbertranslation). The IP string remains unchanged.


RADIUS password = anyother value

The User-Name and User-Password are filled out with the RADIUSusername and RADIUS password values respectively.

Force "Telephony" in h323-call-type – select the checkbox to replace the "h323-call-type=VoIP" with"h323-call-type=Telephony" in the incoming leg packets.

Cisco-NAS-Port value – the value of this parameter (if defined) will be put into the VSA Cisco-NAS-port field in the Accounting Stop packets.

Category Redial settings

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

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

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

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

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

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

Category Gatekeeper settings

The following parameters should be used in case the device being configured is a remote gatekeeper.The parameters are valid if the Gatekeeper option was selected in the Equipment type list.

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

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

GK IP address – enter the gatekeeper IP address.

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

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

Category SIP routing server settings

This category comprises parameters designed to configure SIP routing server. The parameters arevalid if the SIP routing server option is selected in the Equipment type combobox:

SIP router IP address – address of SIP routing server in the form of <IP:port>.

SIP router first answer timeout, msec – define the timeout in milliseconds after which the call shouldbe terminated in case of no answer to INVITE message, sent to the routing server.

Use SIP router address for billing – select the checkbox to use the SIP routing server address inCDRs, not the address of the real terminator.

Operating TM

Page 82

Write real DST numbers to CDRs – select the checkbox to write the DST number of the realterminator to the CDR Outgoing DST number parameter, instead of the SIP router DST number.

Category Default gateway settings

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

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

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

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

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

RADIUS only – use the DST numbers received from the RADIUS server (in the xpgk-ep-number field). The numbers received from the equipment as part of the registration request areignored.

Equipment if no numbers from RADIUS – if the System does not receive the DST numbersfrom the equipment, use the numbers received from the RADIUS server (in the xpgk-ep-numberfield).

RADIUS if no numbers from equipment – if the System does not receive the DST numbersfrom the RADIUS server (in the xpgk-ep-number field), use the numbers received from theequipment.

Category Miscellaneous

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

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

SIP Query gateway – select the checkbox to allow RTU to monitor the serviceability of SIP gatewaysby periodically sending them the OPTIONS request as long as the gateways are handling calls. Theparameter is valid, if the SIP or SIP and H.323 option was selected in the Protocol field.

SIP Gateway query interval, sec – define the interval between repetitive OPTIONS requests (inmilliseconds). The parameter is valid, if the SIP or SIP and H.323 option was selected in the Protocolfield.

H.323 TCP connect timeout, msec – use this parameter to set tcp-connect wait time (in milliseconds).A failure to establish an H.225 session within the specified time results in call disconnection. Theparameter is valid, if the SIP or SIP and H.323 option was selected in the Protocol field.

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

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

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.

Operating TM

Page 83

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

0x0040 – in compliance with RFC5347 emulate 2 media circuits. This mode is required tointeroperate with devices, that put 2 ‘m=’ strings into SDP as per T.38 specification.

0x0080 – do not respond to a repeated INVITE with a SIP 100 message.

0x0100 – allow a media node to automatically redirect the media stream to the actual port fromwhich the equipment sends RTP packets, if the port differes from the port, indicated in thesignaling messages.

0x0200 – do not start the MSD exhange procedure during the second and subsequent TCSexhanges.

0x0400 – enable recognition of inband DTMF from the endpoint equipment.

0x0800 - enable correction of invalid timestamps in incoming RTP stream.

0x1000 - include PRACK method into the list of supported methods for outgoing SIP messagesand declare 100rel support. However, if the terminator requires PRACK in its response, the TSwill send PRACK despite the disabled flag. For SIP-T calls the TS always acts as if the flag isenabled despite its actual setting.

0x2000 - enable repacketization of outgoing RTP packets.

0x4000 - disable dispatch of SIP OPTIONS as TCS to the remote equipment.

If you want to set several flags simultaneously, enter the sum of the required flags.

ENUM - The list of configured ENUM servers is in the left window (see section ENUM servers). Selectan 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 ENUMrouters in the right-hand window, select the appropriate server name and click the left-arrow button

. Holding down a Shift or a Ctrl key allows you to select several servers at once. Use the

and buttons to move all records from the right box to the left one and vice versa.

By shifting the servers names up and down in the list, using the and , buttons, youcan change the ENUM-server query order. If the first server in the list is not available, the next serverwill be queried, till the system finds an available server to be used for external routing.

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

Deny use of dynamic payload types for standard codecs – select the checkbox, if the H.323 gateway isnot capable of redefining payload types for regular codecs for which data types are determined by thestandard.

* SIP Reason policy – from the combobox select the method for generating SIP Reason headers.

Write all disconnect codes – write all disconnect codes to the SIP Reason headers without anymodifications.

Write all disconnect codes and add Q.850 – write all disconnect codes to the SIP Reasonheaders without modifications and add a respective Q.850 code.

Write Q.850 only – write one SIP Reason with a respective Q.850 code only.

Do not use SIP Reason field – do not add Reason headers.

* Q.850 reason source – select the source of Q.850 disconnect codes if the SIP-T protocol is used:

SIP Q.850 reason – use codes from SIP headers.

ISUP Q.850 reason – use codes from ISUP headers.

IP ToS for RTP-packets – define the value of Type of Service field for RTP packets sent to thegateway. The valid values range from 0 to 255.

Force start of H.245 on the other leg upon TCS receipt – select the checkbox if on receipt of TCS (thelist of codecs supported by the equipment) on one call leg, the System should open an H.245 channelon the other leg. This parameter is valid, if H.323 or SIP and H.323 options are selected in theProtocol parameter.

Operating TM

Page 84

ISUP T6 timer value - timeout for RES message arrival (originated by the network) after the receipt ofSUS message (originated by the network). Valid values 90 - 180 secs, default value - 180 secs. Thisparameter is valid, if SIP-T option is selected in the Protocol parameter.

CauseLocation value in outgoing REL messages - "CauseLocation" value that will be put into theoutgoing REL messages. Values are defined according to Q.850. Default value - RLN. This parameteris valid, if SIP-T option is selected in the Protocol parameter.

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

Default gateway endpoints5.2.2

This table comprise registration and authentication data for the endpoints that register with theSystem through default gateways (refer to Appendix C. Default gateways).

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

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

Enabled – select the check box to make the record effective.

* Name – enter the name of the endpoint.

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

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

* Default gateway – in the drop-down list select the default gateway to which the authentication dataof the endpoint pertain. Upon arrival of a registration request to a specific default gateway the

Operating TM

Page 85

registration information will be matched to the endpoint parameters associated with the defaultgateway.

* Endpoint number – the endpoint number that is matched to the number from the registrationrequest.

* Registration username – endpoint registration name that is matched to the registration name fromthe registration request.

Registration password – endpoint registration password that is matched to the registration passwordfrom the registration request.

Override max registration time, sec – define the period for a complete endpoint re-registrationperiod. This parameter overrides the value of Max. registration time, sec parameter defined in thedefault gateway to which the endpoint pertains.

Override registration keep-alive time, sec – define the interval between dispatching keep-alivepackets (required to maintain endpoint registered state). This parameter overrides the value ofRegistration keep-alive time, sec of the default gateway to which the endpoint pertains.

Override registration address list – enter a list of IP addresses allowed for registration with RTU forthis endpoint. Delimit the addresses with semicolons. This parameter overrides the Registrationaddress list parameter of the default gatewau to which the endpoint pertains.

Override NAT keep-alive time, sec – sets a keepalive interval for NAT devices. This parameteroverrides the value of the NAT keep-alive time, sec parameter of the default gateway, to which theendpoint pertains.

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.

To edit or delete a record, invoke the pop-up menu and select the necessary command.

Zones5.2.3

The table Zones presents information about IP and SS7 zones involved in TS call routing. For moredetail on the intent of IP zones refer to section IP zones).

Table of configured zones

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

Add zone dialog box


* Zone name – enter the name of the IP zone as it is defined in the TS configuration file, section zones,or enter the name of the SS7 zone as it is defined in the SS7 Call Agent node configuration file, sectionss7zone.

Operating TM

Page 86

It is mandatory that the IDs of zones in the web-interface are identical to their names in the systemconfiguration files.

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

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

Codecs5.2.4

The table Codecs keeps information about codecs configured in the DB. A codec means a specificimplementation of media data encoding standard bundled with specific required parameters.

Table “Codecs”

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

Adding a codec


* Name – codec name.

* Codec type – select a codec family to which the codec belongs. The codec family implements acertain media encoding standard.

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

* Sample rate, Hz – number of samples per second (or per other unit) taken from a continuous signalto make a discrete signal.

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

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

Operating TM

Page 87

The presence and contents of the Modes and Flags parameters are defined by the codec family,selected in the Codec type field. The table below shows the codec types for which these parametersare available.

Modes and flags for various codec types

Codec type Modes and Flags Description

g.729 Modes

Basic The codec corresponds to G.729 plain

Annex A The codec corresponds to G.729a

speex Modes

1, 2, 3, 4, 5, 6, Any Refer to The Speex Codec Manual for information aboutthe Speex codec parameters.

Flags

Perceptualenhancement

Perceptual Enhancement

Refer to The Speex Codec Manual for information aboutthe Speex codec parameters.

VBR Variable Bitrate

Refer to The Speex Codec Manual for information aboutthe Speex codec parameters.

ilbc Modes

30 ms frame The codec corresponds to iLBC-13k3

20 ms frame The codec corresponds to iLBC-15k2

amr Modes

4.75, 5.15, 5.9, 6.7,7.4, 7.95, 10.2, 12.2

The bandwidth of the media stream in real time, i.e. aminimum circuit bandwidth (in kbit/s) that is required topass this stream without delays. For further informationrefer to 3GPP TS 26.073 — AMR speech Codec.

Flags

“Fring” spring Select the checkbox to support Fring soft phone.

Octet-aligned mode For further information refer to RFC 3267.

g.726 Modes

16, 24, 32, 40 kbit/s The bandwidth of the media stream in real time, i.e. aminimum circuit bandwidth (in kbit/s) that is required topass this stream without delays.

Match with any codec of the same type – this flag indicates that this codec matches any codec withthe same codec type irrespective of matching flags, modes and voice activity detection indicators. Inother words if the checkbox is deselected two codec are considered to be matching (for example, when

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












http://www.3gpp.org/ftp/Specs/archive/26_series/26.073/26073-800.zip






http://www.fring.org/



Operating TM

Page 88

checking if the codec is allowed during origination), if both codec have the VAD indicator selected ordeselected and their modes/flags are the same. If this flag is selected, this codec is considered to bematching any other codec with the same codec type.


Codec groups5.2.5

The table Codec groups keeps information about codecs groups configured in the DB. Individualcodecs may be united under one codec group.

Table “Codec groups”

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

Adding a codec group


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

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


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

Codec group setup5.2.6

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

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

Operating TM

Page 89

Table of codecs

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

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 combobox (the drop-down list is populated with the names of groups from the table Codec groups, seesection Codec groups).

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

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

Category Advanced settings

Use matching pattern for incom. SDP rtpmap – select the checkbox, if you want to use the Matching

Operating TM

Page 90

pattern for incom. SDP rtpmap parameter for matching the codec indicated in the * Codec field withthe incoming codec from the equipment. Otherwise the System will not match the codecs against theSDP rtpmap.

Matching pattern for incom. SDP rtpmap – specify a regular expression, used to match the codecindicated in the * Codec field with the incoming codec from the equipment, when the incoming codechas a nonstandard mime type in the SDP rtpmap parameter. If the check box Use matching pattern forincom. SDP rtpmap is selected, but no regular expression is entered, the SDP should contain nortpmap attribute for the System to match these codecs.

Use matching patterns for incom. SDP fmtp – select the checkbox, if you want to use the Matchingpattern for incom. SDP fmtp parameter for matching the codec indicated in the * Codec field with theincoming codec from the equipment. Otherwise the System will not match the codecs against the SDPfmtp.

Matching patterns for incom. SDP fmtp – enter a regular expression, used to match the codecindicated in the * Codec field with the incoming codec from the equipment, when the incoming codechas nonstandard SDP fmtp parameters. If the check box Use matching patterns for incom. SDP fmtpis selected, but no regular expressions are entered, the SDP should contain no fmtp parameters for theSystem to match these codecs.

The regular expression must comply with Python Regular Expression Syntax and should notcontain “^” and “$” symbols. The regular expression is compared against the whole rtpmap fieldbut not its substrings. This means that a regular expression G\.729[a]? will match rtpmap withthe value G.729 or G.729.a, but not with the values XG.729 or G.729ab, though it matchessome of their substrings.

Substitution string for out. SDP rtpmap – specify a mime type sent to the gateway in the SDP rtpmapattribute.

Substitution strings for out. SDP fmtp – specify strings sent to the gateway as SDP fmtp parameters.

Unlike in RFC 3555, by default the System recognizes the G.729 codec with no AnnexB parameteras G.729 plain and not G.729B. If the support of equipment that follows RFC 3555 and does notsend AnnexB is required, select the Use matching patterns for incom. SDP fmtp check box and leavethe Matching patterns for incom. SDP fmtp field blank.

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 similarfashion you can add other codecs to the groups.

CPS limitation5.2.7

This table allows the user to limit incoming CPS from a specific IP address. To add a limitation, left-click the mouse on a table record and select Add in the pop-up menu.

Adding new incoming CPS limitation

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

* Subnetwork address – IP address or subnet mask from which the CPS is limited.

* Max CPS – maximum incoming CPS from the IP address specified.

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 similarfashion you can add other codecs to the groups.

Operating TM

Page 91

Balancing groups5.2.8

This table comprises a list of balancing groups, defined in the System. To create a new balancinggroup record, invoke the pop-up menu and select Add. For further information about the balancinggroups refer to section Balancing groups.

Declaring a balancing group

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

* Balancing group name – define the name of the balancing group. The name should match a namespecified in the balancing section of TS configuration (see section Balancing groups).

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

Termination5.3

Pre-routing translations5.3.1

The object Pre-routing number transformation serves to configure number transformation rules thatallow 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 mayrequire a number of successively applied rules. The order in which number transformation rules areapplied is determined by the rule precedence.

To see if the number needs transformation, it is checked against regular expression patterns. Thenumber is subject to transformation if it matches the pattern defined in the fields Allowed SRCnumbers pattern, Allowed DST numbers pattern, Allowed SRC groups and Allowed CPC andmismatches the pattern defined in Exclude SRC numbers, Exclude DST numbers, Disallowed SRCgroups and Disallowed CPC.

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

Operating TM

Page 92

Table of pre-routing number transformation rules

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

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 theentered value, the more precedence the configured rule takes. The precedence of rules defines theorder in which number transformation rules are applied. Rules with a greater Precedence value areapplied earlier. The list of configured rules is browsed by the system successively which means thatprior to performing a DP search (route hunting) the system applies the number transformation rulesone by one in the order of their precedence.

Operating TM

Page 93

Allowed SRC numbers pattern – enter a regular expression that determines what calling numbersrequire transformation. You can enter several regular expressions delimiting them with «|».

Allowed DST numbers pattern – enter a regular expression that determines what called numbersrequire transformation. You can enter several regular expressions delimiting them with «|».

Allowed original DST numbers pattern – enter a regular expression that determines what originalcalled numbers require transformation. You can enter several regular expressions delimiting them with«|».

Exclude SRC numbers – enter a regular expression that determines what calling numbers do notrequire transformation. You can enter several regular expressions delimiting them with «|». Disallowednumbers override the allowed ones.

Exclude DST numbers – enter a regular expression that determines what called numbers do notrequire transformation. You can enter several regular expressions delimiting them with «|». Disallowednumbers override the allowed ones.

Exclude original DST numbers – enter a regular expression that determines what original callednumbers do not require transformation. You can enter several regular expressions delimiting them with«|». Disallowed numbers override the allowed ones.

Allowed SRC groups – enter the name of the call origination RAS-user group that needstransformation. You can enter several names delimiting them with «;».

Disallowed SRC groups – enter the name of the call origination RAS-user group not subject totransformation. You can enter several names delimiting them with «;». Disallowed groups override theallowed ones.

SRC number translation – enter a regular expression for transformation of the calling number.

SRC number translation (billing) – enter regular expressions for modification of calling numbers asrequired for the purposes of billing.

DST number translation – enter a regular expression allowing the transformation of the callednumber.

DST number translation (billing) – enter regular expressions for modification of called numbers asrequired for the purposes of billing.

Original DST number translation – enter a regular expression allowing the transformation of theoriginal called number.

SRC number translation (SORM) – enter a regular expression pattern for transformation of thecalling number to be sent to a SORM-gateway.

DST number translation (SORM) - enter a regular expression for transformation of the called numberto be sent to a SORM-gateway.

Group name translation – enter a regular expression for transformation of the group name.

Allowed CPC - enter a list of calling party’s categories that determines what calls requiretransformation.

Disallowed CPC – enter a list of calling party’s categories that determines what calls do not requiretransformation. Disallowed categories override the allowed ones.

CPC translation – select the category which replaces the CPC in the call, if the call matches thistranslation rule. If you want to leave the CPC unchanged, select the blank option.

* Action – use the combo box to select a required post-transformation action:

Next. Next means a transition to the next number transformation rule if any.

Stop. Stop means stoppage of the transformation process and call abortion with the localdisconnect code configured in the field Quit with disconnect code. If no code is selected in thefield Quit with disconnect code, the translation process stops, though the call handlingprocess continues.

Again. Again means re-start of the same transformation but applied to the number or groupname obtained as the result of the just performed transformation. The re-started transformationis 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

Operating TM

Page 94

provide when aborting a call in response to the * Action option Stop.

This parameter is valid only when the option Stop is selected in the field * Action.

Scheduling - specify the translation rule activity period with the help of checkboxes. A respectivecontrol, located below, will be enabled upon activation of a specific combobox.

Time of day - a Time of day control will be activated. Specify DP scheduling during every day inthis control.

Day of week - Monday - Sunday controls will be activated. Specify DP scheduling for therespective day of week in each control.

Day of month - a Day of month control will be activated. Specify the DP scheduling for daysduring every month in this control.

Day of year - a Day of year control will be activated. Specify the DP scheduling for every year inthis control.

Once a control is activated, you can add new schedule records using the button. To delete a

schedule record click the button.

Several schedules on the same level are joined together. For example if you specify two schedules inTime of day field - from 0:00 till 6:00 and from 12:00 till 14:00, the translation rule will be active everyday from 0:00 till 6:00 AND from 12:00 till 14:00.

For schedules on different levels (e.g., Day of year and Day of month) the System searches foroverlapping intervals. For example, if you define a schedule by Day of year - from 5th April 0:00 till 5thJune 0:00, and simultaneously by Day of month - from the 1st day 0:00 till the 10th day 0:00, then inApril the translation rule will active only from the 5th to the 10th, and in June from the 1st till the 5th.

The Day of week schedules override the Time of day schedules. For example, if you specify a Time ofday schedule from 9:00 till 18:00 and simultaneously a Day of week - Monday schedule from 6:00 till8:00, then the translation rule will be active from from 6:00 till 8:00 on Monday, and from 9:00 till 18:00on other days.

When done with entering data, press the button OK to add the configured record to the table. TheSystem 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.

Dial peers5.3.2

In terms of RTU a dial peer is an addressable object to which the call can be routed. A dial peer ischaracterized by the name of termination gateway, operating time, and number transformation rules.

Therefore, the table of dial peers can be regarded as a dial plan comprised of records with informationabout possible routing paths for calls originated by static gateways and RAS users.

Table of DPs

While handling a call, the system searches for the best routing path taking into account the length ofthe matching number prefix and the dial peer precedence. The record of the dial peer selected duringroute 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 valueof the parameter * Precedence takes precedence over the other. If the values of the parameterPrecedence for the two DPs are equal as well, the dial peer is selected at random.

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

Operating TM

Page 95

Add dial peer dialog

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

Enabled – select the checkbox to make the record valid.

* Name – enter the DP name.

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

Precedence – enter a positive integer that determines the DP precedence over other suitable for thecall. The integer may be any number in the range of 0 through 65535. A greater number means greaterprecedence. The default value is 100. If two precedence values are equal, the order of selecting dialpeers is undefined.

Routing policy – select the routing policy applied to the dial peer. For further information on routingpolicies see section Routing policies.

* DST prefix allow patterns – use a regular expression to enter a pattern for destination numberprefixes allowed for the DP. When entering several expressions delimit them with semicolons.

Upon completion of the dial peer configuration, the System forms a tree of destination numberpatterns. Each pattern node of the tree is associated with dial peers, where this pattern is used.Suppose 9 dial peers (dp0 - dp8) are configured in the System. The tree of destination number prefixpatterns may then look as shown in the figure below.

Example of destination number regexp patterns tree

Operating TM

Page 96

* Original DST prefix allow patterns – use a regular expression to enter a pattern for originaldestination number prefixes allowed for the DP. When entering several expressions delimit them withsemicolons.

DST prefix deny patterns – use these fields to enter regular expressions that define called numbersdisallowed to use the DP. You can enter several expressions delimiting them with «|». Disallowednumbers override the allowed ones.

Original DST prefix deny patterns – use these fields to enter regular expressions that define originalcalled numbers disallowed to use the DP. You can enter several expressions delimiting them with «|».Disallowed numbers override the allowed ones.

* Equipment list – make a list of gateways available for use when the DP is selected for call

termination. To add a gateway to the list, select its name in the left window pane and click tomove the GW name to the right window. To remove a gateway from the list, highlight its name in the

right window pane and click . The buttons and serve to move all records

between the windows in one click. Use the buttons and to move the gatewayname one line up or down in the list.

If the Balancing method parameter is set to No balancing, RTU attempts to set up a call sequentiallystarting with the first gateway on the list during routing procedure. Otherwise, the order, in which theSystem establishes a connection with the gateways, is determined by the Balancing method.

Balancing method – use the combo box to select a method of load balancing that the System will usewhen distributing traffic between multiple gateways of the dial peer being configured. The availableoptions include:

No balancing means no call balancing by whatever criterion.

Round-robin balancing means that every new call is forwarded to the next gateway in turn.

Balancing by absolute load means that every new call is forwarded to the gateway thatcurrently handles the least number of calls.

Balancing by load-to-capacity ratio means that every new call will be sent to the gateway thatcurrently displays the least ratio of ongoing calls to gateway capacity.

Scripting nodes have independent gateway capacity counters. These counters are not synchronized.That’s why when calls pass trough different scripting nodes, the scripting nodes may independentlyselect the same gateway.

Capacity group – select the name of the common capacity group from the drop-down list. Thegateway will belong to the selected capacity group. For more information about capacity groups seesection Capacity groups.

Capacity – specify the maximum number of simultaneous calls that the DP can handle. If the field isempty or zero is entered, the number of calls is unlimited.

Override number capacity group – select the number capacity group for the SRC numbers. For furtherinformation about number capacity groups see section Number capacity groups.

Enable statistics – when selected, this checkbox enables call statistics keeping for the DP, the data ofwhich can be later used in graph plotting.

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

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

Category Number translation rules

SRC number translation/DST number translation – enter regular expressions for desiredmodification of calling and called numbers respectively.

Original DST number translation – enter regular expressions for desired modification of originalcalled numbers respectively.

SRC number translation (billing)/DST number translation (billing) – enter regular expressions formodification of calling and called numbers as required for the purposes of billing.

Operating TM

Page 97

Category Advanced settings

Allowed SRC number patterns – use a regular expression to enter a pattern for calling numberprefixes suitable for this DP. You can enter several expressions delimiting them with «|».

Denied SRC number patterns – use these fields to enter regular expressions that define callingnumbers disallowed to use the DP. You can enter several expressions delimiting them with «|».Disallowed numbers override the allowed ones.

Allowed SRC groups – enter names of the gateway groups that are allowed call origination.

Disallowed SRC groups – enter names of the gateway groups that are disallowed call origination.Disallowed groups override the allowed ones.

Stop route hunting after this DP – set the checkbox to reduce the number of dial peers selectedthrough exclusion of dial peers located in the tree before the DP with the checkbox.

For example, the System has the dial peer tree shown in the figure below below and the “dp2” has thecheckbox selected. If the call is routed to number 7910792543, initially the “dp5”, “dp6” and “dp7” dialpeers will be discarded (as the number does not match their patterns).

The remaining dial peers are put into a list where the dial peers with more detailed patterns will be puton top. In our example the list will be as follows:

If one of the dial peers has the Stop route hunting after this DP checkbox selected, all DPs below thisDP will be discarded from the list. In our example the “dp2” dial peer has the checkbox activated andthe resulting list will be as follows.

Override equipment proxy mode – this combo box allows you to override the proxying settings of theterminator for situations when RTU interoperates with the DP being configured. The available mediaproxy options include:

Proxy media — always proxy media (the media stream will pass through the softswitch in any

Operating TM

Page 98

case).

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

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

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

Allowed CPC - enter a list of calling party’s categories that determines what calls will be routed to thisDP.

Disallowed CPC – enter a list of calling party’s categories that determines what calls will not berouted to this DP. Disallowed categories override the allowed ones.

CPC translation – select the category which replaces the CPC in the call, if the call is routed to thisDP. If you want to leave the CPC unchanged, select the blank option.

Override report original destination – select the method of reporting the original DST number for thisdial peer. If you do not want to override the method, select the blank option.

Allowed SRC types of numbers – enter a list of SRC number types (NAI) that determines what callswill be routed to this DP.

Disallowed SRC types of numbers – enter a list of SRC number types that determines what calls willnot be routed to this DP. Disallowed categories override the allowed ones.

Allowed DST types of numbers – enter a list of DST number types (NAI) that determines what callswill be routed to this DP.

Disallowed DST types of numbers – enter a list of DST number types that determines what calls willnot be routed to this DP. Disallowed categories override the allowed ones.

Override equipment SRC type of number – select the type of number which replaces the SRC numbertype of the call, if the call is routed to this DP. If you want to leave the SRC number type unchanged,select the blank option.

Allowed SRC screening indicators – enter a list of SRC screening indicators that determines whatcalls will be routed to this DP.

Disallowed SRC screening indicators – enter a list of SRC screening indicators that determines whatcalls will not be routed to this DP. Disallowed categories override the allowed ones.

Override equipment SRC screening indicator – select the screening indicator value which replacesthe SRC screening indicator of the call, if the call is routed to this DP. If you want to leave the SRCscreening indicator unchanged, select the blank option.

Override equipment SRC numbering plan – select the numbering plan which replaces the SRCnumbering plan of the call, if the call is routed to this DP. If you want to leave the SRC numbering planunchanged, select the blank option.

Override equipment DST numbering plan – select the numbering plan which replaces the DSTnumbering plan of the call, if the call is routed to this DP. If you want to leave the DST numbering planunchanged, select the blank option.

Override equipment SRC presentation indicator – select the presentation indicator value whichreplaces the SRC presentation indicator of the call, if the call is routed to this DP. If you want to leavethe SRC presentation indicator unchanged, select the blank option.

Override codec change policy - select the codec change policy if the call is routed to this DP. If youwant to leave the codec change policy unchanged, select the blank option.

Category Schedule

Scheduling - specify the DP's activity period with the help of checkboxes. A respective control,located below, will be enabled upon activation of a specific combobox.

Time of day - a Time of day control will be activated. Specify DP scheduling during every day inthis control.

Day of week - Monday - Sunday controls will be activated. Specify DP scheduling for therespective day of week in each control.

Operating TM

Page 99

Day of month - a Day of month control will be activated. Specify the DP scheduling for daysduring every month in this control.

Day of year - a Day of year control will be activated. Specify the DP scheduling for every year inthis control.

Once a control is activated, you can add new schedule records using the button. To delete a

schedule record click the button.

Several schedules on the same level are joined together. For example if you specify two schedules inTime of day field - from 0:00 till 6:00 and from 12:00 till 14:00, the DP will be active every day from 0:00till 6:00 AND from 12:00 till 14:00.

For schedules on different levels (e.g., Day of year and Day of month) the System searches foroverlapping intervals.

For example, if you define a schedule by Day of year - from 5th April 0:00 till 5th June 0:00, andsimultaneously by Day of month - from the 1st day 0:00 till the 10th day 0:00, then in April the DP willactive only from the 5th to the 10th, and in June from the 1st till the 5th.

The Day of week schedules override the Time of day schedules. For example, if you specify a Time ofday schedule from 9:00 till 18:00 and simultaneously a Day of week - Monday schedule from 6:00 till8:00, then the DP will be active from from 6:00 till 8:00 on Monday, and from 9:00 till 18:00 on otherdays.

Press the OK button, when through with data entering,. The newly configured DP record will beadded to the table of DPs with a unique ID generated by the System and the record creation datedisplayed in the column Timestamp.

To edit, view or delete a record, select the respective item in the pop-up menu.

Routing policies5.3.3

The table “Routing policies” presents a list of route hunting policies based on statistical data for dialpeers.

Table with a list of available routing policies

Policy routing, as implemented in the RTU system, is based on statistical data that characterize thepath the call will take to get to its final destination.

The RTU standard route hunting is based on the destination number of the call. The softswitchselects several dial peers the regexp destination number patterns of which match the destinationnumber of the routed call and sorts the selected path alternatives by the degree to which thedestination number pattern matches the called number. As a result DPs with the destination numberpattern best matching the destination number of the call are in the beginning of the sorted list.

When it is necessary to take into account additional properties of a potential route the list of selecteddial peers is additionally sorted in the ascending order by the numerical value that reflects thestatistics taken into account (ASR or PDD, for example). I.e. the dial peers with the smaller result of the

Operating TM

Page 100

routing policy expression are put to the top of the dial peer list.

If it is necessary to sort the DP list in the descending order (so that the DPs with the greater result ofthe routing policy go to the beginning of the list), use the following formula:

1/(f(x)*0.00000000001), where

f(x) - the original expression in the routing policy.

Therefore, to define a statistics-based routing policy means to define a statistical parameter by whichthe list of potential routing paths will be additionally sorted.

The list of statistical parameters that can be used in policy routing and their symbolic representationsis given in the table below. Note that the parameters apply only to the dial peers where theseparameters were used as part of a routing policy.

Symbolic representation of statistical data used in configuring routing policies.

Symbolicrepresentation

Parameter

priority DP precedence setting

qos Quality of service. RTU calculates QoS as a ratio of packets lost to total packetstransferred, i.e. the smaller is the calculated QoS value, the better is QoS.

pdd Post Dial Delay. RTU calculates PDD as the time interval between the receipt ofSETUP from the originator and the moment the ALERT, CONNECT orProgressIndicator = 8 (i.e. ProgressInbandInformationAvailable) is received from theterminating party.

asr Standard or conventional ASR (answer seizure ratio). The standard ASR is calculatedas the ratio of the total number of non-zero duration calls to total number of calls.

acd Average Call Duration.

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

cps Calls per Second..

maxActCalls Peak number of active calls

totalCallsDuration

Aggregate duration of all calls

normalCalls Number of successful calls

failedCalls Number of failed calls

totalCalls Aggregate number of all calls

outBytes Total number of bytes sent during all calls

inBytes Total number of bytes received during all calls

actCalls Number of active calls

To define a routing policy right-click the mouse to invoke the contextual menu and select Add. Fill out

Operating TM

Page 101

the displayed form entering the policy name in the edit box * Name and an expression that returns anumerical value for the policy in the edit box * Expression.

The values that you enter in the field * Expression must conform to the format <dp.parameter_name>where parameter_name is one of the symbolic representations from the table above. Expressionsentered in the field * Expression must be a valid expression of the programming language Python. Forexample, the ASR-based rouing policy is defined by entering dp.asr in the field * Expression while therouting policy based on total number of sent and received bytes for all calls can be defined by theexpression dp.inBytes + dp.outBytes.

Routing policy form

The table “Routing policies” allows verification of entered expressions. Press the Check expressionbutton appearing to the right of the just entered value to see if the expression is a valid one. Asuccessful validation results in the the expression font changing to green and the validity flag Yesappearing next to the expression.

Mistyped expression requiring a validity check

To correct a mistyped expression switch to edit mode, make the necessary correction and press theCheck expression button again.

Corrected expression after validity check

Tree of Dial Peers (DPs)5.3.4

A dial peer tree visually represents the routing patterns for all dial peers specified in the Systemwhether these dial peers are explicitly declared in the Dial peer table, or implicitly generated by theSystem one an endpoint is created (gateway Equipment type = Endpoint), or created automaticallyupon equipment’s registration with the System

The initial view of the tree is shown in the figure below.

Operating TM

Page 102

Dial peer tree view

To visualize the required branch of the dial peer tree use the Prefix text field. The valid characters forthe text field are digits and the # character. If any other character was entered into the DST prefixallow patterns, the System will stop displaying this branch of the tree.

Once the digits are entered click the Show dial peer tree button. The selected branch will be expandedup to the position of the last digit in the prefix.

Expanded dial peer tree

To achieve the same effect consecutively expand the tree by pressing the ‘+’ icon next to the prefixdigits.

Once the prefix is fully entered the System will show a fully expanded tree branch. The vertex of thebranch will display the dial peers corresponding to the prefix; their number, associated gateways orendpoints, as well as hyperlinks to their records.

Operating TM

Page 103

The vertex of an expanded DP tree branch

If the checkbox Show results of previous queries is activated, the System stores the results ofprevious queries and expands not only the branch corresponding to the current prefix entered, butalso the branches for previously entered prefixes.

Using the links next to the object names in the tree, you can go to dial peer, gateway or endpointtables.

Debugging5.4

The category of objects Debugging comprises four tables – the table Call simulation, the table Debugregistration and the table Debug calls.

Call simulation5.4.1

The object Call simulation allows you to simulate calls with the end to check the Systemconfiguration and during troubleshooting in situations when customers or partners complain ofimproper System functioning.

Operating TM

Page 104

Call simulation dialog

To simulate a call enter the following parameters in the Call simulation dialog:

* Scripting node – select the scripting node, which will be used to simulate the call.

Zone – if the SS7 protocol is used to simulate the call, select the zone which acts as an originator’saddress. In case of other protocols this combo box is invalid.

Balancing group – if you simulate calls over Internal protocol, from the dropdown list select thebalancing group that will be used as an originator’s address. This dropdown list is invalid for otherprotocols.

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

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

SRC number and * DST number - enter a calling and called number in respective edit boxes.

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

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

Calling party’s category – select the calling party’s category as if it were present in the incoming leg.

Press OK.

Operating TM

Page 105

Call simulation results

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

Debug calls5.4.2

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

If the number of simultaneous calls exceeds 7-9, delays may occur when viewing the debug calls.

To view an individual call log record, select the View item on the pop-up menu.

Call progress log header when viewed from table Debug calls

The parameters of the debug call are identical to those present in the CDR table (see section CDRs).

ID – unique ID of the record.

Incoming SRC number – calling number as received from the call source.

Incoming DST number – destination number as received from the call source.

Outgoing SRC number – calling number after transformation according to the configured numbertranslation rules.

Outgoing DST number – destination number after transformation according to the configured numbertranslation rules.

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

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

Setup time – timestamp of the call setup.

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

Operating TM

Page 106

leg + outgoing call leg).

To view the call log of interest invoke the pop-up menu and select the Get call log item in the Specialfunction section.

Invoking the call log for viewing

You will be displayed the call log page that presents the call log header followed by a table of packetsexchanged during the call.

Operating TM

Page 107

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 ratherthan spread out the entire packet.

Using partial expansion control for contents viewing

Operating TM

Page 108

Debug registrations5.4.3

The table Debug registrations contains records about debug registrations of regestering equipment.

The maximum number of records in the tables is defined by the global setting Max. debug call/registration sessions (see section System global settings).

If the number of entries is large, use a filter to find necessary records.

ID – unique ID of the record.

Registration username – login of the registered device.

Phone number – name/number/alias of the registered device.

Signaling address – originator’s IP address, used for signaling.

Signaling protocol - protocol used by the registered device.

Registration time – date and time of the registration.

Registration ID – TS registration ID.

Traffic Switch5.5

Operating TM

Page 109

This subcategory of objects allows real-time monitoring of the System operation and providesinformation about equipment registrations, currently handled calls, system sockets, etc. The operatorcan view summarized information or detailed information about the operation status of every Systemcomponent.

TS CLASS 4 conferences5.5.1

The table TM CLASS 4 conferences contains information about CLASS 4 calls currently handled bythe TS.

Each record provides the following data:

Connect time – timestamp of the call connect.

In-call time – call duration in milliseconds.

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

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

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



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

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

Outgoing leg protocol – signaling protocol used on the outgoing call leg.


Outgoing DST number – destination number after transformation done according to the configurednumber translation rules.

The user is also able to cancel calls in the web interface. Invoke the context menu on the requiredconference record and select the Delete option. The respective call will be terminated.

TM CLASS 4 calls5.5.2

The table TM CLASS 4 calls comprise data on the current CLASS 4 calls, handled by the TM. Thetable contains information collected from all scripting nodes.

Each record comprises the following information:

TS Conference ID – Conf ID, generated by the TS.

Protocol Conference ID – Conf ID, obtained from the protocol messages.

Call State – current call state.

Originator ID – ID of the originator DB record.

Originator name – name of the originator in the DB.

Incoming leg protocol – signaling protocol on the incoming leg.

Incoming SRC number – SRC number on the incoming leg, before number translations.

Incoming DST number – DST number on the incoming leg, before number translations.

SETUP time – time of SETUP message arrival.

CONNECT time – time of CONNECT message arrival.

In-call time – general call duration.

Dial peer – dial peer, through which the call was routed.

Terminator ID – ID of the terminator DB record.

Terminator name – name of the terminator in the DB.

Operating TM

Page 110

Outgoing leg protocol – signaling protocol on the outgoing leg.

Outgoing SRC number – SRC number on the outgoing leg, after all number translations.

Outgoing DST number – DST number on the outgoing leg, after all number translations.

The user is also able to cancel calls in the web interface. Invoke the context menu on the required callrecord and select the Delete option. The respective call will be terminated.

TS CLASS 5 legs5.5.3

In RTU the table TS CLASS 5 legs comprises data on the call legs, that are handled by the RTU Class5 component. These are incoming calls legs (relative to RTU Class 5 component) - to the RTU Class 5,and outgoing call legs - from RTU Class 5. The table fills with data only when calls are processed bythe RTU Class 5 component.


Connect time – time of CONNECT message arrival.

In-call time – general call duration.

Incoming leg call ID – call ID on the incoming leg (valid for the incoming call leg only).

Remote orig. signaling address – originator's IP address (if the call comes to the RTU Class 5 from anendpoint) or balancing group name as string://<name> (if the call come to the RTU Class 5 fromthe TM component). Valid for the incoming call leg only.

Incoming leg protocol – signaling protocol on the incoming leg(valid for the incoming call leg only).

Incoming SRC number – SRC number on the incoming leg (valid for the incoming call leg only).

Incoming DST number – DST number on the incoming leg (valid for the incoming call leg only).

Outgoing leg call ID – call ID on the outgoing leg (valid for the outgoing call leg only).

Remote term. signaling address – terminator's IP address (if the call goes from the RTU Class 5 to anendpoint) or balancing group name as string://<name> (if the call goes from the RTU Class 5 tothe TM component). Valid for the outgoing call leg only.

Outgoing leg protocol – signaling protocol on the outgoing leg (отобрvalid for the outgoing call legonly).

Outgoing SRC number – SRC number on the outgoing leg (valid for the outgoing call leg only).

Outgoing DST number – DST number on the outgoing leg (valid for the outgoing call leg only).

The user is also able to cancel calls in the web interface. Invoke the context menu on the required callleg record and select the Delete option. The respective call leg will be terminated. If necessary thecorresponding second call leg will be deleted as well.

Operating TM

Page 111

TS incoming registrations5.5.4

This object comprises data on the devices registered with the TS.


Registration ID – unique registration ID, assigned by the TS.

Protocol – protocol that the registered device uses.

Username – name of the registered device.

Address – IP address of the device;

State – registration state:

Initial (the registration process has started, but not yet completed).

Passed (registration completed, the gateway is registered).

Re-registration (complete re-registration of the devices is pending).

Unknown (gateway registration status is unknown).

Unregistering (gateway is unregistering).

TTL, sec – timeout after which the complete re-registration takes place.

Aliases – names/numbers, received in the registration message.

Expiration – time when the registration expires.

TM incoming registrations5.5.5

This object comprises data on the devices registered with the TM. The table contains informationcollected from all scripting nodes.


Registration ID – registration ID.

Gateway ID – database record ID of the registering gateway.

Gateway name – name of registering gateway in the DB.

Protocol – protocol that the registered device uses.

Username – name of the registered device.

Node – scripting node that received the registration message.

Operating TM

Page 112

Nodes5.5.6

This subcategory provides detailed information about operation status of the TS nodes distributed byseparate 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 TSconfiguration file(-s).

For brevity sake let us consider a system with one module of each type running (imaginary names ofmodules are in angle brackets). All modules have the following objects:

IP zones - sockets that are open on the node.

Protocols - protocols used to connect this node with others.

Counters – information about system counters.

The object IP zones includes the following information:

Remote node – name of the remote node, to which this node is connected.

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

Local address – IP address of the local socket, which establishes a remote connection.

Remote address – IP address of the remote socket, receiving connection from the locallyconnected socket. If the remote address is 0.0.0.0, this means that the local socket is waiting foran incoming connection.

The object Protocols includes the following information:

Protocol - the name of protocol under which the node operates

Local address – IP address of the local socket, which establishes a remote connection.

Remote address – IP address of the remote socket, receiving connection from the locallyconnected socket. If the remote address is 0.0.0.0, this means that the local socket is waiting foran incoming connection.

The object Counters includes the following information:

Name – the name of the system counter.

Value – the value of the system counter.

<Management>

This sub-directory includes the objects IP zones, Protocols and Counters that deliver statisticalinformation pertaining to the Management node.

<Signaling>

This object provides statistical information about the signaling node. In addition to the commonobjects IP zones, Protocols and Counters it shows: TS CLASS 4 conferences – data on the currentCLASS 4 calls handled by the node (see TS CLASS 4 conferences).

TS CLASS 5 legs – data on the CLASS 5 call legs, handled by the node (see TS CLASS 5 legs).

Operating TM

Page 113

<Balanacer>

This object is a repository of statistical information about the H.323 gatekeeper/balancer module.Apart from the common objects IP zones, Protocols and Counters, the object includes the tableRegistrations showing information about registered devices.

Registrations – data on the registered devices (see TS incoming registrations).

<Media>

This folder contains operational statistics pertaining to the Media node and includes the objects IPzones, Protocols and Counters.

<Scripting>

This folder contains operational statistics pertaining to the Scripting node and includes the objects IPzones, Protocols and Counters.

Registrations – data on the registered devices, handled by the specific scripting node (see TMincoming registrations).

Calls – data on the calls handled by the specific scripting node (see TM CLASS 4 calls).

<Synchro>

This folder displays the Synchro node operational statistics contained in the objects IP zones,Protocols and Counters.

<SS7-node>

This folder contains operational statistics pertaining to the SS7 Call Agent node and includes thecommon objects IP zones, Protocols and Counters.

Active nodes5.5.7

The table Active nodes comprises the names of all active nodes in the system (column Name) and theiruptime (column Uptime).

SS7 calls5.5.8

This table comprises the information about the SS7 calls, passing through a SS7 Call Agent node.

Each record includes the following fields:

SS7 calls

Call ID – unique identifier of the call.

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

Calling Party ID – ID of the calling party.

Operating TM

Page 114

Called Party ID – ID of the called party.

Circuit ID – ID of the media circuit in an E1 trunk in the form of <hw_id>-<span_id>-<timeslot>,where <hw_id> - media gateway ID, to which the E1 circuits are connected, <span_id> - ID of an E1trunk as part of the ISUP connection, <timeslot> - timeslot of in the E1 trunk.

Circuit group ID – ID of a circuit group, to which the current media circuit belongs.

SS7 zone – a SS7 zone to which the call (call leg) belongs.

ISUP circuits5.5.9

This table comprises the information about the state of media circuit, which a part of an ISUPconnection.


ISUP circuits


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

Circuit ID – ID of the media circuit in an E1 trunk in the form of <hw_id>-<span_id>-<timeslot>,where <hw_id> - media gateway ID, to which the E1 circuits are connected, <span_id> - ID of an E1trunk as part of the ISUP connection, <timeslot> - timeslot of in the E1 trunk.

Circuit group ID – ID of a circuit group, to which the current media circuit belongs.

ISUP circuit label – circuit label in the form <LPC>-<RPC>-<cic>-<ni>, where <LPC> - local pointcode, <RPC> - remote point code, <cic> - media circuit code, <ni> - network indicator code.

Incoming connection – shows if the circuit is used for incoming traffic.

Outgoing connection – shows if the circuit is used for outgoing traffic.

Circuit state – current state of the circuit.

Local circuit block state (maintenance) – state of the local media circuit block of type maintenanceoriented.

Local circuit block state (hardware) – state of the local media circuit block of type hardware oriented.

Remote circuit block state (maintenance) – state of the remote media circuit block of typemaintenance oriented.

Operating TM

Page 115

Remote circuit block state (maintenance) – state of the remote media circuit block of type hardwareoriented.

Zone – SS7 zone to which the media circuit pertains.

To change the state of the circuit invoke the pop-up menu on the required record and select thedesired procedure. Available procedures:

Block – locally blocks the circuit using the maintenance oriented block type.

Unblock – locally unblocks the circuit using the maintenance oriented block type.

Reset state – sets the circuit state to Idle and sends a Reset Circuits message to a remote SS7switch .

MGCP endpoints5.5.10

This table comprises the information about the MGCP endpoints.


MGCP endpoints

SS7 media gateway ID – ID of the MGCP gateway.

E1 trunk ID – ID of the E1 trunk, connected to the media gateway.

Endpoint ID – ID of the MGCP endpoint.

Endpoint state – state of the MGCP endpoint.

Endpoint name – name of the MGCP endpoint.


M3UA associations5.5.11

This table comprises the information about the M3UA SCTP associations.


M3UA associations

Operating TM

Page 116

M3UA association ID – ID of the M3UA SCTP association.

Association status – status of the SCTP-association.

Local endpoint ID – ID of the local SCTP endpoint.

Remote endpoint ID – ID of the remote SCTP-endpoint.

Number of incoming SCTP-streams – number of incoming SCTP streams.

Number of outgoing SCTP-streams – number of outgoing SCTP streams.

Reserved circuit groups5.5.12

This table comprises information about reserved circuit groups.


Group ID – the ID of the reserved circuit group.

Number of elements – number of elements in the group.

Circuit hunting policy – the method for selecting an unassigned circuit for the outgoing call.

State – state of the circuit group.

CDRs5.6

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

In the table Last 1000 CDRs only the last 1000 call detail records are stored, which can decreaseinterface latency in case of a large DB.

The table Inaccurate comprises CDRs created after a signaling or scripting node crash.

Operating TM

Page 117

When the free space in the DB and on the local HDD is exhausted, the System stops handling calls.To avoid such a situation, remove obsolete CDRs from the DB. A method to remove CDRs from thedatabase is described in Appendix F. Removing CDRs from the DB.

Besides the System features an ability to create CDRs not after call termination or call attempt, butalso while the call passes therough the System. The interim CDRs created in such a way are enteredinto the DB at specified intervals. To enable this feature set the CDR interims enabled parameter inthe System global settings to 1 and specify the period for creating interim CDRs in the Interimsperiod parameter. However, this mode causes additional load to the DB when reduces general systemperformance.

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

Viewing a CDR record

CDRs may contain the following information:

ID – the unique identifier of the record.

CDR date – date of the record creation.

The value of CDR date field depends on the Value for "Date" field in CDR: 1 - Setup time, 2 -Disconnect time parameter in the Global settings object. If the parameter is equal to 1, then value ofCDR date means the setup time of the call; if it is equal to 2, the value of CDR date means thedisconnect time of the call.

Record type – if the CDR is an intermediate one, the parameter comprises its type:

Start – the CDR created at the beginning of the call.

Interim <number> – interim CDR and its number. Such CDRs are created at regular intervalsdefined by the Interims period parameter.

Final – final CDR created at the end of the call.

If the System is configured not to create CDRs the CDRs will have Final type.

Operating TM

Page 118




Outgoing DST number – destination number after transformation according to the configured numbertranslation rules.

Billing SRC number – calling number used for the purposes of billing.

Billing DST number – destination number used for the purposes of billing.

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

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

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

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

Remote orig. media address – media IP address and port of the call originator. Several addresses maybe stored.

Remote term. media address – media IP address and port of the call terminator. Several addressesmay be stored.

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

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

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

Local term. media address – IP address and port of the media node used on the outgoing leg. Severaladdresses may be stored.

Incoming leg protocol – signaling protocol of the incoming leg.

Outgoing leg protocol – signaling protocol of the outgoing leg.

TS Conference ID – unique identifier of the conference the call was a party to (conference = incomingcall leg + outgoing call leg), generated by the TS.

TS Incoming leg call ID – call ID, generated by the TS, on the incoming leg.

TS Outgoing leg call ID – call ID, generated by the TS, on the outgoing leg.

Protocol Conference ID – unique identifier of the conference the call was a party to (conference =incoming call leg + outgoing call leg), received in the protocol messages.

Protocol Incoming leg call ID – call ID, received in the protocol messages, on the incoming leg.

Protocol Outgoing leg call ID – call ID, received in the protocol messages, on the outgoing leg.

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

Term. registration username – registration username of the call terminator.

RADIUS username – username sent to the external RADIUS server.

Origination gateway – name of the origination gateway.

Termination gateway – name of the termination gateway.

Dial peer – name of the dial peer.

In?call time – 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

Operating TM

Page 119

mechanism.

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

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

DST Tunneling present – “Yes” indicates that the termination gateway accepted the use of thetunneling 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 orbetween SETUP and ReleaseComplete (if no CONNECT was received).

PDD, msec – time interval between receipt of SETUP from the call originator and receipt of Alert orConnect or ProgressIndicator=8 (ProgressInbandInformationAvailable) from the terminating party.

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

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

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

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

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

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

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

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

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

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

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

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

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

Term. max. jitter buffer size (packets) – maximum jitter buffer size when receiving packets from thecall termination party.

Last CDR – «Yes» in this field means that this record is the last one among all records associatedwith the specific call.

CDRs are written for all call attempts irrespective of their success, and the state of this flag gives apossibility to determine if this record should be fed into the billing system.

Q.850 Reason – disconnect reason code from the SIP Reason header. The code is received from aH.323 gateway, sitting behind a SIP device.

Incoming leg CPC – the calling party category as received by the System from the calling gateway.

Outgoing leg CPC -the calling party category sent by the System to the called gateway.

When transforming the calling party category from one standard into another (e.g. CPC into OLI orvice versa), this parameter stores the category before such transformation occurs.

Pass “From” to Term. GW – the flag showing that the System sent IP address and port of theoriginator in the “From” field of the INVITE message. For further information see the Cancel SRCnumber translations; Put Orig. address in "From" parameter (section Equipment).

Orig. zone – zone of the gateway from which the call originated.

Term. zone – zone of the gateway where the call was terminated.

Operating TM

Page 120

Disconnect initiator – the party which initiated call disconnect.

Redirecting number – the value of the diversion/RedirectingNumber field from the incoming call leg.

Incoming SRC number type – incoming type of the SRC number.

Incoming DST number type – incoming type of the DST number.

Outgoing SRC number type – outgoing type of the SRC number.

Outgoing DST number type – outgoing type of the DST number.

Incoming original DST number – incoming original DST number.

Outgoing original DST number – outgoing original DST number.

Aux. SRC disconnect codes – auxiliary disconnect codes sent to the incoming call leg.

Aux. DST disconnect codes – auxiliary disconnect codes sent to the outgoing call leg.

Using the special function of the context menu it is possible to invoke a debug call log for this CDR. Ifthe CDR was entered into the DB while debug logging was turned on, you will be able to view allmessages pertaining to the call in the debug call log.

CDRs scheduled export5.6.1

The object Scheduled export in the category Export CDRs allows you to configure unattended exportof call detail records by means of the cron scheduler. CDR export is possible in a plain-text and CSVfile.

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

CDRs scheduled export form

The configuration parameters on the Export CDRs form have the following intent and particulars:

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

* Export period – frequency of CDRs export. This parameter also determines the size of periodic CDRs

Operating TM

Page 121

selection for export.

* Timezone – choose the desired time zone that will be used for CDR selection during scheduledexport. The System selects CDRs for export by the DB date, which may not coincide with the Systemdate in the web-interface.

Default DB time zone is UTC.

Starting date – the starting date of export.

Min. age of export CDRs – shows the age of CDRs intended for export. In other words, this fieldshows the time difference between the cron job start time and the time stamp of the CDR to beexported in the HH::MM::SS notation. If this difference is less that the parameter value for any CDR,this CDR will not be exported. Moreover, if the min. age period completely or partially overlaps with anexport period, the System blocks export of CDRs for the whole period.

For example, if Export period = 1 hour, Min. age of export CDRs = 30 minutes, and the exportprocedure launched at 12:00, the CDR export will be blocked not only for 11:30-12:00 period, but alsofor 11:00-12:00 period.

Indication of minimum CDR age is necessary to avoid export of incomplete CDRs for calls that arestill under way at the time of the cron job start.

By this means, the System launches auto export with the frequency, determined by the Export periodparameter, and exports non-exported CDRs, belonging to previous periods (the length of which isagain determined by the same Export period parameter). CDRs with the date earlier than the value ofthe Date begin parameter, and CDRs falling in the interval that is fully or partially covered by theperiod set in the Min. age of export CDRs are not exported. If the scheduled export is configured inthe following way:

Interval size = 1 hour.

Date begin = 9:00.

Min. age of export CDRs = 00:30:00 (30 minutes),

and the cron job starts at 12:00, then cron exports CDRs, starting from 10:00 till 11:00, and the non-exported CDRs from the 9:00-10:00 period. CDRs in the interval 11:00-12:00 are not exported, as thisinterval is within the range set by the Min. age of export CDRs parameter. Later, at 13:00 cron exportsCDRs fitting within the 11:00-12:00 interval, as well as non-exported CDRs with the timestamp earlierthan 11:00.

If the interval size is set to a value less than 1 hour, the System exports CDRs within some interval atthe end of the next interval.

Export fields – windows that allow you to change the content of export CDRs and the arrangement ofdata in them.

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 thebeginning of the CDR). If you wish to customize the makeup and arrangement of information inexported CDRs, select the necessary data and click the left-arrow button to transfer the selected itemsto the left window. The double-arrow button serves to move all items indiscriminately between the

Operating TM

Page 122

windows. The and buttons allow arrangement of data items in CDRs. Moving anitem 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 theend of the record.

* Save to – indicates the location where exported CDR files will be saved. Two possible optionsinclude:

file system locally. This option allows file saving to the HDD or external media mounted on thefile system of the DB server.

FTP server. This option provides for saving exported CDRs to a remote FTP machine.

Export directory – sets a directory where CDR files will be saved.

When specifying a directory for CDR files the administrator must remember that the www-data userin the name of which file saving is done must possess writing rights for that directory

Enable post-processing – activate checkbox to enable the post-processing of the exported CDRs. Seesection CDR post-processing for details.

* 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 ofseveral 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 fileviewable in Microsoft Excel™.

Enable post-processing – select the checkbox to post-process the exported CDRs. For furtherinformation refer to section 6.6.3.

Category General settings

Date format – defines format for dates. Entries should be done in MySQL notation, for example, theentry «%Y-%m-%d %H:%i:%s» corresponds to a date of the type «YYYY-MM-DD HH:MM:SS».

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

Export zero duration CDRs – select the checkbox to export CDRs representing zero duration calls.

* Show call duration in – select a method of presenting call duration in exported CDRs from thecombo box.

Max. number of CDRs per file – sets maximum permissible quantity of CDRs per file.

If actual values happen to be in excess of those defined in the fields Max. number of CDRs per filethe system creates additional export files with index _1,_2 etc in the filename. For example,[filename]_1.csv(or .txt), [filename]_2.csv(or .txt);

Export IP addresses with ports – select the checkbox to export IP addresses of the originator andterminator with ports used for signaling.

Category MVTS-1 format settings

MVTS-1. Leading distinguisher – this field allows you to enter a distinctive character string that willprecede all CDRs in the export file (MVTS 1 format).

MVTS-1. Put date in the beginning – activate the checkbox to export CDRs with the date in thebeginning (MVTS-1 format).

MVTS-1. Export blank fields – activate the checkbox to export fields that can not be filled out in theexported CDRs. (Valid when using MVTS-1 format).

Category CSV format settings

Include headers in CSV file – selection of this checkbox causes inclusion of data fields headers in

Operating TM

Page 123

exported CDRs.

This setting is valid only when CSV is selected as the export format, that is the parameter Exportformat is set to CSV.

CSV. Quotation marks – allows selection of single or double quotes (or none at all) that enclose CDRdata in the export file.

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

Category Substitution settings

Find in fields – specify the string to be searched for in the exported CDR fields. This string will bereplaced by the value of the Replace with parameter.

Replace with – specify the string which will replace the string of the Find in fields parameter.

For example, if the Find in fields parameter = 111 and the Replace with parameter = 222, during theexport procedure the System will replace 111 with 222 in the exported fields of the call detail records.

Category File settings

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

Save empty files – with this check box selected an empty file will be saved if no new CDRs have beengenerated since the latest launch of the cron export job.

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

CDR filename postfix – a string of characters that will be concatenated to the filename, extensionincluded.

Add sequence number – select the checkbox to add a unique sequence number to the file name. Thesequence number is incremented even when the checkbox is deselected. When the number exceeds999999 it is reset to 000000 and the incrementation process starts anew. The sequence number isinserted between the postfix and the timestamp of the file.

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

first CDR. Use the time stamp of the first CDR in the file in filename generation.

last CDR. Use the time stamp of the last CDR in the file in filename generation.

Filename template– defines the template of filenames for exported CDRs. Entries should be done inthe MySQL notation, for example, the entry “%Y-%m-%d %H:%i:%s” corresponds to a date of thetype “YYYY-MM-DD HH:MM:SS”. By default, the value is “%Y%m%d_%H%i%s”. The table belowshows the list of allowed specifiers.

Filename format specifiers

Specifier Description

%d Day of the month, numeric (00..31)

%H Hour (00..23)

%i Minutes, numeric (00..59)

%j Day of year (001..366)

%k Hour (0..23)

%m Month, numeric (00..12)

%s Seconds (00..59)

Operating TM

Page 124

Specifier Description

%u Week (00..53), where Monday is the first day of the week

%w Day of the week (0=Sunday..6=Saturday)

%Y Year, numeric, four digits

%y Year, numeric (two digits)

The name of the file to which exported CDRs are saved is generated in the format PDS, where

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

D - timestamp of export, formatted in keeping with Filename template field.

S - character string, entered in the field CDR filename postfix.

When no new CDRs have appeared since the latest cron job execution and the checkbox Save emptyfiles is selected, the time stamp for the D part of the file name is the server’s system time.

File mask – file access rights, specified as 4 octal digits.

Category FTP settings

FTP server: address – name of FTP server and directory for saving CDR files (e.g. ftp://cdr.storage.machine/CDRs/export).

FTP server: login – login name for access to the FTP server.

FTP server: password – access password for the FTP server.

FTP passive mode – select this checkbox to enable interworking with the FTP server in the passivemode.

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

When through with filling out the form click OK to create a cron job. The newly created cron job isactually a crontab for the user www-data.

The correspondence of field names in the exported files to the field names in the CDRs is listed in thefollowing table.

Correspondence of the file fields and CDR fields

Field name in thefile

Field name in theCDR

Value type (maxlength)

Valid values

cdr_id ID Integer

cdr_date CDR date Date/time

record_type Record type String (100)

in_ani Incoming SRC number String (100)

in_dnis Incoming DST number String (100)

out_ani Outgoing SRC number String (100)

Operating TM

Page 125

out_dnis Outgoing DST number String (100)

bill_ani Billing SRC number String (100)

bill_dnis Billing DST number String (100)

sig_node_name Signaling node String (100)

src_gatekeeper_address

Remote orig. GKaddress

String (21)

remote_src_sig_address

Remote orig. signalingaddress

String (21)

remote_dst_sig_address

Remote term. signalingaddress

String (21)

remote_src_media_address

Remote orig. mediaaddress

String (100)

remote_dst_media_address

Remote term. mediaaddress

String (100)

local_src_sig_address

Local orig. signalingaddress

String (21)

local_dst_sig_address

Local term. signalingaddress

String (21)

local_src_media_address

Local orig. mediaaddress

String (100)

local_dst_media_address

Local term. mediaaddress

String (100)

in_leg_proto Incoming leg protocol String h323: H.323

sip: SIP

sip-t: SIP-T

ss7: SS7

internal: Internal

out_leg_proto Outgoing leg protocol String h323: H.323

sip: SIP

sip-t: SIP-T

ss7: SS7

internal: Internal

conf_id TS Conference ID String (100)

in_leg_call_id TS Incoming call ID String (100)

out_leg_call_id TS Outgoing call ID String (100)

src_in_leg_conf_id Protocol conferenceID

String (100)

Operating TM

Page 126

src_in_leg_call_id Protocol incoming callID

String (100)

src_out_leg_call_id Protocol outgoing callID

String (100)

src_user Orig. registrationusername

String (100)

dst_user Term. registrationusername

String (100)

radius_user RADIUS username String (100)

src_name Origination gateway String (100)

dst_name Termination gateway String (100)

dp_name Dial peer String (100)

elapsed_time In-call time Integer

setup_time Setup time Date/time

connect_time Connect time Date/time

disconnect_time Disconnect time Date/time

disconnect_code Disconnect code Integer Universal disconnect code fromDisconnect codes table

in_leg_codecs Incoming leg codecs String (100)

out_leg_codecs Outgoing leg codecs String (100)

src_faststart_present

SRC Faststart present Boolean 0 or 1

dst_faststart_present

DST Faststart present Boolean 0 or 1

src_tunneling_present

SRC Tunnelingpresent

Boolean 0 or 1

dst_tunneling_present

DST Tunnelingpresent

Boolean 0 or 1

proxy_mode Proxy mode Boolean 0 or 1

lar_fault_reason LAR fault reason Integer 0: Call succeeded

1: No more routes

2: Unable to update mediachannels

3: LAR denied in the last route

4: System crashed

5: Call terminated before routing

6: Call terminated before

Operating TM

Page 127

CONNECT received

7: ISUP attachments exchangedon the last route

8: Call terminated by TS beforefirst route used

9: Call terminated as TMprocessed call for too long

route_retries Routing retries Integer

scd SCD, msec Integer

pdd PDD, msec Integer

src_media_bytes_in Orig. media bytes in Integer

src_media_bytes_out

Orig. media bytes out Integer

dst_media_bytes_in Term. media bytes in Integer

dst_media_bytes_out

Term. media bytes out Integer

src_media_packets Orig. media packets Integer

dst_media_packets Term. media packets Integer

src_media_packets_late

Orig. media packetslate

Integer

dst_media_packets_late

Term. media packetslate

Integer

src_media_packets_lost

Orig. media packetslost

Integer

dst_media_packets_lost

Term. media packetslost

Integer

src_min_jitter_size Orig. min. jitter buffersize, msec

Integer

src_max_jitter_size Orig. max. jitter buffersize, msec

Integer

dst_min_jitter_size Term. min. jitter buffersize, msec

Integer

dst_max_jitter_size Term. max. jitter buffersize, msec

Integer

last_cdr Last CDR Boolean 0 or 1

q850_reason Q.850 Reason Integer

in_cpc Incoming leg CPC Integer Code from Calling party'scategories settings

Operating TM

Page 128

out_cpc Outgoing leg CPC Integer Code from Calling party'scategories settings

pass_from Pass "From" to Term.GW

Integer

in_zone Orig. zone String (100) Zone from Zones table

out_zone Term. zone String (100) Zone from Zones table

disconnect_initiator Disconnect initiator Integer

diversion Diversion String (100)

in_ani_type_of_number

Incoming SRC numbertype

Integer -1: Same as for incoming leg

0: Unknown

1: International number

2: National number

3: Network specific number

4: Subscriber number

6: Abbreviated number

in_dnis_type_of_number

Incoming DST numbertype


0: Unknown


2: National number




out_ani_type_of_number

Outgoing SRC numbertype


0: Unknown


2: National number




out_dnis_type_of_number

Outgoing DST numbertype


0: Unknown


2: National number




in_orig_dnis Incoming original DSTnumber

String (100)

Operating TM

Page 129

out_orig_dnis Outgoing original DSTnumber

String (100)

src_disconnect_codes

Aux. SRC disconnectcodes

String (100) A list of universal disconnectcodes from Disconnect codestables, delimited with ";"

dst_disconnect_codes

Aux. SRC disconnectcodes

String (100) A list of universal disconnectcodes from Disconnect codestables, delimited with ";"

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

Operating TM

Page 130

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@aloenetworks.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 =========

Export interval5.6.2

The object Export interval in the category Export CDRs allows you to perform immediate export of calldetail records matching the specified interval.

In the * Starting date and * Ending date parameters specify the time frame, to which the exportedCDRs pertain. In the * Export period combobox select the period, into which the exported CDRs willbe subdivied. Each period is saved into a separate file, unless the * Save parameter = with browser. In

Operating TM

Page 131

the latter case a single file is generated. All othe parametes correspond to the parameters of theScheduled export object (see section CDRs scheduled export).

To invoke the export procedure click OK.

CDR post-processing5.6.3

The post-processing of exported CDRs adds flexibility of the CDR export. You can adjust anyparameters that are exported according to your own wishes. To use this feature do the following:

Activate the Enable post-processing checkbox in the Scheduled export settings.

Put executable files into the /var/www/rtu/extensions/cdr_export/process.ddirectory. These files will do the post processing.

With the checkbox enabled the System will save the exported CDRs into a temporary file and applythe executable files from the /var/www/rtu/extensions/cdr_export/process.ddirectory to the exported CDRs consecutively, in the alphabetical order. Non-executable files in thedirectory are ignored. These executable files act as filters; that means they take data from the STDINstream (original exported CDRs or the result of processing by the previous filter), process themaccording to their rules and output them into the STDOUT stream. When all filters are applied, thefinal CDR file is moved to the Export directory, saved on the FTP server or displayed in the browser.

It is possible to use the special OS environment variables in the executable files. These variablescorrespond to the parameters of the Scheduled export in the web interface. The variables are listed inthe /var/www/rtu/extensions/cdr_export/process.d/readme.txt file. Anexample of a filter in Perl is shown in the /var/www/rtu/extensions/cdr_export/process.d/disconnect_code.pl file.

Statistics5.7

The category of objects Statistics allows generation of area traffic reports.

Reports5.7.1

The object Reports is a GUI page that allows to create and view DP traffic transit reports.

To create a report, in the dialog Create report (Statistics > Reports) enter a name for the future report,type a regular expression in the field Pattern for DP name (LIKE) that defines a name(s) for DPs, andin the Grouping list select the criteria for grouping CDRs.

Operating TM

Page 132

Creating a report

Grouping – move attributes, by which CDRs will be grouped during report generation, from the left tothe right box. The precedence of grouping is determined by the position of the grouping attribute inthe list. Change the order of grouping by moving grouping attributes in the list up and down using

and buttons. Initially, CDRs are grouped by the topmost attribute on the list, thenthe records within the resulting groups are grouped by the second attribute in the list, and so on.

* Time unit – this parameter selects a measure of time used in record grouping. The process of reportcreation is described below in detail. The parameter is valid if the Grouping list contains Date.

* From date/To date – set the date range used to select CRDs for the report.

Pattern for SRC GW name (LIKE) – enter the originating gateway name pattern to include datapertaining to the specified originating gateway only.

Pattern for DP name (LIKE) – enter the DP name pattern to include data pertaining to the specifiedDP only.

Pattern for DST GW name (LIKE) – enter the termination gateway name pattern to include datapertaining to the specified termination gateway only.

LIKE operator indicates that mySQL syntax is used for name patterns.

Disconnect code – enter a disconnect code to include the calls with the specified disconnect codeonly.

Area – select the prefix from the dropdown list to include those calls into the report that have thespecified prefix in the telephone number.

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

Operating TM

Page 133

Tables "Report contents" and "All reports"

Report generation unfolds as follows:

1. CDRs are selected by the date that fits in the date range defined in the Create report dialog.

The CDR date value depends on the Value for "Date" field in CDR: 1 - Setup time, 2 - Disconnecttime parameter.

2. When a regexp pattern for the DP name, name of the originating or terminating gateway areavailable, the CDRs are additionally filtered by the name matching the regexp entered in thefield Pattern for DP name (LIKE), Pattern for SRC GW name (LIKE) or Pattern for DST GWname (LIKE).

3. The selected CDRs are then grouped by attributes specified in the Grouping list. The order ofgrouping is determined by the precedence of the grouping attributes in the list. If theGrouping list includes Data, then the CDRs are additionally sub-grouped by date using thetime option selected in the Time unit combo box. By way of example, if the Grouping listincludes two attributes – Region and Date, where Region is the first attribute and Date is thesecond, the CDRs will be first grouped by Region, and then by Date. Suppose, the Time unitparameter is set to Hour, then report records in region groups within the defined date range arefurther grouped in hourly sub-groups. When a created subgroup contains no calls - it isdiscarded; otherwise it occupies a line in the generated report.

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

Total minutes – total duration of all calls in minutes (taking into account all records in thegroup), rounded up or down to the nearest whole minute.

Total calls – total number of call arrivals (that is the number of connections between theoriginator and the System). In other words – the number of CDRs with the Last CDRparameter equal to “Yes”.

Successful calls – number of successful calls.

Successful calls are calls completed with call disconnect reason codes marked as Successful (seesection Disconnect codes) or with non-zero duration.

Connected calls – number of calls with a voice session (that is calls of non-zero duration).

Total attempts – total number of attempts to establish a call (number of the Systemconnection attempts to the terminator).

Successful attempts – successful number of attempts to establish a call.

Connected attempts – number of attempts with a voice session (that is attempts of non-zeroduration).

Operating TM

Page 134

The data on the number of calls (total, successful and with voice sessions) is necessary to assess thequality of services, provided by the terminating operator. The data on the number of attempts (total,successful and with voice sessions) is necessary to assess the quality of termination services,provided to RTU operator by other operators.

ASR (calls), % – answer seizure ratio calculated by the RTU intrinsic method (see ASR(RTU)).

Std. ASR (calls), % – standard answer seizure ratio calculated conventionally (see ASR(std)).

ASR (attempts), % - answer seizure ratio for calls forwarded for termination by otheroperators; the ratio is calculated by RTU intrinsic method (see ASR(MVTS)).

Std. ASR (attempts), % - answer seizure ratio for calls forwarded for termination by otheroperators; calculated conventionally (i.e. ASR = total number of non-zero duration calls/totalcalls).

ACD, sec – average call duration for non-zero length calls.

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

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

First CDR date – SETUP time of the earliest call in the group.

Last CDR date – SETUP time of the latest call in the group.

First CDR ID – the CDR unique ID of the first call in the specified period.

Last CDR ID – the CDR unique ID of the last call in the specified period.

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

Operating TM

Page 135

Viewing report contents

You cannot remove individual CDRs from a report; you can only remove the entire report form thetable All reports.

Charts5.7.2

The object Charts allows an illustrative representation of the System statistics in real-time. To enablestatistics collection globally, set the Enable statistics (Global settings -> System global settings)parameter to 1. To include data about individual gateways and dial peers into the statistics, select thecheckbox Enable statistics in configuration forms of respective GWs or DPs.

If statistics collection is disabled globally (Global settings -> System global settings -> Enablestatistics = 0) the Enable statistics setting of individual gateways and dial peers is ignored.

Operating TM

Page 136

Charts

To add a new chart click .

A new dialog will appear where you can configure the parameters of the chart being created.

Creating a new chart

From the drop down list Object type select an object, to which the chart pertains. The list optionsinclude:

Originator – plot a chart for origination gateway.

Terminator – plot a chart for termination gateway.

Gateway – plot a chart for the gateway that is both originator and terminator.

Dialpeer – plot a chart for the DP as a whole (including all gateways pertaining to it).

In the Object name field type the first characters of the object to be monitored and the select theobject from the drop-down list.

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

To create a new chart click OK.

The screen will show a new chart area. To add a new curve for a specific parameter to the chart, on theright panel select the checkbox next to the parameter name. You can monitor the following parameters,calculated as exponential moving average. To plot a statistics chart:

ASR – Answer seizure ratio (MVTS-specific).

ASR (std.) – Conventional ASR.

ACD – Average call duration.

PDD – Post-Dial Delay.

Operating TM

Page 137

SCD – SETUP-CONNECT Delay.

QoS – Quality of Service.

CPS – Call arrival rate

Calls – total number of calls being handled

To change the curve options for each parameter, click on the parameter name on the right panel.

Configuring a curve

To select the curve color, click on the field next to the Line color label.

Select the desired curve thickness in pixels from the Line weight combo box.

Select the desired curve form from the Line type combo box – Spline and Polygon.

To apply new parameters, click OK.

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

Define the chart horizontal scale using the Scale slider.

To stop plotting of all curves press . To edit the chart parameters press .

When several scripting nodes are selected, the plot value is calculated as a weighted average withregard to the CPS value for every selected node.

Suppose, you want to display an ASR chart for the dial peer DP1 and your System has two scriptingnodes – ScrN1 and ScrN2. The ASR statistics for ScrN1 is 80 and 40 for ScrN2. Simultaneously, theCPS data for ScrN1 equals 15 calls per second and is 5 calls/sec. for ScrN2. The weighted averageASRavg is then calculated as:

ASRavg = (ASRScrN1 * CPS ScrN1 + ASR ScrN2 * CPS ScrN2)/(CPS ScrN1 + CPS ScrN2),

that is

ASRavg = (80*15 + 40*5)/(15 + 5) = 70.

If CPS or Calls are the main chart parameter, the plotted value is just the sum of CPS or Calls valuesrespectively from all selected scripting nodes.

You can add new charts by pressing . The new chart will appear at the top of thechart list window.

To remove the chart, click in its right-upper corner.

Operating TM

Page 138

Global settings5.8

The subcategory Global settings comprises objects pertaining to system global settings, websettings, call disconnect codes and interoperation with RADIUS, ENUM and DNS servers.

System global settings5.8.1

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

Table of global configuration parameters

The global configuration parameters currently accessible to the RTU administrator include:

Max. call duration – maximum call duration for all calls. Among the parameters limiting maximum callduration, defined on the originator, terminator, RADIUS-server and in the global settings, theparameter with the lowest value is selected (Zero means no limitation).

Number of routes sent to TS at a time – number routes selected by the scripting node that are sent tothe TS at a time. This parameter allows you not send all routes simultaneously, thus enhancing the

Operating TM

Page 139

performance.

MVTS name – the name identifying the RTU to interoperating devices.

Enable statistics – toggle collection of statistical data, which is used to plot charts.

Number of calls for EMA calculation – defines the number calls used for calculation of exponentialmoving average of the following parameters: ASR (MVTS), ASR (std), ACD, PDD, SCD, CPS and QoS.

Value for "Date" field in CDR: 1 - Setup time, 2 - Disconnect time – determines the way of filling inthe Date field in CDRs. 1 means the call setup time will be recorded, 2 means the call disconnect timewill be recorded.

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

Max. debug call/registration sessions sets the maximum number of debug records allowed in thetables “Debug registrations” and “Debug calls”.

Debug data lifetime (days) defines the maximum retention time for debug call and debug registrationdata. As the size of debug data files may grow prohibitively large, set this parameter so as to preventhard disk overflow.

Enable logging for unknown calls – determines if the System should log calls from unknowngateways (i.e. gateways with no record in the DB, including records of default gateways).

Enable logging for unknown registrations – determines if the System should log registrations fromunknown gateways (i.e. gateways with no record in the DB, including records of default gateways).

"In-call time" representation method: 1 - sec, 0 – msec – determines the units in which the CDR In-call time parameter is represented. 0 – in milliseconds, 1 – in seconds.

Maximum number of CDRs in a queue – define the maximum number of CDRs in a scripting nodequeue. If the DB is not able to insert CDRs as fast as they are generated by the scripting node, theseCDRs are put into a queue. When the number of CDRs in a queue exceeds the specified number, theSystem starts to write CDRs onto the hard drive, an alarm is raised and a notification is sent to theSystem administrator’s email (see section TS notification function).

Clear alarm if the number of CDRs in a queue is less than – if the number of CDRs in a queue is lessthan the specified number the alarm raised when the maximum CDR number in the queue is exceededwill be cleared (a notification is sent to the System administrator’s email).

CDR storage period – define a period for storing tables with CDRs, in months. The CDR tables forwhich the storage period is expired, will be automatically removed from the DB. To cancel automaticremoval assign 0 to the parameter. For further information see CDR tables.

Interims period – the interval between sending Interim packets to the RADIUS server/creating InterimCDRs in the DB.

CDR interims enabled – 0 – do not create interim CDRs, 1 – create interim CDRs.

Data update period for the DP balancing method – the number of calls serving as a period forupdating data of the DP Balancing method parameter. When the specified number of calls gets routedthrough a DP, the data gets updated and the call counter zeroes. Thus if you specify a large number inthe parameter, the data update frequency reduces and System performance increases. The exactSystem actions on data update depend on the Balancing method:

Round-robin balancing – new gateway will be selected for call routing after N calls are routedto the DP, where N is specified in Data update period for the DP balancing method parameter.

Balancing by absolute load – the number of calls on gateways gets updated after N calls arerouted to the DP, where N is specified in Data update period for the DP balancing methodparameter.

Balancing by load-to-capacity ratio – the “load/capacity” ratio of every gateway in the DP getsupdated after N calls are routed to the DP, where N is specified in Data update period for theDP balancing method parameter.

EMA coefficient for calculating average incom. call handling time - this parameter is used tocalculate the average incoming call handling time. As the TS rejects all calls if they were handled bythe scripting node for more than 5 seconds, this time is used to determine if the scripting node canfinish call handling in time and thus if it should try to process it. Specifically, if the time, when the

Operating TM

Page 140

scripting node received a call for handling, + avg. call handling time is more than SETUP time + 5 secs,the scripting node will reject the call without processing. The average call processing time iscalculated using the EMA method. The formula is:

where

- the average call handling time.

- a moment of time.

- a timestamp.

- a the amount of time the System used to process a call.

- the EMA coefficient, as defined by the EMA coefficient for calculating average incom. callhandling time parameter.

The greater the coefficient, the more accurate will be the averaging.

Max. time of call handling by the scripting node, msec - the amount of time the scripting nodeallocates for handling one call. When the time expires the call will be terminated. As the TS waits forthe scripting node to process the call for 5 seconds and then terminates it anyway, it is pointless toset the parameter to more than 5 seconds.

Presently the time is averaged to seconds.

Click the button Switch to edit mode to configure the parameters of the Traffic Manager.

Web settings5.8.2

The table Web settings includes parameters essential for GUI management, which are as follows:

Table of GUI parameters

Default GUI Language - sets the GUI default language: 1 for English, 2 – for Russian.

Possible number of rows on page – use this parameter to define the size of a table page expressing itin a number of rows per page. A list of decimal numbers delimited with commas. For example, 10, 20,30, 50.

Default number of rows on page – use this parameter to define the default table page size, i.e. thenumber of rows a table will display when first accessed for viewing.

Operating TM

Page 141

Maximum number of rows displayed in GUI tables – use this parameter define the maximum number oftable records displayed in GUI. Should the actual number of records in the DB exceed the specifiedtable size limit apply a filter to view the table data. The parameter serves to expedite the display oftables with large amounts of data (for example, tables of CDRs). If the parameter is not defined, theerror “General error: 126 Incorrect key file for table” may occur, when trying to display a table with alarge number of entries.

CSV date format – this parameter allows the user to define a date format applied to exported data.

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

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

CSV null value – serves to define a symbol or symbols that will be used to fill empty data fields indata export files.

Enable/disable logging of user activity – two possible values for this parameter are 0 and 1. 1 enablesuser GUI activity logging, 0 disables user activity logging.

Enable/disable logging of view actions – allows two values 0 and 1. 0 disallows logging of userviewing activity. 1 enables logging of all user actions, including object viewing . If Enable/disablelogging of user activity = 0, the view activity logging parameter is ignored.

Maximum storage time for user activity log (days) - sets a retention time for web activity log records(days). Records, the age of which exceeds the value defined by this parameter, are subject to deletionform the log. Note that to avoid excessive server load records will be deleted with some delay.

Enable/disable authentication history – allows two possible values - 0 and 1. 0 disables userauthentication logging, 1 enables authentication logging.

Maximum storage time for authentication history (days) - sets a retention time for authenticationhistory records (days). Records the age of which exceeds the value defined by this parameter aresubject to deletion form the log. Note that to avoid excessive server load records will be deleted withsome delay.

Initial values from filter – set the parameter to 1, if you want to initialize parameters of a freshly addedrecord with values of the filter currently applied to the table.

Enable/disable top banner – toggles the display of top RTU banner. 0 – do not show banner. 1 – showbanner.

Exported file encoding – set the encoding of the file exported through a pop-up menu. The list ofavailable encodings:

UTF8

UTF16

UTF32

CP1251/WINDOWS1251

KOI8R

Add BOM to exported files – set the parameter to 1 if it is necessary to place Byte Order Mark (BOM)at the beginning of the exported file. The BOM defines a correct byte order for Unicode encodings.

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

Operating TM

Page 142

Setting the parameter Maximum number of rows displayed in GUI tables

Type the required parameter value in the edit field Value and click the OK button. To discard themade changes click Cancel.

Time zone is defined separately in a combobox:

Time zone – use this parameter to specify the default time zone for the GUI objects (objects CDRs,Reports, Debug calls and Debug registrations).

Disconnect codes5.8.3

The table Disconnect codes presents a listing of call disconnect codes. To quicken search of thenecessary information you can use search filters. Refer to section Use of filters for information aboutthe use of search filters.

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 thecalling and called parties, instead of local TS and TM disconnect codes. The equipment supportive ofH.323 protocol will receive the code from the column H.323 code mapping, the SIP endpoints will

Operating TM

Page 143

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 disconnectreason 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. Selectthe respective checkbox in the displayed dialog box and click the OK button.

ENUM-servers5.8.4

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 allowconversion of conventional E.164 telephone numbers into URIs by means of the DDDS (DynamicDelegation Discovery System) algorithm and further into IP addresses (with the help of a DNS server)which makes such servers especially fit for external routing.

If the ENUM server responds with an URI, the System will query a DNS server to resolve the URI. Ifthe ENUM server supplies not an URI, but an IP address, the System will not query the DNS serverbut will connect to the terminator immediately using the IP address supplied.

Refer to RFC 3761 for a more detailed explanation of ENUM.

External routing by means of ENUM servers is possible under SIP signaling only.

To add a ENUM server, invoke the pop-up menu and select Add.

ENUM server properties form

In the dialog that opens enter the following data (the parameters marked with an asterisk character arerequired parameters):

* Name – name that identifies the ENUM server.

Description – you can enter any descriptive information or comments pertaining to the record beingcreated 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.

Operating TM

Page 144

You can specify the configured ENUM server as an external routing means when configuringgateways.

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

DNS servers5.8.5

The table “DNS servers” allows you to overview the domain name servers used for resolution of URIsreceived from ENUM servers.

To add a DNS server, invoke the pop-up menu and select Add.

Entering DNS server data

Fill out the DNS servers form and click OK to add the newly configured record. The required fields onthe form are marked by an asterisk ’*’.

The required fields on the DNS servers form are *Name (the server name assigned by theadministrator) and *Address (the server’s IP) only.

The parameter Precedence shows the DNS server preference. The greater the parameter value thegreater the server’s preference.

Select the Enable checkbox to validate the record.

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

Areas5.8.6

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

Adding a new area record

To add a new record to the table, invoke the pop-up menu and click the Add item. Enter the name ofthe area in the * Name edit field and click the OK button.

Operating TM

Page 145

A unique ID for the record will be generated automatically.

Area specifics5.8.7

The table Area specifics displays information about area number prefixes and minimum or/andmaximum lengths of numbers in areas.

Invoke the pop-up menu and select Add, to add another record to the table.

Area specifics dialog

Enter the following data in the displayed dialog (the required fields are those marked with asterisk ‘*’):

* Area – select the area name from the dropdown list of this combo box.

* Prefix – enter the telephone number prefix for the area.

Min. number length – enter the decimal integer showing the minimum length of telephone numbers inthe area.

Max. number length – enter the decimal integer showing the maximum length of telephone numbers inthe area.

Click OK to add the record to the table.

Calling party’s categories5.8.8

The table Calling party’s category contains reference information about the calling party’scategories.

Table "Calling party's category"

The table presents the following data:

CPC type – name of the standard, which defines the category.

Namespace – shows belonging to the international (CPC) or American (OLI) standard.

Code – code of the category.

Operating TM

Page 146

Description – description of the category.

CPC translations5.8.9

The table CPC translations presents information about correspondences between the international(CPC) and American (OLI) calling party’s categories.

Table "CPC translations"

The table presents the following information:

Namespace – shows belonging to the international (CPC) or American (OLI) standard.

Code – code of the category.

CPC code mapping – if the category belongs to the OLI standard, this field shows the correspondingcode in the CPC standard. If the correspondence is not defined, the System uses the value fromparameter Default CPC code mapping.

Default CPC code mapping – if the category belongs to the OLI standard, this field shows the defaultcorresponding code in the CPC standard.

OLI code mapping – if the category belongs to the CPC standard, this field shows the correspondingcode in the OLI standard. If the correspondence is not defined, the System uses the value fromparameter Default OLI code mapping.

Default OLI code mapping – if the category belongs to the CPC standard, this field shows the defaultcorresponding code in the OLI standard.

The System translates calling party’s categories automatically, if the CPC in the incoming leg (or aftertranslations on DPs, gateways, etc.) is defined in one standard (for example, CPC), but should be sentto the outgoing leg in the other standard (for example, OLI).

Capacity groups5.8.10

To control the softswitch capacity the System enables assorting calls into capacity groups.

Table "Capacity groups"

Grouping by capacity aims at flexible management of individual and aggregate capacity of gatewaysand dial peers. Capacity management allows you to limit the number of calls not only for each stand-alone gateway, but also for a group of gateways, if necessary.

For example, the individual capacity of the terminators A and B is 10 and 10 calls respectively, but you

Operating TM

Page 147

want to limit the total capacity of both gateways to 15 calls. You can fulfill this task by assigning thegateways A and B to an A_B group and limiting the group capacity to 15 concurrent calls.

In such a case when a new call arrives to the A gateway, the System checks if the capacity of thegateway A is not exceeded, as well as if the capacity of the group A_B (to which the gateway Abelongs) is not exceeded.

Capacity groups may become members of other capacity groups, thus creating a group hierarchy.

In such a case when a call arrives to the A gateway, the System checks the capacity of the gateway,the capacity of the group A_B to which the gateway is a member, the capacity of the group A_B_C towhich the group A_B is a member, and further up the group hierarchy.

To add a new capacity group invoke the pop-up menu and select the Add option.

Adding a capacity group


* Name – name that identifies the capacity group.

Description – you can enter any descriptive information or comments pertaining to the record beingcreated in this field.

Parent group – the parent group of this capacity group.

Capacity – the number of concurrent calls that can pass through the group. If the field is empty orzero is entered, the number of calls is unlimited.

When done, press OK.

Operating TM

Page 148

Number capacity groups5.8.11

This table comprises capacity groups limiting concurrent calls to/from a specified phone number. Thegroups defined in the table may be assigned to originators to limit SRC numbers (the parameter SRCNumber capacity group in the equipment settings), to terminators to limit the DST numbers (theparameter DST Number capacity group in the equipment settings) and to dial peers to override theterminator number capacity group settings (the parameter Override number capacity group in the dialpeer settings). If the group is assigned, the number of concurrent calls with the same phone numberpassing through the gateway/dial peer may not exceed the number defined in the group.

Number capacity groups

* Name – name of the number capacity group.

* Capacity – maximum number of calls with the same phone number. If the field is empty or zero isentered, the number of calls is unlimited.

When limiting the SRC numbers, the number after originator translation is used; when limiting theDST number on the dial peer, the number after per-routing translations is sued; when limiting the DSTnumber on the terminator, the number after dial peer translation is used.

Models codecs5.8.12

This table comprises codec parameters that are predefined in the System in the Codecs table. Thistable may be used to restore the original settings of the predefined codecs in case they were changedor deleted.

Restoring predefined codec settings

The table stores a list of predefined codecs together with their original settings. To restore theparameters of a certain codec or codecs select them in the table by clicking on column to the left,

Operating TM

Page 149

invoke the popup menu and select the Special function -> Restore model codec settings (marked orselected). If a filter is applied to the table, then to restore the settings of the codecs, shown in thefiltered table, in the popup menu select the Special function -> Restore model codec settings (allfiltered). To restore the settings of all predefined codec click the OK button below the Restore modelcodec settings.

Model RADIUS attributes5.8.13

The page comprises a table with the model RADIUS attributes. This table may be used to restore theoriginal settings of the predefined attributes in the RADIUS attributes table (see section RADIUSattributes) in case they were changed or deleted.

Model RADIUS attributes page

The following data is available in the table columns:

ID – attribute ID (sequence number);

Record name – name of the attribute record in the format: <attribute source>-<attribute name>, where:

Attribute source may have values:

o rfc – attribute profile executed as per RFC2866.

o cisco – attribute profile executed as per Cisco specifications.

o mvts – attribute profile executed as RTU proprietary.

Attribute name – name of the attribute, selected from the list of names, defined in RFC2866,provided by RTU or defined by Cisco.

Code – digital code of the attribute.

Field name – attribute name in the RADIUS packet.

Vendor code – ID of the namespace provided to a certain company to define the attribute (9 = CISCO).In case of an empty value, the attribute is defined according to RFC 2866.

Type – value type.

Value – value (contents) of the attribute.

Description – arbitrary description of the attribute.

To restore the parameters of RADIUS attributes select them in the table by clicking on column to theleft, invoke the popup menu and select the Special function -> Restore model RADIUS attributes(marked or selected). If a filter is applied to the table, then to restore the settings of the attributes,shown in the filtered table, in the popup menu select the Special function -> Restore model RADIUSattributes (all filtered).

Operating TM

Page 150

Pop-up menu for the “Model RADIUS attributes” table

To restore the settings of all predefined codec click the OK button below the Restore all modelRADIUS attributes.

CDR tables5.8.14

This object comprises lists of all tables with CDRs stored in the DB. The System keeps one table foreach month.

CDR tables

Each record in the object defines one CDR table in the DB. To view information on a specific table,invoke the context menu and click View.

Table name – name of the table in the DB in the format mvts_cdr_<year><month>.

Row count – number of rows in the table.

Data size, MB – size of data in megabytes.

Available for removal– indicates if the table can be removed. The following tables can not beremoved:

Table for the current month;

Table for the next month;

Table for the previous month;

Table mvts_cdr_000000, storing inaccurate CDRs.

To purge the DB it possible to set up automatic removal of CDR tables. To do it define the number ofmonths for the table to be kept after its creation in the System global settings, CDR storage period(see section System global settings). For example, if:

Current month – May (i.e. 05).

CDR storage period = 2

then all record created in March (month 03) and before will be removed from the DB. To stopautomatic removal assign 0 to the CDR storage period.

Besides, it is possible to remove CDR tables manually. Select the required records in the CDR tablesby any means (by clicking on them, activation checkboxes in the left column or applying a filter),invoke a pop-up menu and select Special function -> Remove CDR tables.

Custom views5.8.15

This table comprises a set of filters that are applied to GUI objects of the System. For each tablerecord the System creates a separate subobject in the category tree, where the filtered information ispresented. To add a new view invoke the pop-up menu and select the Add option.

Operating TM

Page 151

Table "Custom views"


* Table - select the table to which the filter will apply. A subobject with data, filtered by the Filter, willbe created in this table.

* View name - enter the subobject (view) name.

* Filter - define the filter that will be applied to the data of the parent table, specified in Table. Therules of filter definition are described in Use of filters section.

Click OK to add the record to the table. The System will create a new view in the form of a separatesubobject to the parent table in the GUI object tree. For example, for the figure above the view will beas follows:

Added view

Logs5.9

The category Logs comprises objects, which record all authentication attempts and actions of users inthe GUI.

Operating TM

Page 152

Web authentication history5.9.1

The object Authentication history is designed to store the log of user authentication attempts.

Authentication history table

The following table presents the authentication history record parameters:

Session ID – ID number of the user logon session.

Date – date and time of the registered authentication attempt.

User – user account used for authentication.

Realm – realm of the user.

Login – login of the user used for authentication.

IP address – IP address, of the computer which requested authentication.

Login successful – shows if the login attempt was successful or not.

To view all logged user actions during the selected session, invoke the pop-up menu and select Webactivity log. This will open Web activity log filtered by the selected session ID.

Web activity log5.9.2

Web activity log is accessible n the category of objects GUI. The table Web activity log presents anaccount of user access to database objects and actions that users performed.

Page with user activity transcripts

An individual user activity record provides the following information presented in table columns:

ID – record identifier.

Session ID – ID of the session, during which the record was created.

Logging time – date and time of record creation.

Operating TM

Page 153

User – actor’s account name.

Object – name of the object that was accessed.

Action – nature of the action done by the actor.

Data – detailed account of the action effect.

Filter – filter used while accessing data.

Row count – number of processed lines.

Import5.10

The Import category comprises the Import wizard, designed for importing records from csv-files intodifferent System tables.

In step 1 you define the file from which the records are imported and specify the required importsettings.

Defining imported file parameters. Step 1

Можно задать следующие параметры:

* From file – click Browse and locate the source file;

* To table – select the target table;

* Column sequence – select the required method for determining the sequence of columns. This

Operating TM

Page 154

parameter has the following options:

Try to match the headers – the import procedure automatically matches the column names inthe file with the names of the columns in the web-interface. Thus the sequence of columns inthe files may be arbitrary if the column names match the names in the web interface. Thismethod is used for importing records previously exported by means of a context menu from arespective table.

Use the template – the import procedure matches the columns in the order they are in the web-interface (without considering the rearrangements performed by the web interface user). Thecolumns that the user can not edit (such as ID) are ignored. This method is used when the filewith imported records was obtained from a template file (see below).

* Separator – define the separator used to delimit data in the source file;

* Quote - define the quote character used in the source file;

* Include headers – select this check box if the source file contains column headers. This will instructthe System to ignore the first row of data during import.

* Encoding – select the type of encoding used in the source file;

* Date format – use this control to define the date format to be applied to the imported data. Besidesdates are also checked for compliance to specific requirements of some columns (for example, in theSchedule group of the Dial peer table);

Records for inserting only – activate the checkbox if it is necessary to import only those records fromthe files that are absent in the target table. If they are present, such records will not be updated.

* Unique columns – this field shows the list of columns checked for uniqueness during import. Forthe record in the file to be considered unique it is necessary that the combination of values ofcolumns, defined in the list, should be unique. Non-unique records found in the csv file are discardedduring the import.

Template - by clicking this hyperlink you can download a template CSV file for import to the selectedtable. This file can be used to enter data that can be imported later. The template comprises nocolumns that the user can not edit (such as ID), thus it can be easily imported using the Use thetemplate method.

When done, click the Load button and proceed to the next step.

Defining the sequence of columns. Step 2

In step 2 you can re-arrange the columns so that they correspond to the sequence of imported data.

Use the and buttons in column headers to move them to the leftmost or rightmost position orclick the header name, drag it to the required position and click again to insert it.

The customized column order can be saved for further use. For this, click the Save sequence buttonand enter the layout’s name in the Save column sequence dialog box.

Operating TM

Page 155

Saving column sequence

To delete unnecessary sequences click the Delete sequence button and select the needless layout’sname in the Delete column sequence dialog box.

Deleting column sequence

Click the Next button to continue.

Screen 3 of the wizard presents information about imported data including:

Target table

Total number of imported records

Number of records ready for insert

Number of records ready for update

Number of erroneous records, such records also will not be uploaded

Number of duplicated records in the source file, only the last of the duplicated records in theimported files will be uploaded. Duplicated records in the DB will not be updated.

The List of columns to be updated parameter in the Additional parameters group comprises a two-windowed control with column names. The columns in the right list will be updated during the import.The columns in the left list will remain unchanged. To move the columns from the left to the right list

use the and buttons.

Operating TM

Page 156

Data for import. Step 3

The table Data for import is a temporary table with data imported from the CSV file in Step 1. Inaddition to the columns that constitute regular tables, the table Data for import contains the columnErrors that provides information on detected errors and the column Status with current status of therecord. Records with erroneous data are highlighted in red.

You can add new records to the temporary table or edit the existing ones in the same way as you do itin regular tables. Upon editing the records are automatically checked and assigned a new status.

Click the Import button to move the data to the regular table. To exit the wizard and return to the firstpage click Cancel.

Operating TM

Page 157

RADIUS settings5.11

The RADIUS settings category comprises objects that allow the user to flexibly configure theinteroperation if the System with the RADIUS server for accounting, authorization and routing.

The detailed step-by-step instruction on configuring RADIUS interoperation is in section An exampleof RADIUS accounting configuration.

RADIUS global settings5.11.1

The object RADIUS global settings comprise settings pertaining to interoperation with all RADIUSservers.

RADIUS global settings

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

Operating TM

Page 158

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

Encrypt H.323 plain text password – toggles encryption of the plain text password from an H.323device, when the password is sent to a RADIUS server. The password is encrypted, when the deviceregisters through a default gateway or has RADIUS password set to ‘*’. The System uses the secretkey of the RADIUS server, to which the password is sent, for encryption.

‘Service-Type’ attribute value – specify the value of the Service-Type attribute to be sent to theRADIUS server. If no value is 0, the attribute is not included into the packets. For further informationrefer to RFC 2865.

‘Framed-Protocol’ attribute value – specify the value of the Framed-Protocol attribute to be sent tothe RADIUS server. If no value is 0, the attribute is not included into the packets. For furtherinformation refer to RFC 2865.

Query period for offline RADIUS servers – interval between attempts to switch to non-active butfirst-priority RADIUS servers. See the Precedence parameter of the RADIUS servers objects.

Use protocol conference ID in h323-conf-id field – the parameter defines the way to fill out the h323-conf-id field sent to the RADIUS server. 1 – Conf ID coming from the equipment is used. If the ConfID has not come from the equipment (for example, in case of SIP), the h323-conf-id is sent empty. 0 –the Conf ID generated by the TS is used for all cases.

For this parameter value1 is valid only in case of using a standard RADIUS profile (i.e. a profilewith Send ACCT.START/STOP packets not set to Customizable Cisco-compatible, see sectionRADIUS accounting profiles). Otherwise error may occur.

Active RADIUS accounting profile – enter the record ID of a RADIUS accounting profile (see sectionRADIUS accounting profiles). This profile will become active.

Digest authentication type: 0 - draft-sterman-aaa-01, 1 - draft-sterman-aaa-04 – determines the typeof Digest authentication (see section Digest authentication) to be used by the system: 0 - draft-sterman-aaa-01, 1 - draft-sterman-aaa-04.

RADIUS interims enabled – 0 – do not send RADIUS interims, 1 – send RADIUS interims.

Call authorization before routing - if the parameter is 0, call authorization is performed aftergenerating a list of routes. If the parameter is 1, call authorization is performed after generating a list ofroutes. By default, the parameter is 0. If Call authorization before routing is 1, the System does notmake use of External routing w/o authorization parameter value.

RADIUS servers5.11.2

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

Table of configured RADIUS servers

To add a RADIUS server record, left click the mouse over the table and select Add on the pop-upmenu.

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




Operating TM

Page 159

Adding a RADIUS server record

Fill out the displayed server configuration form. The fields marked with an asterisk are required fields.

* RADIUS server name – enter the name of the RADIUS server.

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

Enable – select the checkbox to make the record active.

* Precedence – use this parameter to define the server precedence. The higher the value – the higherthe precedence (that is 2 has higher precedence than 1). At each instance of time RTU interacts withone server only, with the highest precedence. If the system detects a failure of the RADIUS server it iscurrently connected to, it will switch to the next configured server with the lower precedence value.

Enable authentication – select the check box to enable authentication of gateways by the RADIUSserver being configured.

Enable authorization – select the check box to enable authorization of calls from gateways by theRADIUS server being configured. If RADIUS does not respond in (Max. time of call handling by thescripting node, msec - (SETUP time - time of authorization request dispatch)), the System terminatesthe call.

When the Enable authorization checkbox is selected and at least one route of a dial peer isgenerated with help of external routing feature, all routes of the dial peer do not undergoauthorization on the RADIUS server. This relieves the load from the System and the RADIUS server.

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

Enable external routing – select the check box to if you are planning to use the RADIUS server forexternal routing.

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

Operating TM

Page 160

the RADIUS server.

Retry number – use this parameter to specify the number of send attempts for the packets destinedfor the RADIUS server. When this limit is exceeded the System starts to interoperate with the next (byprecedence) RADIUS server. Note that the System checks the physical servers for authentication andaccounting individually. The implications of this fact are shown in the figure below.

Interoperation with RADIUS servers in case of a failure

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

Category Authentication – these parameters are valid only with the selected Enable authenticationcheckbox:

Authentication address – enter the IP address of the RADIUS server used for authentication.

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

Category Accounting – these parameters are valid only with the selected Enable accountingcheckbox:

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.

Category External routing – these parameters are valid only with the selected Enable externalrouting checkbox:

External routing address – enter the IP address of the RADIUS server to be used for purposes ofexternal routing.

External routing port – enter the port of the RADIUS server to be used for purposes of externalrouting.

It is possible to use the same IP addresses and ports for different functions of the RADIUS server; youcan specify the same IP address and port for authentication and accounting, for example.

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

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

The System polls RADIUS servers every 60 seconds and uses operational billing and authorizationpackets for it. In other words every 60 seconds the System starts to send billing and authorizationpackets not to the active server, but to the server with highest precedence and further to serverswith lower precedence. In case of authorization packets, if the server with higher priority isunavailable, the call will be rejected during the switch to the lower precedence server. Besides incase of a large number of inactive RADIUS servers, large retry numbers and large intervals betweenretries the waiting period for the RADIUS reply may exceed 5 seconds and the call will be rejected

Operating TM

Page 161

with “TMngr timeout” code. That is why it is recommended to use not more than two RADIUSservers.

RADIUS attributes5.11.3

This table comprises record with all attributes that could be incorporated in to the RADIUS packets.

Initially the table comprises 140 records with predefined RADIUS fields.

RADIUS attributes table

Possible actions over this record are specified in the context menu invoked by a left click.

Menu of available actions in the RADIUS attributes table

The following information is available in the columns of the table:

ID – ID of the attribute record (sequence number).

Operating TM

Page 162

Record name – name of the attribute record in the format: <attribute source>-<attribute name>, where:

Attribute source may have values:

o rfc – attribute profile executed as per RFC2866.

o cisco – attribute profile executed as per Cisco specifications.

o mvts – attribute profile executed as RTU proprietary.

Attribute name – name of the attribute, selected from the list of names, defined in RFC2866,provided by RTU or defined by Cisco.

Code – digital code of the attribute.

Field name – attribute name in the RADIUS packet.

Vendor code – ID of the namespace provided to a certain company to define the attribute (9 = CISCO).In case of an empty value, the attribute is defined according to RFC 2866.

Type – value type.

Value – value (contents) of the attribute.

Description – arbitrary description of the attribute.

It is possible to use the Python expressions as well as variables listed below in the Value field.

The list of available variables is provided in the table below.

Available variables

Name Value on the incoming leg Value on the outgoing leg

alertingTime ALERTING arrival time. ALERTING arrival time.

ani SRC number. SRC number after pre-routingtranslations

aniADPT N/A SRC number after dial peertranslations

aniAGT SRC number after gateway translations N/A

aniAPT SRC number after pre-routingtranslations

N/A

aniBasic SRC number coming to the scriptingnode on call begin

N/A

aniBill SRC number for billing after pre-routingtranslations

SRC number for billing after pre-routing translations

aniIsup SRC number from ISUP message (SIP-T). N/A

aniNumberPlan N/A SRC numbering plan

aniPresentation N/A SRC Presentation indicator

aniScreening N/A SRC Screening indicator

aniTypeOfNumber SRC number type SRC number type

callId Call ID from the equipment N/A

code N/A Disconnect code

codecs Codec list Codec list

confId Conf ID from the equipment N/A

connectTime CONNECT arrival time. CONNECT arrival time.

cpc Calling party category. Calling party category

Operating TM

Page 163


creationTime Time of call arrival into the scriptingnode

N/A

disconnectInitiator Call disconnect initiator N/A

disconnectTime Disconnect time N/A

dnis DST number DST number after pre-routingtranslations

dnisADPT N/A DST number after dial peertranslations

dnisAGT DST number after gateway translations N/A

dnisAPT DST number after pre-routingtranslations

N/A

dnisBasic DST number coming to the scriptingnode on call begin

N/A

dnisBill DST number for billing after pre-routingtranslations

DST number for billing after dialpeer translations

dnisIsup DST number from the ISUP message(SIP-T).

N/A

dnisNumberPlan N/A DST numbering plan

dnisTypeOfNumber

DST number type. DST number type

dpName N/A Dial peer name

dpID N/A Dial peer ID.

faststart N/A If faststart is used or not

gatekeeperAddress Gatekeeper address N/A

gwAddress Originator gateway address Terminator gateway address

gwID Originator gateway ID Terminator gateway ID

gwName Originator gateway name Terminator gateway name

h323Id "H323-ID" parameter from theequipment.

N/A

h323IvrIn If H232_IVR_IN is used in User-Namefield.

N/A

larFaultReason Re-routing reason N/A

localSrcSigAddress

Local orig. signaling address N/A

outAniTypeOfNumber

SRC number type N/A

packetType Packet type: 1=START, 2=STOP Packet type: 1=START, 2=STOP

proto Protocol. Protocol.

radiusForceOriginateTelephony

N/A If "h323-call-type" has "Telephony"string

radiusNasPortNam N/A RADIUS port name

Operating TM

Page 164


e

radiusUser RADIUS user name. N/A

remoteMediaAddress, rtpAddress

N/A Media address of the media node

remoteSrcSigAddress

Remote orig. signaling address N/A

routeNum N/A Route sequence number

routeRowId N/A A random value

setupTime SETUP arrive time SETUP arrival time

sigAddress N/A Remote term. signaling address

signalingSrcSigAddress

Signaling address from the signalingpackets

Signaling address from thesignaling packets

sigNodeName Signaling node name N/A

tsCallId Call ID, generated by the TS N/A

tsConfId Conf ID, Generated by the TS N/A

user User name. N/A

zone Zone Zone

pdd N/A PDD.

radiusPassword N/A RADIUS password

As it is clear from the table the variable value depends on the call leg, for which it is used. Besides itis possible to explicitly specify the call leg by using the inLeg. (incoming) and outLeg. (outgoing)qualifiers before the variable name. Take ani variable as an example:

For the incoming leg (the data on which is transmitted in answer packets) the value of anivariable is an SRC number arrived from the gateway.

For the incoming leg (the data on which is transmitted in originate packets) the value of anivariable is an SRC number after applying pre-routing translation rules.

To explicitly define which value to take, use the following statement:

o inLeg.ani – as in the incoming leg;

o outLeg.ani – as in the outgoing leg.

The requested may have no value. In this case the attribute and its value will not be included into theRADIUS packet.

Function available in RADIUS attributes

Name Parameters Desscription Example

toVsaTimeFormat

TimeTime zone

Translation of time toVSA time format:“14:09:27.861 UTC WedOct 01 2008”. Time zonemay defined by twovalues: “UTC” and

toVsaTimeFormat(setupTime,"UTC")

Operating TM

Page 165


“SYSTEM”.

toCiscoConfId Conf ID Translation of Conf ID toCisco conf id format:“00000000 0000000000000000 00000000”

toCiscoConfId(inLeg.confId)

toCiscoCallId Call ID Translation of Call ID toCisco call id format:“00000000 0000000000000000 00000000”

toCiscoCallId(callId)

getIP IpAddress:port Translation of “IP:port”string from“127.0.0.1:1234” to“127.0.0.1”

getIP(gwAddress)

reasonToH323 Universaldisconnect code

Translation of auniversal disconnectcode to a H323 code

reasonToH323(code)

ipFromBin Ip-address as 4bytes

Translation of 4-byte IPaddress into a string“127.0.0.1”

ipFromBin(ip)

replaceAniIn User nameNumber

Replacement of $ANI$metavariable in theusername with thenumber.

replaceAniIn(user, ani)

str Any value Cast of any value tostring

Str(setupTime)

toSeconds A result of timessubtraction

Translation of timessubtraction result intoseconds.

toSeconds(disconnectTime-connectTime)

toCiscoReleaseSource

Call disconnectinitiatorProtocol used

Translation ofdisconnect data intoCisco format:If the call disconnectinitiator is the System,the result is “Internalcall-control application(Tcl or VoiceXMLscript)” - code 7;If the call disconnectinitiator is the originatorand SS7 protocol isused, the result is“Calling party located inPSTN” - code 1;If the call disconnectinitiator is the originatorand SS7 protocol is notused, the result is “Calling party located inVoIP network” - code 2;If the call disconnectinitiator is the terminatorand SS7 protocol isused, the result is

toCiscoReleaseSource(inLeg.disconnectInitiator ,proto)

Operating TM

Page 166


“Calling party located inPSTN” - code 3;If the call disconnectinitiator is the terminatorand SS7 protocol is notused, the result is “Calling party located inVoIP network” - code 4;

RADIUS accounting packets5.11.4

The table RADIUS accounting packets serves to modify and compose new RADIUS accountingpackets, sent to the RADIUS server.

RADIUS accounting packets table

The addition or modification of packets is performed via a two panel dialog.

To add a new packet invoke the context menu and click Add.

Dialog for adding/modification of a packet

In the parameter Packet name define the new packet name.

On the left panel of the Fields dialog is the full list of all attributes from the RADIUS attributes table.On the right panel the fields incorporated into the packet are listed.

The packet composition is modified by including one and removing other fields, as well as bychanging their order.

Operating TM

Page 167

By moving the elements from the left to the right fields are included into the packet. By moving theelements from the right to the left fields are removed from the packet.

Holding down a Shift or a Ctrl key allows you to select several elements at once. Use buttons

and to move the selection from one list to the other.

Use the and buttons to move all records from the left box to the right one and viceversa.

By shifting the element names up and down in the list, using the and , buttons, youcan change the order in which they are put into the RADIUS packet. Elements from the top of the listbecome the first attributes in the packet.

When done click OK.

RADIUS accounting profiles5.11.5

The RADIUS accounting profiles page allows the user to flexibly define the RADIUS accountingparameters and save this parameters to the accounting profiles. The user can change the active profileaccording to his own needs and requirements.

In every given moment of time of all the profiles in the table only one profile may be active.

To activate the profile enter its record ID into the Active RADIUS accounting profile in the RADIUSglobal setting window.

RADIUS accounting profiles table

Initially the System has two profiles configured:

Standard – the profile imitating RADIUS settings for System versions 1.5.2 and below.

Cisco PGW 2200 – the profile the allows the user to flexibly configure the billing information.The composition of the packets corresponds to that of Soft switch Cisco PGW 2200.

To add a new RADIUS accounting profile invoke the context menu and select Add.

Operating TM

Page 168

Adding a new RADIUS accounting profile

Specify the following parameters in the profile window:

* Profile name – name of the RADIUS accounting profile.

* Send ACCT. START/STOP packets – defines an accounting method through the choice of packetsused for accounting and billing. Select the required option from the drop-down list. In case an optionother than Customizable Cisco-compatible is selected, the System composes the packet automaticallyaccording to Appendix E. RTU – RADIUS interaction.

of the incoming leg – when selected makes the System send the RADIUS-server ACCT. START/STOP packets, pertaining to the incoming leg.

of the outgoing leg – when selected makes the System send ACCT. START/STOP packets,pertaining to the outgoing leg.

of both legs – when selected makes the System send ACCT. START/STOP packets, pertainingboth to the incoming and outgoing legs.

of both legs with field substitution – when selected makes the System send ACCT. START/STOPpackets, pertaining to both call legs, and performs the following substitutions in packet fields:

For the incoming leg:

Field name Substituted value

h323-gw-id ID of the termination gateway

h323-gw-address IP address of the termination gateway or gatekeeper used forsignaling

h323-remote-id ID of the origination gateway

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

For the outgoing leg:

Field name Substituted value

h323-gw-id ID of the origination gateway

h323-gw-address IP address of the origination gateway or gatekeeper used for signaling

h323-remote-id ID of the termination gateway

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

of both legs for each rerouting attempt – with this option selected the System sends only one

Operating TM

Page 169

pair of ACCT. START/STOP packets pertaining to the incoming leg.

For example, if the call was rerouted three times, the set of the packets sent to the RADIUS-serverwill be as follows:

Accounting START record for the answer leg

originate leg Accounting START record 1

originate leg Accounting STOP record 1





Accounting STOP record for the answer leg

of the outgoing leg is the default setting.

Customizable Cisco-compatible – when selecting this option the window changes to thefollowing one. The new window allows you to specify the START and STOP packet for theincoming and outgoing legs from the previously defined packets (see section RADIUSaccounting packets):

RADIUS accounting profile view when Customizable Cisco-compatible option is selected

Use old CISCO format – the flag that indicates the preferred accounting format. Select the checkboxto use old CISCO format (overloaded attribute 44). The cleared checkbox means that the used format isCISCO VSA.

Send Accounting Boot message – with this option selected, when the System starts or stopsinteroperation with the RADIUS server (including the emergency restart of the System), it sends theRADIUS server a corresponding Accounting Boot message. The Accounting Boot message is usedto synchronize call state on the RADIUS server with call state in the System, as all calls in the Systemare terminated after emergency restart, so they should be terminated on the RADIUS server.

Send Accounting STOP only – enables/disables sending of Accounting STOP packets only. Selectthe checkbox to have the System send accounting STOP packets only.

START Answer packet – from the dropdown list select a packet (defined in the RADIUS accountingpackets) to be sent to the RADIUS server as a START packet for the incoming call. If an empty optionis selected, the START packet for the incoming call leg will not be sent. The parameter is displayedwhen the Customizable Cisco-compatible option is selected in the Send ACCT.START/STOPpackets parameter.

STOP Answer packet – from the dropdown list select a packet (defined in the RADIUS accountingpackets) to be sent to the RADIUS server as a STOP packet for the incoming call. The parameter is

Operating TM

Page 170

displayed when the Customizable Cisco-compatible option is selected in the Send ACCT.START/STOP packets parameter.

START Originate packet – from the dropdown list select a packet (defined in the RADIUSaccounting packets) to be sent to the RADIUS server as a START packet for the outgoing call. If anempty option is selected, the START packet for the outgoing call leg will not be sent. The parameter isdisplayed when the Customizable Cisco-compatible option is selected in the Send ACCT.START/STOP packets parameter.

STOP Originate packet – from the dropdown list select a packet (defined in the RADIUS accountingpackets) to be sent to the RADIUS server as a STOP packet for the outgoing call. The parameter isdisplayed when the Customizable Cisco-compatible option is selected in the Send ACCT.START/STOP packets parameter.

An example of RADIUS accounting configuration5.11.6

RADIUS server declaration5.11.6.1

First of all it is necessary to define the settings of the RADIUS server with which the System will beinteroperating. In the RADIUS server table invoke the pop-up menu and select Add.

Adding a new RADIUS server record

In the RADIUS server name enter the name of the record. In the example it is Custom RADIUS.

Select the Enable accounting checkbox for the System to dispatch Accounting packets to theRADIUS server. Otherwise this server will not be used for accounting.

Operating TM

Page 171

In the Accounting parameter group defined the address and port of the RADIUS server to which theAccounting packets will be dispatched.

When done click OK.

Using predefined or custom profiles5.11.6.2

The next steps depend on the necessity to use standard RADIUS accounting settings.

The application of standard accounting settings (e.g. the Standard profile) allows the user to emulateSystem operation similar to that of versions 1.5.2 and below. To make use of the standard profile dothe following:

In the table RADIUS accounting profiles create a new profile or modify the existing one. In thefield Send ACCT.START/STOP packets select an option other that Customizable Cisco-compatible (for further information refer to sections RADIUS accounting profiles). Thecomposition of attributes in packets will be according to the set, specified in section RTU -RADIUS interoperation.

In the table RADIUS global settings -> Active RADIUS accounting profile parameter specifythe record ID of the new or modified RADIUS accounting profile.

If it is necessary to define the attributes sent to the RADIUS server in a more flexible way, do thefollowing:

Define the required RADIUS attributes (see section RADIUS attributes configuration);

Distribute attributes among packets (see section RADIUS packet configuration);

Assign packets to a RADIUS accounting profile and active the profile (see section RADIUSprofile configuration).

RADIUS attributes configuration5.11.6.3

After RADIUS server configuration specify the RADIUS attributes to be sent to the RADIUS serverin the RADIUS attributes table.

By way of example let’s take a new attribute mvts-custom-h323-call-id. This record will compriseinformation of the h323-call-id attribute generated by the TS as a string in Cisco format.

To add a new attribute invoke the pop-up menu and select Add.

Adding a new RADIUS attribute

In the Record name parameter specify the record name. In this example it is mvts-custom-h323-call-id.

In the Field name parameter select the name of the attribute in the RADIUS packet from the drop-down list. In this example it is h323-call-id.

In the Code parameter specify the digital code of the attribute. In this example it is 1.

Operating TM

Page 172

In the Vendor code parameter specify the code of the originator of the attribute. In this example it is 9(Cisco VSA).

In the Type parameter specify the type of attribute. In this example it is a string.

In the Value parameter specify the value of the attribute. In this example it is the result of the functiontoCiscoCallId, that takes a callId variable. The callId variable comprises the call ID generated by theTS.

In the Description parameter specify the pertinent information.

When do click OK.

Configure all other required attributes in the similar fashion.

RADIUS packet configuration5.11.6.4

Once attribute configuration is completed it is necessary to group them into different packets.

To do it go to the RADIUS accounting packets table and add anew record using the pop-up menu.

Adding a new RADIUS packet

In the Packet name field specify the name of the RADIUS packet. In this example it is Custom-Packet.

In the Fields window move the required attributes from left to right using the button. In thisexample move the attribute mvts-custom-h323-call-id. The order of attributes in the packet is modified

with the and buttons.

When done click OK.

RADIUS profile configuration5.11.6.5

Once RADIUS packets are set it is necessary to configure a RADIUS accounting profile that governsthe parameters for interoperation with the RADIUS server, including those defining packetcomposition.

Go to RADIUS accounting profiles and using the context menu create a new profile.

Adding a new RADIUS accounting profile

In the Profile name specify the profile name. In this example it is Custom-Profile.

In the parameter Send ACCT.START/STOP packets select Customizable Cisco-compatible. The

Operating TM

Page 173

view of the page will change and new parameters will appear.

In the parameters STOP Answer packet and STOP Originate packet specify the name of thepreviously created packet (Custom-Packet).

When done click OK.

Then it is necessary to activate the profile.

Go to the table RADIUS global settings and in the parameter Active RADIUS accounting profilespecify the record ID of the new profile. In this example it is 4.

Activating a new RADIUS accounting profile

Click OK.

So after the abovementioned procedure is completed The System will send two packets Accounting-Stop upon call disconnect with one field h323-call-id that will comprise a Call ID, generated by the TS,in Cisco format.

RTU Redundancy

Page 174

RTU Redundancy6

System redundancy ensures continuous services (or minimum downtime) and correct entry of CDRsfor terminated calls.

The RTU system has a modular architecture. Thus RTU redundancy is achieved by adding redundantnodes to the configuration.

The nodes to be backed up:

LMN (only one backup node possible).

Scripting node (unlimited number of nodes).

Signaling node (unlimited number of nodes).

Media node (unlimited number of nodes).

Balancer node (unlimited number of nodes).

SS7 Call Agent node (unlimited number of nodes).

Database (only one redundant DB possible).

Nodes that can not be backed up:

Synchro node.

Continuous services and correct entry of CDRs6.1

Service continuity in case of a node failure is achieved under the following conditions:

Backing-up balancer nodes with the help of a Server Load Balancing (SLB)-capable switch (e.g.CISCO Catalyst 4840G) or a Shared-IP mechanism that allow calls to pass to another node.

Backing-up of license management node to avoid complete closedown of the System once 30minutes passed after the LMN failure.

Backing-up SS7 Call Agent nodes to allow SS7 calls pass through another SS7 Call Agentnode.

Guaranteed availability of a full set of other nodes on other servers so that the System couldprocess new calls.

Two nodes are responsible for CDR’s entry into the database – signaling node that terminates the calland scripting nodes that store the CDR. In case of scripting node failure handling the call thesignaling node will send a command to terminate the call to another scripting node. In case ofsignaling node failure the scripting node will detect that the connection to the signaling node hasfailed and enters a CDR to the DB. Thus to ensure correct entry of CDRs the following conditionsshould be met:

The System should comprise at least two scripting nodes so that the signaling node had atleast one scripting node where it can send a message about call termination in case onescripting node fails.

The database should be backed up as it should always be available for CDR entry.

Two-server redundancy configuration6.2

According to this redundancy configuration two servers host a double set on nodes to be backed up.VoIP traffic entry points are backed up using an SLB-capable router or with the help of Shared-IPmechanism (implemented by Linux Heartbeat utility, see section Redundancy using Linux Heartbeat).All SS7 gateways should be connected to at least two SS7 Call Agent nodes on different servers.

RTU Redundancy

Page 175

An example of two-server redundancy configuration

The advantage of this redundancy configuration is its relative simplicity. The disadvantage is theinability to ensure correct CDR storage in case of hardware failures. To mitigate this problem a interimCDR functionality may be used (see section CDRs). For example, if call passes through Signaling-1and Scripting-1 and interim CDRs are disabled, in case of hardware failure of server 1 all data on thecall will be complete lost and no CDR will be entered into the DB on this call.

Four-server redundancy configuration6.3

An extended redundancy configuration is designed to ensure correct storage of CDRs in all cases.

According to the extended configuration the backed up nodes are hosted on four servers accordingto the following rules:

Signaling nodes and scripting nodes should be hosted on different servers to avoid theirsimultaneous failure in case the server fails physically.

At least two scripting nodes should be hosted on different servers so that the signaling nodehad at least one scripting node to send a message about call termination in case one scriptingnode fails.

This means that two servers should host signaling nodes, and the other two – scripting nodes. Anexample of the extended redundancy configuration is shown in the figure below.

RTU Redundancy

Page 176

An example of four-server redundancy configuration

A disadvantage of this configuration is its cost.

Control links interval settings6.4

To minimize system downtime in case of node failure you should adjust the control link intervalsettings accordingly (see section Common sections). The recommended settings are as follows:

link_send_timeout "500";link_recv_timeout "1000";link_restore_timeout "1000";link_reconnect_interval "200";link_connect_interval "1000";

Consider the control link between two nodes A and B. The System operation is as follows:

Node A with the period defined by link_send_timeout sends a keep-alive packet tonode B to which it is linked by a control link.

Each node (in the example - A) waits for any messages from another node (including keep-alivepackets) for the period defined by link_recv_timeout. If after the last message arrivalthe specified amount of time elapsed and no other messages arrived, the TCP connection withthe other node is considered severed. Note during this period node A will store messages,dispatched to B and waiting to be acknowledged by the latter, in its queue. Once the TCPconnection is considered severed node A no longer generates and dispatches new messagesto B.

Once the link_recv_timeout has expired, if the TCP connection is severed a new timeout link_restore_timeout starts, within which with the period defined bylink_reconnect_interval node A tries to restore TCP connection to node B. If thelink_recv_timeout has expired but the TCP connection was not restored, the controllink is considered completely severed and node A start to perform necessary actions in allmessages in its queue (e.g. store CDRs, terminate calls, etc).

RTU Redundancy

Page 177

If node A did not restore the connection within link_recv_timeout, it tries to establish aTCP connection and a control link from the very start with the period oflink_connect_interval.

Thus, as it is derived from the abovementioned the link_recv_timeout controls the number ofmessages dispatched to B when the TCP connection is already severed but is not discovered yet.

Beside downtime these intervals also control the validity of dates and times in CDRs. Specifically incase of a control link failure the time of call termination in the CDR will differ from the actual calltermination by:

Sum of link_recv_timeout and link_restore_timeout (maximum).

Value of link_restore_timeout (minimum).

Media Node6.4.1

When one of the media nodes fails, (as MedNode1) the subscribers, whose talk was enabled by thefaulty node, will probably (if the workload is large) hear voice distortion for a while (some seconds) orsilence in the receiver until the phoenix process automatically restarts the crashed node. Theconversation will continue after the MedNode is restarted and its pre-failure state is restored. If thefaulty MedNode restart turns out impossible for some reason or there is no access to the server onwhich the faulty MedNode1 is installed, voice sessions of new arriving calls are established throughMedNode2, and the SigNode1 will terminate calls passing trough MedNode1 after the timeoutslink_recv_timeout and link_restore_timeout expire.

Diversion of media flows to healthy media node

As soon as MedNode1 is alive again (its serviceability is manifested by a restored link to theSigNode) SigNode1 resumes traffic balancing between MedNode1 and MedNode 2.

Signaling node6.4.2

When a Signaling node fails (as for example SigNode1) all H.323 calls handled by the crashed nodeget terminated, as well as all non-finalized SIP calls (i.e. calls in the process of being set up or a changeof state). Established SIP calls are saved and restored, when the SigNode recovers. The calls thatcould not be restored get terminated correctly.

RTU Redundancy

Page 178

Reassignment of new call arrivals after SigNode1 fails

All new arriving calls will be forwarded to SN2 while SN1 remains inoperative. As soon as SN1resumes functioning, the balancer nodes BN1 and BN2 will again include the SigNodes SN1 and SN2in load balancing.

If the automatic restart fails or there is no network access to the server hosting SigNode1, then afterthe expiry of link_recv_timeout and link_restore_timeout the media node will stop passing media forcalls controlled by the SigNode1 and the scripting node will enter a CDR into the Inaccurate table. Forthe SIP calls no BYE message will be sent.

Scripting node6.4.3

If the automatic restart fails or there is no network access to the server hosting SigNode1, then thealready established call will remain and after their normal termination another scripting will enter aCDR on them into the Inaccurate table. But if interim CDRs is enabled, the calls will be terminated assoon as the System tries to write down an interim CDR.

Balancer node6.4.4

If one of the balancer node fails, all H.323 calls, set up through the faulty node, will be terminated, andall SIP/H.323 registration data, associated with this balancer node, will be lost.

If the automatic restart fails or there is no network access to the server hosting the scripting node,then the H.323 calls will be correctly terminated and CDRs on them will be written into the DB.Balancer node failure does not affect the SIP calls, established using the 302 message. For SIP call,established without 302 message, the signaling transmission will stop, as the result the call may beterminated only after the expiry of the media timeout, if its is configured (gateway parameters Orig.RTP timeout and Term. RTP timeout), or if the maximum call duration is exceeded. In any case anormal CDR will written down for such calls.

SS7 Call Agent node6.4.5

Upon the failure of a SS7 Call Agent node all calls passing through it will be terminated.

RTU Redundancy

Page 179

Synchro node6.4.6

SyncNode serves to keep record of the equipment capacity. There may be only one SyncNode in eachSystem, and it requires no backups. If the SyncNode fails, all set-up calls continue and the Systemaccepts newly arriving calls, though without regard to the existing origination and terminationequipment capacity limitations.

License Management node redundancy6.5

The LMN serves for software license management (that is it reads the USB dongle) and fordisseminates configuration data among other RTU nodes.

When the System starts, the LMN is the first module launched. As other nodes start up, they connectto the LMN and receive configuration files.

LMN redundancy is achieved by adding a stand-by LMN with a copy of the USB dongle.

The parameters governing LNM redundancy are described in section Daemon process ‘phoenix’ andphoenix.conf configuration file.

Thus a configuration with a primary and failover LMN requires the following sample phoenix.conf files:

Example of phoenix.conf configuration file on the primary server:

management primary=192.168.132.1:9000 backup=122.168.132.2:9000phoenix address=127.0.0.1:5000 timeout=7000 count=5 sleep=2000statestore db=phoenix.db trafficlog=traffic.logload type=management name=management-1 mode=main...This example illustrates that the main LMN with the name SYSTEM-1 runs on the server with IP-address 192.168.132.1:9000, while the system with IP 192.168.132.2:9500 hosts the failover LMN.

Deployment of the main and failover LMNs on the same host is not allowed!

You can display the name of the System’s LMN by carrying out the “show status” (“sh st”) commandin the console terminal.

Failover and failback events in the System with Management Node redundancy unfold as follows:

1. When the System starts, the primary LMN is the first to start up. The main USB dongle shouldbe inserted into the server beforehand.

2. The failover LMN starts on the failover server with the duplicate USB dongle inserted. Oncestarted the failover LMN establishes a link with the primary LMN and switches to standbyoperation where it does not interoperate with other functional nodes and does not read theUSB dongle.

3. If the main LMN fails (the System alerts the operator to the event by an e-mail notification), thefailover LMN switches to “active” mode which means:

It reads the USB dongle.

It accepts connections from other nodes of the System.

It performs periodic checks if the link to the primary LMN server is restored.

4. All functional nodes of the System switch to interoperation with the failover LMN within 60seconds. Meanwhile all set-up connections are preserved and newly arriving calls areprocessed.

5. Once the main LMN is alive again (this indicated by restored accessibility of the primaryserver), the failover LMN restores the link with the main LMN, stops interplay with otherSystem nodes and returns to the standby mode.

6. All System nodes switch to interoperation the main LMN. All set-up connections arepreserved and all newly arriving calls are processed.

RTU Redundancy

Page 180

DB and WEB interface server redundnacy6.6

Owing to the RTU architecture specifics the DB unit is not a critical component and its failure doesnot affect the System overall operation.

When the System starts, the ScriptNode reads the entire DB, and further just keeps track of updates.

If the DB host fails, the System continues call handling, based on data as of the moment of the DBlatest update. CDRs get saved to temporary files and pertinent data are later entered in the DB, whenthe connection is restored. Debug calls are not saved. To ensure data retention, unattended DBbackup may be used.

However, to ensure additional reliability the user has an option to configure DB redundancy. To dothis, fill in the proper settings for the failover database in the scripting node configuration file(parameters like dbms_*_slave, see Scripting node configuration) and set up the DB replication (seeDB replication).

In a layout with a redundant DB, if the main DB fails, the scripting node switches over to the failoverDB until the connection the main one is restored. CDR records will be entered into the failover DB.Meanwhile, the System will successively try to restore connection to the main DB. When theconnection is restored, the scripting node switches over to the main database.

Case study: two server System redundancy6.7

RTU Redundancy

Page 181

Node distribution6.7.1

See an example of the two server redundancy configuration of RTU in the figure below.

Nodes of primary and failover server

Configuration files6.7.2

Below are configuration files for the primary and failover servers of the System in the figure above.The IP-address of the main server is 192.168.132.1; the IP-address of the standby server is192.168.132.2.

The node names on the main and redundant server should not coincide.

Primary server configuration6.7.2.1

6.7.2.1.1 Configuration f ile phoenix.conf

management primary=192.168.132.1:9000 backup=122.168.132.2:9000phoenix address=127.0.0.1:5000 timeout=7000 count=5 sleep=2000statestore db=phoenix.db trafficlog=traffic.log

RTU Redundancy

Page 182

load type=management name=management-1 mode=mainload type=balancer name=balancer-1load type=media name=media-1load type=media name=media-2load type=media name=media-3load type=commandline name=commandline-1 address=127.0.0.1:7000load type=scripting name=scripting-1load type=synchro name=synchro-1load type=signaling name=signaling-1

6.7.2.1.2 File system-1.conf

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

6.7.2.1.3 Configuration f ile system-1.balancer.conf

balancer{

balancer "balancer-1"{

common { loglevel "1"; };

controllink { address { "192.168.132.1"; }; port "7101"; };

ras{

address{

"0.0.0.0";};port "1719";gkname "MVTS3G";allow_md5 "yes";allow_chap "yes";allow_plain "yes";

};

sip{

address{

"0.0.0.0";

RTU Redundancy

Page 183

};port "5060";

expiration "1800";};

h323{

address{

"0.0.0.0";};port "1720";

};};

balancer "balancer-2"{

common { loglevel "1"; };

controllink{

address{

"192.168.132.2"; };

port "7101";};

ras{

address{

"0.0.0.0";};port "1719";gkname "MVTS3G";allow_md5 "yes";allow_chap "yes";allow_plain "yes";

};

sip{

address{

"0.0.0.0";};port "5060";

expiration "1800";};

h323{

address{

RTU Redundancy

Page 184

"0.0.0.0";};port "1720";

};};

};

6.7.2.1.4 Configuration f ile system-1.signaling.conf

signaling{

common{

loglevel "1";};

h323{

address{

"0.0.0.0";};port "1721";

}; sip { address {

"0.0.0.0"; };

port "5061";};

synchro{

address { "192.168.132.1"; }; port "7711";

};

signaling "signaling-1"{

controllink{

address{

"192.168.132.1";};port "7050";

}; };

signaling "signaling-2"{

controllink

RTU Redundancy

Page 185

{ address { "192.168.132.2"; }; port "7050"; };

};};

6.7.2.1.5 Configuration f ile system-1.scripting.conf

scripting{

scripting "scripting-1"{

common{

loglevel "0";};

controllink{

address{

"192.168.131.1";};

port "7710";};

loader_path "voip2.loader";environment{

dbms_type_master "MySQL";dbms_name_master "192.168.132.1@rtu";dbms_user_master "rtu";dbms_pswd_master "rtu";

dbms_type_slave "MySQL";dbms_name_slave "192.168.132.1@rtu";dbms_user_slave "rtu";dbms_pswd_slave "rtu";

};};

scripting "scripting-2"{

common{

loglevel "0";};

controllink{

address{

"192.168.131.2";};

RTU Redundancy

Page 186

port "7710";};loader_path "voip2.loader";environment{

dbms_type_master "MySQL";dbms_name_master "192.168.132.2@rtu";dbms_user_master "rtu";dbms_pswd_master "rtu";

dbms_type_slave "MySQL";dbms_name_slave "192.168.132.2@rtu";dbms_user_slave "rtu";dbms_pswd_slave "rtu";

};};

};

6.7.2.1.6 Configuration f ile system-1.media.conf

media{

media "media-1"{

controllink{

address{

"192.168.132.1";};port "7760";

};portrange "10000-19999";

};

media "media-2"{

controllink{

address{

"192.168.132.1";};port "7761";

};portrange "20000-29999";

};

media "media-3"{

controllink{

address{

"192.168.132.1";};port "7762";

};portrange "30000-39999";

RTU Redundancy

Page 187

};

media "media-4"{

controllink{

address{

"192.168.132.2";};port "7760";

};portrange "10000-19999";

};

media "media-5"{

controllink{

address{

"192.168.132.2";};port "7761";

};portrange "20000-29999";

};

media "media-6"{

controllink{

address{

"192.168.132.2";};port "7762";

};portrange "30000-39999";

};};

6.7.2.1.7 Configuration f ile system-1.syncro.conf

synchro{

controllink{

address{

"192.168.132.1";};port "7711";

};

synchro "synchro-1"{};

};

RTU Redundancy

Page 188

6.7.2.1.8 Configuration f ile system-1.zone.conf

zone{

zone "voip"{

"192.168.132.0/24";};

};

Standby server configuration6.7.2.2

6.7.2.2.1 Configuration f ile phoenix.config

management primary=192.168.132.1:9000 backup=122.168.132.2:9000phoenix address=127.0.0.1:5000 timeout=7000 count=5 sleep=2000statestore db=phoenix.db trafficlog=traffic.logload type=management name=management-2 mode=backupload type=balancer name=balancer-2load type=media name=media-4load type=media name=media-5load type=media name=media-6load type=commandline name=commandline-2 address=127.0.0.1:7000load type=scripting name=scripting-2load type=signaling name=signaling-2

Redundancy using Linux Heartbeat6.8

The Linux Heartbeat software enables the deployment of the redundant System with the help of‘shared IP’ mechanism. In the layout with Linux Heartbeat installed the software programmaticallybrings up the so-called “floating” IP address on the main server, where the SIP and H.323 registration-balancer nodes receive incoming calls. The Linux Heartbeat software checks the availability of themain and redundant servers, and in case the main server is offline, brings up the “floating IP” on theredundant server. This means that the calls will be transferred to the registration-balancer node on theredundant server. Once the main server is online again, the Linux Heartbeat software takes down the“floating” IP address on the redundant server and bring it up on the main one. The traffic once againgoes trough the main server.

To back up TS do the following:

1. Install the Linux Heartbeat software on the main and redundant servers and "expect" utility on themain server using the following commands:

aptitude install heartbeat-2

aptitude install expect

2. Configure the Linux Heartbeat software. All heartbeat settings are in /etc/ha.d directory.

File /etc/ha.d/ha.cf (identical for both servers):

udpport 1680ucast eth0 x.x.x.x // x.x.x.x – ip address of the other servernode rtu-masternode rtu-slavelogfacility local7# syslog facilitykeepalive 1warntime 2

RTU Redundancy

Page 189

deadtime 5auto_failback on

Thus we indicate the heartbeat should use the eth0 interface. The rtu-master, rtu-slave names shouldbe the host names of the servers, the uname -a command should return these names, these namesshould be added to the /etc/hosts file.

Then create the file /etc/ha.d/authkeys (identical for both servers) for mutual authenticationof rtu-master and rtu-slave servers. It is not necessary to use sha or md5 algorithms, crc will besufficient to save resources. After the file is created, set the access rights for it to root only (chmod600 /etc/ha.d/authkeys)

File /etc/ha.d/authkeys:

auth 11 crc

The file /etc/ha.d/haresources describes resources managed by rtu-master and rtu-slave.The resources are essentially start/stop scripts, similar to scripts in /etc/init.d. The /etc/ha.d/resource.d directory comprises available (ready to use) scripts. Use the IPaddr resource toactivate an additional IP address on eth0 interface, as well as a script to reconfigure the nodes.

Example of /etc/ha.d/haresources file:

rtu-master IPaddr::89.175.76.155/27/eth0 restart.sh rtu-common

In this example rtu-master is a name of the server where the shared IP should be active,89.175.76.155 - the shared IP, 27 - subnet mask, eth0 - interface where the shared IP will beactivated, restart.sh (full path to the script - /etc/ha.d/resource.d/restart.sh) - ascript that reconfigures the redundant TS, rtu-common - starting script of RTU Class 5 logic.

The restart.sh file should have the rights for execution (added by chmod +x /etc/ha.d/resource.d/restart.sh). haresources files should be identical on both servers.

The TS reconfiguration is required to make the TS balancer node add the shared IP, activated by theheartbeat service, into the active configuration.

An example of reconfiguration scenario:

restart.sh file on the main server:

#!/bin/bash

case $1 instart)/etc/ha.d/resource.d/start_slaveexit 0;;

stop)echo "Hello";;esac

It is required to create a /etc/ha.d/resource.d/start_slave file (with execution right)with the following contents:

#!/usr/bin/expect

spawn telnet localhost 7000expect {*mvts3g|> }send "config /etc/mvts3g/system-1.conf\r"expect {*mvts3g|> }send "quit\r"

restart.sh file on the redundant server:

#!/bin/bash

RTU Redundancy

Page 190

case $1 instart)kill -9 `ps ax | awk '/balancer/ && $0 !~/awk/ {print $1}'`exit 0;;stop)echo "Hello";;esac

3. After everything is ready start the heartbeat service on both servers:

/etc/init.d/heartbeat start

DB backup and recovery6.9

DB backup ensures data retention and database structure preservation and allows recovery from badsituations caused by a corrupted file system, server HDD crash or accidental clearing of informationfrom the DB.

DB specifics affecting backup policy6.9.1

The RTU 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 forMySQL. Data from tables of such type are stored in one or several InnoDB data files. The backup ofsuch tables is carried out with the help of the mysqldump utility organic to the MySQL databasesoftware. When run, the mysqldump utility creates an SQL script for replication of the databasestructure 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”, thereforethis data is stored in the tables of myISAM type (ISAM = indexed sequential access method). Datafrom such tables are saved to special files. Backup of myISAM tables can be performed both bymeans of the mysqldump utility and through simple replication of structure, data and index files inthe file system. As CDR tables are the only ever growing in size tables and the resulting size of dataretention files may prove to be formidable it is reasonable to use the “replicate-in-the-file-system”method of backup for CDR tables.

Call log tables contain no critical data and information from them is not saved during a backup.

The mvts_cdr table is of the special type MERGE. It incorporates no data and only provides aconvenient data handling interface for monthly CDR tables. To put it plainly, this table allows retrievalof data according to any criteria for whatever period of time regardless of in which CDR table and forwhat month the necessary information is actually located. During a backup only the mvts_cdr tablestructure is preserved.

In addition to the tables the DB includes several views and stored procedures also backed up with thehelp of the mysqldump utility.

Backup tools and utilities6.9.2

Database maintenance utilities are stored on the DB server in the directory /usr/local/lib/mvtspro. The same directory contains files pertaining to DB backup:

backupdb.conf – is the DB backup procedure configuration file.

backupdb-cron – an example cron job (for cron configuration directories /etc/cron.daily, /

RTU Redundancy

Page 191

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 ascript 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 theserver.

Configuring SSH public key authentication6.9.3

The DB backup copying can be done both to the local disk drive and to a remote server (over ssh orscp). For the sake of a greater safety it is strongly recommended that a remote server backup methodbe used. If you still opt to save backup copies on the DB server it is advisable to add a specialpurpose hard disk drive to the server.

For unattended DB backup by means of the cron utility with saving the backup copy to a remoteserver password-protected access to the remote server is impossible, therefore it is necessary to setup SSH for open-key authorization. To enable open-key authorization, working as root, launch thessh_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 andpassword for the user account in the name of which backup copy files will be saved on the remoteserver:

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

ssh root@db-server

For the arguments of the ssh command, type user name in lieu of “root” and provide the remote servername or IP address in lieu of “db-server”. If you are not prompted for a password and an accesssession starts, the open key authentication functions properly.

Configuring DB backup6.9.4

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.

RTU Redundancy

Page 192

tmpdir= directory for temporary files. The directory must have enough free space to accommodate theDB backup of a forecasted size (to be more specific, there should be enough free space toaccommodate 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 noremote server and it is planned to save DB backup files locally, i.e. to the DB server, delete this line orcomment 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 theparameter desthost). This directory must be accessible for writing to the user who performs the DBbackup (the user whose name is entered in the parameter destuser, when a remote server is used toaccommodate the backup). If there is no such a directory it will be created automatically.

rotate – the number of directories with latest DB backups in the directory destdir. Count starts from 1and all subsequent backup copies will be written to the directory with the next number. As soon asthe number of folders equals the value of the parameter rotate, the least numbered directory isremoved.

backup_prefix – prefix for names of folders with DB backup copies (for example, backup).

backup_cdrs – flag that can be 1 or 0. The flag determines whether monthly CDRs will be backed up.When the flag is set to 1 monthly CDRs are backed up, when set to 0, there will be no CDR backups.

tables_no_data is a comma-separated list of tables that should not be included in backup copies. Thetable mvts_cdr is the one that needs to be included in the list.

Launching backup6.9.5

The script backupdb.php, that performs the DB backup procedure, should be launched by the userroot or a member user of the group mysql, as the correct performance of the script requires themysql group rights.

When run, the utility backupdb.php creates the files tab1.sql and tab2.sql with tables andother DB objects except the monthly CDR tables. The script makes copies of structure files, data filesand index files for monthly CDR tables that have changed since the time of previous execution. Inaddition the utility creates the file cdr.info with information about the status of saved CDR tables.

Unattended backup arrangements6.9.6

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

DB recovery procedure6.9.7

The script restoredb.sh performs restoration of the DB from a backup copy. The script should belaunched by the user root or a member user of the group mysql, as the correct functioning of thescript 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 scriptentering the name of the recovery DB as the command argument:

./restoredb.sh rtu_restored

RTU Redundancy

Page 193

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

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 tothe backup copy directory in the second command argument, for example:

./restoredb.sh rtu_restored /path/to/backup

DB Replication6.10

Replication is a process of backing up information by transferring it from the main server (masterreplication server) to one or several slave servers to ensure consistency between the DB replicas.

In RTU, replication is used to provide additional fault-tolerance when interoperating with the DB. Incase the main server fails, the System switches to the slave server with the redundant DB.

Replication types6.10.1

Replication can be classified in a variety of ways:

1. By the direction of replication:

Master-slave replication — one-way replication when changes in the master DB aretransmitted to the slave DB only.

Master-master replication — two-way replication when two databases are synchronizedwith each other.

2. By synchronism:

Synchronous replication — the DBMS replicates modified data within the same transaction.The changes take no effect until acknowledged by both the local and the remote server. Inother words, there is only one version of data at every instance of time.

Asynchronous replication — the DBMS replicates the modified data after some time, ratherthan within a transaction. When asynchronous replication takes place, the databases maynot be identical for some time.

3. By replication formats:

Row-based replication — the database management systems share and apply modifiedrows of the table.

Statement-based replication — the database management systems share and execute SQLoperators.

RTU uses two-way master-master asynchronous row-based replication. To arrange for mutual master-master replication, the user should configure a one-way master-salve replication on each of twoMySQL servers.

When using replication with RTU never perform write operations to both databases simultaneously.Write operations are only allowed to one DB at a time only.

Replication configuration6.10.2

Before configuring replication, make sure that the databases on both servers are identical. The easiestway to synchronize data is to copy one DB to the other server entirely. Disconnect all applicationsfrom the databases so that the DBs remain unchanged during the configuration process. Additionally,halt the TS while you are setting up replication.

All commands should be performed with the rights of the OS user “root”.

In case the any password was specified for the MySQL “root” user, add the --passwordparameter to all mysqldump and mysql commands. The MySQL will then ask for a MySQL rootpassword upon command execution.

RTU Redundancy

Page 194

1. Make a snapshot of the main DB using mysqldump:

#> mysqldump --allow-keywords --triggers --routines --opt --hex-blob --databases mvtspro > mvtspro.sql

2. If the DB on the second server already exists, make a back-up copy of it first, using thecommand from step 1. Remove the existing DB from the second server:

#> mysqlmysql> drop database rtu;

3. Copy the mvtspro.sql file, created after step 1, to the second host and create a DB fromthe SQL script:

#> mysql <mvtspro.sql

4. Create a repl user for both databases:

#> mysql mysql> grant replication slave on *.* TO 'repl'@'%' identified by 'slavepass';

5. Stop the slave process of both DBs (no error will occur even if no such process exists) andreset the binary logs:

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

6. Stop both DBs:

#> invoke-rc.d mysql stop

7. Create a configuration file /etc/mysql/conf.d/mvtspro-repl.cnf on one of thehosts. The contents of the file should be as follows:

[mysqld]## * Logging and Replication#

server-id = 10#binlog-format = rowlog_bin = /var/log/mysql/mysql-bin.logexpire_logs_days = 30log-slave-updatesauto-increment-increment = 10auto-increment-offset = 1replicate-same-server-id = 0

report-host = name-of-this-hostreplicate-do-db = mvtsproreplicate-ignore-table = mvtspro.mvts_debug_callreplicate-ignore-table = mvtspro.mvts_debug_call_logreplicate-ignore-table = mvtspro.mvts_debug_registration

master-host = name-of-the-other-hostmaster-user = replmaster-password = slavepasssync_binlog = 1slave-skip-errors=1062,1053

8. Create a configuration file /etc/mysql/conf.d/mvtspro-repl.cnf on the otherhost. The contents of the file should be as follows:

[mysqld]## * Logging and Replication#

RTU Redundancy

Page 195

server-id = 20#binlog-format = rowlog_bin = /var/log/mysql/mysql-bin.logexpire_logs_days = 30log-slave-updatesauto-increment-increment = 10auto-increment-offset = 2replicate-same-server-id = 0

report-host = name-of-this-hostreplicate-do-db = mvtsproreplicate-ignore-table = mvtspro.mvts_debug_callreplicate-ignore-table = mvtspro.mvts_debug_call_logreplicate-ignore-table = mvtspro.mvts_debug_registration

master-host = name-of-the-other-hostmaster-user = replmaster-password = slavepasssync_binlog = 1slave-skip-errors=1062,1053

The distinctions between the two files are in italics.

9. Start both databases:

#> invoke-rc.d mysql start

10.Start the slave process in both databases:

#> mysql mysql> start slave;

11.Use the following MySQL commands to monitor the state of the replication process:

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

The main field showing the state of the replication is the Slave_IO_Status field in the output of theshow slave status \G command. In the normal state the field shows the Waiting for master to sendevent string. If the field shows any other state for a long time, this may indicate a failure in thereplication process. The number and textual representation of the last error are shown in theLast_Errno and Last_Error fields.

Appendix A. Metacharacters, regular expressions and number transformation

Page 196

Appendix A. Metacharacters, regular expressions andnumber transformation

7

Use of metacharacters in search7.1

The comparison operators Like and Not like allow the use of patterns in search. Search patterns mayinclude 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 ‘%’ usedindividually 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 thatoccur 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 thesearch pattern. With the operator Not like the System will output all data that do not correspond tothe search pattern.

Use of regular expressions in search7.2

Regular expressions provide a powerful tool for defining information search criteria. Regularexpressions used in search consist of alphanumeric characters and metacharacters the description ofwhich follows.

Metacharacters

Description

Charactermatch

. Any character

[] Any characters matching those in square brackets

Location

^ Beginning of character string (string head)

$ End of character string (string tail)

Quantitymatching

? Matches zero or one occurrence of the previous expression

* Matches zero or more occurrences of the previous expression


Page 197

+ 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 previousexpression

Alternation

| The alteration operator that matches either the expression before or theexpression after the operator

Grouping

( ) Logical grouping

To instruct the system to treat a metacharacter as an ordinary character, precede the metacharacterwith 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 expressionpattern.

^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 canuse 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" andfollowed 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.

Number transformation7.3

The purpose of number transformation is bringing the calling or called telephone number to thenecessary format. Setting number transformation rules involve the use of regular expressions. As arule a transformation expression consists of two parts – a search pattern and a replacement stringdelimited by the slash «/» character.

Use the brackets «( )» to create separate sections within the search pattern. The replacement stringcan include a replacement sub-string for a section. The replacement substring can be preceded by thesearch pattern section number followed by the backslash symbol «\».


Page 198

The most common number transformation tasks are removal, addition and replacement of numberprefixes.

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.

If it is necessary to separate the replacement sub-string from the following symbols, use the followingnotation: \g<#>, where # is the number of the section in the search pattern. The maximum number ofsections is 99. This notation is required when the figures go straight after the replacement sub-string.

Goal:Add postfix 5555 to all numbers

Transformation pattern:

^(.*)/\g<1>5555 (append postfix 5555 to the ending of any string, i.e. after section 1)

Result:1234567 12345675555

7654321 76543215555, etc.

The same goal can be attained through the use of different translation patterns:

translation pattern ^1234#/0000# is equal in effect to pattern ^1234#(.*)/0000#\1 (replaceprefix 1234# with prefix 0000#).

translation pattern ^/0000# is equal to pattern ^(.*)/0000#\1 (add prefix 0000# to all numbers).

One string can include several translation expressions delimited by semicolons (;). Of all availableexpressions in the string the first that matches the number is used for transformation.

To explain this, consider the following number transformation rules:


Page 199

^78312/01# (add prefix 01# to numbers beginning with 78312).

^7831/02# (add prefix 02# to numbers beginning with 7831).

Such number transformation expression can be written as follows:

^78312/01#;^7831/02#

For the number 78312555555 the application will apply the first pattern and as a result prefix 01# will beadded to the number (01#78312555555). At the same time the second expression will be used fortransformation of the number 78315555555, and the prefix 02# will be added to the number(02#78315555555).

Along with the patterns based on regular expressions you can use several additional keywords:

the keyword rand(n) replaces itself with a random n-digit number. n may take values from 0 to99. For example, any number in the rule ^(.*)/(123)rand(2) is translated into such numbers as12389 or 12322, where the last two digits are random.

the pattern ^$ matches an empty SRC number. This pattern may be used in the search patternonly. For example, the rule ^$/123 will translate all empty SRC numbers into number 123.Replaces the obsolete blank keyword.

Tips and tricks for regular expressions7.4

To speed up regexp processing and, consequentially, the overall System performance the Systemadministrator is encouraged to minimize the number of regular expressions and simplify them. It isrecommended to adhere to the following rules:

Do not indiscriminately use the braces "()" in regexp patterns without number translation (e.g.in Orig. allowed SRC numbers). By way of example, use ^123456.* instead of ^123456(.*). Use braces only when it is really necessary.

Delimit several regexp patterns with "|", not with ";" in all cases but for the DP DST prefixallow patterns parameter. As the ";" character delimits separate regular expressions, it cancause lags during routing due to the increased number of expressions. By way of example, use^123.*|^456.*|789.* instead of ^123.*;456.*;^789.*. In this case threeexpressions will be substituted by one.

Delimit the regexps with semicolons ";" only in the DP DST prefix allow patterns parameter, asit is only valid way to supply DST numbers to the dialpeers. For example, instead of 12345.*|67890.* use 12345.*;67890.*, otherwise the System will not match the number67890 to the pattern 12345.*|67890.*.

Do not start the expressions with "^" in the DP DST prefix allow patterns parameter. Forexample, instead of ^12345.*;^67890.* use 12345.*;67890.*.

In all fields where number translation is used reduce the number of expressions combiningseveral expressions into one. For example, a regexp 1234(.*)/\1;1235(.*)/\1; 1236(.*)/\1 may be combined into 123[4-6](.*)/\1.

When limiting the maximum number length, use a pattern like xxx.{n} in the allowed numbersfield, where xxx is the initial digits of the number and n is the maximum number length minus thenumber of initial digits. For example, to limit the number starting with 1234 with 12 digits use thefollowing pattern: ^1234.{8}.

Appendix B. Codec list generation in RTU

Page 200

Appendix B. Codec list generation in RTU8

Codec matching rules8.1

Stage I. When using SIP some device types send SDP with non-standard codec definitions. The TS isable to identify codecs with standard definitions only. In case the TS is unable to identify codecscompletely, the TM takes over codec identification from the TS.

Stage II. The TM tries to match the partially identified (the codec type is identified, but some rtpmapor fmtp parameters may need correction) or unidentified (the codec type is not identified) codecs fromthe previous stage with the codecs, defined for the equipment in the DB (the Orig. codec group andTerm. codec group parameter). Each codec from the equipment is sequentially compared to the codecsdefined in the TM.

The following rules apply:

Codecs from the TM are checked according to their Precedence in group – from codecs withthe highest precedence to codecs with the lowest precedence.

The rtpmap and fmtp parameters and codec types of codecs from the equipment and codecsfrom the TM are compared against each other. If the fmtp and rtpmap parameters are notdefined for the TM codecs (Use matching pattern for incom. SDP rtpmap and Use matchingpatterns for incom. SDP fmtp checkboxes are deselected respectively) these parameters areconsidered defined according to the standard.

Codecs from the equipment defined in the standard way (that is those codecs that were fullyidentified during stage I) are also compared with those TM codecs that have Match with anycodec of the same type checkbox selected. Codecs from the equipment that are identifiedpartially or not identified at all during the first stage are not compared against codecs withMatch with any codec of the same type checkbox selected.

If a codec from the equipment is compared against a codec with Match with any codec of thesame type checkbox selected and these codecs have the same codec type, this codec isconsidered fully identified and remains in the list of allowed codecs.

If the codec is not identified and is not matched to any codec in the System, this codec isdiscarded.

Thus the System gets a list of allowed codecs for the equipment. If such list is empty during callinitiation, the call will be terminated.

Here is an example of codec matching. The originator sent an SDP with the following codecs from theG.729 codec group:

m=audio 21000 RTP/AVP 18 100 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=true a=rtpmap:100 G729/8000

During the first stage the TS partially identifies them with the following parameters:

The first G.729 codec:

SDP rtpmap = "G729" SDP fmtp = "annexb=true"

The second G.729 codec:

SDP rtpmap = "G729"

The first G.729 codec corresponds to the G.729B codec. The second G.729 codec may be a G.729,G.729A, G.729AB or G.729B codec. To determine which codec matches this codec in the G.729 group,the System uses codec precedence. For example, the following codecs are defined in the System:


Page 201

Identifying codecs of the G.729 group

In this case the G.729 codec (number 2, with the checkbox Match with any codec of the same typeselected) will be used as a default codec. It has the lowest priority and any partially identified codec ofG.729 group without any specific parameters will match this codec in the process of codec matching.

If Pass all changes codec policy is used, two more stages are added.

Stage III. The System performs the same procedure as in stage II but uses codecs defined for theother party as the TM codecs. For example the originator's codecs obtained after stage II areadditionally matched against the terminator’s codecs and vice versa.

Stage IV. The final list of available codecs obtained at stage III is sent to the endpoint equipment(that is, to the terminator if the originator’s codecs were filtered or to the originator if the terminator’scodecs were filtered).

The described codec identification procedure is performed for the originator as well as the terminator.

Thus the codec identification procedure for the Pass all changes codec policy is shown in the figurebelow.

Codec filtering when all changes in codecs are passed

The procedure for codec identification for the Do not pass changes, Pass changes of media type, Passchanges for G.711 codec policies is shown in the figure below.


Page 202

Codec filtering when other codec policies are used

If the final codecs of the originator and terminator after filtering do not match each other, codecconversion takes place if possible.

Codec conversion for video codecs (H.261, H.263) and fax codecs (T.38) is not implemented.

Of the two codec policies (on the originator and terminator) the System selects the strictest one as thefinal policy. The list of policies sorted by strictness (from most to least) is as follows:

Do not pass changes

Pass changes of media type

Pass changes for G.711

Pass all changes

If the established policy is Pass all changes – the System will ignore the Term. codec sorting policysettings and send the codec from one gateway to the other in the order they were received from theirsource gateway.

If the established policy is other than Pass all changes – the System will use Term. codec sortingsettings as follows:

If Term. codec sorting = No sorting, the codecs communicated to the gateway will be in theorder they were in the DB.

If Term. codec sorting = Matching codecs first, the codecs, matching the DB codecs, will beput to the head of the list and communicated to the gateway in the order they were receivedfrom the source equipment.

Proxy policies8.2

To ensure maximum flexibility of media transit through the Traffic Switch, the System provides forsetting individual media proxy modes for each dial peer. The procedure is as follows:

It is possible to select media proxy mode for each dial peer individually from the drop-down listOverride equipment proxy mode in the dial peer properties form (Termination > Dial peers >Advanced settings). The dial peer setting overrides similar setting (Proxy policy) of the terminator (Equipment -> Equipment -> Termination settings). If the proxy override policy on the dial peer is notdefined, the terminator proxy policy will be used.

The final proxy mode is selected according to the following procedure:

Call legs may be in one of two modes – proxying or non-proxying. The modes on both call legsshould coincide.

Initially, before the first route (terminator) is chosen no mode is assigned to any call legs.

When selecting the first terminator the incoming and outgoing call legs are assigned proxymodes as per “Initial call leg mode” column of the table below, depending on the proxy policyapplied. The rules for selecting proxy policies are described above.

If due to any reason the System was unable connect to the first terminator, the System resetsthe proxy mode for the outgoing call leg, leaves the previously selected proxy mode on theincoming call leg and proceeds with the next terminator in the dial peer.

When selecting the second and subsequent gateways the System assigns a proxy mode to theoutgoing leg as per “When selecting a route other than the first, established mode is” column,depending on the proxy mode established on the incoming call leg.

The available proxy policies are shown in the table below.

Proxy policies

Proxy policy Initial call legmode

When selecting a route otherthan the first, establishedmode is

Notes


Page 203

Do not proxymedia

Proxy media

Do not proxymedia

Do not proxymedia

Continue withnon-proxying

Try to stopproxying, iffailed –terminate thecall

Call legs are always in non-proxying mode; they neverswitch into proxying mode.

Try not to proxymedia

Do not proxymedia


Try to stopproxying, iffailed –continueproxying

Call legs may switch intoproxying mode.

Do not proxywheneverpossible

Do not proxymedia


Continueproxying

Call legs may switch intoproxying mode.

Do not proxywheneverpossible, usefirst originatorcodec

Proxy media Start proxying Continueproxying

Proxy initially. If after CONNECTthe first codec in the originator’scodec list matches anyterminator’s codec, then switchinto non-proxying mode usingthis codec. Otherwise continueproxying.

Do not proxywheneverpossible, usefirst commoncodec

Proxy media Start proxying Continueproxying

Proxy initially. If after CONNECTany codec in the originator’scodec list matches anyterminator’s codec, then switchinto non-proxying mode usingthis first common codec.Otherwise continue proxying.

Proxy media Proxy media Start proxying Continueproxying

Call legs are always in proxyingmode; they never switch intonon-proxying mode.

If finally the established mode for both call legs is non-proxying, then the codec policy for bothgateways will be set to Pass all changes. Otherwise the System selects the strictest codec policy forboth gateways.

Appendix C. Default gateways

Page 204

Appendix C. Default gateways9

When several subscribers connect to the System, their gateway settings differ only in billingparameters. To ease the configuration of such gateway, RTU features default gateways, i.e.separate template gateways with all-in-one settings, through which the devices register. Insuch layout the billing information (registration username, password, etc. pertaining to eachsubscriber) is stored on the RADIUS server, preventing the duplication of the data in theSystem. The System operation procedure in such a case unfolds as follows:

System administrator creates a default gateway (object Equipment), selects Default gateway inthe Equipment type combo box and selects the Enable RADIUS authentication checkbox. Tocomplete the configuration, the administrator also needs to specify the allowed and disallowedregistration username patterns (the Allowed registration username patterns/Disallowedregistration username patterns parameter) and the precedence of the default gateway (theDefault gateway precedence parameter).

On arrival of a registration request the System first checks if the name of the registering devicematches any of the names (Registration username parameter) of configured gateways. If not,the System draws up a list of default gateways, sorted by precedence (the value of the Defaultgateway precedence parameter). If the registration name of the device, which issued therequest, matches any pattern defined in the Allowed registration username patterns, and doesnot match any patterns defined in the Disallowed registration username patterns, then suchgateway is included into the list of default gateways. If the list is not empty, the registeringdevice is authenticated through the RADIUS server using the data of the first appropriatedefault gateway on the list and the device’s registration name.

The System supports the receipt of the registration usernames and passwords under thefollowing methods:

o For the SIP-equipment the registration username and password is authenticated usingDigest Authentication.

o For the H.323-equipment the following authentication methods are available:

The H.323-gateway sends the registration username and password in plain text. TheSystem may forward them to the RADIUS server in plain text (if the parameter Systemglobal settings -> Encrypt H.323 plain text password = 0), or may first encrypt it with thesecret key (the Secret key parameter), defined in the RADIUS server settings. In the lattercase the Encrypt H.323 plain text password parameter should be equal to 1. By default the Encrypt H.323 plain text password parameter is 1.

The H.323-gateway sends the registration username and password encrypted using md5.The System forwards them to the RADIUS server unmodified.

The H.323-gateway sends the registration username and password encrypted using CiscoCHAP. The System forwards them to the RADIUS server unmodified.

The System creates a virtual gateway inheriting all the settings of the default gateway. If thegateway is a terminator, the System additionally creates a dial peer with the virtual gatewayincluded into the dial peer’s Equipment list. For the terminator it is also possible to specify theDST numbers source in the Phone numbers source parameter.

The call handling procedure for the virtual gateway, cloned from the default gateway, does nodiffer from the call handling for the gateways, entered into the DB regularly.

Appendix D. SS7 Call Agent node limitations

Page 205

Appendix D. SS7 Call Agent node limitations10

At the moment the SS7 Call Agent node has the following limitations:

Limitation Possible effects

M3UA

The ‘Network Appearance’ and‘Routing Context’ parametersare mandatory

1) This limitation does not conform to the RFC4666 specification.As per the specification the ‘Routing Context’ and ‘NetworkAppearance’ parameters are optional.

2) AS the AS properties on the ASP and SGP side should be thesame, and the configuration capabilities of the SGW equipmentmay be restricted, it may limit the overall number of availableSystem configurations.

For example, on the SS7 gateway the AS and its Routing Key arenot configured explicitly, and there is no option to set the RoutingContext and Network Appearance.

The ‘Network Indicator’parameter is not used forrouting

May cause routing errors when different signaling points havethe same point codes.

The node does not supportseveral local (logical) signalingpoints

The concept of logical signaling points is a basis for supportingcomplex configurations by the SS7 Call Agent node. For example,when one node is connected to several SS7 switches (using oneor several SGWs) and may look for them as one or several SS7switches, depending on the configuration.

Presently the support of several SS7 switches within one TS isimplemented by setting up several SS7 Call Agent nodes, onenode for each local SS7 switch.

ISUP-R

The overlap signaling is notsupported

May cause call routing errors.

Message segmentation is notsupported

May cause problems with calls where segmented messages areused. However, segmented messages are rarely applicable, so theproblems are unlikely.

Continuity testing is notsupported

May cause problems when continuity testing is used by theremote switch. For example, the switch may stop using thecircuits, which failed the test, and eventually decrease the trunkcapacity to zero.

Call suspend and resume (SUS/RES) is not supported

The features basing on this functionality are not supported.

Signal propagation delaydetection is not supported


Automatic reconnect is notsupported


Unrecognized data processingis not supported


Appendix D. SS7 Call Agent node limitations

Page 206

Unexpected data handling is notsupported


MTP congestion control is notsupported


Automatic Congestion Controlis not supported


User subsystem readinessmanagement is not supported


Redundancy

A case of SS7 gateway failurewas not tested. It is stronglyrecommended to set up aredundant gateway andconfigure the SS7 Call Agentnode accordingly.

The failure of a non-redundant SS7 gateway will most like causeproblems.

Initialization of the SS7 CallAgent nodes and switchingbetween them requires sometime for exchanging messageswith MGW, SGW and a remoteSS7 switch.

Usually the message exchange time is little, when there are noproblems in the network. Generally it is defined by the delays inresponses from gateways and remote signaling points, as well asthe scale and complexity of configuration. Calls, active at the timeof the switch, are terminated.

Configuration

Changing configuration of theSS7 Call Agent node ‘on the fly’(without node restarting) is notsupported

To change the SS7 Call Agent node configuration stop the nodeand start it with the new configuration applied. All current callsget terminated and no calls may pass through the System until thenode is online with the new configuration.

Appendix E. RTU – RADIUS interaction

Page 207

Appendix E. RTU – RADIUS interaction11

The three types of services that the RTU may request from a RADIUS server are authorization,accounting and routing.

In all the three cases the request initiator is the RTU session controller. The RADIUS server mayinitiate a communication exchange with the RTU server in one situation only: when it requires of theRTU to terminate a call due to depletion of the account balance.

With the authorization and routing service the RTU sends the RADIUS server an AccessRequest ofthe appropriate type and receives either an AccessAccept or AccessReject. During an accountingexchange the RTU originates an AccountingRequest (Code 4) while the RADIUS server replies withAccountingResponse.

When the exchange initiator is the RADIUS server, it sends the RTU DisconnectRequest (type 40),and the RTU responds with DisconnectAck(type41) for session termination or with DisconnectNack(type 42) for the request rejection.

Below is a detailed description of the RTU-RADIUS server exchange content.

Registering endpoint authorization11.1

The RTU sends the RADIUS server this type of authorization request on arrival ofRegistrationRequest received by the RTU from the registering endpoint.

AccessRequest structure in authorization request for a registering endpoint

IETFattr.No.

Attributename

VSAattr.No.

Description Data format Mandatory/Optional(M/O)

4 NAS-IP-Address

Local RTU address Defined by the«radius_nas_ip_addr» parameter from theconfig file, by default- «127.0.0.1»

M

5 NAS-Port-Type

Local port type always 0 M

6 Service-Type Service type always 1 M

26 xpgk-request-type

1 Authorizationrequest type

always «user» M

1 User-Name User name string M

2 User-Password Password encryptedthrough MD5 or inthe plain form

BYTE[16] or string O

26 xpgk-md5-auth 1 Password encryptedthrough MD5


3 CHAP-Password

CHAP-encryptedpassword

string O

60 CHAP-Challenge

Unique CHAPidentifier

string O

104 Digest-Realm Describes acomponent of

string O


Page 208

IETFattr.No.

Attributename

VSAattr.No.

Description Data format Mandatory/Optional(M/O)

protected RADIUSserver realm

105 Digest-Nonce Used as acomponent forDigest authorizationscenario

string O

109 Digest-URI Unique URI forDigest authorizationscenario

string O

108 Digest-Method

Method type forDigest authorizationscenario

string O

103 Digest-Response

Used as acomponent forDigest authorizationscenario

string O

115 Digest-Username

User name string M

Expected responses are AccessAccept and AccessReject

On receipt of AccessReject the authorization is deemed rejected and the RTU sends the registeringuser RegistrationReject with the cause SecurityDenial.

Pre-routing call authorization11.2

The RTU sends the RADIUS server this type of authorization request before forwarding the call todestination along the selected path.

AccessRequest structure in pre-routing call authorization

IETFattr.No.

Attributename

VSAattr.No.

Description Data formatMandatory/Optional (M/O)

1 User-Name

User name string,If the username contains the «$ani$»metasymbol, the metasymbol isreplaced with an outgoing SRC number

M

2 User-Password

Passwordencrypted usingMD5, or in theplain form

BYTE[16] or string M

4 NAS-IP-Addres

Local RTU address Defined by the «radius_nas_ip_addr»parameter from the config file, bydefault - «127.0.0.1»

M


Page 209

IETFattr.No.

Attributename

VSAattr.No.


s

5 NAS-Port

Local RTU port always 0 M

5 NAS-Port-Type


6 Service-Type

Service type always 1 M

7 Framed-Protocol

This attributeindicates theframing to be usedfor framed access.

always 1 M



always "number" M

30 Calling-Station-Id

SRC number string M

31 Called-Station-Id

DST number string M

26 h323-conf-id

24 Conference ID h323-conf-id=<HEX[16]> M

26 h323-call-id

1 Call ID h323-call-id=<HEX[16]> M

26 h323-gw-id

33 Originator ID forthe RADIUS server

h323-gw-id=<string> M

26 h323-gw-address

23 Originator IPaddress

h323-gw-address=<IP-address> M

26 xpgk-src-number-in

1 SRC number,received in aSETUP packet

xpgk-src-number-in=<number> M

26 xpgk-src-number-out

1 SRC number, sentto the terminator

xpgk-src-number-out=<number> M


Page 210

IETFattr.No.

Attributename

VSAattr.No.


26 xpgk-dst-number-in

1 DST number,received in aSETUP packet

xpgk-dst-number-in=<number> M

26 xpgk-dst-number-out

1 DST number, sentto the terminator

xpgk-dst-number-out=<number> M

44 Acct-Session-Id

Unique ID string M

26 xpgk-record-id

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

26 xpgk-route-retries

1 Current retrynumber

always 1 M

26 h323-remote-id

1 Terminator ID forthe RADIUS server

h323-remote-id=<string> M

26 h323-remote-address

23 Terminator IPaddress

h323-remote-address=<ip-address> M

26 xpgk-md5-auth

1 MD5 passwordtaken from SETUPregistrationRequest

xpgk-md5-auth=<username/<timestamp>>/HEX[16]

O

3 CHAP-Password


string O

60 CHAP-Challenge


string O

104 Digest-Realm

Describes acomponent ofprotected RADIUSserver realm

string O

105 Digest-Nonce

Used as acomponent forDigestauthorizationscenario

string O


Page 211

IETFattr.No.

Attributename

VSAattr.No.


109 Digest-URI

Unique URI forDigestauthorizationscenario

string O

108 Digest-Method

Method type forDigestauthorizationscenario

string O

103 Digest-Response

Used as acomponent forDigestauthorizationscenario

string O

115 Digest-Username

User name string O

Expected responses are AccessAccept and AccessReject

Content of AccessAccept response from RADIUS server in pre-routing call authorization

IETFattr.No.

Attribute nameVSAattr.No.

Description Data formatMandatory/Optional(M/O)

26 h323-credit-time

102 Session max length h323-credit-time=<time, sec>

O

26 h323-return-code

103 h323-return-code (ifthe field is notpresent or its valueis 0, 13, 51 or 52,the authorization isconsideredsuccessful,otherwise the callwill be finished)

h323-return-code=<number>

M

27 Session-Timeout

Session max length integer O

26 h323-ivr-in 1 Used as User-Namein Accountingpackets

string O

A receipt of AccessReject means a negated authorization and the route is rejected with theappropriate local disconnect code (LDC).


Page 212

Accounting Start record11.2.1

The RTU sends the RADIUS server the Accounting Start record upon arrival of a call (incoming leg)or on sending SETUP to the destination gateway (outgoing leg).

Request type – AccountingRequest (Code 4)

Structure of Accounting Start record forwarded to RADIUS server

IETFattr.No.

Attribute name

VSAattr.No.

Description

Data formatMandatory/Optional (M/O)

1 User-Name Username

string,If the username contains the«$ani$» metasymbol, themetasymbol is replaced with anoutgoing SRC number

M

4 NAS-IP-Address LocalRTUaddress

Defined by the«radius_nas_ip_addr»parameter from the config file,by default - «127.0.0.1»

M

5 NAS-Port-Type Local porttype

always 0 M

6 Service-Type Servicetype

always 1 M

41 Acct-Delay-Time Time (insec),duringwhich theclient willtry tosendAccounting packet

always 0 M

30 Calling-Station-Id SRCnumber

string M

31 Called-Station-Id DSTnumber

string M

26 h323-setup-time 25 SETUPreceipttime

h323-setup-time=< hh:mm:ss.uuu t www MMM dd yyyy>

M

26 h323-connect-time 28 Connecttime

h323-connect-time=< hh:mm:ss.uuu t www MMM dd yyyy>

M

26 h323-conf-id 24 Conference ID

h323-conf-id=<HEX[16]> M

26 h323-call-id 1 Call ID h323-call-id=<HEX[16]> M


Page 213

IETFattr.No.

Attribute name

VSAattr.No.

Description


26 xpgk-src-number-in 1 SRCnumber,receivedin aSETUPpacket

xpgk-src-number-in=<number> M

26 xpgk-src-number-out 1 SRCnumber,sent totheterminator

xpgk-src-number-out=<number>

M

26 xpgk-dst-number-in 1 DSTnumber,receivedin aSETUPpacket

xpgk-dst-number-in=<number> M

26 xpgk-dst-number-out 1 DSTnumber,sent totheterminator

xpgk-dst-number-out=<number>

M

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

26 xpgk-route-retries 1 Currentretrynumber

xpgk-route-retries=<number> M

26 h323-call-type 27 Call type always “h323-call-type=VoIP” M

26 h323-call-origin 26 Call leg,to whichthe packetpertains

For the originating leg always“h323-call-origin=answer”, forthe terminating leg always“h323-call-origin=originate”

M

44 Acct-Session-Id ID forStart-Stoppair ofAccountingpackets

Format detailed after the table M

26 h323-gw-id 33 OriginatorID for theRADIUSserver


26 h323-gw-address 1 OriginatorIPaddress

h323-gw-address=<IP-address>

M


Page 214

IETFattr.No.

Attribute name

VSAattr.No.

Description


26 h323-remote-id 1 Terminator ID

h323-remote-id=<string> M

26 h323-remote-address 23 Terminator IPaddress

h323-remote-address=<IP-address>

M

40 Acct-Status-Type Type ofAccounting packet

always «1» M

26 xpgk_centrex_cookie 1 UniquesessionID

xpgk_centrex_cookie=<number>

O

26 xpgk_centrex_dvo 1 VASservicesindicator(1 - used,0 - notused)

xpgk_centrex_dvo=<number> O

26 xpgk_centrex_calltype

1 Call type xpgk_centrex_calltype=<number>

O

26 xpgk_centrex_source 1 Centrexsource ID

xpgk_centrex_source=<number>

O

26 xpgk_centrex_destination

1 Centrexdestination ID

xpgk_centrex_destination=<number>

O

26 xpgk_centrex_billing_id

1 Billing ID xpgk_centrex_billing_id=<number>

O

26 xpgk_centrex_line_name

1 Subscriber linename

xpgk_centrex_line_name=<linename>

O

26 xpgk-src-codec 1 Originatorcodec list

xpgk-src-codec=<codecs' list> O

26 xpgk-dst-codec 1 Terminator codeclist

xpgk-dst-codec=<codecs' list> O

In the Acct-Session-Id field information is presented as follows:

<prefix>-<leg type><route number>

where

<prefix> is a random 8-digit hexadecimal number, delimited with "-".

<leg type> - AV for the incoming leg and OV for the outgoing leg.

<route number> is the current call termination attempt number.


Page 215

Expected response is AccountingResponse.

Accounting Stop record11.2.2

The RTU sends the RADIUS server the Accounting Stop record on call termination. Request type –AccountingRequest (Code 4).

Structure of the Accounting Stop record sent to RADIUS server

IETFattr.No.

Attribute name

VSAattr.No.


1 User-Name User name string,If the username containsthe «$ani$» metasymbol,the metasymbol isreplaced with an outgoingSRC number

M

4 NAS-IP-Address Local RTU address Defined by the«radius_nas_ip_addr»parameter from the configfile, by default -«127.0.0.1»

M

5 NAS-Port-Type Local port type always 0 M


41 Acct-Delay-Time Time (in sec), duringwhich the client willattempt to sendAccounting packet

always 0 M

30 Calling-Station-Id SRC number string M

31 Called-Station-Id DST number string M

26 h323-setup-time 25 SETUP receipt time h323-setup-time=< hh:mm:ss.uuu t www MMM ddyyyy>

M

26 h323-connect-time 28 Connect time h323-connect-time=< hh:mm:ss.uuu t www MMMdd yyyy>

M

26 h323-disconnect-time

29 Disconnect time h323-disconnect-time=<hh:mm:ss.uuu t wwwMMM dd yyyy>

M

26 h323-conf-id 24 Conference ID h323-conf-id=<HEX[16]> M

26 h323-call-id 1 Call ID h323-call-id=<HEX[16]> M


1 SRC number, receivedin a SETUP packet

xpgk-src-number-in=<number>

O


Page 216

IETFattr.No.

Attribute name

VSAattr.No.



1 SRC number, sent tothe terminator


M


1 DST number,received in a SETUPpacket

xpgk-dst-number-in=<number>

O


1 DST number, sent tothe terminator


M

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

26 xpgk-route-retries 1 Current retry number xpgk-route-retries=<number>

M

26 h323-call-type 27 Call type:"Conference";"Forward","FollowMe", "CallTransfer", "GroupCall","AutoDial","AlarmCall","AutoDialCBCallTerminator","AutoDialCBCallOriginator", "PickUp","CallWaiting","VoiceMail";

always “h323-call-type=VoIP”

M

26 h323-call-origin 26 Call leg, to which thepacket pertains

For the originating legalways “h323-call-origin=answer”, for theterminating leg always“h323-call-origin=originate”

M

44 Acct-Session-Id ID for Start-Stop pairof Accountingpackets

Format detailed after thetable

M

26 h323-gw-id 33 Originator ID for theRADIUS server


26 h323-gw-address 1 Originator IP address h323-gw-address=<IP-address>

M

26 h323-remote-id 1 Terminator ID h323-remote-id=<string> M

26 h323-remote-address

23 Terminator IP address h323-remote-address=<IP-address>

M

40 Acct-Status-Type Type of Accountingpacket

always “2” O


Page 217

IETFattr.No.

Attribute name

VSAattr.No.


26 xpgk-scd-time 1 Interval between theSETUP andCONNECT messageor call teardown inthe absence ofCONNECT

xpgk-scd-time=<number> O

26 xpgk-pdd-time 1 Interval betweendialing the last digitand hearing the RBT

xpgk-pdd-time=<number> O

26 h323-disconnect-cause

30 Disconnect causecode

h323-disconnect-cause=<number>

M

26 xpgk-local-disconnect-cause

1 Local call disconnectcode

xpgk-local-disconnect-cause=<number>

O

26 xpgk-source-rtp-address

1 Media source IPaddress

xpgk-source-rtp-address=<IP-address>

O

26 xpgk-dest-rtp-address

1 Media destination IPaddress

xpgk-dest-rtp-address=<IP-address>

O

26 xpgk-source-faststart

1 Source Faststartcapability

xpgk-source-faststart=<number>

O

26 xpgk-destination-faststart

1 Destination Faststartcapability

xpgk-destination-faststart=<number>

O

26 xpgk_centrex_cookie

1 Unique session ID xpgk_centrex_cookie=<number>

O

26 xpgk_centrex_dvo 1 VAS servicesindicator (1 - used, 0 -not used)

xpgk_centrex_dvo=<number>

O

26 xpgk_centrex_calltype

1 Call type:"Conference";"Forward","FollowMe", "CallTransfer", "GroupCall","AutoDial","AlarmCall","AutoDialCBCallTerminator","AutoDialCBCallOriginator", "PickUp","CallWaiting","VoiceMail";

xpgk_centrex_calltype=<number>

O

26 xpgk_centrex_source

1 Centrex source ID xpgk_centrex_source=<number>

O


Page 218

IETFattr.No.

Attribute name

VSAattr.No.


26 xpgk_centrex_destination

1 Centrex destinationID

xpgk_centrex_destination=<number>

O

26 xpgk_centrex_billing_id

1 Billing ID xpgk_centrex_billing_id=<number>

O

26 xpgk_centrex_line_name

1 Subscriber line name xpgk_centrex_line_name=<line name>

O

26 xpgk-src-codec 1 Originator codec list xpgk-src-codec=<codecs'list>

O

26 xpgk-dst-codec 1 Terminator codec list xpgk-dst-codec=<codecs'list>

O


<prefix>-<leg type><route number>

where

<prefix> is a random 8-digit hexadecimal number, delimited with “-”.

<leg type> - AV for the incoming leg and OV for the outgoing leg.


Expected response – AccountingResponse.

AccessRequest structure for RADIUS-aided routing11.3

The RTU sends the RADIUS server a routing AccessRequest when gateway, acting as a terminator, ismarked as RADIUS routing server.

The RTU’s request is aimed at getting a list of routing options for termination of the call at itsdestination point. In addition the RTU affords the possibility to change the username and passwordfor the call in question.

The RTU can handle several route options sequentially attempting every next route after a successfulcall termination through the previous one proves impossible.

The type of request is AccessRequest (Code 1).

Structure of routing request sent to RADIUS server

IETFattr.No.

Attributename

VSAattr.No.


1 User name Username String M

2 User passwdPassword encryptedusing MD5, or in theplain form


44 Acct-Session-Id

ID for Start-Stoppair of Accountingpackets

Format detailed afterthe table

M


Page 219

IETFattr.No.

Attributename

VSAattr.No.


1 User-Name User name string M

2 User-Password Password encryptedusing MD5, or in theplain form


4 NAS-IP-Address

Local RTU address Defined by the«radius_nas_ip_addr» parameter from theconfig file, by default- «127.0.0.1»

M

5 NAS-Port-Type





always "route" M

30 Calling-Station-Id

SRC number string M

31 Called-Station-Id

DST number string M

26 h323-conf-id 24 Conference ID h323-conf-id=<HEX[16]>

M

26 h323-call-id 1 Call ID h323-call-id=<HEX[16]>

M


1 SRC number,received in a SETUPpacket

xpgk-src-number-in=<number>

M


1 SRC number, sent tothe terminator


M


1 DST number,received in a SETUPpacket

xpgk-dst-number-in=<number>

M


1 DST number, sent tothe terminator


M

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

M

26 xpgk-route-retries

1 Current retrynumber

xpgk-route-retries=<number>

M

26 h323-gw-id 33 Originator ID for theRADIUS server


26 h323-gw- 1 Originator IP h323-gw- M


Page 220

IETFattr.No.

Attributename

VSAattr.No.


address address address=<IP-address>

2 User-Password Password encryptedusing MD5, or in theplain form


26 xpgk-md5-auth 1 Password encryptedusing MD5


3 CHAP-Password


string O

60 CHAP-Challenge


string O

104 Digest-Realm Describes acomponent ofprotected RADIUSserver realm

string O

105 Digest-Nonce Used as acomponent forDigest authorizationscenario

string O

109 Digest-URI Unique URI forDigest authorizationscenario

string O

108 Digest-Method

Method type forDigest authorizationscenario

string O

103 Digest-Response

Used as acomponent forDigest authorizationscenario

string O

115 Digest-Username

User name string O


<prefix>-<route number>

where

<prefix> is a random 8-digit hexadecimal number, delimited with "-".


Expected response – AccessAccept, AccessReject.

Structure of AccessAccept response from RADIUS server


Page 221

IETFattr.No.

Attributename

VSAattr.No.


26 h323-return-code

103 h323-return-code (if the field is notpresent or its value is 0, 13, 51 or 52,the authorization is consideredsuccessful, otherwise the call will befinished)

h323-return-code=<number>

M

26 xpgk-xrouting-routing

252 Set of routes for termination of thecall (can be several ones, in thatcase they will be handled in thesame order as they go in the packet)

Format detailedafter the table

O

26 xpgk-xrouting-username

251 Translation of username andpassword for the session (only onefield in packet)

<username>/<password>

O

26 h323-ivr-in 1 Used as User-Name in Accountingpackets

string O

Field XPGK_XROUTING_ROUTING detailed11.3.1

gateway/proxy_mode/source/dest/src_bill/dst_bill/ip-address[:port]/converter/extra

where:

gateway – GW name from the Equipment record;

proxy_mode – mode of proxy operation:

0 – media proxying disabled.

1 – media proxying enabled.

2 – use proxying mode of originating gateway.

3 - use proxying mode of terminating gateway.

source – calling number (src_number).

dest – called party number that will be sent to the terminating gateway (dst_number).

src_bill – calling number for the billing system.

dst_bill – called number for the billing system.

ip-address[:port] – IP address for connection (port number is optional).

converter – name of the record for the converter through which the call is to be terminated.

extra – extra parameters.

AccessReject – route authorization failed and the route is rejected with the appropriate localdisconnect code.

Authentication of registering devices on a RADIUS-server11.4

There are several RADIUS authentication scenarios depending on the authentication types supportedby the registering equipment.

H.323 ID-based authentication (standard RADIUS authentication)

MD5 hash password authentication


Page 222

Chap authentication

Digest authentication

H.323 ID-based authentication (standard RADIUS authentication)11.4.1

During standard RADIUS authentication the registering endpoint sends the RTU an AccessRequestpacket with the user’s ID in the field terminalAlias (marked with the red ellipse in the figure below).The user’s ID consists of the user’s name and password delimited by one of the following symbols:«|», «:», «!» or «%».

Upon receipt of the packet, the RTU forwards to the RADIUS server an access request (marked withthe red rectangle) with the user’s name, password, the RTU identifier and port the registeringendpoint attempts to access. The password undergoes MD5 hash encryption and is obtained from:

UserPassword = MD5Hash(Shared Secret, RemoteAuthenticator) XOR password,

where

Shared Secret is the value of the parameter Secret key in the RADIUS server settings.

RemoteAuthenticator is a pseudorandom number present in the header of the AccessRequest packetreceived from the registering endpoint.

password denotes the user’s password available from the RTU database.

Standard RADIUS authentication

Based on the received data and the shared secret established between the RTU and the RADIUSserver, the RADIUS server generates an MD5 hash and if the newly generated hash matches the onereceived from the RTU, the RADIUS server responds with AccessAccept, otherwise the server’sreply is AccessReject.

MD5 Authentication11.4.2

With this type of authentication involved the GatekeeperRequest that the RTU receives from theregistering endpoint contains the information that the endpoint is supportive of this authenticationmethod. Upon receipt of the GatekeeperConfirm packet from the RTU, the endpoint responds with aregistration request containing the user’s alias, time stamp, MD5 hash password and data about theparameters used for the hash generation (marked with the red ellipse in the figure below). As the RTUis unaware of the user’s true password, it sends the hashed password in the field xpgk-md5-auth(marked with the red rectangle) together with the parameters used for its generation rather than in thefield password. The RADIUS server must possess the capability to read the field xpgk-md5-auth.

.


Page 223

MD5 authentication

CHAP Authentication11.4.3

With CHAP authentication the GatekeeperRequest that the RTU receives from the registeringendpoint contains the information that the endpoint is supportive of this authentication method. TheRTU responds with a GatekeeperConfirm packet that includes the ‘challenge’ (a pseudorandomhexadecimal number). The registering user sends the RTU a registration request the field tokens ofwhich contains the challenge and the hashed password generated using the challenge, the user’spassword and identifier. Following this the RTU sends the RADIUS server a registration request withthe data as below:

CHAP-Password – the hashed password generated by the user;

CHAP-Challenge – the challenge;

User-Name - the user’s name.

The figure below shows an example of the RTU registration request.

CHAP authentication

The RADIUS server reads the fields CHAP-Password, CHAP-Challenge and searches its database forthe user’s password using the user’s name for the search argument. Based on the found password,the user’s name and the challenge the RADIUS server is expected to generate an identical hash. If thehash generated by the RADIUS server does not match the hash received from the RTU, theauthentication attempt is rejected.

Digest authentication11.4.4

Digest authentication is used for authorization of SIP endpoints. A digest authentication procedureincludes the following steps:

The registering endpoint sends the registration-balancer node a registration request (the


Page 224

packet “REGISTER”)

The registration-balancer node responds to the request with packet 401 containing the so-called “nonce”, i.e. a pseudorandom number.

Using the received “nonce” and some other data the registering user generates an MD5 hash(DigestResponse) and sends it back along with the data used for its generation in theREGISTER response packet.

The registration-balancer node forwards to the RTU a registration request containing in thefield tokens a certificate comprised of the user generated MD5 hash and the data used for itsgeneration.

The RTU uses an AccessRequest packet to provide the RADIUS server with the user’s MD5hash and the hash generation data.

Based on the received data and the user’s password stored in the database the RADIUS serveris supposed generate an identical MD5 hash. In case the hash generated by the RADIUSserver coincides with the hash received from the MVTS in the Digest-Response attribute, theuser is authenticated, otherwise the authentication fails.

Digest authentication

Call disconnect upon Packet of Disconnect arrival11.5

This feature allows the RADIUS server to terminate any call by sending a Packet of Disconnect to theSystem. The packets and their composition is per RFC 3576.

The call disconnect procedure unfolds as follows:

RTU receives a Packet-of-Disconnect on any port (authorization, accounting or externalrouting). The packet should comprise an ID of the conference to be disconnected.

Upon packet arrival the System checks if the conference with the ID specified exists.

o If the conference exists, the System terminates it and sends a Disconnect-ACK message tothe RADIUS server.

o Otherwise the System sends Disconnect-NACK.

The System disconnects always active calls upon Packet of Disconnect arrival regardless of thesettings.

Messages associated with Packet-of-Disconnect


Page 225

Message RFC 3576message code

Message attributes

Packet-of-Disconnect

40 h323-conf-id — ID of the conference to bedisconnected. The ID was generated by the TS. The attributeshould comprise the same value as the h323-conf-id, inAccess-Request, Accounting-Request.

h323-incoming-conf-id - ID of the conference to bedisconnected. The ID was received from the equipment. Theattribute should comprise the same value as the h323-incoming-conf-id, in Access-Request, Accounting-Request.

The System expects the arrival of h323-conf-id orh323-incoming-conf-id. If both attributes arrived inthe packet, the System uses h323-conf-id.

Disconnect-ACK 41 N/A.

Disconnect-NACK

42 N/A.

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

Appendix F. Removing CDRs from the DB

Page 226

Appendix F. Removing CDRs from the DB12

To remove CDRs from the DB do the following:

Removing CDRs is irreversible.

1. In the MySQL console enter the command:

alter table mvts_cdr union=(mvts_cdr_model);

2. Remove all unnecessary CDR tables in the MySQL console. For example:

drop table mvts_cdr_200801



3. In the shell execute the following command:

/usr/local/lib/mvtspro/mvtsprodb.py --user=rtu --pass=rtu --db=mvtsproupdate_merge_cdr

Appendix G. RTU utilities

Page 227

Appendix G. RTU utilities13

Enter topic text here.

The mvtspro-checker utility13.1

The mvtspro-checker utility is designed to check the System as a whole for correct operationand allows the user to do the following:

1. check existence of the default directories where the data is temporarily backed up.

2. verify the consistency of tables for saving CDRs and availability of triggers for the selectedtables.

3. check existence of the mvts3g-sqlclient and mvts3g-sclient utilities.

4. output the info about the disk space used.

5. output the info about the memory and CPU used.

6. output the info about the node state.

To invoke the utility use the mvtspro-checker command.

The configuration file of the utilities in located along the following path /etc/mvts3g/mvtspro-checker.conf

Each line should comprise a record of type “variable = value”.

The parameters in the configuration file are grouped by sections depending on the type of verificationperformed. The list of parameters and their description:

The Checking modules section: parameters defining what verification procedures should beperformed.

Name Defaultvalue

Description

directory yes If “yes”, check existence of the default directories where the data istemporarily backed up.

database yes If “yes”, verify the consistency of tables for saving CDRs andavailability of triggers for the selected tables.

mvts3gutils yes If “yes”, check existence of the mvts3g-sqlclient and mvts3g-sclientutilities.

diskspace yes If “yes”, output the info about the disk space used.

memcpu yes If “yes”, output the info about the memory and CPU used.

ts yes If “yes”, output the info about the node state.

The Data Base section describes the DB parameters.

Name Defaultvalue

Description

host localhost IP-address or host domain name where the DB is located.

name mvtspro DB scheme name.

user rtu DB user name.

passwd rtu DB user password.


Page 228

triggers4tables

mvts_gateway,mvts_dialpeer

List of tables, for which the trigger availability will be checked.

The TS section describes the parameters for connecting to the TS via telnet.

Name Defaultvalue

Description

commandlineIP localhost IP-address or host domain name where the TS is located.

commandlinePort 7000 Port that the TS CLI node listens.

The mvtspro-cdr-restorer utility13.2

The mvtspro-cdr-restorer utility to insert all saved CDRs to the DB is added to the RTUinstallation bundle.

To invoke the utility use the mvtspro-cdr-restorer command.

The configuration file of the utilities in located along the following path /etc/mvts3g/mvtspro-cdr-restorer.conf.

The blank lines and lines starting with # are ignored.

Each line should comprise a record of type “variable = value”. No variable has a default value.

The list of variables and their descriptions:

Variable name Description

host Name or IP address of the host with the DB.

name Name of the database scheme where the CDRs are inserted.

user Name of the DB user.

passwd Password of the DB user.

path The directory, where the stored CDRs are located.

template The prefix of the filenames, where the CDRs are stored.

nodename Scripting node name.

When setting the template parameter note that the System searches for the files with the savedCDRs using the following pattern:

path + '/' + template + '.*'

The mvtspro-acc-restorer utility13.3

The mvtspro-acc-restorer utility to send the saved Accounting packets (but for AccountingBoot packets) to the RADIUS server at once added to the installation packet.

To use the utility type the mvtspro-acc-restorer command in the console.

Options:

-m – defines the packet sending mode:


Page 229

sync – synchronous mode: the packets are sent one by one; the System does not send thenext packet until it finishes sending the previous one (or the timeout is expired).

async – asynchronous mode: the System send the maximum possible number of packets atonce and waits for responses for any sent packet.

Example:

mvtspro-acc-restorer -m async

The utility configuration file resides in the /etc/mvts3g/mvtspro-acc-restorer.confdirectory.

Blank lines and lines started with # in the configuration file are ignored.

Each line should contain a setting in the form of “variable = value”. The variables have no defaultvalues.

The list of variables and their description:

Variablenames

Description

host Name or IP address of the computer, hosting the RADIUS server.

port Port where the RADIUS server listens for the incoming Accounting packets.

secret A coding key for communicating with the RADIUS server (same as the Secret keyparameter in the web interface).

retry Number of attempts to send the packet.

timeout Timeout (in ms) for the response from the RADIUS server.

maxpacklen Maximum length of the response packet from the RADIUS server.

path Directory where the Accounting packets are stored.

template Prefix for filenames where the Accounting packets are stored.

When setting the path and template parameters note that the System searches for the files withthe Accounting packets using the template:

path + '/' + template + '.*'

The Disk Space Monitor utility13.4

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

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

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

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

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

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

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

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

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

5. Specify the free disk space limit of the directories in the /etc/mvts3g/mvtspro-


Page 230

diskspace.conf configuration file.

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

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

<directory> <free space limit>

where:

<directory> - the directory check for free space.

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

Appendix H. Balancing SIP and H.323 calls

Page 231

Appendix H. Balancing SIP and H.323 calls14

A registration-balancer node distributes incoming calls between several signaling nodes. The methodof distribution depends on the protocol governing the call.

H.32314.1

Whenever any device connects to a registration-balancer node, the node selects a signaling node(based on standard ASR for this node for the last several seconds) and starts to proxy signalingmessages between the selected node and the device. Thus, for the H.323 protocol all messages passthrough the registration-balancer node in any case.

SIP14.2

With message 302 support

If the calling device is able to handle the 302 message and the registration-balancer nodeconfiguration file has proxying_balancing “no” in the sip section, on arrival of the INVITEmessage the registration-balancer node selects a signaling node (based on standard ASR) andresponds to the device with the 302 message comprising the address of the selected node. Then thedevice sends an INVITE message to the signaling node and all further message exchange between theSystem and the device goes on without the registration-balancer node involved.

Without message 302 support

If the registration-balancer node configuration file has proxying_balancing “yes” in the sipsection, on arrival of the INVITE message the registration-balancer node selects a signaling node(based on standard ASR) and proxies all messages between the signaling node and the devicemodifying them whenever required. Thus, in such a mode the registration-balancer node acts in thesame way as with H.323 calls. This mode is useful for devices that do not support handling ofmessage 302, however the mode significantly increases the load of the registration-balancer nodecompared to the mode when message 302 is used.

Appendix I. NAT router traversal

Page 232

Appendix I. NAT router traversal15

1. The System is able to receive calls from behind NAT routers under SIP and H.323 protocols.The originator may be identified by an IP address of a NAT router and by the signaling IPaddress/port comprised in the signaling messages.

2. The System is able to route calls behind a NAT router using the SIP protocol under thefollowing conditions:

The terminator registers with the System.

The terminator sends a REGISTER message from the same port, which it will use to receivean INVITE message.

The procedure of routing calls behind a NAT router is as follows:

When the terminator dispatches a REGISTER message, the NAT router creates anassociation between the IP address/port of the terminator and IP address/port of theregistration-balancer node.

This association is maintained by the terminator (using the keep-alive packets) or by theSystem (using the OPTIONS packets).

During the call the packets from the respective port of the registration-balancer node aresent to the respective port of the NAT router that forwards them to the terminator and viceversa.

3. The System is able to route calls behind a NAT router under H.323 only when NAT static rulesare defined (these are the rules that define correspondence between the IP address/port of theterminator and IP address/port of the NAT router).

Appendix J. Managing endpoints in RTU

Page 233

Appendix J. Managing endpoints in RTU16

Although RTU is designed to handle transit calls predominantly, it is capable of managing subscribertraffic too. The System assigns a phone number to every subscriber endpoint. The endpoint may ormay not register with the System.

To use this functionality do the following:

Invoke the pop-up menu in the Equipment table and select Add.

Select the Endpoint option in the Equipment type listbox.

In the Endpoint number field specify the phone number of the subscriber (the same rules aswith DST prefix allow patterns in the dial peer settings apply).

Define the registration and other parameters for the endpoint if necessary.

The System automatically creates a dial peer for this endpoint, and after registration (if it isconfigured) the endpoint is able to originate and terminate calls. The implicit dial peer will have thename (visible, for example, in the CDRs) based on the endpoint name: <endpoint name>-epdp. Thisdial peer will not be shown in the Dial peers table. For example, for the endpoint with the nameJohnSmithEP the implicit dial peer will have the name JohnSmithEP-epdp. Such implicit dial peer hasPrecedence equal to 100.

Appendix K. External routing over SIP/H.323

Page 234

Appendix K. External routing over SIP/H.32317

External call routing over SIP and H.323 is implemented in the System.

H.32317.1

For H.323 external routing the System interoperates with the H.323 gatekeeper and makes use of Lxxmessages.

The scheme of interoperation is as follows:

If the System finds a gateway of Gatekeeper type in the list of routes, generated from the dialpeer, the System sends a LRQ message to this gatekeeper.

The gatekeeper responds with a LCF message, comprising numbers and addresses of servers,where the call should be actually routed.

This data replaces the gatekeeper record in the route list and the System proceeding with routeselection procedure as usual.

SIP17.2

SIP external routing is based on handling SIP 300 “Multiple choices” message that comprises a list ofpossible destinations for call termination.

The scheme of interoperation is as follows:

If the System finds a gateway of SIP routing server type in the list of routes, generated from thedial peer, the System sends an INVITE message to this SIP routing server.

The SIP routing server responds with a 300 messages comprising “Contacts” field withnumbers and addresses of servers, where the call should be actually routed.

This data replaces the gatekeeper record in the route list and the System proceeding with routeselection procedure as usual.

Appendix L. Confiiguration of IPSP

Page 235

Appendix L. Confiiguration of IPSP18

The IPSP mode allows the user to establish interoperation between two SS7 signaling points over IPwithout using a signaling gateway.

To set up the IPSP mode on the SS7 Call Agent node, specify the parameters in the nodeconfiguration file, m3ua section as follows:

RIPSP parameter, defining the ID of the remote IPSP;

LIPSP section, the header of which defines the ID of the local IPSP;

Set the role parameter of Association section to Client or Server, depending on therole of the node - if it establishes the association itself (Client) or wait for the association tobe established by the other party (Server).

Set the direction parameter in the RoutingContext section to Both.

Documents

MVTS Pro & RTU 1.5.3-60 Admin Guide