So, not quite, Astricon will be in Glendale AZ, 9 miles northwest from Phoenix downtown. The conference will be from September 23 - 25 and I’ll be speaking about the support for MFC/R2 I am adding to Asterisk, hope to see you there!
I just created 2 branches for MFC/R2 support in chan_zap for Asterisk 1.2 and 1.4, this branches replaced the patches and .tar.gz I previously published, is much easier to keep them up-to-date this way. If you still need the patches you can easily get them using svn diff.
Let’s say you need a patch against Asterisk 1.4.21.1
svn diff http://svn.digium.com/svn/asterisk/tags/1.4.21.1 http://svn.digium.com/svn/asterisk/team/moy/mfcr2-1.4 > asterisk-openr2-1.4.21.1.patch
That will create a patch to transform Asterisk 1.4.21.1 version into an OpenR2-enabled version. However this has other side-effect, changes that may have nothing to do with openr2 can be introduced. I therefore recommend using my branches directly.
I just back-ported the support for MFC/R2 signaling using the OpenR2 library to Asterisk 1.4 and 1.2, go and get it while is still hot!
I also updated the site to use TextMotion, a new web publishing software (aka CMS), works pretty well, kudos to the TextMotion devs.
I just created a branch for Asterisk that has everything required to test the chan_zap MFC/R2 support. Now the installation steps are easier.
1. Install zaptel from 1.4 branch http://svn.digium.com/svn/zaptel/branches/1.4
2. Install openr2 library from the trunk svn://libopenr2.org/openr2/trunk
3. Install Asterisk from the MFC/R2 branch: http://svn.digium.com/svn/asterisk/team/moy/mfcr2
Some people in brazil has now reported success with basic call setup. Configuration info is available at the bugtracker: http://bugs.digium.com/view.php?id=12509
The libopenr2.org site is up, but empty 
, right now I just have the SVN server, but info will be added soon as well.
I’ve been working lately in a library for the MFC/R2 telephony signalling. I named this library “OpenR2″. My goal is to include support for this signaling in the Asterisk project and eventually in FreeSwitch if possible. I just created a new issue in the bugtracker, that is the first patch I have to give MFC/R2 support in the Asterisk channel driver chan_zap. Hopefully this will eventually be the standard MFC/R2 implementation for Asterisk and finally it will “just work”.
If you are from the many people with R2 issues in Mexico or other country, you should consider to give this thing a try.
The code of the library is LGPL and is available temporarily to download from http://www.moythreads.com/openr2-april21.tar.gz.
I am in the process of getting an SVN account and will post later the link.
Patch for chan_zap: http://www.moythreads.com/chan_zap-mfr2.patch
All you have to do is download Asterisk from this branch: http://svn.digium.com/svn/asterisk/team/markster/mfr2
Then apply the patch. You will also need zaptel from this branch: http://svn.digium.com/svn/zaptel/branches/1.4
After applying the patch, please run ./bootstrap.sh in the Asterisk root directory. Then ./configure –prefix=/usr –with-openr2=/usr
Please report feedback in the bugtracker or contact me via e-mail or IM. My user at gmail it’s quite easy to remember: moises.silva
Quick note to myself: to check the version of the loaded zaptel module just cat /sys/module/zaptel/version
I have been coding some new stuff for Asterisk lately, but the feature I like the most is Asynchronous AGI. I got the idea from MAGI, an old patch written by David Pollak that allowed AGI execution thru the manager interface. For those ignoring what AGI and AMI are, go read:
Asterisk Gateway Interface ( AGI )
Asterisk Manager API ( AMI )
So, my patch, allow users to execute AGI commands using “Action: AGI” and get the response reading “Event: AsyncAGI”. The manager header “CommandID” can be specified to match up the responses. Let’s see an example
In extensions.ael you would put something like this:
context sample-async-agi {
test => {
AGI(agi:async);
};
};
That will put the channel to wait AGI commands. The channel will NOT do anything but wait for Hangup or any AGI command you ask it to execute. AGI commands can arrive from 2 sources. The most important and useful source of commands is the manager, but with my patch you can also execute AGI from the command line. Let’s see how it is done from the manager:
# telnet localhost 5038
Action: Login
Username: test
Secret: test
Action: AGI
Channel: SIP/33-blah
Command: EXEC Playback tt-monkeys
CommandID: MyCommandID
That would cause Asterisk to execute the “Playback” application on channel SIP/33-blah, which MUST be in AGI(agi:async) application. After executing the command you will be able to read an event with the AGI response url-encoded. If the channel is not in Async AGI, the command will not be executed and you will get an error response.
As I said, you can use the command line to execute Async AGI as well, just like this:
tcore*CLI> agi exec SIP/testing-09a5b960 “EXEC startmusiconhold”
tcore*CLI> agi exec SIP/testing-09a5b960 “EXEC stopmusiconhold”
tcore*CLI> agi exec SIP/testing-09a5b960 “EXEC Dial(Agent/23)”
That will start MOH, then stop it, and finally will dial to the Agent 23. This means you can implement a Queue without using native buggy Asterisk queues. You can receive calls and send them to Async AGI to put them on hold, then, when you detect availability of some of your Agents, Dial() to that agent.
If you want to learn more about this feature here is the mantis bug entry: http://bugs.digium.com/view.php?id=11282.
If you want the patch back-ported to 1.4, I have one here: http://www.moythreads.com/asterisk-1.4.15-async-agi.patch
In case you find this patch useful, please try it in trunk as well and provide feedback in mantis. Even when some people has found this patch useful, some of the top developers at asterisk-dev are hesitating in accepting it because similar results can be obtained thru the use of FastAGI, however, me and other people at asterisk-dev are trying to prove the patch also makes easier the implementation of some applications.
This is a hot discussion we got some weeks ago about it: http://lists.digium.com/pipermail/asterisk-dev/2007-December/031046.html
See you!
You gotta belive me, I love Asterisk, I have learned lots of stuff playing with it. However in the last days I have been trying FreeSwitch and reading its code. Yesterday I was hanging out at freeswitch-dev when Anthony posted a link, that I have to admit is so fucking funny!
http://www.sofaswitch.org/eg/pix/mfp_small.jpg
Enjoy,
Some weeks ago I wrote about a buffer overflow in app_conference Asterisk application when more than 160 samples per frame were received. I showed how the overflow could be fixed using Asterisk smoothers interface. Two days ago I got an e-mail from a guy in Germany ( Tom ), who had a crash in app_conference and found my blog googling about it. I send him the modified version of app_conference with my fix. Even when Asterisk stopped crashing, audio from chan_mISDN channel going to SIP channel was jittering. After adding some debugging messages to app_conference I sent him a new member.c file so he could try it and send me the resulting logs ( I had no access to his server ). The logs showed that chan_mISDN generated frames with multiple amount of samples, is not that odd? The first voice frame on the call had 640 samples encoded with ALAW ( hence 640 bytes ), that first frame was causing Asterisk crash because of the overflow I showed in my other app_conference post. But what was causing the jitter? Well, if more samples than expected can cause an overflow, what does less samples than expected can cause? yes, jitter. app_conference assume 160 samples per frame, because of 20ms RTP packeting being so common and 8000 samples per second being a telephony standard. So, receiving more samples cause overflow, and receiving less of 160 samples cause the mixing of the audio to be incomplete (zeros in the remaining mix buffer), hence, audio with jitter. As I said, chan_misdn generated frames with different amount of samples, however, most of the audio frames (99%) were being received with 120 samples, and a few ones with less than that.
Solution?
I was tempted to make a simple buffering in app_conference to queue an audio frame until enough samples were received to mix the audio, however, a quick non-code fix was achieved by configuring misdn-init.conf to generate 240 samples. That configuration along with the use of Asterisk smoothers worked like a charm 
I think I will join iax-devel mailing list to discuss this issue with app_conference developers and possibly integrate a final fix for this issues with more/less samples than expected. I saw code in app_conference that was trying to use smoothers, however the last time I checked it was disabled for some reason.
By the way, Tom nicely offered me some German beer for help with that issue.
Thanks Tom!
This week took place the Innovation in Software Engineering Latin America Symposium at IBM Guadalajara. I participated with an Asterisk session giving an overview of the Asterisk capabilities with AEL, AGI and AMI. Also I mentioned how it was possible to run Asterisk on an IBM System i Linux LPAR effectively converting the System i in a powerful IP PBX. I plan to give the same talk, but with some adjustments at ENLi the next month.