It’s most likely we’re going to want to control out dial plan from external AGI/database rather from extensions.conf. Extensions.conf is just too limited.
Rather than writing it ourselves, is anyone aware of any companies that have written (presumbaly commercial) AGI applications that interface to a database to control the dial plan?
It is not limited if you understand what you are doing.
Rather than writing it ourselves, is anyone aware of any companies that have written (presumbaly commercial) AGI applications that interface to a database to control the dial plan?[/quote]
There is a whole list of dialplan ‘solutions’ here:
voip-info.org/tiki-pagehisto … s&diff2=17
As far as commericial apps to handle outbound call management, there are apps such as:
But based on your previous posts I would say that this is not quite what you are looking for.
It’s limited. AEL can’t use #includes, and neither can incorporate variable names into include statements. Neither can have floating VAR=VAL statements in contexts besides [global] and the ‘s’ extension doesn’t work with SIP.
All those applications are really quite simple and don’t provide the level of customisation we’re looking for unfortunately.
Customer A might want their main number to ring two phones simultaneously, then jump into one or more queues, and finally go to a company voicemail box.
Customer B might want all incoming calls to go into a Queue, then go to invidual mailboxes.
User A at Company A might have 1900 numbers blocked, and needs to have a PIC code automatically prefixed for prefixes 212,213,456 etc, and so forth.
User B at Company A might want to have all long distance blocked, and not have 1900 blocked but international is, and has different PIC codes prefixed for different prefixes.
and so forth. You get the idea. I worked for a VOIP company in 1997 and we had a replicated Oracle database that performed all the routing logic, deciding where calls would go based on the dialled number. This is far more complicated than that, because now we have the ability to dial multiple numbers, put calls into ACD queues and so forth. Every customer is going to have different requrements, and the solution needs to have the ability to customise absolutely every detail for every customer.
Of course there are limitations, just as there are in any scripting environment. But the limitations you describe above in no way inhibit you acheiving the requirements you have set out in previous posts using extensions.conf/extensions.ael. Further, you seem to still not understand how Asterisk works, as using AGI is called from an extensions.conf/extensions.ael so does not solve your percieved issue with the ‘s’ extension.
Not being able to use #include in AEL does not matter, as all the AEL interpretor does is convert the file into the standard extensions.conf logic in runtime within Asterisk. Therefore, you may use #include in extensions.conf and go about your business. Also, there is nothing described in your requirements in your posts on this forum that would indicate the need to use variables to substitute #include filenames. All #includes do is is allow you to break a single extensions.conf into multiple fragments which may be more manageable. #includes are loaded at startup, not at runtime. Once again, it appears that you do not understand the fundmentals of Asterisk as of yet and are making statements based on misunderstandings.
All doable in extensions.conf.
All doable in extensions.conf.
All doable with extensions.conf.
All doable in extensions.conf.
Indeed, and I see that everything you have described is doable in extensions.conf if you know what you are doing.
Then it is amazing to see how long it is taking you to grasp Asterisk.
Once again, what you describe is doable in extensions.conf. What the issue is, is mangeability, not that extensions.conf is ‘limited’. It most likely makes more sense for you to use an AGI that branches into a database for logic using Python (or whatever) in order to allow you to build a web interface to manage that environment.
But do not confuse creating the environment that is best for your needs with inherit limitations within the Asterisk dialplan capabilities. As clearly you are still on a steep learning curve.
Yes it does. It allows me to match all dialled numbers with _. and then perform pre-dialling initialisation in the AGI script before the number is dialled. This can’t be done in extensions.conf.
sigh So, without the ability to include variables in #include statements, we have to do:
#include “3250071-blocked.conf”
#include “3250072-blocked.conf”
…
#include “3250999-blocked.conf”
whereas with a variable we could have done…
#include “${CALLERID}-blocked.conf”
which is substantially easier.
I’d consider a lack of managability as a limitation. There’s two possible answers to your statement that I am on a steep learning curve…
a) If someone had some decent documentation, this wouldn’t be the case, and
b) I’m doing fine with Asterisk. As I stated before, we’re performing quite advanced functions with it.
Yes it does. It allows me to match all dialled numbers with _. and then perform pre-dialling initialisation in the AGI script before the number is dialled. This can’t be done in extensions.conf.[/quote]
No, it does not. You must still match a dialed SIP extension (in this case the wildcad _. matching) before you may call an AGI/FastAGI in the first place. The same situation exists whether you use the logic of an extensions.conf dialplan or an AGI that forks from an extensions.conf dialplan, as the calling mechanism is still an extensions.conf dialplan.
You may also use the wildcard matching in conjunction with GotoIfs and string/variable manipulation within the extensions.conf dialplan to acheive this. You are not solving a pereived ‘limitation’.
[quote=“dgarstang”]sigh So, without the ability to include variables in #include statements, we have to do:
#include “3250071-blocked.conf”
#include “3250072-blocked.conf”
…
#include “3250999-blocked.conf”
whereas with a variable we could have done…
#include “${CALLERID}-blocked.conf”
which is substantially easier.[/quote]
This is not possible, nor is it necessary to acheive what you are looking for. As stated before, #includes are just a way of breaking down an extensions.conf into fragments to make them more modular/manageable and are all loaded at startup. You may do your stated requirements in various ways, including the use of the MySQL cmd within the dialplan itself, or using the internal Asterisk database.
As stated, the extensions.conf dialplan does have limitations, as does any scripting environment. The point is that the requirements you describe are all doable within extensions.conf, there are not limitations in this regard.
Further, it is possible to drop the extensions.conf into a database (using Realtime) to enhance the manageability, but using the same logic.
[quote=“dgarstang”]a) If someone had some decent documentation, this wouldn’t be the case, and
b) I’m doing fine with Asterisk. As I stated before, we’re performing quite advanced functions with it.[/quote]
Your two statements above are contradictory. First you say you don’t know it because you don’t have access to decent documentation, and then you say you know it just fine. Which is it?
It would appear from the posts that number one is more accurate, as you are describing limitations that only exist in your mind. There is plenty of documentation available online and in print form, none of it is perfect so to become fluent with Asterisk it requires a creative approach and willingness to learn through trial and error. This is an opensource community project afterall.