Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
2
Operator's manual
Document №: 2
Document type: Operator’s manual
Document status:
Date of issue: 03.05.2006
Responsible
Technical Writer
employee:
COPYRIGHT INFORMATION
T he in for ma tio n c on taine d in th is doc ume nt is the pro per ty o f Mera Sys te ms Inc.
No pa r t o f th is p ub lica tio n ma y b e rep roduc ed or c op ie d in any fo rm or b y an y
m ea ns - gr aph ic , e lec tro n ic or mec ha nica l i nc l ud ing p ho toc op y in g , r ec o r d ing ,
ta ping , or a n y o ther in fo rma tio n s torag e an d re trie val s ys te m - w i th ou t wr itte n
co nsen t o f Mera Sys te ms Inc . No th ird pa r ty, org an iza tion or ind i vid ua l , is
a u tho riz ed to gra nt s uch per mission .
2
covering the ‘di gk’ command of the administration
console
Added new LDCs to the table of Local Disconnect
Codes (LDCs 134, 135, 136, 137, 132, 213). The table
of LDCs was restructured into a 3-column table
17/02/2006 Release Technical writer
Added description of the console commands ‘show
media’ (displays operational information for media
MVTS) and ‘show converter’ (displays operational
information for the SIP-HIT module)
06/03/2006 Release zabytina: the table of local disconnect codes updated
24.04.2006 Release azharkov: document revised and updated in compliance
with the latest information from developers
11.07.2006 Release azharkov: the section SNMP statistics, updated
the document revised and updated in compliance with
the latest information from developers
3
Table of Contents
1. INTRODUCTION ................................................................................................................ 10
1.1. DOCUMENT PROFILE .......................................................................................................... 10
1.2. AUDIENCE ......................................................................................................................... 10
1.3. CONVENTIONS ................................................................................................................... 10
1.4. DOCUMENT STRUCTURE .................................................................................................... 11
2. PRODUCT OVERVIEW ..................................................................................................... 12
2.1. INTENT OF THE APPLICATION ............................................................................................. 12
2.2. TECHNICAL DATA AND SPECIFICATION .............................................................................. 12
2.3. SINGLE-SERVER MVTS..................................................................................................... 13
2.4. MVTS-BASED CLUSTERS .................................................................................................. 14
2.4.1. Clusterization ideology .............................................................................................. 14
2.4.2. Load Balancer ............................................................................................................ 16
2.4.3. Signaling MVTS ........................................................................................................ 16
2.4.4. Media MVTS ............................................................................................................. 16
2.5. SIP–HIT MODULE ............................................................................................................. 17
3. INSTALLATION.................................................................................................................. 19
3.1. GENERAL DEPLOYMENT CONSIDERATIONS ........................................................................ 19
3.1.1. Hardware requirements .............................................................................................. 19
3.1.2. Networking................................................................................................................. 20
3.1.3. Operating system........................................................................................................ 20
3.2. PRE-INSTALLATION CONSIDERATIONS ............................................................................... 21
3.2.1. File systems................................................................................................................ 21
3.2.2. File descriptors........................................................................................................... 21
3.2.3. MVTS user groups ..................................................................................................... 21
3.3. INSTALLING THE APPLICATION .......................................................................................... 22
3.4. POST-INSTALLATION TASKS (MAKING THE MVTS OPERATIONAL) .................................... 26
3.4.1. Firewall-related issues................................................................................................ 26
3.4.2. HASP dongles ............................................................................................................ 26
4. MVTS CONFIGURATION ................................................................................................. 28
4.1. CONFIGURATION FILES OVERVIEW .................................................................................... 28
4.2. CONFIGURATION FILE STRUCTURE..................................................................................... 29
5. MVTS OPERATION............................................................................................................ 31
5.1. ADMINISTRATION CONSOLE .............................................................................................. 31
5.1.1. Starting and exiting the administration console......................................................... 31
5.1.2. Administration console commands ............................................................................ 33
5.2. STRUCTURE OF CDR FILES ................................................................................................ 60
5.3. MVTS LOGGING MECHANISM ........................................................................................... 63
5.3.1. MVTS trace logs ........................................................................................................ 64
5.3.2. MVTS debug logs ...................................................................................................... 65
5.3.3. Debug log parameters ................................................................................................ 65
5.4. MVTS WEB MONITOR ....................................................................................................... 69
5.4.1. Configuring and using the Web Monitor ................................................................... 69
4
5.4.2. Customizing interface language................................................................................. 72
5.5. MVTS KERNEL ................................................................................................................. 74
5.5.1. Command-line options............................................................................................... 74
5.5.2. Kernel startup script mp_kerneld.sh .......................................................................... 76
5.6. DELETION/COMPRESSION OF OUTDATED SYSTEM FILES ..................................................... 76
5.6.1. Rotate.cfg ................................................................................................................... 76
5.7. HARDWARE FAULT TOLERANCE OF SYSTEMS HANDLING PRODUCTION TRAFFIC ................ 78
6. TROUBLESHOOTING ....................................................................................................... 79
6.1. MALFUNCTIONING SYMPTOMS AND REMEDIES .................................................................. 83
7. REFERENCE INFORMATION ......................................................................................... 85
7.1. DIAL PEER SEARCH ALGORITHM ........................................................................................ 85
7.2. MVTS – RADIUS INTERACTION ...................................................................................... 87
7.2.1. Registering endpoint authorization ............................................................................ 87
7.2.2. Pre-routing call authorization..................................................................................... 88
7.2.3. Accounting request .................................................................................................... 90
7.2.4. RADIUS-aided routing .............................................................................................. 95
7.2.5. DisconnectRequest originating from RADIUS server............................................... 98
7.2.6. Authentication of registering endpoints not configured in user.cfg........................... 99
7.3. PROVIDING FOR ENOUGH FILE DESCRIPTORS.................................................................... 103
7.3.1. Increasing the number of available file descriptors in Red Hat Linux .................... 103
7.3.2. Setting the number of file descriptors for FreeBSD ................................................ 106
7.4. USE OF REGULAR EXPRESSIONS IN CONFIGURING MVTS ................................................ 107
7.4.1. The dst_patern, src_pattern prefixes ........................................................................ 107
7.4.2. Number translation................................................................................................... 108
7.5. MACRONAMES IN TRANSLATION PATTERNS..................................................................... 111
7.6. REMOVING THE MVTS FROM THE SYSTEM ..................................................................... 112
7.7. DEFINITIONS.................................................................................................................... 112
7.8. ACRONYMS ..................................................................................................................... 113
APPENDIX A SYNTAX OF REGULAR EXPRESSIONS............................................. 116
APPENDIX B SNMP STATISTICS.................................................................................. 119
APPENDIX C MVTS LOCAL DISCONNECT CODES ................................................ 124
APPENDIX D EQUIPMENT COMPATIBILITY........................................................... 129
VoIP gateways and gatekeepers........................................................................................... 129
Billing and accounting systems............................................................................................ 129
5
List of tables
6
List of Figures
7
Fig. 32 Show gw output for the specified gateway only................................................................ 51
Fig. 33 Output of the ‘show incoming’ command ......................................................................... 51
Fig. 34 Traffic load data for local IPs ............................................................................................ 51
Fig. 35 Output of show media command....................................................................................... 52
Fig. 36 Output of the ‘show route’ command................................................................................ 53
Fig. 37 General server statistics ..................................................................................................... 53
Fig. 38 Output of the ‘show stat full’ command ............................................................................ 54
Fig. 39 Call source statistics .......................................................................................................... 54
Fig. 40 Call destination statistics ................................................................................................... 54
Fig. 41 Calls statistics for gateways............................................................................................... 54
Fig. 42 Statistics for the call source MyPC.................................................................................... 55
Fig. 43 State of the redundancy scheme displayed by the show redundancy command ............... 55
Fig. 44 Output of the ‘show snmp’ command ............................................................................... 57
Fig. 45 Output of the sh gk command............................................................................................ 58
Fig. 46 Logon dialog of the MVTS web interface......................................................................... 69
Fig. 47 Admin’s and Client’s Main menu ..................................................................................... 70
Fig. 48 List of accounts existing in the web interface ................................................................... 71
Fig. 49 Account editing dialog....................................................................................................... 71
Fig. 50 Localization page of the Web interface ............................................................................. 73
Fig. 51 Selecting the interface language ........................................................................................ 74
Fig. 52 New interface language (Spanish) ..................................................................................... 74
Fig. 53 Standard RADIUS authentication ................................................................................... 100
Fig. 54 MD5 authentication ......................................................................................................... 101
Fig. 55 CHAP authentication....................................................................................................... 101
Fig. 56 Digest authentication ....................................................................................................... 102
8
Table of References
9
1. INTRODUCTION
1.1. DOCUMENT PROFILE
This document gives description of the MERA VoIP Transit Softswitch v.3.1.0 (in what follows
referred to as the MVTS for brevity), its structure, installation and operation. The intent of this
manual is to provide a handy guide on the capabilities of the system and management of its individual
components.
1.2. AUDIENCE
This guide is intended for the system administrator whose responsibility is to install, configure and
operate the MVTS. Users of this document are presumed to have a working knowledge of UNIX-like
operating systems (Free BSD, Red Hat Linux) and at least some acquaintance with regular
expressions.
1.3. CONVENTIONS
The table below describes the document conventions:
10
1.4. DOCUMENT STRUCTURE
Chapter 1: Introduction describes the subject matter and structure of this document, the target
audience and typographic conventions.
Chapter 2: Overview gives a brief coverage of the product, its purpose, supported functions and
standards. It also describes various system architecture layouts depending on the system scalability
and operating environment of the product.
Chapter 3: Installation leads you through the particulars of product installation: beginning with the
system hardware requirements, operating systems, step-by-step software installation procedure and
ending with the post-installation tasks.
Chapter 4: Configuration tells you how to accomplish the initial configuration of the MVTS and
enumerates the files whose parameters are essential for this task.
Chapter 5: MVTS Operation is focused on the system operation, administration and management
matters. The chapter is divided into sections that provide information about the MVTS management
tools: administration console, MVTS Web Monitor, logging mechanism of the application, CDRs, etc.
A brief coverage of system redundancy is available in this chapter as well.
Chapter 6: Troubleshooting provides information about the MVTS most frequent faults, describes
their symptoms and methods of eliminating the trouble cause. The chapter includes the description of
issue-specific, step-by-step troubleshooting processes, and reference table ‘Malfunctioning symptoms
and remedies’.
Chapter 7: Reference information provides a miscellany of auxiliary but nonetheless useful
information including the use of regular expressions in configuring MVTS, dialpeer search algorithm,
number translation patterns, definitions and acronyms used in the manual, MVTS-RADIUS
interaction, etc.
Appendix A Syntax of Regular Expressions is totally dedicated to description of regular
expressions.
Appendix B covers SNMP statistics.
Appendix C is the Local Disconnect Codes Table.
Appendix D lists VoIP entities (including gateways, gatekeepers and billing systems) that have been
proved compatible to operate with the MVTS SBC.
11
2. PRODUCT OVERVIEW
2.1. INTENT OF THE APPLICATION
The MERA VoIP Transit Softswitch (MVTS) is a carrier-class VoIP session controller with the
gatekeeper and proxy functionality. The MVTS is designed for flexible traffic management that
ensures smooth peering of VoIP networks. The MVTS is a solution that radically simplifies the
network infrastructure, while adding to its efficiency, quality and reliability.
The advanced interworking features enable the MVTS to fix manufacturer-specific inconsistencies in
H.323 protocol implementations allowing the use of multivendor equipment.
Despite rather modest hardware requirements the MVTS is a full-fledged softswitch that provides:
• A signaling and media proxy server that allows concealment of the owner’s
network structure
• Elaborate call routing based on the embedded routing engine and on the
external RADIUS-aided method
• Static and dynamic endpoint servicing
• Two way H.323/SIP translation and conversion of media codecs to ensure
interoperability with variegated networks and equipment (by means of the SIP-
HIT module)
• CDRs and RADIUS API for simple integration with billing systems
• Load balancing and bandwidth management for efficient use of network
resources
• Truly carrier-grade solution: fully redundant and scalable to handle up to 40,
000 simultaneous calls
Supported Protocols
• H.323 v.2
• H.245 v.7, H.225 v.4
• SIP v.2 RFC 2543bis (the SIP-HIT module)
• RTP/RTCP
• T.38, T.120
• SNMP v.1 (statistics and trap)
• MD5, CHAP
• RADIUS authentification
• RADIUS accounting (Attribute 44 and VSA) [6]
12
Operating Systems
• Linux RedHat 9.0;
• Linux RedHat Enterprise 3.0, 4.0;
• Linux RedHat Advanced Server 3;
• Linux Fedora Core 3, 4;
• Free BSD 5.0+ (evaluation version only).
Note: The MVTS operates with the OS Linux kernel of versions 2.4 - 2.6 only.
Fault-tolerance
• remote SNMP monitoring by means of the MVTS Manager or SNMP-counter
• embedded 'watch dog' timer
• fault-triggered e-mail alerts to the System administrator
• failover MVTS server (system redundancy) [14]
• backup RADIUS server configuration
13
Fig. 1 Stand-alone MVTS system architecture
A stand-alone MVTS is a session controller with combined signaling and media proxy functions. Full
proxy operation is extremely demanding in terms of computing power, therefore a single-server
MVTS can only handle up to 1,200 simultaneous call sessions. Clustering the MVTS allows
increasing of traffic volumes processed by the system. Since a single-server MVTS operating in the
dual capacity of a signaling and media proxy can handle up to 1000-1200 concurrent calls, greater
traffic may necessitate installation of additional MVTS boxes and bringing them under a single point
of centralized control.
To protect the carrier’s initial investment in the switching capability and cope up with the scalability
challenge the MVTS session controller is made clusterable.
14
MMVTSs (reliably manageable fleet is three full proxies, each with 1500-2000 simultaneous calls
capacity).
Therefore a basic (two-level) functional cluster element comprises two parts:
signaling MVTS (SMVTS) in control of
three media MVTSs (MMVTS)
Since the number of media MVTSs in the two-level hierarchy is small, the signaling MVTS is
designed to evenly distribute traffic between the media systems. Such four-component layout (an
SMVTS in control of three media systems) provides a basic cluster element that can serve as a
building block for large-scale switching facilities.
As a single signaling MERA can cope up with maximum three MMVTSs (each one capable of
processing up to 1500 calls), a growth in the population of media servers requires more signaling
MERAs, and proliferation of signaling MVTSs entails introduction of dispatch control of some kind
and changes in the intellect of the signaling MVTS which is now designed to work under the control
of a Load Balancer (LB).
Fig. 3 gives a graphical representation of a three-level MVTS traffic management facility.
15
Fig. 3 Three-level MVTS switching facility made up of a cluster of two-level systems
Deployment of the Load Balancer to manage the operational efficiency of the signaling MVTSs
provides a three-level cluster version of the MVTS-based switching facility. With the only function of
“giving orders” a single LB can control as many as 4-5 signaling MERAs.
16
- call statistics
- definition of routing rules
MMVTS has only one task – media proxying.
17
SIP/HIT functional features include:
• SIP/H.323 two-way protocol conversion
• Audio codec conversion (G.729, G.729A, G.723.1, G.711A-LAW, G.711m-LAW
)
• SIP registration (based on Digest authorization md5 hash)
• T.38 fax protocol pass-through
• Automated log keeping: archiving, file size and file rotation management.
The question of configuring the MVTS to operate with SIP-HIT interprotocol
translator is tackled in [12].
18
3. INSTALLATION
3.1. GENERAL DEPLOYMENT CONSIDERATIONS
This section details what is necessary to setup and operate the MVTS session controller. The three
basic things that materially affect the MVTS production capacity and performance are the computing
power of the server platform, the operating system and the network characteristics.
In what follows we give you an insight into what the MVTS hardware and operating system
requirements are.
Table 3 presents hardware configuration recommendation for the MVTS employed as a signaling
proxy only (i.e. with the media proxy functionality disengaged). The system production performance
is expressed as a number of simultaneous call sessions handled by the server.
19
Refer to Table 4 for hardware profile estimates for the MVTS used to the utmost of its capability (in
full proxy operation).
The use of a 1Gbit Ethernet card is a prerequisite for systems whose expected capacity is 300
simultaneous calls and above with full proxying (signaling and media).
3.1.2. NETWORKING
The capability of the local area network is another factor that influences the MVTS performance. The
implications of this factor become especially significant in case of media traffic proxying.
The 100Mb data transfer rate is the minimum LAN requirement for the MVTS server and full-duplex
equipment would be a big plus.
The best possible capacity of an MVTS server used for full proxy operation (G.729) on a 100Mb full-
duplex network is about 1100 concurrent calls. Such a capacity requires installation of at least two
network interface cards – one for H.323 signaling and voice traffic and the other for RADIUS
communication.
Larger capacity during media proxying is attainable through employment of more capable network
interfaces (Gigabit Ethernet, for example).
Install the operating system of your choice making the installation lean and business-oriented (that
actually means that you will not need games, desktop environment and office applications normally
supplied with Linux operating systems). Though, if you are reluctant to bother about deciding what of
the supplied packages are really necessary and you are not concerned about extra disk space occupied
20
on your system by surplus software you can well have the installation program install the OS for you
in one of the available configurations.
The installation of the operating system must be carried out in accordance with the installation
procedure described in the User’s guide and pertinent reference documentation for the OS.
21
Table 5 MVTS user groups
Group Access and permissions
Admin Administration group. The group members enjoy unlimited
access permissions to all files in all directories. The Admin
group users have the right to terminate forcefully a call with a
certain ID or a group of calls connected with the same
gateway. Owners of member accounts of the Admin group
may run any command in the administration console.
Billing Billing and Accounting group. The group users have access to
the files of billing statistics in the billing/ directory. The
group members may execute only the console commands that
display information about the ongoing calls (show call) and
display a list of successfully loaded dial peers (show dp).
Support Technical Support group. The group users may run the
statistics viewing commands of the administration console
(show call, show dial, show stat) only and are denied access
to the commands controling the MVTS operation (start, stop
and some other).
The MVTS user groups with appropriate permissions and access rights are created automatically
when you install the MVTS application with the help of the setup.sh script.
22
• A set of configuration file templates (meraproxy.cfg, gateway.cfg, dialpeer.cfg,
gatekeeper.cfg, user.cfg). The supplied configuration templates can be used as
examples or models during initial MVTS setup.
In addition to the above components, the MVTS delivery package may comprise:
• an assortment of electronic documentation (including this Guide)
• a portion of open source code that needs to be published under the Mozilla Public
License (MPL) [11].
After the installation process is complete, the newly formed directory structure will look as shown in
Fig. 5.
23
Fig. 5 MVTS file system structure
The main MVTS executables and scripts are located in the directory bin/ except the setup script
setup.sh, which is in the root directory.
24
The same directory stores the file, which contains information about the volume of traffic (in seconds)
processed by the registered RAS users and gateways since the last MVTS restart. The name of the file
is formed according to the following pattern: <file_name>_time,
where <file_name> is the value of the file= field, found in the section [Statistics], meraproxy.cfg.
The data in the file is organized into individual records. Each of the records consists of three parts,
delimited by spaces. The first part (src/dst) shows the endpoint type (originating/terminating) in
relation to the MVTS, the second one is the endpoint ID, and the last one shows the traffic volume (in
seconds) sent to/received from the MVTS.
Example:
src ata 5
src sp 0
src user7001 0
dst ata 5
dst sp 0
All the configuration files are in the cfg/ folder. After installation this directory contains the templates
of the configuration files meraproxy.cfg, gateway.cfg, dialpeer.cfg, user.cfg, gatekeeper.cfg,
rotate.cfg and the synchro/ subdirectory. Every time when the MVTS reads new configuration (on
the start or reload config command) it creates a subdirectory in the synchro/ subfolder and names it
with the date and time of the newly created configuration and places copies of the configuration files
into it.
The billing/ directory is the storage place for call records written to CDR files. Depending on the
configuration settings, MVTS periodically stops writing to the currently open work file and creates a
new one. The filenames of the CDR files have a simple structure: bill_<date>_<time>, where <date>
is the date of file creation in format yyyymmdd, <time> is the time when the file was created in the
hhmmss notation, while the prefix bill is a default one and can be changed by the System
Administrator. Here is an example of a CDR filename: bill20020327_113000. The work file, to which
the billing statistics is currently being written, has a different filename, always.
The MVTS writes runtime journals consisting of the packets received and sent by the MVTS during
operation to the debug/logs/ directory.
In case of an eventual MVTS kernel crash, the generated core files containing parsed VoIP packets
will be moved by the mp_kernel.sh script to the directory debug/cores/. The core files are marked
by the crash time stamp and can be used by the system administrator or technical support personnel
for debugging purposes and crash cause analysis. To provide for unlimited disk space for writing
core-files in case the MVTS failure, it is recommendable to add the line ‘ulimit -c 10000000’ in the
mp_kerneld.sh script. Core files assist the MVTS developers in troubleshooting, though frequent
MVTS crashes may lead to the HDD overflow as the size of a core-file may at times reach 100 MB.
The tmp/ folder contains files for internal use by the MVTS. Abstain from modifying and/or deleting
these files when the session controller is running.
The src/ directory contains portions of the MVTS code distributed under an Open Source License
(OSL).
25
The doc/ directory is for documentation supplied in electronic form.
26
> pkg_add /mnt/cdrom/SUD-ParallelDriver-5.50-0.i386.tgz
to install the parallel driver.
2. Type
> pkg_add /mnt/cdrom/SUD-USBDaemon-5.50-0.i386.tgz
to install the USB daemon.
The post-installation directory structure will contain any of the following components, depending on
the installation choices you have made:
/opt/RainbowTechnologies/SUD5.50/bsd_drvr_uninstall.sh - the script to uninstall the Sentinel UNIX
Driver.
/opt/RainbowTechnologies/SUD5.50/Parallel/rbdr.ko - the parallel port driver module.
/opt/RainbowTechnologies/SUD5.50/Parallel/readme.pdf – Sentinel driver Read Me file
/opt/RainbowTechnologies/SUD5.50/USB/usbdaemon - the USB daemon binary.
/opt/RainbowTechnologies/SUD5.50/USB/bsd_load_daemon.sh - a script for starting, stopping and
restarting the USB daemon.
After you have installed the drivers your application is ready for initial configuration.
27
4. MVTS CONFIGURATION
Since all the MVTS configuration files are simple text files, configuring the application for operation
is just a process of editing the configuration files in a text editor.
The rotate.cfg file is not mentioned in the table because it has nothing to do with configuring the
MVTS. It is connected rather with the rotate.sh script and serves to perform certain system
administration tasks concerning log files and CDR files handling.
Configuring the MVTS involves:
1) setting the system global parameters in meraproxy.cfg
2) describing communicating gateways in the gateway.cfg file and registering
entities in the user.cfg file
3) preparing a calling plan, which involves defining call routes (dial peers) and
determining number manipulation rules in dialpeer.cfg
4) entering registration (upstream) gatekeepers data if any in the gatekeeper.cfg file.
Refer to [12] for full information regarding the MVTS configuration parameters, their purpose, valid
and default values.
28
On startup, MVTS reads all the configuration files into the cache memory and uses the cached data
only. Thus, the modifications and alterations in the configuration files take effect only after restart of
the application, caused by a crash or intentional stop of the program. The modifications will also take
effect after running the reload config command typed at the command prompt of the administration
console.
29
section names
• empty lines
• the lines starting with the “#” character, i.e. comments
• field values that include unknown (invalid) names
Where an integer is required for the value of configuration parameter, you can enter it in the decimal,
hexadecimal or octal notation. Hexadecimals must start with 0x, while octals are distinguished by a
leading 0.
After installation, the system configuration file of the MVTS (merarpoxy.cfg) contains the default
settings, while the gateway data file and the dial peer file provide the appropriate templates only.
To reconfigure the MVTS current settings make the appropriate changes in the original configuration
file(s). The changes will take effect only after you reload the configuration with the help of the ‘reload
config’ command. The previous system configuration is saved in the mvts/cfg/synchro directory.
30
5. MVTS OPERATION
Stable and fault free operation of the MVTS is achieved by a prudent administration policy and the
operator’s responsiveness to cases of unsatisfactory traffic service.
Administration tasks can be carried out with the aid of several applications: the MVTS administration
console, the MVTS Manager (Windows GUI) and the MVTS Web Monitor. Below you will find all
the necessary information regarding each of the above administration tools.
Support
A user with the support group membership may view various statistics but
cannot enter commands that have impact on the MVTS operation.
Billing
A user of the billing group can only display information about ongoing calls.
The commands of the administration console allow users:
• to start and stop MVTS
• to have the configuration files read into the cache when the main application is
running
• to display various data about MVTS operation
• to forcefully terminate calls under certain conditions
• to view call statistics
• to define routing rules
31
Fig. 6 Administration console terminal screen
The console may be used by several users simultaneously.
To exit the administration console run the quit command.
Example:
The command line of the console accepts one console command or the keyword ‘repeat:’ followed by
the command that requires repeated execution. If the console is started with one of the commands as
an argument, the console will be shut as soon as the command is executed. The result will be one of
the return codes (0 – command executed: 1 – connection with MVTS failed).
If the console script is run with the keyword ‘repeat:’ and a command following it, the console starts
and the command that follows the keyword ‘repeat:’ will be continuously executed every 10 seconds
until the process is interrupted by pressing the Ctrl+С combination on the keyboard.
For example, if you type:
#> mp_shell.sh repeat: help
32
The System will output help screens as shown in Fig. 7 every ten seconds until you press Ctrl+С on
the keyboard.
help
When entered without arguments, this command displays a full list of commands with brief reference
summaries. Typing “help” followed by an individual command brings up a detailed description of the
command, its format and example of use. The help command is accessible to the users of all groups.
Example:
33
Fig. 7 Output of the “help” command
info
Use the command info to display information about current MVTS processes.
Example:
34
Registration with the gatekeeper ‘fbsd_mvts’ will remain valid until all the ongoing calls serviced by
the gatekeeper are terminated.
You can cease all gatekeeper registrations at once by entering the command:
#> di gk all
To resume registration with the gatekeeper:
1 Terminate all the calls supported by the gatekeeper
2 Make sure the gatekeeper record is available in the configuration file
(gatekeeper.cfg)
3 Execute the reload config command
35
Example:
reset stat src|dst|gw|dp clears statistics categorywise (src – for call originators only, dst – for call
destinations only, gw – for gateways only, dp – for dial peers only)
reset stat src|dst|gw|dp [name] clears the statistics categorywise for the object specified in the [name]
argument.
start
This command enables you to start the MVTS if it is not running at the moment. The command is
available to users of the group Admin.
Example:
stop
The command terminates all ongoing calls and shuts down the MVTS. This command is the exclusive
privilege of Admin group members.
terminate call
36
The administration console allows the Administrator to terminate a call or a group of calls that
correspond to a certain criterion. The criterion may be an IP address of a calling/called number or
ICN. The command can be run by members of the group Admin.
When entered with the option ‘table’ the call list is displayed as a table, see Fig. 17.
Example:
37
Fig. 17 Output of the ‘show call’ command entered with the table formatting option ‘ta’
The option ‘name’ in the typed command will replace gateway IP addresses in the column ‘source’
and column ‘destination’ with gateway names.
Example:
Fig. 18 Table-formated output of the ‘show call’ command entered with the ‘name’ option
When the width of a value in the table cell exceeds the width of the column, the value is presented in
an abridged form ending with >. Call data sizes are displayed in kilobytes.
The typed command may contain an argument in form of:
• called/calling gateway IP address
• call ID
In the former case the command output will look like in shown below:
Fig. 19 Output of the ‘sh ca -dst’ command typed with the destination gateway IP address
as an argument
38
As you can see in the screeshot, the output is a list of calls in form of comma-separated values (CSV).
Each call record comprises a set of call parameters described in Table 7 below.
Table 7 Call data for a group of calls, output by the s h o w c a l l command
Parameter Description
ICN Internal call number.
number_src_out Calling number relayed by the MVTS
number_dst_out Destination number relayed by the MVTS
ip_address_src IP addres of the originating gateway
ip_address_dst IP address of the called gateway
talk_time Total call duration in seconds
src_bytes in Bytes received from the calling party
dst_bytes in Bytes received from the called party
dst_bytes out Bytes from the called party transferred
src_bytes out Bytes from the calling party transferred
When the command argument is the internal call number (ICN), the output will have the following
format:
Fig. 20 Output of the ‘sh ca’ command typed with the call ID option
The table below explains the meaning of the call parameters displayed by the sh ca command with
the ICN as the command argument.
39
Table 8 CSVs displayed by the s h o w c a l l command with the ICN argument
Parameter Description
ICN Internal call number
number_src_in Calling number received by the MVTS
number_dst_in Destination number received by the MVTS
number_src_out Calling number relayed by the MVTS
number_dst_out Destination number relayed by the MVTS
src_number_bill Calling number for billing purposes
dst_number_bill Destination number for billing purposes
ip_address_src IP addres of the originating gateway
ip_address_dst IP address of the called gateway
gw name src Name of the originating gateway
gw name dst Name of the destination gateway
call_id Call identification number
conf_id ID of the conference the call is a part of
setup_time Time of SetUp
connect_time Connect time
talk_time Time lapsed since Connect (billed call time)
src_bytes (i/o) Number of bytes transferred from the calling party (bytes
in/bytes out)
dst_bytes (i/o) Number of bytes transferred from the called party (bytes
in/bytes out)
used_codecs src Codecs employed by the calling party
used_codecs dst Codecs employed by the called party
You can also view call data for an individual source or destination. To view call data for an individual
endpoint, use –dstname or –srcname argument of the command (sh ca [-dstname <name>] or sh ca [-
srcname <name>]).
Example:
40
or
show dial
The command is accessible to users of the Admin and Support group.
Use the show dial command to verify if a call route is configured correctly and calls through this path
are possible. The command searches the cached dial plan for the best dial peer for the specified
called/calling number. During execution, the system outputs the decisions resulting from the search
algorithm, found dial peer(s) and all the information required for a call setup.
It is also possible to view the result of preliminary (before the dialpeer search) number transformation
configured in the fields in_src_translate= and in_dst_translate=. To view the result, carry
out the ‘sh di’ command with the following arguments:
sh[ow] di[al] called_number [[calling_number] [[-src endpoint_id] [-g group_name]]]
Example:
41
Fig. 21 Output of the ‘show dial’ command
Fig. 22 Output of the ‘sh stat rt’ command displaying route statistical data
42
To make your query more specific and see the state of a particular route of interest, use the
options ‘–dst’, ‘–src’ and ‘–dp’.
Typing the command with the ‘all’ option (st st rt all) will output detailed route state data for all
currently active routes.
Use the –src option and indicate initial letters of the originator’s name to view information about
a route involving the specified originating gateway.
Use the –dst option and specify initial letters of the terminator’s name in the route to view the
route data.
Use –dp option and enter initial letters of the dial peer name in the route, to select a route by the
involved dial peer.
Example:
The route state codes (found in the last column) are as follows:
FA (fully accessible) – the routing path is freely passable
PA (provisionally accessible) – the route is accessible for the time being
NA (non-accessible) – the route is impassable for calls
43
3. The MVTS calculates ASR as a percetange obtained by multiplying the ratio of successful
to the value of the call_radix= field by 100. The ASR value is calculated every three
seconds.
4. The standard ASR (displayed as a value in parenthesis next to the MVTS ASR) represents
a ratio of non-zero duration calls to total calls.
Fig. 24 ‘Show stat file’ writes statistics to a file and displays the file name
44
Fig. 25 Output of the ‘show stat param’ command
45
Table 9 Parameters, displayed by the s h o w e p command
Parameter Description
Num Running number
Gateway/Endpoint endpoint alias
Endpoint ID endpoint ID
Username user name
dst/src IP destination/source IP-address
RegTime Time of the endpoint registration with the MVTS (angle
brackets contain the time the endpoint has sustained the
registration)
When entered with an argument (‘number’ or ‘endpoint_id’) the command displays configuration
settings for the endpoint whose running number or ID matches the command argument.
Example:
Fig. 27 Output of the ‘show endpoint’ command with the endpoint number
specified
46
Fig. 28 Output of show converter command
The output of the command provides the following information:
N a m e – internal name of the converter
A d d r e s s – the converter’s IP
P o r t – the number of communication port
M o d e – the converter’s operating mode (the word both means the converter can both receive and
send calls)
P r o t o – the type of signaling protocol (H323, SIP)
A c t i v e c a l l s – the number of calls currently in progress
47
Fig. 29 Output of the ‘show disconnect’ command
show dp
This command, accessible to users of all groups, permits you to review all dial peers that were
succesfully loaded from the dial plan or to see a single dial peer matching the specified name.
Example:
Note: the maximum output of the show dp command is limited to 250 dialpeers.
48
Table 10 Dial-peer parameters, displayed onscreen by the s h o w d p
command
Parameter Description
dial peer Dial peer name
gateway Gateway name
prio(rity) Gateway precedence
capacity Configured number of concurrent calls for the dial
peer
hunt_stop The flag preventing call rerouting when the selected
dial peer is the right one but the corresponding
gateway is inaccessible or busy
hunt_mode Load balancing technique
dst_pattern
Number translation rules for the calling/called party
src_pattern
49
Fig. 31 Overview of gateways displayed by the ‘show gw’ command
When the gateway’s IP or name is specified as the command option, the command outputs
information about the specified gateway only. The command is accessible to members of the user
group Admin and Support.
Example:
50
Fig. 32 Show gw output for the specified gateway only
51
show media
The command s h o w m e d i a (s h m e ) allows you to view the operational statistics of media
MVTSs used in your traffic handling facility (a media MVTS is the constituent part of MVTS
clusters that deals with media traffic only).
The lines displayed under the table show current configuration settings:
m i n _ a s r shows the configured ASR minimum value
m i n _ a c d presents the configured ACD minimum for the MMVTS
mode indicates the operating mode of the system when there are no media MVTSs available for
t r a f f i c 1 – terminate the call via the terminating endpoint specified in the configuration; 0 –
abort the call with LDC 400 (NoMediaServer)
c a l l _ r a d i x – the number of calls used for ASR and ACD calculations
s u s p e n d _ t i m e – duration of blocking the MMVTS showing low ASR and ACD
n o _ c o n n e c t _ s u s p e n d _ t i m e – the system’s operating mode in the absence of TCP
connection to the MMVTS
show route
The command reads and displays the system routing table. In addition, the command allows the
operator to see what local address the proxy server will choose for the called party.
Example:
52
Fig. 36 Output of the ‘show route’ command
53
Fig. 38 Output of the ‘show stat full’ command
show stat src|dst|gw|dp [name] - shows statistics for the specified object
Example:
54
Fig. 42 Statistics for the call source MyPC
show redundancy
This console command outputs information about the state of the primary and standby server.
55
Parameter Description
the main MVTS server when it is functioning and the
standby system is idle
master: master and slave are active – status of the
principle host when both the systems in the
redundancy pair are functioning
slave: slave is waiting for master – status of the
failover system when it is waiting to connect to the
principle MVTS host
slave: slave is in standby mode, master is active –
status of the failover server when in the stand-by
mode of operation with the main MVTS host running
slave: slave is active, master is broken down – status
of the failover MVTS server when it is running and
the principle MVTS host is down
Is slave shows the relations of the host to its redundancy
counterpart (main/failover)
Check period shows the time interval between two successive TCP
connects from the failover to the primary system
Max failed retries shows the configured number of connect retries to the
primary server
Connect timeout shows a TCP connect attempt timeout
Master address shows the main server’s IP address (for remote
disabling of the incoming IP(s) on the main server by
the failover MVTS)
Slave address shows the IP address of the failover server (for remote
disabling of the incoming IPs on the failover host by
the primary MVTS)
Last slave connect time shows the time of the last successful connect from the
failover to the main server. This parameter is relevant
for the main MVTS host only
Master down time shows the time when the failover system took over
from the principle host
Checked address a set of parameters for the incoming IP addresses,
checked by the failover system
Address shows the incoming IP address and port, checked by
the failover MVTS
Local address the failover system’s local address used for checking
the incoming IP address and port of the main MVTS
host
56
Parameter Description
Last check time self-explanatory
Bring up command command sequence that gets up the IP address
Shutdown command command sequence to disable the IP address
show snmp
By typing this console command you output information about the present SNMP settings of the
MVTS (media MVTS) and the number of objects currently available in the SNMP statistics
sh[ow] gk
The command displays information about the gatekeepers the MVTS is currently registered with.
57
Fig. 45 Output of the sh gk command
The meaning of the fields of the command output is explained in the table below:
Parameter Description
state Shows the current gatekeeper status
address IP address of the gatekeeper
port GK’s port
type Type of interaction of the MVTS and the gatekeeper
security The gatekeeper’s authorization method
terminal The way the remote gatekeeper treats the MVTS
keepalive Time interval (in seconds) of repeated registration
with the gatekeeper
keepalive type Type of the registration keepalive message
options Shows whether the translation of the destination
number in positive replies received from the
registration gatekeeper is enabled (1) or disabled (0)
local_address Originating IP address for RAS packets
user User’s name for gatekeeper authorization
password The user’s authorization password
id The gatekeeper identifier
endpoint_id Endpoint ID
active_admissions The field has three values:
The first value stands for the number of call sessions
handled by the gatekeeper
The second value is the number of active ARQs sent
58
Parameter Description
to the gatekeeper by the MVTS
The third value is the number of DRQs (Disengage
Request) sent to the GK by the MVTS
59
5.2. STRUCTURE OF CDR FILES
CDR files provide an interface for billing and accounting systems and are instrumental in
troubleshooting since they contain data about the disconnect cause for every call processed by the
MVTS.
CDRs are plain text files used to store information about individual calls. The CDR files are
generated on the ‘one call – one record’ basis. An example of an individual call record is given
below.
MVTS CDRs can be output to the screen in four different formats. You can choose the output
format by changing the value of the c d r _ f o r m a t = parameter in the section [Billing] of
meraproxy.cfg.
Setting the parameter to 0 will enable output of call detail records in the MVTS intrinsic format –
that is – with the CDR field names (as shown in the example above).
Setting c d r _ f o r m a t = to 1 will output of CDRs in the MIND CTI format, that is without field
names. A call detail record in this case is just a list of comma-separated values. Zero values are
not displayed. The field ELAPSED-TIME= is always displayed in all formats regardless of the
c d r _ f o r m a t = setting.
Setting c d r _ f o r m a t = to 2 will output call detail records in the format similar to the one
achieved by c d r _ f o r m a t = 0 but with zero values shown.
With c d r _ f o r m a t =3 the format of records is similar to that with c d r _ f o r m a t = 2 but the
values of fields s e t u p _ t i m e = , c o n n e c t _ t i m e = and d i s c o n n e c t _ t i m e =
are presented as the number of seconds elapsed since January, 1970.
Table 12 presents the fields found in a CDR record in the same order as they appear in a CDR.
60
SRC-NUMBER-OUT Number of the calling party after translation
DST-NUMBER-OUT Number of the called party after translation
SRC-NUMBER-BILL Number of the calling party after translation into
the billing system format
DST-NUMBER-BILL Number of the called party after translation into
the billing system format
SRC-IP:SRC-POR IP address and port of the originating gateway
DST-IP:DST-PORT IP address and port of the gateway the call was
forwarded to
SRC-RTP-IP:SRC-RTP- Shows the real IP address of the originator when
PORT several gateways are used for call routing
DST-RTP-IP:DST-RTP- Shows the real IP address and port of the
PORT terminator when call routing involves several
gateways
REMOTE-GATEKEEPER- Gatekeeper’s IP-address
IP
MEDIA-SERVER- Contains the IP address and port of the Media
IP:MEDIA-SERVER-PORT server (in MVTS cluster systems)
CONVERTER-NAME Shows the name of the SIP-HIT interprotocol
converter
CONVERTER- Contains the IP address and port of the SIP-HIT
IP:CONVERTER-PORT interprotocol converter
SRC-USER Calling user name
DST-USER Called user name
RADIUS-USER User’s name received from the RADIUS server
with the use_h323_ivr_in mode enabled and
afterwards used in the accounting packets
SRC-NAME Name of the section containing the data of the
originating gateway
DST-NAME Name of the section containing the data of the
terminating gateway
DIALPEER-NAME Name of the section containing the data of the
involved dial peer
INITIAL-INCOMING- Local IP address that received Setup from the call
LOCAL-ADDRESS originator
SELECTED-INCOMING- Local address selected for exchange with the call
LOCAL-ADDRESS originator
OUTGOING-LOCAL- Local address selected for exchange with the call
ADDRESS terminator
61
RECORD-ID Unique call identifier of the <start-time>-<call-
number> type, where <start-time> is a time stamp
of the current MVTS session, expressed as an
amount of seconds that elapsed between January
1, 1970 and the instance of the latest MVTS start,
and <call-number> is the index number of the call
in the current MVTS session.
ELAPSED-TIME Call duration in seconds
SETUP-TIME Call setup time
CONNECT-TIME Conversation start time
DISCONNECT-TIME Disconnect time
DISCONNECT-CODE- Disconnect cause code
LOCAL
DISCONNECT-CODE- Q931 disconnect code
Q931
SRC-BYTES-IN Number of bytes received from the caller
DST-BYTES-IN Number of bytes received from the called party
SRC-BYTES-OUT Number of bytes transmitted to the caller
DST-BYTES OUT Number of bytes transmitted to the called party
QOS Quality of service
SRC-CODEC Codecs used by the caller
DST-CODEC Codecs used by the called party
CALLID 32 hexadecimal digits representing a unique call
identifier
CONFID Conference ID the call was a part of
LAR-FAULT-REASON LAR fault cause code; reason for call routing
interruption
PROXY-MODE Operational mode of the proxy server
ROUTE-RETRIES Number of attempts to re-route the call
SCD-TIME Time in seconds elapsed between receipt of
SETUP and CONNECT or between SETUP and
ReleaseComplete (if no CONNECT was received)
SOURCE-FASTSTART SOURCE-FASTSTART=1, when the originator’s
Setup includes fields with FASTSTARTs
DESTINATION- DESTINATION-FASTSTART=1, when the
FASTSTART terminator’s packets included fields with
FASTSTARTs
62
SOURCE-TUNNELLING SOURCE-TUNNELLING=1, when the tunneling
flag was set (1) in the originator’s messages
DESTINATION- DESTIANTION-TUNNELLING=1, when the
TUNNELLING tunneling flag was set (1) in the terminator’s
messages
PDD-TIME Time interval between receipt of SETUP from the
call originator and receipt of Alert or Connect or
ProgressIndicator=8
(ProgressInbandInformationAvailable) from the
terminating party
PDD-REASON Type of the message, which ends the PDD time
interval
The following values are valid:
ALERT – ALERT was received from the call
terminator
PI8 – ProgressIndicator=8 was received from the
call terminator
CONNECT – CONNECT was received from the
call terminator
N/A – none of the mentioned messages was
received
REDIRECT-NUMBER Contains the list of numbers received from the
RADIUS server in the field VSA(106) h323-
redirect-number
INFO-NUMBER Shows the call destination number formed by the
MVTS from the Setup and Information messages
Note: Remember that the MVTS does not attend to timely removal of old log files, CDR files,
core-files etc., nor does it forewarn the system administrator of pending disk overflow. It is the
Administrator’s responsibility to see that the old files are disposed of regularly.
As debug logs take up quite a large amount of disk space, they can completely fill the HDD
impeding further saving of logs, CDR files and files with the system operating statistics.
You can always use an additional hard drive as a storage media for saved logs and it is advisable
that you employ the script mvts/bin/rotate.sh to compress or delete outdated log files.
Use the rotate.cfg configuration file to configure the script to compress or delete log files and set
the compression/deletion interval.
63
Should a disk overflow occur the system will continue to function faultlessly handling the calls
but without saving the logs, core-files and billing data. Therefore, all the information for the time
that has elapsed since the disk overflow will be irretrievably lost.
In case of HDD overflow, the system administrator has to dispose of the obsolete and unneeded
files in compliance with the existing documentation policy.
When the MVTS generates LDC 202 (call with unknown originator’s IP-address), the event “call
from unregistered gateway located on <IP address>” is added to the MVTS trace log.
Primarily intended for technical support personnel and developers team who have an intimate
knowledge of the MVTS operating principles, the content of trace logs may be of little interest
and sometimes obscure to MVTS operators.
When requested by MERA technical support personnel, trace data may be obtained from the file
$H323PROXY_ROOT/debug/logs/mp.kernel.sh.log-<date> , where the MVTS writes trace logs.
All MVTS users have the permission to extract files from the above mentioned directory. When
presented to the attention of a technical support engineer, trace logs serve the source of
information about the system errors and malfunctioning. They enable the engineer to advise you
of an adequate corrective action to take and to provide you with full troubleshooting information.
The only parameter recommended for configuration by the MVTS operator is the detail level of
information written to trace logs. This parameter is determined by the system administrator in the
field t r a c e _ l e v e l = of the section [Debug] of the system configuration file meraproxy.cfg.
When the t r a c e _ l e v e l = field value is 0 (default setting), trace logging is disabled.
Setting t r a c e _ l e v e l = to 1 will allow the MVTS to write trace logs with the minimum
information level.
64
The highest level of information details for trace logs is enabled by setting the above parameter to
3. Setting t r a c e _ l e v e l = to 3 makes the information written to trace logs most detailed and
elaborate.
65
<protocol> - message protocol
<message type> - type of the message (according to the H.323 protocol [1])
Example:
12:16:47 12/09/2001 Recv 192.168.5.1:1813 Q.931 Setup
12:16:47 12/09/2001 Sent 192.168.5.1:1720 Q.931 Setup
12:16:47 12/09/2001 Recv 192.168.5.1:1720 Q.931 Facility
12:16:47 12/09/2001 Sent 192.168.5.1:1813 Q.931 Facility
12:16:47 12/09/2001 Recv 192.168.5.1:1720 Q.931 Connect
12:16:47 12/09/2001 Sent 192.168.5.1:1813 Q.931 Connect
12:16:47 12/09/2001 Recv 192.168.5.1:1813 Q.931 Facility
When it is necessary to obtain the most detailed information from the log files, set the parameter
level= to 3.
This will enable output of message texts in the following format:
<time><date><Recv/Sent><IP address><protocol><message text>
where:
<time> and <date> is the time/date stamp
<Recv/Sent> - Recv – the message was received, Sent – the message was sent
<IP address> is the address of the communicating computer
<protocol> is the message protocol
<message text> is the text of the message (that may consist of several lines)
Example:
15:05:05 12/09/2001 Recv 192.168.5.1:2883 Q.931
{
protocolDiscriminator = 8
callReference = 1
from = originator
messageType = Setup
IE: Bearer-Capability = {
88 c0 a5 ...
}
IE: Display = {
4d 45 52 41 20 70 68 6f 6e 65 20 37 37 37 37 30 MERA
phone
77770
66
30 0
}
}
Note: As the highly detailed information is used for testing and debugging purposes mostly the
level=3 setting cannot be recommended for periods of trouble free operation because of large
size of debug log files
Note: The correct use of this option may be challenging as there is a certain peculiarity in its
employment described below
67
Suppose you wish to ecomomize on HDD space and have a highly detailed log for call sessions
involving a particular gateway only. Turn off the system global logging setting (level=0 in the
section [Debug] of meraproxy.cfg and set the debug_level= parameter to the highest detail
level in the configuration record of the needed gateway only. However, the right way to obtain a
highly detailed log of a call session involving the gateway of interest is to set debug_level=3 in
the configuration of the call originator, because if you specify debug_level=3 in the
configuration of the terminating gateway, detailed session logging will start only after the SETUP
message is sent to the terminator and this terminating gateway can happen to be the last one in the
list of possible termination options. Therefore, there is a chance that you will get a detailed log of
a small portion of the target session only.
68
5.4. MVTS WEB MONITOR
The MVTS Web Monitor is a web-interface application that allows remote access to the MVTS
operating statistics from Web clients (for example, MS Internet Explorer or Opera Web
browser). To ensure operating flexibility, user accounts in the Web Monitor have no relation
whatsoever to the accounts of the MVTS GUI and have to be created and configured separately.
The MVTS Web Monitor is included in the supplied software bundle together with the server
part of the MVTS GUI. You have full access to all of the Web Monitor features immediately
after installation of the MVTS MS and starting the MVTS agent.
If your logon credentials (login name and password) are recognized and accepted by the system,
you will see the general statistics page comprising three tables:
- Originators statistics
- Terminators statistics
- Dialpeers statistics
While the MVTS web interface is generally self-explaining and intuitive, consider the different
options of the main menu as viewed by the system administrator and a user with fewer
privileges. (see Fig. 47).
69
Fig. 47 Admin’s and Client’s Main menu
The admin’s and client’s menu views presented above differ in one item only. The client’s
version of the Main menu lacks the Accounts option.
The Statistics item invokes a page with complete statistics for all VoIP entities configured in the
MVTS presented as tables with data for gateways, call originators, call terminators and dial
peers. The sub-items of the Statistics option (Gateways, Originators, Terminators, Dial peers)
display pages with data tables for the named category of objects only (a client with access to the
Web monitor will see the statistics only for the objects accessible to him).
The Objects menu item serves to display the list of objects available for statistics visualization.
The sub-items of the Object list item help to select the title objects for viewing.
The Settings item invokes the Personal settings dialog used to change the access password and
choose the interface language. The interface language can be customized by changing the content
of a plain text file (for details refer to section 5.5.2_Customizing Interface Language)
The Accounts option is a tool for the system administrator to create user accounts,
grant/withdraw permissions and determine objects to be available to clients for viewing statistics
70
Fig. 48 List of accounts existing in the web interface
.
Fig. 49 Account editing dialog
In the account dialog box you can change the account settings, i.e. give/withdraw permissions by
checking/unchecking appropriate checkboxes. The settings available in the dialog box are:
Activate/suspend account (the Enable checkbox)
71
Grant/deny access to object statistics views (gateway, dial peer, route
checkboxes)
Allow/disallow change of the login password (the Change password
checkbox)
Engage/disengage the capability to reset current object statistics (Can reset
statistics)
The Administrator of the MVTS server checkbox corresponds to the account attribute that by
default grants unrestricted permissions to the account owner.
ACD = ACD
ASR = ASR (std)
Account = Account
Accounts = Accounts
Active_calls = Active calls
Administrator_of_MVTS_server = Administrator of MVTS server
Apply = Apply
Are_you_sure = Are you sure?
Can_reset_statistics = Can reset statistics
Cancel = Cancel
Change_password = Change password
Common_settings = Common settings
Common_statistics = Common statistics
Create_account = Create account
Creating_account = Creating account
Delete = Delete
Delete_account = Delete account
etc.
If you wish to change the language of the Web interface, click the Localization option on the
Main menu. This will bring up the Localization page of the interface.
72
Fig. 50 Localization page of the Web interface
Click the Template link to download the interface template and save the file to a directory of
your choice.
Edit the template entering the necessary character strings after the ‘=’ sign in the template fields.
For example:
LANGUAGE = Spanish
ACD = ACD
ASR = ASR
Account = Cuenta
Accounts = Cuentas
Active_calls = Llamadas activas
Administrator_of_MVTS_server = Administrador del servidor MVTS
Are_you_sure = Esta seguro?
Can_reset_statistics = Puede reajustar estadística
Cancel = Cancelación
Change_password = Cambiar la contraseña
... ... ... ... ...
etc.
The name of the interface language, which appears as a selectable option of the drop-down box
in the Personal settings window, is in the field LANGUAGE. To avoid possible
misunderstanding always name your interface language variant in English.
Save the ready language file in the UNICODE/UTF-8 encoding with a different name and upload
it to the server. To upload the interface language file click the Browse button on the Localization
page and find your newly prepared file in the appearing file selection dialog. Click the Upload
button to upload the file to the server.
After a successful upload the name of the new language module will appear in the Module
column of the Localization table.
To change the interface language go the Personal settings page (click the Settings link to invoke
the page) and select the desired language from the drop-down list.
73
Fig. 51 Selecting the interface language
Click the Save settings button to apply the new language settings. The effect should become
visible immediately.
74
Options of the Description
command ‘start’
-k --kill Starts with process kill in the PID-file
-c --console Redirects output to the standard output
stream (console) instead of the syslog
journal
-l --log-file Redirects output to a file/directory with the
specified name (instead of the syslog
journal)
-x --execute Runs the kernel as a common program
-i --ini-file Specifies the filename (complete file path)
of the initialization file or provides a list of
directories for ini-file search. The directories
on the search path list must be delmited with
‘:’.
-C --core-size Specifies maximum size of the core-file.
An attempt to start the MVTS kernel by entering the command without command-line options:
#>start
will result in a screenful of tips describing the command arguments.
bash-2.05$ ./mp_kerneld.x
error: must specify one of -v, -h, -t, -k, -d or -x
usage: [-c] -v|-d|-h|-x
-h --help output this help message and exit
-v --version display version information and exit
-d --daemon run as a daemon
-u --uid uid set user id to run as
-g --gid gid set group id to run as
-p --pid-file name or directory for pid file
-t --terminate orderly terminate process in pid file
-k --kill preemptively kill process in pid file
-c --console output messages to stdout rather than
syslog
75
5.5.2. KERNEL STARTUP SCRIPT MP_KERNELD.SH
To run the MVTS kernel startup script, change your working directory to …/mvts/bin and type
#> mp_kerneld.sh [cfg_file] ъ
[cfg_file] stands for the name of the global configuration file (meraproxy.cfg by default). This
method allows you to start the MVTS from the OS console terminal without the need to run the
MVTS administration console.
5.6.1. ROTATE.CFG
File rotate.cfg consists of two sections: [Billing] and [Logs], which set the parameters of
compression/deletion of CDR files or runtime logs respectively.
Each of these sections comprises five identical fields.
[Billing], [Logs]
path=
This parameter serves to specify the full path to the directory where the MVTS saves CDR-files
([Billing]) or logs ([Logs]).
Valid values:
A character string that stands for the path to the file.
Example:
path=$H323PROXY_ROOT/billing – for CDRs
path=$H323PROXY_ROOT/debug/logs – for logs
file=
Define a mask for the files subject to removal or compression.
Valid values:
76
A string of alphanumeric characters representing a file mask.
Example:
file=bill[0-9]*_[0-9]* - for CDRs
file=log[0-9]*_[0-9]* - for logs
time=
Set a time interval of compression or removal of the outdated CDR-files or logs.
Valid values:
The parameter can have the following values:
day – enables daily deletion/compression of files
week – enables weekly deletion/compression of files
month – enables monthly deletion/compression of files
year – enables annual deletion/compression of files
Example:
time=day
action=
Enables the MVTS operator to choose between complete removal and compression of outdated
CDR files or logfiles.
Valid values:
delete – irretrievably deletes CDR files (logfiles)
compress – enables the rotate.sh script to archive logs (CDR files) and save them to the
directory specified in archive= (see below).
Example:
action=compress
archive=
Specify a directory where the script will save the compressed CDR files or logfiles.
Valid values:
A string of characters representing the name of the directory.
Example:
archive=$H323PROXY_ROOT/bil.tar – for CDR files
archive=$H323PROXY_ROOT/log.tar – for logfiles
77
5.7. HARDWARE FAULT TOLERANCE OF SYSTEMS HANDLING
PRODUCTION TRAFFIC
The operational dependability of the system is achieved by deployment of an additional MVTS
box that functions as a hot-standby system in continuous readiness to take over from the primary
MVTS should it fail.
Note: the system administrator is notified about the primary MVTS system failure via e-mail,
generated at the time of activation of the failover server.
Refer to [14] for details about MVTS redundancy schemes.
78
6. TROUBLESHOOTING
This chapter is intended to offer you the information you need for effective troubleshooting in
case of system malfunctioning.
While operating the MVTS you may be confronted with the following most likely types of
malfunctioning:
I. Failure to start the MVTS application.
II. Failure to establish steady call sessions with the MVTS application running
normally.
The troubleshooting procedure varies with the type of the malfunctioning situation you
encounter.
I. If you have a problem starting the MVTS application, follow the steps below:
1. Start the MVTS administration console by the
$H323PROXY_ROOT/bin/mp_shell.x command.
2. Type info at the console command prompt to display the list of MVTS
processes. If no processes are displayed, then carry out the start
command to start the MVTS application.
3. After 5 -10 seconds type info at the command prompt again. If the list of
displayed processes contains several mp_kerneld.sh records, and at least
one mp_kerneld.x record, then be sure that the MVTS kernel is running.
4. To verify that the MVTS kernel is running properly type sh st at the
command prompt of the MVTS administration console. This command
outputs your lisence information, the MVTS build date, number of calls,
etc.
If you have performed step 3 and the displayed list of processes does not comprise at least one
mp_kerneld.x record it means that the MVTS application kernel is not running. You can find the
MVTS diagnostic information about the system errors in trace logs generated by the MVTS
incase of malfunctioning. Files with the trace logs are in the directory
$H323PROXY_ROOT/debug/logs.
79
#> less <name of the trace log>
4. To archive the selected log type
#> tar –czf trace.tar.gz <name of the trace log>
5. Send the trace log archive to MERA customer support for analysis.
II. In situations when your seemingly fully operational MVTS application fails to
establish call sessions take the following steps:
1. Start the MVTS administration console with the command
#>$H323PROXY_ROOT/bin/mp/shell.x.
2. Type info at the console command prompt to display a list of processes.
The displayed list must contain at least one mp_kerneld.x record as an
indication that the MVTS application is running.
3. Type show stat at the command prompt to display a list of active calls.
Remember that all calls beyond the license capacity of your MVTS will
be rejected automatically.
4. If there is at least one active call in the displayed list of current calls the
MVTS application is working properly and the problem of rejected calls
exists only for a certain route or routes.
5. Check the state of call paths (dial peers) by carrying out the show dial
command. If the command ouputs data for at least one route, it means that
your dial peer configuration is correct and the MVTS routes calls to the
terminating gateway. If the command displays no route data, there are no
dial peers in the dial plan corresponding to the dialed number and the
specified group. In the latter case check your dial plan (file dialpeer.cfg)
for possible errors in dial peers. Please note that all the entries of the dial
plan are case-sensitive which actually means that ‘My_ny_gway’ and
‘my_ny_gway’ are two different gateways.
The dial peer data, displayed by the ‘show dial’ command provide an evidence that your dial
plan is configured properly and the MVTS sends calls to the desired destination(s).
To find out why calls fail in spite of the right configuration, examine CDRs. The MVTS
CDRs contain disconnect cause information in form of local disconnect codes and Q931
codes provided by the MVTS and the equipment of your peering partners.
To view disconnect codes for a call, find the CDR corresponding to the call of interest.
There are two ways to find a CDR – by means of the MVTS Manager and with the help of
the MVTS command console.
For console-assisted viewing of CDRs perform the following steps:
1. Change your working directory to $H323PROXY_ROOT/debug/billing
#>cd $H323PROXY_ROOT/debug/billing
2. To display a sorted list of CDR-files in the directory, type ls –latr .
#> ls –latr
80
1. Select the latest CDR file in the list. It contains information about the
most recent calls handled by the MVTS.
2. Type less <filename> to view the contents of the selected CDR file.
#> less <filename>
3. Type / <search string> to search the file for the necessary CDR using a
phone number, time of the call or other call parameters as a search
criterion.
To view the necessary CDR with the help of the MVTS Manager, perform the following actions:
1. Connect to your MVTS host remotely using the MVTS Manager.
2. Make sure the ‘local’ checkbox of the Log on Dialog box is unchecked.
3. Go to section ‘CDR’ to view the list of CDR files.
4. Double-click the mouse on the necessary CDR file to view the call
parameters.
5. To view the debug log, corresponding to the CDR, right click on the
selected CDR and choose “debug” from the drop-down menu options.
For full information on the MVTS Manager please refer to [13].
Now that the necessary CDR is available, look at the local disconnect code and check the
LDC table to find out what it stands for.
With all MVTS call handling parameters properly configured, i.e. the originating and
terminating endpoint, possible call paths etc., the reason for failing calls is more frequently
than not hard to find. The only way to learn what really prevents calls from happening is a
thorough examination of a detailed debug log that contains a step-by-step transcript of call
sessions. To get the log of the needed call session you must know the ID of the call of
interest. You can get the required call session ID from the session CDR record.
To get the debug log for the call that needs investigation proceed as follows:
1. Make sure the t r a c e _ l e v e l = and l e v e l = parameters in the
section [Debug] of meraproxy.cfg are set to the highest level of
information details, i.e. t r a c e _ l e v e l = 3 , l e v e l = 3
2. Find the CDR record for the call of interest (about finding the necessary
CDR record see above) and get the call ID (the call ID is a 32-digit
hexadecimal number)
3. Change your working directory to /mvts/bin and run the logextractor.sh
script providing the filename of the log file and call ID as the command
options:
#> ./logextractor.sh “logfile” ‘call_id’ > log.txt
where:
logfile is the name of the debug log that will be searched for the call data
call_id is the identifier of the call obtained from the call CDR
log.txt is the name of a new file where the call data will be written
81
Example:
#> ./logextractor “tmp_log_64359bb828958d9127f5a4f6681e60f74c84bb64” ’20 a1 1a 90
7d f5 d8 11 86 29 00 0e 0c 30 a2 1f’ > log.txt
You can use the resulting log of the call session for examination or submit it for analysis by
MERA Customer Support personnel and/or MVTS developers.
Below is a table that an MVTS operator may find instrumental in some uncomplicated
troubleshooting situations. The table contains fault manifestations, explanation of probable
fault causes and simple remedies that resolve the situation.
82
6.1. MALFUNCTIONING SYMPTOMS AND REMEDIES
Table 14 Fault symptoms, causes and remedies
Symptoms Probable cause Resolution
Calls fail with LDC (local Calls through this route are not 1. Correctly configure your RADIUS for call authorization.
disconnect code) 200 though authorized by RADIUS. 2. Disengage RADIUS-aided authorization for certain originating
configuration records in the dial gateways (auth_enable=0).
plan (dialpeer.cfg) and endpoint
files (gateway.cfg, user.cfg) are
correct.
The MVTS application fails to The system is not supportive of Check if your HASP dongle is inserted properly into the usb port.
start USB devices. Check if your Linux kernel is configured to support usb devices.
The HASP dongle cannot be Make sure the HASP dongle drivers are installed (service aksusbd start)
detected.
See if the usb-device driver is loaded ( ps –aux | grep usb )
If all the above checks yield positive results run the hasp_detect.x
executable.
[root@host local]# ./hasp_detect.x
The positive output of the utility is:
Try to detect HASP key
HASP key is connected
The MVTS is seemingly fully Your HASP dongle is See the term of your License and contact your MERA sales manager for
operational but user registrations programmed for a limited License reprogramming the HASP dongle.
are rejected, there are no TCP time which has expired
connects, all calls get rejected.
MVTS rejects RAS registrations Wrong configuration of the The error cause ‘Duplicate alias’ indicates that the rejected VoIP entity is
83
Whiletheinreason
with the GUIDuplicate
manageraliasthe
or Lack of registering
rejected reading permissions
endpoint (RAS
for Make sure
configured both that
as a static
the gateway
files in the gateway.cfg
tmp_log* and log* file andina RAS
the
Security option
‘debug’ denial inonthethecall
drop-down
log user)
files in the registration user in the user.cfg file. Delete
$H323PROXY_ROOT/debug/logs directorytheare
extra
accessible
record leaving
for reading
only the
by
menu stays unselectable despite $H323PROXY_ROOT/debug/lo one default
the that describes
user mvts. the
To grant
entitytheas
mvtsa user
statically
readingconfigured
rights for newly
gateway
created
(in
right-clicking the mouse on a CDR gs directory gateway.cfg) oruse
files a registering endpoint
debug_ (in
f iuser.cfg)
le_attr=444 and
record 4 settings
d e berror
The ug_t m p f ‘Security
cause i l e _ a tdenial’
t r = 4 4indicates thatinsomething
the sectionis [Debug] of the
wrong with the
meraproxy.cfg file. Alternatively, add user mvts to a user
user-password configuration. The MVTS interprets the H323_ID field as the group with the
necessary permissions.
username|password pair, that is registration will be successful only when the
H323_ID
The MVTS field
Manager sentgetsbypreliminary
the registering entity
information aboutisa call
presented like
from CDRs,
H323_ID=123|456
therefore these mustwhile the endpoint’s
be accessible record
for reading in the user.cfg file includes
also.
the settings u s e r = 1 2 3
password=456
The number of simultaneous calls The available file descriptors are Configure the OS for an increased number of file descriptors or recompile
never rises beyond 100. The not enough. the OS kernel (see section 7.3)
system frequently returns local
disconnect code 112
Calls fail when H.245 tunneling is TCP ports in the 1024-65535 ports 1024-65525 should be open for TCP traffic on all firewalls throughout
disabled range closed on some firewall the entire call path
along the call path
No CDR records are visible in the The user who attempts to access To ensure creation of new files with the necessary user permissions set the
MVTS Manager GUI, despite the CDR data does not have b i l _ f i l e _ a t t r = and b i l _ t m p f i l e _ a t t r = parameters in the
being available on the MVTS reading permissions for the section [Billing] of the meraproxy.cfg file to 444, e.g.
server mvts/billing directory or CDR files b i l _ f i l e _ a t t r = 4 4 4 and b i l _ t m p f i l e _ a t t r = 4 4 4
contained therein
84
7. REFERENCE INFORMATION
7.1. DIAL PEER SEARCH ALGORITHM
The MVTS server surveys the call routing options (the list of dial peers) in the order of
decreasing precedence. The appropriate dial peer is considered found if it meets the following
requirements:
• The numbers of the calling and the called party comply with the
d s t _ p a t t e r n = and s r c _ p a t t e r n = respectively.
If the number translation pattern for the calling party (s r c _ p a t t e r n = ) is
not defined then any number is good for the dial peer in question.
• Outbound calls via the selected dial peer are allowed for the group, to which
the originating gateway belongs.
The following algorithm determines groups of gateways allowed or denied
call routing through a dial peer:
o If both g r o u p _ a l l o w = and g r o u p _ d e n y = are empty, then all
gateway groups are allowed calls via the dial peer, else
o If g r o u p _ d e n y = is configured and g r o u p _ a l l o w = is empty,
then all groups are allowed calls through the dial peer, except those
mentioned in g r o u p _ d e n y = , else
o If g r o u p _ a l l o w = is configured while g r o u p _ d e n y = is
empty, then the dial peer will accept only the calls originated by the
groups specified in g r o u p _ a l l o w = , else
o If both g r o u p _ a l l o w and g r o u p _ d e n y are not empty then the
dial peer will accept only the calls from the groups mentioned in
g r o u p _ a l l o w = and not listed in g r o u p _ d e n y =
• The gateway specified in the g a t e w a y = field operates under its full
capacity and does not have the ‘temporary down’ attribute (flag
a c c e s s i b i l i t y is set).
The call is forwarded to the gateway associated with the found dial peer.
If the dial peer record selected in accordance with the d s t _ p a t t e r n = and
s r c _ p a t t e r n = contains the macroname AGAIN in the g a t e w a y = field
(g a t e w a y = A G A I N ), then number translation is initiated and search is repeated again with
modified numbers (maximum number of search cycles is 10).
Below is a graphical representation of the dial peer search algorithm.
85
86
7.2. MVTS – RADIUS INTERACTION
The three types of services that the MVTS may request from a RADIUS server are
authorization, accounting and routing.
In all the three cases the request initiator is the MVTS session controller. The RADIUS server
may initiate a communication exchange with the MVTS server in one situation only: when it
requires of the MVTS to terminate a call due to depletion of the account balance.
With the authorization and routing service the MVTS sends the RADIUS server an
AccessRequest of the appropriate type and receives either an AccessAccept or AccessReject.
During an accounting exchange the MVTS originates an AccountingRequest (Code 4) while
the RADIUS server replies with AccountingResponse.
When the exchange initiator is the RADIUS server, it sends the MVTS DisconnectRequest
(type 40), and the MVTS responds with DisconnectAck(type41) for session termination or with
DisconnectNack(type 42) for the request rejection.
Below is a detailed description of the MVTS-RADIUS server exchange content.
87
IETF Attribute name VSA Description Data format Mandatory
attr. attr. /Optional
No. No. (M/O)
IP address and port
number from which the
26 SourceAddress 1 xpgk-source-addr=IP:port M
RRQ (Registration
Request) was sent
On receipt of AccessReject the authorization is deemed rejected and the MVTS sends the RAS
user RegistrationReject with the cause SecurityDenial.
88
IETF VSA Mandatory
attr. Attribute name attr. Description Data format /Optional
No. No. (M/O)
26 MD5 password 1 MD5 password taken xpgk-md5- O
from auth=<username/<timestamp
RegistrationRequest >>/HEX[16]
26 AuthRequestType 1 Authorization request xpgk-request-type=number M
type
26 Conf ID 24 Conference ID h323-conf-id=<HEX[16]> M
26 Call ID 1 Call ID h323-call-id=<HEX[16]> O
26 SrcGatewayId 33 Originating gateway ID h323-gw-id=<string> or <IP- O
for RADIUS server or address>
its IP-address (if ID is
not defined)
26 SrcGatewayIP 1 IP address of the h323-gw-address=<IP- O
originating gateway address>
26 DstGatewayIP 23 IP address of the h323-remote-address=<IP- O
terminating gateway or address>
gatekeeper
26 DstGatewayId 1 Id of the terminating h323-remote-id=<IP- O
gateway or gatekeeper address>
or its IP address (if ID
is not defined)
26 DstUserName 1 Username of the xpgk-destination- O
terminating gateway user=<string>
26 ReceivedH323Id 1 H323 alias received in xpgk-h323-id=<string> O
Setup packet
26 IncomingAniNumber 1 ANI number received in xpgk-src-number- O
the Setup packet in=<number>
26 OutgoingAniNumber 1 ANI number sent to the xpgk-src-number-out- O
terminating gateway <number>
26 IncomingDnisNumber 1 DNIS number received xpgk-dst-number- O
in the Setup packet in=<number>
26 OutgoingDnisNumber 1 DNIS number sent to xpgk-dst-number-out- O
the terminating gateway <number>
26 RouteRetries 1 Current retry number xpgk-route- M
retries=<number>
89
IETF VSA Mandatory
attr. Attribute name attr. Description Data format /Optional
No. No. (M/O)
h323-return-code (if the
field is not present or its
value is 0, 13, 51 or 52,
h323-return-
26 CISCO_H323_RETURN_CODE 103 the authorization is O
code=<number>
considered successful,
otherwise the call will be
finished with LCD 208)
The username to be used
26 h323-ivr-in 1 in the current session for h323-ivr-in=<string> O
billing purposes
CISCO_H323_REDIRECT_NUM Session DNIS number h323-redirect-
26 BER
106 O
translation number=<number>
A receipt of AccessReject means a negated authorization and the route is rejected with the
appropriate local disconnect code (LDC).
90
IETF VSA Mandatory
attr. Attribute name attr. Description Data format /Optional
No. No. (M/O)
for the outgoing leg
Conference Id received in h323-incoming-conf-
26 IncomingConfId 1 O
Setup id=<conf id>
h323-incoming-call-
26 IncomingCallId 1 Call Id received in Setup O
id=<conf id>
h323-setup-time=<
26 Setup time 25 Setup receipt time hh:mm:ss.uuu t www O
MMM dd yyyy>
Originating gateway ID
for the RADIUS server or h323-gw-id=<string> or
26 SrcGatewayId 33 O
its IP-address (if ID is not <IP-address>
defined)
IP address of the h323-gw-address=<IP-
26 SrcGatewayIP 1 O
originating gateway address>
26 Conf ID 24 Conference ID h323-conf-id=<HEX[16]> M
IP address of the
h323-remote-address=<IP-
26 DstGatewayIP 23 terminating gateway or O
address>
gatekeeper
Id of the terminating
gateway or gatekeeper or h323-remote-id=<IP-
26 DstGatewayId 1 O
its IP address (if ID is not address>
defined)
Username of the xpgk-destination-
26 DstUserName 1 O
terminating gateway user=<string>
H323 alias received in
26 ReceivedH323Id 1 xpgk-h323-id=<string> O
setup
ANI number received in xpgk-src-number-
26 IncomingAniNumber 1 O
setup in=<number>
ANI number sent to the xpgk-src-number-out-
26 OutgoingAniNumber 1 O
terminating gateway <number>
DNIS number received in xpgk-dst-number-
26 IncomingDnisNumber 1 O
setup in=<number>
DNIS number sent to the xpgk-dst-number-out-
26 OutgoingDnisNumber 1 O
terminating gateway <number>
xpgk-route-
26 RouteRetries 1 Current retry number M
retries=<number>
26 Call ID 1 Call ID h323-call-id=<HEX[16]> O
A list of numbers received
xpgk-redirect-
Redirect number 1 from RADIUS during one O
number=<list of numbers>
call session.
xpgk-record-
26 xpgk-record-id 1 Call ID in the CDR format M
id=<RECORD-ID>
91
where
<prefix> is a random 8-digit hexadecimal number
<call number> is the serial number of the call counted since the moment of the latest MVTS start
<hash> is a hash string consisting of 8 hexadecimal digits
<leg type> is the type of the call leg (T for the incoming leg and V for the outgoing leg with the
acct_leg_type= parameter values 1 through 3 and AV for the incoming leg and OV for the
outgoing leg with the acct_leg_type= parameter value 4 or 5)
<route number> is the current call termination attempt number.
92
IETF VSA Mandatory
attr. Attribute name attr. Description Data format /Optional
No. No. (M/O)
h323-call-origin=answer
The type of the leg the for the incoming leg
26 CISCO_H323_CALL_ORIGIN 26 accounting packet pertains M
to h323-call-origin=originate
for the outgoing leg
Conference Id received in h323-incoming-conf-
26 IncomingConfId 1 O
Setup id=<conf id>
h323-incoming-call-
26 IncomingCallId 1 Call Id received in Setup O
id=<conf id>
h323-setup-time=<
26 Setup time 25 Setup receipt time hh:mm:ss.uuu t www O
MMM dd yyyy>
Originating gateway ID
for the RADIUS server or h323-gw-id=<string> or
26 SrcGatewayId 33 O
its IP-address (if ID is not <IP-address>
defined)
IP address of the h323-gw-address=<IP-
26 SrcGatewayIP 1 O
originating gateway address>
h323-connect-time=<
26 Connect time 28 Connect time hh:mm:ss.uuu t www O
MMM dd yyyy>
h323-disconnect-time=<
26 Disconnect time 29 Disconnect time hh:mm:ss.uuu t www O
MMM dd yyyy>
h323-disconnect-
26 Disconnect cause 30 Q931 disconnect reason O
cause=<value>
QoS calculated using
h323-voice-
26 Voice quality 31 MERA’s proprietary O
quality=<value>
algorithm
xpgk-local-disconnect-
26 Local disconnect cause 1 Local disconnect code O
cause=<value>
Cause for stopping search
26 LAR fault reason 1 of routes to terminate the xpgk-lar-fault=<value> O
call
Codec list declared by the xpgk-src-codec=<codec
26 Codecs of source gateway 1 O
originating GW list>
Codec list declared by the xpgk-dst-codec=<codec
26 Codecs of terminating gateway 1 O
terminating GW list>
xpgk-initial-incoming-
Local address the call was
26 Initial incoming IP address 1 local-address=<IP- O
received at
address>
xpgk-selected-incoming-
Local address chosen for
26 Selected incoming IP address 1 local-address=<IP- O
the call
address>
xpgk-selected-incoming-
Local address used for the
26 Selected outgoing IP address 1 local-address=<IP- O
outgoing leg
address>
93
IETF VSA Mandatory
attr. Attribute name attr. Description Data format /Optional
No. No. (M/O)
through
IP-address of the
26 Converter IP-address 1 converter the call was xpgk-converter-address O
terminated through
The time interval between
26 SCD-time 1 the call arrival and the xpgk-scd-time O
receiver pickup
26 Conf ID 24 Conference ID h323-conf-id=<HEX[16]> O
IP address of the
h323-remote-address=<IP-
26 DstGatewayIP 23 terminating gateway or O
address>
gatekeeper
Id of the terminating
gateway or gatekeeper or h323-remote-id=<IP-
26 DstGatewayId 1 O
its IP address (if ID is not address>
defined)
Username of the xpgk-destination-
26 DstUserName 1 O
terminating gateway user=<string>
H323 alias received in
26 ReceivedH323Id 1 xpgk-h323-id=<string> O
setup
ANI number received in xpgk-src-number-
26 IncomingAniNumber 1 O
setup in=<number>
ANI number sent to the xpgk-src-number-out-
26 OutgoingAniNumber 1 O
terminating gateway <number>
DNIS number received in xpgk-dst-number-
26 IncomingDnisNumber 1 O
setup in=<number>
DNIS number sent to the xpgk-dst-number-out-
26 OutgoingDnisNumber 1 O
terminating gateway <number>
xpgk-route-
26 RouteRetries 1 Current retry number M
retries=<number>
26 Call ID 1 Call ID h323-call-id=<HEX[16]> O
Redirect number 1 A list of numbers received xpgk-redirect- O
from RADIUS during one number=<list of numbers>
call session.
26 InfoNumber 1 The call destination xpgk-info- O
number formed by the number=<number>
MVTS from the data
received in the Setup and
Information messages
26 xpgk-record-id 1 Call ID in the CDR format xpgk-record- M
id=<RECORD-ID>
94
where
< p r e f i x > is a random 8-digit hexadecimal number
< c a l l n u m b e r > is the serial number of the call counted since the moment of the latest MVTS
start
< h a s h > is a hash string consisting of 8 hexadecimal digits
< l e g t y p e > is the type of the call leg (T for the incoming leg and V for the outgoing leg with
the a c c t _ l e g _ t y p e = parameter values 1 through 3 and AV for the incoming leg and OV
for the outgoing leg with the a c c t _ l e g _ t y p e = parameter value 4 or 5)
< r o u t e n u m b e r > is the current call termination attempt number
95
d e s t is the number of the called party which will be sent to the terminating gateway
(dst_number)
s r c _ b i l l is the callee’s billing number;
d s t _ b i l l is the caller’s billing number;
i p - a d d r e s s [ : p o r t ] denotes an ip-address for call setup. The p o r t extension is
optional and if omitted the default port value (1720) will be used.
The top five fields are mandatory.
There can be only one field with ID=251. There can be several ID=252 fields and the routes
contained therein will be processed sequentially.
96
IETF VSA Mandatory
attr. Attribute name attr. Description Data format /Optional
No. No. (M/O)
26 AuthRequestType 1 Routing request type xpgk-request-type=route M
Routing request flag External routing request xpgk-routing-request=1
26 1 M
flag
26 Conf ID 24 Conference ID h323-conf-id=<HEX[16]> M
26 Call ID 1 Call ID h323-call-id=<HEX[16]> O
Originating gateway ID
for RADIUS server or its h323-gw-id=<string> or
26 SrcGatewayId 33 O
IP-address (if ID is not <IP-address>
defined)
IP address of originating h323-gw-address=<IP-
26 SrcGatewayIP 1 O
gateway address>
IP address of terminating h323-remote-address=<IP-
26 DstGatewayIP 23 O
gateway or gatekeeper address>
Id of terminating gateway
or gatekeeper or its IP h323-remote-id=<IP-
26 DstGatewayId 1 O
address (if ID is not address>
defined)
Username of terminating xpgk-destination-
26 DstUserName 1 O
gateway user=<string>
H323 alias received in
26 ReceivedH323Id 1 xpgk-h323-id=<string> O
setup packet
ANI number received in xpgk-src-number-
26 IncomingAniNumber 1 O
setup packet in=<number>
ANI number sent to xpgk-src-number-out-
26 OutgoingAniNumber 1 O
terminating gateway <number>
DNIS number received in xpgk-dst-number-
26 IncomingDnisNumber 1 O
setup packet in=<number>
DNIS number sent to xpgk-dst-number-out-
26 OutgoingDnisNumber 1 O
terminating gateway <number>
xpgk-route-
26 RouteRetries 1 Current retry number M
retries=<number>
97
IETF VSA Mandatory
attr. Attribute name attr. Description Data format /Optional
No. No. (M/O)
in the same order as they go in content below
the packet)
XPGK-XROUTING- ANI/DNIS/Bill_ANI/
26 250 Translation of the call numbers M
TRANSLATE Bill_DNIS
AccessReject – route authorization failed and the route is rejected with the appropriate LDC
The MVTS is capable of handling RADIUS call disconnect requests of type DisconnectRequest
(type 40).
The disconnect request packet must include the field VSA(24) h323-conf-id or VSA(1)
h323_incoming-conf-id presented as 4 hexadecimal octets, delimited by blank spaces (similar to
ConfId sent by the MVTS to the RADIUS server). This ConfId is used in the active call search.
The call is terminated with LDC 100 cause (ForceTerminateCall).
If call termination was successful the MVTS responds with the DisconnectAck(type41) packet.
If call termination failed (the call was not found or the field ConfId is missing) the MVTS
responds with DisconnectNack(type 42).
98
7.2.6. AUTHENTICATION OF REGISTERING ENDPOINTS NOT
CONFIGURED IN USER.CFG
To allow any registering endpoint that is not configured in the user.cfg file to register with the
MVTS gatekeeper, add the section [Default] to the file user.cfg. An example of the section is
given below.
user.cfg
…
[Default]
user=default
…
Authentication of such RAS users is possible through the RADIUS server only. Authentication
methods applied to RAS users registering by means of the section [Default] depend on the
authentication algorithms supported by the registering endpoint and include:
During standard RADIUS authentication the registering endpoint (RAS-user) sends the MVTS
an AccessRequest packet with the user’s ID in the field terminalAlias (marked with the red
ellipse in the figure below). The user’s ID consists of the user’s name and password delimited by
one of the following symbols: «|», «:», «!» or «%».
Upon receipt of the packet, the MVTS forwards to the RADIUS server an access request
(marked with the red rectangle) with the user’s name, password, the MVTS identifier and port
the RAS user attempts to access. The password undergoes MD5 hash encryption and is obtained
from:
where
Shared Secret is the value of the parameter secret= of the section [Radius] in meraproxy.cfg
RemoteAuthenticator is a pseudorandom number present in the header of the AccessRequest
packet received from the registering endpoint;
99
password denotes the user’s password available from the MVTS configuration files.
Based on the received data and the shared secret established between the MVTS and the
RADIUS server, the RADIUS server generates an MD5 hash and if the newly generated hash
matches the one received from the MVTS, the RADIUS server responds with AccessAccept,
otherwise the server’s reply is AccessReject.
MD5 Authentication
With this type of authentication involved the GatekeeperRequest that the MVTS receives form
the registering endpoint contains the information that the endpoint is supportive of this
authentication method. Upon receipt of the GatekeeperConfirm packet from the MVTS, the
endpoint responds with a registration request containing the user’s alias, time stamp, MD5 hash
password and data about the parameters used for the hash generation (marked with the red ellipse
in the figure below). As the MVTS is unaware of the user’s true password, it sends the hashed
password in the VSA(1) field xpgk-md5-auth (marked with the red rectangle) together with the
parameters used for its generation rather than in the field password. The RADIUS server must
possess the capability to read the VSA(1) field xpgk-md5-auth.
100
.
Fig. 54 MD5 authentication
CHAP Authentication
With CHAP authentication the GatekeeperRequest that the MVTS receives form the registering
endpoint contains the information that the endpoint is supportive of this authentication method.
The MVTS responds with a GatekeeperConfirm packet that includes the ‘challenge’ (a
pseudorandom hexadecimal number). The registering user sends the MVTS a registration request
the field tokens of which contains the challenge and the hashed password generated using the
challenge, the user’s password and identifier. Following this the MVTS sends the RADIUS
server a registration request with the data as below:
101
The RADIUS server reads the fields ChapPassword, ChapChallenge and searches its database
for the user’s password using the user’s name for the search argument. Based on the found
password, the user’s name and the challenge the RADIUS server is expected to generate an
identical hash. If the hash generated by the RADIUS server does not match the hash received
from the MVTS, the authentication attempt is rejected.
Note: In case a RAS-user supports both MD5 and CHAP authentication , the use of CHAP
authentication is preferable because in case of CHAP authentication the MVTS does not have to
use VSA fields.
Digest authentication
The registering endpoint sends the SIP-HIT module a registration request (the packet
“REGISTER”)
The SIP-HIT module responds to the request with packet 401 containing the so-
called “nonce”, i.e. a pseudorandom number.
Using the received “nonce” and some other data the registering user generates an
MD5 hash (DigestResponse) and sends it back along with the data used for its
generation in the REGISTER response packet.
The SIP-HIT forwards to the MVTS a registration request containing in the field
tokens a certificate comprised of the user generated MD5 hash and the data used for
its generation.
The MVTS uses an AccessRequest packet to provide the RADIUS server with the
user’s MD5 hash and the hash generation data.
Based on the received data and the user’s password stored in the database the
RADIUS server is supposed generate an identical MD5 hash. In case the hash
generated by the RADIUS server coincides with the hash received from the MVTS
in the SipDigestResponse attribute (marked with the red ellipse in Fig. 56), the user
is authenticated, otherwise the authentication fails.
102
7.3. PROVIDING FOR ENOUGH FILE DESCRIPTORS
Note: If you plan to install a demo version of the product or the capacity of your production
MVTS is below 60 concurrent calls, no kernel customization is required, and you may skip the
information given below.
The MVTS is a resource-intensive application in terms of computing power and is especially
unsparing of file descriptors. Each open file, socket or FIFO requires one file descriptor at least.
At the same time, the standard configuration of the OS kernel allows but a limited number of file
descriptors (normally, 1024).
Therefore, an operator planning for a large-scale service may want to change this parameter and
add the appropriate command to the system initialization script or even rebuild the kernel to
allow a large number of simultaneously open file descriptors.
In estimating the necessary number of simultaneously available file descriptors, it is reasonable
to proceed from the assumption that six to twelve file descriptors are required to proxy a single
call (during signaling or media proxy operation). With a certain allowance for the needs of the
operating system itself, it is safe to state that 20 simultaneously open file descriptors per call
should be fully commensurate with the system operating demands. As a general landmark the
8192 limit would be enough for a 600 calls system and the 16384 setting will meet the file
descriptor demand for 1000 concurrent calls.
Before you proceed to increase the number of available file descriptors in the RedHat Linux
operating system you have to decide what user account will be used to start the MVTS.
The following three variants are possible:
1. Root account is used to start the MVTS, thus the increased number of file
descriptors is made available when the root user logs on to the system.
2. A specific user account (other than root) is used to start the MVTS and the
increased number of descriptors is available to this user only.
3. Any user starting the MVTS operates the system with the increased number
of file descriptors.
Each of the three variants is described below.
If you are willing to make the increased number of available file descriptors permanent for user
root only, follow the instructions below:
1. Open file /etc/profile in any editor (vi)
vi /etc/profile
103
2. Add “ulimit –n 8192” to the file /etc/profile
If you intend to allow a specific user (other than root) to start the MVTS and you wish to make
the increased number of descriptors available for this user only, proceed as follows:
1. Open file /etc/pam.d/login
vi /etc/pam.d/login
vi /etc/security/limits.conf
104
6. Save the changes made in the /etc/security/limits.conf file
If you are planning to make the increased number of file descriptors available for any user who
starts the MVTS application follow the algorithm below:
vi etc/profile
vi etc/security limits.conf
105
7.3.2. SETTING THE NUMBER OF FILE DESCRIPTORS FOR FREEBSD
Unlike in the Red Hat Linux, the number of descriptors for simultaneously open files
(kern.maxfiles) in the FreeBSD operating system is linked to the value of the MAXUSERS
parameter. (See http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/configtuning-
kernel-limits.html).
The number-of-users dependence for simultaneously open file descriptors is expressed by the
following equation:
kern.maxfiles=(20+MAXUSERS*16)*2
It means that enabling the FreeBSD OS to open 8000 file descriptors and above (based on the
approximate estimate of 20 sockets per a call) will require rebuilding the kernel with
MAXUSERS set to no less than 249, i.e.
106
7.4. USE OF REGULAR EXPRESSIONS IN CONFIGURING MVTS
You have to use regular expressions while setting the following MVTS parameters:
dialpeer.cfg
- dst_pattern=, src_pattern=,
- dst_translate=, src_translate=
- dst_bill_translate=, src_bill_translate=
- user_translate=
- display_ie_translate=
user.cfg; gateway.cfg
- dst_pattern=, src_pattern=,
- dst_translate=, src_translate=,
- in_dst_translate=, in_src_translate=
Use the keyword ‘empty’ when you need to indicate an empty number string (for example in the
description of a dialpeer.)
Example:
With the value of the parameter src_translate=empty/123456, the MVTS translates the
received empty calling number string into 123456.
You can also use the keyword ‘empty’ for transformation of the ‘display’ information element
(IE) (dialpeer.cfg, parameter display_ie_translate=), when it is not included in SETUP.
The system checks configured regular expressions for the validity of used characters and
removes unacceptable symbols. The characters allowed in regular expressions are:
^0123456789*#\&
The outcome of the validity check can be found in the trace log written to the file
mp.kernel.sh.log-<date>.
dst_pattern=777[0-9]+
Comment: destination numbers starting with 777 followed by any number of digits in the 0 – 9
range.
good examples: 77711, 777922
107
bad examples: 77811, 7767
dst_pattern=777[0-5]{1}[0-9]+
Comment: destination numbers starting with 777 followed by a single digit in the range from 0
through 5, and then by any number of digits ranging from 0 through 9
dst_pattern=......
or
dst_pattern=.{6}
Comment: any six characters (can include all valid symbols – e.g. #)
• A slash “/” divides the regular expression in two parts: the search pattern and the
substitution string. All characters to the left of the slash are the search pattern (all
numbers that match the search pattern are subject to transformation). All characters
to the right of the slash constitute the substitution string (i.e. the string used as a
replacement for the phone number match found with the help of the search pattern).
• Vertical bars “|” serve to divide the search pattern into two or more portions
108
• A backslash “\”is used in the rightmost part of the regular expression. A digit that
follows this character indicates which portion of the string divided by ‘|’ is to be used
to form a new number.
• The ampersand character “&” is used in the substitution part of the expression to
denote that the entire string should be used in the number transformation.
• The period symbol (dot) “.” denotes a single occurrence of any valid character
• A numeric expression in square brackets is used in the search pattern only and
denotes a single digit out of the numeric interval or sequence in the brackets. For
instance: [0-9] stands for any number from zero through nine, [1234] stands for any
digit in the range of 1 through 4, i.e. 1 or 2 or 3 or 4, [1236-9] denotes any digit out
of the following: 1, 2, 3, 6, 7, 8, 9.
• A digit in braces indicates the number of occurrences of the preceding character or
expression. For instance: .{4} means four dots, i.e. .{4} = …. , while [0-9]{2} stands
for two times [0-9], i.e. [0-9]{2}=[0-9] [0-9].
• An asterisk denotes any number of occurrences of the preceding symbol or
expression. For instance [0-9]* stands for any number of digits in the 0-9 range. .*
means any number of arbitrary characters.
1. Addition
Objective 1: add prefix 78 to number 12345:
dst_translate=12345/78&
result: 12345 → 78 12345
109
Objective 4: concatenate the number adding 77
dst_pattern=.*
dst_translate=.*/&77
2. Removal
Objective 1: strip any number of prefix 095 if present
dst_pattern=.*
dst_translate=095|.*/\2
dst_translate=[0-9]*|#|[0-9]*/\1\3
Comment: in this expression two vertical lines divide the search string in three parts,
isolating the middle #. The syntax of the replacement string indicates that only the first and
the third part are used to form a new number.
3. Replacement
d s t _ p a t t e r n =.*
dst_translate=8182|[0-9]*/777\2
110
Comment: the vertical line in the search string splits it in two logical parts (8182 and [0-9]).
The replacement string is made up of the substring 777 and the second part of the search
pattern.
Objective 3: replace the # character in the middle of the string with 555
dst_translate=[0-9]*|#|[0-9]*/\1 555\3
dst_bill_translate=[0-9]*|#/\1 123
Comment: Use the vertical line character to segregate the character # in the end of the
search string. The replacement string is comprised of the first part of the search string only
and concatenates 123 to it.
Note: do not fail to insert a space between \1 and 123. In the absence of the space the system will
interpret the expression \1123 as ‘use 1123rd logical part from the divided search string’.
The number translation patterns used in the configuration files can include the following
macronames:
111
$bill_ani$ - substitute the number of the calling party for billing purposes
$bill_dnis$ - substitute the number of the called party for billing purposes
$id$ – unique call identifier (extracted form a CDR record) in the following notation
<MVTS start time stamp>#<call ordinal number>#
Example:
(the task is to swap caller’s and callee’s number)
dst_translate=.*/$ani$
src_translate=.*/$dnis$
The macronames $bill_ani$, $bill_dnis$ cannot be used in translation that precedes dial peer
search, i.e. in the configuration parameters whose names start with the prefix in_ (e.g.
i n _ d s t _ t r a n s l a t e = , i n _ s r c _ t r a n s l a t e = ).
7.7. DEFINITIONS
The table below contains the definitions used in the manual.
112
Gateway POTS-to-VoIP Gateway, providing “regular” telephony becomes
Voice-over-IP. Gateway does the following:
- answers a telephony call on the line or trunk connected to it
- establishes a connection to the remote gateway with or without
directions from gatekeeper
- voice/fax data encoding/decoding, compressing, etc.
- connects the call through to the remote subscriber over the net and
vise versa
RAS user A VoIP net entity (a gateway or a terminal), registered with the
gatekeeper under the RAS (Registration, Admission and Status)
protocol.
Debug log A log file in plain text format used to log and store call session
events, including the server state, call state, date/time stamps.
Trace log A plain text file generated during the periods of system
malfunctioning and used for analytic purposes.
7.8. ACRONYMS
113
GID Group Identifier
GK Gatekeeper
GUI Graphics User Interface
HASP Hardware Against Software Piracy (a hardware-based security system
that protects software against piracy and illegal use)
HDD Hard Disk Drive
ICN Internal Call Number. ICN is the call’s sequential number counted
from the last start of the MVTS application.
LB Load Balancer
LDC Local Disconnect Code
MMVTS Media MVTS
MVTS MERA VoIP Transit Softswitch
NAT Network Address Translation/Translator
OS Operating System
POTS Plain Old Telephone Service (used in this manual as an opposition to
‘VoIP’).
PSTN Public Switched Telephone Network
QoS Quality of Service (calculated as a ratio of total number of lost packets
to the total number of received packets multiplied by 100)
RADIUS Remote Authentication Dial In User Service (a client/server protocol
and software to enable remote-access equipment to communicate with
a central server to authenticate dial-in users and authorize their access
to the requested system or service).
RAS Registration, Admission, and Status protocol. H.225 signaling
protocol that is used between endpoints and the gatekeeper to perform
management functions. RAS signaling function performs registration,
admissions, bandwidth changes, status, and disengage procedures
between the VoIP gateway and the gatekeeper.
RPM Red-Hat Package Manager
RTCP Real-time Transport Control Protocol
RTP Real-time Transport Protocol
SBC Session Border Controller
SC Session Controller
SIP Session Initiation Protocol
SMVTS Signaling MVTS
SNMP Simple Network Management Protocol
114
VoIP Voice over Internet Protocol
VSA Vendor-Specific Attribute
PBX Private Branch eXchange
115
Appendix A SYNTAX OF REGULAR EXPRESSIONS
The values appearing hereinafter between the quotation marks (“”) mean the values returned by
regular expressions while the symbols between the ‘’ characters are intended to illustrate the syntax of
regular expression.
The sought-for patterns
The required pattern is a character or a string of characters enclosed in parentheses or square brackets.
Use of parentheses and square brackets is explained below.
Character classes
Through use of the square brackets one may define a group of characters (commonly called a character
class) to find. For example, expression ‘1[23]45’ matches words <1245> and <1345>, i.e. any word
starting with <1> followed by either <2> or <3> and ending with <45>.
The reverse is also possible, that is - one may define characters that must not be present in the found
substring. For expamle, expression ‘[^1-6]’ finds all characters except digits from 1 through 6.
Quantifiers
If one is unaware of how many symbols there might be in the sought substring, it is possible to use
metacharacters which are referred to by an intricate name as quantifiers.
For example, setting ‘1234+5’ means a word starting with “123” followed by one or several 4s and
ending with 5. One important point to remember is that the quantifier applies to the entire preceding
expression and not to an individual character!
116
Metacharacter Description
For example, '4{1,3}’ finds three first instances of 4 in
"5444446".
'4{0,1}' is equivalent ot '4?'. There must be no spaces
between the comma and the digits following it.
Greediness
An important characteristic of the ‘*’ and ‘+’ quantifiers is their greedy nature. They will always
look for the biggest match possible rather than what you really need. That is:
The above expression means: “search for ‘h’ followed by several arbitrary symbols followed by ‘o’
“. The operator probably meant finding ‘hello’ but due to greediness of the quantifiers the search
will yield “hello out there, how are yo”, since they look for “o” as far to the right as possible rather
than for the first instance of the character. Use the ‘?’ meta character to cure the greediness. For
example:
$test = "hello out there, how are you";
$test =~ m/h.*?o/
will yield exactly “hello” since the expression searches for ‘h’ which is followed by several
arbitrary characters until first occurrence of ‘o’.
To put it in a nutshell, the greediness of a quantified subpattern means that it will match as many
times as possible (given a particular starting location) while still allowing the rest of the pattern to
match. Follow the quantifier with a ‘?’ when the minimum number of matches possible is required.
*? Match 0 or more times
+? Match 1 or more times
?? Match 0 or 1 time
{n}? Match exactly n times
{n,}? Match at least n times
{n,m}?Match at least n but not more than m times.
Note: Note that the meanings do not change, just the scope of “greediness”.
117
The ‘|’ character is the alternation operator in regular expressions and is used to match either what’s
on its left side or right side. Employment of the ‘|’ operator together with parentheses ‘(…|…|…)’
permits creation of alternative groups.
Parentheses serve for ‘seizure’ of substrings for subsequent reuse and saving them to read-only
variables $1, $2… $9.
Backreferencing
The important ability of regular expressions to save matching substrings for later reuse has been
mentioned already. Though, this can be avoided through use of the ‘?:’ operator.
For example:
$test = "Today is monday the 18th.";
$test =~ m/([0-9]+)th/
118
Appendix B SNMP STATISTICS
SNMP statistics is available for the following objects: call originating endpoints, call terminating
endpoints, dial peers, gateways and routes, i.e. call paths.
Data for all types of objects are stored in MIB tables.
MIB table identifiers are as follows:
Legend:
Y – object index (>=1),
X = 101 for originators
119
X = 103 for dial peers
X = 105 for terminators
X = 107 for gateways
The index in these tables is an integer value for the statistical object (index >=1). Every object of
SNMP statistics is assigned a dynamic index. Information about objects of statistics and assigned
indices is saved to the file snmp_index (the directory where MVTS will save this file is specified in
the parameter file=, section [Statistics]). Upon restart the MVTS reads the file and assigns every
created object of statistics the index the object had before the application restart.
The index is considered obsolete and subject to removal if the object of SNMP statistics remains
inactive for 48 hours.
120
1.3.6.1.4.1.999.10.X.1.18.Y Integer Kbytes sent
The index in this table is an integer value for the statistical object (index >=1). The index is
assigned to the object at the start of statistics collection and remains such as long as the statistical
object exists.
121
1.3.6.1.4.1.999.10.109.1.19.Y String Route status. Possible
values: "NotAccessible",
"PartlyAccessible",
"FullyAccessible"
Legend:
Y – Index of the object to which the statistics pertain
Z – index of a given pair of disconnect codes
The index is calculated by the following formula:
index = 100+LDC*127+Q931
where LDC is the MVTS local disconnect code, Q931 is the disconnect code according to the Q931
standard.
X = 101 for call disconnect codes statistics on originators,
X = 102 for call disconnect codes statistics on dial peers,
X = 105 for call disconnect codes statistics on call terminators,
X = 107 for call disconnect codes statistics on gateways,
X = 109 for call disconnect codes statistics on routes.
122
123
Appendix C MVTS LOCAL DISCONNECT CODES
124
Code Name Description
109 eInvalidH225ReadCalled The MVTS could not read out the
H.225-packet received from the call
terminator
110 eDestinationUnreachable Failure to find the appropriate dial peer
or none of the contacted gateways is
available
112 eFailedTCPConnectH225 Failure to set up an H.225 session with
the call terminator
113 eInvalidCalledIpAddress Invalid IP-address of the call terminator
(according to the routing plan)
114 eFailedDecodeUUCaller Failure to decode the UserUserField in
the packet received from the call
originator
115 eInvalidTPKTCaller Error in the packet heading received
from the call originator. Occurs in case
of improper operation of the gateway
116 eFailedDecodeUUCalled Failure to decode the UserUserField in
the packet received from the call
terminator
118 eDuplicateCallId The Call ID of the received call already
exists in one of the active links
(protection against infinite call looping)
119 eInvalidTPKTCalled Error in the packet heading received
from the call terminator. Occurs in case
of improper operation of the gateway
120 eTimeoutRouteAttempt Failure to setup a link with the
terminating gateway within 10 seconds
after commencement of routing to this
gateway
121 eTimeoutSetupMsg Failure to receive Setup within 15
seconds
122 eTimeoutRTPidle No voice traffic for 180 seconds during
full media proxy operation. In such a
case the call is presumed dangling and is
terminated
123 eFailedTCPConnectH245Caller Failure to initiate an H.245 session with
the call originator.
125
Code Name Description
was not the first to arrive)
125 eMaxRerouteRetries Over 10 rerouting attempts undertaken
(protection against infinite looping in the
look-ahead procedure)
126 eMaxCapacityExceed The maximum value of the capacity=
parameter for the call originator
exceeded
127 eRouteBlocked The route “originator-dialpeer-
terminator” was blocked by the smart
routing
128 eFailedTCPConnectH245Called Failure to initiate an H.245 session with
the call terminator.
129 eNotAllowedPrefix Attempted call to destination number
with disallowed prefix
130 eDuplicateCalledPartyNumber Maximimum number of call sessions
with identical DNIS number exceeded
131 eNoPacketTimeOut Call aborted owing to absence of packets
within the configured timeout
132 eConsoleTerminatedCall The call forcefully interrupted by a
command from the administration
console
133 eDialpeerCapacityExceeded The maximum value of the parameter
сapacity= for a dialpeer exceeded
134 eGatewayUnaccessible Call failed owing to the inaccessibility
of the terminating gateway
135 eGatewayIncompatible Call failed owing to the mismatch of the
terminating and originating gateways
“capability”
136 eDestinationGatewayCapacityExceeded Call failed because the capacity (call
limit) of the terminating gateway was
exceded
137 eGatewayNullReached Routing stopped on a dialpeer with
gateway=NULL and q931_cause
138 eHuntStopped The dialpeer search stopped with
hunt_stop=1.
139 eNoAppropriateDialpeer No appropriate dialpeer found during the
call route search
200 eRadiusAdmissionCallerReject Call originator authorization denied by
the RADIUS-server
126
Code Name Description
201 eGkClientAdmissionTimeout No response to the Admission Request
from a remote gatekeeper within 10
seconds
202 eSourceGatewayUnknown Unknown IP-address of the call
originator (the call goes via the SIP-HIT
converter)
203 eGkClientAdmissionReject Admission Request rejected by the
remote gatekeeper
205 eSourceGatewayAniReject Originator’s src_number does not match
the number, specified in the ani_allow
field of the gateway or RAS-user record
206 eRadiusAdmissionTimeout No response from the Radius server for
10 seconds
207 eRadiusAdmissionCallerReject Call terminator authorization denied by
the RADIUS-server
208 eRadiusAdmissionRouteReject Call routing denial from the RADIUS
server
209 eRouteProhibited A call from/to a prohibited address
210 eIncomingBandwidthOverload The incoming bandwidth for IP-
addresses exceeded with the set
local_ip_manager= parameter.
211 eOutcomingBandwidthOverload The outgoing bandwidth for IP-
addresses exceeded with the set
local_ip_manager= parameter.
212 eOutgoingDestNumberEmpty Attempt to send Setup with empty
CalledStationId.
213 ePacketOfDisconnect The call forcefully terminated by
PacketOfDisconnect from the RADIUS
server
300 eMaxSessionTime Exceeding of the call maximum time
(delivered by the Radius server as
CISCO_H323_CREDIT_TIME)
301 eDanglingCall Call duration is in excess of the preset
limit (default value is 10000 seconds,
i.e. 2 hours 46 minutes 40 seconds), and
the call is presumed dangling
302 eSystemOverflow The license limit of authorized
concurrent calls exceeded.
303 eSourceGatewayExpired Expiration date set in expire_date for the
127
Code Name Description
originating gateway exceeded
304 eDestinationGatewayExpired Expiration date configured in
expire_date for a destination gateway
exceeded
305 eIncomingTrafficExceeded Time limit for incoming traffic
configured in the max_incoming_time
exceeded
306 eOutgoingTrafficExceeded Limit set in max_outgoing_time=
was exceeded.
400 eNoMediaServer Media MVTS for call termination from
the signaling MVTS not found
401 eFailedTCPConnectMediaServer Failure to establish a TCP-connection to
Media MVTS
The Local Disconnect Codes generated by an MVTS cluster version are different from those
generated by a stand-alone MVTS. The difference is as follows: when the call session completes the
MediaMVTS generates an LDC for sending it to the Signalling MVTS and adds 1000 to it. For
instance, if the call completed normally with a “ReleaseComplete” message from the call terminator
(i.e. LDC=2), the MediaMVTS sends the Signaling MVTS LDC 1002.
128
Appendix D EQUIPMENT COMPATIBILITY
VOIP GATEWAYS AND GATEKEEPERS
MERA VoIP Transit Softswitch has been tested and proved compatible with the H.323 equipment
of the following vendors:
129