[VoiceOps] Does anyone implement RFC 3219?

[John Todd]

On Aug 20, 2009, at 2:36 PM, Kenny Sallee wrote:

>  Otherwise we all might as well turn our SIP/H.323 devices off now  
> and go home.
>
> I have to agree with this.  However, mindset changes typically  
> happen at engineering levels first (if we are comfy we push them)  
> and if business models and $$ can be made are learned by the VP's we  
> all care about.  Like David said tho - if we can make it work from a  
> policy standpoint and use our engineering skills to protect us from  
> the idiots (I'm sure most of us in our engineering careers have been  
> one at some point) then something like TRIP sounds very interesting  
> to me.
>
> BGP is solid - but the engineers who configure it and global nature  
> of errors are what make people who care about phone calls shy away  
> from it.  Those are some of the problems we'd need to address to  
> reach a phone via some global directory.  Have to be able to trust  
> it and the path.  The TRIP RFC was implemented back in 2002 and  
> perhaps was ahead of it's time like so many other .com's and it's  
> time to look at it again


A few points that I've noticed in my thinking over the last 10 years  
or so trying to come up with clever ways to do telephony routing..


1) TRIP is great, but ultimately doesn't work on a global basis.  It  
may work in tightly-coupled environments, such as a large multi- 
national firm, or even a keiretsu-style conglomerate of companies, but  
in "the wild" it would be unworkable.  Why?

    a) Phone numbers are not in large spans of sequential space, and  
are growing more fractured by the day.  Just the amount of route  
injections to cover transferred mobile numbers would (I suspect) be in  
the hundreds of thousands of records per day if even 50% of the  
world's phone numbers were in the tables.  (Look at some of the update  
and churn numbers in China and India to make your head spin.)

   b) The trust model of who "owns" a number is unworkable in an  
endpoint-trusted environment with a non-hierarchical routing  
structure.  Who, really, is supposed to get the call for a particular  
E.164 address?  Well, that sounds like the role of a central authority  
to me.  So why have TRIP if you have a central repository?  (Feel free  
to exchange the words "central authority" for "several dozen or even  
several hundred nationally-designated legally compliant bodies of  
authority with geographic reign")

   c) The potential for abuse or misconfiguration is serious, and  
filtering to prevent that type of problem (as Alex Balashov notes) is  
formidable.  That would be an understatement.  It is nearly  
impossible.  The fluctuations of the route tables would be  
significant, and even one incident where an "important" number is mis- 
routed to the wrong person would have possibly two orders of magnitude  
more of a press/public opinion result than those events that occur  
with some frequency in the BGP tables.


2) ENUM is great, but suffers from 1(a) and 1(b).  Additionally, it  
suffers from a political structure in many nations that is highly  
resistant to re-distribution of number space at the geographically  
national level away from the hands of a very small minority of  
controllers, typically incumbents.  In my opinion, ENUM in North  
America is currently dead for these issues regardless of whatever  
anyone says.


3) E.164 is outdated, and should be banished.  Why?

   a) See 1a-1c and 2, which are all results of E.164's political and  
geographic constraints.


Regardless of (3), we're stuck with E.164 for a while.  Working in  
small pockets with equally trusted members and a low risk of unknown  
or uncertified members of the routing information mesh, technologies  
such as ENUM, DUNDi, and TRIP all work well.  But they do not scale  
across organizational boundaries easily.  In the instance of a school  
system or group of school systems (to Jonathan's query/point) that may  
be small enough to work.  Uncertainty grows with the number of fingers  
typing configurations, and one must also consider the risk of "stale"  
or inaccurate routing data  - is it really an issue for your user  
community if something "bad" happens?

My punchline to this whole thing is "Look at freenum.org" since while  
it has the significant downside of introducing a new numbering scheme,  
it avoids almost all of the downsides of E.164 and various E.164  
routing methods I list above.  (Even the downside is an upside,  
actually.)

JT