asterisk users - Sep 2005 - Complete NPA-NXX list for USA/Canada npanxx,

> > 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?
> 
> Nathan
> 
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.

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

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 *

BTW - for $5/mo you can have access to a reasonably well maintained
complete listing of NPA/NXX/OCN/CLLI/ADDRESS, ETC.

https://www.telcodata.us/secure/account/signup (no affiliation)

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