Drupal - Asterisk Integration Works

Events happening in the community are now at Drupal community events on www.drupal.org.
davec611's picture
Posted by davec611 on June 19, 2006 at 7:41pm

As far as I can tell, our site www.forestlake.ca is currently the only working example of asterisk drupal integration. I would love to be disabused of this notion, so if there are other working sites out there, please let us know.

At any rate you can read about the "Forest Lake Telephone Company" at this posting on drupal .org: http://drupal.org/node/59187 or you can just register and try it out on the forest lake site. Go to : http://forestlake.ca/forestlake/?q=node/466 for instructions on trying it out.

The good news in all this is that I have an asterisk server all ready and working with Drupal. If you want to install and test the asterisk integration module developed by Malthus, you can do so by downloading and installing the asterisk module (http://drupal.org/project/asterisk) on your site. (Important, as far as I know, the asterisk integration module only works so far on 4.6. I do not know what plans Malthus might have to upgrade).

Once you have installed and activated the module you can register your site on our asterisk server by going to http://www.vcg.net and following the instructions on the front page. Assuming a successful install and registration, the asterisk server will then poll your site every minute to initiate calls that your users have entered.

Some caveats: This is for testing purposes only. Currently I am successfully completing PSTN calls using voipjet.com. (I have not actually tested sip or iax only calls. I would be most happy if someone were to try those). This means there are some minor costs. I dont mind covering the odd test call within North America,( rates of 1.2 cents a minute )but if you are going to have two hour calls with your aunt in Afghanistan, or start putting more than the occasional call through, we will have to discuss some cost recovery.

If this all sounds loosey goosey - it is! I am doing this in the interests of stirring the asterisk pot and perhaps getting some needed development going. Malthus has already provided an asterisk road map at http://drupal.org/node/37571 which is worth a read. I will add some additional suggestions for asterisk development based on our experience in a later post.

I intend to cross post this on www.drupal.org as well as here.

I would love to hear your comments

regards

Davec

Forest Lake Online

Categories:

Comments

New Asterisk module maintainer

Posted by hunmonk on September 19, 2006 at 6:11pm
hunmonk's picture

hi,

i wanted to introduce myself as the new maintainer of the Asterisk module. after some discussions with Malthus, it was decided that i should take over maintainership, since i'm currently the one doing all the work on the module. :)

so now it's time for the good news and the bad news...

good news:

  • i have upgraded the module to drupal 4.7, and have plans to also upgrade it to 5.0 within a month or so
  • i have completely redesigned the workflow of the module, partially based on the roadmap Malthus provided, and partially on some ideas i had of my own. basically, the workflow has been reversed--the Asterisk server no longer polls the Drupal server. instead the Drupal server sends it's calls to the Asterisk server via XML-RPC.
  • the reversed workflow offers a number of excellent benefits:
    1. calls placed from the Drupal site happen in near real time. my testing has indicated that from the time you initiate a call on the Drupal site, you'll get a ring on the other end of a NANPA number in 5-10 seconds. It looks to me like most of that delay (which isn't much!) is a result of the time it takes for my provider to connect the call--the XML-RPC calls and Asterisk response are nearly instantaneous.
    2. the load on the Asterisk server is decreased significantly. Running a cron every minute where you may be issuing dozens of XML-RPC calls wasn't exactly efficient... :) Now, XML-RPC calls are only made when there is something that actually needs to happen, as in a call being placed. also, because Drupal intiates the calls, i was able to move some of the code processing stuff to the Drupal side--better again for the Asterisk server, whose only job should be to place the calls.
    3. if the Asterisk server is set up with a secure XML-RPC server (which is highly recommended), then everything is transmitted in a secure manner, including any recording/playback files!
    4. client-side setup of the module has become a breeze. you simply need to install/enable the module, set up perms, and enter the appropriate XML-RPC server and password for the Asterisk box you're connecting to (and possibly the XML-RPC server for the Drupal site if it happens to be different from the default) and you're done!

bad news...

  • the new server side approach isn't compatible at all with the old approach, so this means that you either run an Asterisk server w/ the 4.6 approach, or with the 4.7 approach, and only connect sites that have the appropriate client side installed. it may be possible to have both server side approaches running on one Asterisk server, but i doubt it, given that the dialplan has changed. maybe we can look at creating a legacy dialplan context if there are people desperate to stay on 4.6
  • at this point you have to install an XML-RPC server on the Asterisk box, and you really should make it a secure one so site passwords aren't flying around in plain text... :) this means installing a webserver on the Asterisk box, which will take some of the server's processing power away from Asterisk. at this point i'm not sure how well that would scale, but the good news is that outside of file loading, the XML-RPC calls are pretty low overhead in processing power and bandwidth.

now my plan for bad news #2 is to rework the server-side code to support the XML-RPC server and the Asterisk server being on different boxes. this will solve the problem, but also make the setup of the server-side more difficult. i'm ok with that, because one of the things we found with the first iteration of the Asterisk module was that it was a bitch to set up the Asterisk server anyways for folks who have no experience with it! which means to me that, really, only people who know what they are doing should be setting up the server side of things--and for them i haven't raised the bar too much with this new approach. it's a trade-off: make the client side easier and the server-side harder, which i believe will ultimately result in making this module much more usable. :)

my demo site is here: http://asterisk.drupal.xcarnated.com

like you i haven't really messed w/ the iax/sip stuff yet--but i'll test that and make sure it works properly in the near future. i'm afraid i'm not quite as cavalier as you are about letting people make calls. :) i only enable accounts for testing when somebody is demo'ing with me, for a couple of different reasons. but please feel free to shoot me an email or sign up for a demo account on that site, and we can schedule a demo for you.

I'm really excited about the new direction of the module--hopefully you'll join me!

overview

Posted by Anonymous on October 23, 2006 at 10:43am
Anonymous's picture

I just started to work with asterisk.kindly send me few links of work flow,how does it work exactly with files and modules.

doc

Posted by hunmonk on October 23, 2006 at 2:48pm
hunmonk's picture

sorry, there's no documentation of that kind available at this time. i'll answer a specific question if you have it, or you can look through the module code and figure it out for yourself.

http://cvs.drupal.org/viewcvs/drupal/contributions/modules/asterisk/

CiviCRM

Group organizers

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: