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