[asterisk-users] Large number of prefixes in a route to a trunk

[Lee Jenkins]

Eric Germann wrote:
> 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)
> 

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?

-- 

Warm Regards,

Lee