[Asterisk-Users] Complete NPA-NXX list for USA/Canada npanxx,

[Joe Greco]

> > > On a related note, I wanted our phones to display "city, st" for the
> > > caller-ID name in the event that none was provided.
> > 
> > Interesting code.  What sort of memory does * take up when you load up
> > all those CLID values?
> 
> I am a little late to this thread, but the answer is WAY TO MUCH.
> 
> With 150,000 "pattern" match extensions * takes a very long time to
> reload, during which time calls do not proceed.

pbx*CLI> !date
Thu Sep 22 00:33:50 CDT 2005
pbx*CLI> reload
[snip lots of junk]
pbx*CLI> !date
Thu Sep 22 00:33:54 CDT 2005

Ohhhkay, then, the entire four seconds it took this ancient Pentium Pro 200
to reload is... _maybe_ ... a second longer than it did before, and that's
really giving it the benefit of the doubt.

> If you use Realtime MySQL it pulls in ALL patter match extensions in the
> context on every call (150,000 rows per query).

Using pattern matching would be a bit retarded.  Databases work so much
better when you give them a key and they only need to do a single lookup.
I'm not sure what better key you could have than the npa-nxx itself, so
that's what I used...

> There are two ways to fix this;
> 
> The one we did, use the application command realtime() to pull the
> record from a database based on napnxx and then use gotoif to route to
> the lowest cost provider in that records (realtime must be used on a
> unique index so ONLY 1 row is retruned). We are testing upgrading this
> to mysql 5 where a view could be used to eliminate the gotoif. With the
> gotoif and 2 carriers per npa nxx it is fast. Realtime() can only do
> simple queries as of right now, so views would be a huge plus.
> 
> The other option I know others are using is to get the route via an agi
> script.
> 
> Bottom line, YOU CAN NOT load all 150,000 NPA/NXX pattern matches in
> asterisk via text file or realtime and expect acceptable performance,
> YOU MUST use a database query solution to get only info you need to *

Then perhaps you should inspect the code that we were discussing, eh.
It's a quick, simple hack, to be sure, but it certainly seems to offer
acceptable performance using the built-in database (and Berkeley DB v1
ain't the most wonderful thing around, but it definitely *works*).

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.