Traffic Processing

Section overview

This section allows a user to configure and perform number translations. Here you can add and remove rules for Traffic Processing. The section includes 2 tabs: Traffic Processing and Orig/Term Rules:

Column	Description
ID	Rule's identification number
Stage	Stage of a rule (the rules are grouped by following stages: Initial, After Client, After Rate, After Routing)
Filters	Depending on rule parameters, a table can display the following scope of details: - Name of service, the rule is created for - Gateway, specified in a rule - Tag(s), indicated in a rule - Client's name, specified in a rule - Client's account, defined in a rule - Indicated Code - POSIX regular expression for Src number (Src Match) - POSIX regular expression for Dst number (Dst Match) - Src Prefixes (Src P Any/Src P Not) - Src Prefixes Names (Src PN Any/Src PN Not) - Dst Prefixes (Dst P Any/Dst P Not) - Dst Prefixes Names (Dst PN Any/Dst PN Not)
Action	Depending on rule parameters, a table can display the following scope of details: - Replacement for a matched rule for Src number (Src) - Replacement for a matched rule for Dst number (Dst) - List of tags added during traffic processing rule execution - Deny plank for blocking rules - LNP/MNP db specification with LNP direction and Revert LNP indication (if enabled) - Any blocked termination Clients/Accounts from the Routing Blocks section
Notes / Expiry Date / Modified by	Depending on rule parameters, a table can display the following scope of details: - Notes specified in a rule - Rule's Expiry date - User name and time when a rule was created/edited
Order	Specified order for rule execution

Functional buttons/icons presented in the section are as follows:

Button/Icon	Description
	Allows creating a new traffic processing rule
	Allows importing a .csv file with a traffic processing rule(s)
	Allows exporting a current list of rules in a .csv format
	Indicates that a rule origin is origination
	Indicates that a rule origin is termination
	Allows editing existing rules in a section list
	Allows deleting a traffic processing rule from the system

Advanced search

In the top right corner of the section above the table, an Advanced Search drop-down menu is located. By clicking on a blue downward arrow icon, a drop-down menu with the following structure is displayed:

To apply the specified search criteria, click "Search"; to cancel the applied parameters, click "Reset".

Creating a new Traffic Processing rule

To perform a number translation, click the "Add Rule" button and fill in the following fields:

General

Field	Description
Stage	Specifies at what stage a current translation rule will be applied: - Initial - execute this rule before a Client is identified - After Client - execute this rule after client identification but before rate identification - After Rate - execute this rule after rate identification but before routing - After Routing - execute this rule after routing
Order	Sets rules ordering that works within the same rule Stage
Origin	Specify the event origin: Origination or Termination
Company	Specify a Reseller for this rule to be executed under. Default - all resellers
Notes	Specify additional information about a rule
Expiry Date	Define a date when this rule will expire and will be removed from the system
Src Deck	Identify a code deck that will be used for Src codes or code names filtering
Dst Deck	Identify a code deck that will be used for Dst codes or code names filtering

tip

TP rules' stages affecting RATING:

1. Origination part:
   • Origination Initial rules
   • Origination After Client rules
   • Origination After Rate rules
2. Termination part:
   • Termination Initial rules
   • Termination After Client rules
   • Termination After Rate rules

TP rules' stages affecting ROUTING:

1. Origination Initial rules
2. Origination After Client rules
3. Origination After Rate rules
4. Termination After Routing rules

Therefore, any termination rule with stage Initial, After Client, and After Rate won't affect routing but will be used in rating.

warning

Note that this field indicates the order of rules execution only within a specified stage. It means that a rule with the Initial stage and order 1 will be executed before any other rule of the same stage with order ≥ 2.

However, such rule will be executed prior to a rule with the After Rate stage and order 0, even though the latter has a higher order, because Initial is the 1st on the stages list.

Filters

Select the required parameters for a Traffic Processing rule on the Filters menu. To cancel any filter, click on the "delete" sign next to its name.

You can start a quick search by typing filters' names in the field at the top of the Filters menu.

tip

If, for instance, the Client filter is empty, it means that this rule will implicate all clients.

General

Filter Name	Description
Service ID	Select a target from the drop-down list of all services, presented in the Services section of your JeraSoft Billing
Gateway	Select a respective VoIP gateway, for which rule is applied, from the drop-down list
Tags (Any)	A rule will work if an event has at least one of the tags, specified in this field
Tags (All)	A rule will work if an event has all tags, specified in this field
Tags (Not)	A rule will work if an event has no tags, specified in this field
Volume	Specify volume range for further processing (e.g. different billing depending on the volume of the call). The range should be set in the units of the Service

Src Party ID

Filter Name	Description
Src (Match)	In this field you may indicate POSIX regular expressions syntax, by which a number will be analyzed
Src Prefixes (Any)	A rule will work if an event has at least one of the Src prefixes (e.g., 010, 810), specified in this field
Src Prefixes (Not)	A rule will work if an event has no Src prefixes (e.g., 010, 810), specified in this field
Src Prefixes Names (Any)	A rule will work if an event has at least one of the Src prefixes names (e.g., vodafone), specified in this field
Src Prefixes Names (Not)	A rule will work if an event has no Src prefixes names (e.g., vodafone), specified in this field

Dst Party ID

Filter Name	Description
Dst (Match)	In this field, you may indicate POSIX regular expressions syntax, by which a number will be analyzed
Dst Prefixes (Any)	A rule will work if an event has at least one of the Dst prefixes (e.g., 010, 810), specified in this field
Dst Prefixes (Not)	A rule will work if an event has no Dst prefixes (e.g., 010, 810), specified in this field
Dst Prefixes Names (Any)	A rule will work if an event has at least one of the Dst prefixes names (e.g., vodafone), specified in this field
Dst Prefixes Names (Not)	A rule will work if an event has no Dst prefixes names (e.g., vodafone), specified in this field

Client

warning

Please be advised that any traffic processing rule can have either the Client OR Account field.

Filter Name	Description
Client	Specify a respective client
Account	Specify a respective account
Dst Code	Specify a destination code
Dst Code Name	Specify a destination code name
Src Code	Specify a source code
Src Code Name	Specify a source code name

Parties ID translations

Field	Description
Type	Define a type of translation: Src or Dst
Order	Specify the order of translation
Match	In this field, you may indicate POSIX regular expressions syntax (see best practice example below), by which a number will be analyzed. If an expression matches the number, the translation will occur in respective settings in the Replace field.
Replace	Replacement for a matched rule

tip

If you need to do multiple translations for the same call flow, it's better to create them all in one rule than to create multiple rules for the same type (time) of translations. That's where ordering would be useful.

Actions

Field	Description
Mode	Defines an action that will be executed if a traffic rule matches: - Allow - allow a current event to proceed. Stop further traffic processing rules within this type of rule - Allow and Continue - allow a current event to proceed. Search for the next traffic rule - Deny - deny a current event
Add Tags	Here you can add tags that will be added for events matching this rule

LNP / Jurisdiction

Field	Description
LNP/MNP	Define a provider for the LNP/MNP service, which will be dipped for translation
Revert LNP	Allows returning original numbers to vendors after routing: Enabled or Disabled
LNP Party	Define, which Party ID(s) (Src, Dst, or both) will be used for LNP dipping. To enable this feature, you need to specify the LNP/MNP field.
US NANP	Define if NANP processing will be used for LNP dipping: Enabled or Disabled
LNP Actions	Define, which actions should be applied to an event after LNP dipping: - "Owner" – add Owner as a tag to the event - "Prefix" – prepend Prefix to the selected LNP Party ID - "Routing Number" – Replace LNP Party ID with Routing Number

note

In the LNP/MNP field, you can select either tja.ee (Routing Number) or tja.ee (Owner). The difference is as follows:

• tja.ee (Routing Number) - if a traffic processing rule executes, 372+Original Number will be substituted by 372+Routing Number, specified in the TJA database.
• tja.ee (Owner) - if a traffic processing rule executes, 372+Original number will remain unchanged. Instead, a Dynamic Tag indicating an owner of the number will be added to the call.

Please find more about TJA database in the TJA Owner integration guide.

Routing blocks

Field	Description
Block Clients	Specify, which termination Clients to block for the originator, specified in the Filters block
Block Accounts	Specify, which termination Accounts to block for the originator, specified in the Filters block

Best Practice Example

To get a better understanding of how the Src/Dst Match and Src/Dst Replace fields work, let's consider the following example:

If our Src/Dst number is "123#456", the Src/Dst Match field is ^123#(.*)$ and the Src/Dst Replace field is 789\1, the resulting number will be "789456".

That's because the ^123#(.*)$ expression tells the system that from "123#456" number it must remember only the "(.*)" part, which stands for "456".

Now, in the Src/Dst Replace field, we have 789\1, which means that instead of "123#456", it must insert "789" + add \1 that equals "(.*)". Therefore, our resulting number will be "789+456=789456".

These translation rules use the PostgreSQL regular expressions syntax (based on POSIX regex with some extensions). For more information, please refer to the PostgreSQL documentation portal.

In addition, in the Src/Dst Replace field you can insert random number with fixed digit length using the $rnd(xxx-yyy)$ variable, where "xxx" - start number and "yyy" - end number of the range. For example, $rnd(050-950)$ will be replaced by a 3-digit random number from 50 to 950.

Rules import

A user can import a .csv file containing a list of Traffic Processing rules. To import the file, click the "Import" button and a pop-up window with the following structure will appear:

File process

Field	Description
Select a file for import	Select a .csv file to import a traffic processing rule from
Fields Delimiter	Specify a delimiter symbol here. The possible options are: - Autodetect (selected by default) - , - ; - Tab

Import config

Field	Description
Import Mode	Specify what to do with the current traffic processing rules: - Keep previous data - new rules will be added to the old ones (selected by default) - Purge all other rules - old rules will be deleted and substituted by the new ones

When all fields are filled in, click "Process>>". You will be transferred to the second step to indicate the default values in respective fields and specify rows and columns. To finish importing, click "Process>>" again.

Rules export

By clicking on the "Export" button you can download a current list of rules in a .csv file.