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”
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})}
where
CLEARDIALPLAN=readsql DELETE FROM astext
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