US Routing & Billing Configuration
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/
Also, please ensure the Jurisdictional Manager from System Service 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.
Stageâ
Please select "After Client" or "After Rate". Reason: 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â
To filter only USA numbers.
- Type: "Src"
- Order: select order
- Match:
^\+?1.{10}$ - Replace: leave empty
- Type: "Dst"
- Order: select order
- Match:
^\+?1.{10}$ - Replace: leave empty
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.
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.
Stageâ
Please select "After Client" or "After Rate". Reason: 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: select order
- Match:
^(?!\+1.{10}).*$(to filter non-USA source numbers) - Replace: leave empty
- Type: "Dst"
- Order: select order
- Match:
^\+?1.{10}$(to filter only USA destination numbers) - Replace: leave empty
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 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 and 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.
Stageâ
Please select "After Client" or "After Rate". Reason: 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â
- Src Match:
^\+?1.{10}$ - Dst Match:
^\+?1.{10}$
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.
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 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 tg 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:
Stageâ
Please select "After Client". Reason: Because this processing needs to be done prior to Rate identification.
Parties IDs Translationsâ
- Tags (all): Specify needed tags (ex.: "interstate", "intralata").
Actionsâ
- 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 and dst_lnp_original_number. The following rule needs to be configured for Origin: termination:
Stageâ
Please select "After Routing". Reason: to return an original number to the vendor after the Routing Table has been generated.
Parties IDs Translationsâ
- Src Match:
^.*$ - Dst Match:
^.*$
Actionsâ
- 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.
Stageâ
Please select "After Client" or "After Rate". Reason: 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â
- Src Match:
^(?!\+1.{10}).*$(to filter non-USA source numbers). - Dst Match:
^\+?1.{10}$(to filter only USA destination numbers).
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 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.
Stageâ
Please select "After Routing". Reason: to return an original number to the vendor after the Routing Table has been generated.
Parties IDs Translationsâ
- Dst Match:
^.*$(to match all the numbers).
Actionsâ
- 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