Routing decision based on DID

TLDR: Is it possible to route a call based on the original DID after the inbound route and if so, how?

Background

I’d like to set up a business hours announcement based on a time condition for all calls coming in on the main trunk. The trunk will carry calls for several DIDs and I would like to play the same announcement regardless of the DID, and then route the call to different destinations (different IVRs actually) based on the original DID.

The goal is to avoid creating and maintaining individual time conditions and announcements for every DID.

If it matters, I’m using a vanilla install of the most recent FreePBX image.

Possible? Yes. Easy? No.

Do you have a quantity of DIDs where it is worth the effort?

I’ve only got 4 right now; however, that may change to 10+ in the near future. I’d rather front load the work than have to update numerous branches of logic for every little change later (I’m a bit of a programmer and setting things up easy at first that are brittle later makes me itchy!). Also, since I’m a bit of a noob, I would be happy to get my hands dirty and learn as much as possible.

I have no idea how to do this, but I was thinking I could create a custom destination and then hand-code the Asterisk config (dial plan?) with the required logic. Did you have any other ideas? Would you mind getting me started with some pointers and/or examples? I’d be grateful for any help.

if it was me I would not consider this for 4 DIDs, but maybe the simplest way is to:

  1. Manually create a context in extensions_custom.conf that prepends a string of nonsense digits to the DID, then goes to context from-trunk. Configure your trunk(s) to go to this context.
  2. Create an inbound route that intercepts calls to a DID with the prefix string specified in 1, direct to time condition or whatever
  3. Process the call however you want, than go to a Custom Destination that now sends the call back to context from-trunk with the nonsense prefix now removed.
  4. Create additional inbound routes for your DIDs like normal.

Lorne made a good suggestion, and you might be overthinking this process.

Having the same recording for multiple DID announcements is simple.

I can think of at least three ways to do this without any special coding.

The first is to set up each after-hours destination so that it points to a “DID Specific” announcement. The recording for this announcement is the same as every other announcement. The “DID specific” part of the announcement is the :next destination" is the IVR for that DID.

Set up the IVR as you would normally.

It scales OK if you are adding DIDs more-or-less one at a time. Since you aren’t creating DID-Specific general announcements, your only audio gymnastics are the recordings for the individual IVRs, which were going to not scale to begin with.

Thank you both for the suggestions!

@lgaetz: that does sound like more work than necessary for 4 DIDs so I will wait until we decide whether to expand before attempting it.

@cynjut: I do like to keep things simple! :smile: However, wouldn’t I also need to set up individual time conditions and any other preceding steps for each DID? Ex: if I later had to add an announcement, IVR, etc. before the conditional office hours announcement then I would have to duplicate it for every DID, wouldn’t I?

1 Like

Hmmmmmm.

You bring up a good point. A single time-condition wouldn’t be able to discern the incoming DID as written now. The incoming DID is stored in a variable, so processing while in the context stream would be possible, but at what point would you need to differentiate the DID?

If we assume the contexts are something like:
Time-Condition
→ Day - Go somewhere
→ Night - Play announcement
→ Night - Pick an IVR
→ Night - Go to the IVR

the only step that’s challenging is the “Pick an IVR” step. You’d want to have something based on data so that you didn’t have to modify the picker every time you added a new number. Looking at $DID (assuming that’s what it is called) could actually made the context simple. Lorne suggestion could bear some fruit for you at this point - If, at the beginning of the Pick an IVR step, you added something to the beginning of the $DID, did stuff based on that, strip the stuff, and feed the number back into the “from-pstn” context (for example) then you could get there relatively simply.

I know there’s a simpler way to do this - I’ve done it “by accident” a couple of times. I just can’t remember how I did it.