Document generated by Confluence on Sep 27, 2010 15:02 Page 1

VoipSwitch documentation : 4.0 Dialing plan

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

4.9.2 Operation
4.1 Base informations
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
Document generated by Confluence on Sep 27, 2010 15:02 Page 2
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
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.
Document generated by Confluence on Sep 27, 2010 15:02 Page 3
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)
Document generated by Confluence on Sep 27, 2010 15:02 Page 4
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.
Document generated by Confluence on Sep 27, 2010 15:02 Page 5
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:[email protected]>
paid1 is "Cullen Jennings"
paid2 is fluffy
paid3 is [email protected]
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).
tx 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 :
Remote-Party-ID:t[rpi1] <sip:t[rpi2]>;party=calling;privacy=off;screen=yes OR t[fm1]
<sip:t[fm2]>;party=calling;privacy=off;screen=yes
Document generated by Confluence on Sep 27, 2010 15:02 Page 6
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:[email protected]:5060>
instead of default:
From: <sip:[email protected]: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.
Document generated by Confluence on Sep 27, 2010 15:02 Page 7
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.
Document generated by Confluence on Sep 27, 2010 15:02 Page 8
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:
NumberPriority 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.
Document generated by Confluence on Sep 27, 2010 15:02 Page 9
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.
Document generated by Confluence on Sep 27, 2010 15:02 Page 10
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
Document generated by Confluence on Sep 27, 2010 15:02 Page 11
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.
Document generated by Confluence on Sep 27, 2010 15:02 Page 12
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)