5 para Wuindows Server

1.
0 Main system - VoipSwitch documentation - VoipSwitch Dashboard Page 1 of 4
1.0 Main system
28 Added by Michal, last edited by Lukasz Nowak on May 18, 2010
Calls processing
Filter and display settings
Reload settings and listeners actions
Logs window
Statistics
Registered Clients
Edit selected client
Gatekeepers
Synchronize with database
Gatekeeper settings
Users
Calls processing
This window is showing calls made by Clients (see Fig.1). You may customize the way calls are displayed with filters and maximum calls number (see Fig.2). All settings are
described below.
All calls are shown in following manner:
[ICON] Call to number: [DESTINATION NUMBER], [CALLER ID] ([CALL TYPE])
Icons are:
New call is connecting.
Call connected and active.
Call not connected with some reason.
Call finished properly.
Call failed with some reason.
[DESTINATION NUMBER] - this is number Client dials (send by gateway or Client's device)
[CALLER ID] - this is Client's ID (sent by gateway or Client's device)
Fig.1 VoipSwitch calls processing window [CALL TYPE] - short description of Client's connection, for example:
(H323 Reg) or (SIP Reg) - call from registered H323 or SIP device
(Callback call) - call initiated by VoipSwitch after client's call to callback trigger number
(H323) or (SIP) - call from H323 or SIP gateway
To view short recording click here.
Filter and display settings

Available commands in context menu (activated after right mouse click on calls window).
Fig.2 Calls processing window - context menu
Context manu give you possibility to manipulate calls display settings, including:
Freeze call list - when you activate this option you can easily look through calls that was on the list - any new call will be shown
Maximim logs - this option will allow you to limit number of calls shown in the calls processing window. It is useful when you don't need to see all calls made but for
example only last 200. In such case calls processing window is more readable and uses less system resources.
Filter - this option give you possibility to bound displayed calls. It is useful when you want to see only calls made by one Client or/and to relevant destination number
(see Fig.3). When setting up filter only new calls are filtered.
Clear filter - resets current filter applied to default settings (to show all calls)
Clear list - this option removes all calls from list (it doesn't influence calls in database, just calls window is cleared)
http://docs.voipswitch.com:8080/display/VDoc/1.0+Main+system 10/16/2010
1.0 Main system - VoipSwitch documentation - VoipSwitch Dashboard Page 2 of 4
Fig.3 Calls filter options
In example on Fig.3 calls are filtered to show only callback Client calls or calls with destination number 48774560220. Every other calls will not be visible on
the list, but of course this will not influence other calls.
Reload settings and listeners actions

Context menu is shown on Fig. 2. Last two options from context menu allows you to reload settings and start or stop listeners.
Reload settings mean, that VoipSwitch will read and apply all changed settings).
Start listeners may be started and stopped. By default all listeners are started after VoipSwitch start. If you want to stop listeners (ie. when changing VoipSwitch
version) just right mouse click on Calls window and choose "Stop listeners". When listenres are not running appriopriate information is shown on Calls window title bar
(see Fig. 4).
Fig.4 VoipSwitch with stopped listeners.
When listeners are not running new calls will not be connected.
Logs window
This window is used to display startup parameters and informations about abnormal Clients operations (ie. calls limit reaching, unknown gateways call attempts).
Fig.5 VoipSwitch log window.
Statistics
Statistics window is displaying in real time informations about current and past calls (since VoipSwitch start). There are four main sections - summary statistics, incoming calls,
outgoing calls and Clients/Users counters. Below you can see exemplary Statistics window (Fig. 6) and short description of computed values:
Connections connected - sum of all successful connected calls since last
VoipSwitch start
Total connections - sum of all calls since last VoipSwitch start (connected and
failed)
ASR - (Answer seizure ratio)
- is computed as:
Connections connected / Total connections
Incoming and outgoing calls:

pending - currently pending calls (callls not yet connected)
connected - current active calls
total calls - total incoming/outgoing calls that has reached VoipSwitch
since last start
total connected calls - total successfuly connected incoming/outgoing
calls that has reached VoipSwitch since last start
H323 calls - all calls that was using H323
protocol
SIP calls - all calls that was using SIP
protocol
ASR - answer seizure ratio for incoming/outgoing calls
ACD - (Average incoming/outgoing call duration)
Registered users - All currently registered users (more details in Registered

clients section)
Registered user calling - Sum of calls in progress made by registered users.
Total users - sum of logged users via Portal/Web, Callshop, Callback module
(described later)
Users logged - currently logged users.
Fig.6 VoipSwitch Statistics window.
Incoming statistics are calculated from client perspective and outgoing are for Voipswitch owner. Example of such difference is visible when client is calling to
number which is sent first offline gateway and than it is rerouted by VoipSwitch to gateway which connects. Outgoing ASR will be 50% because one call to
gateway1 failed and second was connected by gateway2. Incoming ASR will be 100% because one call from client were connected no matter than two gateways
were tried to connect. Total calls in given example for incoming statistics will be 1 and for outgoing 2.
Registered Clients
All clients are represended by icon, username and their IP address (public / private)
Clients icons are:
Registered SIP Client.
Registered SIP Client with active call.
Registered H323 Client.
Registered H323 Client with active call.
Registered PC2Phone Client.
Registered PC2Phone Client with active call.

Fig.7 VoipSwitch registered clients window.
Edit selected client

There is possibility to edit registered Client settings without searching one in VSM or VSC. To do so just click on Client (right mouse button) and select Edit as shown on Fig. 8,
VSM window with Client's detailed configuration will shown.
Fig.8 VoipSwitch registered clients edit dialog.
After right click on Client some basic informations are also displayed (tariff, founds, prefixes and codecs).
Gatekeepers
Gatekeepers window is displaying current state of all active gatekeepers. VoipSwitch has to be registered to gatekeeper in order to send a call there. Every gatekeeper login state
is shown on Gatekeepers window (Fig. 9).
Synchronize with database

After some changes in gatekeepers configuration you should reload settings. This may be done by right click on Gatekeepers window and choose (only one available) option
named: Synchronize with database (Fig. 9). VoipSwitch will read and apply all gatekeepers settings.
Fig.9 VoipSwitch Gatekeepers reload settings.
Gatekeeper settings
Gatekeeper settings shown after right click on one of listed gatekeepers (Fig. 10). You may see some simple statistics (calculated since VoipSwitch start) and Gatekeeper IP,
name, H323 ID, E164 and codecs options.
Each gatekeeper has icon next to it's name describing current register status. There are
only two possible icons as shown below:
H323 Gatekeeper online (registered)
SIP Registrar online (registered)
Gatekeeper/Registrar offline (unregistered)
Fig.10 VoipSwitch Gatekeepers window with settings.
There is also (Fig. 10) log information about gatekeeper login state and 3 buttons to Login, Logout and Reload data for gatekeeper.
Users
This window is showing currently logged and past login/logout actions for Clients which use standalone Callback or Web Callback and Callshop module (Fig.11).
For each Client login and logout time are displayed. Clients may have different icons with their names, it
depends on their login state as shown below.
Client online (connected)
Client offline (disconnected)
Fig.11 VoipSwitch Users window.
Labels
voipswitch calls window windows processing filter reload log logs statistics registered gatekeepers users clients
Printed by Atlassian Confluence 2.10.2, the Enterprise Wiki.
2.0 Clients - VoipSwitch documentation - VoipSwitch Dashboard Page 1 of 13
2.0 Clients
37 Added by Michal, last edited by Bartek Wrobel on Jul 06, 2010
2.1 Introduction
2.2 Common features of clients
2.2.1 Login and password
2.2.2 Tariff
2.2.3 Currency
2.2.4 Account state
2.2.5 Prefixes
2.2.6 Codecs
2.2.7 Active state
2.2.8 Personal data
2.2.9 Reseller
2.3 GW Clients
2.4 PC2Phone Clients
2.5 GK/Registrar Clients
2.6 Callback Clients
2.7 IVR Clients
2.8 Common Clients
2.9 Callshop Clients
2.10 Guest account
2.11 Automatic clients generation
2.11.1 Creating lot
2.11.1.1 Lot's propperties
2.11.1.2 Logins and passwords
2.11.1.5 Supported codecs
2.11.2 Assigning reseller to a LOT
2.11.3 Lot export
2.12 Currencies management
2.12.1 Description
2.12.2 Currency definition
2.12.3 Adding ratio values
2.12.4 Advanced - currency processing
2.13 Client's import and export
2.13.1 Importing/exporting clients
2.13.2 CallShop clients export
2.1 Introduction
Every call coming to VoipSwitch must be authorized before processing. Voipswitch authorize calls from 6 types of clients that differ by functions, method of autorization and available options.
Some features are the same for all kinds of clients.
Clients are added using VSM or VSC or by reseller through VSR pages. In addition automatic registration realized through Web or Portal is used to add clients.
Type of clients available in VoipSwitch system
1. GW clients
2. PC2Phone clients
3. GK clients
4. Callback Clients
5. IVR clients
6. Common clients
7. Callshop clients
8. Guest account
2.2 Common features of clients

2.2.1 Login and password
It is used differently by every type of client. For GW clients it can be used to authorize every call. For GK , PC2Phone or Callshop clients it is used to log to the system. IVR clients use just
a password as PIN number to authorize callers to use the IVR. One common functionality for all types of clients is loging to a web page using login and password. Every type of client has different
information available there and can use it to get access to his account.
2.2.2 Tariff
Tariff assigned to a client is used to:
calculate cost of a call for the client

estimate maximum time of connection
calculate the remaining time announced for IVR clients
limit available directions. If there is no matching prefix in tariff, the call will not be realized.
The cost of every call is calculated using tariff right after disconnection. When tariff for a client changes in the future, all calls made untill this change won't be changed. The system will use new
tariff only for new calls and old ones will be left unchanged. Details on how to define tariffs and how to use them in cost calculation are described here
http://docs.voipswitch.com:8080/display/VDoc/2.0+Clients 10/16/2010
Assigning tariff to the client
2.2.3 Currency
This option allows assigning currency
to a client so he or she can be charged
with different currency that
VoipSwitch owner charges.
Details about currency support are
described here
Choosing the client's currency
2.2.4 Account state

Client must have some funds in the account to be able to make calls through Voipswitch. One exception is when tariff assigned to a client has 0 cost rates, but this is rather unusual. In most cases
every call is charged and this amount is subtracted from client's account state value. When value reaches 0 the client will be blocked.
Account state value can be modified only by adding payments. Using payment in comparison to direct modification account state value has one big advantage. Every change is recorded with date
and optional description.
There are 4 types of payments:
1. Prepaid - should be used after client has paid money.

2. Return - when it is necessary to return money to client this payment type should be used. Return payment cannot be higher than funds available on clients account.
3. Credit - adding fund with this payment type allows client Credit Balance to go below 0 and continue making calls. Total available credit for client is a summary of all credit payments made
for him. It is not clear for some clients but we decided to build it this way to avoid problems with clients overusing accounts. If client really wants to have unlimited credit then it is possible
to add big amount as credit payment.
You can use Credit option to allow users to call below 0. It is not as regular payment, rather like a value which allows user call below 0 until he reach value. You can use that
for postpaid payments but not like adding more credit. If you are using postpaid system, add Credit = 100$, and when client finally pay add normal payment as prepaid. It will
be working like postpaid system.
4. Return credit - this payment decreases available credit for client or removing it. You can't return more credit than you added before.
Adding payments
The most typical way to increase account state (balance) is to add payment. It can be done by VoipSwitch owner using VSM or VSC or by reseller. Reseller can add funds only to clients or resellers
belonging to him. Clients can see history of payment on the web and recharge accounts in several ways. Methods of recharging are described here.
2.2.5 Prefixes
This is a general name used for manipulating information being sent in a client's call. It is specified as:
Dialing plan prefix

Tariff prefix
Caller id prefix
First it must be explained how VoipSwitch processes calls coming from a client. After client authorization, VoipSwitch checks the dialed number. It must match the entries defined in Dialing Plan
and in Tariff. Before searching the dialed number in dialing plan it can be modified by Dialing plan prefix. It will not change number used to find prefix in Tariff. To modify number before
searching in tariff tariff prefix must be used. Caller id prefix is used to modify caller ID being sent to VoipSwitch from a client.
Dialing plan prefix and tariff prefix modify the called number seperately for every given client. A rule defined in one place is not used for another.
Every prefix is built from digits or characters. Modifcation of them is described in special section available here
There are additional prefixes available for callback calls:
Source dialing plan prefix

Source tariff prefix
Source caller id
Every callback call consists of two legs, which means that different rules can be set for modyfing number or caller id for every leg.
2.2.6 Codecs
Allows the selection of 9 codecs groups depending on what client device can support.
One codec has to be set as primary and it will be the default codec.
Voipswitch supports group of codecs, meaning that if you select g723.1, all kind of g723.1 codecs will be allowed, including g723r63 and g723r53. Same thing for other codec groups.
After selection of the codecs you can enable Use client codec to let VoipSwitch negotiate the right codec from the list with client device. Of course client's device has to be able to autonegotiate
codecs.
Codecs settings screen
Please note that VoipSwitch acts differently in "proxy all" mode and in "proxy only signaling" mode. In "proxy all" VoipSwitch does not allow codec negotiation directly between endpoints and
instead will negotiate itself with each endpoint in part. While in "proxy only signaling" the endpoints can negotiate directly the codecs, it is possible to choose any codec that both endpoints
support, even those that are not listed in VoipSwitch settings.
2.2.7 Active state

Client can be active or not active. Inactive client cannot make calls nor log into VSPortal.
2.2.8 Personal data

Every client has an option to write extended information about himself. Available fields are presented on figure below.
Client's personal data screen
These information is used when creating invoices or sending warning emails defined in Services.
2.2.9 Reseller
Client created in VoipSwitch can
belong to reseller or he can be
unassigned. Information about
assigned reseller is presented in client
definition and can be changed.
However it is not recommended to do
it manually. It is more secure to do it
through the resellers pages.
2.3 GW Clients
Those clients are used mostly for carriers and wholesale services. Other popular application is to authorize DID numbers being used to:
activating callback
calling to IVR scenarios
calling to devices and make charging them for answering
Options available for GW client
Login field is the username for this account.
Password is the allocated password.

These 2 fields are used to access the web page to see the CDR's. Also the Login@Password combination is used to match against the H323ID sent by the client in case that Authorise by
login/password feature is enabled. For SIP clients login and password can also be used without adding client's IP.
GW Client's general options
Recognize by H323 ID option allows sending SIP and H323 traffic without IP authorization.
DID source - allows to charge clients answering calls.

It is useful with DID services when client is paying a monthly fee for the number and then additionally for every call answered using this number. This option will work with calls ending to
PC2Phone, GK or Common clients. When checked, every such client will be charged for answering a call. Tariff assigned to this client will be used to calculate cost of a call. If a client doesn't have
enough money to pay even one billing step, the call will not be connected.
PIN source option is used for calls made to IVR system. Calling to PIN asking scenario allows to work with calling cards services. Only with this option checked GW client can connect to
scenario with PIN name. Such call will be billed in two ways.
SIM Source
IP address based authorization
IP numbers are the list with authorized IP

addresses. Cost of calls coming from IP
assigned to a client is taken from his
account. You can set here an unlimited
number of addresses, but one IP address
can be enabled only for one GW Client at a
time. Under the IP numbers list there is a
field where to write the new addresses to be
added in the list. Use the "Add IP" button
after you fill it.
To remove an IP from the list select it first
and then click Remove IP.
It is possible to add IP addresses in range.
After clicking Add Range button the dialog
as on screen below will appear.
There it should be set starting IP and
ending IP. VoipSwitch will use them as
boundaries to create appropriate entries in Adding IP number to the GW Client
IP numbers list. For starting IP will be
added 1 till it reaches ending IP.
Connect client immediately

Enable this only when all calls of a client do not connect to any destination. This will open the media channel immediately after routing but in most cases will generate also false billing because the
calls will be declared answered immediately.
So this feature is for extreme cases only. Do not use it for normal users.
Calls limit
Used to a limited number of concurrent calls being sent from gateway. When number of calls is equal to this limit any new calls from this client will be rejected. This is also checked for calls in
progress and connected apiece.
2.4 PC2Phone Clients

This type of client is for PC2Phone dialer and Web2Phone page access only. PC2Phone is a proprietary application that allows clients who have a valid PC2Phone client account to connect to the
VoipSwitch and initiate and also to receive calls. This dialer uses particular communication ports and is not compatible with other systems.
Settings for PC2Phone clients are very simple and the fields have mostly the same
meanings as for GW clients. Generate ringback is the new option here.
If checked VoipSwitch will generate ringback tone while calling the PC2Phone
user.
PC2Phone application always uses g723.1 codec group so there is no need for codec settings.
PC2phone client is allowed to make only one call at the same time. This type of client is hot billed.
Login and password defined for every client are used to log using PC2Phone application
Log-in screens of PC2Phone dialers
More about PC2Phone application is described here.

Setting termination on PC2Phone client is described in dialing plan section of manual.
2.5 GK/Registrar Clients

This client type is used for devices behind NAT, or those which change the IP often or simply want to register with a user and pass only. The client will have to configure his device to register to
VoipSwitch's Gatekeeper (when using h323 protocol) or Registrar (for SIP protocol) using the username and password he received. Also he will need to enter in his device configuration the IP of
Voipswitch server and the
Gatekeeper name that is by default Gatekeeper (in case he uses h323).
Parameters supported codecs, calls limit have the same meaning as desribed for GW clients.
Login and password are used to log from device to VoipSwitch acting as Registrar or Gatekeeper. VoipSwitch will recognize automatically the protocol being used to log.
Clients of this type are hot billed but only when one port of device uses one login and password. Otherwise the hot billing function may not work, for example when one call is started and then
second port using the same account calls. The system will not be able to calculate properly remaining account state, and account balance can go below zero.
To eliminate this possibility calls limit value should be set to 1.
After sucessfull loging to VoipSwitch a device will appear in Registered clients. Different icon will be used for h323 and sip devices.
GK/Registrar clients working with SIP protocol can be used also with VoipTunnel module. How to work with VoipTunnel and GK/Registrar clients is described here
2.6 Callback Clients

These clients can use different types of callback. Detailed description can be found in manual for callback system. Every connection made by callback client consists of 2 calls and both are charged.
Main callback features are listed below:
After being connected to destination number a client can finish call and pick another number without disconnecting source leg of connection.
After setting appropriate scenario the client can hear account state and remaining time announcement after every call made.
There is an option available to charge source leg only if destinations were connected.
Separate dialing plan, tariff or caller id prefix can be set for source and destination number used. Thanks to this it is possible to use different rates defined in the same tariff for source and
destination numbers. Also different gateways can be used.
2.7 IVR Clients

Used in calling card service. Using this type of clients is possible only with VoipSwitch with IVR module. Every client must go to VoipSwitch through connection already authorized. Clients are
using regular phones to call to special number redirected to VoipSwitch. Such call is being connected to PSTN network and is authorized on VoipSwitch as GW client with [PIN source] option
checked. Then a client connects to scenario which asks about PIN number. After finishing one connection the user can pick another number without dialing access number again.
Client can call to recharge scenario to add funds using special recharge codes or check account state on his account.
They can also call from authorized phone numbers without entering the pin number. Authorized phone numbers can be added:
through VSPortal by choosing "Authorised caller IDs" from menu,
by sending specially formated SMS message

by calling to special scenario which will register phone number after successful login by pin (can be used one of the "PIN+register" scenarios or special scenario which uses DTMF).
by the switch operator via VSM or VSC.
Setting authorized numbers for IVR Client
To enable calling from authorized numbers feature "Recognize by ANI" option has to be checked for the client.
2.8 Common Clients

Special type of client which can be used for different services like:
PC2Phone dialer;
IP Phone;
Calling Cards service, PIN-less service;
Callback service.
It is recommended to use this type of client for new clients. One account for all mentioned services can be set in this way and no matter what service is used the same account is charged for calling.
If the client desirably has to have limited accessibility to services it should be considered using other account type (PC2Phone, GK/Registrar, IVR).
Calls redirection can be set in the same way as for other types of clients. No matter what service is used to log to VoipSwitch (from dialer or IP Phone) client can receive calls.
2.9 Callshop Clients

This type of clients differs greatly from the others. Client of such type is used to log to VoipSwitch from callshop application.
Callshop application is available as part of a callshop module. Every callshop definition consists of a number of cabins assigned. As a cabin can be used GW, GK/Registrar, Pc2Phone or Common
client's accounts.
Assigning a Cabin to the Callshop Client
Client assigned to callshop is used differently then unassigned. When callshop client (to which specified cabin belongs) is logged in VoipSwitch then the cost of every call is taken from callshop
account, not from cabin account.
Cabin account state should be set to 0 to avoid calling from it when callshop application is logged off.
When callshop client account will reach 0 then any cabin will be blocked from calling. Tariff assigned to cabin is separate from tariff assigned to callshop. This tariff is used to calculate end user
prices and is higher then callshop tariff. Difference between those tariffs is a profit for callshop. Callshop client can change cabins rates through the web interface so such client has a right to set
rates charged from clients.
It is important to assign different tariff to every callshop client. If assigned the same changing it will affect every callshop client with such tariff.
More about callshop application can be find in Callshop manual.
2.10 Guest account

This pecial feature
allows to call from
unauthorized devices. It
can be turned on using
VSM->Settings-
>VoipSwitch. A combo
box with a list of GW

clients can be found
there. If any client
account is chosen then
calls not authorized
(normally rejected) will
be accepted and
assigned to this client.
Setting the Guest account feature
2.11 Automatic clients generation

For every type of client it is possible to generate clients automatically in lots.
All clients are assigned to a lot identified by name. Later it can be easily managed to change tariff, modify account state for all clients, export, activate, deactivate or delete.
Generated lot can be assigned to reseller.
Automatic client generation is available in Clients node of VSM or VSC application.
After clicking it the list of lots will appear.
The list of lots
Every row in this list is describing one lot. There is name of a lot, number of clients and type, creation date and links used to activate or deactivate all clients in a lot. Before activation or
deactivation the system asks about confirmation.
It is possible to remove the selected lot by clicking the Delete button above the list. If more than one is checked the checkbox system will remove all checked.
Removing lot will remove all clients belonging to it and operation cannot be undone.
2.11.1 Creating lot

Creating lot of clients is divided on few section. Every such section has fields used to define parameters for generated clients.
Location of Automatic Clients Generation in VSM and VSC
2.11.1.1 Lot's propperties

Descripition - lot name which allows to identify group of
clients. In clients list it is possible to filter clients using this
name. From list of available lots it can be activated,
deactivated or removed by selecting this name and
choosing appropriate action.
Lot name should be detailed to be to easily

recognized in the list of other lots
Number of new clients - number of clients to be created

Starting serial - this number will be used to identify every client created in lot. It can be used as card number if logins or passwords are printed on card. In export of lot this number will be
available and used later for printing or client identification. If there is a new lot and cards numbers don't start from 1 then serail number can be set with any value and new serials will start from
given value.
Users - type of clients to be generated. Changing the type of client also changes other section enabling or disabling option available for different kind of clients.
2.11.1.2 Logins and passwords

Options defined in these section are the same but they are
used for login and password generation for new clients.
Number of characters - number of characters used to
create login or password. Type of characters used to
generate is defined below.
Starting characters - every login or password can start
from some initial starting characters. It is used to easily
identify all clients or can be used to set dialing plan with
only one entry to all these clients. Such scenario is
described here.
Starting characters cannnot be too long in comparison to Number of characters. For example setting login length as 5 and starting characters as value 7777 will allow only to generate
9 different logins. Depending on client type the login or password must be unique so if there are any other clients created already it will narrow possible values.
Logins and passwords are generated randomly. Every character used in login or password is randomly generated and its type depends on which option is checked:
Use numbers
Use up cases
Use low cases
If more than one option is checked the system will generate it as a mix of different characters.
For GK/Registrar clients it is good to create logins as numbers only so later it is easy to set dialing plan for automatic calls redirection to them without any number modificiations.
For IVR clients password is used as a pin to log to the system so it must be defined also as number because letters are not possbile to enter from phone keypad.
Sequential generation - allows to generate login or password sequentially. Below there is Starting number and Step. During client generation it will start from starting number and every new
login or password will be increased by step value. If there are starting characters set it will add generated value to it. It wont be added as number but as concatention of characters for example
starting characters set as 1000 and starting number as 3000 will create first client as 10003000 and not 4000.
2.11.1.3 Client's properties

Values defined there are the same as used when client is added or edited manually. The only difference is that value set there will be used to create all clients in this lot. Some fields in this section
are activated or deactivated depending on the kind of client chosen to generate.
Tariff
Chose tariff according to rules
Funds
Dest. dialing plan prefix
Dest. tariff prefix
Dest. caller ID prefix
Src. dialing plan prefix
Src. tariff prefix
Src. caller ID prefix
2.11.1.4 Connection settings

Allows to define special properties used by clients of chosen type.
2.11.1.5 Supported codecs

It can be determined which codecs will use newly generated users.
2.11.2 Assigning reseller to a LOT

Create lot can be assigned to reseller by clicking right mouse button on
selected lot. Context menu will appear with command "Add to reseller". After
choosing a reseller lot and all clients belonging to it will be assigned to him.
Assigning lot in this way is not typical way and it will not cause
changing "Clients limit" value for reseller. Normally resellers
should create their lots from reseller system VSR.
2.11.3 Lot export

Lot export is available by clicking Export button above list of lots.
CSV comma delimited file is used as output format. Such file can be opened and modifed by Excel or notepad. During export operation there is progress window available presenting current status
of operation and when option open file after finishing is checked the system will open exported file automatically when finished.
Exporting the lot
2.12 Currencies management

2.12.1 Description
This feature allows to assign different currencies to clients. For example, if VoipSwitch owner is charged in USD and his clients want to be charged in EUR, one may keep USD as base currency
but assign clients EUR.
One thing is very important to work properly with currencies in VoipSwitch. Tariff assigned to a client and payments added should be considered currency defined for him. Rates in tariff are added
only with value and only assinging them to clients will define what currency and ratio is used to calculate cost of a call. The same goes for payments. Amounts added must be connected with
currency defined for every client.
Currencies are not supported for any level of resellers or costs calculation for termination devices. Only based tariff can be used to calculate their cost. All tariffs assigned to resellers
or termination gateways must be in the same currency which is treated as base.
Future browsing calls made by clients in VSM, VSC or VSR will show value made in base currency. Clients logging on the web and portal will be able to see these values modified by ratio defined
for currency. Values taken from calls are multiplied by ratio assigned to currency defined for clients and taken for browsed date.
2.12.2 Currency definition

First thing to do when you start working with tariffs is adding currencies. Every currency has defined number of ratios assigned with dates. It is important to keep them up to date.
Currency manager main screen
2.12.3 Adding ratio values

In the main currencies window you can add or edit a list of
managed currencies.
When you click the currency name, the dialog box with ratios
for given dates appears.
Ratio has the function of dividing the cost of a call before it is
saved in the database. This means that all costs for resellers,
clients and termination devices have the same currency, which
allows to calculate profits. Before the cost of a call is displayed
for a client on the web it is multiplied by ratio saved with
the call, and the client can see proper value on the screen.
Changing ratio for previous dates will not change

cost of calls made by clients. Changing ratio for
the last day will cause new calculation for calls
made after this change. Ratio used to calculate
the cost of a call is stored with every call and it
cannot be changed after finishing the call.
Adding ratio to the currency
2.12.4 Advanced - currency processing

1. Values used in tariff or in payments should be in a currency assigned to a client. Tariff definition makes no difference for different clients. Different rates can be used only from the
currency assigned to the client. The same is for payments.
2. When client is connecting to VoipSwitch remaining time is checked. Tariff and amount of money on client's account is used to calculate the cost of time remaining. If tariff has appropriate
rates and amounts are defined in the same currency, all is valid and the client will be disconnected properly upon reaching 0 amount.
3. After finishing a call cost of reseller or cost of termination is calculated without any change. There is a difference for a client who has different currency. Before the cost of a call is saved in
the calls table of VoipSwitch's database it is modified by appropriate ratio taken from the currencies table. Doing this recalculation will save cost for the client in the same currency as for
other costs. It will allow to estimate profits properly.
Diagram showing the cost calculation
1. A client after logging to his web pages will see costs taken from calls table but multiplied by ratio. After saving cost of a call for client ratio is saved in every call record and later used to
show values in client currency. Browsing calls in VSM, VSR and VSC will show results without any multiplying.
Internal Notes This section won't appear in exports
2.13 Client's import and export
2.13.1 Importing/exporting clients

VSM and VSC export and imports Client's information using comma delimited CSV format without column names. Eeach row represents one client definition.
Note: In VSM - user could select which column may be exported - but changing the exported columns will cause problems in importing this data back to VSM or VSC, because only all-columns
exports could be imported back.
Exported file format:
test,123,3277362,173,235.0000,SD:;ST:;DP:;TP:;CP:;SC:,-1,-1,0
Fields meaning (counting from left side):
1. Client login,
2. Password,
3. Client type - value set there is coding option available for client definition like codecs, connect immediately and others,
4. Tariff ID in system (or Tariff Interstate ID) - is internal number assigned to every tariff created in system. It is not presented anywhere in the system and can be seen only in export file,
5. Account state - client's money amount,
6. Tech prefix - values coded here are used as tariff prefix (TP), dialing plan prefix (DP) and caller ID prefix (CP). For Common Clients and Callback Clients there will be also source dialing plan prefix
(SD), source tariff prefix (ST) and source caller ID prefix (SC) This values are coded from appropriate text boxes in client's definition,
7. Reseller ID in system - internal number assigned to reseller of first level. This number is not visible in system,
8. Intrastate Tariff ID,
9. Calls limit - it stands for calls limit value limiting number of concurrent calls being accepted from defined client.
Export client's operation with visible dialogs: a) Performing task progress (default dialog in VSM for long tasks), b) Select columns which should be saved to file.
As described above some fields are difficult to create by someone who wants to import clients. It is recomended to export first one or few clients with proper definition. Later using Notepad,
Excel or OpenOffice it can be modified and multiplied. The value of some fields and others can be filled with logins and password or account state values. The file can be saved from Notepad,
Excel or OpenOffice using CSV file format and imported with VSM or VSC application.
In the future it will be available to import clients using special form by filling coded values.
2.13.2 CallShop clients export

Format has some differences fom standard client's modules export:
Exported file format:
CSExample,CSExample_pwd,61,500.0000,-1,DP:;TP:;CP:,
Field meaning (counting from left side):
1. Client's login
2. Password
3. Tariff ID (from VoipSwitch's database)
4. Account state
5. Reseller ID (from VoipSwitch's database)
6. Tech prefix
In Callshop there is no possibility to assign Interstate/Intrastate tariff, so this field is not supported by export too.
Because of differences between exported file format between Callshop clients and other clients in VoipSwitch such accounts data can't be interchanged using export/import options
without editing the exported file.
Children (21)
Account state
Active state
Automatic clients generation
Callback Clients
Callshop Clients
Client's prefixes
Codecs
Common Clients
Currency
GK Registrar Clients
Guest account
IVR Clients
Login and password
Personal data
Reseller
Tariff
GW Clients
PC2Phone Clients
Currencies
Prefixes
Recharging accounts
Comments (1)
READER says: Dec 11, 2008
can we deactivate a client automatically after a particular time period say 60 days after recharge
___________________________
Expiration service is triggered after first call made by Customer. More details here.
3.0 Destinations - VoipSwitch documentation - VoipSwitch Dashboard Page 1 of 5
3.0 Destinations
11 Added by Michal, last edited by Bartek Wrobel on May 26, 2010
3.0 Destinations
Every call coming to VoipSwitch is first authorized by proper definition of clients. Then the dialed number is forwarded depending on the Dialing Plan rules to te specified destination.
There are 5 types of destinations where VoipSwitch can send calls:
3.1 Gateways
3.2 Gatekeepers
3.3 GK, PC2Phone, Common clients
3.4 Enum routes
3.5 Lookups
3.6 VoipBox (IP IVR)
3.1 Gateways
In this section can be defined the termination gateways where calls will be sent . VoipSwitch forwards traffic to the gateways in direct mode (IP to IP).
Gateway definition VSM Gateway definition VSC
Available general options for gateways are described below:
Description is a label for the termination gateway;

IP number is the IP address of remote termination GW. Instead of IP the domain name like sip5060.arbinet.com can be set;
Port on remote gateway where calls are being sent. Standard port for h323 protocol is 1720 and
for SIP 5060. If changing protocol the port has to be changed manually;
Calls limit sets a limit of maximum simultaneous calls that Voipswitch is allowed to send to
this terminating gateway. Zero means unlimited calls;
Active sets the gateway active or inactive;
H323 device or SIP device determines the protocol that Voipswitch will use when sending calls
to this gateway;
H323ID and FastStart are options that can be set when you select H323 protocol. H323ID
can be required by your termination carrier to be sent for authentication. If not required it is
safe to be left blank. FastStart is a specific H323 protocol feature that enables faster call
connection and advanced in-call options like call on hold and forwarding. You have to ask
your carrier if his terminating gateway accepts this feature.
When you select SIP protocol you will be presented with Username and Password fields. Set
them according to the terminating carrier requests or leave them bank;
Early H245 permits to achieve faster call initiation;
Calculate cost and Tariff when this check box is selected there must be tariff chosen from combo box. This tariff will be used to calculate the cost of connection after finishing every
call terminated using this gateway. Tariff used there is defined in the same way as any other tariff in VoipSwitch. It should be named differently than tariffs used for clients. Cost of
calculation allows later to compare bills received from carrier or to see profit for calls made by clients;
Dialed number prefix is prefix which will be added to dialed number just before call is sent to termination;
Dest. tariff prefix is prefix which is added to gateway tariff for destination cost calculation.
Gateway codec section - codecs accepted by remote side:
http://docs.voipswitch.com:8080/display/VDoc/3.0+Destinations 10/16/2010
Gateway codecs definition
3.2 Gatekeepers
VoipSwitch can log to gatekeeper or registrar by itself and then send calls there. All information used to register should be provided there. Useful function is LRQ which allows to negotiated
with Gatekeeper new ip address and new format number. This option must be supported by gatekeeper and VoipSwitch will handle it. After you create the GK/Registrar account you can go to
the main VoipSwitch application, press right mouse button on the gatekeeper in "Gatekeepers" window and choose "Relog" to make VoipSwitch try to register immediately. Properly defined
and configured gatekeeper is marked with blue color. If there is any problem it is marked with red.
Gatekeeper/Registrar definition VSM Gatekeeper/Registrar definition VSC

Description field is a label for the
termination account.
IP number sets the remote GK or
Registrar IP address.
Port which is used to send the
registration request (usually 1719 for
h323 Gatekeepers and 5060 for SIP
Registrars).
Time To Live in seconds. It sets the
amount of time until Voipswitch will
check again if the remote GK or
Registrar still accepts calls. Better to set
this value smaller or equal than the value
set on remote side.
Calls limit limits the simultaneous calls
number.
Supported codecs accepted by remote
side.
Gatekeeper (h323):
H323 ID, E164, GK name, FastStart -
consult your carrier about these settings.
If not required leave them blank. But
you should set at least GK Name and
FastStart.
Registrar (SIP):
Password, User name, Domain user,
Domain - consult your carrier about the
values in these fields.
Dialed number prefix is the prefix which will be added to dialed number just before call is send to termination.
Dest. tariff prefix is the prefix which is added to gatekeeper tariff for destination cost calculation.
Gatekeeper/Registrar codec section - codecs accepted by remonte side:
Gatekeeper/Registrar codecs definition
3.3 Clients defined in VoipSwitch

Any number set in VoipSwitch can be redirected to clients logged in VoipSwitch. It can be done in the Dialing Plan by choosing appropriate Destination:
Internal gatekeeper (GK/Registrar client)

PC2phone user
Common user
After selecting the type of client specified login should be chosen from the list of clients.
Selecting one of Common Clients as a destination
After the assignment a call coming to this number will be sent to such device or dialer. No matter what IP is used to login or whether a device is logged from behind NAT (SIP protocol only)
the call will be sent properly. Sometimes it is required to modify number sent to client device to change according to rules. On VSPortal client can set "Answering rules". This feature enables
him to define variety of calls redirection rules. Clients are charged for redirection depending on their tariffs. It is possible to charge clients for answering calls sent to them (DID option in GW
Clients settings) and client tariff will be used to calculate cost. For bigger number of clients it is possible to define redirection for all clients using just one entry in dialing plan. Every such client
login should have the same beginning.
3.4 Enum route

Enum route is a DNS server which changes phone number to SIP/H323 URI (address) of the number's owner. The most known enum route are e164.arpa and e164.org.
The following examples will clarify the usefulness of these route:
1. e164.arpa comprises all PSTN numbers. Lets imagine that Bob has a +48 100 200 300 proper phone number. In the same time he has SIP account at callto.net, which is
sip:bob@callto.net. He added a record to the e164.arpa (usually by Web pages maintained by e164.arpa itself) which contains his PSTN number and his SIP account information. Now
Alice wants to call Bob. She has SIP account sip:alice@haloswiat.pl. But she knows only the number of proper phone of Bob. So she just dials +48 100 200 300. If haloswiat.pl is
capable of enum lookups, it will look up the enum.arpa, finds Bob's SIP URI, and dials to his SIP device, which makes the call costless for Alice. If there is no Bob's record at enum.arpa,
the call should go to his proper phone in a "normal" way.
2. e164.org is responsible eg. for a range of international numbers started from 88. Lets assume Bob asigned 8892 100 100 100 number to his SIP account at callto.net. It could be done on
e164.org Web pages or via Portal. Alice's SIP device is logged to haloswiat.pl, another VoIP provider. If Alice wants to reach Bob, she just dials his 8892 100 100 100 number.
haloswiat.pl search for that number e164.org and finds the Bob SIP account. Then tries to connect to that account. Of course callto.net has to have a guest account to accept the call
from "uknown" haloswiat.pl.
Setting enum routes is very simple:
First things first enum route has to be configured in VSM's Enum roots section. There aren't many options to be set here - Description is a name of enum route that will be stored in
database and IP number is an address of enum route.
Adding enum routes
Secondly Dialing Plan entry has to be added. Enum route can be added with priority 0 so VoipSwitch will try to send call using this entry first and if failed will route it to the gateway
specified with the priority 1.
Connecting Dialing Plan prefix with Enum Route
3.5 Lookups
With VoipSwitch version 944 lookup for a number in external Lookup Service Provider has been added. There is a new route type in Dialing Plan - Lookup route. Choosing this route allows
you to set a destination as one of the service providers saved in Lookup table. The Lookup table can be changed only using some sql tools (not directly from config) because lookups are not
commonly used and each one needs a small VoipSwitch's modification.
The first provider we support is RMV3. When the call is directed to the lookup service VoipSwitch sends to the provider via http authorization credentials (from DB) and called number.
Provider sends back new number. Now VoipSwitch applies client's dialing plan prefix to that number (second time in that call, before dialing plan prefix was used to dialed number) and makes
new search in Dialing Plan to find destination for given number. Then VoipSwitch just forwards the call to new destination.
Lookup services are usually used to get information about real provider of a mobile number. The prefix of a number is not longer enough to specify the provider, specially since we are able to
change the operator and save our mobile number.
There is no one standard lookup response so small VoipSwitch's modification is needed before using this feature.
Since VoipSwitch version 985_13 new feature is available.

There is possibility to define a query in lookups table which will be fired on VoipSwitch database.
Query is expected to return "one row/one column" dataset with the new number to search in DialingPlan.
Exemplary SQL statement is
sql://SELECT new_number FROM MyTable WHERE ani='#cli#'
Statement must be entered in the query_string column of lookups table. Returned column name is not important. String "sql://" defines type of lookup (currently two - "http://" and "sql://"
types are allowed).
"#cli#" is a dynamic variable replaced with proper value by the VoipSwitch before statement execution.
Possible dynamic variables are :
"#number#" - full dialing plan number (parsed with client's and dialing plan prefixes)
"#cli#"
"#caller_ip_number#"
"#id_client#"
"#client_type#"
For setting lookup scenarios you can view following manuals:
Lookup scenario for ported numbers

How to set LOOKUP scenario
3.6 IP IVR (VoipBox)

Last type of destination is VoipSwitch IVR system. Client connecting to such destination can hear voice depending on the assigned scenario. Available scenarios are described in Voipbox
manual. To list only few examples it can be used for playing account state information, asking for clients PIN number in calling card services, asking for number, etc. All details are described in
IP IVR module section.
Connecting VoipBox scenario with a prefix in Dialing Plan
Children (7)
Destinations
Destinations - Clients
Destinations - IVR
Enum route
Gatekeepers
Gateways
Lookups
4.0 Dialing plan - VoipSwitch documentation - VoipSwitch Dashboard Page 1 of 11
4.0 Dialing plan
12 Added by Michal, last edited by Bartek Wrobel on Jun 15, 2010
4.1 Base informations

4.2 Calling modes
4.3 Load balancing
4.4 Rules for modifying client's data
4.4.1 Fields definitions
4.5 Automatic calls redirection to group of clients
4.6 Special properties
4.7 Time span
4.8 Importing and exporting dialing plan data
4.8.1 Exporting dialing plan entries
4.8.2 Importing dialing plan entries
4.9 Least Cost Routing (LCR)
4.9.1 Applicability
4.9.2 Operation

Dialing plan is used to route calls to destinations. Rules are based on dialed numbers. First characters of numbers are named prefixes. Every prefix is assigned to a
destination. VoipSwitch searches for matching prefixes and tries to send call to the most detailed (the longest) prefix. For example, when 48600316151 number is
dialed and prefixes 48600 and 48 are defined in dialing plan the system will try first to connect the call using 48600 prefix. If gateway defined for first matching prefix is
not connecting, gateway defined for less detailed will be used. The same prefixes can have different priorities to set order of choosing them or different balance share
what enables the Load Balancing feature.
VSM Dialing Plan screen VSC Dialing Plan screen
This part of manual describes rules for creating dialing plan entries and available options.
4.2 Calling modes

It is used to define special properties when passing a call between origination ( client ) and termination side. Modes chosen depend on protocol used by a client and
destination.
Modes available for H323 client calling to H323 destination:
Independent signalling and media proxy - origination and termination endpoints do

not see each other, the VoipSwitch connects independently with each endpoint then
conferences them together.
H225 signalling and H245 signalling proxy and media proxy - the signaling and
media will still be passed through VoipSwitch as in first rule. The difference between
this option and the previous is that the call setup received from the client is sent to the
target gateway. So the two endpoints can use more codecs if they both support them
(even if VoipSwitch doesn't support it). Also, information coming from a client
through H245 channel is forwarded directly to the termination gateway. So H245
tunneling can be used (if both endpoints support it).
H225 signalling and H245 signalling proxy - only signaling information and H245
channel are passed through the switch, media packages are sent directly between
endpoints.
H225 signalling proxy - in this mode only signaling information is passed through
the switch. All the rest are flowing directly between the two endpoints.
Modes available for SIP client calling to SIP destination (meaning is the same as for H323 modes):
Independent signalling and media proxy

Signalling and media proxy
http://docs.voipswitch.com:8080/display/VDoc/4.0+Dialing+plan 10/16/2010
Signalling proxy
Modes available for h323 client calling to SIP destination and from SIP to h323 (changing protocol):
Media proxy - VoipSwitch is handling protocol conversion as well as media packets are passing through it.
No media proxy - only protocol conversion is being made by VoipSwitch. Media packets are being sent directly between endpoints.
4.3 Load balancing

This function allows to set percentage of calls being sent to different destinations for the same prefix. It is useful to split traffic between gateways for the same country.
Any number of entries in a dialing plan can be set in this way but they must fulfill special requirements:
1. Number is exactly the same for each entry,

2. Priority is exactly the same for each entry.
3. Summary of balance share value for all entries must equal 100.
In case it is desired three gateways to be balanced equally it has to be set 33/33/34 "Balance share" for those gateways. The balance share does not have to be equal for
each entry, but their sum has to be 100.
Example of Load Balancing set in the Dialing Plan
For better finding entries with defined load balancing all of them are selected in different green color.
4.4 Rules for modifying client's data
Different "Call strings" are present for different destination protocols (SIP or H323)
This field is complex and allows modifying different call settings last time before the call is sent to the termination gateway.
At the end of this field there is a button with 2 dots. Pressing it will open a window that will guide you through the possible settings for this rule.
Information available to be changed:
Dialed number - allows changing number.

IE display and IE Calling party number are 2 fields from H323 protocol that refer to caller ID information. If you want to modify the caller ID sent to
termination you should modify either one or both fields depending on termination provider (some accept first field others work with the second field).
H323 ID - sent to the termination GW can be modified or defined here as well.
Display and From field fields are doing the same for SIP as "IE display" and "IE Calling party number* for H323 protocol.
Dest. tariff prefix - allows to modify the called number before it is sent to the the tariff assigned to the destination.
Rules definition on how every string is changing are described with details in section prefixes.
Very common usage of field Dialed number is

to add some prefix before sending a call to the
specified gateway. Some carriers require it for
authorization or different billing. VoipSwitch
owner can have clear dialing plan with real
country codes. Using these rules it can be
modified. In given example number
31798804370 is modified by adding in front
prefix 77678 so on destination gateway 1233 will
be received number 7767831798804370
Other common option is to replace number

dialed by client to number expected on IP
phone. If destination is IP phone logged to
VoipSwitch as GK Registrar client than in most
cases it will respond only to the number being
the same as login. If we want to redirect some
DID number then rule must be defined as show
on screen. In given example number
33172898106 is replaced with login name which

is sipura1 before it is sent to destination IP
phone logged with login sipura1.
Every device has special field used as number to
which it responds. Below is a list of different
devices with these fields marked.
Sipura, Cisco ATA,
Since VoipSwitch version 966

there is no need to replace
destination number. When a call is
directed to logged device
VoipSwitch sends there an internal
number, unless there is something
about the number in 'Rules for
modifying client's data'. This is
quite comfortable for end users,
they do not need to change
internal lines numbers.
4.4.1 Fields definitions

There are three fields defined , P-Asserted-Identity, Remote-Party-ID and From.
Each of them is defined by regular expression put in the table, it may be changed to extract other paramenters but it is not necessary.
Regular expression divides each field to three parts which are defined in the table also. For example
P-Asserted-Identity is composed of 3 parts ,
paid1, paid2, paid3
Example:
In the field
P-Asserted-Identity: "Cullen Jennings" <sip:fluffy@vovida.org>
paid1 is "Cullen Jennings"

paid2 is fluffy
paid3 is fluffy@vovida.org
The rest of fields are divided similarly.
Those parts can be used in prefix definition of Dialing Plan.

Exemplary Dialing Plan prefix is
P-Asserted-Identity:t[paid1] <sip:t[paid2]> OR t[fm1] <sip:t[fm2]>
This prefix means :

add to SIP INVITE P-Asserted-Identity field when one of two "tech prefixes" (
t[paid1] <sip:t[paid2]>
OR
t[fm1] <sip:t[fm2]>
can be used ( prefix can be used when at least one token t[] can be created).
t[x] means part x of field defined in the mentioned table
First subprefix means

take from client's INVITE message paid1 part of P-Asserted-Identity field and add to it "<sip:" and add part2 and add " >". Of course if client doesn't have P-
Asserted-Identity field, next subprefix will be fired and
VoipSwitch creates P-Asserted-Identity field using client's From field.
In order to add Privacy:ON to the INVITE with P-Asserted-Identity defined prefix should look like:
P-Asserted-Identity:t[paid1] <sip:t[paid2]> OR t[fm1] <sip:t[fm2]>

Privacy:ON
In database there will be "\r\n" at the end of first line.
Because Privacy is "static" prefix it doesn't need any entry in the field_description table.
There is another example for Remote-Party-ID :
Because Remote-Party-ID mechanism never got an RFC status even we suggest to use P-Asserted-Identity instead.
To adjust From field send from VoipSwitch to external gateways following rule can be used:
From:t[fm3] <sip:t[fm2]>
This rule will take user caller ID prefix to manipulate incoming From parameter from INVITE packet (for Vippie or SIPLink user login is send as caller ID).
If user Destination CallerID prefix is set to "!15672480700" then above rule will cause VoipSwitch to compose From parameter for outgoing INVITE like that:
From: 15672480700 <sip:15672480700@213.218.118.232:5060>
instead of default:
From: <sip:15672480700@213.218.118.232:5060>;tag=170238101413183785718
Above rule is especially needed when Carr
4.5 Automatic calls redirection to group of clients

Map DNIS to GK/Registrar accounts
Map DNIS to PC2Phone accounts
Map DNIS to common clients accounts
All these "Map DNIS to..." features will automatically route the calls to the GK/Registrar, PC2Phone or Common client account having the Login as the dialed
number.
For example, to route calls internally between all your PC2Phone clients all you need to do is to create the PC2Phone accounts with distinct numbers as Login name
and then add a Dialing Plan rule having Map DNIS to PC2Phone accounts enabled.
While creating the Dialing Plan rule the distinct number has to be set in the Number field and the Destination can be set any of the present.
Destination is omitted in this case but has to be set with any value.
"Map DNIS to..." features can be found under "Connection properties" in Dialing Plan
When this option is used Follow me feature is automatically turned on.
4.6 Special properties

Prefix not allowed - used to block any call coming to a number starting with such prefix. Even if there are other prefixes matching the dialed number
rerouting will not be made. Common practice is to block special expensive numbers.
Route disabled - For some reason (expected gateway inaccessibility) we can disable prefix without removing it from the dialing plan. Such prefix will not be
used to send calls and later it can be easily restored.
Disable "follow me" for DNIS mapping - This option the Follow me feature.
Map DNIS to ...
Follow me
Allow Voipbox to send media before client - used to send recording from voipbox without sending connect message to client. It is used commonly with
callback service. DID number used to activate callback can be set in dialing to Voipbox and Play file scenario. This scenario is playing recording as no answer
voice. Voice is played to client but connect is not returned so there is no charging for such call.
Do not announce time - option used to stop announcing time when a call is made to this number. Announcing the remaining time is one of the features of IP
IVR module. For some service numbers ( account state information, recharge scenario ) time announcement is not required and can be blocked using this
option.
Do not jump - when you have multiple rules for same prefix you can enable this option to stop the hunting when the call will fail on the current rule.
4.7 Time span

Every prefix defined in the dialing plan can have
set time or day of week when it will be used.
Different destinations can be used in different
time.
"From your" - "To hour" time interval will apply
in every day included in the day's interval.
"Time Span" feature for Dialing Plan has to be
turned on in VoipSwitch Settings in VSM
application. There can be found Use time spans
in DP option which has to be checked in this
case.
4.8 Importing and exporting dialing plan data

4.8.1 Exporting dialing plan entries
Export of dialing plan entries is available in VSM and VSC web config. After choosing dialing plan record from a menu tree the import export buttons will appear in
the upper right corner of the screen.
Export buttons for exporting dialing plan positions
Clicking on Export button results in exporting all dialing plan entries into the coma delimited CSV file. System will ask for location, where the file has to be stored, and
it's name and then it will proceed with the operation. CSV file can be opened in Notepad, Excel, OpenOffice Calc or any similar suftware for further modifications.
If the filter is applied only filtered records will be exported.
Exported columns order:
Number Priority Destination Id route Tech prefix Call type Type From day To day From hour To hour Balance share
48 0 1 4 'DN:00->365' 1216348180 1036 0 6 0 2359 100
Number and priority are self-explanatory and the same titles can be found in a form when editing dialing plan position in VSM or VSC.
Destination and id route defines where calls for given number will be send.
Destination description:
Id Destination Database table
0 External gateways Gateways
1 Internal gatekeepers ClientsE164
2 External gatekeepers Gatekeepers
3 PC2Phone clients clientshearlink
4 VoipBox (IVR) scenarios loaded dynamically in voipbox
5 Common clients clientshared
6 Enum route enumroots
7 Lookup lookups
Tech prefix stores value for part defined in VSM as Rules for modifying client's data. This text value has coded conversion rules for the dialed number, caller ID,
H323 ID before sending them to destination from VoipSwitch. It is quite complicated to manipulate directly those values but anyone interested can define some test
entry with valid conversion and later use it in these files (for import purpose). Examples of string manipulations are defined here
Call type value is binary coded and it defines dialing plan mode. Depending on which protocol is using specified route (SIP or H323) this value is differently encoded.
It is not recommended to modify it manually.
Type has coded definition of values defined in VPSconfig as Special properties. It shouldn't be modified directly but rather copied from existing row.
From day, To day, From hour and To hour values are used for defining time spans.
The last value, Balance share, is used for configuring Load balancing in the Dialing Plan.
4.8.2 Importing dialing plan entries
Import button
Of course file with export from the dialing plan can be used as import. But there is a feature which allows importing incomplete rows from file. The only one required
field is number. If other fields are empty ( for example '4877',,,,,,,,,,,,) the system will present a form to fill missing values before using file for import. This form is
the same as the one used with adding or editing dialing plan positions. Some parts are hidden or displayed depending which fields are in import file.
Filling missing information in dialing plan import
Only first row is checked while other rows are imported with values filled using this form.
Example of such incomplete row
'4877',0,,,'DN:9889',,,,,,,50,
This row will cause the system to ask about destination device and call type. These values must be picked up in a form. Other rows in this file will have the same
values except columns filled with not empty values like "Number", "Priority", "tech_prefix", "Balance share" where every value will be taken from appropriate row.
Only setting two comas without any character between them will cause asking about missing value. Space character or two apostrophies '' between comas
won't be taken as empty.
4.9 Least Cost Routing (LCR)

4.9.1 Applicability
The LCR function allows to greatly simplify management of a dialling plan composed of multiple entries assigned to various gateways. It may be, for example, that
when we receive new rates from carriers, to which we send the traffic, some of those rates will be lower than those offered by other carriers. Manual comparison of
tariffs composed of many entries and the subsequent search for appropriate records in the dialling plan may be difficult and - in case of frequent changes - quite
tiresome. The LCR function enables a very easy modification of priorities used in the dialling plan. The system automatically checks which gateway has the lowest rates
for a particular direction and makes this gateway used more frequently. This function is only used for records in the dialling plan that have the same number but a
different priority. It will not be applied to records 48 and 4, even though they both match the number 48774578988, since the more detailed numbers are used first.
For the same dialling plan numbers and the same priorities the load balancing service is used that requires to enter the percentage of traffic sent to each of the gateways
and the LCR function will not be applied here, as well.
4.9.2 Operation
This function operates by changing the priorities of gateways used in the dialling plan depending on the termination cost. At defined intervals, a special service checks
changes to tariffs assigned to gateways that are used in the dialling plan. The lower the termination cost the more frequently the gateway is used (lower value of the
priority field for this record, 0 is the biggest priority). In order for the LCR function to be used, there should be at least two records with the same number but a
different priority in the dialling plan.
Dialing Plan entries prepared for LCR
After adding two identical numbers with a different priority those records will appear in the Least Cost Routing menu. You should activate those records by selecting
them and clicking the Active LCR option. If you have more than two identical numbers with a different priority it is possible to activate all records or to leave some of
them inactive - they will be ignored.
_Activating the Dialing Plan entries for LCR _
All termination gateways used in the dialling plan should have the cost tariffs added, since the priorities are calculated based on them. The lower the rate the higher the
priority for a particular gateway. Gateways without the cost tariffs added should be inactive in the Least Cost Routing menu.
Assigning a Tariff to a destination Gateway
Calculations for LCR are made at certain time intervals, defined in Services -> Least Cost Routing. This module has to be active with the set time range. After making
changes to the cost tariffs, special functions compare the rates and determine a priority for the termination gateway.
Setting the Check Interval and enabling the LCR service
In the future we plan to combine the LCR function with dynamically calculated statistics. This will allow us to combine the price criterion and the quality. It will be
possible to configure the system in such a way that any change of priorities in accordance with the LCR will only apply to gateways for which ASR or ACD have their
values bigger than those defined.
The following conditions must be pass in order to proper work of LCR:
there must be at least 2 same prefixes set to different destination gateways (with calculate cost option enabled) with different priorities (cheapest
gateway must have higher priority - highest priority is 0) - at first time the priorities need to be set manually correctly in order from cheapest to
most expensive
dialing plan -> least cost routing the LCR function need to be activated on those prefixes
VSM->services->least cost routing service must be activated
dialing plan prefix must be equal to the destination cost tariff prefix (ex. dialing plan entry is 1 212 so in cost tariff must be a rate for prefix 1 212)
LCR will work only after change of the rate in cost tariff (ex. GW1 rate for 1212 prefix = 0.015 priority 0, GW2 rate for 1212 prefix = 0.02
priority 1 - after the LCR is activated (priorities are set properly because GW1 is cheaper than GW2 and has higher priority) we change rate in
cost tariff of GW2 to 0.01 then after the VSM->services->least cost routing check interval is passed the priorities should be reorganized for the 1
212 prefix)
Labels
dialing plan import export csv load balancing not jump calling modes
Children (10)
Automatic calls redirection to group of clients
Calling modes
Dialing Plan - Base informations
Dialing Plan - Special properties
Dialing Plan - Time span
Fields rules
Importing and exporting dialing plan data
Least Cost Routing (LCR)
Load balancing
Rules for modifying client's data
Comments (5)
READER says: May 19, 2008
Please explain how to work with lookups
Jaroslaw Marek says: May 20, 2008
Short description has beed added here
Kind regards,
Jaroslaw Marek
READER says: Aug 24, 2008
We have any option for blocking long and short numbers ??
More info on call modes, please.
READER says: Jan 13, 2009
I had request to have 2 different dialing plan for the same pin
How do I do it? for example 14082222222 calling to USA is routing to premium route while 0014082222222 is routing to LCR.
How do I enable it in the dialing plan? Please assist. Thanks
5.0 Tariffs - VoipSwitch documentation - VoipSwitch Dashboard Page 1 of 10
5.0 Tariffs
13 Added by Michal, last edited by Bartek Wrobel on Jun 28, 2010

5.2 Tariff parameters
5.2.1 Tariff name
5.2.2 Minimal duration
5.2.3 Resolution
5.2.4 Surcharge time
5.2.5 Surcharge amount
5.2.6 Tariff multiplier
5.2.7 Rate addition
5.2.8 Time span
5.2.9 Currency
5.3 Tariff prefixes
5.3.1 Description
5.3.2 Prefix
5.3.3 Voice rate
5.3.4 Rate multiplier
5.3.5 Rate addition
5.3.6 Grace period
5.3.7 Minimal time
5.3.8 Resolution
5.3.11 Disable prefix
5.3.12 Time span
5.4 Importing tariff prefixes
5.5 Changing tariff for clients
5.5.1 Caller ID
5.5.2 DNIS number
5.5.3 Using NPA function
5.6 Tariff comparer
5.7 Calculating cost of call by VoipSwitch
5.8 Effective rate
5.8.1 View rates defined for future
5.8.2 Define future changes
5.9 SMS tariffs

Tariff in VoipSwitch defines a set of paremeters used to calculate cost of a call. Every tariff is built of prefixes with assigned minute price for them. Few
parameters can be defined to whole tariff and some of them can be defined for specific prefixes. All tariffs are defined in one place and later a tariff can be
used for different purpose. Tariff can be assigned to:
any client defined in VoipSwitch to charge him for calling

gateway, SIP proxy or gatekeeper to calculate cost of termination
reseller of any level to calculate cost for him
for special usage like Tariff to DNIS or Tariff to ANI
Every tariff is defined the same way and only assigning them causes different usage.
A call will be connected only if the prefix of the dialed number exists in the tariff. All the dialed numbers without matching prefixes in tariff
table will be rejected. Prefix must exists in tariff assigned to a client, reseller (if client is assinged to reseller) or in tariff assigned to gateway if
calculating cost is set.
List of defined tariffs can be accessed by clicking Tariffs node in VSM or in VSC.
http://docs.voipswitch.com:8080/display/VDoc/5.0+Tariffs 10/16/2010
After you click it, a list of tariffs is presented on screen.
5.2 Tariff parameters

Every tariff is identified by it's name and a set of parameters used to calculate cost of calls.
5.2.1 Tariff name

Every tariff has to have it's now unique
name. It is visible for VoipSwitch
administrator on VSM and VSC as well as
for clients on VSPortal or for resellers on
VSR. Tariff name under VSPortal
5.2.2 Minimal duration

This value is used to define minimal time a client will be charged for after connection. Even if the call is connected and disconnected after few seconds
the client will be charged for the set minimal time. Resolution steps required to cover minimal duration will be used to calculate cost. If resolution is 6 and
minimal time is 40 then minimal time will be 7 billing steps because 7*6=42 seconds.
5.2.3 Resolution
Every rate assigned to prefix is per one minute. Tariff definition allows to charge clients for shorter periods starting from 1 second to any number of
seconds. Resolution is a parameter which is used for that. Value of resolution is specified in seconds and defines what part of a minute price should be
added to cost of a call. For example when it is set to 6 it means that every 6 seconds one tenth of the minute price will be added to the cost of a call.
Resolution can be set to any value but for clear calculation it should have a value which exactly divides number 60.

This value defines initial time of a call time in seconds which can be charged with surcharge amount. Remaining time of the call will be charged using other
rules described in minimal time and resolution. When surcharge amount is set to 0 then initial time of a call time defined in surcharge time will be free for client.
For example when surcharge time is defined as 10 and duration of a call was 60 then surcharge amount will be added to the cost of a call and the rest of 50
seconds will be calculated using minimal time and resolution.

Amount added at the begining of each call is defined by surcharge time. If surcharge time is set to 0 then it will work as connection fee for any connected
call. After the Surcharge time expires the billing starts as if it is the beginning of the call.
For example if the Surcharge time field is 10 seconds and Surcharge amount is 0.1 then the first 10 seconds of each call will be charged with 0.1 and only then the
normal billing will start.
5.2.6 Tariff multiplier

Using this option allows rates visible by a client to be changed during the call. Until the client recalculates cost of a call manually he will not be aware of it.
After logging to the VSPortal client can only see bare tariff rates.
Rate multiplier is changing cost of every rate by multiplying it by the set value.
Examples.
If it is set to 1.1 every rate will be 10% higher than client can see on the web.
Value 0.8 will decrease every rate by 20%.
5.2.7 Rate addition

Similar to tariff multiplier but instead of multiplying it adds some value to every rate.
Tariff multiplier is applied before Tariff addition when both enabled.
5.2.8 Time span

When this option is checked it allows to define different rates used for different days or hours. Unchecking this option makes setting the tariff easier and will
speed up cost calculation.
If you would like to setup some rate for hours crossing the midnight (ie 8.00PM - 6:00AM) you shouldn't add this rule in one stage. Insted of
this add two rules (first one: 8:00PM - 12:00PM, and second one: 0:00AM - 6:00AM).
5.2.9 Currency
With this option different currencies can be assigned to the tariff. More informations about currencies can be found here
5.3 Tariff prefixes

Prefixes defined for a tariff are presented on screen after clicking tariff name.
Prefixes are assigned with rates and descriptions. Tariff can have any number of prefixes defined in it. The same as in dialing plan longer ( more detailed )
prefixes matching dialed number are taken first before shorter.
Examples
Descriptions defined in every prefix should be filled properly because they are used later in detailed billing, on client web CDR page or in Reports. The same
description can be used for different prefixes and later can be used for more general grouping. For example 486 and 485 are Poland mobiles however with
different cost. Later in summary we can see it grouped by description and see how many calls went to polish mobiles.
If price is the same for many similar prefixes it must be considered if it cannot be replaced with one more general prefix. Tariffs with smaller
number of prefixes are easier to manage and with higher traffic can be processed faster.
Examples
For every prefix some parameters can be set to modify calculation of cost. Some parameters are the same as for tariff. If such parameter has value higher
then 0 it will be used instead of the one defined in tariff. It allows to set different value for specific prefixes.
Prefix properties
5.3.1 Description
In the "Description" field can be put some text that the client will see while calling from one of VoipSwitch's dialers, viewing rates, browsing calls made or
on the billing.
Few examples of the "Description" utility
5.3.2 Prefix
Prefix (phone number) that the preferences will be applied to.
5.3.3 Voice rate

The cost of one minute of a call to the specified prefix (phone number).
5.3.4 Rate multiplier

See tariff multiplier defined for tariff.
5.3.5 Rate addition

See rate addition defined for tariff
5.3.6 Grace period

This option is used to enable making the costless calls of specified period. If any connected call is shorter then this time it will appear in CDR with 0 cost.
Calls longer then this time will be billed normally with the whole duration including the grace period.
5.3.7 Minimal time

See minimal duration defined for tariff.
5.3.8 Resolution
See resolution defined for tariff.
See surcharge time defined for tariff.

See surcharge amount defined for tariff.
5.3.11 Disable prefix

Any number which matches this prefix will be blocked from processing. System will reject such call.
This option is similar to the one that can be found in dialing plan used to block some prefixes.
5.3.12 Time span

Values set in this section defines in which days of a week (From day, To day) and between what hours (From hour, To hour) the prefix with specified
properties will be used.
Values set there defines when the prefix will be used. It is possible to define from which day of a week to which day and between which hours this prefix
will be valid. Below is an example of how it should be set to have off-peak and on-peak rates.
Example
5.4 Importing tariff prefixes

It is possible to import the tariff rates from a CSV file. For this you will have to prepare the file in the following specific format (order of columns):
Prefix, Description, Rate, From Day, To Day, From Hour, To Hour, Grace Period, Minimal Time, Resolution, Rate Addition, Rate Multiplier, Surcharge Time, Surcharge
Amount
Be sure you don't have column names in the text file, and the fields are comma-separated ( , ) or semicolon-seperated ( ; ). The file should not
contain comments or column headers and data should start from the first row.
Usually you can work this rate file in Microsoft Excel or Open Office and save it as CSV.
The file should look like this:
93,AFGHANISTAN,0.2243,0,6,0,2400,0,0,0,-1,-1,-1,-1.0000
4795,NORWAY - zz Mobile Teleno,0.1938,0,6,0,2400,0,0,0,-1,-1,-1,-1.0000
47960,NORWAY - zz Mobile Teleno,0.1938,0,6,0,2400,0,0,0,-1,-1,-1,-1.0000
You can also import tariffs from files that had tariffs exported before. Please note that if you are importing Tariff using Web Config the fields
in the CSV must be seperated with semicolon ( ; ), not comma ( , ).

When the file is ready it can be uploaded into the server. Import of such file can be performed in VSM or VSC by pressing the Import button.
Importing the tariff
You will be asked to select the text file. After pointing the csv file with tariff date the import process will be started. If some fields have been left empty
VSM will ask for filling it and VSC will display Error list screen.
Importing the tariff - missing fields
If the import process fails VSM will interrupt it and display the error message.
The records from the file will be added to the existing records in the tariff. You must remove the existing records before importing if you want to replace
them. There is a Remove all button that will delete all rates in that tariff for your convenience.
Removing all tariff entries
5.5 Changing tariff for clients

Client can have one tariff assigned to him but there are a few ways to change such tariff depending on information sent to VoipSwitch. This change can be
done:
because of Caller ID
because of called number
using NPA function
5.5.1 Caller ID
This mode can be used only with IVR clients or common clients working as IVR.
This function is named Tariff to ANI and is used only while providing the calling cards service.
Every reseller can set different rules for his clients on how tariff should be changed depending on the number the call is comming from.
Tariff to ANI function is changing tariff assigned to a client to some other depending on caller ID coming to VoipSwitch. It can be used to differentiate cost
of calls when client is calling from abroad.
Tariff to ANI detailed description
5.5.2 DNIS number

Using this feature tariff is changed depending on the called number. In VoipSwitch Manager it can be found under Tariff to DNIS name. It is usually used
in calling cards service. Typical scenario is to set different number for calling cards and then depending on different tariffs it will be used to charge clients. One
number used to call to IVR system can be toll free and other charged for every connection. Only by using this feature we can differentiate tariff used to
charge the same client.
Detailed description how to set it is described here.
5.5.3 Using NPA function

This function allows a user to change the tariff depending on the number that is dialed and the number that makes the call (using Caller ID).
This function is exceptionally useful in the USA, where there is a need to change the tariff not only on the basis of the state called but
also on the basis of the state the call is made from. A simple comparison of numbers is not enough, so there has to be a special table, that links places with
codes.
In the Others section the NPA Numbers table with a Location (name) linked to it can be found.
Filling the NPA Numbers table
To add new entries into the table simple CSV file will have to be prepared first. Format of such file looks like below:
NPA Number;Location;
When the file is ready it can be easily imported using the Import... button.
Location of NPA Numbers under VSM
Procedure of tariff change:
1. The user calls a number that begins with a certain string of numbers.
2. The system checks which Location has such number assigned.
3. After finding the Location the system compares the beginning of the clients Caller ID and if it is assigned to the same Location it
uses the Intrastate Tariff.
4. If there is no match the Interstate Tariff is used.
Definition of Interstate and Intrastate tariff is available on dialog window which appears after checking the Choose tariff according to box and pressing the
Rules button. After clicking it the Tariff rules window will show up where rules for choosing tariffs can be configured.
Applying Interstate/Intrastate tariff to the client
5.6 Tariff comparer

This feature is available under tariff node.
Tariff comparer is used to compare 2 tariffs. Working with traffic and clients requires many tariffs, prefixes and rates. Mistake in one rate can cause big loss for
VoipSwitch owner so it is very important to check every tariff before assigning it to the clients. Tariff comparer is one of features available in VSM application.
It is possible to chose two tariffs and define criteria for comparing tariffs. If one tariff should be lower, higher, equal then any rate in the other it can be
chosen in the compare operator combo box. It is possible to define how much bigger or smaller it should be by specifying the percent value by which every rate
from the Tariff 2 will be multiplied while comparing tariffs. Matching prefixes are listed in output window and can be modified. Tariff comparison is more
complex and works in a similar way like finding prefix in tariff made by VoipSwitch. If the prefix in tariff is not the same the best matching entry is taken to
comparison.
Bear in mind that comparing tariffs with many records can take relatively long time.
The Tariff Comparer feature
Example shown in figure above displays only prefixes from tariff TestTariff which are higher than 20% of appropriate prefixes from TestTariffHigh.
Value from Tariff 2 voice rate is used to multiply prefixes from Tariff 2.
Examples
5.7 Calculating cost of call by VoipSwitch

Below is a diagram describing cost calculation made by VoipSwitch.
5.8 Effective rate

Since version 1.9.3.0 VSM has this option available in services.

Effective Rate service needs to be turned on to use Define future changes option in tariffs. Check interval describes how often the service will check future
tariffs entries.
Effective rate feature options
5.8.1 View rates defined for future

In the VoipSwitch
Manager under
Tariffs a filter option
to display current
tariffs or future
changes can be
found. Using it VSM Future changes filter under Tariffs
can display all
changes defined for
tariffs to be applied
in the future.
5.8.2 Define future changes

In order to define future changes in the tariff the "Define future changes" button has been added.
Displayed form allows to choose if the future change should be based on old tariff (Copy data from base tariff) or a new (empty) one (Create empty
tariff).
Defined changes will be applied at the time specified in the Time to take effect fields.
Defining future changes in the tariff
This feature needs "Effective rate" service to be enabled.
5.9 SMS tariffs
Every tariff has two sets of rates - Calls and SMS.
Switching tariff rate-sheet between Calls and SMS
SMS tariffs are managed in the same way as voice tariffs however list of parameters is quite shorter.
Description - description for the prefix - usually name of country and(or) network,
Prefix - prefixes are specified with rates and descriptions. Tariff can have any number of prefixes defined in it. In the same way as in the Dialing Plan
longer (more detailed) prefixes matching the dialed number are taken before shorter ones,
Voice rate - cost of sending one SMS message,
Rate multiplier - client can see his tariff rates and prefixes on the web page after logging. Using this option allows rates visible to a client to be
changed but the client won't be aware of it until he recalculates cost of the SMS manually. Rate multiplier is changing cost of every rate by multiplying
it by this value,
Rate addition - similar to Rate multiplier but instead of multiplying it adds some value to every rate. Rate multiplier is applied before Rate addition when
both enabled,
Disable this prefix - any number which matches this prefix will be blocked from processing. System will reject such SMS message,
Time span - when this option is used it allows to apply different rates for different days or hours.
SMS tariff options
Labels
tariff prefix rate surcharge multiplier addition resolution minimal grace period day hour caller id clid ani dnis npa import comparer
Children (10)
Changing tariff for clients
Define future changes (Effective rate)
SMS tariffs
Tariff comparer
Tariff import
Tariff parameters
Tariff prefixes
Tariffs - Base informations
Tariff to ANI
Tariff to DNIS
6.0 Browsing calls, reports, statistics, payments - VoipSwitch documentation - VoipSwitc... Page 1 of 5
6.0 Browsing calls, reports, statistics, payments
8 Added by Michal, last edited by Bartek Wrobel on Aug 10, 2010

6.2 Calls
6.2.1 Time shift
6.2.2 Export
6.2.3 Grouping calls by client type
6.2.4 Resellers calls
6.3 Failed calls
6.4 Reports
6.4.1 Exporting the reports
6.5 Statistics
6.6 Payments

Calls connected through VoipSwitch or failed are available to browse in VSC and VSM application. Any call can be traced using date, client, calling number and other details. It is possible to see summary reports
with charts about gateways usage, popular directions and many others. Statistics can help to choose best destinations and modify dialing plan according to such knowledge. Browsing payments made by client help
solve misunderstandings.
6.2 Calls
History of calls connected successfully through VoipSwitch is available in this part. It is possible to filter calls by:
Date and time - it is possible to see calls made only in given time. There are helper periods available as Today, Last week, which allow to define exact date interval,
Called number - destination number dialed by a client,
Caller IP - ip number from which the call was received, starting characters can be used for filtering,
Caller ID - caller id from which the call was made, starting characters can be used for filtering,
Duration - duration of a call, it can be defined with comparison operators like <, > or = to list calls with duration less, greater on equal of the defined value,
Cost - similar to duration but describes revenue calculated for a client,
Tariff - tariff used to calculate revenue for clients,
PDD,
Route - destination used to terminate calls,
Time shift - described below,
Calls/SMS - combo-box which allows to switch between listing calls and SMS messages.
Origin Call ID - sequence of characters representing the call,
Termination Call ID - sequence of characters representing the call.
Working with filters, saving them, sorting columns and context menu are described in section Common UI elements
Main calls window with simple filter
It is possible to use a few criteria to see only specific calls. After clicking Apply filter button the list of calls will be refreshed with filtering conditions. Below grid with calls summaries are calculated for the filtered
set of calls. Informations available in summary section are:
Total revenue - summary of revenue calculated for clients,

Avarage revenue - average revenue for all filtered calls,
Total duration - total duration for given set of records,
Average duration - average duration for calls,
Total cost - summary of cost calculated by tariff assigned to destinations, if tariff is not set at the cost 0,
Average cost - average cost of calls,
Total profit - summary of profit which is calculated by subtracting the total cost from total revenue,
Average profit - average profit for every call,
6.2.1 Time shift

This option allows to show result using time shift. The value is set with hours and allows to modify call_start and call_end columns by adding hour value set there. It is useful when comparing calls made to the
VoipSwitch with the same calls received from the carrier while they are not in the same time zone.
http://docs.voipswitch.com:8080/display/VDoc/6.0+Browsing+calls%2C+reports%2C+st... 10/16/2010
Using time shift option
6.2.2 Export
Calls displayed in the list can be exported to CSV file. It is coma delimited and can be easily opened in Excel, OpenOffice or Notepad. You may choose columns to export if it suits your needs. After choosing
export file the the window with exported columns selection is displayed. It can be chosen which columns should be exported.
Customizing calls export
6.2.3 Grouping calls by client type
Calls node can be expanded to show

calls made by specific type of clients.
If filtering with the client's login exact
name has to be put into the Login
field. Otherwise no data will be listed.
Other filtering fields are the same.
6.2.4 Resellers calls

Special part of calls is availalble for resellers. It is possible to see calls made by every reseller on every level. Filtering by date is also available.
Resellers calls filters set
6.3 Failed calls

It is possible to filter failed calls by:
Date and time - it is possible to see calls made only in given time. There are helper periods available as Today, Last week, or from which allows to define exact date interval,
Called number - destination number dialed by a client,
Caller IP - ip number from which call was received, starting characters can be used for filtering,
Caller ID - caller id from which call was made, starting characters can be used for filtering,
PDD,
IE Error, Reason - fields which are displaying the number that represents the cause of the failed connection,
Route - destination used to terminate calls,
Time shift - described below,
Calls/SMS - combo-box which allows to switch between listing calls and SMS messages.
Origin Call ID - sequence of characters representing the call,
Termination Call ID - sequence of characters representing the call.
Working with filters, saving them, sorting columns, context menu is described in section Common UI elements
Failed calls with simple filter options
Clicking on every row of failed calls loads the form below the list. Values there are similar as in the list but for IE error and reason there are explanations of errors which can be useful for finding issue on
destination gateway.
In the form below additional fields are:
Client login
Client type
Route type
IE Error description
Release complete reason
Origination Call ID
Termination Call ID
Failed calls detailed form
6.4 Reports
This section is used to see reports for calls made. It is possible to group and filter depending on different criteria. For grouped record it can calculate:
Sum - calculate revenue for clients,

Profit - profit as difference between cost of termination and revenue paid by client or reseller,
Average - average duration and profit,
Count - count of calls.
Reports window with simple example
Grouping allows to see sums for chosen client, period of time and other options. Below is a list of possible grouping:
Clients type and name - when client type is choosen it will show record grouped by logins from the chosen type. Using such report can be helpful to see the most profitable clients. By typing the client's
login in the Login field reports for specific client can be listed. Grouping by client's login can be used only when client's type is selected,
Route type and name - when only type is chosen the system will show how traffic is divided between different destinations. With route name it can be narrowed to the particular destination,
Date - it can be set period for which the reports should be generated,
Period - allows to group reports houry, daily or monthly,
Resellers - when reseller of any level is chosen the system will show how traffic is divided for every one of them,
Group by Country - using this grouping it can be viewed which countries and regions are the most popular. Visualization of this report is available in pie chart,
Group by Prefix - in comparison to country or region reports can be grouped by specific prefix, for example the same region description can have many prefixes so this option will give the more detailed
result,
Time shift - it has been described here.
Different criteria can be joined together to help generating the desired report.
Example
Choosing many groupings can result in high CPU usage and long operation. It is better to limit time for which such report is being generated and use grouping with caution.
For some reports the charts generation is available. Grouping by country makes it possible to see as pie chart countries chosen by clients. For every reseller level it can be presented on a chart how big the usage of
every reseller in total traffic is.
Examples of charts generated from reports
6.4.1 Exporting the reports

Every generated report can be exported to CSV file format. This format can be opened using MS Excel, OpenOffice or simply by Notepad.
Steps of exporting the reports
The "Export" button can be found over the list of reports. Clicking it will display the window where the file name and destination folder can be set. After pressing the "Save" button the user will be prompted
which columns should be included in the exported file. In the next step the export is performed.
Exported file format

Date;Reseller;Route;Client;Route name;Country;Prefix;Sum duration;Revenue;Avg. duration;Avg. cost;Count;Date;Cost;Profit;Profit res.;Cost res.;Profit from res.;
6.5 Statistics
In this section informations from calls made and failed are used to calculate statistics. It are useful to check the quality of gateways. Values available are:
ASR,
Number of calls made, calls failed,
Average, total, the shortest, the longest and median of duration,
Best, worst, average and median of PDD.
Statistics screen
Statistics are calculated depending on defined filters:
Date and time period - except of days it is possible to define period in hours,
GW clients - it can be chosen for which GW Client statistics should be calculated (mostly used in wholesale),
GK/Registrar clients - this option works the same as the above one but is applied to GK/Registrar Clients,
External gateway/gatekeeper - similar to the User filters it can be specified which gateway or gatekeeper should be included in the statistics.
Pressing the "Apply filter" button will fill the list below the filters pane with calls and failed calls according to filters selected. Clicking "Calculate statistics" will trigger the statistics calculation procedures and display
results at the bottom of the "Statistics" window.
6.6 Payments
This section is used for browsing the clients payments. As usual the result list can be filtered according to requirements. Filters are similar as in other sections and additionally it can be specified whether the
remaining funds, balance and/or credit should be larger, smaller or equal to the specified value.
Payments browser in VSM
Children (5)
Reports
Statistics
Statistics - Calls
Statistics - Failed calls
Statistics - Payments
Comments (3)
READER says: Feb 24, 2008
Could someone please explain what does the new Feature exactly made for ? is it for alerts ?
please explain more about this feature.
READER says: Aug 07, 2008
How can we exports all calls for any client easily? both successful and failed calls.
Why cant I export from statistics screen ? I have to see all calls failed and succesful together
7.0 Settings - VoipSwitch documentation - VoipSwitch Dashboard Page 1 of 17
7.0 Settings
11 Added by Michal, last edited by Bartek Wrobel on Aug 17, 2010
Introduction
7.1 VoipSwitch
7.1.1 Call settings
7.1.2 Authorization
7.1.3 Miscellaneous
7.1.4 Rerouting calls
7.1.5 Ending calls
7.1.6 Settings for saving failed calls
H323
H323 listeners
Other ports
Gatekeeper
Authorization
SIP
SIP listeners
Registrar
Other
PC2Phone
Pc2Phone listeners
Callback
Callback listeners
SMS Callback listeners
Additional settings
Regular Callback
Callshop
Callshop listener
Callshop's web page addres
VoipBox
Listener
Other settings
Time multipliers
Invoices settings
Mail settings
SMTP settings
Custom fields
Introduction
Settings are used to define parameters for VoipSwitch main system and for few modules. After clicking Settings node in VSM application it will expand and show
different sections as shown on figure.
After changing most settings, VoipSwitch should be restared or at least start command Reload VSM data.
7.1 VoipSwitch
http://docs.voipswitch.com:8080/display/VDoc/7.0+Settings 10/16/2010
VoipSwitch settings view
Settings defined there are used mostly by VoipSwitch, every change there has an influence on VoipSwitch behaviour and efficiency. Any change made here should be
done carefully and with full awareness of possible effects. If not sure ask VoipSwitch support.
Parameters here are divided into 5 sections:
7.1.1 Call settings
Call settings panel
Limit ring time - value given in seconds allows to define when call will be abandoned in case of no answer. It is useful to set some value there to avoid endless
calling and enable calls redirection triggering.
Limit call duration - with this option limited maximum call duration - value in minutes of longest possible call.
Use media timeout - special timeout used to disconnect both sides of conversation when media packets are not coming from one side during this time. It will
work only in full proxy mode when media packets are coming through the VoipSwitch.
Limit number of hops(re-routing policy) - it can be limited how many hops should be tried before ending a call. Normally it is unlimited. If there are
matching prefixes defined in dialing plan, all of them will be tried. This parameter allows to limit it.
Guest account - account used to authorize calls by default is not set to any client. Without this option set all unauthorized calls would be rejected. When it is
set calls will be authorized and billed for this client.
Any option changed before it will be used by VoipSwitch must be saved and settings must be reloaded. It can be done by clicking right mouse button on
Calls window of VoipSwitch and choosing from context menu command Reload settings. After executing this command new settings should be applied
to the running VoipSwitch.
7.1.2 Authorization
Authorization settings panel
7.1.3 Miscellaneous
Parameters set in this section turn on and off functions available with VoipSwitch. If any of them is not used it should be unchecked and it can improve VoipSwitch
effciency.
//
Miscellaneous settings
Use common clients - when unchecked common clients will not be able to call through VoipSwitch.
Save active calls in DB - when checked it will save information about connected calls to special database table. It is presented through VSC pages or limited
version for resellers in VSR.
Use load balancing - when checked load balancing is available in dialing plan.
Use resellers - if this is unchecked VoipSwitch will not calculate any cost for reseller of any level. It will also not substract any value from their account. It can
cause some problems if unchecked by mistake because all calls made by resellers clients won't be assigned to resellers.
Use time spans in DP - when checked it is possible to define time span for dialing plan positions.
7.1.4 Rerouting calls
Rerouting calls allows to find different gateways for dialed

number if for any reason a call cannot be connected.
VoipSwitch is set by default to reroute all calls no matter
what error code is received from termination gateway.
Sometimes it can be required to stop rerouting calls so calls
can be treated as failed faster then waiting for trying many
gateways. Good example is error "User busy". This message
is returned when dialed number is busy. There is no sense
in finding other gateway because it will still be busy.
Using this dialog can be an added option allowing not
to reroute when such error will be received on VoipSwitch.
Similar rules can be added for every error returned by
gateway. Rules set here are applied to all numbers defined in
dialing plan.
Settings for rerouting calls
7.1.5 Ending calls
Ending calls settings
For some errors specific for VoipSwitch it is possible to define error number sent to SIP and H323 clients.
It is important to set it for both protocols for every reason.
Possible reasons which could happen in VoipSwitch are:
Destination off-line - it can happen when defined gateway is behind firewall or there is a mistake in IP address for such destination.
Number doesn't exists in dialing plan or tariff - it will occur when for dialed number a dialing plan entry or prefix in tariff couldn't be found.
Unauthorized call - VoipSwitch denies call processing because of unauthorized request, IP not added, wrong login and password sent.
Codec problem - codec used by a client doesn't match a list of available codecs in client definition.
Unknown reason
Channels limit - number of allowed channels for client or gateway exceeded.
Second part of these settings is for changing error numbers received from destination and passed to clients. Default behavior is to pass it unchanged but using these
settings it is possible to replace one error number with another.
There are two buttons which allow to chose error number. One is Gateway end reason and number set there will be replaced with End reason sent to client. After
clicking button rule it will be copied to text box on the right and for next calls matching Gateway end reason it will be replaced.
Adding error number replacing rules doesn't require restarting VoipSwitch.
7.1.6 Settings for saving failed calls
Settings for saving failed calls
Calls failing because of VoipSwitch misconfiguration are not stored by default in database. It was built in this way to avoid counting such calls for general statistics like
for example ASR. Sometimes in order to have more extended information about such calls it is possible to turn on saving them in failed calls. Every error presented on
screen above can be checked to be saved in database in general failed calls table.
H323
This section deals with setting H323 listeners, ports, gatekeeper and authorization of H323 devices.
H323 listeners
Listeners are needed for clients to connect to server. Server is listening on it's IP (it may be one or more IP addresses, but according to our experience no more than 5)
for clients to connect. You may setup H323 listeners in section shown on Fig.1.
Left box (Available computer addresses) is showing all IP addresses assigned to server network adapters. If you wish to choose one of them to be used for clients to
connect just select one and add to the second box by clicking ">" button between boxes. There is one IP address (79.187.62.139) chosen on example Fig.1.
Every VoipSwitch executeble file is prepared to operate on fixed IP addresses list.

If a server has more than one IP one should make sure that VoipSwitch is able to work with all of server's IP addresses. VoipSwitch needs global IP
address to function properly. It is impossible to use VoipSwitch on Private IP addresses.
H323 listener has default port 1720. If you wish to add more ports just choose one and click green "+" (plus) button. Newly added port will be listed above (H323
listener ports list shown on Fig. 1).
If VoipSwitch is unable to start one or more listeners check if some application is not using this port already. Click here to read more
Fig.1 H323 listeners section
If you add more H323 listener ports, VoipSwitch will listen those ports on every choosen IP address.
After changing listeners IP addresses or ports you have to restart VoipSwitch or at least listeners.
Other ports
This section has only two fields. You may choose starting UDP ports of media and gatekeeper's RAS. Default settings are 6000 for UDP media and 1810 for GK's
RAS and shouldn't be changed without a reason.
Fig.2 H323 other ports section
Gatekeeper
This part of H323 settings allows you to assign IP and port for VoipSwitch Gatekeeper. Choosing IP address and port is similar to H323 listeners. Default gatekeeper
port is 1719.
Fig.3 H323 gatekeeper section
Authorization
Authorization section allows to turn on or off user login option by H323 ID. H323 login consists of login, password and separator. By default separator is at (@) sign
and H323 login looks like: username@password
Fig.3 H323 authorization section
H323 user and password separator may be changed in this section. Default settings are shown on Fig.3.
SIP
Whole SIP Settings window is shown on this picture (click to view).
SIP listeners
Listeners are needed for clients to connect to server. Server is listening on it's IP (it may be one or more IP addresses, but according to our experience not more than
5) for clients to connect. You may setup SIP listeners in section shown on fig. below.
Similar to other listeners (H323, PC2Phone, etc.) consider that every VoipSwitch executable file is prepared to operate on fixed IP addresses list (or single IP -
depending on server configuration). Make sure that all server IPs are recorded in our CRM to avoid VoipSwitch failures.
SIP listener has default port 5060. If you wish to add more ports just choose one and click green "+" (plus) button. Newly added port will be listed above (SIP listener
ports list shown on previous fig.).
If VoipSwitch is unable to start one or more listeners, check if some application is not using this port already. Click here to read more
Registrar
This part of SIP settings allows you to assign IP and port for VoipSwitch Registrar. Choosing IP address and port is similar to SIP listeners. Default registrar port is
5060.
Other
In this section you can setup Realm and User-agent for SIP protocol.
Default settings (empty) are shown below:
In this situation Realm will be "VoipSwitch" and user-agent will be "VoipSwitch 2.0"
PC2Phone
PC2Phone settings are limited only to listener configuration.
Pc2Phone listeners
Under Settings/PC2Phone Settings
Listener is needed for PC2Phone clients to connect to server. Server is listening on it's IP (it may be one or more IP addresses, but according to our experience not
more than 5) for clients to connect. You may setup PC2Phone listeners in section shown on fig. below.
PC2Phone listener has default port 1800. If you wish to add more ports just choose one and click green "+" (plus) button. Newly added port will be listed at
"PC2Phone listener" section.
Callback
Whole Callback Settings window is shown on this picture.
Callback listeners
Callback listeners are needed for Callback function to work. Server is listening on it's IP (it may be one or more IP addresses, but according to our experience not more
than 5) for Callback trigger informations.
Similar to other listeners (H323, PC2Phone, etc.) consider that every VoipSwitch executeble file is prepared to operate on fixed IP addresses list (or single IP - depends
on server configuration). Make sure that all server IPs are recorded in our CRM to avoid VoipSwitch failures.
Callback listener has default port 1801. If you wish to add more ports just choose one and click green "+" (plus) button. Newly added port will be listed above (SIP
listener ports list shown on previous fig.).
SMS Callback listeners
SMS Callback listeners are needed for SMS Callback function to work.
SMS Callback listener has default port 1802. If you wish to add more ports just choose one and click green "+" (plus) button. Newly added port will be listed above
(SIP listener ports list shown on previous fig.).
Additional settings
There also can be checked additional options for callback:
Charge calls only when both legs were connected - if set failed callback calls will not be charged at all. When VoipSwitch owner has to pay for callback call
this may cause money loss and has to be used with care,
Do not ask for number after leg B has ended - if the call is ended using "End call string" (which can be found in VoipBox settings), or if destination ends
the call, the caller won't be asked for choosing another number.
Regular Callback
In the section Callback one sets parameters of Callback listeners. Default values should work fine, so do not change this settings without a reason.
Regular Callback Settings should be configured to fit one's needs.
Regular Callback settings node in VoipSwitch Manager.
In this program there are 4 groups of settings:
Common,
ANI Callback,
PIN callback
DID callback
Typical configuration
All parameters set here are subsequently used by a twin program which functions as a service in the Windows system and is called "Calls Reader Service".
One should remember that after every change the service "Calls Reader Service" should be re-started (in order to download new settings).
The purpose of the section Common is to determine the settings used by the Service "Calls Reader Service" to connect to VoipSwitch. One should set the IP number
of a server where VoipSwitch functions and the port are used as SMS Callback (by default it is port 1802).
The parameter "Checking interval" determines the frequency - how many seconds the service "Calls Reader Service" checks for new connections with the number
which activates callback. If this parameter is too big, the period of waiting for calling back will be to long; if this parameter is too small, the user may not have enough
time to answer the call or the system may work too slowly.
From experience it is known that the optimum time is 3-5 seconds.
After finding out in the database table "CallsFailed" about an attempt to connect with the number which activates callback, the Service "Calls Reader Service" collects
"Caller ID" and sends the information to VoipSwitch in order to try and execute a connection. The time after which this information is sent is known as "Sending
delay".
At the initial phase of using this service, one may select the option "Make logs". This option enables recording additional information about the
functioning of the service "Calls Reader Service" in the Windows system logs. Later this option may be switched off.
The purpose of the section ANI Callback is to define the number which activates callback and the numbers which the "Caller ID" will be connected with. It is possible
to define one or several numbers. (It is not recommended that more than 5 numbers should be defined as this may slow down the functioning of the system). If more
numbers are defined which activate callback and more than one number in the table 'IVR numbers', the appropriate number of the table 'Numbers' will be connected
with a number in the same position in the table 'IVR numbers'.
A part of ANI Callback is used for the clients who activate callback only from the numbers authorised earlier.
See register option for more information about saving authorised numbers.
Section PIN Callback is used during the execution of callback connections when "Caller ID" is not recognised. This option may be switched on and off with the check
box "Check PIN if ani couldn't be found". Now it is necessary to verify a user who will be used to execute return connections, in the section "Client callback".
It is necessary to select a user in the section PIN Callback from the list "Client callback", but the user will not bear any costs unless the PIN authorisation
is used.
Defining the numbers and the IVR numbers assigned to them is similar to such defining in the case of ANI Callback.
One must remember that a number defined in the table 'IVR numbers' should indicate the PIN action of the system IVR.
Typical configuration of callback should allow client to call did number and receive call asking about pin number. After successfull authorization using pin, caller id
should be added to client account. Next time when client will call from this caller id his call will be authorized without asking about pin.
To configure it in this way 2 DID numbers are required. Both of them should be set to end on not existent gateway or play file scenario. One number will be defined
in ANI section and PIN section of regular callback and point in ANI to IVR scenario asking only about number ( without pin ). The same number should be defined
in PIN section and go to
IVR scenario asking about PIN. Second from DID numbers should be only defined in PIN section and point to number assigned with scenario PIN+Register. Client
will call this number only when he will want to authorize his caller id. When he will finish one card and will want to use new, he will also call second number to get
rewritten his caller id ot new card. All other calls he will do for first number and when caller id is register he wont be asked about pin.
Section DID Callback. This type of callback allows this service to work even when the "Caller ID" is not transferred to the system VoipSwitch. In this type, each client
is assigned a unique number to which the client calls. The call is not connected as in the case of other callback calls but the system, on the basis of this target number,
calls back to a previously defined number assigned to this client. All target numbers defined for clients must start with a common prefix (see Fig. 4, number 2000 in the
"Dialing plan prefix"). In the same location, one defines the number the clients will be connected with (number 777 entered in the dialing plan). This is a number for
the IVR action of the system VoipSwitch. This is an action of the type "Ask for number" because the clients do not require authorisation. Calling a specific target
number triggers the connection of a particular client number with the number assigned to the IVR action.
There is no need to call from specified number (as before), so Client is able to trigger callback call from any phone device, the system will call back to specified
number assigned to this Client .
When adding DID callback prefix use number that is not used in any of existing dialing plans or add dedicated dialing plan entry for this prefix and route
to offline gateway as before
Assigning the activating numbers and the numbers to which the callback will be executed for individual clients may be done in the window which appears after
pressing the button "Clients DID numbers".
DID numbers window.
In the left part of this window, there are the already assigned activating numbers together with relevant users and the numbers which will be used to connect with a
client. In the above image, in the first line there is information that if a call to the number 2000 1 is executed and is not connected, then the system should call back as
the callback client of the login "800123" to the number 800123 and then connect this call with the number 777 defined in the previous window. The numbers DID,
presented here, constitute only the last part of the activating number (in this example just "1" for number "20001").
Callshop
Callshop listener
Default port used for callshop is 1804. Using this part of settings it can be set IP on which listener for callshop will be started and also this default port can be changed
to some other value. It cannot be used for port number already occupied by other application. After changing port or IP of callshop listener VoipSwitch application
must be restarted. This change must be reflected also in callshop.ini file located in callshop working directory. In NETWORK section of this file parameter
SERVER_PORT=1804 should be modified.
Callshop's web page addres

Valid address of Web or Portal module should be set. This link will be used to show calls history and other details about callshop client within callshop application.
It opens automatically when clicked on Web tab in callshop application. Format of such link is:
http://server.ip/Portal or
http://server.ip/Web/
server.ip should be replaced with the IP address or domain name of the server that has the module installed.
VoipBox
Any parameter used by Voipbox can be set in VSM application after clicking node VoipBox in Settings part.
Parameters defined here are used by VoipBox and in general are taken only when it is starting. Any change made to them requires restarting
VoipBox application. Exception of these parameters are time multipliers where defined parameters can be changed without restarting VoipBox.
Listener
Use VoipBox - determines if VoipBox is used or not.
VoipBox IP Address and Port - enter here a valid IP number and port number of computer running VoipBox application.
Other settings
Maximum number length - Determines limit of digits in dialed number.
Non activity timeout - Determines the time in seconds, after which the VoipBox will send the dtmf selected by a user to the VoipSwitch system. If nothing has been
entered, the system will repeat its request to enter the pin number or the telephone number we wish to be connected to.
Finish key - A person making a call into the IVR system is asked to enter the pin number and then the telephone number which he or she wishes to be connected to.
After entering the pin number or the telephone number, one can press the symbol defined as the finish key in order to make the verification or connection to the
desired number faster. Having received that symbol, the VoipBox will automatically start analysing the entered number. When the user does not press this symbol, the
analysing of the entered pin number or telephone number will start only after the period described as "non activity timeout".
Redial string - It is used to redial the last dialed number. Working for IVR, callback clients. It is working only for numbers dialed during current session. First number
dialed after being connected must be picked up manually or using speed-dial.
End call string - A user may terminate the connection at any moment. In order to do so, a user has to press the symbols described here. The telephone call will
become instantly disconnected and the system will ask the user to enter another telephone number.
Non activity retries - This value defines how many times the system will ask a user to enter the pin number or telephone number. The request will be repeated
according to the defined value only if a user does not enter any digit.
Wrong pin retries - Defines how many times the system will repeat the request to enter the pin number in the event that an incorrect pin has been entered. If the user
fails to enter the correct pin number, he or she will be disconnected.
Time multiplier - This multiplier may be used to change the message about the remaining time of the telephone call, which is communicated to the user. Only the
message will become changed as the actual time depends on a specific tariff and is unchangeable. If we set the multiplier at 1.1, the message will communicate that the
remaining time is increased by o 10% compared to the actual time after which the telephone call will become disconnected.
Time addition - With this variable, it is possible to change the information concerning the remaining time of the telephone call by a certain number of seconds. If this
value equals 10, the user will hear that the remaining time of the telephone call is 10 seconds longer than the actual time.
Round time to minutes - Thanks to this option the information concerning the remaining time of the telephone call will become rounded off to the nearest whole
minute and the number of seconds will not be included in the message.
Silence duration - This parameter is defined in seconds. Each message becomes sent (ask for pin, ask for number, account information) to the client only after this
period of time.
Use client's account to recharge - If the setting Use client's accounts to recharge is set to on, the account can be recharged using the IVR or common client password.
In such case the amount of credit that is present on the account of the users whose password one uses as the PIN number is added to the account of the user who
makes the recharge. The account of the customer that is used to make the recharge is zeroed, and a Return type payment containing the credentials of the user that
made the payment is added.
Import dialable scenarios - This button allows to import saved dialable scenarios. Usually scenarios are located in subfolder \scenarios\dialable in VoipBox directory.
Select language pair - In this field you should enter language names and digits assigned to them, for example: 1-English;2-Spanish. More information in section
Save changes - Any saved changes in VoipBox configuration require restarting VoipBox.exe in order to activate them.
Time multipliers
This part of settings is used to define multipliers used for resellers or lots. Values set there are used to modify time announced to clients using IVR services. Value set
for lot will apply to all clients belonging to it and value set for reseller will be used for all clients created by reseller. Value of this parameter is used to multiply rate for
number dialed by client. It is used only to change time being announced.
Invoices settings
In order to modify invoice settings choose the "Settings" menu and next "Invoices". The invoice settings window will appear (Fig.1).
Figure 1. Invoices settings in VoipSwitchManager
You subsequently enter:

The directory in which the documents will be saved - "Output folder" (Fig.2).
Figure 2. Setting output folder for generated invoices.
You can choose the directory by pressing the button at the right side of a field (Fig.3). A window will appear, in which you select the appropriate directory and press
"OK".
Then we enter a seller's name, address and Tax Identification Number which will be printed in the invoice (Fig.3 ).
Figure 3. Setting seller details.
All bolded items are required for generating invoices.
The following settings concern the invoice (Fig. 4). They are "Terms of payment", "Invoice item", "VAT, PST rate", "Currency symbol", "Decimal places", "Invoice
number" and "Place of making out".
Figure 4. Invoice detailed settings.
In the name of an invoice item you can use variables which will be changed into appropriate values when generating an invoice. You can use the following variables:
[FROM_DATE] - the date since which the billing is generated.

[TO_DATE] - the date until which the billing is generated.
[LOGIN] - the login of a client for whom the billing is generated.
[CLIENT_NR] - the number of a client for whom the billing is generated.
[ACCOUNT_STATE] - the account state of a client for whom the billing is generated.
Example
The value "Calls from [FROM_DATE] to [TO_DATE]" when generating an invoice for the period from 2005-12-01 to 2005-12-31 will be
changed into the value "Calls from 2005-12-01 to 2005-12-31".
Variables can be edited manually but you can also use the button on the right side of the field which brings out the list of variables and their description. In
order to enter the appropriate variable you can choose it from the list and press the "OK" button. It will be added at the end of the invoice item name.
Next you have to quote the VAT rate and a currency for the invoice. You can also specify PST rate and number of decimal places for amount.
The next step includes defining the way of invoice numeration.

In the invoice number you can use the following variables:
[YEAR] - the year of issuing an invoice.

[MONTH] - the month of issuing an invoice.
[NUMBER] - the following invoice number.
Example
The value "INV/[NUMBER] with the number 20 will be changed into the value "INV/20" when generating an invoice.
Variables can be entered manually, you can also use the button on the right side of a field, which brings out the list of variables and their description.
Then we specify the way of generating the following invoice number (the "[NUMBER]" variable).
Figure 5. Resetting invoice numbers.
If the number should be reset you have to select "Reset invoice number" and specify if the numeration should be started from the number 1 every month or every
year.
You also have to specify what invoice template you want to use (Fig. 6).
Figure 6. Setting invoice template and footer text.
There are two templates available - the standard one and the template which does not include the VAT tax.
After pressing the "Edit templates" button you may choose which template you wish to edit and Template Designer will open. There you will be able to edit template.
Template editing is only for advanced users. Use this feature with care!
Then we specify the invoice footer. In the footer (Fig. 6) you can use the same variables like in the invoice field in the same way.
If you want your logo to be printed in the invoice press the "Select logo file" (Fig. 6) button. It brings up the window in which we point an appropriate graphic file
(jpg, gif, bmp).
The section "Summary billing grouping type" (Fig. 7) specifies the way of generating the summary billing. If you select "Tariff prefix and description" the calls are
grouped according to the prefix and tariff description, if you select "Tariff description" the calls are grouped only according to tariff description.
The section "Additional grouping type" (Fig. 7) specifies whether additional monthly, daily grouping should also be created for the summary billing or not.
Figure 7. Billing grouping and summary generating options.
Send invoice" means that an invoice (and the billing if it is also generated) should be sent to a client by e-mail. "Create detailed billing" means that a detailed billing
(including all calls) should be generated for a client. "Create summary billing" means that summary billing should be generated for a client.
Mail settings
In order to modify settings of sent e-mails choose the "Mail settings" sub-menu from Invoices. It brings out the settings window for e-mails sent to clients together
with invoices.
Figure 8. Invoices mail settings.
You have to enter as follows: the address of an e-mail from which you will send messages, title and content of a message. In the title and content of a message you can
use the following variables:
[FROM_DATE] - the date from which the billing is generated.

[TO_DATE] - the date until which the billing is generated.
[INVOICE] - the number of an invoice.
Variables can be edited manually but you can also use the button on the right side of the appropriate fields which brings out the list of available variables.
SMTP settings
The parameters of connection with the SMTP server should be set in the section called "SMTP settings".
Figure 9. SMTP settings for sending invoices.
You have to enter as follows: SMTP server address, if a server requires authorization you have to select "Server requires authorization" and enter a user's name and a
password. You can also check to use SSL protocol checkbox and set port different from standard. After entering the parameters you can press the "Test settings"
button in order to test your settings. A window will appear where you can enter the address to send a test e-mail.
If the settings are incorrect a message window will appear with description of an error.
Otherwise the message will appear like on Fig.10.
Figure 10. SMTP settings test success.
Custom fields
This section allows administrator to setup definition of custom fields for personal details. Additional fields will be visible both in VSM and Customer Portal.
There are three default field types:
Text
Numeric
ComboBox
Every field can be hidden or set as read only for Customers.
After setting up fields definition administrator is able to edit extended personal details in Client definition.
Custom fields are working for all Customer types.
Labels
vsm voipswitch h323 sip pc2phone callback callshop voipbox invoices listener registrar mail smtp
Children (8)
Callback
H323
Invoices settings
PC2Phone
Regular Callback
Settings - VoipSwitch
SIP
VoipBox settings
8.0 Services - VoipSwitch documentation - VoipSwitch Dashboard Page 1 of 10
8.0 Services
33 Added by Jaroslaw Marek, last edited by Jaroslaw Marek on Feb 23, 2009
VoipSwitch ® Services give possibility to automate some cyclic tasks. This section of documentation covers configuratin and how-to-use examples for
VoipSwitch ® Services.
Configuration
Starting and stopping VoipSwitch Service
SMTP settings
Services log
Account state
Account state reseller
Expiration time
Archives
Invoices
Payments
Voice Messages
Least Cost Routing
Effective Rate
Configuration
Starting and stopping VoipSwitch Service
In order to start and stop the service, select accordingly Start or Stop position from the menu which appears after clicking the Configuration leaf in Services
section of VSM.
Fig.1 Starting and stopping VoipSwitch Service
The buttons "Start" and "Stop" are used to start and stop the service.
Label above buttons indicates the current state of services. It may be either RUNNING (as shown on Fig. 1) or STOPPED.
SMTP settings
Next, you should provide then SMTP server parameters, i.e. server address; if the server requires authorisation, check the box "Server requires authorization"
and enter the user name and the user password. Having done that, if you want to test the parameters, you may press the button "Test settings". You will see a
window where you enter the e-mail address to which you want to send a test e-mail message.
Fig.2 SMTP settings
http://docs.voipswitch.com:8080/display/VDoc/8.0+Services 10/16/2010
If the settings are incorrect, the message with the error description will appear (see Fig.3a), otherwise, the message will look as shown on Fig.3b.
a. b.
Fig.3 SMTP settings test result. a) failed, b) succeed
Having tested the connection parameters and SMTP parameters, save the settings by pressing the button "Save".
SMTP settings are needed for sending emails by Account state, Invoices and Payments modules.
Services log
This is the window with the log of the service operations.
Fig.4 VoipSwitch services log
The upper part of the window contains the list of operation types and date fields. Select the starting and ending dates of a period and you will be able to see the
operations executed within this period. Having changed the operation type or dates, press the button "Apply filter" in order to refresh the content of the list. You
may arrange the list according to different criteria by clicking on the appropriate column heading.
Account state
At the "Account state" leaf, you may define how often the system should examine the state of user accounts and send reminding messages by e-mail.
Fig.5 Account state controls - check interval.
The minimum value of check interval is 30 minutes.

The service examines whether a given type of e-mail has already been sent to a particular user and does not send the e-mail again until 7 days later.
For example, if the user X account's state is EUR 1, and the e-mail message is defined for the state below EUR 2, regardless of the above setting, the e-mail
message will be sent every 7 days unless the account state changes.
Below, there are checkboxes to define whether the service should use the client types or " Lots".
Fig.6 Account state controls - client types or lots.
Then, from the selection lists, choose the client type you are interested in and (if "Use lots" above was checked) a relevant "Lots".
Fig.7 Account state controls - client type choosing.
After making the selection in the list below, there will appear a list of messages defined for a client type (or "Lots").
Fig.8 Account state - list of messages defined for a clients.
In order to add a new message with the information about the account state, press the button "Add". The message-defining window will appear.
Fig.9 Account state - email message composer.
First, enter the account state, at (or below) which the reminding message will be sent.
Then, define the message title and the text of the message.
In case of both the title and the text of the message, you can use the following variables:
[AMOUNT] - current state of the account

[LOGIN] - client's login
[NAME] - client's name
The variables may be entered manually or by selecting particular positions from the list of all available variables in the drop-down menu. To open the drop-down
menu (see Fig.10), press the 'upside-down triangle' button to the right of the variable field.
Fig.10 Account state - special variables window.
After pressing the button "OK", the selected variable will be entered at the end of a relevant field. The variables will be replaced with appropriate values while the
message is being sent.
Example
When sending a message to a client whose account state equals EUR 1, the message title "Account state: EUR [AMOUNT]" will be changed into
"Account state: EUR 1".
It is also possible to send HTML messages. To do so, check the box "Use HTML", and then select an external, previously defined HTML file (by pressing the
button located to the right of the field "HTML file"). Having completed defining, confirm the new message by pressing "OK".
In order to edit a previously defined message, highlight the relevant position in the list and press the button "Edit" or double click on this position in the list. In
order to remove a message, highlight the message in the list and press "Delete". Remember to press the button "Save settings" after defining is completed (as
shown on Fig.11).
Fig.11 Account state - save settings.
Account state reseller

Settings in this section are very similar to the previous one. Instead of "Client type", "Reseller level" selection is available.
Fig.12 Account state reseller controls.
Expiration time
This service is used to block clients accounts after defined time which passed from first call. Common usage is to set expiration time on 1 month after first call so
user must finish all his funds in a month. After this time even if his account is not 0 he will be blocked from calling.
In the upper part of the tab "Expiration time", you may set the frequency of how often the service should examine the expiration time of user accounts. The
minimum value of expiration is 1 hour. Second time which can be set there is time of checking interval. Minmum value of it is 30 min and it means only how often
service is checking for expired clients. Setting this value higher can spare system resources.
Fig.13 Expiriation time.
Below, there are checkboxes to define whether the service should use the clients, client types or "Lots" during such examination.
Fig.14 Expiriation time - use clients.
If you choose "Client types", for each client type you must provide the time from the first call after which the user account will be blocked.
Fig.15 Expiriation time - selecting all clients of particular type.
If you do not want to have the accounts for some client types blocked, uncheck the box to the left of a relevant type.
If you decide to use Lots, the lower part of window contains the list of "Lots" for which the expiration time will be examined.
Fig.16 Adding new lot to expiriation module.
In order to add "lots" select the time from the last call (1.), after which the client account in a selected "Lots" will be blocked; next choose the client type and
desired lot (2.) from "Lots" drop-down list.
After defining is completed, press the button "Add new" (3.). After that new expiriation entry will be added to the list (Fig. 16, green line and elipse)
In order to edit previously chosen Lots, highlight the appropriate position in the list; then change values and press the button "Save".
In order to exclude "lots" from examination, highlight selected "lots" in the list and press the button "Delete".
Account will expire cruelly, with aside of payments and client's account state.
Archives
This service gives possibility to archive old data from calls and failed calls tables to reduce database tables size. Reducing calls and failed calls tables can speed
up calls processing and improve performance of server. Good practice is to keep only last 2 months in main tables and any older records will be moved to
archive tables.
Actually archive tables are not accessbile by clients or even by VoipSwitch owner. We are going to add functionality to browse thru them in near
future. If someone wants to check older records it is possible only directly by accessing database tables.
Fig.17 Archives - main controls.
Checked interval options define a number of days between each archive and exact execute time.
Fig.18 Archives - time interval settings.
Move to archive records:
1. older than X months - on execution time the system analyzes calls tables and saves records older than X months to table named "callsarchive_Y", where Y
is number starting from 1
2. when record counts exceed X records - after condition is true (number of records is more or equal X), the oldest records are transferred to archive
Create new archival table with current active archive:
1. contains records from X months - when archive table contains data older than X months a new table is created and archive will be stored in the new table
2. records count exceeds Y records - when archive table contains more than Y records a new table is created and archive will be stored in the new table
Fig.19 Archive options.
Invoices
In the upper part of the tab "Invoices", you should define how often the service should generate invoices. The minimum value is 30 minutes.
Fig.20 Invoices - time interval and range of invoice generation.
In the next step, define the period for which the invoices are to be generated.
Next, choose a destination folder into which the invoices will be generated.
Fig.21 Invoices - select output folder.
Choose the folder by clicking the button on the right and selecting the appropriate folder.
Below, there are checkboxes to define whether the service should use the client types or Lots while generating invoices.
If you select "Client types", you should define for what client types the invoices will be generated.
Fig.22 Invoices - selecting client types or lots.
If you want the application to generate invoices for a certain client type,
check the box to the left of the relevant type name.
If you have chosen "Use lots", the invoices will be generated for the clients in the "Lots" of the below list.
Fig.23 Invoices - selecting all clients of particular type.
In order to add "Lots", select a client type and next the "Lots" you are interested in and press the button "Add new".
In order to remove a "Lots" form the list, highlight it in the list and press the button "Delete".
Payments
Payments service is used to charge users accounts with desired amount. Payments are made cyclic on daily, weekly, or monthly basis.
There is a posibility to send notification email to the client at some time before charge.
Notification email is sent only when client account state is lower than scheduled payment.
In order to enable sending notification emails corresponding checkbox must be marked.

Reminder template may be edited. An example is shown below:
Fig.24 Invoices - reminder template.
You should define whether the service should use the client types, lots or single clients while executing payments.
Fig.25 Invoices - using client type, lots or list of choosen clients..
When you use client types, as shown above, mark client type you want to charge and set parameters up. The parameters are:
1. charge every - set time interval between charges; this may be some number of days, weeks or months.
2. fee - set the amount the client account will be charged.
3. start from - set start date of payments (useful i.e. when client has free of charge trial period).
4. payment desc - set description of this payment.
Examples on Fig.25
Some examples of Payments are visible on Fig.25, especially how to setup weekly, daily and monthly payments to clients.
When use lots is enabled, you have to set up charge settings for every lot you wish to charge clients from. An example is shown here:
Fig.25 Invoices - use lots type.
First choose one of client type (1.), next choose lot from Lots list(2.); then set up charge settings (charge interval, fee, start date and description) as in
previous section (3.) and click Add new button(4.). Next, the new entry will appear on defined payments list (5.).
Every defined payment is shown on the list (with short description and client type displayed) and may be edited or deleted.
When use clients is enabled, almost all settings are similar to the previous section. Instead of lots the clients are added to list as shown below:
Fig.25 Invoices - use client types.
Using this mode you can schedule more than one payment for Clients. For example Client can be charged monthly with given sum and also weekly with another
sum. It is very usable when different Clients have different services.
Voice Messages
Voice messages service sends an email to the configured user email address when they "miss a call". You may set the frequency of how often the service should
check for new messages. Reminder message template may be edited. An example is shown below:
Fig.26 Voice Messages - reminder template.
Least Cost Routing

Calculations for LCR are made at certain time intervals, defined in Services -> Least Cost Routing. This module has to be active with the set time range. After
making changes to the cost tariffs, special functions compare the rates and determine a priority for the termination gateway.
General LCR description: Least Cost Routing (LCR)
Effective Rate
This service is used to apply defined future changes for tariffs.
Labels
service account resseler expiry expiriation archive invoices payments configuration services
Comments (1)
How should I create a remainder mail for a specific customer if there is no lot defined. I configured smtp and eanbled account state.
Is it possible to assume an existing customer into a new lot?
VSM 2 - Clients - VoipSwitch documentation - VoipSwitch Dashboard Page 1 of 6
VSM 2 - Clients
1 Added by Bartek Wrobel, last edited by Bartek Wrobel on Aug 30, 2010
Clients
Base informations
VSM 2 comes with simplified clients system. There are available few types of client accounts, all accessible from the left menu panel.
Usable client types are:
Wholesale clients
Retail clients
PBX clients
PBX sub-accounts
CallShop clients
Other
CallBack clinets
IVR clients
Except these under the Clients menu are accessible functions for searching the client by his login name and for generating client's lots.
Clients common features

Login and password
It can be used differently by different type of client. For Wholesale clients it can be used to authorize every call. IVR (or Retail) clients use password as a PIN number to authorize
caller to use the IVR. Common functionality for all types of clients is capability of logging into a VSPortal using login and password. Every type of client has different information
available there and can use it to get access to his account.
To keep decent security level clients passwords should be chosen carefully. Under no circumstances it should contain his login or any easy-to-guess data, otherwise
such account can be easily hacked causing money loss to the VoipSwitch owner.
Funds & Tariff

Tariff assigned to a client is used to:
calculate cost of a call for the client

estimate maximum time of connection
calculate the remaining time announced for IVR clients
limit available directions. If there is no matching prefix in tariff, the call will not be realized.
Cost of every call is calculated using tariff right after disconnection. When tariff for a client changes in the future, all calls made untill this change won't be changed. The system
will use new tariff only for new calls and old ones will be left unchanged.
http://docs.voipswitch.com:8080/display/VDoc/VSM+2+-+Clients 10/16/2010
Funds & Tariff window in VSM 2
Along with tariff options comes such settings as:
Currency - enables to assign defined currency for the client. If should be the same as currency defined with the tariff;
Remaining funds/Add payment - displays client's remaining funds and enables to manually recharge his account;
Choose tariff according to... Rules - enables to switch tariffs according to called number or/and caller ID. PBX and CallShop clients are disabled from using this option;
Automatic payments - here can be added payments the client will be charged with every fixed period of time;
Tariffs plans - in this box Tariff plans can be added to the client. More about Tariff plans can be found here.
Account state
Client must have some funds in the account to be able to make calls through Voipswitch. One exception is when tariff assigned to a client has 0 cost rates, but this is rather
unusual. In most cases every call is charged and this amount is subtracted from client's account state value. When value reaches 0 the client will be blocked from calling.
Account state value can be modified only by adding payments. Using payment in comparison to direct modification account state value has one big advantage. Every change is
recorded with date and optional description.
There are four payment types available:
Prepaid - should be used after client has paid money;

Return - when it is necessary to return money to client this payment type should be used. Return payment cannot be higher than funds available on clients account;
Credit - adding fund with this payment type allows client Credit Balance to go below 0 and continue making calls. Total available credit for client is a summary of all credit
payments made for him. If client really wants to have "unlimited" credit then it is possible to add big amount as credit payment;
The Credit option can be used to allow users to make calls after the account state has reached 0. After that, while calling, the client's account state will go
below 0 till it reaches the Credit value. This feature can be used for postpaid payments but not like adding more credit. If the postpaid system is used it can be
added eg. Credit = 100$ and then, when client finally pay, add normal payment as prepaid. It will be working like postpaid system.
Return credit - this payment decreases available credit for client or removing it. It can't be returned more credit than has been added before.
Adding payments in VSM 2
The most typical way to increase account state (balance) is to add payment. It can be done by VoipSwitch owner using VSM or VSC or by reseller. Reseller can add funds only to
clients or resellers belonging to him. Clients can see history of payment on the web and recharge accounts in several ways. Methods of recharging are described here.
Prefixes
This is a general name used for manipulating information being sent in a client's call. It is specified as:
Dialing plan prefix

Tariff prefix
Caller id prefix
First it must be explained how VoipSwitch processes calls coming from a client. After client authorization, VoipSwitch checks the dialed number. It must match the entries defined
in Dialing Plan and in Tariff. Before searching the dialed number in dialing plan it can be modified by Dialing plan prefix. It will not change number used to find prefix in Tariff.
To modify number before searching in tariff tariff prefix must be used. Caller id prefix is used to modify caller ID being sent to VoipSwitch from a client.
Dialing plan prefix and tariff prefix modify the called number seperately for every given client. A rule defined in one place is not used for another.
Every prefix is built from digits or characters. Modifcation of them is described in special section available here
There are additional prefixes available for callback calls:
Source dialing plan prefix

Source tariff prefix
Source caller id
Every callback call consists of two legs, which means that different rules can be set for modyfing number or caller id for every leg.
Codecs
Allows the selection of 9 audio and 3 video codec groups depending on what client device can support. One codec has to be set as primary and it will be the default one.
Voipswitch supports group of codecs, meaning that if the g723.1 is selected, all kind of g723.1 codecs will be allowed, including g723r63 and g723r53. Same thing for other codec
groups.
After the selection Use client codec option can be enabled letting the VoipSwitch to negotiate the right codec from the list with the client's device. Of course client's device has
to be able to autonegotiate codecs.
Audio codecs list
Video codecs list
VoipSwitch acts differently in "proxy all" mode and in "proxy only signaling" mode. In "proxy all" VoipSwitch does not allow codec negotiation directly between
endpoints and instead will negotiate itself with each endpoint in part. While in "proxy only signaling" endpoints can negotiate codecs directly. It is possible to choose
any codec that both endpoints support, even those that are not listed in VoipSwitch settings.
Codec selection is available for Wholesale clients, Retail clients and PBX sub-accounts.
Active state
Client's account can be active or inactive. Inactive client cannot make calls nor log into VSPortal/PBX Portal.
Personal data
Every client has an option to write extended information about himself. Available fields are presented on figure below.
Client's personal data settings in VSM 2
These informations are used when creating invoices or sending warning emails.
Reseller assignment
Client created in VoipSwitch can belong to reseller. Information about the

reseller assignment is present in client's settings under the "General" tab
and can be changed. However it is not recommended to do it manually. It
is more secure to do it through the resellers pages.
Wholesale clients
Those clients are used mostly for carriers and wholesale services. Other popular application is to authorize DID numbers being used to:
activating callback
calling to IVR scenarios
calling to devices and make charging them for answering
Options available for Wholesale client
Login field is the username for this account.
Password is the allocated password.

These 2 fields are used to access the web page to see the CDR's. Also the Login@Password combination is used to match against the H323ID sent by the client in case that
Authorize by login/password feature is enabled. For SIP clients login and password can also be used without adding client's IP.
Wholesale client's general options
Recognize by H323 ID option allows sending SIP and H323 traffic without IP authorization.
DID source - allows to charge clients answering calls.

It is useful with DID services when client is paying a monthly fee for the number and then additionally for every call answered using this number. This option will work with calls
ending to PC2Phone, GK or Common clients. When checked, every such client will be charged for answering a call. Tariff assigned to this client will be used to calculate cost of
a call. If a client doesn't have enough money to pay even one billing step, the call will not be connected.
PIN source option is used for calls made to IVR system. Calling to PIN asking scenario allows to work with calling cards services. Only with this option checked Wholesale client
can be used as an access to PIN-scenario. Such call will be billed in two ways.
SIM Source
IP address based authorization:
IP numbers are the list with authorized IP addresses. Cost of calls

coming from IP assigned to a client is taken from his account.
There is no limit for the IP addresses here. Theoretically there can't
be added two the same IP addresses, unless there have been
specified prefix modification sequence in the Prefix field. Pressing
the ... button will trigger the dialog window for setting prefix
modifications. In the IP numbers box there is a field where the new
addresses can be put and after pushing the "Add IP" button it will
be added to the list. To remove an IP from the list it has to be
selected first and then clicked Remove IP button. It is possible to
specify IP addresses range to be added to the list. After clicking
Add Range button the dialog as on the screen below will appear. It
should be set starting IP and ending IP there. VoipSwitch will use
them as boundaries to create appropriate entries in IP numbers list.
For starting IP will be added 1 till it reaches ending IP.
Adding IP number to the Wholesale Client
Connect client immediately - this option should be enabled only when all calls of a client do not connect to any destination. This will open the media channel immediately after
routing but in most cases will generate also false billing because the calls will be declared answered immediately.
So this feature is for extreme cases only. It shouldn't be used for normal users.
Calls limit - used to limit the calls count running through the Wholesale client. When number of calls is equal to this limit any new calls from this client will be rejected. This is
also checked for calls in progress and connected apiece.
Retail clients
This type of clients account enables the VoipSwitch clients to use its features such as:
calling from different types of dialers: PC2Phone, ATA, WebDialer, Mobile dialer etc.;
using Calling Card service: calling on PIN/PIN-less scenarios;
using callback feature;
log into VSPortal and use their features.
Settings for Retail clients are very simple and were mostly described in the Clients common features chapter. One of new feature here is recognizing the caller by his caller ID. It is
used in PIN scenarios where the client has to send his PIN first to get access to his account. With Recognize by ANI option, if the caller ID is present on the ANI numbers list,
client will not have to enter his PIN. Instead of that he will be recognized by the system automatically and so registered on the proper account.
Retail clients general options
There are available special VoipBox scenarios where client's caller ID can be saved automatically or the one where client can add ANI numbers manually.
Another now option is Generate ringback. If checked VoipSwitch will generate ringback tone while calling the client.
Children (3)
Retail clients
VSM 2 - Clients. Clients common features
Wholesale clients
VSR - Resellers - VoipSwitch documentation - VoipSwitch Dashboard Page 1 of 6
VSR - Resellers
14 Added by Michal, last edited by Editor on Feb 19, 2008
General description
Resellers definition
General
Funds & Tariff
Personal data
Client types & permissions
Reseller with parent

General description
Resellers system is built as web application. It allows resellers to create and manage clients of VoipSwitch system. After logging to web
page which is accessible by default under address
http://........./VSR/
they can manage clients, tariffs, check reports or see calls being connected by their clients.
Every reseller has amount of money assigned to him. This amount is used as credit. After every call made by client belonging to reseller
this amount is decreased by cost. Cost is calculated using tariff assinged to reseller. This tariff is named base tariff and it can only be
read by a reseller when he is logged to system.
From web pages available after logging resellers can add and manage their tariff. As mentioned above one tariff cannot be changed and
it is assigned during reseller creation. Other tariffs can be added by resellers and later assigned to clients. These new tariffs should have
higher rates than defined in base tariff. It will give profit for reseller after every call made by clients.
Rates in tariffs created by resellers can be even smaller than in base tariff. The system allows that. It is a reseller's
responsbility to create valid rates
We decided to allow adding lower rates because of marketing reasons. Some countries can be even cheaper than resellers buys and
more popular can be higher so summary will give positive profit.
There are 3 levels of resellers:

Level I - resellers I
level II - resellers II
level III - resellers III
Having 3 levels allows to built complex models of sales. Resellers hierarchy can be defined as follows:
Reseller of level I can create and manage clients calling through VoipSwitch.
Reseller of level II can create and manipulate resellers of level I created by him.
Reseller of level III can manage resellers of level II created by him.
http://docs.voipswitch.com:8080/display/VDoc/VSR+-+Resellers 10/16/2010
Even though resellers of level II and III cannot create clients directly they can add lower levels and use them to create clients. Using
reports part of system they can still see calls being connected by clients belonging to lower levels.
Using resellers with one or more levels makes some additional work with cost calculation. For example if there are 3 levels of resellers
used, after every call 4 costs are calculated. One for client and 3 for every level.
Resellers system is built to give profit for resellers only after making calls by their clients. Normal scenario can be as described below.
1. Reseller account is created with some initial money on his account. This money can be credited to reseller or just money paid by
him.
2. During reseller creation login and password are created which are used to log on web pages.
3. Reseller creates tariff with rates higher than he has in tariff assigned to him.
4. After logging to system reseller creates clients ready to use VoipSwitch system and services available. He can be limited or can
have almost unlimited posibility to add new clients.
5. Reseller sells created clients accounts and they start calling.
6. Clients call using higher tariff so their funds will finish faster than reseller credit and the difference will be a profit available for
reseller. He will collect bigger amount of money than he must pay for his calls.
Resellers system allows to assign different tariffs for different clients belonging to the same reseller.
Reseller can fully manage his own account including tariffs and client management. Reseller is responsible for creating tariffs and
clients.
Reseller can be limited by several options listed below:
1. calls limit value is limiting calls made by his clients.

2. clients limit limits amount of money assigned to new clients. This value normally is much bigger than calls limit.
3. maximum number of clients created can be set, 0 means unlimited number.
4. reseller can be limited to see only selected client types available in VoipSwitch.
5. even if specified type is visible reseller can be limited in adding new clients. He can only see and change already created ones.
6. adding new tariffs can be disabled for specified reseller.
7. in calls history route is used to terminate calls. It can be displayed or hidden.

8. special prefixes assigned to reseller can be used to allow him to chosen between different routes defined in VoipSwitch. These
prefixes must be configured in VoipSwitch already, but assigning them to resellers allows to assign them to different clients.
Resellers definition
Resellers support must be turned on in VoipSwitch settings. If you don't set this option the cost for resellers won't be
calculated and calls limit value will not be decreased.
New resellers can be added in three ways. It can be done by VoipSwitch owner using VSM or VSC interface or by reseller of higher
level using VSR web pages.
Every reseller must have some fields to fill with valid values. Values are divided into four sections:
General
Funds & Tariff
Personal data
General
Login and password - values used to log using VSR pages. After logging a reseller can see his clients, tariffs, reports and calls
going through VoipSwitch.
Identifier - it is short symbol used to identify a reseller. It must be unique for all 3 reseller levels. It is used by a reseller to add
new tariff. This symbol is added in front of tariff name. For example if reseller names his tariff Test and if his shortcut is WJS
tariff will be added with name WJS:Test. Later when VoipSwitch administrator will browse tariffs it will be easy to find tariffs
belonging to one reseller.
Reseller level - it is read-only and is used only to display reseller level. It was prepared for option to change reseller level after
creation but it is not available yet. Reseller level cannot be changed when it is created.
Parent - this field displays login name of parent for reseller. When it is empty it means that reseller has no parent. Normally
reseller of highest level is created by VoipSwitch administrator and later this reseller will create resellers of lower level. However
using VSM or VSC can add a parent to reseller or change it. Parent of reseller shouldn't be changed when reseller's client has
made some calls. There are some differences with setting option for reseller when he has parent or is unassigned.
Src dialing plan prefix, Src tariff prefix, Dest. dialing plan prefix, Dest tariff prefix - prefixes are used for reseller allowing
them to assign them to clients. For every type a few prefixes can be added and they must be delimited by comas. More about
usage of prefixes is described here. Below prefixes is a button with title Validate prefixes. After changing some prefix,
especially removing one of them it must be validated if this prefixe was not used for one or more clients belonging to a reseller.
Clicking this button will cause this checking and show clients required to be modified. It must be done manually.
Active - if this option is not checked then reseller will not be able to log to VSR pages.
Tariff to DNIS - reseller can be allowed or blocked from using it. More details about this option can be found here.
Report for routes - when this option is unchecked a reseller will not see in reports which gateway was used to terminate calls.
Sometimes it can be useful to show him name of gateway used to terminate calls so he can decide which one is better.
Dis. adding tariffs - checking this option will disable resellers from adding any new tariff. He will be able to use his base tariff
and all tariffs already assigned to him before this option was checked.
Funds & Tariff
Base tariff - tariff assigned to a reseller which is used to calculate his calls. Any calls made by his clients will calcualte cost
for the reseller using this tariff and this cost will be taken from calls limit value. Rates and other values in this tariff cannot be
changed by reseller after logging to VSR pages.
Calls limit - amount of money added to reseller and used for calling. It is added through payments so later the history of
operations can be checked. To return some money to a reseller a special payment must be added of type return. Amount of
money defined with such type of payment will be substracted from calls limit value.
When calls limit value reseller will reach 0 any of his clients will be blocked from calling.
Clients limit - this amount of money is modified directly by editing value. It is used to limit a reseller against adding too much
clients without neccessity. For example if value set there will be 1000 only 10 clients with 100 amount on every of them can be
added. Calls limit value is checked independetly from this limit. It should be set with some high value if you don't want to limit
a reseller.
Maximum clients - value higher then 0 will limit a reseller to create only this number of clients. 0 has special meaning and
allows to create any number of clients.
Personal data
There is personal information about reseller. Full name , address, city, country can be used for invoicing ( invoicing for reseller is being
developed now ). Email address is used by service which is reminding resellers about low level of calls limit value.
This part is used to limit some rights for reseller.
Client types - this place allows to define which types of clients will be available to see by reseller.
Assign permissions - Even if reseller is allowed to see given client type he can be limited from adding new clients. This rule
can be even applied later when he created clients and we will want to block him from adding new.
Reseller with parent

When reseller has a parent assigned to him there are some limitation with possible values.
1. In permissions tab it can be only limited rights. Types and permissions blocked for parent reseller cannot be allowed for child
reseller. Child reseller can only has smaller number of types and persmissions than parent to which he belongs.
2. Child reseller can use only prefixes available for parent reseller. Clicking a button close to prefix will show a list of prefixes
assigned to parent from which those to be assigned to a chilld can be selected.
For reseller without parent a list of prefixes can be added without limitation.
Children (4)
Changes VSR
Resellers features
Resellers prefixes
Resellers Web pages VSR
VoipTunnel - VoipSwitch documentation - VoipSwitch Dashboard Page 1 of 4
VoipTunnel
9 Added by Jaroslaw Marek, last edited by Jaroslaw Marek on Oct 08, 2010
General description
VoipTunnel Server
VoipTunnel Server installed on dedicated host.
VoipTunnelClient
VoipTunnelClient (version built in the SIPLink dialer)
Sample configuration of devices to cooperate with the module VoipTunnelClient
Sipura SPA -2000
General description
The application VoipTunnel has been created in order to enable making VoIP phone calls for users who live in the countries where VoIP traffic is blocked. This
application may also be used in locked computer networks, e.g. in networks where NAT disables correct functioning of SIP . The use of VoipTunnel makes it possible
to reduce the number of ports necessary for VoIP communication to only one. VoipTunnel cooperates with any devices/programs which support SIP , including, of
course, the dialer SIPLink made by VoipSwitch . The application VoipTunnel does not support the protocol H323 .
The application VoipTunnel consists of two parts described below.
VoipTunnel Server
The server module receives packets form all clients. This module should be installed on the computer which follows normal principles to communicate with the
VoipSwitch server by the means of SIP . In practice, this is a computer with a public IP address or, in most installation cases, a computer where VoipSwitch has been
installed.
http://docs.voipswitch.com:8080/display/VDoc/VoipTunnel 10/16/2010
During the first starting of VoipTunnelServer (vts.exe) configuration file tunnel_config.set will be created. The default values will be placed there - the server IP and
ports 1805 and 5600. If you haven't changed the values in VoipSwitch settings nor you haven't ordered dialer for different IP than you don't have to change anything
there.
However if you wish to change the settings of the VoipTunnelServer, please go to servers default installation directory (usually C:/program
files/VoipTunnelServer/) and open to edit file tunnel_config.set. Enter new values
TCP_TUNNEL_LISTENER_IP_ADDRESS=192.168.20.157:1805
UDP_TUNNEL_LISTENER_IP_ADDRESS=192.168.20.157:1805
SIP_SIGNALLING_IP_ADDRESS=192.168.20.157:5060
after making the changes save the file and restart the VoipTunnelServer.
Please remember that the VoipTunnelServer will work only on IP which has be registered with VoipSwitch.
TCP tunnel listener IP number and TCP tunnel listener port - these are, accordingly, the address and the port where VoipTunnelServer awaits the connection
from clients. These connections will be executed in the protocol TCP. Into these parameters, there should be entered the IP address of the computer where the
VoipTunnelServer functions and the port which we would like to use (conventionally it is port 1805).
UDP tunnel listener IP number and UDP tunnel listener port . These parameters are analogous to TCP tunnel listener IP number and TCP tunnel listener port . At the
address and port defined therein, VoipTunnelServer awaits the connections from clients executed by the means of the protocol UDP.
SIP signalling ip number and SIP signalling port - these are, accordingly,
the IP address and port used by the VoipSwitch server to register and receive the SIP clients traffic. If VoipSwitch does not function on the same computer as the
VoipTunnelServer module, its IP address and the appropriate port (by default 5060) should be entered in this place.
For the connections between the client and the VoipTunnelServer module, one may use either TCP or UDP protocols. The server receives packets for both protocols,
but in consideration for the quality and speed it is recommended that the protocol UDP be used. On the other hand, the protocol TCP enables to "pass through"
even the most sophisticated locks.
The properly working VoipTunnelServer should have all listeners started and the value numbers in packet counters should increase as the connections from clients are
received. This is shown in the image below.
You can use command line interface to change the UDP tunnel listener IP address and the SIP signalling IP address.
-tunnel_listener_ip_address=ip_address:port
-sip_signalling_ip_address=ip_address:port
Example: "c:\program files\voiptunnelserver\vts.exe" -tunnel_listener_ip_address=213.77.145.66:1810 -sip_signalling_ip_address=213.77.145.66:5091
VoipTunnel Server installed on dedicated host.

This solution allows to use VoipTunnel module even with 3rd party SIP Servers (like Asterisk and others). One server is dedicated to run VoipTunnel Server
module. End users using softphones (including mobile softphones), VoipTunnel Client module with ATA (or other generic SIP Clients) are connecting to
VoipTunnel Server from where communication is decrypted and send using SIP protocol.
VoipTunnelClient
This module should be installed and started on a computer which is located within the locked network. Many IPphones which function in this network and use the
protocol SIP may use this computer in order to register on the VoipSwitch server. Obviously, later they can make connections via this computer. Before starting the
VoipTunnelClient module, one should start VTCconfig and set the appropriate IP addresses and used ports.
Protocol denotes the type of protocol which will be used by this client (recommended UDP).
Tunnel Server IP number and Tunnel Server port are used to determine the IP of the computer where the started VoipTunnelServer is located. Port 1805 is entered here by
default but if in the VoipTunnelServer module another port is used, the appropriate value should be entered here.
Dummy SIP signalling IP number and Dummy SIP signalling port is the local address of the computer where the VoipTunnelClient will be started and where the packets from
clients will be received. In the above image this is a private IP address. This is the correct setting because IPphones which use this module should be in the same
private network.
After pressing the button Savesettings, the module VoipTunnelClient may be started.
After starting, it is possible to use such a computer for registering and calling from IPphones in the created tunnel.
VoipTunnelClient (version built in the SIPLink dialer)

In the case of a dialer, the end user obtains the final version which is ready to work as soon as the client installs it. Clients do not need to execute any configuration
activities.
The client who uses a thus-prepared dialer should have two unlocked ports. Port 1800 protocol TCP and port 1805 protocol UDP. Port 1800 may be changed in the
VoipSwitch system in the section PC2Phone settings of the VPSconfig program and port 1805 may be changed into another one in the module VoipTunnelServer in the
parameter UDP listener port . The dialer is prepared to work on specific ports so if the ports need to be changed it is necessary to create a new installation version of a
dialer and to re-install it on the clients' computers.
Sample configuration of devices to cooperate with the module VoipTunnelClient

As VoIPTunnel is embedded only in VoipSwitch Softphones then to make use of it with other SIP Clients there is need to install VoipTunnel Client application on
Windows PC or Server in the same network as SIP Client (ATA or IP Phone).
Example below shows how to configure ATA device to communicate with VoipSwitch Server through VoipTunnel Client application.
Sipura SPA -2000

In the example below, the device has been set to register and handle calls using VoipTunnel Client instaleld on PC with IP address 192.168.2.9, port 6060.
If the module VoipTunnelClient with parameters Dummy SIP signalling IP number and Dummy SIP signalling port set accordingly to 192.168.2.9 and 6060 is started on the
computer with the aforementioned address, the device should log in the VoipSwitch system via the application _VoipTunnel._
Labels
tunnel voiptunnel sipura cisco ata outstrip electronic technology gateways shenzhen

5 para Wuindows Server

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

5 para Wuindows Server

Transféré par

Droits d'auteur :

Formats disponibles

1.

0 Main system - VoipSwitch documentation - VoipSwitch Dashboard Page 1 of 4

1.0 Main system

28 Added by Michal, last edited by Lukasz Nowak on May 18, 2010

All calls are shown in following manner:

[ICON] Call to number: [DESTINATION NUMBER], [CALLER ID] ([CALL TYPE])

New call is connecting.

Call connected and active.

Call not connected with some reason.

Call finished properly.

Call failed with some reason.

To view short recording click here.

Filter and display settings

Fig.2 Calls processing window - context menu

Fig.3 Calls filter options

Reload settings and listeners actions

Fig.4 VoipSwitch with stopped listeners.

Fig.5 VoipSwitch log window.

Incoming and outgoing calls:

Registered users - All currently registered users (more details in Registered

Fig.6 VoipSwitch Statistics window.

Registered SIP Client.

Registered SIP Client with active call.

Registered H323 Client.

Registered H323 Client with active call.

Registered PC2Phone Client.

Registered PC2Phone Client with active call.

Edit selected client

Fig.8 VoipSwitch registered clients edit dialog.

Synchronize with database

Fig.9 VoipSwitch Gatekeepers reload settings.

H323 Gatekeeper online (registered)

SIP Registrar online (registered)

Gatekeeper/Registrar offline (unregistered)

Fig.10 VoipSwitch Gatekeepers window with settings.

Client online (connected)

Client offline (disconnected)

Fig.11 VoipSwitch Users window.

Printed by Atlassian Confluence 2.10.2, the Enterprise Wiki.

37 Added by Michal, last edited by Bartek Wrobel on Jul 06, 2010

Type of clients available in VoipSwitch system

2.2 Common features of clients

calculate cost of a call for the client

Assigning tariff to the client

Choosing the client's currency

2.2.4 Account state

There are 4 types of payments:

1. Prepaid - should be used after client has paid money.

Dialing plan prefix

There are additional prefixes available for callback calls:

Source dialing plan prefix

Codecs settings screen

2.2.7 Active state

2.2.8 Personal data

Client's personal data screen

Options available for GW client

Login field is the username for this account.

Password is the allocated password.

GW Client's general options

DID source - allows to charge clients answering calls.

IP address based authorization

IP numbers are the list with authorized IP

Connect client immediately