> It is that type of mechanism that enum uses and yes it was to solve asimilar 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 _______________________________________________ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users
