<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
We have a similar situation and we do a realtime lookup in an external
db, works like a champ<br>
<br>
Steve Murphy wrote:
<blockquote cite="mid1170912356.14474.11.camel@digium2" type="cite">
<pre wrap="">On Wed, 2007-02-07 at 22:21 -0500, Lee Jenkins wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Eric Germann wrote:
</pre>
<blockquote type="cite">
<pre wrap="">We're beginning to test MultiTech's CallFinder CDMA Units, one for Sprint
PCS and one for Alltel. They sell both. Our intent is to use them as a
backup line for our main office (which has a PRI) and a backup/911 line for
our remote offices which are all connected via * over a VPN with no local
trunks at any of them.
In the interest of maximizing use of the lines, I'm putting together a dial
plan that includes PCS-to-PCS/Nextel calling for the Sprint trunk.
Essentially, the PBX would look like a cell phone to the PCS cloud. Total
merged NPA-NXX list for SPCS I come up with is around 7,600 prefixes. Since
our parent has offices strung out all over the US and is standardizing on
SPCS, it makes sense to try and leverage as many PCS-to-PCS calls as we can.
Alltel comes in at around 1940 prefixes.
Has anyone found a soft limit for what * can handle in an outbound route
associated with a trunk? The box that does the routing is a new quad core
with 2GB of RAM. Any recommendations for whether to use the straight
extensions_XXXXX.conf or write a custom dialplan with a db hook in it? I'm
sort of in favor of the *.conf files since they remove an external
dependency from the dialplan, if the speed is reasonable, but a prefix list
like this is new territory for me.
If anyone is interested, drop me an email and I will be happy to share the
NPA-NXX extracts for Alltel Wireless, Sprint PCS and Nextel in CSV format.
Thanks in advance and I will be happy to share with anyone or the list if
there is interest in our experience with the devices (they're relatively
new)
</pre>
</blockquote>
<pre wrap="">I'd be curious in how asterisk would handle that. That seems like an
awful lot for asterisk to sift through although I'm sure there is some
hashing going on inside somewhere. With a db, you get to use an index,
but then have to be concerned about the time it takes to establish a
connection, extra resources used, etc.
Maybe the built in AstDB would be an option to look at as well?
</pre>
</blockquote>
<pre wrap=""><!---->
personally, I'd think a few thousand entries in the AstDB would be no
big deal;
it's based on DB1, and should handle this kind of thing with no
problems!!
I'd think it's worth investigating, at any rate! You'll have to look at
factors like query rate, db size, whether or not multiple clients are
necessary, etc. etc.
murf
</pre>
<pre wrap="">
<hr size="4" width="90%">
_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
<a class="moz-txt-link-freetext" href="http://lists.digium.com/mailman/listinfo/asterisk-users">http://lists.digium.com/mailman/listinfo/asterisk-users</a>
</pre>
</blockquote>
</body>
</html>