[VoiceOps] The big ENUM question (Was: VPFs)

[John Todd]

Comments in-line.

On Aug 5, 2009, at 11:19 AM, Mark R Lindsey wrote:

> At IPTComm a couple of years ago, Jonathan Rosenberg stood up and  
> said the big problem was the walled gardens that are telcos and  
> ITSPs. We carriers just aren't passing traffic via VoIP. Even Cisco  
> customers aren't passing traffic within their own company; you'd  
> have a BTS over here and a BTS over there, owned by the same Cable  
> MSO, passing traffic via ISUP.
>
> Continuing this conversation about VPFs: what would it take for you  
> to start routing calls across the Internet using lookups like ENUM?
> 
> 1. A big task would be advertising our routes. We'd have to pull our  
> user's numbers out of our boxes -- Asterisk, BroadWorks, MetaSwitch,  
> Taqua, Sonus, Nortel, Cisco, etc., and advertise those numbers  
> somehow. I'm sure tools to extract the list of local numbers from  
> each of these systems would be pretty easy. Raise your hand if  
> you're excited about advertising all of your user's telephone  
> numbers to make the telemarketing and SPIT easier.

I think that should already exist, if you're offering some sort of  
routing to start with.  If you don't know the E.164 addresses that are  
assigned to each customer, how are you getting calls to them in the  
first place?

As far as authenticating to protect against SPIT, that's not overly  
difficult, I believe.  I had a suggestion some time ago that would at  
least let you create black/whitelists based on asserted domain name.   
Here is discussion and code I wrote that might be of some interest:

   https://mail.internet2.edu/wws/arc/sip.edu/2006-07/msg00012.html
   http://forum.e164.org/index.php?topic=16.0


> 2. We'd need to agree on some way to ensure that these routes  
> advertised were authoritative. E.g., how would YOU know that I'm  
> really authorized to advertise +1-229-316-0013? If you dip to SS7,  
> that goes to my CLEC-partner-of-the-week.

OK, now this is a serious issue that I have no easy answer for.  There  
are two companies here in North American that would be GLAD to offer  
the ability to look that data up in their proprietary databases, and  
charge you for that service.  Personally, I'm not really interested in  
that model, though Bellheads nearly froth with glee when the concept  
of a "central database" starts to be needed for EVERY transaction.

> 3. Then we'd need to agree on some way to do the lookup. ENUM seems  
> like a nice option -- if the basic delegation mechanism made sense.  
> It makes sense if we have large blocks of numbers, like NPANXXs, and  
> there are no number ports. But since we all have number ports, the  
> large blocks will be punctuated by many, many individual references  
> to the ITSP that ported in the number. So the ability to delegate  
> subdomains using ENUM doesn't bring much value, to my mind.  So  
> whether we use ENUM or a normal SIP redirect server probably doesn't  
> make a lot of difference.

OK, another huge stumbling block.  Especially when we're now talking  
about creating ENUM trees that have to be completely broken down to  
individual responses for each 0-9 subdomain space for each reply if  
one number is ported out of the block.  Gak.  DNS doesn't like this.

> 4. We'd also need to make peace on the whole transport thing. As  
> Brian Sneddon just said, the commodity Internet remains acceptable  
> for a lot of purposes. There's risk in betting on that, of course.

If the user doesn't know what to expect, yes, that's very true.

> 5. And then we'd have to figure out how to bill each other, if we're  
> going to do billing. But is billing each other for 100 kbps audio  
> streams worthwhile anyway?

In my opinion, no.  But I'm not a carrier who has become used to  
feeding from that teat of inter-carrier compensation.  I'm used to  
charging my users for connecting their calls in or out, not charging  
someone else for the luxury of reaching my customers.

> 6. Of course, we also want to be sure we're allowing calls only from  
> the right people. A few years ago, many of us setup our SBCs to  
> allow calls from the public Internet, but that's much less common  
> now. Oh, we'll accept any ol' screechy call that comes from our  
> known peer, and pay him to do it.

I guess I can agree with this, but I don't know what "allowing calls  
from the right people" means, except in the context of getting paid  
for inbound calls (see my reply to your #5) or in a quality assurance  
issue (see #4.)

> And once we figure out all of these challenges -- which are really  
> quite moderate -- we've got to convince ourselves that the effort is  
> worth the reward: we get to bypass the big carriers for some calls,  
> and get to use fancy codecs like G.722 and video.
>
> The technical challenges are really quite moderate. The VPF people  
> are trying to solve it but only within their club. Why pay them when  
> we can do it ourselves?

I agree with this last statement entirely, but with a caveat.

The caveat is that I think that E.164 is broken, from both an  
operational and political level.  I used to be a big believer, and I  
still think it probably is good non-global peering arrangements.  But  
for public use, I think it's dead.  (possibly excepting iNum, but I'm  
still viewing that with some suspicion)

What's the punchline to this set of comments I've made?  I am an  
advocate (and administrator) of the freenum.org system, which uses a  
concept called "ISN", which is an alternate pointer system which can  
replace E.164.  It uses organizationally-based numbering schemes which  
are keypad friendly (12 digit standard DTMF keyboard) and which are  
suitably different from

An ISN (ITAD Subscriber Number) is formed very much like a SIP URI: a  
subscriber portion, a separator, and an organization identifier.  A  
SIP URI might be "1234 at loligo.com", and a similar ISN would be  
"1234*256".  In this case, loligo.com (me) has received ITAD 256 from  
IANA a few years ago.  So the ENUM-like lookup is  
"4.3.2.1.256.freenum.org" - the freenum.org zone can either delegate  
zone "256" to me, or I can do what most organizations do and put in a  
wildcard NAPTR record that just points all SIP calls to my Asterisk  
SIP platform.  In this example case, the NAPTR for  
4.3.2.1.256.freenum.org maps to "1234 at loligo.com", and uses standard  
SIP lookups from there on out.

Here's a small set of advantages of freenum.org over E.164:

  - Not similar to E.164 numbers (users have expectation of "internet  
calling")
  - Works on most of the world's existing phones
  - Requires no alphanumerics
  - Maps very cleanly to SIP infrastructures
  - Uses all standard ENUM methods, but slightly modifies root
  - Totally free
  - IANA-based registry for organizations (not-for-profit)
  - Layers onto existing E.164 system, if you so wish (12125551212*254  
would work fine, as an example)
  - Does not involve the ITU
  - Does not involve governments
  - Assumes end-to-end IP SIP at no charge between entities
  - Organizationally-based, not geographic
  - Scales better than ENUM, and within organizations can scale  
laterally
  - OpenSER, SER, Asterisk, FreeSwitch support existing already for  
dialing/DNS lookups
  - We have SIP, ENUM shims for systems that

So, I believe that many of the problems with ENUM are insurmountable  
on a large scale.  A different system needs to be put in place that  
allows dialpad access yet is more friendly and scalable for systems  
which are internet-enabled in the core.  Hopefully, you'll take a look  
at the concept and see if you might permit your users to dial those  
digits and also accept inbound calls.

JT