VoIP and ENUM

My next panel was the BoF: Public and Private ENUM Issues in the afternoon. All presentations can be found here.

The panel was moderated by Karen Mulberry (MCI and Chair CC1 ENUM LLC). Karen gave a short introduction of the speakers, the topics to be covered in the panel and the USG guiding principles.

Next to speak was Richard Shockey (Neustar and Co-Chair of the IETF ENUM WG). Rich gave in his presentation a short introduction of the status of work in the IETF ENUM WG, the three faces of ENUM (Public, Private and Carrier ENUM). It was decided at the last IETF in Paris to discuss Carrier ENUM within IETF ENUM WG, which requires a re-charter of the ENUM WG. This is currently ongoing, but complicated by the reorganization of the IETF areas itself. The IETF is currently creating a new "Real-Time Application and Infrastructure (RAI) Area:

“The Real-Time Applications and Infrastructure Area develops protocols and architectures for delay-sensitive interpersonal communications and will consist of the WG's SIP, SIPPING, XCON, SIMPLE, GEOPRIV, ECRIT, ENUM, IPTEL, MEGACO, MMUSIC, IEPREP, SPEECHSC, and SIGTRAN"

One reason of the change in mind at IETF to deal with Carrier ENUM also was the outcome of the VOIPEER BoF also held at the IETF#63 meeting in Paris. At this session a strong need for Carrier ENUM was expressed. Regarding this needs, the problems with Carrier ENUM are quite simple, the real problem will be a common agreement on VoIP Peering (as I also pointed out in my presentation), which as a pre-requisite for any ENUM implementation. This is still far away, or as Rich said next day on the End-to-End IP Peering Panel: "There where 200 people in the room of the IETF voipeer BoF, and at least 250 opinions." Rich is listing some of the issues in his presentation. He closed his presentation with the statement: ENUM is the NGN IP-SCP and as usual with:



Penn Pfautz (AT&T) gave in his presentation a short overview on the issues with Carrier ENUM and also some answers to the non-issues:

• Will carrier ENUM be implemented (yes)
• Will it compromise user privacy? (no)
• Will there be private ENUM deployments? (done)

Under what auspices and domain will carrier ENUM be implemented?

• Carrier ENUM will be implemented,
• it could be implemented synergistically with UserENUM under e164.arpa
• it may initially be implemented locally

How open will carrier ENUM be?

• Carrier ENUM could be implemented in the public DNS, potentially facilitating an evolution toward “Internet Interconnection”
• Carrier ENUM could be implemented in the public DNS with carriers still requiring interconnection agreements before accepting traffic terminations and providing different POIs for different connecting entities
• Carrier ENUM could be implemented privately as a closed user group with query access restricted to carrier members

Does public ENUM have a future?

• By and large, public end user ENUM trials have not indicated a strong market, though an enterprise private ENUM market does exist
• Carrier ENUM could subsidize initial deployment of user ENUM if implemented in a common infrastructure

Michael Haberler (IPA and enum.at) followed Penn and explained in detail the options currently discussed at IETF how to integrate Carrier ENUM into e164.arpa.

He listed the requirements for a solution:

• single DNS lookup
• no shape change for User ENUM
• additional functionality/code only for carrier resolvers.
• work with closed and open number plans – avoid wildcards / enable DNSSEC
• no new NAPTRs just for resolution
• deployment in finite time
• local decisions as far as possible
• no revisiting of global agreements like the interim procedures
• Address privacy concerns – disclosure of unlisted numbers, user identity

and his proposal is:

• Add a Carrier ENUM subtree (branch) under e164.arpa
• Branch location is a per-CC decision
• Provide mechanism to locate country CE subtree
• Carriers may populate that subtree
• What a „carrier“ is is a national matter
• This suggest a branch under .e164.arpa
• But also enable different scenarios like:
• .carrier.e164.arpa or
• Carrier...e164.arpa

Regarding resolution and management, Carrier and User ENUM tree should be „ships in the night“

The way forward could be:

• Get combined ENUM through IETF - ENUM WG addresses only resolution
• Get consensus as to how the „interconnect agreement“ is mapped into Carrier ENUM semantics
• Getting service into the field

My presentation was the last of these presentations and focused basically on one point mentioned in the previous presentations - the relationship between ENUM and VoIP Interconnect (VoIP Peering):

It has already be shown that User ENUM does not fly without VoIP Peering - the same is true for Carrier ENUM.

Henry Sinnreich said this all the time, also in his new book SIP beyond VoIP he asks the question: What is real VoIP?

Does the VoIP service allow the user to print on the business card,

• one single phone number (using ENUM) and/or
• a SIP URI?

If the answer is YES, then the service is VoIP.

If the anser is NO, it is just an emulation of the circuit switched voive service of the PSTN

So I concluded:

• If Carrier ENUM is intended to allow the mapping of any E.164 number that can be reached on IP to a SIP URI, Carrier ENUM must be in the public DNS.
• But this is useless, if the resulting SIP URI cannot be reached. So for Carrier ENUM also an IP Interconnect (VoIP Peering) regime is required.

Work on VoIP Peering is of highest priority, but first we have to get the 250+ opinions mentioned above down to say 5 or 10.