OpenR2 1.2.0 released

Posted on August 31, 2009 by moy

I just released openr2 1.2.0

http://openr2.googlecode.com/files/openr2-1.2.0.tar.gz

Several bugs were fixed, everyone is encouraged to upgrade to this new release, which is totally API/ABI compatible with previous openr2 versions.

Posted in openr2 | Leave a comment

OpenR2 and OpenZap now integrated – MFCR2 support for FreeSWITCH

Posted on August 21, 2009 by moy

After putting this off by several weeks, I finally spent some quality time working in getting to work OpenZAP with OpenR2. The result is now available in the openzap project svn trunk:

http://svn.openzap.org/svn/openzap/trunk/

I also created some basic documentation about how to set it up: http://wiki.freeswitch.org/wiki/OpenZAP_OpenR2

This means that from now on FreeSWITCH will support MFC-R2 signaling with the same stack that Asterisk is using since 1.6.2

I still need to do some work on the documentation and lots of stress testing, but you can start playing with it and bugging me if it does not work 🙂

Posted in freeswitch, linux, openr2 | Leave a comment

Back from ClueCon 2009 in Chicago

Posted on August 9, 2009 by moy

I attended ClueCon 2009 in Chicago the past week to present “FreeSWITCH modules for Asterisk Developers”, where I discussed FreeSWITCH internals and interfaces from an Asterisk developer point of view (particularly my point of view).

The power point presentation can be found here: FreeSWITCH modules for Asterisk Developers

Chicago

The presentation will show you the key internal data structures and call flow when making a two-leg call in FreeSWITCH and Asterisk between SIP and PRI protocols. And of course, how to write modules for both telephony engines.

After the talk some people approached me to ask some particular questions, it seems the interest in creating FreeSWITCH modules and applications on top of it is increasing, it’s definitely going to be interesting what happens in the next years, the future of FreeSWITCH really looks promising.

Posted in freeswitch, sangoma, voip | Leave a comment

Sangoma cards compared to Digium’s

Posted on June 22, 2009 by moy

I am by no means a hardware guy, but found this article interesting to compare the evolution of telephony boards by Sangoma and Digium: http://www.halokwadrat.pl/sangoma-vs.-digium.html

Posted in sangoma | Leave a comment

About the Asterisk development model

Posted on June 2, 2009 by moy

This post is my opinion regarding to

http://lists.digium.com/pipermail/asterisk-dev/2009-March/037262.html (English)

http://www.saghul.net/blog/2009/03/18/sobre-el-modelo-de-desarrollo-de-asterisk/ (Spanish)

For those not involved in the Asterisk users and/or developers community, it all comes down to users complaining about Asterisk reliability and the new (1.6) development model that will allow new features to be introduced in dot releases which (they say) will make it worst. Telephony systems are damn critical. Users are used to see their computer crash (yeah, even Linux users, not that often but it happens). But telephony lines are very reliable circuits (basically because they’re very simple in nature and have been around a long time). Asterisk started a revolution and I don’t think anyone can deny that, it has brought a lot of flexibility to telephony systems, but that revolution comes of course with a cost.

I started playing with Asterisk at the beginning of 2004, I’ve seen segfaults, deadlocks and all kind of funny behaviours here and there. Sometimes a brand new release of Asterisk has basic functionality broken (like originate calls from the manager). That’s true as well, it can be said that Asterisk, out of the box, is not reliable (scalability is another beast I don’t want to talk about now), and naturally users don’t like that.

Having said that, I need to clarify what I mean by “reliable”. In this context, by reliable I mean, if you take 1.4.N release, deploy applications on top of it and then you blindly upgrade from 1.4.N to 1.4.(N+1) WITHOUT TESTING and put it in production expecting it to just work, well, good luck with that, and enjoy your new job flipping burgers at McDonalds. That is, Asterisk is not reliable for users who are not willing to put some effort when upgrading. Asterisk is a complex beast (and built on top of somewhat still shaky core), the Asterisk developers had been doing a great job improving the core, however, nasty hacks like masquerade are still there.

I don’t have problems with Asterisk being criticized, that’s what it will make it better in the end. I do have a problem though with all that people that are nothing but leeches of the community. Here is the kind of user I have a problem with:

1. They typically just ask questions in the mailing list, never spend time helping other users.
2. They download for free Asterisk and expect it to work out-of-the-box for their particular (profit) purpose without spending time not even doing their homework, testing their particular scenarios etc.
3. They bitch about Digium not fixing bugs in the bug-tracker, bugs that according to them are so damn critical to their business that they not even put a bounty on the voip-info wiki or in the asterisk-biz mailing list for someone to fix it.
4. They do not download beta releases or release candidates, they just wait for the “stable” release and again, expect things to magically work for them to profit.

In short, they don’t want to spend a single cent, nor spend some time out of their busy life, all they expect is their life to be free of problems and cash big bucks. One common argument for these users is that they are not developers and cannot help, that’s just bs, there is other ways to help and in the end you can always spend some of your free-asterisk-based business revenue to place bounties for the development of test beds or whatever you feel is needed to improve Asterisk.

At the end, I agree Asterisk development has to improve. But Digium does not has unlimited resources, and is already paying for a big team of development creating Asterisk and you can download it for free. Being free is not an excuse for lacking quality, but just think, there is limited resources and Digium is allocating those resources where it makes sense for its business. Type “core show warranty” in your Asterisk CLI and tell me what your warranty is.

In the other hand, those leech-users should know that not only users, but also some developers are unhappy with the development model (but different arguments than leech-users had). That’s why CallWeaver was born, and not only that. The biggest example I like to use of one of the foundations of open source (if you don’t like it, then fix it) is the FreeSwitch project.

The FreeSwitch project was born out of the discontent (to put it nicely) of one of the top developers of Asterisk: Anthony Minessale II, he complains a lot about Asterisk, yeah, but he also did a lot more for Asterisk than anyone else I know of beyond Mark himself and just a couple of the top developers of Asterisk. So, yes, from my perspective in some way he has earned the right to talk shit about Asterisk, because he knows it, he has proposed solutions and he has actually brought solutions: FreeSwitch. FreeSwitch has brought some serious competition to Asterisk (sorry, but let’s be serious, CallWeaver and Yate had never been close to match Asterisk functionality and usage, let alone GNU Bayonne).

FreeSwitch, from my perspective has solved many of the core problems that Asterisk has, it also solves the licensing issues (it’s MPL) and it’s developer friendly (since there is no business driving force yet behind it and you can get an svn branch right away). Probably FreeSwitch is not a short-term solution for those who are already hooked into Asterisk business, but in any case, at this point I don’t think there is short-term solutions for the problems Asterisk users complain about, it’s gonna cost ya baby, one way or another, and from my perspective that is the way is supposed to be.

In the end, Olle Johansson did quite good being the first in reply to that post and resumed the situation, which is not simple, but one thing is for sure, the community has to stop bitching and start doing. Well, I really don’t care if you keep bitching as long as you fucking do something else to make the situation better.

Posted in asterisk, freeswitch | 1 Comment

Manual de Asterisk

Posted on May 21, 2009 by moy

Solo quiero publicar un manual de Asterisk que escribi hace muchos años, los conceptos siguen siendo los mismos y las configuraciones también, tal vez uno que otro comando cambio de nombre. Habia perdido el manual pero recientemente alguien en el MSN me pregunto por el manual y luego lo encontramos en el blog de pablasso. Solo cambie el e-mail de contacto, asi que sigue siendo el mismo viejo manual, pero no del todo inútil 😛

Manual de Asterisk

Posted in asterisk | Leave a comment

Why does Asterisk consume 100% CPU?

Posted on May 6, 2009 by moy

I don’t know 🙂

But people has asked me this a couple of times lately and my answer is always “I don’t know”. However ps can give you more information about it. In fact, this works for any application you have and you want to debug why is going crazy.

First, check which thread (Asterisk is a multi threaded application) is going crazy.

# ps -LlFm -p `pidof asterisk`

That should show you the % of CPU being used by each Asterisk thread in the column named “C”, then write down the LWP colum value for the thread you are interested on. (LWP is a light weight process number, roughly speaking, the thread id). Now that you have the thread id, you need to know what that thread is doing.

# pstack `pidof asterisk` > /tmp/asterisk.stack.txt

That will cause the asterisk process to dump the stack state to the /tmp/asterisk.stack.txt file. If you don’t have the pstack command google for it, I think in CentOS is as easy as yum install pstack.

Then open the file and search for the LWP that you just wrote down. Hopefully you will find some hints that let you know how to avoid it or at least a lot more information to post in bugs.digium.com

UPDATE:
One of the guys who asked this question later told me what he found:

Thread 10 (Thread 0x41d8f940 (LWP 3406)):
#0 0x00000033ce2ca436 in poll () from /lib64/libc.so.6
#1 0x00000000004933c0 in ast_io_wait ()
#2 0x00002aaabd9510cd in network_thread ()
#3 0x00000000004f8b2c in dummy_start ()
#4 0x00000033cee06367 in start_thread () from /lib64/libpthread.so.0
#5 0x00000033ce2d2f7d in clone () from /lib64/libc.so.6

A quick grep -rI “network_thread” in the Asterisk source code reveals this function belongs to chan_iax.c, disabling chan_iax.so in modules.conf is a good workaround to his problem, however further debugging would be needed to determine why the monitor thread is looping like that.

Posted in asterisk, linux | 21 Comments

Cluecon 2009

Posted on May 5, 2009 by moy

I will be speaking at ClueCon this year. The talk will be about writing FreeSwitch modules and how the development process compares to writing modules for Asterisk in terms of APIs. If you are interested in learning how to write modules for Asterisk and/or Freeswitch, this is your chance!

The full schedule is still being prepared so be sure to check the site later when it’s done.

I could not decide which banner to use here, so I decided to put 3 I really liked 🙂 … if you use any open source telephony application, support developers by attending or at least putting one of these banners on your site.

From the ClueCon site:
ClueCon – is an annual 3-Day Telephony User and Developer Conference bringing together the entire spectrum of Telephony from TDM circuits to VoIP and everything in between. The presentations and discussions will cover several open source telephony applications such as Asterisk/Callweaver, OpenSIPS/Kamailio (formerly OpenSER), Bayonne, YATE and FreeSWITCH. Other great projects that will be discussed include OPAL and Woomera.

More funny banners at: http://files.freeswitch.org/cluecon_2009/

Posted in freeswitch, voip | Leave a comment

MFC-R2 support in Asterisk trunk

Posted on March 17, 2009 by moy

I am glad to announce that MFC-R2 support has been merged into Asterisk trunk. Today I just got an e-mail from Russell, the team lead of the Asterisk development team confirming the merge and that the upcoming version Asterisk 1.6.2 will be the first one having built-in support for this signalling.

More details in the following commit: http://lists.digium.com/pipermail/asterisk-commits/2009-March/031735.html

I want to thank all the people that supported the development of OpenR2 with code, testing and build infrastructure. Particularly thanks to:

Neocenter, company located at México, Distrito Federal, that supported the development of OpenR2 from the very beginning, even when I myself was not even sure it could work. Thanks Octavio, Pop and Alejandro.

Sangoma Technologies For their sponsorship during all this time.

Digium Inc for creating Asterisk.

Alexandre Alencar for all his contributions to the project in different areas.

There is obviously more people that has contributed, you all know who you are 🙂

Posted in asterisk, openr2 | Leave a comment

G729A and G723.1 support for FreeSwitch

Posted on February 8, 2009 by moy

The past weekend I spent some time writing a module for the FreeSwitch project in order to support the G729A codec in it. This codec is patent encumbered, however, my target was not to do this in software, but just create the software interface for FreeSwitch to talk with a PCI card manufactured by Digium that does the transcoding for G729A and G723.1 .

This is the data sheet for the TC400B board. The programming interfaces to access the encoders and decoders is not documented (or at least I could not find any documentation), but it’s enough to have available the source code for the module in Asterisk that uses that very same board.

This board expose its available encoders to the DAHDI / Zaptel core driver, which in turn exposes all transcoders registered by the boards through the Linux filesystem in /dev/dahdi/transcode or /dev/zap/transcode, depending on whether you have Zaptel or DAHDI drivers.

Here I want to explain the few interfaces required to use this board.

The first thing you usually want to do is verify that there is encoders and decoders available. This is done through an ioctl to request the information about the availability of these transcoders. 

        struct dahdi_transcoder_info info = {0};

        fd = open("/dev/dahdi/transcode", O_RDWR);
        if (fd < 0) {

                fprintf(stderr, "Failed to open dahdi transcode device\n");
                exit(1);
        }
        for (info.tcnum = 0; !(res = ioctl(fd, DAHDI_TC_GETINFO, &info)); info.tcnum++) {

                printf("Found transcoder '%s', numchannels = %d, dstfmts = %d, srcfmts = %d.\n", info.name,
                                info.numchannels, info.dstfmts, info.srcfmts);
        }

        close(fd);

The driver will let you know the number of encoders, decoders and the source and destiny formats. The formats masks can be found in /usr/include/dahdi/kernel.h. In future versions that may change, I discussed this with one of the DAHDI developers, since I think that this should be in dahdi/user.h and not in kernel.h given that is a user space interface.

Once you know which transcoders are available you can request an encoder or decoder, or both.

        int encoder_fd, decoder_fd;

        struct dahdi_transcoder_formats g729_encoder;
        struct dahdi_transcoder_formats g729_decoder;
        
        g729_encoder.srcfmt = DAHDI_FORMAT_ULAW;

        g729_encoder.dstfmt = DAHDI_FORMAT_G729A;

        g729_decoder.srcfmt = DAHDI_FORMAT_G729A;

        g729_decoder.dstfmt = DAHDI_FORMAT_ULAW;

        encoder_fd = open("/dev/dahdi/transcode", O_RDWR);

        if (encoder_fd < 0) {
                printf("Failed to open transcode device\n");
                exit(1); 
        }   
        if (ioctl(fd, DAHDI_TC_ALLOCATE, &g729_encoder)) {

                printf("Failed to allocate encoder\n");
                close(encoder_fd);
                exit(1); 
        }

        decoder_fd = open("/dev/dahdi/transcode", O_RDWR);
        if (decoder_fd < 0) {

                printf("Failed to open transcode device\n");
                exit(1); 
        }   
        if (ioctl(fd, DAHDI_TC_ALLOCATE, &g729_decoder)) {

                printf("Failed to allocate decoder\n");
                close(fd);
                exit(1); 
        }

Finally, once allocated, you just have to write chunks of ulaw data and read chunks of decoded g729 data and viceversa. You can choose whether the device will accept ulaw or alaw to g729 or g723 manipulating the srcfmt and dstfmt members of dahdi_transcoder_formats. Just remember that ulaw or alaw encoded data requires 8 times more bytes than g729 encoded data, therefore if you write a frame of 20ms of alaw (160 bytes for a sampling rate of 8000hz) you will read just 20 bytes of g729 encoded data, of course, the same apply when you decode a g729 frame or for g723 (for which alaw and ulaw requires 12 times more space).

The module is available here under the MPL license. Also, the module was just commited to trunk yesterday in the Freeswitch SVN repository. I want to thank to Voiceway for sponsoring the module and Neocenter for providing the hardware to test it.

Posted in freeswitch, linux | 4 Comments