Sippy Software, Inc.

Practical Role of Number Translation

Number translation plays a very important role in today’s VoIP world by allowing networks with different and often conflicting numbering conventions to communicate. In an ideal world there would be only one numbering standard, and everybody would adhere to it, but unfortunately this is not the case in the real world.

When it comes to plain old PSTN, almost every country has its own incompatible standards for dialing local, long distance and international numbers. Any VoIP provider who wants to provide services to customers in different countries will face the need to cope with the differences and provide a consistent numbering plan in the system, still letting users dial numbers in the way they are used to.

Many VoIP carriers, require their customers to send calls to them using "special” numbering plans (country-specific plans, technical prefixes, etc).  To cope with all real-world scenarios, the Softswitch provides a flexible number translation mechanism whose task is to compensate for differences in the dialing conventions of individual users and to adhere to Vendor’s requirements. The diagram below illustrates how different CLD number translations are applied during a typical call.

1. The customer dials a phone number in his SIP Phone. He enters the phone number in the same format he uses on a normal phone. The number is delivered to the Softswitch, which performs authentication, as a result identifying the corresponding Account in the system. In the example above, a customer who is physically located in Vancouver, Canada wants to call number 123456 in Dnepropetrovsk, Ukraine.
2. After identifying the calling Account the Softswitch translates the number using a CLD Translation Rule specific for the Account. In the example above this process results in the international dialing prefix 011 to be removed. The CLD becomes 380-56-123456 – number in the E.164 format.
3. The Softswitch then passes the resulting number into routing logic, which builds a list of possible destinations (Connections) towards which it would terminate the call. In the example above, two such Connections have been identified – Connection “A” and Connection “B”.
4. The called number in E.164 format is passed to the routing engine along with the set of Connections that can accept this call, and along with the CLD Translation Rules corresponding to each of those Connections. The routing engine tries to send the call to each of those Connections until it is either connected or there are no more Connections to try. In the example above, in the process of trying to reach the final destination for the call, the Softswitch first tries to send it to Connection A, which corresponds to the gateway connected to the PSTN in the same area where the destination number is. Therefore, applying the CLD Translation Rule for Connection A removes country code and local area code from the E.164 number and it becomes simply 123456 (4a). If for some reason, the call is not going through, the Softswitch attempts the next Connection (Connection B) from the routing list. Connection B corresponds to the gateway connected to the PSTN in the same country, but in a different area code. Again, before sending the call to the PSTN gateway the Softswitch takes the CLD in E.164 format and associates the corresponding CLD Translation Rule, which in this case removes the country code (380) and replaces it with long-distance access code (80). The CLD becomes 80-56-123456.

How Number Translation Works

The Softswitch is built with the assumption that all numbers inside the system are in the E.164 format, that is, country code followed by the area code followed by the local number followed by the optional extension number. However, as the previous section explains, in the real world, calls arrive in various formats that need to be converted into E.164 format, etc.

For the purpose of doing Account-specific to E.164, and then E.164 to Vendor-specific conversions, the system provides three different features that allow translation of called or calling number at different stages of the call through the switch.

There are 6 basic types of number translation available in the Softswitch:

• Incoming Destination Number Translation in Authentication Rule. Configured at authentication rule level, is applied to the number called after matching specific authentication rules and before per-Account Number Translation. Configured via the CLD Translation Rule parameter in the Authentication Rules of the Account or via the CLD Translation Rule parameter in DID preferences (from 4.5 version)
• Incoming Calling Number Translation in Authentication Rule. Configured at authentication rule level, is applied to the calling number after matching specific authentication rules and before per-Account Number Translation. Configured via the CLI Translation Rule parameter in the Authentication Rules of the Account or via the CLI Translation Rule parameter in the Authentication Rules of DID.
• Incoming per-Account Destination Number Translation. Configured on a per-Account basis, is applied to the number called before any call rating and routing decisions are made. Configured via per-Account CLD Translation Rule Account parameter.
• Incoming per-Account Calling Number Translation. Configured on a per-Account basis, is applied to the calling number before any call rating and routing decisions are made. Configured via two per-Account parameters: CLI and Force CLI. If Force CLI is "ON", then the CLI of all incoming calls matched to that Account will be replaced with the value of the CLI parameter.
• Outgoing Destination Number Translation. Configured on a per-Connection basis, is applied to the number called.  Is obtained after applying the number translation rule and after the rating and routing decisions are made but before a call is sent to the Connection. Configured via CLD Translation Rule parameter for each Connection or Outbound CLD in Trunks.
• Outgoing Calling Number Translation. Configured on a per-Connection basis, is applied to the original calling number before a call is sent to that connection. Configured via per-Connection CLI Translation Rule parameter.

Extended picture as of Sippy 2020 release

Translation Rule Syntax

Translation rules are specified either as the replacement numbers or as a set of regular expressions with Python syntax in the following two forms:

• s/<match what>/<replace with>/
• s/<match what>/<replace with>/g

The former will match/replace a single matched occurrence or pattern, while the latter – all of them. Several expressions may be used in one translation rule; in this case they need to be separated by semicolon (“;”).

There are several “special” symbols in <match what> which allow you to define matching rules, for example ^ matches the beginning of the string, while $ - matches the end, so that for example ^1 will only match 1 as the first character of the string, while 9$ will only match 9 as a last character.

For example, the following translation rule can be used to strip the leading 011 prefix from the number:

• s/^011//

Translation rule will add 53872# prefix:

• s/^/53872#/

While the next rule will result in the number replaced with 123456 in all cases unconditionally.

• 123456