Dialplan based on CallingParty?

I have a requirement to treat calls based on CalledParty CallingParty pair: end users have ability to change how they wish calls to be treated based on who’s calling, which would also be applicable to multi-tenant environments. Potentially many 1,000s end users all with their own unique, user specified dialplan; they will not be directly configuring dialplan but user facing application will create for them based on user preferences. Surely I can’t be the only one with this type of requirement… can I?

The options I’ve considered:

extensions.conf file:

  • too difficult to manage large file, created a subfile (using #include) for each user and managed that way makes easier
  • requires dialplan reload for each end user change

ODBC Realtime:

  • Much more flexible and easy to manage dialplan based on end user config
  • Does not appear to support CallingParty qualification

Hybrid extensions.conf and Realtime:

  • Gives flexibility needed but static in dialplan length, need to create maximum length ext config for every user(?)
  • ODBC query for each step in dialplan (same as Realtime behavior?)

exten => ${EXTEN},1,${ODBC_GETDIALPLAN(${EXTEN},${CALLER(num)},1)
exten => ${EXTEN},2,${ODBC_GETDIALPLAN(${EXTEN},${CALLER(num)},2)
exten => ${EXTEN},3,${ODBC_GETDIALPLAN(${EXTEN},${CALLER(num)},3)
exten => ${EXTEN},4,${ODBC_GETDIALPLAN(${EXTEN},${CALLER(num)},4)
doesn’t work because extension cannot be evaluated at time dialplan is loaded; the error message is humorous “You have to be kidding me-- add exten ‘’ to context ? Figure out a name and call me back” :smile:
I could do the same as above with more general pattern I guess

Self-modifying Realtime:
Started down the path of self-modifying realtime database, which may work, but just seems really ugly to debug and maintain consistency over time. I would preload the database for each user so the first step in ever dialplan would be:

exten => 123,1,${ODBC_CLEARDIALPLAN(${EXTEN},${CALLERID(num})}
exten => 123,2,${ODBC_GETDIALPLAN(${EXTEN},${CALLERID(num})}

GETDIALPLAN=readsql SELECT context,exten,priority,app,appdata FROM astext WHERE CalledParty=’${ARG1}’ AND CallingParty=’${ARG2}
which would then load the rest of the dialplan for this specific call into the called party realtime context beginning at priority ‘n’ so next step in dialplan would be read as if it was already there. The details of above aren’t right just the idea
-This all assumes Realtime dialplan reads from database step at a time, which seems logical, but I don’t know for sure yet

  • Just seems “wrong” from an application perspective to have self-modifying dialplan…

AGI Scripting:
I’ve done AGI scripts to initiate actions outside Asterisk and considered their use for this application

  • Performance concerns with spawning bunch of AGI processes
  • Unclear how they would solve the requirement… I need to give that one some more thought

So I could really use some thoughts on how others may have solved the problem, multitenancy solution would probably be a step in the right direction; I am looking for suggestions

Can you clarify what you mean by how they’re treated based on callerID? Looks like you basically want to build a dynamic profile for each of your user that they can modify at any time through some GUI front? This profile should be in some database so its easy for you to allow your user to change

Then use dialplan/AGI to lookup the various options and route them accordingly in your dialplan. Not seeing the complexity whether you work in extensions.conf or in ARA. Build common macro that can be reused so you can simply pass variables to it and reusable dialing context to make it more manageable.

Imagine a multitenant pbx where each tenant is single user with few phones and a pstn connection, and local control over own personal dialplan based on calling party; tenants could call each other but that’s not very likely and they would do so over pstn so they would be treated as any other calling party at destination. All inbound calls arrive from single pstn gateway so destination context is implicit but then call treatment is determined by calling party.

Call flow:

  • call arrives pstn (already know destination user since it arrived their pstn gateway)
  • answer call, plar to user exten
  • dialplan based on calling party
  • deliver call as instructed in dialplan

As supertle suggested the plan is to create a database (done) with which end users access via web interface (not done) which asterisk then derives it’s dialplan for each user.

User 100:
if 5551212 calls send directly to vmail
if 6661212 calls ring all my phones

User 101:
if 5551212 calls ring my mobile and place user field in cdr record
if 6661212 calls play disconnected num sound, hangup

User 102:
if 5551212 calls don’t answer just hangup
if 6661212 calls ring home phone

These are just example actions, time of day dependency also likely … the end users will be constrained somewhat in what they control; app will map their desired actions into dialplan.

I’m comfortable with the mechanics of implementing the various dialplan options and believe the final solution will be realtime via odbc, which is already functional… really looking for architectural thought process, I’m thinking in terms of dialplan based on calling party, as I describe the behavior above, but perhaps there’s another perspective for accomplishing the same result. Very much appreciate suggestions.

So… what am I missing?? :smile:

Follow-on to above, where I suspect realtime dialplan will be my solution.

Does realtime dialplan query for each step in the dialplan as it’s needed? odbc query for priority 1, take action, odbc query priotity 2, take action, odbc query 3… etc

If realtime steps through dialplan as needed then my plan was to have first step of each user dialplan query app db for user call treatment of calling party and copy to realtime extensions table for duration of call then clear dialplan; essentially users would have no dialplan until an incoming call was identified, query of app db would load the dialplan based on calling party for just that call, then execute dialplan, reset dialplan for user in preparation for next call.

I have already built a very similar dialplan template within my app db that is easy to copy into user context of realtime for duration of call. Two concerns with this approach:

  • Is it architecturally ugly to have a self-modifying realtime database?
  • realtime extensions db uses auto-incrementing “id” field which increases by length of call dialplan for each call, over time high call volume could cause rollover (?), is this really an issue?

Am I crazy for this approach?