[Asterisk-Users] Opportunistic VoIP

[Florian Overkamp]

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 ?).

>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.

>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.

>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.

Thanks for your comments!

Florian