Skip to main content

Tips on how to route inbound calls based on CallerID?

Posted by beedsley on Fri, 05/01/2009

I assume a script would be used here, but some help would be appreciated.


Submitted by eeman on Fri, 05/01/2009 Permalink

not scripts, AGI in order to do DB lookups. We wrote one for another customers STE build to route based on area code. This is not practical for MTE.

Submitted by beedsley on Tue, 05/12/2009 Permalink

We found that we could route inbound calls based on 10 digit callerid using the "User Portal".

Works just great for when we are collecting our voicemails using our cell phones, drops us right into the voicemail box, not having to wait for the extension to ring.

Submitted by eeman on Wed, 05/13/2009 Permalink

beedsley, user portal would be ok for 1 or 2 'conditions' but if you are talking about an array of data with thousands of records that would not be practical. We had a customer that wanted to maintain a call center with several queues, where by each queue would only service a specific geographical area. So they wanted a database table populated with every NPA/NXX and as the call came in it would lookup ${CALLERID(num):0:6} and return the extension to route the call to (each queue had a feature extension). They do some 10,000 call records per day so I didnt want to use the MYSQL command in extensions.conf format and risk any kind of issue with a hangup before the disconnect is issued etc.

Submitted by cbbs70a on Wed, 05/13/2009 Permalink

Sorry, but I don't agree. Even in the case where the customer is a call center, (which I do not think is the case here, but I could be wrong) 10,000 lookups in a day is not that big of a deal, especially if you are going to use the BerkeleyDB. 10,000 lookups a day is 1 every 3.6 seconds. A well designed database and a well designed dialplan would never break a sweat even with a large number of records.

But then again, thats been my experience with my setup.

FSD

Submitted by eeman on Wed, 05/13/2009 Permalink

your suggesting a bastardized setup to load some 250,000 NPA/NXX into berkleydb? when php/mysql is so much easier?

Submitted by cbbs70a on Wed, 05/13/2009 Permalink

Dude, I'm suggesting that BerkleyDB is A way to go, not necessarily THE way to go. Ultimately, there is not enough information here to say which is the optimal route to go. How many lookups, how many DB entries, how many tests and conditions in the dialplan, etc all contribute to the final solution design.

I've gone as high as 5,000,000 mysql entries to see how far I can push things. 250,000 npa/nxx enties is a walk in the park. But thats just my opinion. You certainly know more than I do when it comes to MTE.

FSD