wardmundy
Nerd Uno
- Joined
- Oct 12, 2007
- Messages
- 19,199
- Reaction score
- 5,218
What appears to be a very sophisticated Smartroutes module for FreePBX has just been released. It lets you use MySQL databases to route incoming calls and was developed specifically for call centers but should have broader application as well. You can read all about it in this ticket.
The module is available in the PIAF Source Repo as well as from the FreePBX site.
Context-sensitive help is built into the module, and additional documentation should be available in a couple weeks.
Special thanks to Jay Reeder for the heads up.
The module is available in the PIAF Source Repo as well as from the FreePBX site.
Context-sensitive help is built into the module, and additional documentation should be available in a couple weeks.
Special thanks to Jay Reeder for the heads up.
SmartRoutes is a module that allows you to control inbound call routing based on external database values.
Using SmartRoutes you can route incoming calls to the appropriate queue (skills based routing), you can automatically route calls from one trunk to another (sip->tdm gateway), you can set variables in the dial plan (like cdr, caller id name, etc), strip unnecessary caller-id and did prefixes from inbound calls, and much more based on the caller id, did called or other asterisk call values.
We're using this on multiple Asterisk installs for various functions. In one case we're using it to create a simple type of SBC or SIP->TDM gateway that receives SIP calls from various vendors and looks up the DID in our CRM database to figure out if the call should be routed out one of the TDM trunks to one of the Enhanced Services Platforms or down the MPLS (SIP) to our live call center (another Asterisk server). If the MPLS fails then the call is routed out over TDM to arrive at the call center via PSTN trunks.
In each of the call centers using this module, it will lookup the customer account based on DID and determine the "Priority" of that customer and route to the appropriate queue. At the same time it pulls the account number and assigns to the CDR(userfield) and sets the account name as the caller id prefix.
The module supports both MySQL and ODBC database access. MySQL is pre-installed with AsteriskNOW and is easy to use but unfortunately it is unreliable and causes asterisk restarts in our 1.4 and 1.6 versions. ODBC support is preferable and the module will auto-manage the func_odbc.conf entries.
Additionally there is support for a feature to reset the FROM_DID and the callerid(num) to strip unnecessary prefixes. Some SIP providers pad those numbers with prefixes that might be incompatible if the call is switched back out through another SIP provider (or to an Enhanced Services Platform).
Full support for standard inbound route features (including fax) is included.
This module has been tested with FreePBX 2.7 and 2.8 / Asterisk 1.4.26 and 1.6.2.7
We're working on comprehensive documentation in web pages. It may be a week or so from being done. For now, the module has a few paragraphs on the main page and then each field has context sensitive help in the label hover.
Next we're going to add 2 yes/no questions where:
1) it will allow you to execute smartroutes before the static inbound routes so that you can dynamically divert to dynamic or alternate static routes (using EXTEN translation) based on call volume or some other variable. If there's not a smartroute match that would redirect the call then it would go on to process the static routes. An example in our call center would be that instead of sending to straight to queue, hit a high volume announcement first and then forward to queue.
2) it will track the "current calls" as described below in a table that could be used to handle dynamic routing changes such as 'High volume diversion'
Sample applications would be:
- for example to have your static routes handle the incoming calls and (in the call center) where you forward static routes to a queue, it could pass through a smart-route that simply sends the call to a queue but first checks for that 'high volume' metric and divert to a lower priority queue if a single account is flooding you (after xx calls get through).
- we could do the easy one of per-did simultaneous call limits if we wanted so that after the initial IVR, if there are too many calls for a specific customer, they get the high volume message before going into a lower priority queue.
- in the answering service industry, some customers will call forward their lines to us around 5pm and agents have to stop taking regular calls so that they can answer these calls where lines are being forwarded. Sometimes there are many lines per customer. We could automate/eliminate that with the smartroutes module. We could identify the window (time of day) using SQL HOUR(CURTIME()) and recognize the caller-id and divert to an IVR so that our staff isn't bombarded answering those calls. The IVR would give them the ability to hit a key and speak to a rep (if necessary) but it would auto-answer when they call forward and then they could just hang up.