Using Dynamic Routes for Call Flow Control

dynroutes
Tags: #<Tag:0x00007ff2e73cabe0>

(Lorne Gaetz) #1

The Call Flow Control module works great for giving user control over how calls get branched, provided you have exactly two destinations. Once you have more than 2 destinations, the CFC module technically can work by chaining them together, but doesn’t work well at all for that. Branching call flow based on a condition is what Dynamic Routes does best, and it can easily handle multiple destinations.

Over this past long holiday weekend, I tested this setup. For this use case, suppose you have some sort of after hours call handling, where several people take turns. Users want to be able to set the after hours destination manually to whomever is on call. Traditionally something like this would be done by logging extensions in/out of an after hours queue, or you might use a pure custom solution such as this. But it’s pretty easy to use Dynamic Routes for this as well.

Step 1 - Create Dynamic Route to set the destination

  • Create a new Dynamic Route. You will need to Enable DTMF Input and you will want to provide a sound prompt indicating correct usage.

  • In this case I’m allowing a maximum of one digit, and I’m assigning that to the input variable name dyncfc (dynamic call flow control).

  • Set the Dynamic Route Lookup Source to Asterisk variable, enable substitution and use the expression:

    ${SET(DB(dyncfc/after_hours)=[dyncfc])}
    
  • Set the default destination to hangup

  • Create a Misc Application that points to this dynroute

With the above you now have a means for users to dial the Misc Application feature code, get to a menu, hear a recording and enter a DTMF digit. That digit is stored in the AstDB under dyncfc/after_hours and then the call is terminated.

Step 2 - Create Dynamic Route to branch call

  • Create a new Dynamic Route. There is no need to enable input or provide a recording.

  • Set the Dynamic Route Lookup Source, Source Type to Asterisk Variable and use this expression:

    ${DB(dyncfc/after_hours)}
    
  • Create a separate Dynamic Route Entry for every valid input that you allow for step 1.

  • Set a default destination for wherever calls should go in case the lookup returns an unexpected result.

  • Config the system to send callers to this dynroute in place of a traditional CF control.

In the GUI it will look like this:

This second dynroute will look at the AstDB value for dyncfc/after_hours and allow you set set a different destination for for each expected value. Whenever a user changes the value using the first dynroute, calls to the second dynroute will automatically start going to the new destination, no need for an apply config.


(Andrew) #2

Clever. I use chained CFC all the time so this is great.