Skip to main content

New features of Traffic Processing

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:

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

Traffic Processing rules

Origination rule "ID number 1" 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 termination rule "ID number 2" 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 number 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 number 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).

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

Origination rule

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

Termination rule

Information blockFieldValue
GeneralTypeHere, 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
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):

Routing Analysis section