[VoiceOps] Does anyone implement RFC 3219?
jtodd at loligo.com
Fri Aug 21 00:18:55 EDT 2009
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
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
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,
More information about the VoiceOps