TABLE OF CONTENTS

About this document

This document details the procedure to install and operate MERA VoIP Transit Softswitch. It is a quick
reference aimed to assist administrators in configuring and running the application. This document is not
meant to be an exhaustive description of the system capabilities, which is available in the System
Administrator Guide.

Overview
MERA VoIP Transit Softswitch (MVTS, for brevity) is a VoIP softswitch with gatekeeper and proxy
functionality. MVTS is a high performance utility employed in IP telephony networks for routing voice
traffic to gateways.
Deployment of MVTS gives IP-telephony providers the the following benefits:
Facilitation of the network administration and network enhancement tasks (newly
added gateways need to be registered with MVTS only).
New flexible traffic concentration and routing capabilities
(including dynamic routing, load balancing between the gateways of a single
destination).
Solution to the multivendor interoperability problem (for example, Cisco and
VocalTec).
One-point authorization and accounting based on the RADIUS standard.
Concealment of internal network structure.
Capacity to set up and administrate corporate customer VPNs with individual dialing
plans.
A highly-efficient, reliable and readily controllable system.

Hardware requirements
The hardware platform meant to host MVTS must be selected with due regard to the system performance
(30, 60 or 120 concurrent calls) and the functions the system is supposed to carry out (gateway-only
functions, signaling proxy or signaling and media proxy functionality).
The tables below illustrate the minimum hardware specifications for the system with regard to intended
use of the product.
Table 1. Performance-dependent system requirements (gatekeeper only)
Performance

Recommended hardware specifications

Low
Medium
High

Pentium III 833/256Mb RAM/10Gb SCSI HDD

Pentium III 1,4/1024Mb RAM/10Gb SCSI HDD
Dual Pentium III 1,4/1024Mb RAM/20Gb SCSI HDD

Table 2. Recommended hardware configuration (without media proxy)

Performance

Hardware specifications

30 calls
60 calls
120 calls
300 calls
600 calls
1000 calls

Pentium III 833/256Mb RAM/10 Gb SCSI HDD

Pentium III 833/512Mb RAM/10 Gb SCSI HDD
Pentium III 933/512Mb RAM/10 Gb SCSI HDD
Pentium III 933/512Mb RAM/10 Gb SCSI HDD
Pentium III 1,13/1024Mb RAM/20 Gb SCSI HDD
Pentium III 1,13/1024Mb RAM/20 Gb SCSI HDD

Table 3. Recommended hardware configuration (full proxy mode)

Performance

Hardware specifications

30 calls
60 calls
120 calls
300 calls
600 calls

Pentium III 800/256Mb RAM/10 Gb SCSI HDD

Pentium III 933/512Mb RAM/10 Gb SCSI HDD
Pentium III 1/512Mb RAM/10 Gb SCSI HDD
Pentium III 1,4/1024Mb RAM/10 Gb SCSI HDD
Dual Pentium III 1,13/2048Mb RAM/20 Gb SCSI
HDD
Dual Pentium III 1,4/2048Mb RAM/20 Gb SCSI
HDD

1000 calls

Note: Use of a 1Gbit Ethernet card is a prerequisite for the performance involving 300
simultaneous calls with full media proxy.
While choosing the optimum hardware configuration, one important point to remember is that the system
performance depends on the capability of the local area network. The significance of this factor increases
if media traffic proxy mode is used.
When MVTS is connected to a local Ethernet net, the 100Mb data transfer rate is the minimal networking
requirement. Besides, use of full-duplex equipment is recommended.
The best possible performance of MVTS running in the full traffic proxy (G.729) mode in a 100Mb fullduplex network is about 1100 concurrent calls. Such performance requires installation and configuration

of at least two network interfaces for transmission and receipt of H.323 signaling and voice traffic and an
additional RADIUS interface.
If a still better performance is required for media proxy, you may want to consider employment of more
capable network interfaces (Gigabit Ethernet for example).
Operating system requirements
The operating system for VoIP software should satisfy the following requirements:

Capability to seamlessly integrate in TCP/IP networks, support of TCP/IP and capacity to

enhance this functionality (well-developed system of IP filters, dependable TCP/IP stack)

Security system to protect networked servers with open Internet access (built-in Firewall or
NAT applications)

Remote administration functionality

Customization and enhancement capabilities

Hardware independence

While the popular MS Windows lacks the said features to a large extent, they are successfully
implemented in UNIX-like operating systems.
Registered MVTS employment cases indicate smooth operation under the following Linux clones: Red
Hat, FreeBSD, Slackware, Mandrake, SuSe, Sun OS (low-capacity configuration).
MVTS has been thoroughly proof-tested under Linux Red Hat 6.1-7.3 and FreeBSD 4.7 (and later) to
guarantee fault-free functioning under the above operating systems.
Creating a file system for MVTS
A proper organization of the file system contributes much to the smooth and uneventful operation of
MVTS.
Pursuant to the planned employment of MVTS, the administrator is encouraged to allocate enough disk
space for creation of several file systems:1

2Gb at the least for the root directory of MVTS and the OS.

Enough space for swapping with regard to the available size of RAM and in accordance with
the installation guide recommendations for your OS. (In any event, no less than 1Gb must be
reserved for swapping.)

When RADIUS accounting is not employed and the billing statistics is be written to CDR
files, it is advisable to create an individual 5Gb file system with the billing/ directory used for
the mounting point. Such approach will help avoid overflow of the root file system where the
MVTS application resides.

It is recommended to provide 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 the system runtime
journals (runtime logs) and core files. When MVTS runs in the test mode, the size of the

It is assumed that the MVTS software and the OS are installed in one and the same file system with the OS,
i.e. the root file system.

system logs may be rather big, in which case the availability of a separate file system will
protect the root file system against repletion.
OS kernel tuning
Important! If you are installing a demo version of the product or its performance is below 60
concurrent calls, no kernel tuning is required and the information below is irrelevant.
MVTS consumes considerable system resources and is especially unsparing of file descriptors. Each open
file, socket or FIFO requires one descriptor at least. At the same time, the standard configuration of the OS
kernel allows for a limited number of file descriptors (normally, 1024). Therefore, an operator planning for
a large-scale service may want to change this parameter and retune the kernel to enable support of a large
number of simultaneously open file descriptors.
In estimating the necessary number of simultaneously open file descriptors, it is reasonable to assume that
six to twenty sockets (file descriptors) is required to proxy a single call. With a certain allowance for the
needs of the operating system itself, it may be safe to presume that 20 simultaneously open file descriptors
per call should fully meet the demands of the system.
Detailed information about kernel customization is readily available in the pertinent OS documentation.
Therefore we refrain from giving a complete set of instructions herein and will describe the parameters to
be modified prior to compiling a new kernel.
To change the number of simultaneously opened file descriptors, proceed as follows:
The Red Hat Linux
1. Prepare the system for kernel retuning as per the OS documentation.
(http://www.redhat.com/docs/manuals/linux/RHL-7.3-Manual/custom-guide/ch-customkernel.html)
2. Make a backup copy of the system (a boot disk) if it does not exist.
3. Replace the original parameters in the source code with the new ones:
a. Find header files limits.h and fs.h in directory / u s r / i n c l u d e / l i n u x
and change the value of the N R _ O P E N parameter in limits.h and the value
of the I N R _ O P E N parameter in fs.h for 8 1 9 2 .
b. In file p o s i x _ t y p e s . h change the _ F D _ S E T S I Z E parameter to
read 8192.
4. Recompile the kernel with the new parameters.
5. Make sure that the new kernel is loaded at bootup.

The FreeBSD
Unlike in Red Hat, the number of descriptors for simultaneously open files ($maxfiles)
cannot be explicitly set in the FreeBSD operating system, since it is dependent on the value
of the $maxusers parameter. (See http://www.freebsd.org/doc/en_US.ISO88591/books/handbook/configtuning-kernel-limits.html). The number-of-clients dependence
of simultaneously open file descriptors is expressed by the following equation:
$maxfiles=(20+$maxusers*16)*2
It means that enabling FreeBSD OS to open 8000 file descriptors and above (calculated as
approximately 20 sockets per call) will require retuning the kernel to set maxusers to no
less than 249, i.e.
$maxfiles = (20+249*16)*2 = 8008
Note: The maximum allowed value of $maxusers in FreeBSD is 384

1. Follow the kernel tuning instructions per the OS documentation (See

http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/kernelconfigbuilding.html).
2. To configure the OS kernel for a large-scale service requiring a big quantity of
simultaneously open file descriptors, change the value of the maxusers parameter in file
/usr/src/sys/i386/conf/GENERIC accordingly and rebuild the kernel.
3. Make sure that the new kernel is loaded at bootup.
Installing MVTS
To install the MVTS application, follow the instructions below:
1. Log on to the system using the root account.
2. Copy archive (the .tgz file - mvts-2.1.5-Linux-eng.tgz or mvts-2.1.5-Linux-rus.tgz) to /
usr/local or any other folder.
3. Type and run the following command to unpack the archive file containing the MVTS
application:
tar xvzf <filepath_to_archive>/<file_name>
If you are working from the archive directory, the filepath to archive can be omitted.
Example:
cd/usr/local
tar xzvf mvts-2.1.5-Linux-eng.tgz
4. Change path to the directory ./MVTS.

5. Type the sh setup.sh command to run the setup.sh script.

You will be prompted to enter IDs for the admin, support and billing groups. You may use arbitrary chains
of characters or the numbers assigned to other groups elsewhere. (The list of groups and their assigned IDs
is contained in the /etc/group file).
If installation is successful,
Setup finished successfully

will be displayed onscreen.

Deinstallation
To uninstall MVTS and delete it from the system, run the following 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

Configuring MVTS
The system is configured through the five ASCII text files stored in folder $H323PROXY_ROOT/cfg/.
The file can be edited with the help of any text editor.2 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 will take effect only after restart of the application or after running the r e l o a d
c o n f i g command typed at the command prompt of the administration console.
Data required for MVTS operation is stored in the five configuration files below.
Table 4. The MVTS configuration files
Filename
meraproxy.cfg
gateway.cfg
dialpeer.cfg

Description
System configuration file containing the
settings for administration, runtime logging,
administration console and billing
Configuration file containing the information
about the gateways and their settings
Dial peer data file, i.e. calling plan
containing the dial peer IDs, called/calling
number data, internal names of gateways,
and number translation patterns

It is good practice to make a copy of the system configuration file and edit the copy rather than the original
file. Copy the edited file back into the original configuration file when done with editing.

gatekeeper.cfg
user.cfg

Gatekeeper data file storing information

about the gatekeepers, with which MVTS
registers as a client
The RAS user data file

After installation, the system configuration file (merarpoxy.cfg) will contain the default settings, while
the gateway data and dial peer files provide the appropriate templates only. Prior to starting your MVTS
for the first time, follow the steps below:
1. Fill in the data fields in the system configuration file (meraproxy.cfg).
2. Add gateway records to the gateway data file (gateway.cfg).
3. Configure the dial plan (dialpeer.cfg).
4. If necessary, enter the appropriate parameters in the RAS user and gatekeeper data
files (user.cfg, gatekeeper.cfg).
The meraproxy.cfg file consists of the following sections for general configuration settings:
[Administration] contains fields for configuration file names (which can be modified
if necessary), email address for system error alerts, address used by MVTS for call
setup, and gateway authorization by IP address.
[Console] sets user group rights for Admin, Support and Billing groups, and the
administration console port.
[H323] is the section for H.323-related settings.
[Billing] contains the billing system settings: name and path for the file to which

billing statistics shall be written, attributes for temporary and final statistics files, file
write period, CDR format and the record detail level.

[Debug] contains the runtime journal settings: the name and path for the file to which

the runtime journal is written, temporary and final files attributes, log file write period
etc.

[Radius] section is for settings related to RADIUS server functionality

(authentication, accounting etc.)
[Gatekeeper] contains gatekeeper functionality settings.
[LAR] is for look-ahead routing configuration.
[proxy] sets up proxy parameters.

The gateway.cfg is for gateways whose IP addresses or DNS names are known.
The user.cfg file stores parameters for dynamically registered users or RAS users, whose IP addresses or
DNS names are unknown to the system.
The dialpeer.cfg file contains dial peer data, that is, possible traffic paths, collectively called dial plan.
The gatekeeper.cfg file stores information about the gatekeepers at which MVTS registers as a RAS user.
Below are some of the most typical scenarios for connecting gateways to MVTS, with configuration
details for each case.

Scenario 1: 2 gateways

Gateway
(Cisco 5300)

Gateway
(Samsung)

This is the simplest scenario. Gateways whose IP addresses are known (static users) are described in
the gateway.cfg file. For example, records for the Cisco 5300 and Samsung gateways would look as
follows:
<gateway.cfg>
[isco_5300]
address=xx.xx.xx.xx
gateway_mode=3
port=1720
capacity=30
ip_precedence=5
proxy_type=1
validation_gap=1000
validation_msg=1,3,7
[Samsung]
address=xx.xx.xx.xx
port=1720
gateway_type=3
auth_enable=0
force_call_proceeding=3000
ip_precedence=5
Below is a simple example of the dialpeer.cfg file to enable calls between Moscow and New York:
<dialpeer.cfg>
[DP_Moscow_to_NYC]
dst_pattern=1212[0-9]*
gateway=Cisco_5300
[DP_NYC_to_Moscow]
dst_pattern=7095[0-9]*
gateway=Samsung

If MVTS dial plan includes several call termination routes, validation_gap and validation_message
parameters shall be used to handle the multivendor interoperability issue. As gateway response time is
vendor-specific, MVTS needs a fixed delay period and message code, the receipt of which makes possible
further interworking with a particular gateway. The above example will have the following settings for the
Cisco_5300:
, dial plane , MVTS
,
validation_gap validation_message, , ,
Call Proceedisng .
(, ,
).
Cisco_5300:
validation_gap=1000
validation_msg=1,3,7
Briefly, if the call originator is the Cisco_5300, it will receive signaling packages only upon receipt of the
Alerting(1), Progress(3), and Connect(7) messages or one second after the Setup packet is sent to the
terminating gateway.

Scenario 2: 4 gateways +
This is a more complicated deployment case involving four gateways and more complex routing rules. Let
us consider for instance a system of four gateways (two in New York, one in Moscow and one in
Argentine). In this example, the Argentine gateway is not expected to accept calls from Moscow.

Gateway

Gateway

(Arg)

(NYC1)

Gateway

Gateway

(Moscow)

(NYC2)

< gateway.cfg>
[NYC1]

address=xx.xx.xx.xx
group=NY
gateway_mode=3
port=1720
proxy_type=1
[NYC2]
address=xx.xx.xx.xx
group=NY
gateway_mode=3
port=1720
proxy_type=1
[Moscow]
address=xx.xx.xx.xx
gateway_mode=3
port=1720
proxy_type=1
[Arg]
address=xx.xx.xx.xx
gateway_mode=3
port=1720
proxy_type=1
<dialpeer.cfg>
[NYC]
dst_pattern=1212[0-9]*
gateway=NYC1; NYC2
hunt_mode=2
[Moscow]
dst_pattern=7095[0-9]*
gateway=Moscow
[NYC_to_Arg]
dst_pattern=54[0-9]*
group_allow=NY
gateway=Arg

The g r o u p field is a useful parameter for easier gateway configuration. It enables grouping numerous
originating gateways under a single name and thus saves the effort of inputting each individual gateway in
the s r c _ p a t e r n field. The g r o u p _ a l l o w parameter indicates the gateways allowed by a
specified dial plan.

Scenario 3: Gateway and ATA 186:

186

Gateway

To enable the use of ATA 186 both as call originator and call terminator, you will need to configure
it accordingly. Enter the required telephone numbers in the UID0 and UID1 fields. For successful
registration with MVTS, set 1 in the UseLoginID field and fill in the LoginID1 and LoginID2 fields with
the respective user|password parameters from the user.cfg file. If MVTS interworks with a gateway sitting
behind a NAT barrier, set the nat_rtp flag (nat_rtp=1) in the description of the pertinent gateway.

Scenario 3b: ATA 186 behind a NAT router

Below is a configuration example of the following deployment case: two users connected to ATA
186, which is configured to call and terminate calls from the gateway with the 416 prefix.

186

NAT

<user.cfg>
[ATA_user1]
user=first_user
password=pass1
number=70954444333
group=ATA_users
proxy_type=1
nat_rtp=1
[ATA_user2]
user=second_user

Gateway

password=pass2
number=70954444555
group=ATA_users
proxy_type=1
nat_rtp=1
< gateway.cfg>
[Static_GW1]
address=xx.xx.xx.xx
gateway_mode=3
port=1720
proxy_type=1
<dialpeer.cfg>
[DP_ATA_ENDPOINTS]
dst_pattern=70954444[0-9]{3}
gateway=ENDPOINTS
[DP_ATA_to_GW1]
dst_pattern=416[0-9]*
group_allow=ATA_users
gateway=Static_GW1

4: RADIUS server
186

186

Gateway

RADIUS server

For authorization of all dynamically registered users through the RADIUS server, set the auth_enable flag
(auth_enable=1) in the meraproxy.cfg file (Radius section). To enable accounting through the RADIUS
server, set the acct_enable flag (acct_enable=1) in the same section.
<meraproxy.cfg>
[Radius]
local_address=*
auth_enable=1
acct_enable=1
acct_type=1
acct_leg_type=2
auth_password_type=1
secret=strongsecret
auth_address=xx.xx.xx.xx
auth_port=1812
acct_address= xx.xx.xx.xx
acct_port=1813
dst_user_orig_leg=1
local_auth_port=1644
local_acct_port=1645

To disable RADIUS authorization for certain gateways, reset the auth_enable flag (auth_enable=0) for
relevant gateways in the gateway.cfg or user.cfg files.
< gateway.cfg>
[gate1]
address=xx.xx.xx.xx
gateway_mode=3
port=1720
proxy_type=0
auth_enable=0

To enable registration of any dynamic user with MVTS, enter the following settings in the user.cfg file:
<user.cfg>

[default]
user=default

The default section settings will apply to any dynamic gateway that is not specified in the user.cfg file.
Important! If the auth_enable flag is disabled (auth_enable=0), any RAS user can access the MVTS
server with no authorization required, even if the public assess parameter is off (public_access=0) in the
Administration section of the meraproxy.cfg file).

Scenario 5: NetMeeting

186

Soft-phone

MVTS is proved compatible with MS NetMeeting. To configure NetMeeting for interworking with the
MVTS server, follow the instructions below:
1) Set flag Use a gatekeeper to place calls in the Tools>Options>Advanced Calling menu.
2) Set flag Log on using my account name (Tools>Options>Advanced Calling).
3) In the Account name field enter user_name|password of the users described in the user.cfg file.
For calls from ATA 186 to NetMeeting, disable the Fax T.38 support by entering datacap_deny=4096I in
the user.cfg file for the user to be connected through NetMeeting.
<user.cfg>
[NetMeeting_user]
user=nmuser
password=nm
number=78312444333
datacap_deny=4096

Scenario 6a: MVTS and two gatekeepers

GW1 -- GK1 -> MVTS -> GK2 -- GW2
In the above model, GK1 is registered with MVTS, whereas MVTS is registered with GK2:
<gatekeeper.cfg>
[GK2]

= xx.xx.xx.xx
= 1719

= 1
=second_testuser
=
security=2
=0
=30

<user.cfg>
[GK1]
user=testuser
password=kk98fcc5
<gateway.cfg>
[GW1]
address=aa.aa.aa.aa
[GWterm_for_GK2]
gatekeeper=GK2
proxy_type=1
capacity=60

[GWorig_for_GK2]
address=xx.xx.xx.xx

<dialpeer.cfg>
[DP_GK1toGK2]
#destination - SAN FRANCISCO
dst_pattern=415[0-9]{7}
gateway= G W t e r m _ f o r _ G K 2
[DP_GK2toGK1]
#destination - NYC
dst_pattern=212[0-9]{7}
gateway= G W 1

Configuring dial peers (dialpeer.cfg)

Dial peers enable flexible routing based on various preset criteria.

The dst_pattern field is for the destination number mask used to define the numbers for a specific dial
peer. For example:
dst_pattern=.*

// any digits, # and *

dst_pattern=[0-9]*

// any digits

dst_pattern=[0-9]{7}
dst_pattern=...[1-4;7]..

// any 7 digits
// any 3 symblols, followed by any digit in the range of 1 through 4 or by 7,
followed by any 2 digits

The same is applicable to the src_pattern field (the source number).

Fields dst_translate, src_translate, bill_translate, src_bill_translate and dst_bill_translate enable
translation of called and calling numbers and the numbers used for accounting purposes.
dst_translate=12345/78&

// adds the 78 prefix

dst_translate=095|.*/\2

// deletes the 095 prefix

src_translate=[0-9]*|#|[0-9]*/\1\3 // deletes # from the middle part of the number

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

// deletes # from the end part of the number

bill_translate=1212|.*/1718\2

// replaces the 1212 prefix with 1718

dst_translate=....|/\177

// adds 77 at the end of the number

The src_exclude and dst_exclude fields are used for entering numbers to be ignored by a specified dial
peer. For example:
dst_exclude=7888..
All the said fields allow entry of several number or translation patterns to be divided by a semicolon.
Besides, a parameter can consist of several lines, each ending with a semicolon except for the final one.
Examples:
A.
dst_translate=54..../76\2; 55..../77\2
B.
dst_translate=..../34&;
dst_translate=[0-9]{5}/4&
The gateway field is used for entering the gateway name from the gateway.cfg file, or the user name from
the user.cfg file, or one of the reserved words (EXTERNAL, ENDPOINTS, AGAIN or NULL). EXTERNAL
initiates dynamic routing capability of the RADIUS server. ENDPOINTS is for search of gateways with a
complete match of the call number. These gateway numbers are entered in the static gateway records in the
gateway.cfg file or dynamic gateway records in the user.cfg file. AGAIN invokes number translation and
starts a new search for the dial peer corresponding to the translated number. NULL stops further dial peer
search.
The priority field permits setting dial peer precedence.

If a dial peer in the gateway field contains several gateways (separated by a semicolon), the hunt_mode
parameter is used for load-balancing between them:
hunt_mode=0 means that the functionality is disabled;
hunt_mode=1 rotates the gateways on the list every 10 seconds (the first gateway becoming the last one);
hunt_mode=2 every 10 seconds the gateways on the list are sorted by their absolute load (ascending sort);
hunt_mode=3 every 10 seconds the gateways on the list are sorted by their load/capacity ratio (ascending
sort).
The hunt_stop flag discontinues further dial peer search.
The group_allow and group_deny fields allow or ban outgoing calls from the gateway groups described in
the gateway.cfg and user.cfg files.