...
Screenshot: New Traffic Processing rule
Information block | Field | Description |
---|
General | 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 | |
. The first matched rule will stop further number translationsthat works within the same rule Stage. Panel |
---|
borderColor | #ffffb3 |
---|
bgColor | #ffffb3 |
---|
borderWidth | 2px |
---|
| Attention Note that this field indicates the order of rules execution only within a specified |
|
typestage. It means that a rule with the Initial |
|
type stage and order 1 will be executed before any other rule of the same |
|
type stage with order ≥ 2. However, such rule will be executed prior to a rule with the After Rate |
|
type stage and order 0, even though the latter has a higher order, due to the fact that Initial is the 1st on the |
|
types |
Origin | Specify the event origin: |
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 |
MatchFilters | Select the required parameters for a traffic processing rule on the |
MatchFilters menu. To cancel any filter, click on the delete Image Modified sign next to its name. You can start a quick search by typing filters' names in the field at the top of the |
Match Filters menu. Panel |
---|
borderColor | #ccffcc |
---|
bgColor | #ccffcc |
---|
borderWidth | 2px |
---|
borderStyle | solid |
---|
| Image Modified Tip If, for instance, the Client filter is empty, it means that this rule will implicate all clients. |
|
General |
---|
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 |
Scr Party ID |
---|
Src (Match) | In this field you may indicate POSIX regular expressions syntax, by which a number will be analyzed |
. If an expression matches the number, the translation will occur in respective settings in the SRC Replace field. |
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 |
---|
Dst (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 Dst Replace field. |
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 |
---|
Client | Specify a respective client Panel |
---|
borderColor | #ffffb3 |
---|
bgColor | #ffffb3 |
---|
borderWidth | 2px |
---|
| Attention Please be advised that any traffic processing rule can have either the Client or Account field. |
|
Account | Specify a respective account |
Dst Code | Specify a destination |
code (use * as a wildcard)Parties ID Translations | Actioncode |
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 | Type | Define a type of translation: |
Order | Specify the order of translation 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. |
|
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. |
Actions | 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.
|
Src Replace | Replacement for a matched rule. For this field to work, the Scr Match filter must be used in the Match information block. |
Dst Replace | Add Tags | Here you can add tags that will be added for events matching this rule |
Replacement for a matched rule. For this field to work, the Dst Match filter must be used in the Match information block. |
Set Service | Allows to change a specified service to another one while processing them |
Add Tags | Here you can add tags that will be added for events matching this rule LNP / Jurisdiction | LNP/MNP | Define a provider for the LNP/MNP service, which will be dipped for translation Panel |
---|
borderColor | #ffffb3 |
---|
bgColor | #ffffb3 |
---|
borderWidth | 2px |
---|
| Attention In the VCS 3.17.0, a new feature regarding TJA database has been added. Starting from this version, while creating a new rule, in the LNP/MNP field, a user 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 here. |
|
Revert LNP | Allows returning of original numbers to vendors" case realization: |
LNP |
DirectionParty | 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 |
Processing | Define if NANP processing will be used for LNP dipping: |
Routing Blocks | Block Clients | For the case where you need to block certain terminator/-s for an originator, now there is a Routing Blocks block. Here you can specify, which vendors (Clients or Accounts entities) to block for the originator, specified in the Filters block |
Block Accounts |
|
Panel |
---|
borderColor | #ccffcc |
---|
bgColor | #ccffcc |
---|
borderWidth | 2px |
---|
borderStyle | solid |
---|
|
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. |
...