Sei sulla pagina 1di 130

MERA VoIP Transit Softswitch v 3.1.

2
Operator's manual

© 2006 Mera Systems Inc.


MERA VoIP Transit Softswich v 3.1.2

Document №: 2
Document type: Operator’s manual
Document status:
Date of issue: 03.05.2006
Responsible
Technical Writer
employee:

C o p yr igh t © 200 6 M er a S ys t ems I nc .


A l l r ig h ts r es er ve d .

M er a S ys tems I nc .r es e r ves th e r i gh t t o c han ge a n y i n fo r ma t io n c o n ta ine d i n t h is


d oc u men t w i tho u t pr io r no t ic e .

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 .

© 2006 Mera Systems Inc.


History of changes

Date Version Author and description of changes


02.09.05 Release azharkov: description of the “show call” command
options added (command syntax: sh ca [-dstname ...] [-
srcname ...]), 2 screenshots
02.09.05 Release azharkov: ACD description added (to the “Acronyms”
table)
02.09.05 Release azharkov: 2 CDR fields described: PDD Time and
PDD Reason
02.09.05 Release azharkov: comment on the “show dp” command (total
dialpeer output restriction) inserted
02.09.05 Release azharkov : new LCD 130, described
02.09.05 Release azharkov: new Access Request field, sent to RADIUS
for user authentication, described
02.09.05 Release azharkov: comment on the sysadmin email notification
in case of the MVTS system failure and activation of
the failover server, inserted (chapter Hardware Fault
Tolerance)
02.09.05 Release azharkov: new field of Access Accept in response to
request for external routing, added and described
15.09.05 Release azharkov: names of documents in the Table of
References, changed
Name of this document, modified
screenshot of the di gk command, added
the instance of the CDR record, changed as obsolete
2 new CDR fields SRC-RTP-IP and DST-RTP-IP,
added and described
19.09.2005 Release azharkov: Tables ‘Definitions’ and ‘Acronyms’,
modified
20.09.05 Release azharkov: chapter “File descriptors”, modified
22.11.05 Release askudalov: added chapter “Authentication of registering
endpoints not configured in user.cfg”
30/01/2006 Release Technical writer
Added description of the ‘show snmp’ command of the
administration console
Added description of the ‘all’ option to the section

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

Table 1 Typographic conventions used in the document............................................................... 10


Table 2 MVTS server hardware requirements (gatekeeper only).................................................. 19
Table 3 Capacity-dependent hardware requirements for signaling proxy operation ..................... 19
Table 4 Capacity-dependent hardware requirements for full proxy operation .............................. 20
Table 5 MVTS user groups............................................................................................................ 22
Table 6 MVTS configuration files ................................................................................................. 28
Table 7 Call data for a group of calls, output by the s h o w c a l l command.......................... 39
Table 8 CSVs displayed by the s h o w c a l l command with the ICN argument .................... 40
Table 9 Parameters, displayed by the s h o w e p command ...................................................... 46
Table 10 Dial-peer parameters, displayed onscreen by the s h o w d p command ..................... 49
Table 11 Parameters, displayed by the s h o w r e d u n d a n c y command ............................. 55
Table 12 CDR fields ...................................................................................................................... 60
Table 13 Command-line options of the MVTS kernel (mp_kerneld.x)......................................... 74
Table 14 Fault symptoms, causes and remedies ............................................................................ 83
Table 15 AccessRequest structure in authorization request for a registering endpoint ................. 87
Table 16 Content of AccessAccept sent by RADIUS server when authorizing a registering entity
................................................................................................................................................ 88
Table 17 AccessRequest structure in pre-routing call authorization ............................................. 88
Table 18 Content of AccessAccept response from RADIUS server in pre-routing call
authorization .......................................................................................................................... 89
Table 19 Structure of Accounting Start record forwarded to RADIUS server.............................. 90
Table 20 Structure of the Accounting Stop record sent to RADIUS server .................................. 92
Table 21 Structure of routing request sent to RADIUS server ...................................................... 96
Table 22 Structure of AccessAccept response from RADIUS server ........................................... 97
Table 23 Definitions, alphabetized .............................................................................................. 112
Table 24 List of acronyms used in this manual ........................................................................... 113
Table 25 List of quantifiers.......................................................................................................... 116
Table 26 MVTS-generated disconnect codes .............................................................................. 124

6
List of Figures

Fig. 1 Stand-alone MVTS system architecture .............................................................................. 14


Fig. 2 Two-level MVTS system..................................................................................................... 15
Fig. 3 Three-level MVTS switching facility made up of a cluster of two-level systems .............. 16
Fig. 4 Two-way SIP-H.323 translation .......................................................................................... 17
Fig. 5 MVTS file system structure................................................................................................. 24
Fig. 6 Administration console terminal screen .............................................................................. 32
Fig. 7 Output of the “help” command............................................................................................ 34
Fig. 8 Output of the ‘reload config’ command .............................................................................. 35
Fig. 9 Output of the ‘re st’ command............................................................................................. 35
Fig. 10 Output of the ‘reset stat all’ command .............................................................................. 36
Fig. 11 Starting the MVTS kernel.................................................................................................. 36
Fig. 12 Stopping the MVTS........................................................................................................... 36
Fig. 13 Stopping the MVTS graciously ......................................................................................... 36
Fig. 14 Terminating a call .............................................................................................................. 37
Fig. 15 Unregistering an endpoint ................................................................................................. 37
Fig. 16 Output of the ‘show call’ command .................................................................................. 37
Fig. 17 Output of the ‘show call’ command entered with the table formatting option ‘ta’ ........... 38
Fig. 18 Table-formated output of the ‘show call’ command entered with the ‘name’ option ....... 38
Fig. 19 Output of the ‘sh ca -dst’ command typed with the destination gateway IP address as an
argument ................................................................................................................................ 38
Fig. 20 Output of the ‘sh ca’ command typed with the call ID option .......................................... 39
Fig. 21 Output of the ‘show dial’ command .................................................................................. 42
Fig. 22 Output of the ‘sh stat rt’ command displaying route statistical data ................................. 42
Fig. 23 Show route statistics for the destination ATA................................................................... 43
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
Fig. 26 Output of the ‘sh ep’ command ......................................................................................... 45
Fig. 27 Output of the ‘show endpoint’ command with the endpoint number specified ................ 46
Fig. 28 Output of show converter command ................................................................................. 47
Fig. 29 Output of the ‘show disconnect’ command ....................................................................... 48
Fig. 30 Dialpeers overview provided by the ‘show dp’ command ................................................ 48
Fig. 31 Overview of gateways displayed by the ‘show gw’ command ......................................... 50

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

Reference Title of the document


[1] ITU-T Recommendation H.323 “Packet-based multimedia
communications systems”
[2] RFC 1889 “RTP: A Transport Protocol for Real-Time
Applications. Audio-Video”
[3] ITU-T Recommendation H.245 “Control protocol for
multimedia communication”
[4] ITU-T Recommendation H.225, “Call signaling protocols and
media stream packetization for packet based multimedia
communication systems”
[5] Remote Authentication Dial-In User Service (RADIUS), RFC
2138, April 1997 (http://www.pasteur.fr/cgi-
bin/mfs/01/21xx/2138?8#mfs)
[6] ITU-T Recommendation Q.931: “ISDN user-network interface
layer 3 specification for basic call control”
[7] RADIUS Accounting, RFC 2139, April 1997
(http://www.pasteur.fr/cgi-bin/mfs/01/21xx/2139)
[8] Jeffrey Friedl “Mastering Regular Expressions”, O’Reilly,
1997, ISBN: 5-318-00056-8
FreeBSD Handbook. The FreeBSD Documentation Project.
Copyright © 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002
by The FreeBSD Documentation Project
[9]
Red Hat Linux Manuals. Red Hat Linux 7.2. “x86 Installation
Guide”, “Getting Started Guide”, “Customization Guide”,
“Reference Guide”. Copyright © by Red Hat Inc.
ITU-T Recommendation T.38 “Procedures for real-time Group
[10]
3 facsimile communication over IP networks”, June 1998
Mozilla Public License, version 1.1.
[11]
http://www.mozilla.org/MPL/MPL-1.1.html
[12] “MVTS Configuration”
[13] “MVTS Management System”
[14] “MVTS Redundancy Schemes”
[15] “MVTS-based clusters”

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:

Table 1 Typographic conventions used in the document


Example Convention
Note: text Important information requiring special attention
[N] Numbers in square brackets represent a reference
to some other document
Void Words in Times New Roman expanded by 1.5pt
represent examples of source code, contents of
logs, configuration files etc.

White text against black background represents


[user@localhost]# cat
user.cfg
screenshots of the CLI and commands typed at the
MVTS console prompt
CallingStationId Arial Narrow 12 pt is utilized to highlight call
parameters and names of call session stages
Setup
Ulimit Boldface is used to highlight names of programs,
files and directories as well as the names of the
system configuration files
call_radix= Courier New, 11 pt is used to highlight the names
of the parameters of the system configuration files
and their sections.

10
1.4. DOCUMENT STRUCTURE

Here is a brief synopsis of the chapters and appendices in this document:

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

2.2. TECHNICAL DATA AND SPECIFICATION

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.

Run-time logs and journals


• System trace logs with selectable information detail level
• Billing and debug logs
• Call log extraction based on the call ID (log extractor script)
• Call log viewing by means of a Windows based GUI (MVTS manager)
• Automated log file management: (archiving, file size and file rotation control)

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

System traffic throughput capacity


• single-server versions with capacity ranging from 30 to 1500 concurrent calls
per server in E1 multiples
• two- and three-level cluster versions with capacity ranging from 4,500 to
40,000 simultaneous call sessions

2.3. SINGLE-SERVER MVTS


Below is a schematic view of a single-server MVTS with configured static gateways and RAS
users dynamically registering with it.

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.

2.4. MVTS-BASED CLUSTERS


Operation in a heavy traffic environment necessitates division of the major system functions
(signaling proxy, media proxy, gatekeeper, RADIUS, etc.) between the components of the MVTS
clustered facility [15].

2.4.1. CLUSTERIZATION IDEOLOGY


The roles of MVTS hosts in complex systems change. Media traffic proxying becomes the sole
function of the computer which in what follows we call Media MVTS (MMVTS). At the same time
all the gatekeeper, routing, billing and RADIUS procedures are now the job of the system referred to
in this document as the signaling MVTS (SMVTS). Since signaling, routing, billing and all associated
tasks are less demanding from the standpoint of computing power one SMVTS can handle several

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.

Fig. 2 Two-level MVTS system

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.

2.4.2. LOAD BALANCER


The main task of the Load Balancer (LB) is even distribution of signaling traffic among signaling
MVTSs. The LB periodically (in 5 sec time) inquires all of the controlled signaling MVTSs to assess
their current traffic load. Based on these data the LB sorts the signaling MERAs by their traffic and
the least busy one always becomes first in line for additional portion of traffic. The query mechanism
allows the use of several LBs at the same time.

2.4.3. SIGNALING MVTS


Operating a signaling MVTS (SMVTS) in a two-level cluster facility does not differ much from
operating a common MVTS session controller with one minor exception – the signaling MERA runs
as a signaling proxy only regardless of the settings that may affect this operating mode.

2.4.4. MEDIA MVTS


The media MVTS (MMVTS) is intended for full proxying calls only.
The functionality of the media MVTS has been reduced to indispensable austerity that would
allow a pass-through for signaling traffic and media proxying. The media MVTS is devoid of the
following capabilities:
- interoperation with a remote gatekeeper;
- gatekeeper functionality
- interaction with RADIUS servers

16
- call statistics
- definition of routing rules
MMVTS has only one task – media proxying.

2.5. SIP–HIT MODULE


As the MVTS operates under H.323, the client base of the carrier who has deployed MERA is limited
to the customers whose equipment supports the same protocol.
SIP-HIT (SIP-H.323 Interprotocol Translator) module serves a means to cope with this compatibility
challenge.
SIP-HIT is a complementary module for the MVTS Session Controller, intended to allow peering of
H.323 and SIP networks and ensure interoperability of VoIP equipment of different vendors. The SIP-
HIT module significantly increases operational flexibility of the MVTS.
SIP-HIT increases the provider’s operating versatility due to:
ƒ the ability to add SIP customers to the provider's H.323 domain
ƒ integration of carrier and customer VoIP nets with different codec
capabilities
ƒ enabling interworking of H.323 equipment from various manufacturers
ƒ NAT traversal
The SIP-HIT module has been specially designed to work with the MVTS session controller and can
not be employed as a stand-alone application for SIP-H.323 protocol conversion purposes.

Fig. 4 Two-way SIP-H.323 translation

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.

3.1.1. HARDWARE REQUIREMENTS


While deciding on hardware for the MVTS server, account must be taken of the intended use of the
application. Operating the MVTS as a gatekeeper or a signaling proxy only requires less computing
power while full proxy operation (signaling and media traffic) is more demanding in terms of
hardware specifications. The tables below provide guidance on assessing MVTS-related hardware
requirements.

Table 2 MVTS server hardware requirements (gatekeeper only)


Capacity Recommended hardware specifications
Low Pentium III 833/256Mb RAM/10Gb SCSI HDD
Medium Pentium III 1,4/1024Mb RAM/10Gb SCSI HDD
High Dual Pentium III 1,4/1024Mb RAM/20Gb SCSI
HDD

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.

Table 3 Capacity-dependent hardware requirements for signaling proxy operation


Capacity Recommended hardware specifications
30 concurrent calls Pentium III 833/256Mb RAM/10 Gb SCSI HDD
60 concurrent calls Pentium III 833/512Mb RAM/10 Gb SCSI HDD
120 concurrent calls Pentium III 933/512Mb RAM/10 Gb SCSI HDD
300 concurrent calls Pentium III 1.2/512Mb RAM/10 Gb SCSI HDD
600 concurrent calls Pentium IV 1.4/1024Mb RAM/20 Gb SCSI HDD
1000 concurrent calls Pentium IV 1.8/1024Mb RAM/20 Gb SCSI HDD

19
Refer to Table 4 for hardware profile estimates for the MVTS used to the utmost of its capability (in
full proxy operation).

Table 4 Capacity-dependent hardware requirements for full proxy operation


Capacity Recommended hardware specifications
30 concurrent calls Pentium III 800/256Mb RAM/10 Gb SCSI HDD
60 concurrent calls Pentium III 933/512Mb RAM/10 Gb SCSI HDD
120 concurrent calls Pentium III 1.15/512Mb RAM/20 Gb SCSI HDD
300 concurrent calls Pentium IV 1.8/1024Mb RAM/40 Gb SCSI HDD
600 concurrent calls Xeon Pentium IV 2.4/2048Mb RAM/40 Gb SCSI HDD
1000 concurrent calls Dual Xeon Pentium IV 2.0/2048Mb RAM/40 Gb SCSI
HDD

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

3.1.3. OPERATING SYSTEM


The MVTS version 3.1.x has been developed to run on the following Linux OSs:
• 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).

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.

3.2. PRE-INSTALLATION CONSIDERATIONS


Here is some information that we think is worth knowing prior to installing the MVTS application.

3.2.1. FILE SYSTEMS


MVTS operation requires existence of several file systems. Pursuant to the assumption that the MVTS
will be installed into the same file system with the OS, disk space requirements are as follows:
• 2Gb for the MVTS and the OS root directory (the billing/ and debug/
directories not included)
• enough space for the swap partition with due regard to the available size of
RAM and in accord with the recommendations of the installation guide for
your OS [7] (in any event reserve no less than 1Gb for the swap partition).
• When RADIUS accounting is not required and billing-related data will be
written to CDR files, it is advisable to create an individual 5Gb file system
with the billing/ directory used for the mounting point. This will help avoid an
overflow of the root file system where the MVTS application resides.
• Allocate about 10 Gb for an additional file system with the mounting point in
the debug/ directory, which will be used as a storage place for log files and
core- files of the system. The size of MVTS logs may be rather big; and the
availability of a separate file system protects the root file system against
repletion.

3.2.2. FILE DESCRIPTORS


The MVTS application is a prodigal spender of the server computing power and is especially
unsparing of file descriptors. As a matter of fact, the standard configuration of the OS kernel allows
but for a limited number of file descriptors.
Therefore, while planning to provide a large-scale service you may wish to change this parameter
with the help of the “ulimit” command making sure the parameter is set every time the OS is
initialized or building a customized kernel to make it possible for the operating system to support a
large number of simultaneously open file descriptors. Refer to section 7.3 of this document for details
about changing the number of available file descriptors.

3.2.3. MVTS USER GROUPS


There are several user groups organic to the MVTS operating environment, whose description you
can find in the Table below. The scope of rights and permissions an MVTS user has depends on what
group the user’s account belongs to.

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.

3.3. INSTALLING THE APPLICATION


The MVTS software is supplied in form of a gziped tarball archive with the filename ending with
tar.gz. The archive name is comprised of meaningful components denoting the version of the
application and the OS it is designed to run on.
For example, the archive with the filename MVTS-1.1-linux-x86-7.2.tar.gz contains the MVTS
application version 1.1 compiled to run on the operating system Red Hat Linux 7.2 (for the x86
family of CPUs).
The MVTS delivery bundle includes:
• The installation script (setup.sh) that optimizes the operational environment for
proper MVTS functioning, i.e. creates the necessary user groups, defines user
access rights, and adds the MVTS kernel to the list of the programs started
automatically at the boot time of the operating system.
• The MVTS kernel executable and the script, which restarts the kernel in case of
the program crash (mp_kernel.x and mp_kernel.sh respectively).
• The administration console executable and a script for starting the console
(mp_shell.x and mp_shell.sh).

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

To install the MVTS application, proceed as follows:


1. Log on to the system using the root account
2. Copy the tarball archive to a directory of your choice (in what follows we assume
that the archive has been copied to /usr/local)
3. Change path to the directory where the tarball archive is, for example:
[root@localhost]# cd /usr/local
4. Type and run the following command to unpack the archive file with the MVTS
software:
# tar xvzf MVTS-1.1-linux-x86-7.2.tar.gz
5. Change path to the directory ./mvts
# cd ./mvts
6. Run the setup.sh script by typing
]# ./setup.sh
and follow the instructions on the screen. If installation is successful the message
Setup finished successfully
will be displayed onscreen.

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.

3.4. POST-INSTALLATION TASKS (MAKING THE MVTS OPERATIONAL)


3.4.1. FIREWALL-RELATED ISSUES
When the MVTS is installed to run in a protected LAN environment, make the necessary firewall
arrangements to make it possible for the MVTS to send and receive calls.
The system uses standard ports for RAS traffic, incoming calls and RADIUS communication. The use
of the standard ports is ensured by setting the parameter port= to the appropriate default value in the
configuration files.
When dealing with firewall protection of your network, keep in mind that during media-traffic
proxying, the ports for voice transmission are allocated dynamically in the 1024 – 65535 range.
Therefore, for proper MVTS functioning open the following ports in the direction of your peering
partner gateways: UDP 1024-65535, TCP 1719, 1720, 1721, plus TCP ports 1024-65535 (in case no
H.245 tunneling is used in calls).

3.4.2. HASP DONGLES


Your license copy of the MVTS SC is protected by a HASP dongle; therefore to be able to start and
operate the MVTS you must install the necessary (Aladdin or Sentinel) drivers.
Aladdin drivers are supplied in form of a file with .rpm extension and are installed with the help of the
RPM installation utility, included into the MVTS delivery bundle.
To install Aladdin drivers change path to the directory, which contains the file a k s u s b d -
r e d h a t - * . * - * . i 3 8 6 . r p m , and type the following command at the command prompt:
> rpm -i aksusbd-redhat-*.*-*.i386.rpm
You can install the Sentinel UNIX Driver by running the install script or using PKG commands.
• If you choose to use the script to install the driver, perform the following steps:
1. Insert the installation CD in the appropriate drive of your computer.
2. Mount the CD device:
> mount -t cd9660 /dev/cdrom /mnt/cdrom
3. Now, run the installation script
> sh bsd_drvr_install.sh
4. You will be prompted to specify one of the following options: 1 (Only parallel
driver), or 2 (Only USB daemon), or 3 (Both parallel driver and USB daemon).
Type the corresponding digit for the component of your choice. We recommend
selecting both the parallel driver and the USB daemon.
5. Un-mount the CD
> umount /mnt/cdrom

• If you decide to use PKG commands


1. Type

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.

4.1. CONFIGURATION FILES OVERVIEW


The table below presents the description of the five configuration files used to configure the MVTS
application.

Table 6 MVTS configuration files


Name Description
File of global settings that determine the MVTS
meraproxy.cfg
features and operational behavior
Configuration file used to declare ‘static’ VoIP entities
gateway.cfg
(gateways) and describe their attributes.
Configuration file that serves to define the properties of
registering VoIP entities (i.e. endpoints that need
user.cfg
registration under the RAS protocol and hereinafter
referred to as RAS users)
File that provides a description of available call routes
dial peer.cfg (dial peers) and allows determination of their properties
and peculiarities. In other words it is a calling plan.
File used to describe and configure the MVTS
interaction with other gatekeepers (the MVTS
gatekeeper.cfg
gatekeeper functionality is configured in section
[Gatekeeper] of the meraproxy.cfg file)

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.

4.2. CONFIGURATION FILE STRUCTURE


The data structure common for all configuration files is as follows:
[section_name]
config_parameter1=value
config_parameter2=value
A section name is a word in square brackets that may comprise the following characters only:
• Upper and lower case Latin letters
• Digits ‘0’-‘9’
• The underscore character
• Dots
The opening bracket must be positioned at the start of the line. The space characters after the opening
bracket, before and after the closing bracket are ignored.
Here is an example of a correctly named section:
[ Section ]
The order in which individual parameters appear within a section is of no significance. Character ‘=’
is positioned between the parameter (field) name and its value. If a parameter value is a list, the list
components must be delimited by a semicolon ‘;’.
A long list that does not fit into one line may be continued on the next line with the parameter name
repeated in the beginning of the line.
Example:
[ata3]
address=183.132.44.76;183.132.44.78;183.132.44.71;
address=183.132.44.77
Parameter values and section names must not contain the following characters:
• Space, Tab
• Line Feed
Both section names and field names are case-sensitive, which actually means that [section] and
[Section] are different section names.
The ignored characters and character strings in configuration files include:
• spaces and tabs preceding and following the “=” character
• spaces following the opening bracket and preceding the closing bracket in

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.

5.1. ADMINISTRATION CONSOLE


The MVTS administration console is a command-line interface that ensures interaction of the operator
and the system.
When the operator enters a command the system performs user identification to verify if the user has
the permission to execute the entered command, and in this perspective the suite of MVTS console
commands accessible to the user is dependent of his group membership (see paragraph 3.2.3 about
MVTS user groups). Overview of membership-dependent accessibility of the console commands
follows:
ƒ Admin
A user belonging to this group has the right to carry out any command of the
administration console.

ƒ 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

5.1.1. STARTING AND EXITING THE ADMINISTRATION CONSOLE


Run the mp_shell.sh script to start the console. Once the command is entered, the administration
console tries to locate the MVTS.
The administration console sends output to a terminal screen that looks like this:

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.

5.1.2. ADMINISTRATION CONSOLE COMMANDS


The present version of the MVTS features three categories of the console commands:

• Reference commands: help, info


• Configuration and administration commands: reload config, reset statistics, start,
stop, stop gracious, terminate call, disable gatekeeper, unregister endpoint
• Diagnostic commands: info, show call, show dial, show disconnect, show dp,
show gw, show stat, show route, show stat route, show ep, show converter, show
incoming, sh ipload, show media, show stat file, show stat param, show
redundancy, show snmp, sh gk
The administration console will accept a new command only after the previous one has been carried
out.

5.1.2.1. Reference commands

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:

5.1.2.2. Configuration and administration commands

disable gatekeeper (di gk [all])


This command is a solution to the problem of abrupt termination of calls, which require gatekeeper
registration, caused by execution of the reload config command.
Disable gatekeeper registrations prior to carrying out reload config
An entry of the command at the console command prompt discontinues the use of the gatekeeper.
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

reload config [-d][-ras]


This command forces MVTS to read the configuration files anew.
Entering the command with the –d option displays configuration error messages onscreen.
The –ras option is used when it is necessary to initiate RAS socket rebinding.
Whith both options used together in a single command the –ras option must follow the –d argument.
If an error occurs during reading, new configuration, error information is output to the administration
console and the MVTS reverts to old configuration. The command is accessible to users of the group
Admin.
Example:

Fig. 8 Output of the ‘reload config’ command

reset statistics (re st)


Use the command to reset the current call statistics values.
Example:

Fig. 9 Output of the ‘re st’ command

reset stat all


Use the command to clear the entire statistics memory.

35
Example:

Fig. 10 Output of the ‘reset stat all’ command

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:

Fig. 11 Starting the MVTS kernel

stop
The command terminates all ongoing calls and shuts down the MVTS. This command is the exclusive
privilege of Admin group members.

Fig. 12 Stopping the MVTS

stop gracious (stop gra, stop gr)


This command makes the MVTS wait for the ongoing calls to complete while rejecting all new
calls and shut down when there are no live calls any more. The command is the privilege of the
Admin group users only.

Fig. 13 Stopping the MVTS graciously

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.

Fig. 14 Terminating a call

unregister endpoint [num] (unregister ep [num])


The command performs forceful unregistration of a RAS-user registered with the gatekeeper. The
command is accessible to users of the group Admin.
The ‘num’ option represents the number of the RAS gateway appearing in the first column of the
table displayed by the show ep сommand and is used to unregister the RAS entity indicated by the
specified number.
Example:

Fig. 15 Unregistering an endpoint

5.1.2.3. Diagnostic commands

show call [–dstname][–srcname][table][name](sh ca [ta][na])


The command displays either a list of all ongoing calls or a list of those that meet a certain criterion.
The command is accessible to users of the group Admin, Support and Billing.
Example:

Fig. 16 Output of the ‘show call’ command

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

Note: bracket the originator’s or the terminator’s name containing a space

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

show stat route (sh st rt) [all] [-dst] [-src] [-dp]


The command displays call statistical data characterizing route performance (a route is understood as
a triad comprised of an originating gateway, a dial peer and a terminating gateway.)
The displayed table is similar to the table output by the show stat src, show stat dst, and sh st dp
command except for the last column, which presents the current state of the route in terms of the
percentage of successful calls calculated for the latest 200.
When typed at the command prompt without options the command displays information for 250
routes only.
Example:

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:

Fig. 23 Show route statistics for the destination ATA

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

Changeover conditions for the status codes are:


FA → NA when ASR for the latest 200 calls is below 20%
NA → PA 30 minutes after the route state changed to NA
PA → NA when ASR for the latest 20 calls drops is under 20%
PA → FA when ASR for the latest 20 calls is above 20%
Notes:
1. The above route estimation parameters, i.e. 30 minutes, 200, 20 calls, and 20% are the
application constants. There are plans, though, to make these settings configurable in
future releases of the MVTS.
2. Currently, the mechanism of route state monitoring is implemented to register the instance
and the cause of a route state change in the runtime journal. Factually, “bad” routes are
not blocked by the system.

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.

show stat file (sh st file)


The command sh st file generates a full statistics file and outputs the name of the saved file to the
console screen.
Example:

Fig. 24 ‘Show stat file’ writes statistics to a file and displays the file name

show stat param (sh st pa)


The command show stat param displays the current settings of the statistics generation
mechanism including information about the number of gateways, dial peers and routes present in
the statistical data.
Example:

44
Fig. 25 Output of the ‘show stat param’ command

show endpoint (show ep) [number]


When entered without the argument ‘number’, this command displays a table of all endpoints
providing the following data:
- endpoint running number;
- endpoint alias;
- endpoint ID;
- user name;
Example:

Fig. 26 Output of the ‘sh ep’ 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

show converter (sh co)


The command s h o w c o n v e r t e r (s h c o ) allows you to display the parameters of the
SIP/H.323 converter module (see the screeshot in Fig. 28)

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

show disconnect (sh dc)


The command displays call disconnection data with brief description of reasons for call releases
in all routes. The command is used for debugging purposes.
Example:

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:

Fig. 30 Dialpeers overview provided by the ‘show dp’ command

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

show gw [name], [IPaddress]


The command displays configuration settings for all gateways available in the gateway data file
gateway.cfg or for one gateway only referred to by the specified name or IP.
Example:

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

show incoming <IP address> (sh in <IP address>)


Based on the provided IP address, this command outputs the name of a registering endpoint or a
static gateway (the name of a section in the gateway.cfg file with the parameters of the
originating gateway.) The permission to carry out the command belongs to users of the group
Admin and Support.
Example:

Fig. 33 Output of the ‘show incoming’ command

show ipload (sh ipload)


The command displays traffic load estimates for local IP addresses.
Example:

Fig. 34 Traffic load data for local IPs

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

Fig. 35 Output of show media command


The comman outputs operational statistics in form of a table followed by several lines of current
MMVTS configuration settings. The displayed table provides information about:
A d d r e s s – IPs of media MVTSs
A S R ( s t d ) – current ASR value (standard)
A C D – average call duration value
M a x L – registered traffic peak (max. load)
A c t –calls in progress currently
T o t a l – calls time total (hrs:min)
N o r m a l – number of successful calls
F a i l e d – number of failed calls
S t a t u s – current operating state of media MVTSs (FA – fully accessible/ASR=73%/ACD=46
seconds/current position of call radix pointer

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

show stat [full | src | ds t | gw | dp ]


The command provides the Administrator with the operation statistics for the MVTS server,
delivering the data with the accuracy of an individual gateway (both originating and terminating)
or a dial peer. The command also informs users of the type of failover/failback mechanism
currently employed. However, the primary MVTS host is unable to show the ‘Gatekeeper – RAS
user’ redundancy type.
The command is accessible to users of the groups Admin and Support.
Example:

Fig. 37 General server statistics


The statistical data output will vary with the entered command option:
show stat full - shows exhaustive statistics
Example:

53
Fig. 38 Output of the ‘show stat full’ command

show stat src|dst|gw|dp - displays statistics by object categories (originators,


terminators, gateways and dial peers)
Example:

Fig. 39 Call source statistics


or

Fig. 40 Call destination statistics


or

Fig. 41 Calls statistics for gateways

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.

Fig. 43 State of the redundancy scheme displayed by the show redundancy


command

Table 11 below gives an explanation of the command output.

Table 11 Parameters, displayed by the s h o w r e d u n d a n c y command


Parameter Description
Redundancy enable shows whether the system redundancy function is
engaged or disengaged
Redundancy state status of the host in the redundancy pair
undefined/initial state – initial state (when the type of
the version is being defined)
master: master is active, slave is inactive – status of

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

Fig. 44 Output of the ‘show snmp’ command

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

‘show ras request’


The output of the ‘show ras request’ command consists of three blocks of data:
1. IP addresses and identifiers of the gateways the description of which includes the
parameter lrq_allowed_only=1.
2. A list of current (as of the time of the data output) requests with ConfId (for ARQ) or
CallId (for LRQ), the time elapsed since the receipt of the request, identifier of the
gateway that is the request originator and the request storage timeout indicator.
3. RAS request statistics including that show:
- packet counter for LRQ requests received
- packet counter for LRQ requests processed
- packet counter for LRQ requests rejected due to the gateway’s inactivity
- packet counter for LRQ requests rejected owing to time expiry configured in
arq_alive_time=
An example of the command output is given below:

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.

Fri Sep 23 13:12:43 2005, HOST=212.92.148.13, SRC-NUMBER-IN=12345678901, DST-NUMBER-IN=789, SRC-


NUMBER-OUT=12345678901, DST-NUMBER-OUT=999999, SRC-NUMBER-BILL=12345678901, DST-NUMBER-
BILL=999999, SRC-IP=212.92.148.251:3317, DST-IP=212.92.148.251:1721, SRC-RTP-IP=212.92.148.251:16384, DST-
RTP-IP=212.92.148.251:16386, SRC-USER=12345678901, DST-USER=999999, SRC-NAME=ata, DST-NAME=a
ta2, DIALPEER-NAME=dp1, INITIAL-INCOMING-LOCAL-ADDRESS=212.92.148.13, SELECTED-INCOMING-LOCAL-
ADDRESS=212.92.148.13, OUTGOING-LOCAL-ADDRESS=212.92.148.13, RECORD-ID=1127465365-3, ELAPSED-
TIME=6, SETUP-TIME=13:12:25.000 +0400 Fri Sep 23 2005, CONNECT-TIME=13:12:36.000 +0400 Fri Sep 23 2005,
DISCONNECT-TIME=13:12:42.000 +0400 Fri Sep 23 2005, DISCONNECT-CODE-LOCAL=1, DISCONNECT-CO
DE-Q931=16, SRC-BYTES-IN=793, DST-BYTES-IN=668, SRC-BYTES-OUT=653, DST-BYTES-OUT=589, QOS=0, SRC-
CODEC=g711A64k g711U64k g7231, DST-CODEC=g711A64k , CALLID=6000100036b4c41c140c000ccee57293,
CONFID=600010003832a01a0802000ccee57293, PROXY-MODE=0, ROUTE-RETRIES=2, SCD-TIME=11, SOURCE-
FASTSTART=1, DESTINATION-FASTSTART=1, SOURCE-TUNNELLING=1, DESTINATION-TUNNELLING=1, PDD-
TIME=10,PDD-REASON=ALERT, REDIRECT-NUMBER=999999 (END), LAST-CHECKED-DIALPEER=to_ata

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.

Table 12 CDR fields


Field name Description
HOST The MVTS local address
SRC-NUMBER-IN Number of the calling party before translation
DST-NUMBER-IN Number of the called party before translation

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

5.3. MVTS LOGGING MECHANISM


An MVTS log is a file with a listing of all actions and events that have occurred on the server
during operation. The MVTS generates two types of runtime journals: trace logs and debug logs.

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.

5.3.1. MVTS TRACE LOGS


The MVTS trace logs contain diagnostic information for the system in form of messages created
by the MVTS during periods of malfunctioning. The trace logs are used for the purposes of
troubleshooting and system failure analysis.
The MVTS trace logs also include events informing about the ACD, ASR, SCD deterioration and
SCD increase. The same events are included in trap messages dispatched by the MVTS. The
event messages have the following format:
"Gateway <gateway name> ASR calculated for the latest <call_radix> calls dropped to the
critical point of <asr_min>%";
"Gateway <gateway name> ACD calculated for the latest <call_radix> calls dropped to the
critical point of <acd_min> seconds";
"Gateway <gateway name> SCD calculated for the latest <call_radix> calls dropped to the
critical point of <scd_min> seconds";
"Gateway <gateway name> SCD calculated for the latest <call_radix> calls grew to the critical
point of <scd_max> seconds"

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.

5.3.2. MVTS DEBUG LOGS


Debug logs are equally essential as they contain call progress data and are indispensable for
analytical and debugging purposes.
Debug logs are saved in the form of a plain ASCII text to files with the name format
logs_<date>_<time> in the logs/ directory for the convenience of the operator’s technical and
support personnel. All log files found in this directory may be disposed of by the Administrator at
his sole discretion.
The debug log provides the following data for every call handled:
• message receipt time
• the text of the message in ASN.1

5.3.3. DEBUG LOG PARAMETERS


A debug log is comprised of records that reflect changes in the call status. The configurable
parameters of MVTS logging are:
- information detail level of logs
- log file rotation period and
- debug log filename.

5.3.3.1. Information detail level


This parameter is determined by the system administrator in the field l e v e l = of the section
[Debug] in the file of global system settings meraproxy.cfg. The value of the parameter allows
setting a level of information in a log file. The greater is the value of the field, the higher is the
detail level of the information contained in the log files.
If the parameter is set to zero, log writing is disabled (default setting).
Log writing with the minimum level of information details is achieved by setting the l e v e l =
parameter to 1. In this case the record will only comprise the event time, type of message and the
IP address of the computer that sent the message or to which the message was sent.
With l e v e l = 1 , the format of a debug log record will look like this:

<time> <date> <Recv/Sent> <IP address> <protocol> <message type>


where:
<time> and <date> is the record time/date stamp
<Recv/Sent> - shows whether the message was received (Recv) or sent (Sent)
<IP address> - the address of the communicating host

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

5.3.3.2. Log file rotation period


The parameter p e r i o d = allows you to set a time period after which the system closes the
current and starts a new log file. The default value is 120 minutes.

5.3.3.3. Debug log filename formation


The parameter f i l e = allows the system administrator to manage filename formation for files
where the MVTS writes debug logs (‘log’ by default).
The three parameters of MVTS debug logs mentioned above are found only in section [Debug] of
the system configuration file meraproxy.cfg. They provide a means of global log writing
configuration.

5.3.3.4. Log writing particulars


Other sections of meraproxy.cfg and other configuration files may also contain fields that impact
the MVTS log writing. These fields control log writing pertaining to some MVTS functionality
rather than to the system in general.
Thus, the debug_level= field can be added to configuration parameters of the sections
[Gatekeeper] and [Radius] to enable packet logging of the respective MVTS functionalities (the
gatekeeper and Radius functionality) with the general logging being disabled in the section
[Debug] of meraproxy.cfg.
The valid values for this parameter are the same as those in the field level= in the section
[Debug] of meraproxy.cfg.
Other than in meraproxy.cfg the MVTS logging may also be configured in gateway.cfg (static
gateways) and user.cfg (registering endpoints or RAS users). Both these configuration files can
include the field debug_level= that allows setting the detail level of logged information,
provided the corresponding endpoint is engaged in call setup.
For example, with the system global setting for log writing 0, (the field level= in [Debug] of
meraproxy.cfg is set to 0), you can set the debug_level= parameter in the configuration record
of an individual gateway to the desired value (e.g. 3) thus enabling log writing with the highest
level of information only for those call sessions that involve the endpoint of interest.

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.

5.4.1. CONFIGURING AND USING THE WEB MONITOR


After the Web Monitor has been installed there is only one account admin with the password
admin. The admin account is an account with a full set of administrator permissions, which
imply the capability to view and clear statistics for all accessible gateways and dial peers, and
what is more important, to create, delete and modify user accounts.
To access the MVTS web interface type the address of your MVTS server (the one displayed
during installation) in the Address line of your web browser. Make sure that you mention the
right protocol name before the address:port group, i.e https.
For example:
https://222.33.222.33:1730
Once the communication link has been established you will see the logon dialog of the Web
Monitor as shown in the picture below:

Fig. 46 Logon dialog of the MVTS web interface

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

To create a new account, click the Create account button.


The appearing account dialog allows you to define user attributes and permissions. Fill the fields
of the dialog form with pertinent data and click the Apply button to save the newly created
account. A double click on any of the account records is another way to invoke the account
dialog and edit the account properties.

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

5.4.2. CUSTOMIZING INTERFACE LANGUAGE


The language of the Web interface is easily customizable to meet the operator’s needs. The
interface customization is achieved by editing the fields of the plain text file found in the
directory $MVTSAGENT_ROOT/www/lang/. While editing the text file make sure that the
characters you enter conform to the UNICODE/UTF-8 standard.
Structure of the interface language file:
LANGUAGE = English

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.

Fig. 52 New interface language (Spanish)

5.5. MVTS KERNEL


In rare cases when the system administrator needs to deal with the MVTS kernel, he can start the
administration console entering the necessary command arguments.
Another way to start the MVTS kernel is to run the mp_kerneld.sh script, which has certain
advantages. You will find more details about the start script in subsection 5.5.2.

5.5.1. COMMAND-LINE OPTIONS


The command start for the MVTS kernel must include one or several command-line options
whose detailed description is summarized in the table below.

Table 13 Command-line options of the MVTS kernel (mp_kerneld.x)


Options of the Description
command ‘start’
-h --help Displays a screenful of help and exits.
-v --version Displays information about the version
number and exits
-d --daemon Starts the kernel as a background process
(daemon)
-u --uid uid Starts as a process with user identifier
-g --gid gid Starts as a process with group identifier
-p --pid-file Specifies the pid-file name or file path.
-t --terminate Starts with process termination in the PID-
file

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

-l --log-file file output messages to file or directory


instead of syslog
-x --execute execute as a normal program
-i --ini-file set the ini file to use, may be
explicit file or
a ':' separated set of directories to
search.
-C --core-size set the maximum core file size

75
5.5.2. KERNEL STARTUP SCRIPT MP_KERNELD.SH

This method of starting the kernel has the following advantages:


• Core-files saving
• Writing to the debug log in case of a crash
• Automatic restart after a crash

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. DELETION/COMPRESSION OF OUTDATED SYSTEM FILES


Deletion or compression of outdated files (logfiles and/or CDR files) can be performed with the
aid of rotate.sh – a script, whose properties are configured by the MVTS user in the rotate.cfg
file.

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.

To view the necessary trace log proceed as follows:


1. Change your working directory to $H323PROXY_ROOT/debug/logs
#>cd $H323PROXY_ROOT/debug/logs
2. As information about the current system errors is in the latest mp_kerneld
log, sort the trace logs in the directory by the time of their creation.
#> ls –latr
The latest trace log will be positioned at the bottom of the displayed list.
3. To display the ending portion of the latest mp_kerneld trace log type

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.

7.2.1. REGISTERING ENDPOINT AUTHORIZATION


The MVTS sends the RADIUS server this type of authorization request on arrival of
RegistrationRequest received by the MVTS gatekeeper from the registering endpoint (RAS
user).

Table 15 AccessRequest structure in authorization request for a registering endpoint


IETF Attribute name VSA Description Data format Mandatory
attr. attr. /Optional
No. No. (M/O)
1 User name User name String M
Password encrypted
2 User passwd through MD5 or in the BYTE[16] or string O
plain form
CHAP-encrypted
3 User chap password BYTE[16] O
password
Time stamp used for
60 Chap challenge CHAP-encryption of BYTE[4] O
the password
4 NasIpAddress MVTS local address BYTE[4] M
5 NasPortType Local port type Always 0 M
6 ServiceType Service type Always 1 M
30 CallingStationId ANI number String O
31 CalledStationId DNIS number String O
MD5 password taken xpgk-md5-
26 MD5 password 1 from auth=<username/<timestamp O
RegistrationRequest >>/HEX[16]
Authorization request
26 AuthRequestType 1 xpgk-request-type=user M
type

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

Expected responses are AccessAccept and AccessReject

Table 16 Content of AccessAccept sent by RADIUS server when authorizing a


registering entity
IETF VSA Mandatory
attr. Attribute name attr. Description Data format /Optional
No. No. (M/O)
The endpoint phone
26 EndpointNumber 1 xpgk-ep-number=<number> O
number

On receipt of AccessReject the authorization is deemed rejected and the MVTS sends the RAS
user RegistrationReject with the cause SecurityDenial.

7.2.2. PRE-ROUTING CALL AUTHORIZATION


The MVTS sends the RADIUS server this type of authorization request before forwarding the
call to destination along the selected path.

Table 17 AccessRequest structure in pre-routing call authorization


IETF VSA Mandatory
attr. Attribute name attr. Description Data format /Optional
No. No. (M/O)
1 User name User name String M
2 User passwd Password encrypted BYTE[16] or string O
through MD5 or in the
plain form
3 User chap password CHAP-encrypted BYTE[16] O
password
60 Chap challenge Time stamp used for BYTE[4] O
CHAP-encryption of
the password
4 NasIpAddress MVTSlocal address BYTE[4] M
5 NasPortType Local port type Always 0 M
6 ServiceType Service type Always 1 M
30 CallingStationId ANI number String O
31 CalledStationId DNIS number String O

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>

Expected responses are AccessAccept and AccessReject

Table 18 Content of AccessAccept response from RADIUS server in pre-routing call


authorization
IETF VSA Mandatory
attr. Attribute name attr. Description Data format /Optional
No. No. (M/O)
h323-credit-time=<time,
26 CISCO_H323_CREDIT_TIME 102 Session max length O
sec>

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

7.2.3. ACCOUNTING REQUEST


7.2.3.1. Accounting Start record
The MVTS sends the RADIUS server the Accounting Start record upon arrival of a call
(incoming leg) or on sending SETUP to the destination gateway (outgoing leg).
Request type – AccountingRequest (Code 4)

Table 19 Structure of Accounting Start record forwarded to RADIUS server

IETF VSA Mandatory


attr. Attribute name attr. Description Data format /Optional
No. No. (M/O)
1 User name User name String M
4 NasIpAddress MVTS local address BYTE[4] M
5 NasPortType Local port type Always 0 M
6 ServiceType Service type Always 1 M
41 AcctDelayTime Always 0 M
40 AcctStatusType Accounting packet type Always 1 M
30 CallingStationId ANI number String O
31 CalledStationId DNIS number String O
Identificator for the
See format description
44 AcctSessionId ‘start/stop’ pair of the M
under the table
accounting-packets
The type of the leg the h323-call-origin=answer
26 CISCO_H323_CALL_ORIGIN 26 accounting packet pertains for the incoming leg, M
to
h323-call-origin=originate

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>

In the A c c t S e s s i o n I d field information is presented as follows:


<prefix>-<call number>-<hash><leg type><route number>

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.

Expected response is AccountingResponse.

7.2.3.2. Accounting Stop record


The MVTS sends the RADIUS server the Accounting Stop record on call termination.
The type of request is AccountingRequest (Code 4)
Note: The size of the Accounting Stop packet originated by the MVTS may be well in excess of
1,500 bytes, the limit size of UDP packets allowed by the IP stack. As not all network routers
and switches have the capability to correctly handle divided packets the accounting RADIUS
server in the absence of a valid Accounting Stop packet will continue billing even after the cease
of the call session.
The configuration parameter stop_acct_level= has been introduced as a solution to this
problem. It allows the operator to control the number of VSA fields included in Accounting Stop
records thus reducing the accounting packet size.
See a detailed description of the parameter stop_acct_level= in [12].

Table 20 Structure of the Accounting Stop record sent to RADIUS server


IETF VSA Mandatory
attr. Attribute name attr. Description Data format /Optional
No. No. (M/O)
1 User name User name String M
4 NasIpAddress MVTS local address BYTE[4] M
5 NasPortType Local port type Always 0 M
6 ServiceType Service type Always 1 M
41 AcctDelayTime Always 0 M
40 AcctStatusType Accounting packet type Always 1 M
30 CallingStationId ANI number String O
31 CalledStationId DNIS number String O
Identificator for the
See description of the field
44 AcctSessionId ‘start/stop’ pair of the M
format under the table
accounting-packets

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>

26 Converter name 1 Name of the converter the xpgk-converter-name O


call was terminated

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>

In the A c c t S e s s i o n I d field information is presented as follows:


<prefix>-<call number>-<hash><leg type><route number>

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

Expected response – AccountingResponse

7.2.4. RADIUS-AIDED ROUTING


When a dial peer record in the dialpeer.cfg file includes the g a t e w a y = E X T E R N A L setting,
the user authorization will be preceded with a routing request to the RADIUS server containing
the AV-PAIR field "xpgk-routing-request=1".
There can be three possible responses from the RADIUS server:
REJECT – receipt of this response terminates the call.
ACCEPT without routing information – invokes search of other possible routes
ACCEPT WITH ROUTING DATA – includes the following IDs:
− CISCO VSA ID=251 in the n e w _ u s e r n a m e / n e w _ p a s s w o r d notation
(this an optional field which functions like the o v e r r i d e _ u s e r
parameter in the dial peer.cfg file). For example, if the field value is
u s e r 0 1 / q w e r t y , then the current user name and user password in this
call will be substituted for u s e r 0 1 and q w e r t y respectively.
− CISCO VSA ID=252 structured as a five-, six- or seven fields long record:
gateway/proxy_mode/source/dest/src_bill/dst_bill/ip-address[:port],
where:
g a t e w a y is the name of gateway (section) in the gateway.cfg file;
p r o x y _ m o d e is the proxy mode:
0 – no media proxying
1 – media proxying enabled;
2 – use the proxy mode of the originating gateway;
3 - use the proxy mode of the terminating gateway;
s o u r c e is the calling number (src_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.

7.2.4.1. AccessRequest structure in RADIUS-aided routing


The MVTS sends the RADIUS server a routing AccessRequest when the g a t e w a y = field in the
dial peer record of the dial peer.cfg file is configured with the keyword EXTERNAL.
The MVTS’s request is aimed at getting a list of routing options for termination of the call at its
destination point. In addition the MVTS affords the possibility to change the username and
password for the call in question.
The MVTS can handle several route options sequentially attempting every next route after a
successful call termination through the previous one proves impossible.
The type of request is AccessRequest (Code 1)

Table 21 Structure of routing request sent to RADIUS server


IETF VSA Mandatory
attr. Attribute name attr. Description Data format /Optional
No. No. (M/O)
1 User name Username String M
Password encrypted using
2 User passwd BYTE[16] or string O
MD5, or in the plain form
CHAP-encrypted
3 User chap password BYTE[16] O
password
Time stamp used for
60 Chap challenge CHAP-encryption of the BYTE[4] O
password
4 NasIpAddress MVTS local address BYTE[4] M
5 NasPortType Local port type Always 0 M
6 ServiceType Service type Always 1 M
30 CallingStationId ANI number String O
31 CalledStationId DNIS нnumber String O
xpgk-md5-
MD5 password taken from
26 MD5 password 1 auth=<username/<timesta O
registrationRequest
mp>>/HEX[16]

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>

Expected response – AccessAccept

Table 22 Structure of AccessAccept response from RADIUS server


IETF VSA Mandatory
attr. Attribute name attr. Description Data format /Optional
No. No. (M/O)
Translation of the username
XPGK_XROUTING_USERNA and password for the current
26 251 <name>/<password> O
ME session (included in the packet
only once)
Set of routes for termination of
26 XPGK_XROUTING_ROUTING 252 See detailed O
the call (can be several ones, in
description of the field
that case they will be handled

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

* Field XPGK_XROUTING_ROUTING detailed.


gateway/proxy_mode/source/dest/src_bill/dst_bill/ip-address[:port]/converter,
where:
gateway – GW name (name of section) in the gateway.cfg file;
proxy_mode – mode of proxy operation:
0 – media proxying disabled
1 – media proxying enabled;
2 – use proxying mode of originating gateway
3 - use proxying mode of terminating gateway;
source – calling number (src_number)
dest – called party number that will be sent to the terminating gateway (dst_number)
src_bill – calling number for the billing system;
dst_bill – called number for the billing system;
ip-address[:port] – communication IP address (port number is optional, if port number is omitted
the default port 1720 will be used)
converter – name of the record for the converter through which the call is to be terminated

AccessReject – route authorization failed and the route is rejected with the appropriate LDC

7.2.5. DISCONNECTREQUEST ORIGINATING FROM RADIUS SERVER

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:

ƒ H.323 ID-based authentication (standard RADIUS authentication)


ƒ MD5 hash password authentication
ƒ Chap authentication
ƒ Digest authentication

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

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:

UserPassword = MD5Hash(Shared Secret, RemoteAuthenticator) XOR password,

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.

Fig. 53 Standard RADIUS authentication

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:

ChapPassword – the hashed password generated by the user;


ChapChallenge – the challenge;
UserName - the user’s name.

The figure below shows an example of the MVTS registration request.

Fig. 55 CHAP authentication

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

Digest authentication is used for authorization of SIP endpoints. A digest authentication


procedure includes the following steps:

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

Fig. 56 Digest authentication

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.

7.3.1. INCREASING THE NUMBER OF AVAILABLE FILE DESCRIPTORS


IN RED HAT LINUX

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

3. Use the following key sequence to save the changes:


ESC : x ! ENTER

To check the number of simultaneously open file descriptors use the


ulimit –n command.

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

2. Make sure the path to file /pam_limits.so is specified in the /etc/pam.d/login


file

- if the path to the file is specified there must be the


/lib/security/pam_limits.so record in the /etc/pam.d/login file
- specify the path to the /pam_limits.so file if it is missing (add
/lib/security/pam_limits.so to the /etc/pam.d/login file.

3. Save the changes made in the the /etc/pam.d/login file.

4. Open the /etc/security/limits.conf file

vi /etc/security/limits.conf

5. To the /etc/security/limits.conf file add the following entries:

<username> soft nofile 1024


<username> hard nofile 8192
where:
<username> is the user name, which you plan to employ when starting the MVTS.

104
6. Save the changes made in the /etc/security/limits.conf file

7. Open the /etc/profile file


vi /etc/profile

8. Add the following entry to the opened file:


if [ $USER = "username " ]; then
ulimit -n 8192
where:
“username” is the user name which you plan to employ when starting the MVTS.

9. Save the changes.

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:

1. Open the etc/profile file

vi etc/profile

2. Add “ulimit –n 8192” to the opened file

3. Save the changes

4. Open the etc/security limits.conf file

vi etc/security limits.conf

5. Add the following entry to the opened file:

* soft nofile 1024


* hard nofile 8192

6. Save the changes

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.

kern.maxfiles = (20+249*16)*2 = 8008

Note: The maximum allowed value of MAXUSERS in FreeBSD is 384


If you wish to set the system variable kern.maxfiles to the desired value add the necessary line to
the sysctl.conf file. In most cases this method serves the purpose perfectly. Though, operating
the server in an extremely heavy-traffic environment may require additional setting of the
NMBCLUSTERS kernel configuration option. For more information about tuning the
NMBCLUSTERS parameter refer to the FreeBSD handbook at
http://www.freebsd.org/doc/en_US.ISO8859-/books/handbook/configtuning-kernel-limits.html

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

7.4.1. THE DST_PATERN, SRC_PATTERN PREFIXES

Most commonly used structures include:

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

good examples: 77711, 777422


bad examples: 777 (prefix 777 is not followed by anything)
77811 (prefix is not 777)
77761 (the digit following prefix 777 is out of the 0…5 range)
7775 (the digit after prefix 777 is the last digit in the string, nothing follows it)

dst_pattern=......
or
dst_pattern=.{6}

Comment: any six characters (can include all valid symbols – e.g. #)

good examples: 123456, 976065, 123#56


bad examples: 1111111 (seven characters)
111 (three characters)
123456# (seven characters)

7.4.2. NUMBER TRANSLATION


The main purpose of number translation is transformation of a telephone number with the
end of bringing it to the necessary format. The most common number manipulation tasks are
removal, addition or replacement of various parts of a telephone number.
Regular expressions, employed in number translation, are comprised of alphanumeric
characters and metacharacters the description of which follows:

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

Number translation examples

1. Addition
Objective 1: add prefix 78 to number 12345:
dst_translate=12345/78&
result: 12345 → 78 12345

Objective 2: Add prefix 78312 to any six-digit number:


d s t _ p a t t e r n = …… or d s t _ p a t t e r n = .{6}
d s t _ t r a n s l a t e =.{6}/78312&

result:123456 → 78312 123456


result: 654321 → 78312 654321

Objective 3: add prefix 78312 to any number starting with 777:


d s t _ p a t t e r n = .*
d s t _ t r a n s l a t e = 777.*/78312&

result: 777123456 → 78312777123456


result: 777121212 → 78312777121212

109
Objective 4: concatenate the number adding 77

dst_pattern=.*
dst_translate=.*/&77

result: 1234 → 123477

2. Removal
Objective 1: strip any number of prefix 095 if present
dst_pattern=.*
dst_translate=095|.*/\2

result: 095123456# → 095 | 123456# → 123456#


Comment: in this case the expression 095|.*/ is the search pattern, therefore only numbers
starting with 095 will be subject to translation. “|” divides the search pattern in two logical
parts. The replacement string comprises only \2, which indicates that only the second part of
the search string will be used.

Objective 2: strip any number of prefix 8182 if present


d s t _ p a t t e r n = .*
dst_translate=8182|[0-9]*/\2

result: 8182123456 → 8182 | 123456 → 123456

Objective 3: remove # from the middle of the string

dst_translate=[0-9]*|#|[0-9]*/\1\3

result: 123#45 → 123 | # | 45 → 12345

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

Objective 1: replace prefix 8182 with 777

d s t _ p a t t e r n =.*
dst_translate=8182|[0-9]*/777\2

result: 8182123456 → 8182 | 123456 → 777 123456

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 2: replace prefix 1212 with 1718


d s t _ p a t t e r n = .*
bill_translate=1212|.*/1718\2

result: 121212345 → 1212 | 12345 → 1718 | 12345 → 171812345

Objective 3: replace the # character in the middle of the string with 555
dst_translate=[0-9]*|#|[0-9]*/\1 555\3

result: 123#45 → 123 | # | 45 → 123 | 555 | 45 →12355545


Note: make sure to insert a white space between \1 and 555. A failure to insert a space after
\1 will result in the expression \1555, which means ‘use the 1555th logical part from the
divided search string’.

Objective 4: replace the tailing symbol # with 123

dst_bill_translate=[0-9]*|#/\1 123

result: 123456# → 123456 | # → 123456123

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

7.5. MACRONAMES IN TRANSLATION PATTERNS

The number translation patterns used in the configuration files can include the following
macronames:

$ani$ - substitute the ANI number of the caller


$dnis$ - substitute DNIS data
$user$ - substitute user name

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.6. REMOVING THE MVTS FROM THE SYSTEM


In rare cases when you need to uninstall the MVTS and delete it from the system, run the
following sequence of commands:

#> rm -rf $H323PROXY_ROOT


#> vi /etc/profile #remove $H323PROXY_ROOT
#> runlevel
#> cd /etc/rc5.d
#> ls |grep mvts
#> rm -rf S50mvts
#> cd /etc/init.d
#> rm -rf mvts

7.7. DEFINITIONS
The table below contains the definitions used in the manual.

Table 23 Definitions, alphabetized


Billing system A system that provides accounting and billing information based on
the data supplied by MVTS, a gateway, or a gatekeeper.
Codec Voice encoding/decoding mechanism.
Dial peer Addressable call endpoint. In Voice over IP, there are two kinds of
dial peers: POTS and VoIP

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

Table 24 List of acronyms used in this manual


Acronym Expansion
ACD Average Call Duration (calculated as a ratio of aggregate duration of
all successful calls specified in the call_radix= field to the number of
successful calls)
ANI Automatic Number Identification
ASR Answer Seizure Ratio (calculated as a ratio of the aggregate number
of successful calls to the value of the call_radix= parameter multiplied
by 100). Calculated every three seconds.
CDR Call Detail Record
CHAP Challenge Handshake Authentication Protocol (a type of
authentication in which the authentication agent – typically a network
server – sends the client program a key to be used to encrypt the
username and password. This enables the username and password to
be transmitted in an encrypted form to protect them against disclosure.
CLI Command-Line Interface
CSV Comma-Separated Values
DNIS Dialed Number Identification Service
FTP File Transfer Protocol

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!

Table 25 List of quantifiers


Metacharacter Description

* Means 0 or more occurrences, i.e. match 0 or more times


For example, '12*' matches "1" and "122".
+ Means 1 or a greater number of occurrences of the
preceding expression, i.e. match 1 or more times what
precedes ‘+’
For example, "12+" corresponds to "12" and "122", but
not to "1".
? Means 0 or 1 occurrence of the preceding expressions, i.e.
match 1 or 0 times.
For example, '12(34)?' finds 12 in "12" or "1234"
{n} “n” is a non-negative integer. Meaning: match exactly n
times
For example, '1{2}' will not find 1 in "121", but will find
two instances of 1 in "2113".
{n,} “n” is a non-negative integer. Meaning: match at least n
times
For example, '1{2,}' will not find 1 in "212", but it will
find all 1s in "2111113".
'2{1,}' is equivalent to '2+'. '2{0,}' is equivalent to '2*'.
{n,m} “m” and “n” are non-negative integers, and n <= m.
Meaning: match n times but not more than m times.

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:

$test = "hello out there, how are you";


$test =~ m/h.*o/

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

Beginning and end of lines


Metacharacters ^ and $ are used to determine the beginning and end of line respectively. For
example, “^thing” matches a line beginning with “thing”? while “$thing” corresponds to a line
ending with “thing”.

Alternatives and parenthesizing

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/

saves "18" to $1, while

$test = "Today is monday the 18th.";


$test =~ m/[0-9]+th/

saves nothing due to absence of parentheses.

$test = "Today is monday the 18th.";


$test =~ m/(?:[0-9]+)th/

does not save anything either due to operator ‘?:’


The example which follows shows how this capability may be employed in replacement.

$test = "Today is monday the 18th.";


$test =~ s/ the ([0-9]+)th/, and the day is $1/
will save "Today is monday, and the day is 18." to variable $test.

You may refer to already found substrings using \1,\2,…, \9


The regular expression below will remove repeatitious words.
$test = "the house is is big";
$test =~ s/\b(\S+)\b(\s+\1\b)+/$1/
will save "the house is big" to $test.

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:

OID tables Description


Object 1.3.6.1.4.1.999.10.101.1 Data for call originators
identifiers
(OIDs) of 1.3.6.1.4.1.999.10.103.1 Dial peers data the
MVTS 1.3.6.1.4.1.999.10.105.1 Terminating endpoints data
static
1.3.6.1.4.1.999.10.107.1 Gateways data
variables
1.3.6.1.4.1.999.10.109.1 Call routes data

1.3.6.1.2.1.1.1.0 – system description (sysdescr)


1.3.6.1.2.1.1.2.0 –MVTS parameters (sysobjectid)
1.3.6.1.2.1.1.3.0 – system uptime (sysuptime)
1.3.6.1.2.1.1.4.0 – contact information (syscontact)
1.3.6.1.2.1.1.5.0 – system name (sysname)
1.3.6.1.2.1.1.6.0 – system location (syslocation)
1.3.6.1.2.1.1.7.0 – serice number (sysservices)
1.3.6.1.2.1.1.8.0 – the time of the most recent change in the MVTS operation elapsed since the
application start
1.3.6.1.4.1.999.10.1.0 – number of active calls
1.3.6.1.4.1.999.10.2.0 – active calls average (calculated for the last 5 minutes)
1.3.6.1.4.1.999.10.3.0 – traffic growth rate (in calls per second) calculated for the last minute
1.3.6.1.4.1.999.10.4.0 – traffic growth rate (in calls per second) calculated for the last 5 minutes
1.3.6.1.4.1.999.10.5.0 – maximum number of simultaneous calls
1.3.6.1.4.1.999.10.6.0 – system uptime (uninterrupted)
1.3.6.1.4.1.999.10.7.0 – statistics collection time
1.3.6.1.4.1.999.10.8.0 – total duration of calls
1.3.6.1.4.1.999.10.9.0 – number of accepted calls
1.3.6.1.4.1.999.10.10.0 – number of successful calls
1.3.6.1.4.1.999.10.11.0 – number of unsuccessfull calls
1.3.6.1.4.1.999.10.12.0 – number of rejected calls

Statistics for originators, dial peers, terminators and gateways

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.

Object Identifier Data type Description


1.3.6.1.4.1.999.10.X.1.1.Y Integer Object index
1.3.6.1.4.1.999.10.X.1.2.Y String Object name
1.3.6.1.4.1.999.10.X.1.3.Y String in the Total statistics collection time
“dd.MM.yy hh:mm:ss”
format
1.3.6.1.4.1.999.10.X.1.4.Y String in the Time of the latest statistics update
“dd.MM.yy hh:mm:ss“
format
1.3.6.1.4.1.999.10.X.1.5.Y Integer ASR
1.3.6.1.4.1.999.10.X.1.6.Y Integer Standard ASR
1.3.6.1.4.1.999.10.X.1.7.Y String in the ACD
“hh:mm:ss“ format
1.3.6.1.4.1.999.10.X.1.8.Y Integer Average QOS
1.3.6.1.4.1.999.10.X.1.9.Y Integer Peak number of simultaneous calls
1.3.6.1.4.1.999.10.X.1.10.Y Integer Number of active calls
1.3.6.1.4.1.999.10.X.1.11.Y String in the “hh:mm Total duration of calls
“format
1.3.6.1.4.1.999.10.X.1.12.Y Integer Number of calls received
1.3.6.1.4.1.999.10.X.1.13.Y Integer Number of normal calls
1.3.6.1.4.1.999.10.X.1.14.Y Integer Number of zero-duration normal
calls
1.3.6.1.4.1.999.10.X.1.15.Y Integer Number of failed calls
1.3.6.1.4.1.999.10.X.1.16.Y Integer Number of zero-duration failed
calls
1.3.6.1.4.1.999.10.X.1.17.Y Integer Kbytes received

120
1.3.6.1.4.1.999.10.X.1.18.Y Integer Kbytes sent

Call paths statistics


Legend:
Y – object index (>=1).

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.

Object Identifier Data type Description


1.3.6.1.4.1.999.10.109.1.1.Y Integer Route index
1.3.6.1.4.1.999.10.109.1.2.Y String in the “src->dp- Route name
>dst “ format

1.3.6.1.4.1.999.10.109.1.3.Y String in the “dd.MM.yy Total statistics collection


hh:mm:ss“ format time
1.3.6.1.4.1.999.10.109.1.4.Y String in the “dd.MM.yy Time of the latest statistics
hh:mm:ss“ format update
1.3.6.1.4.1.999.10.109.1.5.Y Integer ASR
1.3.6.1.4.1.999.10.109.1.6.Y Integer Standard ASR
1.3.6.1.4.1.999.10.109.1.7.Y String in the “hh:mm:ss“ ACD
format
1.3.6.1.4.1.999.10.109.1.8.Y Integer Average QOS
1.3.6.1.4.1.999.10.109.1.9.Y Integer Peak number of
simultaneous calls
1.3.6.1.4.1.999.10.109.1.10.Y Integer Number of active calls
1.3.6.1.4.1.999.10.109.1.11.Y String in the “hh:mm” Total duration of calls
format
1.3.6.1.4.1.999.10.109.1.12.Y Integer Number of calls received
1.3.6.1.4.1.999.10.109.1.13.Y Integer Number of normal calls
1.3.6.1.4.1.999.10.109.1.14.Y Integer Number of zero-duration
normal calls
1.3.6.1.4.1.999.10.109.1.15.Y Integer Number of failed calls
1.3.6.1.4.1.999.10.109.1.16.Y Integer Number of zero-duration
failed calls
1.3.6.1.4.1.999.10.109.1.17.Y Integer Kbytes received
1.3.6.1.4.1.999.10.109.1.18.Y Integer Kbytes sent

121
1.3.6.1.4.1.999.10.109.1.19.Y String Route status. Possible
values: "NotAccessible",
"PartlyAccessible",
"FullyAccessible"

1.3.6.1.4.1.999.10.109.1.20.Y Integer Number of successful calls


for this route

Call disconnect codes statistics

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.

Object Identifier Data type Description


(OID)
1.3.6.1.4.1.999.10.X.1.Z.Y String Character string in the
following format:
«LDC,Q931,count»,
where LDC is the local
disconnect code, Q931 –
disconnect code according to
the Q931 standard, count –
the number of calls,
completed with this pair of
codes (LDC-Q931)

122
123
Appendix C MVTS LOCAL DISCONNECT CODES

Table 26 MVTS-generated disconnect codes


Code Name Description
1 eCallerNormal The call terminated normally with a
“Release complete” message from the call
originator
2 eCallerNormal The call terminated normally with a
“Release complete” message from the call
terminator
3 eCallerDropTCP Abnormal call termination (no “Release
complete” received) due to TCP link
severed by the call originator
4 eCallerDropTCP Abnormal call termination (no “Release
complete” received) due to TCP link
severed by the call terminator
10 eRemoteGkDRQ Call failed because the
disangageRequest was received from a
remote gatekeeper
100 eForceTerminateCall Forceful call termination (caused by
shuttingdown the MVTS or the
terminate call command)
101 eTimeoutTCPConnectH225 Failure to initiate an H.225 session with
the call terminator within 3 seconds time
102 eTimeoutConnectMsg Failure to receive the Connect Message
within 120 seconds
103 eTimeoutRBT Failure to receive the Alerting message
within 30 seconds time
104 eInvalidH225SizeCaller Invalid size of H.225-packet received
from the call orirginator
105 eInvalidH225SizeCalled Invalid size of H.225-packet received
from the call terminator
106 eInvalidH225MsgCaller Incorrect H.225-packet received from
the call originator
107 eInvalidH225MsgCalled Incorrect H.225-packet received from
the call terminator
108 eInvalidH225ReadCaller The MVTS could not read out the
H.225-packet received from the call
originator

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.

124 eInvalidSetupMsg Wrong Setup Message (lack of the


UserUserField in the packet or Setup

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:

• CISCO (IOS-based, ATA 186)


• VocalTec (VGW 1.4f+, VGK 1.3+)
• Samsung (SMG 400, SMG 3200)
• Nortel Networks (BCM v. 4.0, Succession)
• Clarent (Clarent GK)
• D-Link (DG-10xSH DG-104SH, DVG-1120, DVG-1402S, DVG-1024, DVG-
1104TH, DVG-2004S, DVG-4022, DVG-5030S)
• BosCom (Bosanova)
• Well-Tech (SmartNode 1200, 1400, 2300, 2400)
• AudioCodes (Mediant-2000, MP-104)
• Quintum (Tenor Digital MaltiPath Switch)
• Network Systems Group (NSGate)
• Sysmaster (SM7000 VoIP Gateway)
• Broadsoft (BroadWorks platform)
• IP and Softphones (Microsoft NetMeeting, VocalTec Phone Lite)

BILLING AND ACCOUNTING SYSTEMS


The MVTS being supportive of the RADIUS protocol allows providers to choose a billing system
to their liking. The list of the billing applications that according to the reports of our customers
proved reliable in use with the MVTS:
• PortaBilling
• EyeBill VoIP Billing
• IPSoft Billing
• T-Soft Billing
• CBOSS Billing
• MIND CTI
• Advanced VoIP Billing System
• ISA Billing
• Switch Management Billing
• Cyneric Billing

129

Potrebbero piacerti anche