[Asterisk-Users] Sip Trunk config / Least Cost Routing

[John Todd]

>From: "Wade Weppler" <weppler at wwworks-inc.com>
>To: <asterisk-users at lists.digium.com>
>Subject: RE: [Asterisk-Users] Sip Trunk config / Least Cost Routing
>Reply-To: asterisk-users at lists.digium.com
>Date: Thu, 7 Aug 2003 17:48:01 -0400
>
>>  Why use an AGI?  This seems to be easily done with the dialplan,
>>  unless I'm missing some additional sophistication that you're not
>>  mentioning.
>
>	Our local area (Toronto) has some extreme overlapping areacode
>problems that require some logic to decipher.  I've been able to pull
>exchange data into a MySQL database (NPA/NXX codes) to help with the logic,
>and it's worked quite well.
>
>	For instance, I'm currently in areacode 905, but not all 905
>areacodes are a local call for me.  Our satellite office is in areacode 416,
>where additional 905 areacodes are a local call that we can then use for our
>other office.
>
>	The AGI works quite well.  I may even post it somewhere if anyone
>wants it.  Here's the basic logic:
>
>	1)	Offices are assigned an "exchange" number that includes all
>of the NPA/NXX codes that are local to that exchange (Toronto has over 1300
>combinations).  NPA, NXX, and exchange are all stored in a MySQL database.
>	2)	The AGI script is passed the local exchange number and the
>dialed LD number.  If the dialed number appears in any other exchange in our
>database, the call is passed through the proper office.  If it doesn't
>appear, the LD call is made over the local telco.
>
>	Exchanges are modified constantly, so keeping up with NPA/NXX
>changes can be a fulltime job!

Ah.  Large pain, then.

>  > TRIP (RFC2871 and RFC3219)   Not implemented in Asterisk yet -
>>  looking for programmers.  See my posts to the -dev list last month.
>
>	I'll have to do some digging on this.  I'm assuming this exposes a
>lot more information at each office (ie. line availability) than anything we
>can do in Asterisk today?
>
>-wade

Yes.  It's a way to distribute routes in a manner similar to the 
"switch" statement, but with the ability to pass along routes heard 
from other route talkers, and to associate other things like "cost", 
"weights", and other things with the route announcements.  The 
protocol supports flooding of path information to peers, so it is 
possible (though not necessary) to advertise number of paths 
available at any one time.  (This of course leads to availability 
oscillation just like with a flapping IP path and BGP, but that 
undesired behavior can be mitigated with dampening at both the talker 
and the call originator, and is an implementation-specific feature.)

To give you an idea of how interesting this would be: I could have a 
peer with your office A, and if you had the appropriate filters on 
your announcements to me, I would know how to reach office B without 
going through office A or a PSTN connection.  If you added a line in 
office B, it would "automatically" be available to anyone with whom 
you peered, and their downstream peers (if desired.)  See the 
usefulness in this?

JT