> > > 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. _______________________________________________ --Bandwidth and Colocation sponsored by Easynews.com -- Asterisk-Users mailing list [email protected] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
