VoIP Made Free with Blockchain: Introducing ENUMER

A look into a decentralized implementation of the ENUM VoIP protocol based on the Emercoin blockchain. We discuss how the ENUMER system is organized and how it is different from other ENUM implementations. We also show how to deploy an ENUMER node and configure a FreeSWITCH IP PBX to support it.

Introduction

VoIP has been on the rise recently due to its many advantages over conventional telephony, such as lower price and broader functionality. An increasing number of companies use IP PBXs, but major telephone networks still stick to conventional, if digital, solutions. As a result, even two IP PBXs usually connect via a regular PSTN. Here’s an example:

Let’s take two companies, Acme and Globex, both using IP PBXs internally. An Acme employee runs across a Globex ad and wants to call them. In this case,

two IP PBXs connect with each other via a chain of PSTN providers, so Acme pays for “landing” the VoIP call onto the PSTN network. Then the PSTN providers settle their own mutual accounts, but that’s beyond our interests.

If Acme’s PBX “knew” the path to Globex’s, it could reach it directly via the Internet, ridding Acme of the landing fee and thus making the call free.

This would also improve call quality and reliability, as there would be fewer middle links and hence fewer re-codings of the voice data.

Of course, knowing all the paths — that is, the whole map of all possible direct IP connections, — is not a cakewalk. That’s why IETF has developed ENUM — a network protocol that translates phone numbers to paths, or URIs.

ENUM

The ENUM protocol (see rfc6116) acts as a distributed address book that allows finding the path to a certain IP PBX by a telephone number serviced by it. You can read more about the protocol at https://en.wikipedia.org/wiki/Telephone_number_mapping.

In our example above, ENUM works as follows:

• Globex registers their IP PBX with ENUM,
• During the call, Acme’s IP PBX makes a query to ENUM, trying to find a “shortcut” to Globex bypassing the PSTN network,
• If such a shortcut exists, Acme’s PBX uses it. If not, it uses the conventional PSTN way and pays the landing fee,

Advantages of ENUM

ENUM favors both the calling and the called party, providing:

• Better signal, thanks to direct connection,
• Higher data transfer speed and reliability,
• No volume or time limits imposed by the PSTN operator,
• No risk of service denial due to network overload,
• Free calls for the calling party,
• Free toll-free calls for the called party,
• Seamless and automatic operation with minimum IP PBX configuration efforts.

Although ENUM is simple, lightweight, effective, and supported by all the most popular IP PBXs, it did not catch up due to several organizational and economical reasons. Here they are.

Issues with existing ENUM implementations:

1. The first problem with ENUM is that there is simply no place for a usual IP PBX owner to register their number(s) and SIP URI(s). Previously there were freenum.org and e164.org, but the former has long gone offline, and the latter has ceased operations in November 2016. Some ENUM servers, such as e164.arpa, do linger on, but they are more of an “inter-carrier node” for large and mutually trusted VoIP providers rather than IP PBX owners. The former use it to provide each other with landing data for their networks, but the latter have no access to it.
2. The second issue is ENUM’s critical dependence on a central service, which might work incorrectly or not work at all. e164.org is illustrative in this regard. During its last 2 years of operation it had stability issues and resorted to foul practices. For example, despite having registered toll free numbers, it landed VoIP data to its partner PSTN providers instead of its subscribers’ IP PBXs, resulting in corresponding landing charges. Naturally, this deprived toll-free number owners of any incentives to use it.
   During the last month of its existence, the service stopped giving ENUM responses at all, although it still did contain correct data (we checked).
3. As the classic, centralized ENUM system uses DNS transport, it is vulnerable to all kinds of attacks on the DNS infrastructure, including spoofing, hijacking, and the like. Of course, failures in the DNS system also result in the denial of service for ENUM.
4. Last but not least, an ENUM server experiences a huge load, having to respond to each IP PBX call. Despite caching by intermediate DNS servers, the load is still high for a server that has to serve all the PBXs around the world. This results in denials and delays of service and makes the server infrastructure pretty costly.

The above failures are of both organizational and technical nature and come from the service’s centralized nature and the obscurity of the way it resolves queries. Indeed, the centralization makes ENUM dependent on the central node, which creates and maintains ENUM records, as well as the DNS server resolving ENUM queries. In other words, the credibility of such an ENUM system is limited by the credibility of the organization running it. It doesn’t help that the algorithm and criteria for query resolution are completely unknown. Today it works as intended,and tomorrow it starts forwarding your calls to interesting locations — say, an intermediate VoIP node that can do anything to your data. Because “it’s only metadata,” you know?

Finally, an outage of the central service results in the whole network’s going down at once. We have seen this happen with e164.org, which first forwarded toll-free calls to its PSTN partners, then started sending empty responses, and finally dropped the business altogether, taking all the databases with it.

ENUMER, a decentralized ENUM

To overcome the above challenges, we have built a decentralized ENUM implementation based on the Emercoin blockchain. We called it ENUMER — a portmanteau of ENUM and Emer.

Cryptocurrencies are in vogue these days, but some of them just try to ride the fad. Just like any other cryptocurrency, Emercoin is based on a blockchain, a distributed, trusted, public database of financial transactions.

But unlike the others, Emercoin uses a distributed name-value storage (NVS) for general-purpose information. It means that every network participant has an authentic local copy of the entire blockchain and hence the whole NVS content. The trust in the NVS content and the blockchain in general rests upon the consolidated effort of Proof-of-Work and Proof-of-Stake miners.

This storage is already used in the EmerSSH/EmerSSL security platforms and in EmerDNS — an invulnerable, decentralized domain name system.

The current decentralized ENUM project is based on EmerDNS and has the following advantages compared to the conventional, centralized ENUM implementations:

• Fast resolution of ENUM queries thanks to their local processing.
• Reliable query resolution: Even if you lose connection to other network participants, your queries will still get resolved through your local blockchain copy.
• Anonymity: As the queries never leave your local computer or a trusted local area network, no outsider will ever know what’s going on or who you are looking for.
• It is impossible to attack the DNS infrastructure because there is none (solves issue #3).
• True decentralization makes the network’s credibility independent of the credibility of any single company. No single entity can voluntarily stop the entire system (solves issue #2). The ENUM network will continue operating for as long as hundreds of independent miners keep closing blocks and confirming the blockchain consensus.
• ENUM queries are processed on the querying side. Anyone can find and verify the corresponding code on Github. No ENUM server can change the rules in midstream. You query your own local server via a local connection or a trusted network.
• Thanks to its decentralization, the Emercoin peer network is infinitely scalable. There is no bottleneck to handle queries from across the world. Anyone can install as many independent Emercoin nodes as they like and resolve ENUM queries within that cluster. This solves issue #4.
• Users create and update ENUM records themselves via their local Emercoin wallets, eliminating the need to have a server or another place to send the data to (solves issue #1). Each user does this locally and does not need to report their activity to anyone. You just use your local wallet, and it broadcasts the ENUM record to the peer network.

Thus, we get a system that is:

• Fast,
• Reliable,
• Secure,
• Scalable,
• Has no critical dependence on any single entity,
• Cannot be stopped by a voluntary decision,
• Cannot block “personae non gratae,”
• Has a transparent query resolution algorithm, and
• Can be managed via a local wallet instead of a web server.

But despite its many advantages, a decentralized ENUM implementation has its own specific issues arising from its infrastructure’s being public. Anyone can create a record with any content, squatting a record corresponding to someone else’s phone number and either blocking ENUM access for the real owner or, worse, rerouting the call to another destination.

To avoid such abuse, we have introduced the role of a verifier, an entity that confirms that a certain ENUM record belongs to the real number owner and sends back a signature approving its further use. For the same reason, ENUMER only works with individual phone numbers, so it’s impossible for one ENUM record to grab a hefty piece of the numbering space.

How to create a verified ENUMER record

If you are an IP PBX owner and want to receive ENUM calls, you must first configure your PBX in such a way that its SIP URI can accept calls from the outside world. The exact configuration steps depend on the PBX in question and its network environment and are the same with or without a blockchain.

Then you must add a verified ENUM record to the Emercoin NVS, to be further used to call you. To do this, proceed as follows:

Install an Emercoin wallet

An Emercoin wallet (node) is a client program of the distributed network used, among other things, for ENUM. It is a kind of an admin panel where you can create and update ENUM records as needed. You can download the wallet here.

We recommend using your OS-specific GUI wallet to manage records.

After downloading and starting the wallet, wait until it syncs your local blockchain copy. This may take up to several hours.

Get EMC coins

Then you need to purchase EMCs to create and update NVS records. You can do this in one of the marketplaces or from the developers.
You will need around 0.05 EMC ($0.06 at the current rate) to reserve one record for 10 years, including several updates in the future. So the price is pretty acceptable. And given that soon adding an NVS record will become 99% cheaper, you can consider ENUMER maintenance costs close to zero.

You can set the address for receiving the coins in the File/Receiving Addresses menu. It looks somewhat like this:

ERFJfQGwmZEomHQHGZsRFLZEyBxaWsCHTo.

Create an ENUM record

We store ENUM records in a trusted decentralized name-value storage (Emercoin NVS). You can access NVS records either from the wallet’s GUI (Manage Names tab), or via a documented JSON API. As its name suggests, an NVS record consists of a name and a value.

Name

ENUM names have the following format:

enum:phone_num:N

Where:

• “enum” is the service prefix,
• “phone_num” is a phone number in the E164 format, and
• “N” is an integer used to prevent squatting.

For example:

enum:18009359935:0

The prefix and number parts should be self-explanatory. As for “N”, we need this number to protect real number owners from squatters who want to take other people’s ENUM records and do all kinds of bad stuff using them. They could not use the squatted record anyway thanks to the verification mechanism (see below), but the real owner would not be able to add their record. Now, with “N”, the real number owner can create a record with the first vacant “N” suffix. Suppose you want to create an ENUM record for 18009359935, and it has already been squatted. Just create it with the name “enum: 18009359935:1”. After verification shows that it is your name that the system should trust, the squatter will be left with nothing but a useless record and a few burned coins. If that name is squatted as well, try creating one with N = 2, and so on.

Value

The value field consists of several lines. These can be either NAPTR U-records (see rfc3402), starting with “E2U”, or verifier signatures, starting with “SIG”. One ENUM record can contain multiple NAPTR records and multiple signatures from different verifiers. Here is an example of a value that contains both a NAPTR record and a signature:

E2U+sip=100|10|!^(.*)$!sip:17772325555@in.callcentric.com!
SIG=ver:enum|IC00zMELlEwmMHLpQs8=

As you do not have any signatures yet — you will get them later from existing verifiers, — you should only include U-records (at least one of them) to enable call routing to your IP PBX . A U-record has the following structure:

Service=Priority|Preference|Regex

In the example above:

• Service is E2U+sip,
• Priority is 100,
• Preference is 10,
• Regex is !^(.*)$!sip:17772325555@in.callcentric.com!

The names and meanings of the fields correspond to the classical ENUM standard. Here are some guidelines for those who don’t feel like reading the whole standard:

Service is almost always E2U+sip for SIP IP PBXs, although it can also be E2U+iax or something along these lines. As mentioned earlier, you can create an ENUM record with multiple U-records.

Priority and preference can be left as in the example above. Try not to make them too small.

The most important part is the regex. This is the rule for translating phone numbers into SIP URIs, consisting of two parts delimited with a “!” sign. The left part contains the regex to match the phone number with, and the right part inserts the matched number instead of \1, resulting in the SIP URI.
Here’s another interesting example regex usage:

!^\+?441865332(.*)$!sip:\1@nominet.org.uk!

Pass verification

Now your ENUM is ready, accepted by the blockchain, and available to the world. But callers’ IP PBXs will ignore it until it is signed by trusted verifiers. And that’s the way it should be; for who knows who actually created the record with your phone number? We don’t want the system to route data to random locations, so it will only handle data signed by a verifier.

At the moment, there is no automatic verification system in place, but we plan to build and implement it in the near future. If you want to take part in creating and launching it, let us know at enumer@emercoin.com. For the time being, verification is done by a human operator.

To obtain a signature, send an e-mail to enumer@emercoin.com. In the letter, indicate the NVS name of your ENUMER record, e.g., enum:18009359935:0.

Within a few days, the operator will check the record by calling the corresponding number and making sure that the owner is aware of the query and agrees to use ENUMER. After successful verification, we will send you a response containing the signature to add to your NVS record. Once signed, your record will become trusted, and other users will be able to use it to make direct calls to your PBX.

Add the verifier’s signature to your ENUM record

By adding the verifier’s signature to your ENUM record and calling the NAME_UPDATE method, you prove your ownership of the number. Now ENUMER clients who trust that verifier will be routing their calls to the SIP URI of your IP PBX instead of the PSTN network.

An ENUM record may contain signatures from multiple verifiers. The client will use an ENUM record if it contains at least one signature of a verifier it trusts.

After you add the signature, your ENUM record becomes active, and ENUMER clients will be able to call you directly bypassing the PSTN network.

Making a call using an ENUMER client

Now that your IP PBX’s record is live on ENUMER, you can start using the system for your and other users’ benefit. Now it’s time to configure your IP PBX to send ENUM queries to the Emercoin NVS.

Using the enum.enumer.org service

We have created a public ENUMER gateway that any PBX user can use without any blockchain configuration. To do this, just send an ENUM query to the DNS resolver at enum.enumer.org. Here is an example of a command-line query and the corresponding response:

$ dig -t naptr +short 53995390081.enum.enumer.org

100 10 “u” “E2U+sip” “!^(.*)$!sip:\\1@tollfree.alcazarnetworks.com!” .

Keep in mind that using our gateway brings all the potential problems discussed above for centralized/external servers. So our gateway is merely meant to provide a test environment. We strongly discourage using it in a production environment. Instead, you should deploy your own EmerDNS gateway as described below.

Deploying an EmerDNS gateway

The best, quickest, and safest way is to install an Emercoin wallet daemon and deploy an EMCDNS gateway in your local network or even on the same server that hosts the IP PBX. You can find the documentation for deploying such a gateway here (see “Integration into a regular DNS tree”).

Edit BIND’s (or another DNS proxy server’s) configuration by adding a link to a fifth zone, “enum”, similar to the four provided for EmerDNS.

Also add “$enum” to the list of served zones in the wallet’s emercoin.conf, as shown in the example below. Using “$” instead of “.” instructs the wallet to serve this zone using ENUM (rfc6116) rules. Finally, add the following two ENUM-specific parameters to the wallet’s configuration:

• List of trusted verifiers under “enumtrust” (ver:enum|olegh in the example below).
• Filename or link (the latter starting with a “@”) to an NVS record containing the rules for landing toll-free calls to the PSTN network, for when ENUMER cannot find a destination for the queried number, under “enumtollfree”.
• In the example below, the list refers to the enum:tollfree NVS record, currently containing rules for landing toll-free calls in the United States, France, and Poland. We will maintain this record and add paths to other countries as more landers emerge.

Thus, you should add the following lines to emercoin.conf:

emcdnsallowed=$enum|.coin|.emc|.lib|.bazar # Allowed TLDs, including ENUM

enumtrust=ver:enum|olegh
enumtollfree=@enum:tollfree

To test the settings, try to manually send an ENUM query to the DNS:

$ dig -t naptr +short 53995390081.enum localhost

The DNS should respond with something like:

100 10 “u” “E2U+sip” “!^(.*)$!sip:\\1@tollfree.alcazarnetworks.com!” .

If something is not working, try sending the query directly to the wallet at port 5335 —

$ dig -t naptr +short 53995390081.enum localost –p 5335

— and localizing the issue. But if everything is configured properly, it should start working immediately and smoothly.

Connecting your IP PBX

This is the easiest part. In your IP PBX’s dialing plan, put an ENUMER query after internal and corporate numbers, but before any PSTN providers. Of course, you should translate the desired number to the ITU-T E164 format format before making the query.

The following is a dialplan example for FreeSWITCH, which first translates the number to the E164 format excluding the leading “+” and then makes a query to ENUMER with a “+”. If there is no ENUMER match, it makes a query to e164.arpa. If it fails as well, dialplan switches to PSTN landing. You can add a similar dialplan sequence for another ENUM-compliant IP PBXs (Asterisk, Yate, etc.).

<! — Normalize numbers to ITU-T E164 without PLUS →
<extension name=”Normalize to ITU-T E164 without PLUS”>
<condition field=”destination_number” expression=”^(?:\+|011|00)(\d{7,})$” break=”on-true”>
<action application=”transfer” data=”$1"/>
</condition>
<condition field=”destination_number” expression=”^(\d{10})$” break=”on-true”>
<action application=”transfer” data=”1$1"/>
</condition>
<condition field=”destination_number” expression=”^(\d{7})$” break=”on-true”>
<action application=”transfer” data=”1${home_code}$1"/>
</condition>
</extension>
<! — Lookup E164 with PLUS in the ENUMER and e164.arpa →
<extension name=”Lookup ENUM” continue=”true”>
<condition field=”destination_number” expression=”^(\d{7,})$” break=”on-true”>
<action application=”ring_ready”/>
<action application=”set” data=”hangup_after_bridge=true”/>
<action application=”set” data=”continue_on_fail=true”/>
<action application=”set” data=”effective_caller_id_name=+15553550000"/>
<action application=”set” data=”effective_caller_id_number=+15553550000"/>
<action application=”enum” data=”+$1 enum”/>
<action application=”bridge” data=”${enum_auto_route}”/>
<action application=”enum” data=”+$1 e164.arpa”/>
<action application=”bridge” data=”${enum_auto_route}”/>
</condition>
</extension>