[Asterisk-Users] Opportunistic VoIP

[John Todd]

>This is slightly off-topic I suppose, but:

I'd say it's on-topic, since it's something (if implemented) could 
radically change the way Asterisk moves calls between servers.  If 
understood correctly, I believe it could be the single biggest change 
that the VOIP industry ("movement"?) could use to destroy the 
existing traditional infrastructure of the phone system.  Asterisk 
seems to be a pretty good hammer right now for starting that job; I 
think TRIP would give some extra muscle to the task.

>At 20:37 10-6-2003 -0700, you wrote:
>>You should investigate TRIP (RFC 3129):
>>
>>http://www.zvon.org/tmRFC/RFC3219/Output/
>>
>>Find BSD-licensed proof-of-concept code at 
>>http://www.vovida.org/downloads/trip/trip-1.0.0.tar.gz
>>
>>If someone could incorporate this into Asterisk and extend the 
>>functionality, that would be pretty nice.  The basic ENUM support 
>>in Asterisk already can handle specific number paths, but I think 
>>TRIP or something like TRIP would be best for handling situations 
>>where larger groups of numbers need to be "advertised" into a 
>>routing table behind a particular Asterisk server.  Think "BGP for 
>>phone numbers."
>
>I'm sorry, but I see no real benefits to TRIP over ENUM. Large 
>amounts of data in DNS databases have not been a real problem yet, 
>provided the tree is delegated properly (as ENUM does), and works 
>quite effectively due to caching.
>
>TRIP only makes it harder for widespread use to deal with such 
>things as number portability (can't ever do that with IP, remember). 
>As far as I can tell from the TRIP docs this looks a lot like some 
>big telco tries to make it more difficult for customers to move to 
>another telco and still use their old number...
>
>Florian


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?

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.

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

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.

JT