VoIP and ENUM

On the IETF enum-wg mailing list there is a discussion going on for some time on if and how carrier ENUM should be implemented. The discussion was triggered by the recently submitted draft-pfautz-lind-enum-carrier-user-00 and also by a related contribution submitted to the US ENUM Forum.

The discussion centers currenty around the issue if Carrier ENUM should be implemented in

1. ENUM trees not visible to the public Internet

2. in a separate tree on the public Internet,
2a. in parallel to e164.arpa (e.g. e164c.arpa) or
2b. below e164.arpa (e.g. carrier.e164.arpa)
2c. Below the cc-delegations (e.g. carrier.c.c.e164.arpa)
in all these cases user ENUM as it is now would not be influenced.

3. Within Tier 1 of e164.arpa. Here again to oprions exists:
3a. using non-terminal NAPTRs, as proposed in the draft
3b. using terminal NAPTRs to avaoid some of the problens caused by non-terminals
in these case user ENUM in e164.arpa would be influenced, because ENUM clients need
to be aware of these new architecture and NAPTRs and also additional DNS queries are
necessary

One part of he discussion circled around the question if the pointers contained in Carrier ENUM would be visible and resolvable in public DNS.

So the basic question is NOT Carrier ENUM, it is the publc availability of the SIP URI.

I made some entries regarding to this problem to the list, which I copy here:

The discussion regarding User vs Carrier ENUM and where to place is circling around the central point of the problem, which is the future usability and purpose of a sip: URI

SIP was originally modelled along the lines of the e-mail architecture and in every presentation from Henry and Alan at the VON SIP Tutorial you see the famous SIP trapeziod:

A user is sending an invite to a proxy, containing and Address-of-Record (AoR) in the form of a SIP URI sip:user@domain.foo. The proxy is querying the DNS the domain for SRV-records (=MX) and forwarding the invite to the proxy serving the domain.foo. The proxy has either the "user" registered" already and know where in the world the user is attached to the Internet, or the proxy knows what to do with the call, e.g. connects to a voice-box.

Done.

No need for E.164 numbers.

User ENUM now started with the basic idea that if a user has such a SIP URI, and he has also an E.164 number, he may hint that somebody trying to establish a call in the Internet and knowing only the E.164 number that he has also a SIP URI to be reached also there.

User ENUM without SIP URIs is useless.

Now lets look at Carriers. Originally the carriers had only E.164 numbers and where only on the PSTN. Carrier ENUM could have been useful there as IN-SCP replacement for NP, holding tel: records with routing numbers Nice idea, but nobody was interested.

Then the carrier moved on also to VoIP. After some experiements, e.g with H.323 they finally settled on using SIP (the same arguments are BTW also valid for H323). For using SIP you basically need a sip URI as AoR. The best example is the 3GPP IMS model. 3GPP is using two types of SIP URIs: the private User Identity, basically derived by some algorith from the IMSI and used with registration to find the home network and the Public User Identity. The Public User Identity is a SIP URI which should be known also by the User, because it is basically the means to establish a call: e.g. sip:frank@vodafone.de, or even sip:richard@stastny.com.

Now the queston comes up, how public is public. Naive netheads would assume you just put an SRV record in vodafone.de to point to the whatever-CSCF Not so, this is bad for a number of reasons I do not want elaborate further here, but there may some 3GPP and TISPAN experts out there willing to explain.

So if even this is bad, you are not giving anything about which user belongs to you and how many away with this, only eventually the IP address of you SBC. But since they do not want to be reached from the Internet anyway,because they do not get termination charges, this is
a minor problem (how public is public?)

Now we come to the real problem: every sip:frank@vodafone.de has also a E.164 number attached to him, for compatibility with the PSTN and also users on 3G may want to continue to use E.164 for various reasons also stated many times by Rich Shockey.

Since they want to interconnect via IP and not via the PSTN (really), they need a mapping from E.164 numbers to the Public User IDs (SIP URIs) to route the calls properly. You do not need the mapping of you own E.164 number, this is done at the SIP proxy, you need the mapping of all other numbers. This is done best with all call query via a global NP database, giving you the E.164 to provider mapping. If you get as an additioanl bonus the routing information (the IP address of the proxy, One possible solution for this problem is a Carrier ENUM tree. Done..Fine

One would think.

The problem is: they do not want their compet... partners
1. to know how many users they have
2. who these users are - the partner may just make call and alienate him

So even putting the ENUM tree in an extranet only accessible by partners does not help to solve this problem, because the partners are not really partners.

And in addition there are still "partners" and others, so you cannot peer with them; they have their own tree, this creating the ENUM forest.

Even if all decide to use the same global tree, and regardless if this tree is public (e164.arpa or carrier.e164.arpa) or somewhere else e164.info, it does not solve the basic problem, because this is a Catch 22.

Ideas to have a ENUM tree where my entries can only be seen by some others I decide to do so, is the perverting the whole idea, and proves the fact that these operators do care about everything, but not about their customers.

Can you imagine an announcement on the PSTN like this:

"the user you are calling is hosted with a provider we have no interconnect agreement with, so we are sorry that we cannot complete your call. Tell your friend to move over to a provider we have an agreement with, but be aware, we may change our interconnect agreements at any time without prior notice, so tell you friend to move quickly, because in one month this may have changed already."

So either the carriers get their whatever together and introduce an ACQ in public space (because of the Public User Identities) or they forget the whole issue.