With a release of the latest 3.16.0 version of JeraSoft VCS system, the Preset section has been merged with the Traffic Processing section to decentralize management over numbers translations. However, some features of old Preset section have been reworked to correspond to the needs of new traffic processing, along with the introduction of some advanced functionality. This article mainly focuses on two Traffic Processing features:

  • Migration of preset rules
  • $lnp_original_number$ variable for LNP/MNP rules

Migration of preset rules

Since new traffic rules can be either of origination or termination type, after update to the latest version, in the Traffic Processing section two new separate rules will be created for each old preset rule. Below, two examples of old preset rules are shown:

Screenshot: Preset Orig-Term rules

So, the first rule states that if Rose Orig client calls at 123* and Rose Term client routes it, system must block this call. But If the destination code is 1234, such call will be allowed according to the second rule. After migration to version 3.16.0, for each rule two new ones will be created (see screenshot below):

Screenshot: Traffic Processing rules

Origination rule (ID#1 marked by  icon) indicates that after system recognized that origination client is Rose Orig and dialed destination is 123* – system will mark such call with ot-preset-1 tag. The second termination rule (ID#2 marked by  icon) states that after the routes list is built, if the call has ot-preset-1 tag, its dialed destination is 123* and it's going to be terminated by Rose Term client, system will block a call.

In the same vein, origination rule with ID#3 declares that after system recognized that origination client is Rose Orig and dialed destination is 1234 – system will mark such call with ot-preset-2 tag. However, termination rule with ID#4 specifies that if the call at 1234 destination has ot-preset-2 tag and its terminator is the Rose Term client, after routing system will allow this call.

$lnp_original_number$ variable for LNP/MNP rules

The latest version also brought advanced functionality to the Traffic Processing section - the $lnp_original_number$ variable that works in combination with Number Portability section. In this example, TJA database will be used. Since numbers in the TJA database consist of the original number - an actual number that client is using and the routing number - a number that is stored in the TJA database and is a representation of the original one, $lnp_original_number$ variable allows user to control and manage what type of DST client's number will be displayed to a terminator. First of all, you need to have a target number to be specified in TJA database of Number Portability section. As an example, we will take 1111 as original number, whose routing number is 5555 (see screenshot below).

Screenshot: Number Portability section

Now, we need to go to the Traffic Processing section and create two rules: the first rule with the origination type and the second one with the termination. The origination rule must indicate that if a DST number starts with 372, system checks whether there is such number, specified in the TJA database. Please note that if indicated DST number is 3721111, system performs LNP dip of 1111 number, not 3721111, since 372 prefix will be added to TJA numbers by default. Consequently, if this traffic processing rule is executed, 1111  original number will be replaced by 5555  routing number transforming 3721111 DST number into 3725555. To create such rule, specify the following data in the respective field (see screenshot below):

Screenshot: Origination rule

Information blockFieldValue
GeneralType

Here, you need to select either After Client or After Rate type. Depending on a selected type of a rule, different rates will be applied to a call:

  • After Client - rate for 1111 code will be used
  • After Rate - rate for 5555 code will be used
Scr Code DeckAny code deck. For the example, DEFAULT code deck has been chosen
Dst Code DeckAny code deck. For the example, DEFAULT code deck has been chosen
OrderAny order. 1 is set by default
OriginOrigination
MatchDst Match^372(.*)$. This POSSIX syntax indicates that if the DST number starts with 372, this rule will work
ActionModeAllow
LNP/MNP

tja.ee. By specifying this field, we tell our system to look for a target DST number in TJA database of numbers

However, if we want to send a call to a terminator with original number, we need to create the second rule with the following parameters (see screenshot):

Screenshot: Termination rule

Information blockFieldValue
GeneralType

After Routing

Scr Code DeckAny code deck. For the example, DEFAULT code deck has been chosen
Dst Code DeckAny code deck. For the example, DEFAULT code deck has been chosen
OrderAny order. 1 is set by default
OriginTermination
MatchDst Match^372(.*)$. This POSSIX syntax indicates that if the DST number starts with 372, this rule will work
ActionModeAllow
Dst Replace

$lnp_original_number$. This variable indicates that if there is a target DST number in TJA database, instead of a registation number that has to be displayed according to the traffic rule depicted above, original number will be displayed instead

As a result, when we try to generate a call via Routing Analysis section, we see that intial 3721111 number according to the first rule after rate identification is transformed into 3725555, but after routing is substituted by 3721111 original number (see screenshot below):

Screenshot: Routing Analysis section