Prohibit the routing of calls with invalid CLI

Calling Line Identification (CLI) provides information about the caller and helps the called party decide whether to answer the call. In the telecom market, there is a growing effort to ensure the validity of CLI transmitted through the network. For instance, a valid CLI should be an E.164 phone number of predetermined length consisting of a valid country code, area or mobile network code, and line number. To compel service providers to deliver valid CLI numbers, vendors may refuse to process calls with the CLI that doesn’t meet the requirements or may apply significant surcharges for terminating such calls.

From MR108, you gain tighter control of routing calls with invalid CLI and can simply prevent such calls from going to a specific vendor (if it is known that the vendor applies surcharges or blocks such calls). Suppose some of your customers use invalid CLI due to misconfiguration ‒ for example, an on-premise PBX sends an extension number such as “1356” as CLI instead of the E.164 number such as “27134567890”. When you route customers’ calls to vendors, you can now prohibit routing calls with invalid CLI, thus avoiding the vendor’s surcharges associated with such calls.

Avoiding revenue loss on customers with misconfigured CLI.

• • The CLI validation in PortaBilling supports E.164 numbers only, so you first need to configure the number translation from the local format (e.g., “0134567890”) into E.164 format (e.g., “27134567890”).
  • If CLI does not match any manually added call validation rule, it will be automatically sent for validation by an external tool – Google’s libphonenumber library.
  • Toll-free and premium numbers are identified as invalid CLI by Google’s libphonenumber library.
  • The CLI numbers for emergency calls are not validated at all, so these calls are always allowed regardless of whether calls with invalid CLI are allowed.
  • This feature can be used for voice calls service only.
  • To use the CLI validation in the standalone mode (when the main site in site-redundant PortaSwitch goes down), a web instance must be deployed on the secondary site.

Step 1. Set up the CLI validation on the Configuration server web interface:

1.1 Set the CallerIdValidation.Enable option to Yes.

1.2 If needed, configure the call validation rules within the CallerIdValidation.Rules option (a rule includes Rules_directive and Rules_patern). CLI will be checked against these rules, and if there’s no matching rule, such CLI will be sent for validation to Google’s libphonenumber library.

By default, there is a single rule “allow %”, which means that any E.164 number is considered valid. Since a CLI in a format other than E.164 will not match this rule, such a CLI will be validated by Google’s libphonenumber library.

Step 2. Prohibit routing calls with invalid CLI via specific vendor connections on the PortaBilling web interface.

Go to Vendor > Connections > open a specific connection > Service configuration > turn on the toggle Route calls with valid CLI only.

When a user makes a call, PortaSIP sends the CLI to PortaBilling for validation. First, the CLI is checked against manually added validation rules that you can specify on the Configuration server web interface (see step 1.2).

You can add your own CLI validation rules in the order they should be used. The rules in the list are evaluated top-to-bottom. Once a matching rule is found, the remaining rules are ignored.

A CLI validation rule consists of:

1. An action (CallerIdValidation.Rules_directive), such as:
   • allow ‒ to consider numbers of the specified pattern valid (so they are not sent to Google’s libphonenumber library for validation)
   • validate ‒ to send numbers of the specified pattern to Google’s libphonenumber library and check the number against its rules
   • deny ‒ to consider numbers of the specified pattern invalid (so they are not sent to Google’s libphonenumber library for validation)
2. Number pattern (CallerIdValidation.Rules_patern), which can include valid E.164 symbols, such us digits (0-9), lowercase letters (a-f), uppercase letters (A-F), and the symbols ‘*’ and ‘#’. Additionally, the pattern may include wildcards: the lowercase ‘x’ or underscore ‘_’ representing a single E.164 symbol, and the ‘%’ symbol representing any amount of E.164 symbols.

For example, if you add the rule “allow 27xxxxxxxxx”, it means that only numbers starting with 27 and having 11 digits are valid.

If the CLI in the E.164 format doesn’t match any rule that you specified, then this number will be sent to Google’s libphonenumber library for validation. If you want to treat all E.164 numbers that don’t match any rule as invalid, you can add the rule “deny %” to the bottom of the list.

Your rule list may look as follows:

1. “allow 27xxxxxxxxx” ‒ the numbers starting with 27 and having exactly 11 digits are valid
2. “deny 27%” ‒ the numbers starting with 27 and having length other than 11 digits are invalid
3. “validate xxxxxx%” ‒ the numbers that do not start with 27 and have more than 6 digits will be sent for verification by Google’s libphonenumber library
4. “deny %” ‒ the numbers that do not match any rules above are invalid

In case the CLI is identified as invalid, vendor connections that have the option Route calls with valid CLI only enabled, will be excluded from the routing list for this call.

The SIP INVITE request may include the following headers for CLI: PAI (P-Asserted-Identity), RPID (Remote-Party-ID), and “From”:

1. Initially, PortaSIP attempts to use the CLI value included in the PAI header.
2. If PAI is absent, then PortaSIP uses CLI in the RPID header.
3. If RPID is absent, PortaSIP uses CLI in the “From” header.

Regardless of where the CLI value is found, it is always sent to PortaBilling for validation.