[Asterisk-Users] Let's TALK ABOUT IT!!!

[John Todd]

>  > It is that type of mechanism that enum uses and yes it was to solve a
>>  similar goal, but in this case you need a 'route server' type system - in
>>  particular as this is for IP routing of PSTN end points not on an IP
>>  network.
>
>A discussion about this came up a while ago.  I suggested something along
>the lines of BGP, where each endpoint announces "prefixes" of what they
>can get to.  You'll need a central machine that everyone peers up with and
>then you can use a switch => statement or exten => _.,1,Dial in * to query
>that machine and get the best route for your call.  If you make sure that
>your destination machines are not behind NAT or a firewall, you can do an
>IAX handoff to get the connection set peer to peer instead of through the
>central server.
>
>Example:
>
>4 remote * machines, each configured with our "BGP" software.
>
>Machine 1 announces that it can terminate calls to country code 1 with a
>cost of .02.
>Machine 2 announces that it can terminate calls to 1 with a cost of .05.
>Machine 3 announces that it can terminate calls to 1-830 with a cost of 0.
>Machine 4 announces that it can terminate calls to 1-830-751 with a cost
>of 0.
>
>
>You place a call to 1-830-751-2000 and the system determines that it can
>place that call for a cost of 0 to machine 4.
>You place a call to 1-240-988-4000 and the system determines that it can
>place that call via either machine 1 or 2, but lowest cost is machine 1.

[general summary to all branches of this thread]

Yes, that describes TRIP (RFC3219 - 
http://www.zvon.org/tmRFC/RFC3219/Output/index.html) fairly 
accurately.  While not having quite a "central" machine with which 
everyone peers, it may be that each ITAD (Internet Telephony 
Administrative Domain, like an ASN) would have one main router to 
which all their local Asterisk servers would be leafs, and then that 
core router would peer with other core routers at other ITADs or 
maybe some large IRR-like servers which were clearinghouse-only style 
route distributors.

I offered money here on this list previously to anyone who thinks 
that they're qualified to develop and integrate a TRIP implementation 
into Asterisk.  Warning: it's not a trivial issue, and I will only 
consider programmers with a full understanding of the magnitude of 
the task.  This could threaten to be a surprisingly large mesh with 
possibly hundreds of thousands or millions of routes of an extremely 
dynamic nature, and such an implementation is not for the beginner. 
I'm still taking applications.

In other notes: I saw in other parts of this thread the discussion 
about how to do number routing via DNS.  This is a good idea, so 
good, in fact, that it already exists in Asterisk and is a set of 
RFCs.  It's called ENUM, and it routes phone numbers via the DNS. 
See "enum.conf" and "show application EnumLookup" - the good folks at 
nic.at were kind enough to pay for and work on these improvements to 
Asterisk.

ENUM is great, but it's going slowly as far as the hyper adoption 
rates of Internet time are any comparison.  The main issues seem to 
be political, since the triple whammy of "ownership", 
"authorization", and "administration" seem to be in the way.  If you 
are in a country that hates VoIP, don't expect to see above-board 
ENUM any time in the near future.  :-(

BUT: The nice thing about ENUM, especially in Asterisk (and hopefully 
soon in SER) is that one can specify "cascading" trees in which to 
look up data that are not necessarily e164.arpa. as the root.  I will 
leave it to the reader to figure out why this is a good thing and a 
bad thing at the same time.

ENUM and TRIP provide DIFFERENT functions: ENUM gives out exact 
answers, and TRIP provides gateway answers.  First, you look up the 
number in ENUM.  Is there an answer?  If so, send call to that 
SIP/H323/IAX gateway.  If no answer, then look up the number in TRIP 
and find someone who has a cheap/good/fast/whatever gateway to that 
particular number range, and send the call to that SIP/H323/IAX/etc. 
gateway.

In fact, I had a really nasty thought the other day: make a DNS 
resolver hack that allows ENUM lookups to incorporate TRIP replies. 
Yuck, yuck, yuck... but it would allow TRIP integration into any 
system that supports ENUM with no additional work on the telephony 
client side.

JT