Asterisk works with its conf files where it finds the information it needs. At start up, Asterisk loads all the information from those files, now if you make a change in any of the conf, you have to either restart Asterisk or reload the module the file belongs to. This is our first situation, let’s call it Scenario A.
Now think about a practical deployment of Asterisk where you want do some sort of load sharing having multiple instances of Asterisk. However, you want to have same configuration for all instances of Asterisk e.g. dial plans, peers, users etc. You will have to do the tedious job of updating the conf files for each instance of Asterisk; the situation worsens if you have to make a change in any of the conf files. This is our second situation, let’s call it Scenario B.
Both of these scenarios are not a big problem, if they don’t have to be performed frequently but there are some files which might be required to be updated frequently e.g. changes in dial plans, adding/removing/updating peers or users, these files includes extensions.conf, sip.conf, iax.conf, users.conf etc.
How about putting this configuration information in an external database and having Asterisk to load that information from the database rather than files. That’s solves our problem in scenario B, put the configuration in one database and configure all instances of Asterisk to load the configuration from a single place--Database. Asterisk is equipped with the capability/feature to read the configuration from database through a feature called Asterisk Real-time Architecture (ARA). You can find more information about ARA here. Or you can find this information in ‘doc’ directory of untarred Asterisk directory. ARA mainly works in two modes: Static Real-time and Dynamic Real-time. Static Mode works like the plain conf files i.e. configuration is loaded at the startup and if you make changes, you have to do a reload; asterisk loads the configuration from the database. On the other hand, Dynamic Real-time works in dynamic way, it does load the information at the startup from database but if you make a change in database, it automatically reflects on Asterisk, that means NO RELOAD. Isn’t it great? For example, you add a sip user to database through a front end interface; it gets provisioned automatically on Asterisk!!!!! That fixes our problem for scenario A.
You can find ample information on ARA and its configuration with MySQL and PostgreSQL on the internet and Asterisk’s free book available here. I’m going to discuss Asterisk’s integration with Oracle. My discussion is more a kind of itinerary rather than a guide towards the issue, it describes what problems I faced with and what did I do to resolve them.
to be continued...
No comments:
Post a Comment