VoIP and ENUM

(User) ENUM in e164.arpa is designed according to IETF principles (see the ITU-T/IETF NGN workshop):

.. the end-to-end principle is perhaps the most fundamental and least
understood of the Internet’s architectural principles…:

• Nothing should be done in the network that can be efficiently done in an end-system.
• A function that must be performed at a higher layer should not also be performed at a lower layer (without a good reason)

This implies ENUM is to be used by end-users or proxies on behalf of theend-users.

But end-users are (technology-wise) stupid and how can one expect end-users to understand a technical solution most "experts" still do not understand? The best examples is that even enterprises still do not get the benefits.

Since ENUM is only an add-on working behind the the scenes, it basically requires a SIP URI to work,and it should be hidden within an application or a product. What is required is somebody selling these applications or products to the end-users (including enterprises).

End-users (including most companies) do not configure SMTP and POP3 protocols and set-up their MX records, this is hidden in applications and product.

Ok, User ENUM has some problems and the benefits are not so transparent: e.g. why should an end-user pay for the benefit of another end-user?

We have talked about this short-coming and how to potentially solve them

But there is another possibility for ENUM technology: Carrier or Infrastructure ENUM

Carrier ENUM is not about linking end-user together, it is also not about linking small VoIP islands (enterprises) togeher, it is about linking large IP-islands of VoIP providers (and even PSTN networks) together.

With Carrier ENUM telephony service providers in general could link (peer) their networks together using IP-technology and save a lot of money by doing so.

Carrier ENUM allows any originating network to immediatly identify the destination network currently hosting the E.164 number globally, which renders transit networks - for call setup - not for transport - useless.

Compared with the (broken) method currently used on the PSTN, the benefits are manyfold:

• Since the data is maintained by the destination network only, one can assume the data is as correct as it can get.
• The destination networks have to maintain their data anyway, so they have no additional adminstrative effort in maintaining the ENUM data.
• All other operators have NO EFFORT AT ALL to maintain any routing data. Not for national calls and not for international calls. If one compares this with the OPEX (and CAPEX) currently required for operating NP databases and the efforts to keep international routing data up-to-date (see the 720 and 780 disaster)
• Any tree can be used, there is no cumbersome user opt-in getting in the way and even more there is no cumbersome national regulator opt-in.

There is only one minor problem - there is no common tree defined, so any tree will do, but which one?

In addition Carrier ENUM involves more complicated scenarios and ETSI TR 102 055 tries to give an overwiew framework on the options.

The first to recognize the potential of ENUM where the mobile operators, because they desperately needed a solution for the MMS routing problem. Also cable operators are planning to use ENUM to peer among themselves.

The first implementation between VoIP providers was launched by Thilo Salmon in e164.info.

This implemenation was basically very straightforward, a tree on the public Internet with an option for paranoid providers to peer the information only with selected other providers or to use an anonymizer proxy.

Why would one with the intention to peer want to hide the information required to peer?

I wondered, but if I had known what else will come up soon ...

The next I talked to were the mobile GSM operators grouped in GSM-A. Main reason was that ETSI TISPAN is considering either to set up a similar system or join GSM-A for interconnecting the Fixed IMS NGN. GSM-A wants to implement a Carrier ENUM within a tree for IMS not reachable from the Internet for security, availability and privacy reasons - ok, I can at least follow the arguments, even if not all are valid or other solutions are also possible. And they want to implement ENUM very straightforward, not deviating from the basic rules in RFC3671 (too much). But also here very soon some idea about potential information hiding crept up.

The next discussion started in the LCC TAC. The operators in the US wanted to use 1.e164.arpa both for user ENUM and for Carrier ENUM. Basically not a bad idea, but finally came out that this does not work out. I never got the message what the problem with a separate tree was.

The interesting side-effect of this discussion was that they did not want a URI in ENUM, only a service provider ID (SPID). They real peering information will be somewhere else.

Why? Again the arguments of not anybody should see the URU or IP address of the ingress gateway (because of attacks) and also peering should only be possible if there is a peering agreement. How to interwork with providers where no peering or interconnect agreement exists? Via the PSTN.

So they are planning a system which is not self-sufficient, but needs a metasystem to work. And What if there is no PSTN anymore, only all IP?

Side remark: during the discussion on the SPID I had a deja-vu. What they needed was the old TRC database from TIPHON designed to allow peering of +87810 providers in pre-ENUM days.

This was a very simple protocol: number in - SPID out. With the SPID, the provider looked up a table giveing him the Gatekeeper addresses of the othe prrovider. Telcordia must have somewhere a copy of the software ;-)

But I still had problems to understand the real issue and also thought the paranoia could not get worse.

This was before I talked to Baruch and Eli Katz and saw the presentation from Baruch on XConnect.

This sets the scene for ENUM Update Part 3 - soon to come.