[Asterisk-Users] Opportunistic VoIP

[John Todd]

>At 12:58 11-6-2003 -0700, you wrote:
>>I see large benefits in using TRIP versus ENUM.  I'll list some 
>>below, with #1 and #2 being the most important, and the others in 
>>no particular order.
>>
>>1) The ENUM architecture is controlled by national or international 
>>governing bodies.  Ultimately, they can restrict or charge for data 
>>in the ENUM database, and unless you split your root servers, you 
>>are stuck with whatever policies, speed of response, and political 
>>issues that introduces.  This is a _huge_ problem - note that ENUM 
>>is not deployed in the US due to political issues, and not 
>>technical ones. How do you feel about paying Verisign for your 
>>phone number?
>
>Sure, this is true. However, if no widely acceptable ruleset is 
>defined, alternative roots may rise (who says enum MUST be applied 
>below e164.arpa ?).

A widely acceptable ruleset will eventually arise, but why build 
parallel structures?

>>2) The ENUM system is centralized.  TRIP can be established between 
>>two telephone systems, independently of any third party's 
>>cooperation or assistance.  Routes can be exchanged in any way that 
>>is acceptable to those two systems.
>
>See 1) There is no reason to not run ENUM on other zones for 'private' use.

Historically, attempts at alternate roots have failed, as they 
should.  The DNS should remain cohesive.  While using alternate 
roots, or private zones, may work internally within organizations, 
this rapidly falls apart when crossing autonomous boundaries.  How do 
you filter particular records from certain resolvers?  How do you get 
granular control over even your own zones without re-writing  BIND to 
support these new methods?   ENUM is great for individual numbers, 
but again, it is not apparent to me how it is going to be useful for 
range-based announcements or how it will be used with any weighting 
mechanism that is determined by the "end" owner of the route.

>>3) ENUM is DNS based, and is subject to the delays, trials and 
>>tribulations of that protocol.  TRIP is based on peer-to-peer TCP 
>>sessions which flood updates to each other, and architecturally can 
>>handle changes to the route table more quickly (though still not 
>>ideal.)
>
>I agree that this is a great way to deal with blocks of numbers, 
>just like it is a great way to deal with blocks op IP-adresses. 
>However, as BGP sucks in routing huge amounts of singular numbers, I 
>expect TRIP to suck at routing huge amounts of individual 
>phonenumbers. This is an issue I need to deal with for an ongoing 
>project myself, and I'm not seeing how its adressed in TRIP.

The current problems with BGP are relevant to global route tables.  I 
suspect that aggregation on a much larger scale is possible with 
phone numbers.  Even if it is not, the route selection methods of 
TRIP are easily extracted to alternate processing methods, and 
commodity hardware is _cheap_.  BGP tables are a crisis because of 
expensive vendor-specific hardware requirements (and even now, 
they're really not a crisis - the Internet works.)   By the time that 
tens of thousands of companies are putting their phone systems into 
TRIP-capable networking meshes, a gigabyte of RAM in a machine will 
be standard.  I am not worried at all about scaleability from that 
angle.

>>4) ENUM is really designed to answer specific questions about 
>>individual numbers, and it has exactly one set of answers for those 
>>particular numbers.  TRIP is designed for aggregating number 
>>prefixes in route-like formats.  This allows overlap and 
>>competition between servers that may be offering the same path. 
>>TRIP allows the use of alternate values (communities and 
>>preferences, as well as extendable features in the attributes 
>>fields) that allow decision-making on destination choices.
>
>Hmm, now this may have use, however, the same effect is reached by 
>implementing this on an IP-level (in BGP as opposed to in TRIP), or 
>isn't it ?
>
>Don't get me wrong - I have no need to burn down TRIP or elevate 
>ENUM. I am just trying to figure out each respective value for 
>future telephony.

As am I.  I'm simply trying to be pragmatic.  I have a number of 
customers, all of whom require long distance service from a provider. 
They all run Asterisk.  I would like to be able to create a TRIP peer 
between my customer and five long distance providers (after paying 
the account signup fee, of course) and then have the routing system 
start to choose which provider it's going to use.  Maybe some 
providers don't have service to some countries - so, I simply would 
not see those country codes in the route tables from those providers. 
I might make my choices based completely on "price" as a metric, with 
the best provider winning and the others as "backup".  Then, as I get 
more sophisticated, I can start to weigh certain area codes as having 
better "quality" on some providers, even though they're more 
expensive, and I can start to shift my traffic for certain 
circumstances over to that provider.  And then, let's say that one of 
my clients gets a home office in Tel Aviv.  I can set up a PSTN 
gateway in Tel Aviv, and then set up TRIP between that server and the 
"home office" server in New York, and internally advertise that all 
calls that originate in my customer's New York office that happen to 
be bound for country code 972 will exit the network over the PSTN 
line in Tel Aviv.

Let's say I get three companies sharing their route tables via TRIP. 
Can you imagine what even a small number of cooperative companies can 
do for their long distance bills?  And we'd be talking about a very 
small number of routes here - we could aggregate by area code, or 
maybe area code/prefix.  And, using standard filters, we could allow 
each company to regulate what they allowed into their network 
(route-wise) and what they allowed out of their network (route-wise.)

I'm not saying to not use ENUM - actually, it's a great system. 
There might be numbers outside of my little network that I don't know 
about.  If I can get to them via an IP connection, by all means, use 
it!  ENUM can just be another step in the routing decision in a dial 
statement - it can be first, it can be last, but I don't think it's 
sufficient by itself, and three main problems of it's access control, 
weighting issues, and centralized authority may cause a very slow 
start to the process of it's adoption.

JT