Local number portability and other special cases

While call processing (routing, billing) based on a phone number match to a phone prefix (when each phone prefix defines a group of phone numbers such as 420 – Czech Republic; 4202 – Czech Republic, Prague; 420604 – Czech Republic, T-Mobile and so on) is used in the majority of telecommunications services, in some cases it is not applicable.

This is a very common example of a situation where the rate or call routing cannot be determined simply by looking at the phone number itself. Local number portability (LNP) is widespread throughout Europe, the US and other countries around the world. It means that when a user migrates from one telco (fixed or mobile operator) to another, he is able to take his existing phone number with him. So although his phone number looks as if it belongs to one company (e.g., mobile operator A), in reality his calls should be routed to another company (mobile operator B). Most importantly, anyone making a phone call to this number should be charged according to the termination rates defined by B.

The only way to determine whether a number has been ported or not is to check it against the ported numbers database. These databases differ for each individual country, and have a variety of formats and access API structures. However, PortaBilling offers a flexible method for handling LNP, using a system of number translation plug-ins that satisfy the requirements valid in various countries.

A basic plug-in for LNP (where all ported numbers are imported into a local database on the PortaBilling server) is supplied along with the system. When a call processing request arrives to PortaBilling, the billing engine checks if the original number dialed by the user is found on the list of ported numbers. If there is no match, call setup proceeds as usual.

However, let us assume that a customer has dialed a number that originally belonged to the mobile operator Telenor, but was recently ported to another operator, Netcom. In this case, there will be an entry in the LNP table, and the ID of the phone number’s new owner will be extracted (4792, in this example). This ID could be a symbolic name (e.g., Netcom), but usually it is more convenient to use a phone prefix or phone number belonging to that operator. The following will then happen:

• The billing engine looks up routing to a destination identical to the number owner’s ID (4792, in this case), and the call is routed directly to the Netcom network.
• The same ID is used to calculate your termination costs and apply charges to your customer, i.e. he will be charged according to Netcom’s rates.
• The originally dialed phone number is stored in the CDR record, but is linked to the destination used for charging the call. So the end user will see “4791555123 – Norway, Netcom mobile” in the CDR report.

If a different way of extracting information from the LNP database is required for a given country (for instance, real-time lookup in a central database), you can create your own LNP plug-in and use it with PortaBilling.

The Number_Portability table in PortaBilling is described in the The Number Portability Table Description section.

In the United States and Canada, the only way to determine whether a number has been ported is to subscribe to an LRN dipping service that looks up ported numbers in real-time from a remote database.

Since PortaSwitch is connected with Telnyx, an LRN dipping service provider, it provides this opportunity to determine whether a number has been ported – and it routes the call to the most suitable and most economic vendor.

When a call processing request arrives at PortaBilling, the following happens:

1. PortaBilling checks the destination number and if necessary sends a request to the LRN service provider (e.g., PortaBilling will only check US & Canadian numbers and skip the rest).
2. If the number is not ported, the provider’s response indicates that the call should be routed, based on the original dialed number. However, let us assume that a customer dials a number (for example, 12063131234), that originally belonged to the mobile operator T-Mobile, but was recently ported to AT&T. In this case, the provider returns the LRN number (e.g., 12065549080) and PortaBilling uses it to route the call directly to the AT&T network.
3. When the call finishes, the same LRN number is used to calculate the termination costs and then the charges are applied to the customer – in this case, according to AT&T’s rates. The number originally dialed is stored in the CDR record, but is linked to the destination used for charging the call. So the end user will see “12063131234 – USA, AT&T” in the CDR report.
4. In addition, to improve speed and flow, PortaBilling will temporarily add an entry for this number and its corresponding LRN number to the list of ported numbers.

Since PortaSwitch is already interconnected with Telnyx, it can offer a flexible plug-in solution that allows for easy integration with other LRN service providers.

To enable the number portability framework, set the option FeatureModules.NumberPortability to Yes on the Configuration server web interface.

A service provider can now perform the following operations directly from the unified PortaBilling web interface:

• Port a number to PortaBilling from another telecom (port-in);
• Port a number from PortaBilling to another telecom (port-out).

This feature is convenient for customers who want to change telephone providers but keep their original numbers. This framework provides the option to port numbers via Neustar Inc. – a major player in the number portability market.

In order to port-in a number, a PortaBilling user sends a request via the Port in button on the Edit Account page. In the request dialog window the following parameters must be mentioned:

• The phone number that the customer wants to use;
• The service password or PIN number of a customer’s account within the previous service provider’s system;
• The date in the PortaBilling user’s time zone by which this request must be completed;
• The customer’s account within the previous service provider’s system.

‎PortaBilling sends the porting request to Neustar and waits for confirmation. Neustar requests the number from the telecom and when confirmation is received, the number is replaced in PortaBilling and the customer can receive calls at the new number.

When PortaBilling receives a port-out request, it searches the account with the requested number. If the account is found, PortaBilling terminates it and informs Neustar about the number’s availability. Neustar then sends this information to the telecom that requested the number. So now that the ported number belongs to this telecom, calls are routed to the new telecom’s network.

Let’s consider the following example:

John Doe is a customer of X-Telecom and has the number 1212555123. Due to questionable connection quality, he decides to switch from X-Telecom to GlobalNet Telecom. He calls GlobalNet Telecom, asks to use their services, but declares his wish to keep his old number. The GlobalNet Telecom operator informs John Doe that the service will be available starting January 1st. Then the operator creates an 1818123555 account for John Doe in GlobalNet Telecom, makes the porting request via PortaBilling to Neustar, and when the request is confirmed, the system replaces 1818123555 with 1212555123. So while John Doe continues to use his old 1212555123 number, the calls are now charged according to GlobalNet Telecom’s tariffs.

The PortaBilling administrator may monitor all requests from his system (the Port-in panel) and to his system (Port-out panel) by clicking the Infrastructure, then Inventory and Number porting buttons on the navigation menu.

PortaBilling can receive number porting requests via the HTTP/HTTPS protocols.

Thus, this new feature makes it possible for customers to use their original numbers, regardless of the telecom. Number portability works through Neustar Inc., but if necessary, PortaBilling can collaborate with other number porting companies via additional plug-ins.

In some countries, for example, the Dominican Republic, service providers are obliged to pass number portability parameters when initiating outgoing domestic calls. The vendors are allowed to drop calls that contain no number portability parameters. This can negatively influence the quality of service provided to customers which reduces customer satisfaction, making service providers lose customers and suffer financial loss.

PortaSip can add number portability parameters npdi (number portability database dip indicator) and rn (routing number) to outgoing calls. The vendor can determine that a number lookup in the PortaSwitch local ported numbers database is made and whether that number is ported.

The parameters of number portability are as follows:

• npdi – This indicates that number lookup in the PortaSwitch local ported numbers database was made.
• rn – This defines a target prefix used instead of the originally dialed number to authorize, rate, and route the call. It contains the value defined in the origin field in the Number_Portability table.

If the call is to be routed to a ported number, PortaSIP adds both a npdi and a rn parameter with the value defined in the origin field in the Number_Portability table.

If the call is to be routed to a regular domestic non-ported number, PortaSIP adds a npdi parameter to the outgoing INVITE request. To make this happen, the administrator needs to add domestic non-ported destinations or numbers to the Number_Portability table and specify the “=” value in the origin field. For example, for the Dominican Republic, the administrator needs to add prefixes 1809, 1829, and 1849.

Vendors can drop calls to numbers that cannot be ported (like toll-free or emergency numbers) if they contain the number portability parameter npdi in the incoming INVITE request. As a result, the end users may fail to reach toll-free or emergency numbers. To avoid dropped calls to such numbers, you can skip adding the number portability parameter npdi to calls to specific destinations and numbers.

To skip adding the number portability parameter npdi to calls to a certain destination or number (for example, 1809200 destination for toll-free numbers), the administrator needs to add this destination or number to the Number_Portability table and specify the “!” value in the origin field.

For outgoing calls to destinations and numbers that are not present in the Number_Portability table, PortaSIP adds no number portability parameters.

Let’s consider the example of John Doe, a service provider’s customer, who makes calls to a ported number, to a regular domestic non-ported number, and to a toll-free number.

Let’s say the administrator enables local number portability functionality in PortaSwitch and imports the list of ported numbers to the PortaSwitch database. The administrator also enables PortaSIP to pass the number portability parameters in the outgoing INVITE requests. Then the administrator adds particular numbers and destinations to the Number_Portability table.

John Doe makes a call to 18295557777. This number originally belonged to a mobile operator Claro, but has been recently ported to Viva mobile operator. PortaBilling looks up the number in the PortaSwitch database using the longest match and finds 18295557777 added as a ported number that now belongs to Viva. For this reason, 18097262222 must be used for further routing, and the call must be charged according to Viva’s rates. Thus, PortaSIP passes number portability parameters in the outgoing INVITE request like this:

INVITE 
sip:18295550000;rn=18097262222;npdi=yes@190.123.72.1:5060;user=
phone SIP/2.0.

Then John Doe makes a call to 18092555000. PortaBilling looks up the destination in the PortaSwitch database using the longest match and finds the 1809 destination added as a regular domestic not-ported number. Thus, PortaSIP passes a number portability parameter npdi in the outgoing INVITE request like this:

INVITE 
sip:18292555000;npdi=yes@190.123.72.1:5060;user=phone SIP/2.0.

The next call John Doe makes is to 18092005550, a toll-free number. PortaBilling looks up the destination in the PortaSwitch database using the longest match and finds the 1809200 destination added as an exception. Thus, PortaSIP does not pass number portability parameters in the outgoing INVITE request:

INVITE 
sip:18092005550@190.123.72.1:5060;user=phone SIP/2.0.

• Service providers comply with local regulations.
• Service providers can provide their customers with good quality service (domestic calls) and suffer no financial loss.
• Service providers ensure that mission-critical calls and calls to toll-free numbers reach the intended destination.

To enable PortaSIP to pass the number portability parameters during the outgoing call, open your service policy for voice calls and do the following:

1. On the Attributes panel, select SIP headers.
2. On the SIP headers panel, check the box next to the Out routing number mode option and select npdi from the list.
3. Click Save on the toolbar.