How to configure LNP/MNP?
LNP/MNP processing in JeraSoft Billing​
LNP/MNP functionality in JeraSoft Billing allows managing the ported numbers using external databases.
You need to have access to external databases to use it with our system.
There can be 2 database types to use for obtaining the external data:
No. | DB type | Connection with JeraSoft | DB |
---|---|---|---|
1 | With the file integration | Through a Data Source, Number Portability Gateways, and Traffic Processing rules | JeraSoft LNP Common, Numuri, Lithuanian, TJA (Routing Number), TJA (Owner) |
2 | Without the file integration | Only through Traffic Processing rules. Doesn't require a Data Source or Number Portability Gateways | Broadvox, PCT, Vera Networks |
Depending on the database you use (with/without the file integration), the system will perform different steps to get the ported number and route it according to the Traffic Processing rule. Therefore, configurations will differ based on the database.
When the database is local and has both ranges and single numbers present in it, we always select the most recent record by date (regardless of whether it is a single number or a range).
Use Cases configuration​
Billing by the routing number​
In this use case, we will set up the simple process of billing and routing the call based on the routing number (using TJA (RN) database as an example).
STEP 1 - Create a Data Source to connect JeraSoft to TJA (RN) database​
Go to the Data Source section, and create a Data Source with a required connection type.
Connection types you may use:
- IMAP - to import files from your mail server; for this type, the format of the file must be .csv.zip;
- Web (Numuri) - to download files in web mode; for this type, the format of the file must be .csv;
- FTP - to connect to a server;
- SSH - to connect to a server.
STEP 2 - Set up the Number Portability Gateway​
In the Gateways tab of the Number Portability section, open the gateway settings of the "TJA (RN)" collector. Select a preconfigured Data Source for the gateway.
At first, downloaded files will be displayed in the Downloads History tab. After being parsed by the Files Collector tool, numbers will be displayed in the Number Portability tab:
STEP 3 - Set Traffic Processing rules to dip for the routing number​
For this, go to the Traffic Processing section, and create two new Traffic Processing rules - one for "origination" and one for "termination" - using the settings below:
Information block | Field | Value |
---|---|---|
General | Stage | "After Client", so that the rate for the routing number will be used (a number that is stored in the LNP/MNP database) |
Origin | "origination" / "termination" respectively | |
Filters | Account | Select Originator/Terminator's Account respectively |
Dst Match | ^372(.*)$ - this POSIX syntax indicates that if the DST number starts with 372, this rule will work | |
Actions | Mode | "Allow" |
LNP/Jurisdiction | LNP/MNP | "tja.ee (Routing Number)" |
LNP Party | "Dst Party ID" |
After the needed rules will be configured, you can test the setup by doing a Routing Analysis:
Please also note that orig and term Rates, Routing Plan, and Routings Analysis for this example case use the numbers including the prefix "372". This applies only to "TJA (Routing Number)" database.
Billing by the original number​
In this use case, we will set up the process of billing the calls based on the original number, and use the dipped number for routing (using the "JeraSoft LNP Common" database as an example).
STEPS 1 & 2 - Same as previous​
STEP 3 - Set Traffic Processing rules to dip the database​
For this, go to the Traffic Processing section, and create two new Traffic Processing rules - one for "origination" and one for "termination" - using the settings below:
Information block | Field | Value |
---|---|---|
General | Stage | "After Rate", so that the rate for the original number will be used for billing; the routing number will be used for routing |
Origin | "origination" / "termination" respectively | |
Filters | Account | Select Originator/Terminator's Account respectively |
Dst Match | Indicate a pattern here in POSIX syntax for this rule | |
Actions | Mode | "Allow" |
LNP/Jurisdiction | LNP/MNP | "JeraSoft LNP Common" |
LNP Party | "Dst Party ID" |
These rules will dip the internal database if they match statistics respective to the filters specified. The number will be translated after the rating stage, which means the routing will be conducted using a translated number.
After all the needed rules are configured, you can test the setup by doing a Routing Analysis.
Returning the original number​
If there is a need to revert all LNP/MNP processing before sending the number further to a vendor for any of the cases, please enable the respective option in the Traffic Processing rule in question:
For versions 3.21&older​
To revert any processing done on the number before sending it further to a vendor, you will need to perform backward translation after the 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 | ^.*$ | To match all the numbers |
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 |
Editing the Number Range​
To edit the Number Range:
- Go to the Number Portability section.
- Click the edit button for the desired range to make changes.