Docs for all releases
In this article
The following guide systematizes the configuration of routing and billing of the USA-specific traffic through the JeraSoft platform. It includes examples of Traffic Processing rules setup, as well as LNP provider settings, explanations as to when exactly to run dipping processes, and why.
To configure routing correctly, we need to understand the specifics of the traffic flows' direction. In general, there are basic rules to execute translations for USA-specific routing, i.e. defining numbers' origin and returning original numbers to vendors. The exact setup varies based on the type of traffic. Below you will find the explanations for the three main cases of the USA-specific routing.
Initial Database Setup
In order to use US Jurisdictional Billing & Routing, you have to populate LERG/LCA databases. JeraSoft does not provide these database files within the initial deployment. You have to get your own access to these databases. Required files are:
- LERG 6
- LERG 8
- LCA
- LCA Clusters
These files have to be uploaded to the following location on the JeraSoft Billing server:
/opt/jerasoft/vcs-data/jurisdictional_files/
Note
Also, please ensure the Jurisdictional Manager from System Services is enabled.
Domestic USA calls
The first stage here is to define whether both source and destination numbers are USA numbers. For this, we need to create a Traffic Processing rule with the following parameters. You will need to configure two such rules: one for Origin: origination, and one for Origin: termination.
| Field | Value | Reason |
|---|---|---|
| Stage | After Client or After Rate | If you want to have jurisdiction-specific billing for the translated numbers, these rules should be of type After Client. If you just route them differently - After Rate. |
| Parties IDs Translations | ||
| Type | Src | To filter only USA numbers. Please note This and following examples of Traffic Processing rules are referring to USA numbers formatted with '1' or '+1' in the beginning and the following 10 digits. If your switching equipment processes numbers formatted differently, please change the Match filters accordingly or refer to our Support for detailed instructions. |
| Order | {order} | |
| Match | ^\+?1.{10}$ | |
| Replace | null | |
| Type | Dst | |
| Order | {order} | |
| Match | ^\+?1.{10}$ | |
| Replace | null | |
| Actions | ||
| Mode | Allow and Continue | To keep looking for other related Traffic Processing rules. |
| LNP/MNP | {select_your_lnp_db} | The located USA formatted numbers need to be dipped to the respective LNP database. Please refer to our Number Portability article for instructions as to LNP/MNP configurations and the available databases. |
| LNP Party | Both Party IDs | To dip both Src and Dst Parties IDs. |
| Revert LNP | Enabled | To revert parties' IDs after all processing is complete. |
| US NANP | Enabled | Apart from LNP dipping, calls inside the USA should be NANP processed. Thus, in the same rule, you want to set NANP Processing to Enabled. |
How NANP Processing works?
NANP Processing broadens the area detection functionality for the Jurisdictional Billing module of JeraSoft. It works for those clients who have access to the LERG database. The system will be able to pull data on state, lata, MTA areas and local. For that, we use the LERG 6, LERG 8, and LCA databases.
This functionality is available in the Traffic Processing section of the billing system. If enabled, it will check the filtered numbers (specified in the Match section of the TP rule) through the North American Numbering Plan. You can set it up in the respective field of the rule creation form.
When the first rule executes, it assigns a bunch of tags to calls (simultaneously up to 4 tags can be assigned to a call). These tags are interlata, intralata, interstate, intrastate (and their combinations), interMTA, intraMTA, and local.
Figure 1: Example of number processing with LNP dipping and subsequent original number returning
Calls into USA
The first stage here is to define the Dst Party ID as only it will be the USA number in this case. Thus, in a Traffic Processing rule, we'll need to set up only Dst party dipping. You will need to configure two such rules: one for Origin: origination, and one for Origin: termination.
| Field | Value | Reason |
|---|---|---|
| Stage | After Client or After Rate | If you want to have jurisdiction-specific billing for the translated numbers, these rules should be of type After Client. If you just route them differently - After Rate. |
| Parties IDs Translations | ||
| Type | Src | |
| Order | {order} | |
| Match | ^(?!\+1.{10}).*$ | To filter non-USA source numbers. |
| Replace | null | |
| Type | Dst | |
| Order | {order} | |
| Match | ^\+?1.{10}$ | To filter only USA destination numbers. |
| Replace | null | |
| Actions | ||
| Mode | Allow and Continue | To keep looking for other related Traffic Processing rules. |
| LNP/MNP | {select_your_lnp_db} | The located USA formatted numbers need to be dipped to the respective LNP database. Please refer to our Number Portability article for instructions as to LNP/MNP configurations and the available databases. |
| LNP Party | Dst Party ID | To dip only the Dst Party ID. |
| Revert LNP | Enabled | To revert the Dst Party ID after all processing is complete. |
Figure 2: Example of number processing with LNP dipping and subsequent original number returning
Calls from USA
In this case, we don't need to translate numbers as the routing and billing are usual for international calls. The system will take the rates for A-Z destinations and route the calls based on the preconfigured Routing Plans.
Figure 3: Example of number processing with LNP dipping and subsequent original number returning
For versions 3.21&older
Domestic USA calls
The first stage here is to define whether both source and destination numbers are USA numbers. For this, we need to create a Traffic Processing rule with the following parameters. You will need to configure two such rules: one for Origin: origination, and one for Origin: termination.
| Field | Value | Reason |
|---|---|---|
| Type | After Client or After Rate | If you want to have jurisdiction-specific billing for the translated numbers, these rules should be of type After Client. If you just route them differently - After Rate. |
| Match | ||
| Src Match | ^\+?1.{10}$ | To filter only USA numbers. Please note This and following examples of Traffic Processing rules are referring to USA numbers formatted with '1' or '+1' in the beginning and the following 10 digits. If your switching equipment processes numbers formatted differently, please change the Match filters accordingly or refer to our Support for detailed instructions. |
| Dst Match | ^\+?1.{10}$ | |
| Action | ||
| Mode | Allow and Continue | To keep looking for other related Traffic Processing rules. |
| LNP/MNP | {select_your_lnp_db} | The located USA formatted numbers need to be dipped to the respective LNP database. Please refer to our Number Portability article for instructions as to LNP/MNP configurations and the available databases. |
| LNP Direction | Both Party IDs | To dip both Src and Dst Parties IDs. |
| NANP Processing | Enabled | Apart from LNP dipping, calls inside the USA should be NANP processed. Thus, in the same rule, you want to set NANP Processing to Enabled. |
How NANP Processing works?
NANP Processing broadens the area detection functionality for the Jurisdictional Billing module of JeraSoft. It works for those clients who have access to the LERG database. The system will be able to pull data on state, lata, MTA areas and local. For that, we use the LERG 6, LERG 8, and LCA databases.
This functionality is available in the Traffic Processing section of the billing system. If enabled, it will check the filtered numbers (specified in the Match section of the TP rule) through the North American Numbering Plan. You can set it up in the respective field of the rule creation form.
When the first rule executes, it assigns a bunch of tags to calls (simultaneously up to 4 tags can be assigned to a call). These tags are interlata, intralata, interstate, intrastate, interMTA, intraMTA, and local. Depending on rates for which jurisdictions your vendors send you, you might or might not need tag combinations. If you need them, you'll have to configure the rule/s for creating those combinations. I.e., if your vendors provide rates for interlata-intrastate as a combination (set it as a tag in the Add Tags field), you'll have to create a rule that will combine the tags interlata and intrastate (set in Match filters).
You will need to configure two rules for each tag combination: one for Origin: origination, and one for Origin: termination. The parameters needed are:
| Field | Value | Reason/Example |
|---|---|---|
| Type | After Client | Because this processing needs to be done prior to Rate identification. |
| Match | ||
| Tags (all) | {specify_needed_tags} | Ex.: interstate, intralata |
| Action | ||
| Mode | Allow and Continue | To keep looking for other related Traffic Processing rules. |
| Add Tags | {specify_tag_combinations} | Ex.: interstate-intralata |
The next stage is returning an original number to a vendor, not the translated one. For that, you will need to perform backward translation after routing has been done. The system supports defined variables for original numbers: $src_lnp_original_number$ & $dst_lnp_original_number$. The following rule needs to be configured for Origin: termination:
| Field | Value | Reason |
|---|---|---|
| Type | After Routing | To return an original number to the vendor after the Routing Table has been generated. |
| Match | ||
| Src Match | ^.*$ | To match all the numbers. |
| Dst Match | ^.*$ | |
| Action | ||
| Mode | Allow | To allow such traffic for further routing. |
| Src Replace | $src_lnp_original_number$ | This placeholder replaces the translated source number with an original one that it was before dipping. |
| Dst Replace | $dst_lnp_original_number$ | This placeholder replaces the translated destination number with an original one that it was before dipping. |
Figure 1: Example of number processing with LNP dipping and subsequent original number returning
Calls into USA
The first stage here is to define the Dst Party ID as only it will be the USA number in this case. Thus, in a Traffic Processing rule, we'll need to set up only Dst party dipping. You will need to configure two such rules: one for Origin: origination, and one for Origin: termination.
| Field | Value | Reason |
|---|---|---|
| Type | After Client or After Rate | If you want to have jurisdiction-specific billing for the translated numbers, these rules should be of type After Client. If you just route them differently - After Rate. |
| Match | ||
| Src Match | ^(?!\+1.{10}).*$ | To filter non-USA source numbers. |
| Dst Match | ^\+?1.{10}$ | To filter only USA destination numbers. |
| Action | ||
| Mode | Allow and Continue | To keep looking for other related Traffic Processing rules. |
| LNP/MNP | {select_your_lnp_db} | The located USA formatted numbers need to be dipped to the respective LNP database. Please refer to our Number Portability article for instructions as to LNP/MNP configurations and the available databases. |
| LNP Direction | Dst Party ID | To dip only the Dst Party ID. |
The second stage here will be returning an original number to a vendor. The backward translation here needs to be done after routing only for the destination number (using the $dst_lnp_original_number$ variable). The following rule needs to be configured for Origin: termination.
| Field | Value | Reason |
|---|---|---|
| Type | After Routing | To return an original number to the vendor after the Routing Table has been generated. |
| Match | ||
| Dst Match | ^.*$ | To match all the numbers. |
| Action | ||
| Mode | Allow | To allow such traffic for further routing. |
| Dst Replace | $dst_lnp_original_number$ | This placeholder replaces the translated destination number with an original one that it was before dipping. |
Figure 2: Example of number processing with LNP dipping and subsequent original number returning
Calls from USA
In this case, we don't need to translate numbers as the routing and billing are usual for international calls. The system will take the rates for A-Z destinations and route the calls based on the preconfigured Routing Plans.
Figure 3: Example of number processing with LNP dipping and subsequent original number returning
Overview
Content Tools